https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #29 from Bill Schmidt ---
Author: wschmidt
Date: Tue Dec 6 22:11:54 2016
New Revision: 243319
URL: https://gcc.gnu.org/viewcvs?rev=243319&root=gcc&view=rev
Log:
2016-12-06 Bill Schmidt
Backport from mainline
2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #28 from Bill Schmidt ---
Just recording that, as expected, this patch had neutral performance on
SPECcpu2006.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #26 from Bill Schmidt ---
The original patch direction was impossible to make work, as with a base
register of r31 (frame pointer) and an offset register of r0 (not allowed as a
base register), there is no legitimate way to update the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #25 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 1 14:43:55 2016
New Revision: 239938
URL: https://gcc.gnu.org/viewcvs?rev=239938&root=gcc&view=rev
Log:
2016-09-01 Bill Schmidt
Michael Meissner
PR ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #24 from Bill Schmidt ---
This seems to work as a short-term solution (c,c++,ada bootstrap succeeds).
Need to do a full regstrap with all the languages.
Index: gcc/config/rs6000/rs6000.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #23 from Bill Schmidt ---
Bleah, that doesn't work because offsetreg needs to contain something that's a
valid address in order to use replace_equiv_address. So something more
involved is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #22 from Michael Meissner ---
Note, if the index register is R0 and the base register is SP, you might not be
able to use the other register (well you can use it, but you likely will get a
segmentation fault or just access the wrong m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #21 from Bill Schmidt ---
I think for the purposes of this bug we should be able to work around it by
forcing the offset register to be modified instead of the base register. Going
to try testing this:
Index: gcc/config/rs6000/rs600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #20 from Michael Meissner ---
Yeah, it sounds like you don't want to adjust any of the stack related
registers.
However, in looking at this $#!%, we probably need to rewrite it so it doesn't
do clever tricks like this. Which probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #19 from Bill Schmidt ---
I'm suspicious of rs6000_split_multireg_move in rs6000.c, which appears to be
the code that gets called to split a TImode move involving a GPR pair.
In particular, this code:
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #18 from Bill Schmidt ---
The frame pointer adjustments are introduced in 263r.split2. I haven't yet run
down the offending split, but the pattern being split is a *vsx_movti_64bit. I
know we've had changes in the back end fairly re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #17 from Eric Botcazou ---
> Is this kind of frame pointer adjustment a common occurrence with Ada code
> gen, or do you think this is related to POWER code gen somehow? I've never
> seen this sort of thing before.
No, that's really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #16 from Bill Schmidt ---
Looks like the back end must be inserting the frame pointer adjustments, as
they aren't there at expand time. From the 218.vregs dump:
(call_insn 141 140 3128 2 (parallel [
(set (reg:TI 3 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #15 from Bill Schmidt ---
Created attachment 39520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39520&action=edit
Dumps before and after dse2
Here are the full dumps before and after dse2 in tarball form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #14 from Bill Schmidt ---
Confirmed that the frame pointer dance is where the issue is. Prior to dse2:
(insn 3854 144 4133 2 (set (reg:DI 9 9 [1674])
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #13 from Eric Botcazou ---
> Yes, it does! The tools appear to be building normally with this option.
> Without it the build of gnattools fails almost immediately.
>
> I'll work on getting some dumps to see what is happening in DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #12 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #10)
> > So the double-word load before the call to SS_Release should be from a
> Mark_Id object obtained from a preceding call to SS_Mark. It indeed looks
> like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #11 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #8)
> > I'm afraid I don't know anything about Ada and how its runtime works; it
> > looks like system.secondary_stack.ss_release is called automatically somehow
> > as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #10 from Eric Botcazou ---
> It does look possible that this is an LRA issue. Here's the code right
> before failure:
>
> 100dae08: f8 95 22 39 addir9,r2,-27144
> 100dae0c: 01 00 40 39 li r10,1
> 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #8 from Eric Botcazou ---
> I'm afraid I don't know anything about Ada and how its runtime works; it
> looks like system.secondary_stack.ss_release is called automatically somehow
> as part of entering make.Initialize, but I have no i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #7 from Bill Schmidt ---
It does look possible that this is an LRA issue. Here's the code right before
failure:
100dae08: f8 95 22 39 addir9,r2,-27144
100dae0c: 01 00 40 39 li r10,1
100dae10: 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #6 from Bill Schmidt ---
Backtrace info (svn r239837):
Program received signal SIGSEGV, Segmentation fault.
system.secondary_stack.ss_release (m=...) at ../rts/s-secsta.adb:479
479 To_Stack_Ptr (M.Sstk).Top := M.Sptr;
(g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #5 from Peter Bergner ---
(In reply to Eric Botcazou from comment #4)
> This may have been introduced by:
>
> 2016-08-03 Peter Bergner
>
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Make LRA
> the def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Eric Botcazou changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Eric Botcazou changed:
What|Removed |Added
Component|ada |target
--- Comment #3 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #2 from Bill Schmidt ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405 which appears to be
very similar (slight difference in the error message).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
30 matches
Mail list logo
