Re: Potential fix for rdar://4658012

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 8/26/06, Josh Conner <jconner@apple.com> 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:
>
>   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
>    :)

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.

Richard.