public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument Date: Tue, 30 Jun 2020 20:40:56 +0000 [thread overview] Message-ID: <bug-95726-4-Iox1xC1JqA@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-95726-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #9 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.
next prev parent reply other threads:[~2020-06-30 20:40 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-17 19:02 [Bug c++/95726] New: " jakub at gcc dot gnu.org 2020-06-17 19:07 ` [Bug c++/95726] " jason at gcc dot gnu.org 2020-06-17 19:08 ` jason at gcc dot gnu.org 2020-06-17 19:29 ` rsandifo at gcc dot gnu.org 2020-06-17 19:36 ` jakub at gcc dot gnu.org 2020-06-18 12:49 ` rsandifo at gcc dot gnu.org 2020-06-18 16:11 ` rsandifo at gcc dot gnu.org 2020-06-18 16:46 ` jakub at gcc dot gnu.org 2020-06-18 20:10 ` jason at gcc dot gnu.org 2020-06-19 16:23 ` jason at gcc dot gnu.org 2020-06-22 16:04 ` rsandifo at gcc dot gnu.org 2020-06-30 20:40 ` cvs-commit at gcc dot gnu.org [this message] 2020-06-30 21:10 ` rsandifo at gcc dot gnu.org 2020-07-10 18:07 ` cvs-commit at gcc dot gnu.org 2020-07-15 10:58 ` cvs-commit at gcc dot gnu.org 2020-08-04 12:47 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-95726-4-Iox1xC1JqA@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).