Potential fix for rdar://4658012

[Josh Conner <jconner at apple dot com>]

All -

rdar://4658012 describes a 3.x -> 4.x gcc regression where stack usage
for a particular C++ function increases by 36x.  I have a relatively
simple fix that allows the sharing of stack space for temporaries
generated by the middle-end to hold the result of functions returning
values in memory.  Unfortunately, this approach is reported to have
caused an Ada front-end failure at some point in time on Sparc -- see
thread starting here:

  http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html

So, I went looking for an approach which would fix this in the C++
front-end instead.  However, I discovered that the C front-end has a
similar problem.  e.g., this code:

  typedef struct { char x[1000]; } S;
  S bar (void);
  void foo (void) {
    bar();
    bar();
  }

eats 2000 bytes of stack, instead of 1000.  And so, not changing the
middle-end would mean changing both C and C++ front-ends (note that this
isn't a gcc 3.x regression for C).

So, my question to this fine audience is whether to:

1) apply this patch to positron and move on with my life
2) fight the battle to have this patch applied to FSF (in which case I
   would appreciate support as my track record has been somewhat hidden
   :)
3) just work at fixing the C++ front-end, if possible (which would
   likely meet with acceptance in FSF-land).

Opinions?

Thanks -

Josh

Index: gcc/calls.c
===================================================================
--- gcc/calls.c	(revision 116236)
+++ gcc/calls.c	(working copy)
@@ -1987,7 +1987,6 @@ expand_call (tree exp, rtx target, int i
 	       we would have no way of knowing when to free it.  */
 	    rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);
 
-	    mark_temp_addr_taken (d);
 	    structure_value_addr = XEXP (d, 0);
 	    target = 0;
 	  }