* [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
@ 2024-02-02 10:27 Alex Coplan
2024-02-02 14:34 ` Marek Polacek
0 siblings, 1 reply; 7+ messages in thread
From: Alex Coplan @ 2024-02-02 10:27 UTC (permalink / raw)
To: gcc-patches; +Cc: Jason Merrill, Nathan Sidwell
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
Thanks,
Alex
-- >8 --
When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
builtins.
However, as the PR shows, GCC doesn't implement the full list of
builtins in the clang documentation. After enumerating the builtins,
the clang docs [1] say:
> Support for constant expression evaluation for the above builtins can
> be detected with __has_feature(cxx_constexpr_string_builtins).
and a strict reading of this would suggest we can't really support
constexpr evaluation of a builtin if we don't implement the builtin in
the first place.
So the conservatively correct thing to do seems to be to stop
advertising the feature altogether to avoid failing to build code which
assumes the presence of this feature implies the presence of all the
builtins listed in the clang documentation.
[1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
gcc/cp/ChangeLog:
PR c++/113658
* cp-objcp-common.cc (cp_feature_table): Remove entry for
cxx_constexpr_string_builtins.
gcc/testsuite/ChangeLog:
PR c++/113658
* g++.dg/ext/pr113658.C: New test.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1059 bytes --]
diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
index f06edf04ef0..85dde0459fa 100644
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
@@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
{ "cxx_alignof", cxx11 },
{ "cxx_attributes", cxx11 },
{ "cxx_constexpr", cxx11 },
- { "cxx_constexpr_string_builtins", cxx11 },
{ "cxx_decltype", cxx11 },
{ "cxx_decltype_incomplete_return_types", cxx11 },
{ "cxx_default_function_template_args", cxx11 },
diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C b/gcc/testsuite/g++.dg/ext/pr113658.C
new file mode 100644
index 00000000000..f4a34888f28
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/pr113658.C
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "" }
+
+// PR113658: we shouldn't declare support for cxx_constexpr_string_builtins as
+// GCC is missing some of the builtins that clang implements.
+
+#if __has_feature (cxx_constexpr_string_builtins)
+#error
+#endif
+
+#if __has_extension (cxx_constexpr_string_builtins)
+#error
+#endif
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 10:27 [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658] Alex Coplan
@ 2024-02-02 14:34 ` Marek Polacek
2024-02-02 15:45 ` Alex Coplan
0 siblings, 1 reply; 7+ messages in thread
From: Marek Polacek @ 2024-02-02 14:34 UTC (permalink / raw)
To: Alex Coplan; +Cc: gcc-patches, Jason Merrill, Nathan Sidwell
On Fri, Feb 02, 2024 at 10:27:23AM +0000, Alex Coplan wrote:
> Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
>
> Thanks,
> Alex
>
> -- >8 --
>
> When __has_feature was introduced for GCC 14, I included the feature
> cxx_constexpr_string_builtins, since of the relevant string builtins
> that GCC implements, it seems to support constexpr evaluation of those
> builtins.
>
> However, as the PR shows, GCC doesn't implement the full list of
> builtins in the clang documentation. After enumerating the builtins,
> the clang docs [1] say:
>
> > Support for constant expression evaluation for the above builtins can
> > be detected with __has_feature(cxx_constexpr_string_builtins).
>
> and a strict reading of this would suggest we can't really support
> constexpr evaluation of a builtin if we don't implement the builtin in
> the first place.
>
> So the conservatively correct thing to do seems to be to stop
> advertising the feature altogether to avoid failing to build code which
> assumes the presence of this feature implies the presence of all the
> builtins listed in the clang documentation.
>
> [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
>
> gcc/cp/ChangeLog:
>
> PR c++/113658
> * cp-objcp-common.cc (cp_feature_table): Remove entry for
> cxx_constexpr_string_builtins.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/113658
> * g++.dg/ext/pr113658.C: New test.
> diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> index f06edf04ef0..85dde0459fa 100644
> --- a/gcc/cp/cp-objcp-common.cc
> +++ b/gcc/cp/cp-objcp-common.cc
> @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
> { "cxx_alignof", cxx11 },
> { "cxx_attributes", cxx11 },
> { "cxx_constexpr", cxx11 },
> - { "cxx_constexpr_string_builtins", cxx11 },
> { "cxx_decltype", cxx11 },
> { "cxx_decltype_incomplete_return_types", cxx11 },
> { "cxx_default_function_template_args", cxx11 },
> diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C b/gcc/testsuite/g++.dg/ext/pr113658.C
> new file mode 100644
> index 00000000000..f4a34888f28
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
Might be better to name this has-feature2.C
> @@ -0,0 +1,13 @@
Please include
// PR c++/113658
> +// { dg-do compile }
> +// { dg-options "" }
Why dg-options ""? It doesn't seem to have any purpose here.
> +// PR113658: we shouldn't declare support for cxx_constexpr_string_builtins as
> +// GCC is missing some of the builtins that clang implements.
> +
> +#if __has_feature (cxx_constexpr_string_builtins)
> +#error
> +#endif
> +
> +#if __has_extension (cxx_constexpr_string_builtins)
> +#error
> +#endif
Marek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 14:34 ` Marek Polacek
@ 2024-02-02 15:45 ` Alex Coplan
2024-02-02 16:27 ` Marek Polacek
2024-02-09 17:55 ` Jason Merrill
0 siblings, 2 replies; 7+ messages in thread
From: Alex Coplan @ 2024-02-02 15:45 UTC (permalink / raw)
To: Marek Polacek; +Cc: gcc-patches, Jason Merrill, Nathan Sidwell
On 02/02/2024 09:34, Marek Polacek wrote:
> On Fri, Feb 02, 2024 at 10:27:23AM +0000, Alex Coplan wrote:
> > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> >
> > Thanks,
> > Alex
> >
> > -- >8 --
> >
> > When __has_feature was introduced for GCC 14, I included the feature
> > cxx_constexpr_string_builtins, since of the relevant string builtins
> > that GCC implements, it seems to support constexpr evaluation of those
> > builtins.
> >
> > However, as the PR shows, GCC doesn't implement the full list of
> > builtins in the clang documentation. After enumerating the builtins,
> > the clang docs [1] say:
> >
> > > Support for constant expression evaluation for the above builtins can
> > > be detected with __has_feature(cxx_constexpr_string_builtins).
> >
> > and a strict reading of this would suggest we can't really support
> > constexpr evaluation of a builtin if we don't implement the builtin in
> > the first place.
> >
> > So the conservatively correct thing to do seems to be to stop
> > advertising the feature altogether to avoid failing to build code which
> > assumes the presence of this feature implies the presence of all the
> > builtins listed in the clang documentation.
> >
> > [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
> >
> > gcc/cp/ChangeLog:
> >
> > PR c++/113658
> > * cp-objcp-common.cc (cp_feature_table): Remove entry for
> > cxx_constexpr_string_builtins.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR c++/113658
> > * g++.dg/ext/pr113658.C: New test.
>
> > diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> > index f06edf04ef0..85dde0459fa 100644
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
> > @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
> > { "cxx_alignof", cxx11 },
> > { "cxx_attributes", cxx11 },
> > { "cxx_constexpr", cxx11 },
> > - { "cxx_constexpr_string_builtins", cxx11 },
> > { "cxx_decltype", cxx11 },
> > { "cxx_decltype_incomplete_return_types", cxx11 },
> > { "cxx_default_function_template_args", cxx11 },
> > diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C b/gcc/testsuite/g++.dg/ext/pr113658.C
> > new file mode 100644
> > index 00000000000..f4a34888f28
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
>
> Might be better to name this has-feature2.C
>
> > @@ -0,0 +1,13 @@
>
> Please include
> // PR c++/113658
Can do.
>
> > +// { dg-do compile }
> > +// { dg-options "" }
>
> Why dg-options ""? It doesn't seem to have any purpose here.
That is to disable -pedantic-errors which IIRC is added by default in
the testsuite options.
With -pedantic-errors we would have __has_extension behaving like
__has_feature, and I wanted to check in the test that this doesn't get
reported as a feature or extension.
Incidentally it also means we don't have to provide a dummy declaration,
with -pedantic-errors we would get a warning about an empty TU which
would make the test fail.
Thanks,
Alex
>
> > +// PR113658: we shouldn't declare support for cxx_constexpr_string_builtins as
> > +// GCC is missing some of the builtins that clang implements.
> > +
> > +#if __has_feature (cxx_constexpr_string_builtins)
> > +#error
> > +#endif
> > +
> > +#if __has_extension (cxx_constexpr_string_builtins)
> > +#error
> > +#endif
>
>
> Marek
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 15:45 ` Alex Coplan
@ 2024-02-02 16:27 ` Marek Polacek
2024-02-02 16:32 ` Jakub Jelinek
2024-02-09 17:55 ` Jason Merrill
1 sibling, 1 reply; 7+ messages in thread
From: Marek Polacek @ 2024-02-02 16:27 UTC (permalink / raw)
To: Alex Coplan; +Cc: gcc-patches, Jason Merrill, Nathan Sidwell
On Fri, Feb 02, 2024 at 03:45:48PM +0000, Alex Coplan wrote:
> On 02/02/2024 09:34, Marek Polacek wrote:
> > On Fri, Feb 02, 2024 at 10:27:23AM +0000, Alex Coplan wrote:
> > > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> > >
> > > Thanks,
> > > Alex
> > >
> > > -- >8 --
> > >
> > > When __has_feature was introduced for GCC 14, I included the feature
> > > cxx_constexpr_string_builtins, since of the relevant string builtins
> > > that GCC implements, it seems to support constexpr evaluation of those
> > > builtins.
> > >
> > > However, as the PR shows, GCC doesn't implement the full list of
> > > builtins in the clang documentation. After enumerating the builtins,
> > > the clang docs [1] say:
> > >
> > > > Support for constant expression evaluation for the above builtins can
> > > > be detected with __has_feature(cxx_constexpr_string_builtins).
> > >
> > > and a strict reading of this would suggest we can't really support
> > > constexpr evaluation of a builtin if we don't implement the builtin in
> > > the first place.
> > >
> > > So the conservatively correct thing to do seems to be to stop
> > > advertising the feature altogether to avoid failing to build code which
> > > assumes the presence of this feature implies the presence of all the
> > > builtins listed in the clang documentation.
> > >
> > > [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
> > >
> > > gcc/cp/ChangeLog:
> > >
> > > PR c++/113658
> > > * cp-objcp-common.cc (cp_feature_table): Remove entry for
> > > cxx_constexpr_string_builtins.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR c++/113658
> > > * g++.dg/ext/pr113658.C: New test.
> >
> > > diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> > > index f06edf04ef0..85dde0459fa 100644
> > > --- a/gcc/cp/cp-objcp-common.cc
> > > +++ b/gcc/cp/cp-objcp-common.cc
> > > @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
> > > { "cxx_alignof", cxx11 },
> > > { "cxx_attributes", cxx11 },
> > > { "cxx_constexpr", cxx11 },
> > > - { "cxx_constexpr_string_builtins", cxx11 },
> > > { "cxx_decltype", cxx11 },
> > > { "cxx_decltype_incomplete_return_types", cxx11 },
> > > { "cxx_default_function_template_args", cxx11 },
> > > diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C b/gcc/testsuite/g++.dg/ext/pr113658.C
> > > new file mode 100644
> > > index 00000000000..f4a34888f28
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
> >
> > Might be better to name this has-feature2.C
> >
> > > @@ -0,0 +1,13 @@
> >
> > Please include
> > // PR c++/113658
>
> Can do.
>
> >
> > > +// { dg-do compile }
> > > +// { dg-options "" }
> >
> > Why dg-options ""? It doesn't seem to have any purpose here.
>
> That is to disable -pedantic-errors which IIRC is added by default in
> the testsuite options.
Right.
> With -pedantic-errors we would have __has_extension behaving like
> __has_feature, and I wanted to check in the test that this doesn't get
> reported as a feature or extension.
Oh I see. A comment to that effect might be helpful.
Otherwise LGTM, thanks.
Marek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 16:27 ` Marek Polacek
@ 2024-02-02 16:32 ` Jakub Jelinek
2024-02-02 16:37 ` Marek Polacek
0 siblings, 1 reply; 7+ messages in thread
From: Jakub Jelinek @ 2024-02-02 16:32 UTC (permalink / raw)
To: Marek Polacek; +Cc: Alex Coplan, gcc-patches, Jason Merrill, Nathan Sidwell
On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > With -pedantic-errors we would have __has_extension behaving like
> > __has_feature, and I wanted to check in the test that this doesn't get
> > reported as a feature or extension.
>
> Oh I see. A comment to that effect might be helpful.
Don't we have over 1200 other tests with dg-options "" which
don't have comments why they are doing that?
Jakub
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 16:32 ` Jakub Jelinek
@ 2024-02-02 16:37 ` Marek Polacek
0 siblings, 0 replies; 7+ messages in thread
From: Marek Polacek @ 2024-02-02 16:37 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Alex Coplan, gcc-patches, Jason Merrill, Nathan Sidwell
On Fri, Feb 02, 2024 at 05:32:31PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > > With -pedantic-errors we would have __has_extension behaving like
> > > __has_feature, and I wanted to check in the test that this doesn't get
> > > reported as a feature or extension.
> >
> > Oh I see. A comment to that effect might be helpful.
>
> Don't we have over 1200 other tests with dg-options "" which
> don't have comments why they are doing that?
Yes, but the __has_extension / __has_feature thing doesn't seem
obvious at all, and the test passed for me with and without
dg-options "".
But I'm fine with the patch either way.
Marek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]
2024-02-02 15:45 ` Alex Coplan
2024-02-02 16:27 ` Marek Polacek
@ 2024-02-09 17:55 ` Jason Merrill
1 sibling, 0 replies; 7+ messages in thread
From: Jason Merrill @ 2024-02-09 17:55 UTC (permalink / raw)
To: Alex Coplan, Marek Polacek; +Cc: gcc-patches, Nathan Sidwell
On 2/2/24 10:45, Alex Coplan wrote:
> On 02/02/2024 09:34, Marek Polacek wrote:
>> On Fri, Feb 02, 2024 at 10:27:23AM +0000, Alex Coplan wrote:
>>> Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
>>>
>>> Thanks,
>>> Alex
>>>
>>> -- >8 --
>>>
>>> When __has_feature was introduced for GCC 14, I included the feature
>>> cxx_constexpr_string_builtins, since of the relevant string builtins
>>> that GCC implements, it seems to support constexpr evaluation of those
>>> builtins.
>>>
>>> However, as the PR shows, GCC doesn't implement the full list of
>>> builtins in the clang documentation. After enumerating the builtins,
>>> the clang docs [1] say:
>>>
>>>> Support for constant expression evaluation for the above builtins can
>>>> be detected with __has_feature(cxx_constexpr_string_builtins).
>>>
>>> and a strict reading of this would suggest we can't really support
>>> constexpr evaluation of a builtin if we don't implement the builtin in
>>> the first place.
>>>
>>> So the conservatively correct thing to do seems to be to stop
>>> advertising the feature altogether to avoid failing to build code which
>>> assumes the presence of this feature implies the presence of all the
>>> builtins listed in the clang documentation.
>>>
>>> [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
>>>
>>> gcc/cp/ChangeLog:
>>>
>>> PR c++/113658
>>> * cp-objcp-common.cc (cp_feature_table): Remove entry for
>>> cxx_constexpr_string_builtins.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR c++/113658
>>> * g++.dg/ext/pr113658.C: New test.
>>
>>> diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
>>> index f06edf04ef0..85dde0459fa 100644
>>> --- a/gcc/cp/cp-objcp-common.cc
>>> +++ b/gcc/cp/cp-objcp-common.cc
>>> @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
>>> { "cxx_alignof", cxx11 },
>>> { "cxx_attributes", cxx11 },
>>> { "cxx_constexpr", cxx11 },
>>> - { "cxx_constexpr_string_builtins", cxx11 },
>>> { "cxx_decltype", cxx11 },
>>> { "cxx_decltype_incomplete_return_types", cxx11 },
>>> { "cxx_default_function_template_args", cxx11 },
>>> diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C b/gcc/testsuite/g++.dg/ext/pr113658.C
>>> new file mode 100644
>>> index 00000000000..f4a34888f28
>>> --- /dev/null
>>> +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
>>
>> Might be better to name this has-feature2.C
>>
>> Please include
>> // PR c++/113658
>
> Can do.
OK with those two testcase adjustments.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-02-09 17:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-02 10:27 [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658] Alex Coplan
2024-02-02 14:34 ` Marek Polacek
2024-02-02 15:45 ` Alex Coplan
2024-02-02 16:27 ` Marek Polacek
2024-02-02 16:32 ` Jakub Jelinek
2024-02-02 16:37 ` Marek Polacek
2024-02-09 17:55 ` Jason Merrill
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).