This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/33545] New: [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64

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;

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,
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

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

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

           Summary: [4.3 regression] Bootstrap failure/broken exceptions on
           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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]