* [PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223]
@ 2024-05-25 23:18 Patrick Palka
2024-05-28 19:00 ` Jason Merrill
0 siblings, 1 reply; 2+ messages in thread
From: Patrick Palka @ 2024-05-25 23:18 UTC (permalink / raw)
To: gcc-patches; +Cc: jason, Patrick Palka
Bootstrap and regtest on x86_64-pc-linux-gnu in progress,
does this look OK for trunk if successful?
-- >8 --
When propagating structural equality in build_cp_fntype_variant, we
should consider structural equality of the exception-less variant, not
of the given type which might use structural equality only because of
the (complex) noexcept-spec we're intending to replace, as in
maybe_instantiate_noexcept which calls build_exception_variant using
the function type with a deferred noexcept-spec. Otherwise we might
pessimisticly use structural equality for a function type with a simple
instantiated noexcept-spec, leading to a failed LTO-specific sanity
check if we later use that (structural-equality) type as the canonical
version of some other variant.
PR c++/115223
gcc/cp/ChangeLog:
* tree.cc (build_cp_fntype_variant): Propagate structural
equality of the exception-less variant.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept87.C: New test.
---
gcc/cp/tree.cc | 4 ++++
gcc/testsuite/g++.dg/cpp0x/noexcept87.C | 11 +++++++++++
2 files changed, 15 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept87.C
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 4d87661b4ad..f810b8cd777 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2796,6 +2796,10 @@ build_cp_fntype_variant (tree type, cp_ref_qualifier rqual,
bool complex_eh_spec_p = (cr && cr != noexcept_true_spec
&& !UNPARSED_NOEXCEPT_SPEC_P (cr));
+ if (!complex_eh_spec_p && TYPE_RAISES_EXCEPTIONS (type))
+ /* We want to consider structural equality of the exception-less
+ variant since we'll be replacing the exception specification. */
+ type = build_cp_fntype_variant (type, rqual, /*raises=*/NULL_TREE, late);
if (TYPE_STRUCTURAL_EQUALITY_P (type) || complex_eh_spec_p)
/* Propagate structural equality. And always use structural equality
for function types with a complex noexcept-spec since their identity
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
new file mode 100644
index 00000000000..60b1497472b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
@@ -0,0 +1,11 @@
+// PR c++/115223
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -flto }
+
+template<class T>
+void f() noexcept(bool(T() || true));
+
+void g(int n) { f<int>(); }
+
+using type = void;
+type callDestructorIfNecessary() noexcept {}
--
2.45.1.246.gb9cfe4845c
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223]
2024-05-25 23:18 [PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223] Patrick Palka
@ 2024-05-28 19:00 ` Jason Merrill
0 siblings, 0 replies; 2+ messages in thread
From: Jason Merrill @ 2024-05-28 19:00 UTC (permalink / raw)
To: Patrick Palka, gcc-patches
On 5/25/24 19:18, Patrick Palka wrote:
> Bootstrap and regtest on x86_64-pc-linux-gnu in progress,
> does this look OK for trunk if successful?
OK.
> -- >8 --
>
> When propagating structural equality in build_cp_fntype_variant, we
> should consider structural equality of the exception-less variant, not
> of the given type which might use structural equality only because of
> the (complex) noexcept-spec we're intending to replace, as in
> maybe_instantiate_noexcept which calls build_exception_variant using
> the function type with a deferred noexcept-spec. Otherwise we might
> pessimisticly use structural equality for a function type with a simple
> instantiated noexcept-spec, leading to a failed LTO-specific sanity
> check if we later use that (structural-equality) type as the canonical
> version of some other variant.
>
> PR c++/115223
>
> gcc/cp/ChangeLog:
>
> * tree.cc (build_cp_fntype_variant): Propagate structural
> equality of the exception-less variant.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/noexcept87.C: New test.
> ---
> gcc/cp/tree.cc | 4 ++++
> gcc/testsuite/g++.dg/cpp0x/noexcept87.C | 11 +++++++++++
> 2 files changed, 15 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept87.C
>
> diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
> index 4d87661b4ad..f810b8cd777 100644
> --- a/gcc/cp/tree.cc
> +++ b/gcc/cp/tree.cc
> @@ -2796,6 +2796,10 @@ build_cp_fntype_variant (tree type, cp_ref_qualifier rqual,
> bool complex_eh_spec_p = (cr && cr != noexcept_true_spec
> && !UNPARSED_NOEXCEPT_SPEC_P (cr));
>
> + if (!complex_eh_spec_p && TYPE_RAISES_EXCEPTIONS (type))
> + /* We want to consider structural equality of the exception-less
> + variant since we'll be replacing the exception specification. */
> + type = build_cp_fntype_variant (type, rqual, /*raises=*/NULL_TREE, late);
> if (TYPE_STRUCTURAL_EQUALITY_P (type) || complex_eh_spec_p)
> /* Propagate structural equality. And always use structural equality
> for function types with a complex noexcept-spec since their identity
> diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
> new file mode 100644
> index 00000000000..60b1497472b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
> @@ -0,0 +1,11 @@
> +// PR c++/115223
> +// { dg-do compile { target c++11 } }
> +// { dg-additional-options -flto }
> +
> +template<class T>
> +void f() noexcept(bool(T() || true));
> +
> +void g(int n) { f<int>(); }
> +
> +using type = void;
> +type callDestructorIfNecessary() noexcept {}
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-05-28 19:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-25 23:18 [PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223] Patrick Palka
2024-05-28 19:00 ` 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).