#define X (MinGW)

[syzygy]

Does there exist an option to switch off this rogue behavior w.r.t. the X macro?

Sounds like a compiler bug, but anyway try something like

Code: Select all

#define X _X_rename
#include "standardheaders"
#undef X
#define X ... // Your definition

at the top of your code.

But that will not replace "#define X bla" that supposedly is present somewhere in the included headers with "#define _X_rename bla".

Yes, that's true. I think I made a leap in logic because the compiler "not allowing to #undef the symbol" suggested to me that it wasn't actually a macro. Otherwise #undef X after including the headers should work.

But if Oliver is right that there is no macro X but a function X, it would seem to work.

But judging from what little information HGM gives, it seems to be neither a macro X nor a function X, but a problem with what HGM's macro X expands to.

Or there is just a bad line ending somewhere that messes up compilation on Windows.

[hgm]

When I used the #define X in isolation, the error did not occur, and neither did it when I deleted the part of the program behind it. So I selectively deleted part by part to see what part of the remaining program it needed to evoke the error. From this it turns out that a later #include of <windows.h> is needed to trigger the error. So the following code:

Code: Select all

#define X 36    /* infinite range (B, R, Q)       */
#define Y 37    /* jumping slide (BG, RG, VG, GG) */
#define Z (Y+3) /* orthogonal GG jumping slides   */
#define J (~0)  /* jump to second square (Ph, Kn) */
#define E (~36) /* X or J (FE, LH)                */
#define L (~1)  /* 1 or J (Ln, SE, HF)            */
#define T (~Y)  /* Tetrarch (skip-slide + igui)   */
#define N (-1)  /* moves as Knight                */
#define F (-2)  /* shogi Knight                   */

#ifdef WIN32 
#    include <windows.h>
#endif

produces:

Code: Select all

C:\cygwin\home\hachu>gcc -O2 -s test2.c -o ten2.exe
test2.c:9:12: error: expected identifier or '(' before '-' token
 #define N (-1)  /* moves as Knight                */
            ^
test2.c:2:11: error: expected identifier or '(' before numeric constant
 #define X 36    /* infinite range (B, R, Q)       */
           ^
test2.c:3:11: error: expected identifier or '(' before numeric constant
 #define Y 37    /* jumping slide (BG, RG, VG, GG) */
           ^

I don't understand how a later #include can pro-actively spoil a #define that occurs in the source before it; I thought that pre-processor definitions only take effect downstream.

From the error message it seems to think that a formal-parameter list should mandatory follow the macro names X, Y and N.

When I move the #include <windows.h> to before the #defines, the error disappears!

[BeyondCritics]

I don't understand how a later #include can pro-actively spoil a #define that occurs in the source before it; I thought that pre-processor definitions only take effect downstream.

The first gcc error message is provably wrong.
gcc has always been infamous for its terrible error messages. You could try to compile with clang or visual studio.

When I move the #include <windows.h> to before the #defines, the error disappears!

Well, this is your bug. You have to include system headers first, no matter why.

[petero2]

When I used the #define X in isolation, the error did not occur, and neither did it when I deleted the part of the program behind it. So I selectively deleted part by part to see what part of the remaining program it needed to evoke the error. From this it turns out that a later #include of <windows.h> is needed to trigger the error. So the following code:

Code: Select all

#define X 36    /* infinite range (B, R, Q)       */
#define Y 37    /* jumping slide (BG, RG, VG, GG) */
#define Z (Y+3) /* orthogonal GG jumping slides   */
#define J (~0)  /* jump to second square (Ph, Kn) */
#define E (~36) /* X or J (FE, LH)                */
#define L (~1)  /* 1 or J (Ln, SE, HF)            */
#define T (~Y)  /* Tetrarch (skip-slide + igui)   */
#define N (-1)  /* moves as Knight                */
#define F (-2)  /* shogi Knight                   */

#ifdef WIN32 
#    include <windows.h>
#endif

produces:

Code: Select all

C:\cygwin\home\hachu>gcc -O2 -s test2.c -o ten2.exe
test2.c:9:12: error: expected identifier or '(' before '-' token
 #define N (-1)  /* moves as Knight                */
            ^
