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 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?



6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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;


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.


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: &

- 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


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.


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


Leave a Comment

Please sign in to add a comment. Not a member? Join today