https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #21 from CVS Commits ---
The releases/gcc-10 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:410ddbbc6612ca25f4a00120987921372937623e
commit r10-9433-g410ddbbc6612ca25f4a00120987921372937623e
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #20 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns. I'm not certain whether your fix is the best way to achieve that,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #19 from Peter Bergner ---
Fixed on trunk. Needs backporting to GCC10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #18 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:cb25dea3ef2c7768007bffc56f0e31e1c42b44e2
commit r11-7558-gcb25dea3ef2c7768007bffc56f0e31e1c42b44e2
Author: Peter Bergner
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> The question I have is, there are 2 expanders which I think we also need to
> guard with similar tests. They are vsx_load_ and vsx_store_.
> Segher, I assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #16 from Peter Bergner ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns. I'm not certain whether your fix is the best way to achieve that,
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #15 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #14 from Bill Schmidt ---
We should definitely not be allowing the AltiVec "& ~16" flavors into these
patterns. I'm not certain whether your fix is the best way to achieve that,
but it could well be; I'll defer to Segher on that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #12 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #11 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #10 from Jakub Jelinek ---
The important difference from my auto-host.h to your auto-host.h which causes
this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
Manually commenting it out makes the ICE reproduceable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #9 from Martin Liška ---
> If that fixes it, are you really seeing the same ICE on current trunk?
Yes, I see it also on the current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #8 from Peter Bergner ---
(In reply to Martin Liška from comment #2)
> I do not set any default CPU:
The default cpu on ppc64le is (should be!) POWER8.
That said, I cannot recreate the issue with a cross build using current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #7 from Peter Bergner ---
I cannot recreate the ICE with a native build. I'll try building a cross and
seeing if that exposes the issue for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #6 from Martin Liška ---
Emergency dump:
dump file: ice.i.298r.pro_and_epilogue
;; Function me0 (me0, funcdef_no=0, decl_uid=3226, cgraph_uid=1,
symbol_order=0)
try_optimize_cfg iteration 1
starting the processing of deferred ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Martin Liška changed:
What|Removed |Added
Attachment #50125|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #4 from Martin Liška ---
Created attachment 50125
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50125&action=edit
auto-host.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Martin Liška changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #2 from Martin Liška ---
I do not set any default CPU:
$ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc
ice.i -c -fno-schedule-insns -O2 -v
Using built-in specs.
COLLECT_GCC=/home/marxin/BIG/bin/ppc64le/dev/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-02-03
Status|UNCONFIRMED
24 matches
Mail list logo