[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #21 from danglin at gcc dot gnu dot org 2007-06-30 15:20 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02152.html -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #20 from tbm at cyrius dot com 2007-06-21 08:53 --- It's interesting that you mention problems with va_list and prologues because I have such problems on IA64 too since the df merge. I've no idea if they're related but maybe you want to check them out: Error: .prologue within prologue: PR32338 Segfault after rejecting bogus assembler / va_list: PR32370 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-21 02:56 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* Created an attachment (id=13738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738action=view) Patch under test With this patch hppa-unknown-linux-gnu bootstraps, although test results are poor. I'm still having problems with hppa64. This looks like it may be a va_list problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged). Calls clobber r2.
Dave
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
This is an update. Since the dataflow merge I've been unable to
find a way to handle generation of the prologue/epilogue/return insns
that works on all hppa targets. However, debugging time has been
limited.
I had one successful build on hppa2.0w-hp-hpux11.11. However,
I haven't had a successful build on hppa64-hp-hpux11.11 or
hppa-unknown-linux-gnu. The hppa64 problem is PR 32398.
The linux problem is wierd. In stage2, I get the following
failure:
/bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo
../../sinf
o.h
make[3]: *** [ada/sinfo.h] Error 139
The above fault is a stack overflow. The problem is wierd in the sense
that the error doesn't occur when I run ./xsinfo ../../sinfo.h from
an interactive shell. It only occurs when the command is run by make.
Increasing the stack limit didn't help. This suggests a problem with
the environment passed to xsinfo.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #15 from hjl at lucon dot org 2007-06-19 20:10 --- (In reply to comment #14) The linux problem is wierd. In stage2, I get the following failure: /bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo ../../sinf o.h make[3]: *** [ada/sinfo.h] Error 139 The above fault is a stack overflow. The problem is wierd in the sense that the error doesn't occur when I run ./xsinfo ../../sinfo.h from an interactive shell. It only occurs when the command is run by make. Increasing the stack limit didn't help. This suggests a problem with the environment passed to xsinfo. make may change stack limit. You can write a simple Makefile to check the real stack limit of processes spawned by make. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19 20:39 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* make may change stack limit. You are right. Make bumps the soft limit to unlimited when the hard limit is unlimited. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #17 from danglin at gcc dot gnu dot org 2007-06-19 23:30 --- Created an attachment (id=13738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738action=view) Patch under test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #18 from danglin at gcc dot gnu dot org 2007-06-19 23:32
---
The stack overflow takes some time and I was able to attach gdb:
0x402a6c58 in read_encoded_value_with_base (encoding=11 '\v', base=0,
p=0x60384 , val=0xc019ea8c) at ../../../gcc/libgcc/../gcc/unwind-pe.h:200
200 ../../../gcc/libgcc/../gcc/unwind-pe.h: No such file or directory.
in ../../../gcc/libgcc/../gcc/unwind-pe.h
(gdb) bt
#0 0x402a6c58 in read_encoded_value_with_base (encoding=11 '\v', base=0,
p=0x60384 , val=0xc019ea8c) at ../../../gcc/libgcc/../gcc/unwind-pe.h:200
#1 0x402a70ac in linear_search_fdes (ob=0xc019ea14, this_fde=0x60378,
pc=0x2546b) at ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:812
#2 0x402a79b4 in _Unwind_IteratePhdrCallback (info=value optimized out,
size=value optimized out, ptr=0xc019e8cc)
at ../../../gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:389
#3 0x4025b3c8 in dl_iterate_phdr () from /lib/libc.so.6
#4 0x402a8f70 in _Unwind_Find_FDE (pc=0x2546b, bases=0xc019e3a4)
at ../../../gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:420
#5 0x402a42b0 in uw_frame_state_for (context=0xc019e230, fs=0xc019e418)
at ../../../gcc/libgcc/../gcc/unwind-dw2.c:1121
#6 0x402a611c in _Unwind_RaiseException (exc=0x42ac3a88)
at ../../../gcc/libgcc/../gcc/unwind.inc:103
#7 0x0001da88 in ada.exceptions.exception_propagation.propagate_exception (
from_signal_handler=value optimized out) at a-exexpr.adb:584
#8 0x0001dac8 in ada.exceptions.process_raise_exception (
e=value optimized out, from_signal_handler=false) at a-except.adb:776
#9 0x0001db28 in __gnat_raise_nodefer_with_msg (e=0xb) at a-except.adb:829
#10 0x0001e208 in __gnat_raise_exception (e=0x0,
message=value optimized out) at a-except.adb:859
#11 0x00027fec in ada.text_io.get_line (file=0x74e20, item=
{P_ARRAY = 0x0, P_BOUNDS = 0x0}) at a-textio.adb:630
---Type return to continue, or q return to quit---
#12 0x0002546c in ada.strings.unbounded.text_io.get_line (file=0x74e20)
at a-suteio.adb:72
#13 0x0001b540 in xsinfo__getline___832 ()
#14 0x0001ad7c in _ada_xsinfo ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-15
20:05 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged). Calls clobber r2.
Dave
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
Ok, I've found the problem. The code that outputs trivial returns
in function.c has changed and just outputs the return when optimize
and HAVE_RETURN are true. As a result, we are generating trivial
returns in cases when we shouldn't.
I think the solution is to rename the return pattern and let
the pa epilogue expander control the show. This is what I currently
have:
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 125747)
+++ config/pa/pa.md (working copy)
@@ -7345,11 +7345,11 @@
;; This can only be used in a leaf function, so we do
;; not need to use the PIC register when generating PIC code.
-(define_insn return
+(define_insn trivial_return
[(return)
(use (reg:SI 2))
(const_int 0)]
- hppa_can_use_return_insn_p ()
+
*
{
if (TARGET_PA_20)
@@ -7409,7 +7409,7 @@
/* Try to use the trivial return first. Else use the full
epilogue. */
if (hppa_can_use_return_insn_p ())
-emit_jump_insn (gen_return ());
+emit_jump_insn (gen_trivial_return ());
else
{
rtx x;
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 125747)
+++ config/pa/pa.c (working copy)
@@ -47,6 +47,7 @@
#include tm_p.h
#include target.h
#include target-def.h
+#include df.h
/* Return nonzero if there is a bypass for the output of
OUT_INSN and the fp store IN_INSN. */
@@ -4413,9 +4414,9 @@
hppa_can_use_return_insn_p (void)
{
return (reload_completed
- (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- ! df_regs_ever_live_p (2)
- ! frame_pointer_needed);
+ DF_REG_DEF_COUNT (2) == 0
+ !frame_pointer_needed
+ (compute_frame_size (get_frame_size (), 0) ? 0 : 1));
}
void
The code still seems to be generating trivial returns. Full bootstrap
is in progress.
If this works, there's probably some minor cleanups that can be made.
hppa_can_use_return_insn_p() is only called by the epilogue expander
and it may be possible to move it there. I also think we can do away
with one of trivial_return and return_internal in pa.md.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-14
21:05 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
Thanks, I'll give it a try.
I had tried using current_function_is_leaf. However, it's not working.
It seems to work for some simple test cases but a trivial return is still
being generated in at least one situation where a non trivial return
is needed. I haven't had time to debug what's wrong.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13 13:28 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* It's my turn to ask: so what information does hppa_can_use_return_p need to make the decision ? We need to know that the return pointer (r2) is not used and that the function is a leaf function (i.e., that the incoming value in r2 is unchanged). Calls clobber r2. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #11 from spark at gcc dot gnu dot org 2007-06-14 03:53 ---
(In reply to comment #10)
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
It's my turn to ask: so what information does hppa_can_use_return_p
need to make the decision ?
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged). Calls clobber r2.
Dave
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-12 21:43 ---
This patch should fix the bootstrap. I was in the process of running some
regtests when gsyprf11 got reset.
diff -r f78a38a8334b gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cThu May 31 11:43:34 2007 -0700
+++ b/gcc/config/pa/pa.cTue Jun 05 09:36:50 2007 -0700
@@ -47,6 +47,7 @@ Boston, MA 02110-1301, USA. */
#include tm_p.h
#include target.h
#include target-def.h
+#include df.h
/* Return nonzero if there is a bypass for the output of
OUT_INSN and the fp store IN_INSN. */
@@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- ! df_regs_ever_live_p (2)
+ df_hard_reg_used_count (2) == 1
! frame_pointer_needed);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-12
22:59 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
@@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- ! df_regs_ever_live_p (2)
+ df_hard_reg_used_count (2) == 1
! frame_pointer_needed);
}
Don't understand difference between df_regs_ever_live_p and
f-hard_regs_live_count, and why you are checking for a count of 1.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-12 23:07 ---
(In reply to comment #5)
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
@@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- ! df_regs_ever_live_p (2)
+ df_hard_reg_used_count (2) == 1
! frame_pointer_needed);
}
Don't understand difference between df_regs_ever_live_p and
f-hard_regs_live_count, and why you are checking for a count of 1.
hppa_can_use_return_insn_p() is called
from return insn pattern in pa.md.
The pattern looks:
(define_insn return
[(return)
(use (reg:SI 2))
(const_int 0)]
hppa_can_use_return_insn_p ()
*
i.e. there's a use of reg 2.
Before dataflow branch got merged, regs_ever_live(2) was not true
for reg 2, even though it is used at the return (hence it's live
throughout the function body) - unless there's some other use
within the function.
Now, with df, we always have the correct and precise regs_ever_live.
Since the condition hppa_can_use_return_p() is checking
is really that there are no other insn that uses reg 2
AND since we know the pattern has a use of reg 2,
checking the number of use count to be 1
checks effectively the same assertion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-12 23:30 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* hppa_can_use_return_insn_p() is called from return insn pattern in pa.md. The pattern looks: (define_insn return [(return) (use (reg:SI 2)) (const_int 0)] hppa_can_use_return_insn_p () * i.e. there's a use of reg 2. Before dataflow branch got merged, regs_ever_live(2) was not true for reg 2, even though it is used at the return (hence it's live throughout the function body) - unless there's some other use within the function. Now, with df, we always have the correct and precise regs_ever_live. Since the condition hppa_can_use_return_p() is checking is really that there are no other insn that uses reg 2 AND since we know the pattern has a use of reg 2, checking the number of use count to be 1 checks effectively the same assertion. Thanks for the detailed explanation. I don't think the change is correct. The problem is the epilogue expander also calls hppa_can_use_return_p(). It's not going to be true before before the simple return is emitted. As a result, we will never emit a trivial return. I think the solution is to remove this check from the insn definition in pa.md and change the check in hppa_can_use_return_insn_p() to ! df_hard_reg_used_p(). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13 03:45 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* I think the solution is to remove this check from the insn definition in pa.md and change the check in hppa_can_use_return_insn_p() to ! df_hard_reg_used_p(). This doesn't work. The problem seems to be that df_regs_ever_live (2) doesn't provide an indication that a function isn't a leaf function anymore. Calls clobber register r2 but they don't us it. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #9 from spark at gcc dot gnu dot org 2007-06-13 03:48 --- (In reply to comment #8) Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* I think the solution is to remove this check from the insn definition in pa.md and change the check in hppa_can_use_return_insn_p() to ! df_hard_reg_used_p(). This doesn't work. The problem seems to be that df_regs_ever_live (2) doesn't provide an indication that a function isn't a leaf function anymore. Calls clobber register r2 but they don't us it. It's my turn to ask: so what information does hppa_can_use_return_p need to make the decision ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 00:44 --- This was caused by the Dataflow merge, S. Park is on the trail of fixing this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org Component|regression |rtl-optimization Keywords||build, ice-on-valid-code Summary|Bootstrap failure in stage1 |[4.3 Regression] Bootstrap |on hppa*-*-*|failure in stage1 on hppa*- ||*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
-- spark at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 01:01:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-12 01:14 --- This is a one-liner but I can't access the machine holding the patch now (gsyprf11 on HP's test cluster) and I can't remember the line :( -- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 01:01:30 |2007-06-12 01:14:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-12 01:38 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* --- Comment #2 from spark at gcc dot gnu dot org 2007-06-12 01:14 --- This is a one-liner but I can't access the machine holding the patch now (gsyprf11 on HP's test cluster) and I can't remember the line :( Ok, gsyprf11 is being updated at the moment. pa.c needs to include df.h. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
