Change https://golang.org/cl/121035 mentions this issue: cmd/cgo: handle GCC 8 change in errors about constant initializers

I have filed a bug in the gcc bugzilla, thinking it might be a gccgo issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86289

With gc, I could not reproduce it. However, I realized that it was just becauge gc does not invoke the brand-new gcc in my environment.

I have spent quite a bit time on this issue. I am willing to work on this. Regardless of that, here are what I have learnt.

Firstly, it looks like gc and gccgo with gcc 7.x was working. However, I am not sure if I could call it really working. The basic idea would be a 64 bit integer "neg" should be regarded as an integral value rather than a floating point value.

What had happened is the 64 bit integer was "not-int-const" AND "not-num-const." Here are the code that cgo gives to gcc to figure out "neg":

#line 1 "not-int-const"
void __cgo_f_1_3(void) { enum { __cgo_undefined__3 = (neg)*1 }; }

That is going to be a compile error as underlying enum type is likely 32 bits. However, look another piece of code that cgo generates:

const unsigned long long int neg = (const unsigned long long) -1;`
#line 1 "cgo-generated-wrapper"
#line 1 "cgo-dwarf-inference"
__typeof__(neg) *__cgo__0;
long long __cgodebug_ints[] = {
	0,
	1
};
double __cgodebug_floats[] = {
	neg,
	1
};

Here, the value for integrals seems long long. Thus, for the first place, I am wondering why neg falls into "not-int-const."

Moreover, the reason why neg is "not-num-const" is a bit tricky. C11 standard, as far as I know it, may say that a 'const' variable is not a constant which can be used to initialize a local 'static const' variable. However, it seems that the compiler is allowed to extend the range of constantness in the context.

For me, it seems like cgo relies on gcc regarding what gcc is allowed not to be consistent. Therefore, gcc 7.3 says "not-num-const" according to the C11 standard (even though the given flag might be gnu11) but gcc 8+ silently sort of optimized & compiles the same piece of code with the same -std option.

@kyoukim Thanks. As noted above, I've sent https://golang.org/cl/121035 to fix this issue. Want to take a look at that approach?

@ianlancetaylor Thank you so much! It makes perfect sense to me. It is blocking 64 bits integers to be regarded as a constant. I am relatively new to the code base, and still wondering why a 64 bits integer is treated differently from a 32 bits integer.

I'm not sure about 32-bits vs. 64-bits; what difference are you seeing?

Thanks for looking at the change, by the way.

I thought a 32 bits int would not fall into not-int-const. It was my bad. An int32 indeed does not look being differently treated. Thank you!