Sysprogs forums › Forums › VisualGDB › Mismatched warnings between Clang and GCC
- This topic has 8 replies, 2 voices, and was last updated 5 years, 10 months ago by support.
-
AuthorPosts
-
January 14, 2019 at 20:58 #23445AncarithaParticipant
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 warningsIf 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 warningsAnyone 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!
January 14, 2019 at 21:29 #23447AncarithaParticipantOk… 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.
January 14, 2019 at 21:39 #23448AncarithaParticipantOn 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.
January 14, 2019 at 22:05 #23453supportKeymasterVisualGDB 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?
January 14, 2019 at 23:22 #23460AncarithaParticipantI 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…
January 14, 2019 at 23:52 #23463AncarithaParticipantWell, 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…
January 14, 2019 at 23:55 #23465supportKeymasterYou 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.
January 15, 2019 at 00:23 #23468AncarithaParticipantUnfortunately I’m using make, so that’s not an option. Oh well, disabling the warning it is.
Thanks for the help!
January 15, 2019 at 00:28 #23470supportKeymasterNo 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.
-
AuthorPosts
- You must be logged in to reply to this topic.