__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.

 

publicaciones de 6 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

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.

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

 

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya