https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #1 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> Created attachment 36354 [details]
> Preprocessed source for cselib.c
Thanks for reporting. I was a bit confused ... the attached source is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #3 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #2)
> Created attachment 36356 [details]
> reduced test case
>
> I can reproduce it with trunk rev. 227929 but can't with 227887.
> Clearly very fragile.
> ...
> into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #7 from Oleg Endo ---
Created attachment 36357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36357=edit
Proposed patch
Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
value loaded from memory,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #5 from Oleg Endo ---
(In reply to Oleg Endo from comment #4)
Just for reference, those are the exact options:
-x c -std=gnu99 -m4 -ml -g -O2 -ffloat-store -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #2 from Kazumoto Kojima ---
Created attachment 36356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36356=edit
reduced test case
I can reproduce it with trunk rev. 227929 but can't with 227887.
Clearly very fragile.
It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #6 from Oleg Endo ---
The peephole outputs this:
(insn 2292 0 0 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) -1
(expr_list:REG_INC
