https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:a216daaa30bc8949086a16e7656f2025b692d03c
commit r10-8562-ga216daaa30bc8949086a16e7656f2025b692d03c
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:7d599ad27b9bcf5165f87710f1abc64bbabd06ae
commit r11-2481-g7d599ad27b9bcf5165f87710f1abc64bbabd06ae
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #10 from joseph at codesourcery dot com ---
On Thu, 30 Jul 2020, rsandifo at gcc dot gnu.org wrote:
> IMO process_init_element shouldn't recurse into vector types
> if the initialisation value is also a vector type. We should
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Created attachment 48964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48964=edit
Patch for the initialisation problem
I'm testing this patch to fix the initialisation side of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> I guess that is reasonable thing to do, if the two vector types aren't
> really compatible one will get an error.
> But then, for trunk, won't the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #7 from Jakub Jelinek ---
I guess that is reasonable thing to do, if the two vector types aren't really
compatible one will get an error.
But then, for trunk, won't the stripping of the attributes from vector types
still mean that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #5 from rsandifo at gcc dot gnu.org
---
I think this is bound up with the question whether:
typedef int v4si __attribute__((vector_size(16)));
typedef short v8hi __attribute__((vector_size(16)));
struct s {
v8hi x;
v4si y;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #3 from Jakub Jelinek ---
For those that need a quick workaround for the kernel, I think
(uint8x16_t) (k ^ vld1q_u8(const0)),
(uint8x16_t) (k ^ vld1q_u8(const1)),
instead of
k ^ vld1q_u8(const0),
k ^ vld1q_u8(const1),
will do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #2 from Jakub Jelinek ---
This dates back to
https://gcc.gnu.org/legacy-ml/gcc-patches/2004-06/msg00288.html
Dunno, do we want to never strip attributes from VECTOR_TYPEs and only strip
them that way from non-VECTOR_TYPEs? Or only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #1 from Jakub Jelinek ---
I think the problem is that c_common_type does:
742 if (TYPE_ATTRIBUTES (t1) != NULL_TREE)
743 t1 = build_type_attribute_variant (t1, NULL_TREE);
744
745 if (TYPE_ATTRIBUTES (t2) !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
Last
17 matches
Mail list logo
