https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #21 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #20)
> (In reply to Oleg Endo from comment #19)
> > Could you guys please test this patch? Actually, now it looks quite obvious
> > I think.
>
> gen_rtx_SET functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #20 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #19)
> Could you guys please test this patch? Actually, now it looks quite obvious
> I think.
gen_rtx_SET functions required SImode as their first argument.
Tests are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #19 from Oleg Endo ---
(In reply to Oleg Endo from comment #18)
> Yes, that is true. However, because op0, op1, op2 are all "arith_reg_dest"
> the peephole will only match if those are GP regs. Each captured insn will
> only refere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #18 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #16)
>
> Also arguments of emit_move_insn must have the same integer modes.
>
> if (reg_overlap_mentioned_p (operands[1], operands[2]))
> std::swap (operands[0],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #17 from John Paul Adrian Glaubitz ---
Thanks a lot guys for working on this! I'm really glad you're doing this :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #16 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #15)
Thanks for a quick look!
> However, I think that the emit_move_insn could also be a source of hidden
> problems. For instance, if the captured insn
Also argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #15 from Oleg Endo ---
(In reply to Oleg Endo from comment #14)
>
> I think the check operands[1] / operands[2] check should go into the
> preparation statement. operands[0] is dying after this peephole, so I guess
> this should wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #13 from Kazumoto Kojima ---
Created attachment 35572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35572&action=edit
reduced testcase
>From rtl dumps for 5.1.0 cc1plus against the testcase, the wrong
peephole transformation m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #12 from Kazumoto Kojima ---
I've looked into which stage2 object was miscompiled with bisecting
on objects for 5.1.0 and found tree-cfg.o is the one of them.
5.1.0 cross compiler miscompiles it too and I've got which change
causes th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #11 from John Paul Adrian Glaubitz ---
So, I have tried disabling some of the patches but it seems that these depend
on each other. Thus, I will probably have to checkout gcc from source via git
and revert the patches using git.
Unle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> I haven't worked with the gcc code base before, so any suggestions on how to
> work through the code?
Ah, I just realized Matthias put a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #9 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #8)
> You can revert the above changes to see what happens. Looks safe
> changes to me, but some changes could reveal hidden problems.
> If the issue rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #8 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> Just built with gcc-4.9_4.9.2-7 which previously successfully built
> gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.9.2-16 [2].
It seems that l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> To be followed up.
Just built with gcc-4.9_4.9.2-7 which previously successfully built
gcc-4.9_4.9.2-10 [1] but fails to build gcc-4.9_4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #6 from John Paul Adrian Glaubitz ---
Hi!
I did some more tests and it turns out, my current compiler can't even build
gcc-4.9 anymore. Inspecting the build log [1] closer hints at problems when the
stages 2 and 3 are being compared:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #5 from John Paul Adrian Glaubitz ---
> I can't see these failures on my cross builds of gcc-5, though.
> It could be a problem of the build compiler too.
I am manually building the latest gcc-4.9.2 snapshot we have in Debian now and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #4 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #3)
> I can't see these failures on my cross builds of gcc-5, though.
> It could be a problem of the build compiler too.
Although I can't see them in my cross buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Kazumoto Kojima changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment
19 matches
Mail list logo
