This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix PR middle-end/14988
- From: Eric Botcazou <ebotcazou at act-europe dot fr>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 24 Apr 2004 08:54:24 +0200
- Subject: Re: Fix PR middle-end/14988
- References: <Pine.LNX.4.44.0404232007080.7753-100000@www.eyesopen.com>
> 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?
> 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.
> Isn't it possible that the CONCAT pair will require more alignment than
> just it's first component? For example, I believe the s390 can store
> both floats of a SCmode value in a single register. I'm unsure, but
> loading this register might require alignment beyond that of SFmode.
Would the SCmode value be given a CONCAT in the first place in that case?
> 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.
--
Eric Botcazou