https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #19 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:ffe8baa996486fa0313aa804a064a58b0b161f07
commit r11-3748-gffe8baa996486fa0313aa804a064a58b0b161f07
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #18 from Martin Liška ---
(In reply to Jan Hubicka from comment #17)
> And is it again the operator++ triggering the problem?
> It looks like aliasing bug to me, but in a template hell and
> -Wstrict-aliasing=3 is happy.
It's another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #17 from Jan Hubicka ---
And is it again the operator++ triggering the problem?
It looks like aliasing bug to me, but in a template hell and
-Wstrict-aliasing=3 is happy.
The reason why parameter tracking is necessary seems to be the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #16 from Martin Liška ---
I was able to find a minimal debug counter for IPA modref that triggers that:
-fdbg-cnt=ipa_mod_ref:10902-10904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #15 from Jan Hubicka ---
So it seems that problem is that store in operator++ is TriaObjectAcessor while
read is DoFCellAccessor. I am however not sure where the type puning happens :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct TriaRawIter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #13 from Jan Hubicka ---
OK, I can reproduce it even though the propagation happens in different
function in dom rather than pre.
The callee is again the operator++ so I start to suspect aliasing violation
there.
I get:
ipa-modref: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #12 from Tamar Christina ---
(In reply to Martin Liška from comment #11)
> (In reply to Tamar Christina from comment #0)
> > With just -Ofast the benchmark doesn't seem to ever terminate until it is
> > eventually killed.
> >
>
> Ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #11 from Martin Liška ---
(In reply to Tamar Christina from comment #0)
> With just -Ofast the benchmark doesn't seem to ever terminate until it is
> eventually killed.
>
Can't reproduce the stuck without -flto.
10 matches
Mail list logo
