Mismatched warnings between Clang and GCC

[Ancaritha]

I’m seeing an odd warning that I’m having a hard time to figure out.  The same line of code will give different warnings for GCC and for Clang.  I think the GCC one is incorrect (looking at the wrong header file or something) but I am uncertain how to fix this.  I am using VisualGDB 5.4 Beta 2 and ARM toolchain 7.2.0/8.0.1/r3

Here is the offending line of code:   ‘snprintf(pOut, nLen, “%d”, (int32_t)nSignedVal);’
Here is the GCC message: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘int32_t {aka long int}’ [-Wformat=]
I get no Clang warnings

If I change the code to:   snprintf(pOut, nLen, "%ld", (int32_t)nSignedVal);
I get: [Clang IntelliSense] Warning: format specifies type ‘long’ but the argument has type ‘int32_t’ (aka ‘int’)
I get no GCC warnings

 

Anyone have any idea on where I can start hunting to figure this out?  I use snprintf kind of a lot and it overloads the warning messages making it easy to drown out real warnings I’d care about.

Thanks!

[Ancaritha]

Ok… I do have multiple compilers on my computer, and one of them does define “int32_t” as a “signed long int” inside of it’s stdint.h

 

Since SysGCC is not in my systems path file and it’s only ever referenced by $(TOOLCHAIN_ROOT), I bet this is the problem.  It’s looking up those header files and it’s finding the ones in my path rather than the ones in SysGCC.

[Ancaritha]

On further evaluation, that doesn’t actually make sense.  The /include folders aren’t in my path, so it shouldn’t be able to find them that way.  The compilers must be referencing them by relative path.  Soooooooooo, back to square 1.

[support]

VisualGDB would query the include search path by running gcc from the toolchain and letting it dump the specs (macros and include paths), so it’s usually very accurate.

Please try clicking on “int32_t” and select “Go to definition”. Does the file/location shown there make sense?

[Ancaritha]

I suspect that VisualGDB is the one that is correct, which makes me wonder exactly what GCC is compiling against…

The first one brings me to:    typedef __int32_t int32_t ;    in _stdint.h (c:\SysGCC\arm-eabi\sys-include\)
Go to on __int32_t brings me to:

#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ __int32_t;
#endif

in _default_types.h (c:\SysGCC\arm-eabi\sys-include\machine\)

From there, right-click Go To Definition doesn’t bring me anywhere.  However, while searching around for that, I found it in the gcc_debug.h and gcc_release.h files:

#ifndef __INT32_TYPE__
#define __INT32_TYPE__ long int
#endif

Initially this looked like the culprit, but I manually edited both files (just in case) and threw in some gibberish inside of that ifdef and did a rebuild and it didn’t crash, so I don’t think that’s active.  Just to make sure, I completely removed that entry and did a rebuild.  No change.  And just to really really make sure, I changed them to long long ints, no change.

So that means somewhere  __INT32_TYPE__ is being defined… I just have to find it.  I did a search in Windows Explorer in my solution folder, the entire SysGCC folder and the entire drivers folder in the STM32L4 framework, and it didn’t find anything (which I know is a lie, since it should have found the gcc_debug.h file at the very least).  So now I’m going to go refresh my memory on how to use grep on Windows…

[Ancaritha]

Well, no luck finding it.  Fun fact, though, there is a file in C:\SysGCC\arm-eabi called  IntelliSense.props.  In that file is the line:   __INT32_TYPE__=long int   It also has matches (according to grep) in the cc1.exe and cc1plus.exe files, but since they’re binary it doesn’t show me the outputs.

Unless you guys have any other ides, I think I’m just going to turn off the Wformat warning…

[support]

You could try enabling the preprocessor output (via VS Project Settings -> C/C++ if you are using MSBuild) to track this down (it will expand all preprocessor macros and include directives and save the output to a .E file), however disabling/ignoring this warning should be completely OK unless you are planning to port your code to ARM64.

[Ancaritha]

Unfortunately I’m using make, so that’s not an option.  Oh well, disabling the warning it is.

Thanks for the help!

[support]

No problem. For Make you could try doing the same manually (extract the gcc command line from the logs and then replace -c with -E and .o with .E and run it), but ultimately it may not be worth the effort.

[Author]

Posts