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]

Potential fix for rdar://4658012

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:

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) {

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).


Thanks -


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;

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