test2.c:2:11: error: expected identifier or '(' before numeric constant
 #define X 36    /* infinite range (B, R, Q)       */
           ^
test2.c:3:11: error: expected identifier or '(' before numeric constant
 #define Y 37    /* jumping slide (BG, RG, VG, GG) */
           ^

I don't understand how a later #include can pro-actively spoil a #define that occurs in the source before it; I thought that pre-processor definitions only take effect downstream.

They do take effect only downstream. The error message from gcc is referring to a useless position in the code though. The file ia32intrin.h is included from windows.h. Lines 261-267 look like this:

Code: Select all

/* Write flags register */
extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__writeeflags (unsigned long long X)
{
  __builtin_ia32_writeeflags_u64 (X);
}

When X is defined to be 36, the preprocessed code is invalid. However it seems that the compiler detects that the error occurs at a code position that has been changed by macro expansion, and then decides to refer in the error message to the position where X was defined instead of the position where X was used.

To figure out what was going on I ran the code through the gcc preprocessor like this:

Code: Select all

x86_64-w64-mingw32-gcc -O2 -Wall -E test.c >test.e

Then I searched for 36 in test.e and found:

Code: Select all

extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__writeeflags (unsigned long long 
# 264 "/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/ia32intrin.h"
                                 36
# 264 "/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/ia32intrin.h" 3 4
                                  )
{
  __builtin_ia32_writeeflags_u64 (
# 266 "/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/ia32intrin.h"
                                 36
# 266 "/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/ia32intrin.h" 3 4
                                  );
}
# 28 "/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/x86intrin.h" 2 3 4

[syzygy]

So this is a bug in gcc's ia32intrin.h header file.

It can be reproduced with regular gcc on Linux:

Code: Select all

#define X 36

#include <x86intrin.h>

Code: Select all

$ gcc test.c
test.c:1:11: error: expected ‘;’, ‘,’ or ‘)’ before numeric constant
 #define X 36
           ^

[Evert]

So this is a bug in gcc's ia32intrin.h header file.

It can be reproduced with regular gcc on Linux:

Code: Select all

#define X 36

#include <x86intrin.h>

Code: Select all

$ gcc test.c
test.c:1:11: error: expected ‘;’, ‘,’ or ‘)’ before numeric constant
 #define X 36
           ^

Is that really a bug though? Any other name they pick for the argument can be mangled the same way.
Of course there are a few things that conspire to make this a problem: using such a generic name as "X" for the function argument, making it upper-case rather than lower-case, #defining something as generic as X and including system headers after #defining your own stuff (nominally bad practice, but it really shouldn't break so easily).

Anyway, problem solved and identified.

[syzygy]

So this is a bug in gcc's ia32intrin.h header file.

And if this is a mirror of the official gcc, which it seems to be, then it has recently been fixed:

Code: Select all

/* Write flags register */
extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__writeeflags (unsigned long long __X)
{
  __builtin_ia32_writeeflags_u64 (__X);
}

Compare with the gcc-6.3.0 version of the file:

Code: Select all

/* Write flags register */
extern __inline void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__writeeflags (unsigned long long X)
{
  __builtin_ia32_writeeflags_u64 (X);
}

[syzygy]

Is that really a bug though? Any other name they pick for the argument can be mangled the same way.

If they use __X instead of X (as they do now), then it goes wrong only if someone uses __X in his program. The C and C++ standards tell you not to use identifiers starting with a double underscore.

[Dann Corbit]

Is that really a bug though? Any other name they pick for the argument can be mangled the same way.

If they use __X instead of X (as they do now), then it goes wrong only if someone uses __X in his program. The C and C++ standards tell you not to use identifiers starting with a double underscore.

Ronald is right.

It should be safe to use X as a macro {though I would probably not be brave enough to do it without #undef}. Mingw GCC has invaded the implementation name space, IMO.

[hgm]

OK, thanks everyone. That clears up the mystery. It is bad to use identifiers that could be macros as formal parameters in function definitions in a header file, but I guess this can be excused by the directive that header files should be #included before any #defines. (Although this is a strange directive, as it is quite common to define macros through a compiler flag, like -DX, and then what??)

But that it does not give the error message on the line where it occurs is truly appalling.