- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For my Linux applications, I like to embed compiler information into the executables. For the Intel compiler, the __INTEL_COMPILER and __INTEL_COMPILER_UPDATE pre-processor macros give me what I want. However, I also like to embed the GNU compatibility information, too. __GNUC__ and __GNU_MINOR__ give me accurate information, but __GNUC_PATCHLEVEL__, while defined, does not contain the correct value.
For example, when using icpc 14.0.2.144 with g++ 4.8.2, __GNUC__ is set to 4, __GNUC_MINOR__ is set to 8, but __GNUC_PATCHLEVEL__ is set to 0. I was expecting 2, and I would really like to get the correct version without making a system call.
Is this a bug, an unsupported feature, or am I doing something wrong?
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe icc is calculating patchlevel correctly. I tried this program with gcc 4.8.2
icc patchl.c
-bash-4.1$ ./a.out
patchlevel is 2
-bash-4.1$ gcc patchl.c
-bash-4.1$ ./a.out
patchlevel is 2
-bash-4.1$ cat patchl.c
#include <stdio.h>
int main(void)
{
int lev = __GNUC_PATCHLEVEL__ ;
printf("patchlevel is %d\n", lev);
return 0;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What version of icc do you have? the icc 14.0 works as Melanie noted above.
If you have icc 13.0, it does not support gcc 4.8.
Jennifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Melanie & Jennifer,
Thanks for the responses. I tried Melanie's sample code, and when I run it, I get "patchlevel is 0".
My setup:
- os: SLES 11.2 with kernel 3.0.93-0.5. So, I'm not using a deprecated OS according to the release notes.
- icc versions tested: 14.0.1.106 & 14.0.2.144
- gcc version 4.8.2, verified via [ gcc --version ]. This tool was manually built by my admin, and it sits in a tree in the opt directory. The distribution supplied compiler (4.3.4) remains in the normal distribution locations.
When I build my code and your test-code, I also use the gcc-name and gxx-name arguments of icc to point to the desired gnu tool chain. I have also pre-pended the new compiler location to my system path.
If I dump the macro definitions using [ icpc -dM -E -x c++ /dev/null | grep PATCH ], I get [ #define __GNUC_PATCHLEVEL__ 0 ]. Once again, I am hoping for 2.
Anything look wonky?
- paul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did my testing using the development compiler, but I do see the problem in the 14 branch. In your case, it appears that you could use a workaround like this: create a compilation unit with a function that returns the patchlevel, and compile that function with gcc, and call it from the part of your program that embeds compiler information.
I've created DPD200253561 for this issue & thanks for the report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was DPD200253561 supposed to be included in Update 3?
I repeated all of the tests outlined above, but an incorrect patch level is reported. It is, however, a different incorrect patch level. For GCC 4.8.2, the patch level is reported as 1.
If I repeat the tests with the V15 beta, the patch level IS reported as expected.
Is there a site that I can use to track case numbers?
Thanks again for your help!
- paul
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page