public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types
[not found] <bug-92789-4@http.gcc.gnu.org/bugzilla/>
@ 2020-06-30 20:40 ` cvs-commit at gcc dot gnu.org
2020-06-30 21:07 ` rsandifo at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-30 20:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:
https://gcc.gnu.org/g:31427b974ed7b7dd54e28fec595e731bf6eea8ba
commit r11-1741-g31427b974ed7b7dd54e28fec595e731bf6eea8ba
Author: Richard Sandiford <richard.sandiford@arm.com>
Date: Tue Jun 30 21:40:30 2020 +0100
aarch64: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]
PR95726 is about template look-up for things like:
foo<float vecf __attribute__((vector_size(16)))>
foo<float32x4_t>
The immediate cause of the problem is that the hash function usually
returns different hashes for these types, yet the equality function
thinks they are equal. This then raises the question of how the types
are supposed to be treated.
I think the answer is that the GNU vector type should be treated as
distinct from float32x4_t, not least because the two types mangle
differently. However, each type should implicitly convert to the other.
This would mean that, as far as the PR is concerned, the hashing
function is right to (sometimes) treat the types differently and
the equality function is wrong to treat them as the same.
The most obvious way to enforce the type difference is to use a
target-specific type attribute. That on its own is enough to fix
the PR. The difficulty is deciding whether the knock-on effects
are acceptable.
One obvious effect is that GCC then rejects:
typedef float vecf __attribute__((vector_size(16)));
vecf x;
float32x4_t &z = x;
on the basis that the types are no longer reference-compatible.
I think that's again the correct behaviour, and consistent with
current Clang.
A trickier question is whether:
vecf x;
float32x4_t y;
⦠c ? x : y â¦
should be valid, and if so, what its type should be [PR92789].
As explained in the comment in the testcase, GCC and Clang both
accepted this, but GCC chose the âthenâ type while Clang chose
the âelseâ type. This can lead to different mangling for (probably
artificial) corner cases, as seen for âsel1â and âsel2â in the
testcase.
Adding the attribute makes GCC reject the conditional expression
as ambiguous. I think that too is the correct behaviour, for the
reasons described in the testcase. However, it does seem to have
the potential to break existing code.
It looks like aarch64_comp_type_attributes is missing cases for
the SVE attributes, but I'll handle that in a separate patch.
2020-06-30 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR target/92789
PR target/95726
* config/aarch64/aarch64.c (aarch64_attribute_table): Add
"Advanced SIMD type".
(aarch64_comp_type_attributes): Check that the "Advanced SIMD type"
attributes are equal.
* config/aarch64/aarch64-builtins.c: Include stringpool.h and
attribs.h.
(aarch64_mangle_builtin_vector_type): Use the mangling recorded
in the "Advanced SIMD type" attribute.
(aarch64_init_simd_builtin_types): Add an "Advanced SIMD type"
attribute to each Advanced SIMD type, using the mangled type
as the attribute's single argument.
gcc/testsuite/
PR target/92789
PR target/95726
* g++.target/aarch64/pr95726.C: New test.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types
[not found] <bug-92789-4@http.gcc.gnu.org/bugzilla/>
2020-06-30 20:40 ` [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types cvs-commit at gcc dot gnu.org
@ 2020-06-30 21:07 ` rsandifo at gcc dot gnu.org
2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org
2020-07-10 18:09 ` rsandifo at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2020-06-30 21:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Keeping open since the problem also affects arm*-*-*. I don't
think we should change GCC 10 and earlier though.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types
[not found] <bug-92789-4@http.gcc.gnu.org/bugzilla/>
2020-06-30 20:40 ` [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types cvs-commit at gcc dot gnu.org
2020-06-30 21:07 ` rsandifo at gcc dot gnu.org
@ 2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org
2020-07-10 18:09 ` rsandifo at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-10 18:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:
https://gcc.gnu.org/g:efe99cca78215e339ba79f0a900a896b4c0a3d36
commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36
Author: Richard Sandiford <richard.sandiford@arm.com>
Date: Fri Jul 10 19:06:45 2020 +0100
arm: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]
This is an arm version of aarch64 patch r11-1741. The approach
is essentially identical, not much more than s/aarch64/arm/.
To recap, PR95726 is about template look-up for things like:
foo<float vecf __attribute__((vector_size(16)))>
foo<float32x4_t>
The immediate cause of the problem is that the hash function usually
returns different hashes for these types, yet the equality function
thinks they are equal. This then raises the question of how the types
are supposed to be treated.
The answer we chose for AArch64 was that the GNU vector type should
be treated as distinct from float32x4_t, but that each type should
implicitly convert to the other.
This would mean that, as far as the PR is concerned, the hashing
function is right to (sometimes) treat the types differently and
the equality function is wrong to treat them as the same.
The most obvious way to enforce the type difference is to use a
target-specific type attribute. That on its own is enough to fix
the PR. The difficulty is deciding whether the knock-on effects
are acceptable.
One obvious effect is that GCC then rejects:
typedef float vecf __attribute__((vector_size(16)));
vecf x;
float32x4_t &z = x;
on the basis that the types are no longer reference-compatible.
For AArch64 we took the approach that this was the correct behaviour.
It is also consistent with current Clang.
A trickier question is whether:
vecf x;
float32x4_t y;
⦠c ? x : y â¦
should be valid, and if so, what its type should be [PR92789].
As explained in the comment in the testcase, GCC and Clang both
accepted this, but GCC chose the âthenâ type while Clang chose
the âelseâ type. This can lead to different mangling for (probably
artificial) corner cases, as seen for âsel1â and âsel2â in the
testcase.
Adding the attribute makes GCC reject the conditional expression
as ambiguous. For AArch64 we took the approach that this too is
the correct behaviour, for the reasons described in the testcase.
However, it does seem to have the potential to break existing code.
gcc/
PR target/92789
PR target/95726
* config/arm/arm.c (arm_attribute_table): Add
"Advanced SIMD type".
(arm_comp_type_attributes): Check that the "Advanced SIMD type"
attributes are equal.
* config/arm/arm-builtins.c: Include stringpool.h and
attribs.h.
(arm_mangle_builtin_vector_type): Use the mangling recorded
in the "Advanced SIMD type" attribute.
(arm_init_simd_builtin_types): Add an "Advanced SIMD type"
attribute to each Advanced SIMD type, using the mangled type
as the attribute's single argument.
gcc/testsuite/
PR target/92789
PR target/95726
* g++.target/arm/pr95726.C: New test.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types
[not found] <bug-92789-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org
@ 2020-07-10 18:09 ` rsandifo at gcc dot gnu.org
3 siblings, 0 replies; 4+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2020-07-10 18:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed for GCC 11. Not suitable for backports.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-10 18:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-92789-4@http.gcc.gnu.org/bugzilla/>
2020-06-30 20:40 ` [Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types cvs-commit at gcc dot gnu.org
2020-06-30 21:07 ` rsandifo at gcc dot gnu.org
2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org
2020-07-10 18:09 ` rsandifo at gcc dot gnu.org
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).