PR2975

[Mark Mitchell <mark at codesourcery dot com>]

Richard --

  I've analyzed this failure a bit further.  The problem is that we
are in expand_call, and we decide to try making a sibcall variant of
the call.  In so doing, we find that there are some exception regions
required for the arguments.  That causes us to set sibcall_failure and
bail out.  Unfortunately, this hackery that you can I conspired on a
while back:

      if (pass == 0)
	{
	  /* Undo the fake expand_start_target_temps we did earlier.  If
	     there had been any cleanups created, we've already set
	     sibcall_failure.  */
	  expand_end_target_temps ();
	}

does not work with the new EH scheme because the regions we created
while evaluating the arguments live on.  As a result, we end up with
instructions chained on to the exception_handler_labels list that were
never actually emitted into the instruction stream, which is bogus.

  If the compiler was written in just about any language other than C,
we could throw an exception when we realized we were about to create
an exception region -- before actually creating it -- and get back to
expand_call without doing any damage.  This would be faster, too,
since we wouldn't actually finish generating all the code for the
call.  Needless to say, this is difficult in C, and I don't fancy
sticking setjmp/longjmp all over the place.

  There is a lying comment in sibcall.c that says:

  /* We do not perform these calls when flag_exceptions is true, so this
     is probably a NOP at the current time.  However, we may want to support

But, we do call this function with flag_exceptions.

  I think that the easiest short-term fix is to make the comment tell
the truth: turn off flag_sibling_calls when flag_exceptions is true.
That is OK for GCC 3.0 because it is not a regression from GCC 2.95,
where we did not have the optimization at all.

  Ideally, we would find a way to make this all work better -- but
we've also agreed that sibling call optimization should happen on
trees before we start generating RTL and once we do that all of this
will be a no-op, so I'm not sure it's even worth working hard on this
at the moment.  

  In any case, if you happen to know how to fix this easily, feel free
to do so!  I'll check in my "fix", but you can blow it away and do
something better if you like.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com