__GNUC_PATCHLEVEL__ Value

__GNUC_PATCHLEVEL__ Value

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.

 

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;
}

 

Jennifer J. (Intel)'s picture

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

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

 

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

 

Login to leave a comment.