Re: r374449 - Add -fgnuc-version= to control __GNUC__ and other GCC macros
I think _MSC_VER is controlled by -ms-compatiblity-version based on what I found when I was missing with the bmiintrin.h header yesterday. ~Craig On Fri, Oct 11, 2019 at 3:05 PM Reid Kleckner via cfe-commits < cfe-commits@lists.llvm.org> wrote: > I think overloading zero to mean "don't define __GNUC__" was my way of > side stepping the need to think of a good name for this. I don't like > -fno-gnu-extensions as a name because clang still supports GCC asm, > __attribute__, statement expressions, computed goto, etc, and that flag > name seems like it should turn all of them off. I could imagine > `-f[no-]gcc-compatility` as something that would control our "pretend to be > GCC" behavior. > > I think the _MSC_VER macro is currently controlled -fms-extensions in > clang, but maybe it should be under -fms-compatibility, to imagine a > glorious hypothetical future where we don't have this "user agent" problem. > > On Fri, Oct 11, 2019 at 10:04 AM Nico Weber wrote: > >> It's cool we finally have a flag for this, but overloading its meaning >> with the =0 behavior seems a bit strange to me. Maybe we should have a >> separate -fno-gnu-extensions for that part instead? >> >> On Thu, Oct 10, 2019 at 5:02 PM Reid Kleckner via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> Author: rnk >>> Date: Thu Oct 10 14:04:25 2019 >>> New Revision: 374449 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=374449=rev >>> Log: >>> Add -fgnuc-version= to control __GNUC__ and other GCC macros >>> >>> I noticed that compiling on Windows with -fno-ms-compatibility had the >>> side effect of defining __GNUC__, along with __GNUG__, __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. This change adds -fgnuc-version= to 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*. >>> The gnu language mode tends to enable non-conforming behaviors that we'd >>> rather not enable by default, but the we want to set things like >>> __GXX_RTTI__ by default, so I've kept these separate. >>> >>> Helps address PR42817 >>> >>> Reviewed By: hans, nickdesaulniers, MaskRay >>> >>> Differential Revision: https://reviews.llvm.org/D68055 >>> >>> Added: >>> cfe/trunk/test/Driver/fgnuc-version.c >>> Modified: >>> cfe/trunk/docs/ReleaseNotes.rst >>> cfe/trunk/docs/UsersManual.rst >>> cfe/trunk/include/clang/Basic/LangOptions.def >>> cfe/trunk/include/clang/Driver/Options.td >>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp >>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp >>> cfe/trunk/lib/Frontend/InitPreprocessor.cpp >>> cfe/trunk/test/Driver/rewrite-legacy-objc.m >>> cfe/trunk/test/Driver/rewrite-objc.m >>> cfe/trunk/test/Frontend/gnu-inline.c >>> cfe/trunk/test/Headers/stdbool.cpp >>> cfe/trunk/test/Preprocessor/init.c >>> cfe/trunk/test/Sema/atomic-ops.c >>> >>> Modified: cfe/trunk/docs/ReleaseNotes.rst >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=374449=374448=374449=diff >>> >>> == >>> --- cfe/trunk/docs/ReleaseNotes.rst (original) >>> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Oct 10 14:04:25 2019 >>> @@ -80,7 +80,10 @@ Non-comprehensive list of changes in thi >>> New Compiler Flags >>> -- >>> >>> -- ... >>> +- The -fgnuc-version= flag now controls the value of ``__GNUC__`` and >>> related >>> + macros. This flag does not enable or disable any GCC extensions >>> implemented in >>> + Clang. Setting the version to zero causes Clang to leave ``__GNUC__`` >>> and >>> + other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. >>> >>> Deprecated Compiler Flags >>> - >>> >>> Modified: cfe/trunk/docs/UsersManual.rst >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=374449=374448=374449=diff >>> >>> == >>> --- cfe/trunk/docs/UsersManual.rst (original) >>> +++ cfe/trunk/docs/UsersManual.rst Thu Oct 10 14:04:25 2019 >>> @@ -701,6 +701,13 @@ Other Options >>> - >>> Clang options that don't fit neatly into other categories. >>> >>> +.. option:: -fgnuc-version= >>> + >>> +
Re: r374449 - Add -fgnuc-version= to control __GNUC__ and other GCC macros
I think overloading zero to mean "don't define __GNUC__" was my way of side stepping the need to think of a good name for this. I don't like -fno-gnu-extensions as a name because clang still supports GCC asm, __attribute__, statement expressions, computed goto, etc, and that flag name seems like it should turn all of them off. I could imagine `-f[no-]gcc-compatility` as something that would control our "pretend to be GCC" behavior. I think the _MSC_VER macro is currently controlled -fms-extensions in clang, but maybe it should be under -fms-compatibility, to imagine a glorious hypothetical future where we don't have this "user agent" problem. On Fri, Oct 11, 2019 at 10:04 AM Nico Weber wrote: > It's cool we finally have a flag for this, but overloading its meaning > with the =0 behavior seems a bit strange to me. Maybe we should have a > separate -fno-gnu-extensions for that part instead? > > On Thu, Oct 10, 2019 at 5:02 PM Reid Kleckner via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: rnk >> Date: Thu Oct 10 14:04:25 2019 >> New Revision: 374449 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=374449=rev >> Log: >> Add -fgnuc-version= to control __GNUC__ and other GCC macros >> >> I noticed that compiling on Windows with -fno-ms-compatibility had the >> side effect of defining __GNUC__, along with __GNUG__, __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. This change adds -fgnuc-version= to 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*. >> The gnu language mode tends to enable non-conforming behaviors that we'd >> rather not enable by default, but the we want to set things like >> __GXX_RTTI__ by default, so I've kept these separate. >> >> Helps address PR42817 >> >> Reviewed By: hans, nickdesaulniers, MaskRay >> >> Differential Revision: https://reviews.llvm.org/D68055 >> >> Added: >> cfe/trunk/test/Driver/fgnuc-version.c >> Modified: >> cfe/trunk/docs/ReleaseNotes.rst >> cfe/trunk/docs/UsersManual.rst >> cfe/trunk/include/clang/Basic/LangOptions.def >> cfe/trunk/include/clang/Driver/Options.td >> cfe/trunk/lib/Driver/ToolChains/Clang.cpp >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp >> cfe/trunk/lib/Frontend/InitPreprocessor.cpp >> cfe/trunk/test/Driver/rewrite-legacy-objc.m >> cfe/trunk/test/Driver/rewrite-objc.m >> cfe/trunk/test/Frontend/gnu-inline.c >> cfe/trunk/test/Headers/stdbool.cpp >> cfe/trunk/test/Preprocessor/init.c >> cfe/trunk/test/Sema/atomic-ops.c >> >> Modified: cfe/trunk/docs/ReleaseNotes.rst >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=374449=374448=374449=diff >> >> == >> --- cfe/trunk/docs/ReleaseNotes.rst (original) >> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Oct 10 14:04:25 2019 >> @@ -80,7 +80,10 @@ Non-comprehensive list of changes in thi >> New Compiler Flags >> -- >> >> -- ... >> +- The -fgnuc-version= flag now controls the value of ``__GNUC__`` and >> related >> + macros. This flag does not enable or disable any GCC extensions >> implemented in >> + Clang. Setting the version to zero causes Clang to leave ``__GNUC__`` >> and >> + other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. >> >> Deprecated Compiler Flags >> - >> >> Modified: cfe/trunk/docs/UsersManual.rst >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=374449=374448=374449=diff >> >> == >> --- cfe/trunk/docs/UsersManual.rst (original) >> +++ cfe/trunk/docs/UsersManual.rst Thu Oct 10 14:04:25 2019 >> @@ -701,6 +701,13 @@ Other Options >> - >> Clang options that don't fit neatly into other categories. >> >> +.. option:: -fgnuc-version= >> + >> + This flag controls the value of ``__GNUC__`` and related macros. This >> flag >> + does not enable or disable any GCC extensions implemented in Clang. >> Setting >> + the version to zero causes Clang to leave ``__GNUC__`` and other >> + GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. >> + >> .. option:: -MV >> >>When emitting a dependency file, use
Re: r374449 - Add -fgnuc-version= to control __GNUC__ and other GCC macros
It's cool we finally have a flag for this, but overloading its meaning with the =0 behavior seems a bit strange to me. Maybe we should have a separate -fno-gnu-extensions for that part instead? On Thu, Oct 10, 2019 at 5:02 PM Reid Kleckner via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: rnk > Date: Thu Oct 10 14:04:25 2019 > New Revision: 374449 > > URL: http://llvm.org/viewvc/llvm-project?rev=374449=rev > Log: > Add -fgnuc-version= to control __GNUC__ and other GCC macros > > I noticed that compiling on Windows with -fno-ms-compatibility had the > side effect of defining __GNUC__, along with __GNUG__, __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. This change adds -fgnuc-version= to 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*. > The gnu language mode tends to enable non-conforming behaviors that we'd > rather not enable by default, but the we want to set things like > __GXX_RTTI__ by default, so I've kept these separate. > > Helps address PR42817 > > Reviewed By: hans, nickdesaulniers, MaskRay > > Differential Revision: https://reviews.llvm.org/D68055 > > Added: > cfe/trunk/test/Driver/fgnuc-version.c > Modified: > cfe/trunk/docs/ReleaseNotes.rst > cfe/trunk/docs/UsersManual.rst > cfe/trunk/include/clang/Basic/LangOptions.def > cfe/trunk/include/clang/Driver/Options.td > cfe/trunk/lib/Driver/ToolChains/Clang.cpp > cfe/trunk/lib/Frontend/CompilerInvocation.cpp > cfe/trunk/lib/Frontend/InitPreprocessor.cpp > cfe/trunk/test/Driver/rewrite-legacy-objc.m > cfe/trunk/test/Driver/rewrite-objc.m > cfe/trunk/test/Frontend/gnu-inline.c > cfe/trunk/test/Headers/stdbool.cpp > cfe/trunk/test/Preprocessor/init.c > cfe/trunk/test/Sema/atomic-ops.c > > Modified: cfe/trunk/docs/ReleaseNotes.rst > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=374449=374448=374449=diff > > == > --- cfe/trunk/docs/ReleaseNotes.rst (original) > +++ cfe/trunk/docs/ReleaseNotes.rst Thu Oct 10 14:04:25 2019 > @@ -80,7 +80,10 @@ Non-comprehensive list of changes in thi > New Compiler Flags > -- > > -- ... > +- The -fgnuc-version= flag now controls the value of ``__GNUC__`` and > related > + macros. This flag does not enable or disable any GCC extensions > implemented in > + Clang. Setting the version to zero causes Clang to leave ``__GNUC__`` > and > + other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. > > Deprecated Compiler Flags > - > > Modified: cfe/trunk/docs/UsersManual.rst > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=374449=374448=374449=diff > > == > --- cfe/trunk/docs/UsersManual.rst (original) > +++ cfe/trunk/docs/UsersManual.rst Thu Oct 10 14:04:25 2019 > @@ -701,6 +701,13 @@ Other Options > - > Clang options that don't fit neatly into other categories. > > +.. option:: -fgnuc-version= > + > + This flag controls the value of ``__GNUC__`` and related macros. This > flag > + does not enable or disable any GCC extensions implemented in Clang. > Setting > + the version to zero causes Clang to leave ``__GNUC__`` and other > + GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined. > + > .. option:: -MV > >When emitting a dependency file, use formatting conventions appropriate > > Modified: cfe/trunk/include/clang/Basic/LangOptions.def > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=374449=374448=374449=diff > > == > --- cfe/trunk/include/clang/Basic/LangOptions.def (original) > +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Oct 10 14:04:25 2019 > @@ -111,6 +111,7 @@ BENIGN_LANGOPT(DollarIdents , 1, 1, "' > BENIGN_LANGOPT(AsmPreprocessor, 1, 0, "preprocessor in asm mode") > LANGOPT(GNUMode , 1, 1, "GNU extensions") > LANGOPT(GNUKeywords , 1, 1, "GNU keywords") > +VALUE_LANGOPT(GNUCVersion , 32, 0, "GNU C compatibility version") > BENIGN_LANGOPT(ImplicitInt, 1, !C99 && !CPlusPlus, "C89 implicit
