https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:932e9140d3268cf2033c1c3e93219541c53fcd29
commit r10-8501-g932e9140d3268cf2033c1c3e93219541c53fcd29
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:efe99cca78215e339ba79f0a900a896b4c0a3d36
commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64-linux |aarch64*-*-* arm*-*-*
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:31427b974ed7b7dd54e28fec595e731bf6eea8ba
commit r11-1741-g31427b974ed7b7dd54e28fec595e731bf6eea8ba
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #8 from rsandifo at gcc dot gnu.org
---
Thanks for the pointers. Putting the mangled name in a target-specific
attribute (like we do for SVE) seems to fix it. It actually also keeps
the testcase in comment 4 “working”, which is une
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #7 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #5)
> Dunno, perhaps for backporting it could be done in template_args_equal
> instead?
For backporting we could treat them as different only if
comparing_specializati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #6 from Jason Merrill ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > But if they mangle differently, then structural_comptypes shouldn't treat
> > them as same types.
Definite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #5 from Jakub Jelinek ---
Dunno, perhaps for backporting it could be done in template_args_equal instead?
Like I said, it would probably need to handle also POINTER/REFERENCE/ARRAY_TYPE
whose ultimate element type is VECTOR_TYPE possi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #3)
> But if they mangle differently, then structural_comptypes shouldn't treat
> them as same types.
That certainly avoids the ICE, and makes GCC's beha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #3 from Jakub Jelinek ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> They mangle differently, and e.g.:
>
> void f(float32x4_t);
> void f(V);
>
> aren't ODR equivalent. But a lot of code relies on the GNU vector
> extensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Jason Merrill from comment #1)
> Does the aarch64 port expect __Float32x4_t type to be considered equivalent
> to the GNU vector type or not? If so, why use build_distinct_type_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #1 from Jason Merrill ---
Does the aarch64 port expect __Float32x4_t type to be considered equivalent to
the GNU vector type or not? If so, why use build_distinct_type_copy over
build_variant_type_copy? If not, they might want to se
15 matches
Mail list logo
