Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
$ cat t.s
#include
int64x2_t fn (int64x2_t v, int64_t a)
{
return vsetq_lane_s64(a, v, 1);
}
compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #1 from avieira at gcc dot gnu.org ---
Had a look at this and I see similar codegen for aarch64 when compiling for
big-endian.
If I disable tree-ifcvt (-fdisable-tree-ifvt) I end up with:
MEM [(void *)Ptr.0_1] = 30071062528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #5 from avieira at gcc dot gnu.org ---
I checked it locally and Pinski's recommended change does seem to fix the
codegen for this case. I end up with:
MEM [(void *)Ptr.0_1] = { 7, 6291456 };
I am regression testing the chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
--- Comment #7 from avieira at gcc dot gnu.org ---
My aarch64_be-none-elf regression testing also came back with no new failures.
@Pinski: given it was your suggestion do you want the commit? ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #5 from avieira at gcc dot gnu.org ---
Posted a fix, I believe it's related to the fact that for the cases where we
were using noce before, it was using the default hook to do a cost check, my
patch blankly approved those, thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #4 from avieira at gcc dot gnu.org ---
No hadn't seen that yet. Will look at it thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #38 from avieira at gcc dot gnu.org ---
> At least if the behavior is either perform the operation on all elements and
> then based on the 16 bits in the predicate choose result between the newly
> computed result and somet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
avieira at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64-linux-gnu,|powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116997, which changed state.
Bug 116997 Summary: Wrong bitfield accesses since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116997
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
--- Comment #4 from avieira at gcc dot gnu.org ---
I've added arm-none-linux-gnueabihf to the target list there, but I'm wondering
whether we should have a separate bugzilla given it's likely this is a target
issue as Andrew point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111263
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
--- Comment #4 from avieira at gcc dot gnu.org ---
Good point Kyrill! I was just merely comparing m3 to m55 but yes you are right,
with low overhead loops you don't need the r3 count...
But -O2 also removes the r3, seems it does it at u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
201 - 220 of 220 matches
Mail list logo
