Re: Fix PR middle-end/14988

[Laurent GUERBY <laurent at guerby dot net>]

Is there any reason not to commit this patch to mainline? I've
been using it on x86-linux and powerpc-darwin without problems
for a while, and this is silent wrong code generation.

Laurent

On Sat, 2004-04-24 at 14:16, Roger Sayle wrote:
> On Sat, 24 Apr 2004, Eric Botcazou wrote:
> > > If you test this on another platform (or two) without any problems, then
> > > this is OK for mainline.  Perhaps both a FRAME_GROWS_DOWNWARD and a
> > > FRAME_GROWS_UPWARD target?
> >
> > I'm not sure I can test GCC head with FRAME_GROWS_UPWARD.  What mainstream
> > platforms have F_G_U?
> 
> It looks like i386, sparc and arm define FRAME_GROWS_DOWNWARD and alpha,
> pa, ia64, mips and rs6000 don't.  You shouldn't have a problem, I'm sure
> you have access to atleast two from each category :)
> 
> 
> > > From your analysis, the placement of CONCATs on the stack clearly needs to
> > > be fixed, and although your patch is better than what was there before, the
> > > expectation that the alignment and layout of the CONCAT will be the same as
> > > the sum of its individual components makes me nervous.
> >
> > Isn't that the semantics of a CONCAT?  But I'm not 100% sure either.
> 
> Hypothetically, one approach might be to disable this use of CONCAT
> when this isn't the case.  As you point out, targets with special
> complex number support/requirements will place this variable in an
> ?Cmode pseudo rather than use CONCAT.
> 
> Another preferrable strategy might be to try placing the ?Cmode variable
> in the stack, requesting a single suitable stack slot to contain both
> components.  This might avoid problems that might arise when we implement
> stack slot optimization/pseudos (like those discussed at last year's GCC
> conference).   We might have no guarantees that these two stack slots will
> be kept together during optimization or inlining, but we can allocate one
> larger slot, and then dereference into that.
> 
> Again this needn't affect your patch, I'm just thinking out loud about
> different approaches to cleaning up some of this ugliness, longer term.
> 
> 
> > > However, keeping the two components of a CONCAT sequential in memory is
> > > clearly an improvement, but I suspect that there may also be additional
> > > bugs lurking in this code.  Perhaps someone will convince me I've nothing
> > > to worry about.
> >
> > Yes, I'm also under the impression that the patch (provided that the
> > removal of promoted_mode is correct) can't hurt.
> 
> Agreed.  Testing on one or two more mainline platforms should provide the
> experimental/empirical evidence that using GET_MODE is indeed safe.
> 
> Roger
> --
> 
>