I noticed that compiling on Windows with -fno-ms-compatibility had the
side effect of defining GNUC, along with EXCEPTIONS, GXX_RTTI,
and a number of other macros for GCC compatibility. This is undesirable
and causes Chromium to do things like mix attribute__ and __declspec,
which doesn't work. We should have a positive language option to enable
GCC compatibility features so that we can experiment with
-fno-ms-compatibility on Windows. I propose that -fgnuc-version= can be
that option.
My issue aside, users have, for a long time, reported that GNUC
doesn't match their expectations in one way or another. We have
encouraged users to migrate code away from this macro, but new code
continues to be written assuming a GCC-only environment. There's really
nothing we can do to stop that. By adding this flag, we can allow them
to choose their own adventure with GNUC.
This overlaps a bit with the "GNUMode" language option from -std=gnu*.
I'm not sure how to reconcile them. The gnu language mode tends to
enable non-conforming behaviors that we'd rather not enable by default,
but these feature macros, like __EXCEPTIONS, are pretty benign.
Helps address PR42817
Pretty sure that should be GNUCMajor