public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/33545]  New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
@ 2007-09-24 17:07 roger at eyesopen dot com
  2007-09-26 19:08 ` [Bug target/33545] " pinskia at gcc dot gnu dot org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: roger at eyesopen dot com @ 2007-09-24 17:07 UTC (permalink / raw)
  To: gcc-bugs

I just tried compiling mainline on my dusty alphaev67-dec-osf5.1 and discovered
that recent RTL CFG changes have broken the way that exceptions are implemented
on alpha/Tru64.  Natively, this is seen with "configure" and "make bootstrap"
as a breakage configuring libstdc++-v3 where the "exception model" can't be
detected in configure.

The underlying cause is that exceptions seem to be now be fundamentally broken
on this target.  The simple source file:

struct S { ~S(); };
void bar();
void foo()
{
  S s;
  bar();
}

triggers the following ICE:

conf.C: In function 'void foo()':
conf.C:7: error: end insn 27 for block 7 not found in the insn stream
conf.C:7: error: head insn 24 for block 7 not found in the insn stream
conf.C:7: internal compiler error: Segmentation fault


The problem is reproduceable with a cross-compiler (for example from
x86_64-linux) which is configured as "configure --target=alphaev67-dec-osf5.1"
followed by "make".  The build fails attempting to build mips-tfile, but not
before creating a suitable "cc1plus" which can be used to demonstrate the
problem/logic error.

The underlying cause appears to be associated with the alpha backend's use of
the middle-end RTL function "emit_insn_at_entry".  Using grep it appears
"alpha" is the only backend that uses this function, and I suspect recent
changes to it's implementation (Honza?) are responsible for the breakage.

The flow of events is that in the rest_of_handle_eh pass,
expect.c:finish_eh_generation calls gen_exception_receiver.  In alpha.md,
the define_expand for "exception_receiver" makes use of the function
"alpha_gp_save_rtx" when TARGET_LD_BUGGY_LDGP is defined (as on Tru64 with the
native ld).  The implementation of alpha_gp_save_rtx in alpha/alpha.c creates a
memory slot (with assign_stack_local) and the generates some RTL to initialize
this which it tries to insert at the start of the function using
"emit_insn_at_entry".

The logic error is that emit_insn_at_entry as currently implemented in cfgrtl.c
uses insert_insn_on_edge and commit_edge_insertions.  This occurs during RTL
expansion when some of the basic blocks are not yet fully constructed, hence
the expected invariants are not correctly satisfied leading to the errors and
the segmentation fault.

The only other caller of emit_insn_at_entry appears to be integrate.c's
emit_initial_value_sets.  However, I'm guessing that because this doesn't
occur during RTL expansion, there's no problem with using
commit_edge_insertions.

I'm not sure what the correct way to fix this is.  I'd like to say that this is
a middle-end problem with the change in semantics/implementation of
emit_insn_at_entry causing a regression.  However, because it's only the alpha
that's misbehaving it's probably more appropriate to classify this as a target
bug, and get Jan/RTH or someone familiar with how this should work to correct
alpha.c's alpha_gp_save_rtx.  One approach might be to always emit the memory
write in the function prologue, and rely on later RTL passes to eliminate the
dead store and reclaim the unused stack slot from the function's frame.

I'm happy to test (and approve) patches for folks who don't have access to this
hardware.


-- 
           Summary: [4.3 regression] Bootstrap failure/broken exceptions on
                    alpha/Tru64
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: roger at eyesopen dot com
GCC target triplet: alphaev67-dec-osf5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
  2007-09-24 17:07 [Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64 roger at eyesopen dot com
@ 2007-09-26 19:08 ` pinskia at gcc dot gnu dot org
  2007-10-10 18:02 ` mmitchel at gcc dot gnu dot org
  2007-10-13  4:14 ` roger at eyesopen dot com
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-09-26 19:08 UTC (permalink / raw)
  To: gcc-bugs



-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
  2007-09-24 17:07 [Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64 roger at eyesopen dot com
  2007-09-26 19:08 ` [Bug target/33545] " pinskia at gcc dot gnu dot org
@ 2007-10-10 18:02 ` mmitchel at gcc dot gnu dot org
  2007-10-13  4:14 ` roger at eyesopen dot com
  2 siblings, 0 replies; 4+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2007-10-10 18:02 UTC (permalink / raw)
  To: gcc-bugs



-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
  2007-09-24 17:07 [Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64 roger at eyesopen dot com
  2007-09-26 19:08 ` [Bug target/33545] " pinskia at gcc dot gnu dot org
  2007-10-10 18:02 ` mmitchel at gcc dot gnu dot org
@ 2007-10-13  4:14 ` roger at eyesopen dot com
  2 siblings, 0 replies; 4+ messages in thread
From: roger at eyesopen dot com @ 2007-10-13  4:14 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from roger at eyesopen dot com  2007-10-13 04:14 -------
Many thanks to Eric Botcazou!  It turns out that this bug was a duplicate
of PR target/32325.  I can confirm that with Eric's fix, and once I'd committed
my libstdc++ patch for the EOVERFLOW issue (mentioned by Eric in PR23225's
comment #6), and Alex's SRA fixes stop miscompiling mips-tfile, that I can once
again
bootstrap mainline on alphaev67-dec-osf5.1!

Thanks again to Eric for a speedy fix.  I'm sorry that this was a dupe, and
that
it took a while for mainline to stablize to the point that I could confirm the
problem is resolved.


*** This bug has been marked as a duplicate of 32325 ***


-- 

roger at eyesopen dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-10-13  4:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-24 17:07 [Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64 roger at eyesopen dot com
2007-09-26 19:08 ` [Bug target/33545] " pinskia at gcc dot gnu dot org
2007-10-10 18:02 ` mmitchel at gcc dot gnu dot org
2007-10-13  4:14 ` roger at eyesopen dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).