* Re: GCC support for extensions from later standards [not found] <3A4C9996-750B-4E3F-8F30-E3DA4366C7B5@berlin.de> @ 2023-08-06 19:19 ` Jason Merrill 2023-08-06 19:43 ` Jonathan Wakely 2023-08-08 3:03 ` Nikolas Klauser 0 siblings, 2 replies; 10+ messages in thread From: Jason Merrill @ 2023-08-06 19:19 UTC (permalink / raw) To: Nikolas Klauser; +Cc: gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ [-- Attachment #1: Type: text/plain, Size: 1845 bytes --] On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de> wrote: > Hi everyone! > > I'm working on libc++ and we are currently discussing using language > extensions from later standards ( > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has > quite a lot of these kinds of conforming extensions, but doesn't document > them AFAICT. While discussing using these extensions, the question came up > what GCCs support policy for these is. Aaron was kind enough to answer > these questions for us on the Clang side. Since I couldn't find anything in > the documentation, I thought I'd ask here. > > So, here are my questions: > > Do you expect that these extensions will ever be removed for some reason? > If yes, what could those reasons be? > Potentially, if they don't actually work properly in earlier standard modes. I recently noticed that while we allow DMI and =default in C++03 mode with a pedwarn, combining them doesn't work. Some of the extensions are needed by libstdc++ and are therefore well tested; these are extremely unlikely to ever be removed. libstdc++ folks, is there a list of these? Would you be interested in documenting them? > That would be useful, yes. There is a patch in review to add __has_feature/__has_extension to G++, which would seem like a suitable context for this documentation. Aaron noted that we should ask the Clang folks before using them, so they > can evaluated whether the extension makes sense, since they might not be > aware of them, and some might be broken. So I'd be interested whether you > would also like us to ask whether you want to actually support these > extensions. > Sounds good. Jason ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-06 19:19 ` GCC support for extensions from later standards Jason Merrill @ 2023-08-06 19:43 ` Jonathan Wakely 2023-08-07 13:04 ` Jonathan Wakely 2023-08-08 3:03 ` Nikolas Klauser 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-08-06 19:43 UTC (permalink / raw) To: Jason Merrill Cc: Nikolas Klauser, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++ <libstdc++@gcc.gnu.org> wrote: > > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de> > wrote: > > > Hi everyone! > > > > I'm working on libc++ and we are currently discussing using language > > extensions from later standards ( > > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has > > quite a lot of these kinds of conforming extensions, but doesn't document > > them AFAICT. While discussing using these extensions, the question came up > > what GCCs support policy for these is. Aaron was kind enough to answer > > these questions for us on the Clang side. Since I couldn't find anything in > > the documentation, I thought I'd ask here. > > > > So, here are my questions: > > > > Do you expect that these extensions will ever be removed for some reason? > > If yes, what could those reasons be? > > > > Potentially, if they don't actually work properly in earlier standard > modes. I recently noticed that while we allow DMI and =default in C++03 > mode with a pedwarn, combining them doesn't work. > > Some of the extensions are needed by libstdc++ and are therefore well > tested; these are extremely unlikely to ever be removed. libstdc++ folks, > is there a list of these? We use variadic templates and long long in C++98. We use a DMI in __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use anything else, because we can't rely on it being available when using non-GCC compilers, or when compiling with -Wsystem-headers -pedantic. We don't use if-constexpr before C++17 for example. > > Would you be interested in documenting them? > > > > That would be useful, yes. > > There is a patch in review to add __has_feature/__has_extension to G++, > which would seem like a suitable context for this documentation. > > Aaron noted that we should ask the Clang folks before using them, so they > > can evaluated whether the extension makes sense, since they might not be > > aware of them, and some might be broken. So I'd be interested whether you > > would also like us to ask whether you want to actually support these > > extensions. > > > > Sounds good. > > Jason ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-06 19:43 ` Jonathan Wakely @ 2023-08-07 13:04 ` Jonathan Wakely 2023-08-08 8:55 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-08-07 13:04 UTC (permalink / raw) To: Jason Merrill Cc: Nikolas Klauser, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Sun, 6 Aug 2023 at 20:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++ > <libstdc++@gcc.gnu.org> wrote: > > > > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de> > > wrote: > > > > > Hi everyone! > > > > > > I'm working on libc++ and we are currently discussing using language > > > extensions from later standards ( > > > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > > > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has > > > quite a lot of these kinds of conforming extensions, but doesn't document > > > them AFAICT. While discussing using these extensions, the question came up > > > what GCCs support policy for these is. Aaron was kind enough to answer > > > these questions for us on the Clang side. Since I couldn't find anything in > > > the documentation, I thought I'd ask here. > > > > > > So, here are my questions: > > > > > > Do you expect that these extensions will ever be removed for some reason? > > > If yes, what could those reasons be? > > > > > > > Potentially, if they don't actually work properly in earlier standard > > modes. I recently noticed that while we allow DMI and =default in C++03 > > mode with a pedwarn, combining them doesn't work. > > > > Some of the extensions are needed by libstdc++ and are therefore well > > tested; these are extremely unlikely to ever be removed. libstdc++ folks, > > is there a list of these? > > We use variadic templates and long long in C++98. We use a DMI in > __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use > anything else, because we can't rely on it being available when using > non-GCC compilers, or when compiling with -Wsystem-headers -pedantic. > We don't use if-constexpr before C++17 for example. Oh, but we do use __decltype in a few places. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-07 13:04 ` Jonathan Wakely @ 2023-08-08 8:55 ` Jonathan Wakely 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Wakely @ 2023-08-08 8:55 UTC (permalink / raw) To: Jason Merrill Cc: Nikolas Klauser, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Mon, 7 Aug 2023 at 14:04, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Sun, 6 Aug 2023 at 20:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > > On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++ > > <libstdc++@gcc.gnu.org> wrote: > > > > > > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de> > > > wrote: > > > > > > > Hi everyone! > > > > > > > > I'm working on libc++ and we are currently discussing using language > > > > extensions from later standards ( > > > > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > > > > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has > > > > quite a lot of these kinds of conforming extensions, but doesn't document > > > > them AFAICT. While discussing using these extensions, the question came up > > > > what GCCs support policy for these is. Aaron was kind enough to answer > > > > these questions for us on the Clang side. Since I couldn't find anything in > > > > the documentation, I thought I'd ask here. > > > > > > > > So, here are my questions: > > > > > > > > Do you expect that these extensions will ever be removed for some reason? > > > > If yes, what could those reasons be? > > > > > > > > > > Potentially, if they don't actually work properly in earlier standard > > > modes. I recently noticed that while we allow DMI and =default in C++03 > > > mode with a pedwarn, combining them doesn't work. > > > > > > Some of the extensions are needed by libstdc++ and are therefore well > > > tested; these are extremely unlikely to ever be removed. libstdc++ folks, > > > is there a list of these? > > > > We use variadic templates and long long in C++98. We use a DMI in > > __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use > > anything else, because we can't rely on it being available when using > > non-GCC compilers, or when compiling with -Wsystem-headers -pedantic. > > We don't use if-constexpr before C++17 for example. > > Oh, but we do use __decltype in a few places. I thought of another one: we use __constinit in some C++11 code. But only inside the library, not in headers. I've recorded these at https://gcc.gnu.org/wiki/LibstdcxxHacking for now. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-06 19:19 ` GCC support for extensions from later standards Jason Merrill 2023-08-06 19:43 ` Jonathan Wakely @ 2023-08-08 3:03 ` Nikolas Klauser 2023-08-08 7:33 ` Jakub Jelinek 1 sibling, 1 reply; 10+ messages in thread From: Nikolas Klauser @ 2023-08-08 3:03 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ [-- Attachment #1: Type: text/plain, Size: 2453 bytes --] On 06.08.23 12:19, Jason Merrill wrote: > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser > <nikolasklauser@berlin.de> wrote: > > Hi everyone! > > I'm working on libc++ and we are currently discussing using > language extensions from later standards > (https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > By that I mean things like using `if constexpr` with `-std=c++11`. > GCC has quite a lot of these kinds of conforming extensions, but > doesn't document them AFAICT. While discussing using these > extensions, the question came up what GCCs support policy for > these is. Aaron was kind enough to answer these questions for us > on the Clang side. Since I couldn't find anything in the > documentation, I thought I'd ask here. > > So, here are my questions: > > Do you expect that these extensions will ever be removed for some > reason? If yes, what could those reasons be? > > > Potentially, if they don't actually work properly in earlier standard > modes. I recently noticed that while we allow DMI and =default in > C++03 mode with a pedwarn, combining them doesn't work. > > Some of the extensions are needed by libstdc++ and are therefore well > tested; these are extremely unlikely to ever be removed. libstdc++ > folks, is there a list of these? > > Would you be interested in documenting them? > > > That would be useful, yes. > > There is a patch in review to add __has_feature/__has_extension to > G++, which would seem like a suitable context for this documentation. > > Aaron noted that we should ask the Clang folks before using them, > so they can evaluated whether the extension makes sense, since > they might not be aware of them, and some might be broken. So I'd > be interested whether you would also like us to ask whether you > want to actually support these extensions. > > > Sounds good. > > Jason Thanks for the answers! There are a few really interesting extensions that I would like to use: - inline variables - variable templates - `if constexpr` - fold expressions - conditional explicit - static operator() (https://godbolt.org/z/5n9Y4h69n) Is anybody aware of any problems with these extensions? I'd be happy to provide a patch to add these extensions to the documentation, but I couldn't figure out how to build the documentation without building all of gcc. Nikolas ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-08 3:03 ` Nikolas Klauser @ 2023-08-08 7:33 ` Jakub Jelinek 2023-08-08 16:03 ` Nikolas Klauser 0 siblings, 1 reply; 10+ messages in thread From: Jakub Jelinek @ 2023-08-08 7:33 UTC (permalink / raw) To: Nikolas Klauser Cc: Jason Merrill, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote: > Thanks for the answers! > > There are a few really interesting extensions that I would like to use: > > - inline variables > - variable templates > - `if constexpr` > - fold expressions > - conditional explicit > - static operator() There are multiple problems. cat /tmp/test.h #pragma GCC system_header inline int a = 1; template <int N> int b = N; void foo () { if constexpr (true) {} } template <typename...A> bool bar (A... a) { return (... + a); } struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; void baz () { auto a = [](int x, int y) static { return x + y; }; } cat /tmp/test.C #include "/tmp/test.h" g++ -S -std=c++11 -o /tmp/test.{s,C} The above with GCC 13 doesn't give any warnings, but does with -Wsystem-headers: In file included from /tmp/test.C:1: /tmp/test.h:2:1: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 2 | inline int a = 1; | ^~~~~~ /tmp/test.h:3:22: warning: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions] 3 | template <int N> int b = N; | ^ /tmp/test.h: In function ‘void foo()’: /tmp/test.h:4:18: warning: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 4 | void foo () { if constexpr (true) {} } | ^~~~~~~~~ /tmp/test.h: In function ‘bool bar(A ...)’: /tmp/test.h:5:59: warning: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 5 | template <typename...A> bool bar (A... a) { return (... + a); } | ^ /tmp/test.h: At global scope: /tmp/test.h:6:29: warning: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions] 6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; | ^~~~~~~~ /tmp/test.h:7:34: warning: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] 7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; | ^~~~~~~~ /tmp/test.h: In function ‘void baz()’: /tmp/test.h:8:41: warning: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] 8 | void baz () { auto a = [](int x, int y) static { return x + y; }; } | ^~~~~~ and with -pedantic-errors -Wsystem-headers even errors: ./xg++ -B ./ -S /tmp/test.C -std=c++11 -pedantic-errors -Wsystem-headers In file included from /tmp/test.C:1: /tmp/test.h:2:1: error: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 2 | inline int a = 1; | ^~~~~~ /tmp/test.h:3:22: error: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions] 3 | template <int N> int b = N; | ^ /tmp/test.h: In function ‘void foo()’: /tmp/test.h:4:18: error: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 4 | void foo () { if constexpr (true) {} } | ^~~~~~~~~ /tmp/test.h: In function ‘bool bar(A ...)’: /tmp/test.h:5:59: error: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] 5 | template <typename...A> bool bar (A... a) { return (... + a); } | ^ /tmp/test.h: At global scope: /tmp/test.h:6:29: error: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions] 6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; | ^~~~~~~~ /tmp/test.h:7:34: error: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] 7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; | ^~~~~~~~ /tmp/test.h: In function ‘void baz()’: /tmp/test.h:8:41: error: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] 8 | void baz () { auto a = [](int x, int y) static { return x + y; }; } | ^~~~~~ (so one would need to figure out if __extension__ somewhere around would be able to quite that up or not, or #pragma GCC diagnostic ignored "-Wc++14-extensions" (and 17, 20 and 23). Also, static operator () is only in GCC 13 and later, earlier versions will error on that. The -Wc++*-extensions separate warnings are only in GCC 12 and later, before that it will be harder to quiet the warnings selectively. Similarly, conditional explicit is only GCC 9 and later, if constexpr and inline vars GCC 7 and later, fold expressions GCC 6 and later, and variable templates GCC 5 and later. And in C++98 some of these don't work at all, if constexpr and static lambdas (because constexpr isn't a keyword and lambdas aren't supported altogether). Jakub ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-08 7:33 ` Jakub Jelinek @ 2023-08-08 16:03 ` Nikolas Klauser 2023-08-08 16:07 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: Nikolas Klauser @ 2023-08-08 16:03 UTC (permalink / raw) To: Jakub Jelinek Cc: Jason Merrill, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think. Nikolas > On Aug 8, 2023, at 12:33 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote: >> Thanks for the answers! >> >> There are a few really interesting extensions that I would like to use: >> >> - inline variables >> - variable templates >> - `if constexpr` >> - fold expressions >> - conditional explicit >> - static operator() > > There are multiple problems. > > cat /tmp/test.h > #pragma GCC system_header > inline int a = 1; > template <int N> int b = N; > void foo () { if constexpr (true) {} } > template <typename...A> bool bar (A... a) { return (... + a); } > struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; > struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; > void baz () { auto a = [](int x, int y) static { return x + y; }; } > cat /tmp/test.C > #include "/tmp/test.h" > g++ -S -std=c++11 -o /tmp/test.{s,C} > > The above with GCC 13 doesn't give any warnings, but does with -Wsystem-headers: > In file included from /tmp/test.C:1: > /tmp/test.h:2:1: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 2 | inline int a = 1; > | ^~~~~~ > /tmp/test.h:3:22: warning: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions] > 3 | template <int N> int b = N; > | ^ > /tmp/test.h: In function ‘void foo()’: > /tmp/test.h:4:18: warning: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 4 | void foo () { if constexpr (true) {} } > | ^~~~~~~~~ > /tmp/test.h: In function ‘bool bar(A ...)’: > /tmp/test.h:5:59: warning: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 5 | template <typename...A> bool bar (A... a) { return (... + a); } > | ^ > /tmp/test.h: At global scope: > /tmp/test.h:6:29: warning: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions] > 6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; > | ^~~~~~~~ > /tmp/test.h:7:34: warning: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] > 7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; > | ^~~~~~~~ > /tmp/test.h: In function ‘void baz()’: > /tmp/test.h:8:41: warning: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] > 8 | void baz () { auto a = [](int x, int y) static { return x + y; }; } > | ^~~~~~ > and with -pedantic-errors -Wsystem-headers even errors: > ./xg++ -B ./ -S /tmp/test.C -std=c++11 -pedantic-errors -Wsystem-headers > In file included from /tmp/test.C:1: > /tmp/test.h:2:1: error: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 2 | inline int a = 1; > | ^~~~~~ > /tmp/test.h:3:22: error: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions] > 3 | template <int N> int b = N; > | ^ > /tmp/test.h: In function ‘void foo()’: > /tmp/test.h:4:18: error: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 4 | void foo () { if constexpr (true) {} } > | ^~~~~~~~~ > /tmp/test.h: In function ‘bool bar(A ...)’: > /tmp/test.h:5:59: error: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions] > 5 | template <typename...A> bool bar (A... a) { return (... + a); } > | ^ > /tmp/test.h: At global scope: > /tmp/test.h:6:29: error: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions] > 6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} }; > | ^~~~~~~~ > /tmp/test.h:7:34: error: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] > 7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; }; > | ^~~~~~~~ > /tmp/test.h: In function ‘void baz()’: > /tmp/test.h:8:41: error: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions] > 8 | void baz () { auto a = [](int x, int y) static { return x + y; }; } > | ^~~~~~ > (so one would need to figure out if __extension__ somewhere around would be > able to quite that up or not, or > #pragma GCC diagnostic ignored "-Wc++14-extensions" (and 17, 20 and 23). > > Also, static operator () is only in GCC 13 and later, earlier versions will > error on that. The -Wc++*-extensions separate warnings are only in GCC 12 > and later, before that it will be harder to quiet the warnings selectively. > Similarly, conditional explicit is only GCC 9 and later, if constexpr and > inline vars GCC 7 and later, fold expressions GCC 6 and later, and variable > templates GCC 5 and later. And in C++98 some of these don't work at all, > if constexpr and static lambdas (because constexpr isn't a keyword > and lambdas aren't supported altogether). > > Jakub > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-08 16:03 ` Nikolas Klauser @ 2023-08-08 16:07 ` Jonathan Wakely 2023-08-08 16:10 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-08-08 16:07 UTC (permalink / raw) To: Nikolas Klauser Cc: Jakub Jelinek, Jason Merrill, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote: > > Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think. Can you use it in C++11 though? The body of a constexpr function must be a single return statement, so if-constexpr isn't allowed. You can use it in C++14 though. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-08 16:07 ` Jonathan Wakely @ 2023-08-08 16:10 ` Jonathan Wakely 2023-08-08 16:33 ` Nikolas Klauser 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-08-08 16:10 UTC (permalink / raw) To: Nikolas Klauser Cc: Jakub Jelinek, Jason Merrill, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ On Tue, 8 Aug 2023 at 17:07, Jonathan Wakely wrote: > > On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote: > > > > Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think. > > Can you use it in C++11 though? The body of a constexpr function must > be a single return statement, so if-constexpr isn't allowed. Clang allows it with multiple warnings: ifc.cc:3:6: warning: constexpr if is a C++17 extension [-Wc++17-extensions] if constexpr (sizeof(i) >= 4) ^ ifc.cc:3:3: warning: use of this statement in a constexpr function is a C++14 extension [-Wc++14-extensions] if constexpr (sizeof(i) >= 4) ^ ifc.cc:8:5: warning: multiple return statements in constexpr function is a C++14 extension [-Wc++14-extensions] return 0; ^ ifc.cc:5:5: note: previous return statement is here return i << 3; ^ But GCC gives a warning for if-constexpr and then an error for the invalid function body: ifc.cc: In function 'constexpr int f(int)': ifc.cc:3:6: warning: 'if constexpr' only available with '-std=c++17' or '-std=gnu++17' [-Wc++17-extensions] 3 | if constexpr (sizeof(i) >= 4) | ^~~~~~~~~ ifc.cc:9:1: error: body of 'constexpr' function 'constexpr int f(int)' not a return-statement 9 | } | ^ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GCC support for extensions from later standards 2023-08-08 16:10 ` Jonathan Wakely @ 2023-08-08 16:33 ` Nikolas Klauser 0 siblings, 0 replies; 10+ messages in thread From: Nikolas Klauser @ 2023-08-08 16:33 UTC (permalink / raw) To: Jonathan Wakely Cc: Jakub Jelinek, Jason Merrill, gcc, Louis Dionne, Mark de Wever, aaron, libstdc++ Yes, Clang allows it. Most importantly though: you don’t have to be in a constexpr function for `if constexpr` to be useful. e.g. the Algorithms aren’t constexpr until C++20, but a lot of them have overloads for improving the algorithm based on the iterator category. Having `if constexpr` there instead of enable_ifs seems like quite a nice improvement to me. The main problem is probably that libc++ back-ports a lot of the C++11 stuff to C++03, so in these cases `if constexpr` won’t help. > On Aug 8, 2023, at 9:10 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Tue, 8 Aug 2023 at 17:07, Jonathan Wakely wrote: >> >> On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote: >>> >>> Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think. >> >> Can you use it in C++11 though? The body of a constexpr function must >> be a single return statement, so if-constexpr isn't allowed. > > Clang allows it with multiple warnings: > > ifc.cc:3:6: warning: constexpr if is a C++17 extension [-Wc++17-extensions] > if constexpr (sizeof(i) >= 4) > ^ > ifc.cc:3:3: warning: use of this statement in a constexpr function is > a C++14 extension [-Wc++14-extensions] > if constexpr (sizeof(i) >= 4) > ^ > ifc.cc:8:5: warning: multiple return statements in constexpr function > is a C++14 extension [-Wc++14-extensions] > return 0; > ^ > ifc.cc:5:5: note: previous return statement is here > return i << 3; > ^ > > But GCC gives a warning for if-constexpr and then an error for the > invalid function body: > > ifc.cc: In function 'constexpr int f(int)': > ifc.cc:3:6: warning: 'if constexpr' only available with '-std=c++17' > or '-std=gnu++17' [-Wc++17-extensions] > 3 | if constexpr (sizeof(i) >= 4) > | ^~~~~~~~~ > ifc.cc:9:1: error: body of 'constexpr' function 'constexpr int f(int)' > not a return-statement > 9 | } > | ^ ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-08-08 16:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3A4C9996-750B-4E3F-8F30-E3DA4366C7B5@berlin.de> 2023-08-06 19:19 ` GCC support for extensions from later standards Jason Merrill 2023-08-06 19:43 ` Jonathan Wakely 2023-08-07 13:04 ` Jonathan Wakely 2023-08-08 8:55 ` Jonathan Wakely 2023-08-08 3:03 ` Nikolas Klauser 2023-08-08 7:33 ` Jakub Jelinek 2023-08-08 16:03 ` Nikolas Klauser 2023-08-08 16:07 ` Jonathan Wakely 2023-08-08 16:10 ` Jonathan Wakely 2023-08-08 16:33 ` Nikolas Klauser
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).