Bug 24624 - [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
Summary: [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.0
: P5 critical
Target Milestone: 4.1.0
Assignee: Andreas Krebbel
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2005-11-01 21:47 UTC by Richard Biener
Modified: 2005-11-09 12:18 UTC (History)
3 users (show)

See Also:
Host:
Target: s390x-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-03 02:04:45


Attachments
reduced testcase (613 bytes, text/plain)
2005-11-01 21:48 UTC, Richard Biener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2005-11-01 21:47:48 UTC
We ICE compiling the linux kernel.

/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1 -fpreprocessed inetpeer.i -quiet -dumpbase inetpeer.c -m64 -mbackchain -msoft-float -march=z900 -mpacked-stack -mstack-size=8192 -mstack-guard=256 -mwarn-dynamicstack -mwarn-framesize=256 -mzarch -auxbase-strip net/ipv4/.tmp_inetpeer.o -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wno-sign-compare -Wdeclaration-after-statement -Wno-pointer-sign -version -fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer -finline-limit=10000 -fno-strength-reduce -o inetpeer.s

net/ipv4/inetpeer.c: In function 'peer_check_expire':
net/ipv4/inetpeer.c:461: internal compiler error: in reload, at reload1.c:1071
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.suse.de/feedback> for instructions.
Comment 1 Richard Biener 2005-11-01 21:48:23 UTC
Created attachment 10105 [details]
reduced testcase

testcase
Comment 2 Janis Johnson 2005-11-03 01:28:11 UTC
A regression hunt using a cross compiler identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=101381

2005-06-28  Andreas Krebbel  <krebbel1@de.ibm.com>
                                                                                
        * config/s390/s390.c (machine_function): New field has_landing_pad_p.
        (s390_set_has_landing_pad_p, s390_reg_clobbered_rtx,
         s390_regs_ever_clobbered): New functions.
        (s390_return_addr_rtx): Use get_hard_reg_initial_value.
        (s390_register_info, s390_init_frame_layout, s390_update_frame_layout):
        Use s390_regs_ever_clobbered.
        (s390_emit_prologue): Don't use r14 as temp reg if its content is used
        for builtin_return_address.
        * config/s390/s390.md ("exception_receiver"): New expander.
        * config/s390/s390-protos.h (s390_set_has_landing_pad_p): Prototype
        added.

Only the following options are needed to reproduce the failure with
the reduced testcase: -m64 -mpacked-stack -mstack-size=8192 -mstack-guard=256
Comment 3 Ulrich Weigand 2005-11-03 02:04:45 UTC
Likely backend problem, investigating ...
Comment 4 Mark Mitchell 2005-11-03 06:43:55 UTC
Downgraded to P5; S390 is not a primary or secondary target.
Comment 5 Mark Mitchell 2005-11-03 06:44:45 UTC
Correcting accidental un-assignment.
Comment 6 Andreas Krebbel 2005-11-04 07:56:45 UTC
My patch introduced the s390_regs_ever_clobbered function
which is used instead of regs_ever_live for determining
which registers need saving in function prologue.
This function is called during reload when the elimination
offsets of eliminable registers are calculated. Whithin the
first phase of reload where the reloads only are recorded in
struct reloads without modifying the insn itself the back end
function only sees the registers assigned by global alloc.
Whenever a call clobbered register assigned by global alloc
is changed to a call saved register by reload the back end
can not see this change in the first phase of reload but
afterwards when the changes are applied to the insn. Hence
the elimination offset for the arg pointer can change what
causes the ICE.

Using regs_ever_live is safe even in this first reload phase
because that array is updated when reload information is
recorded in spill_hard_reg.

I've tried a back end hack in s390_regs_ever_clobbered walking 
through the reload_insn_chain if reload_in_progress is set.
For all reload structs I've marked the used reload regs in my
regs_ever_clobbered array. But this is probably wrong because
reload is not bound to the decisions made in the first phase.
It is only assured that the regs in used_spill_regs are sufficient
for covering all spill decisions which will be made later on.
So the better choice should be to look into the used_spill_regs
array which unfortunately is set up after verify_initial_elim_offsets
is called (in select_reload_regs).

For now I don't see how this can be fixed easily. I will discuss the
issue with Ulrich. If we aren't able to come up with a solution I will
revert my patch :(
Comment 7 Andrew Pinski 2005-11-09 12:01:04 UTC
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00389.html
Comment 8 Andrew Pinski 2005-11-09 12:02:57 UTC
Note your testcase will fail on every target except for s390:
/* { dg-do compile } */
/* { dg-options "-O1 -mpacked-stack" } */
Comment 9 Andreas Krebbel 2005-11-09 12:18:13 UTC
Ups sorry. I've fixed that now.