https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Bug 94042 depends on bug 94148, which changed state.
Bug 94148 Summary: The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #50 from Martin Liška ---
commit r10-7160-g5c7e6d4bdf879b437b43037e10453275acabf521
Author: Segher Boessenkool
Date: Thu Mar 12 07:12:50 2020 +
df: Don't abuse bb->aux (PR94148, PR94042)
The df dataflow solvers use th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64-suse-linux|powerpc*
Host|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #47 from Martin Liška ---
(In reply to Segher Boessenkool from comment #46)
> Thank you very much for that new testcase! I wish I had it before :-)
Do you mean /tmp/reduced.ii ? Note that it's already mentioned in c#14.
>
> Yester
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #46 from Segher Boessenkool ---
Thank you very much for that new testcase! I wish I had it before :-)
Yesterday I found the problem. It is in separate shrink-wrapping. The
fix is probably simple; hang on :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #45 from Martin Liška ---
(In reply to Jakub Jelinek from comment #44)
> So, with the reversion, can this be closed as FIXED?
I bet no. There's probably an underlying shrink-wrapping issue and Segher is
investigating that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #44 from Jakub Jelinek ---
So, with the reversion, can this be closed as FIXED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #43 from Martin Liška ---
(In reply to Martin Liška from comment #41)
> Ok, the way how we build our compiler is to use:
> ./configure --with-cpu=default32
>
> that should also lead to the ICE. I'm checking that.
So this one crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #42 from Segher Boessenkool ---
Okay, I see your dumps are 64-bit as well. But mine are very different, huh.
Still, it crashes in pretty much the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #41 from Martin Liška ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32
that should also lead to the ICE. I'm checking that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #40 from Martin Liška ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> >
> > Hm, that's possible. But the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #39 from Vladimir Makarov ---
I've reverted the patch in trouble:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #38 from Segher Boessenkool ---
Then, how did you do that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #37 from Segher Boessenkool ---
Oh wait. I am dumb I guess? You did those dumps with a stage1 compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from Segher Boessenkool ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
>
> Hm, that's possible. But the stage2 should not crash right?
It doesn't work, of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #35 from Martin Liška ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to Martin Liška from comment #31)
> > (In reply to Segher Boessenkool from comment #30)
> > > I cannot reproduce the problem, btw (I cannot build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism. I've decided to revert the patch as soon as git starts working.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Segher Boessenkool ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
Sigh. No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.
It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #31 from Martin Liška ---
(In reply to Segher Boessenkool from comment #30)
> I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> toolchain).
> Martin, you have a working recipe?
Go to gcc110 machine and do:
$ CC="g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #29 from Vladimir Makarov ---
Sorry for all the troubles with my latest patch and thank you for fair
criticism. I've decided to revert the patch as soon as git starts working.
I'll work to find a better solution after this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #36 from John Paul Adrian Glaubitz ---
The m68k bootstrap also recently got broken (PR/94059). Currently testing
whether this is also a result of this change
(r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #35 from Andrew Pinski ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I
Mean the false ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #34 from Segher Boessenkool ---
Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-)
It is very surprising (and not pleasantly so) that this overrides
REG_ALLOC_ORDER. We allocate GPR0 last (of the volatile GPRs), on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #33 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #32)
> So it sounds like this helps for targets with tiny register sets?
I guess it helps for any target but of course more for ones with smaller
register set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #32 from Segher Boessenkool ---
So it sounds like this helps for targets with tiny register sets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #31 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #30)
> r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
This heuristic avoid creating small gaps in hard reg file which prevent
assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #30 from Segher Boessenkool ---
r10-6919 isn't good for Power, btw. Why would it *ever* be a good idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Segher Boessenkool changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |segher at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #28 from Martin Liška ---
Created attachment 47990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47990&action=edit
Attempt to self-contained test-case
There's a PRE that needs to be triggered for error_mark_node and I was unab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #27 from Martin Liška ---
@Segher: Any of -fno-shrink-wrap-separate, -fno-shrink-wrap removes the
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #26 from Martin Liška ---
Created attachment 47985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47985&action=edit
RTL dump files for the function - good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #25 from Martin Liška ---
Created attachment 47984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47984&action=edit
RTL dump files for the function - bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #24 from Andrew Pinski ---
(In reply to Martin Liška from comment #23)
> (In reply to Andrew Pinski from comment #20)
> > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> > being copied into r8 and then co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #23 from Martin Liška ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #22 from Martin Liška ---
>
> good code stores:
> 0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std
> r0,144(r1)
> (gdb) p /x $r0
> $38 = 0x104c9294
>
> but the wrong one into a different memory address:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #21 from Martin Liška ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #20 from Andrew Pinski ---
The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
being copied into r8 and then copied back into r3 (return value), but not r0 is
used and that r0 is used for mtlr (moving back the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #19 from Martin Liška ---
Ok, using the following patch:
diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index 232b192..7e45e46 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -173,6 +173,7 @@ DEBUG_COUNTER (if_conversion_tree)
DEB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #18 from Martin Liška ---
I'll try to make part of the condition:
+ || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+ && best_hard_regno > hard_regno))
to be controllable by debug counter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #17 from Martin Liška ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Martin Liška from comment #15)
> > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
>
> This should just change the costs of the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
--- Comment #16 from Andrew Pinski ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
This should just change the costs of the register usage. Which means it might
be a latent bug
44 matches
Mail list logo
