On 2020-12-10, Karl Berry <invalid.nore...@gnu.org> wrote: > When a longstanding core existing feature (AC_PROG_CC) is changed in a > backward-incompatible way, a way to get the heretofore standard behavior > feels more like a bug fix than a feature request to me. For that matter, it > feels > like a new macro or option would have been more desirable than incompatibly > changing existing behavior.
I will note that -std=gnu11 (or, more recently, the substantially equivalent -std=gnu17) mode has been the default mode of GCC for the better part of a decade now. So with modern compilers I would not expect there to be much difference between old and new behaviour of AC_PROG_CC (you'll get a modern C flavour in either case). > Anyway. Semantics aside, I had the same reaction to the weird error about > "long int". I haven't had a chance to look into it yet, but my expectation > is that it is something specific to the TL autoconfigury. (I mean, presumably > int64_t should not be getting #define-d in the first place.) My guess would be that something is including either <stdint.h> or <inttypes.h> with these macros defined. Per the C spec, int64_t is a reserved identifier if either header is included so defining a macro with this name and including one of these headers gives undefined behaviour. It is really odd that such a problem would occur simply by changing the C standard version. Perhaps there is code conditional code on __STDC_VERSION__? For example, it could be that <stdint.h> is included only if __STDC_VERSION >= 199901, and because of the macro definition you get undefined results (translation failure in this case). Cheers, Nick
