https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #13 from Matthias Klose ---
yes, this works, and I don't see any regressions in the testsuite compared to
non pgo/lto build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #12 from Bill Schmidt ---
Created attachment 37348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37348&action=edit
Proposed patch
Matthias, please apply the attached patch and see if it clears the bug for you.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #11 from Bill Schmidt ---
OK, I see. Although the PHI itself is not directly modified, a new PHI is
introduced in the same block. During this process we may alter the incoming
control flow to the block (introducing a new block along
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #10 from Bill Schmidt ---
The stmt_cand_map is *not* losing its integrity. Instead, it appears that a
phi statement changes its address at some point during the SLSR pass, even
though it hasn't been modified (SFAICT).
There are two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #9 from Bill Schmidt ---
It appears that the stmt_cand_map, which is a hash_map from gimple*s to
candidates, must be getting overwritten. At the time things go south, we have
done a lookup on the var _1338 using base_cand_from_table.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #8 from Matthias Klose ---
> Can you please delete the line
>
> dump_incr_vec ();
>
> from that patch and try again?
installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #7 from Bill Schmidt ---
The most likely cause here is memory being improperly overwritten. If the data
from the next round of dumps don't turn up anything, I'll need a debuggable
version of gcc so I can try to sort out the offender.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #6 from Bill Schmidt ---
Hm, that almost worked. Can you please delete the line
dump_incr_vec ();
from that patch and try again? Sorry for the trouble. Meanwhile I'll see if
the partial data I got triggers any ideas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #5 from Matthias Klose ---
> Matthias, can you please incorporate th3 debug patch
> from the previous comment into your source
done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #3 from Bill Schmidt ---
Created attachment 37008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37008&action=edit
test patch to gather more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #2 from Bill Schmidt ---
Hi Matthias,
Attempted to recreate with powerpc64le-linux-gnu running on POWER8 using latest
gcc-5-branch. I get a different failure within lto1; output shown below. This
indicates a problem streaming in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Matthias Klose changed:
What|Removed |Added
Target||powerpc64le-linux-gnu,
14 matches
Mail list logo
