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]

Re: Potential fix for rdar://4658012

On 8/26/06, Josh Conner <> wrote:
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

Given that this fixes a quite serious regression and the Ada failure on Sparc was quite vague I would argue to put it in 4.3 and later backport it to 4.2.1 if this problem no longer occurs. Or to put that on the burden of Ada/Sparc completely.


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