-1

I ran into some really weird problem with the compilation of a very simple code

typedef volatile struct _underflow_test
{
    unsigned int    OPERATION_MODE;
    unsigned int    UNDERFLOW;
} underflow_test;

This code fails to compile in MSYS2 using gcc12.2. Using the -E option I have checked that the code about is converted to this:

typedef volatile struct _underflow_test
{
    unsigned int OPERATION_MODE;
    unsigned int 
# 4137 "C:/Users/work/eec_control/TC367_project/Libraries/Infra/Sfr/TC36A/_Reg/IfxGeth_regdef.h" 3
                      4
# 4137 "C:/Users/work/eec_control/TC367_project/Libraries/Infra/Sfr/TC36A/_Reg/IfxGeth_regdef.h"
                               ;
} underflow_test;

So preprocessor converted UNDERFLOW into just 4. Then this conversion fails to compile. Using the gcc11 doesn't do this - it doesn't convert UNDERFLOW field into 4.

The command line is the same in both cases:

cd C:/Users/work/build-eec-gnu/core_files/bsp && C:/msys64/mingw64/bin/gcc.exe 
-DROOT_INSTALL_DIR="\"C:/Program Files (x86)/eec-control\"" 
@CMakeFiles/bsp-core-tc367-a1.dir/includes_C.rsp 
-Wall -Wextra -Wno-unknown-pragmas -Wfloat-equal -Wconversion -Wparentheses -Wunused-parameter -Wunused-variable -Wstrict-prototypes  
-DMAJOR_RELEASE_NUMBER=1 -DMINOR_RELEASE_NUMBER=0 -DPATCH_RELEASE_NUMBER=42 -E -O0 -DNDEBUG -g 
-fdiagnostics-color=always -std=gnu99 -MD -MT core_files/bsp/CMakeFiles/bsp-core-tc367-a1.dir/hal.c.obj 
-MF CMakeFiles/bsp-core-tc367-a1.dir/hal.c.obj.d -o CMakeFiles/bsp-core-tc367-a1.dir/hal.c.obj 
-c C:/Users/work/eec_control/core_files/bsp/hal.c

Anyone know what could be causing this and how to solve this strange effect? Perhaps I'm missing something.

ilya1725
  • 4,496
  • 7
  • 43
  • 68
  • 1
    Well, you have `#define UNDERFLOW 4` in `C:/Users/work/eec_control/TC367_project/Libraries/Infra/Sfr/TC36A/_Reg/IfxGeth_regdef.h`. – HolyBlackCat Feb 20 '23 at 06:05
  • If I did, the same error would have occurred with `gcc11`. But it doesn't. – ilya1725 Feb 20 '23 at 06:13
  • 1
    The command line you are showing compiles `hal.c` as C, not C++. So why is `c++` tagged? Your test code doesn't include anything, so where is the mentioned file included from? Also `_underflow_test` is a reserved name in the global namespace scope in C++ and may not be defined by the user because it starts with an underscore. – user17732522 Feb 20 '23 at 06:23
  • Well, you need to debug it. Maybe the macro is defined conditionally, and is disabled in GCC 11. Maybe GCC 11 doesn't use that header at all. Figure out why. – HolyBlackCat Feb 20 '23 at 06:24
  • 1
    `UNDERFLOW` seems to be defined by `#include ` if neither `__STRICT_ANSI__` nor `NO_OLDNAMES` is defined. See https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/math.h – Ian Abbott Feb 20 '23 at 14:15

1 Answers1

0

Kudos to Ian Abbot for the nudge to the right direction. It was caused by the #define collision between the common code and my supplier's code. The supplier's code expected strict ANSI code without GNU extensions.

The fix is to set the CMake extensions flag using set(CMAKE_C_EXTENSIONS OFF).

ilya1725
  • 4,496
  • 7
  • 43
  • 68