This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Alignment fault during function call
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Bernd Schmidt <bernds at codesourcery dot com>, Paul Brook <paul at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot cz>
- Date: Thu, 5 Aug 2010 17:58:13 +0200
- Subject: Re: [PATCH] Alignment fault during function call
- References: <email@example.com> <4C5A0525.firstname.lastname@example.org> <4C5A095E.email@example.com>
On Thu, Aug 5, 2010 at 2:44 AM, Jeff Law <firstname.lastname@example.org> wrote:
> ?On 08/04/10 18:26, Bernd Schmidt wrote:
>> The patch looks reasonable, but it also seems like store_one_arg has the
>> same problem. ?Can you pull out the common code into a function?
>> Unfortunately there's a small amount of divergence in this area. ?It's a
>> bit sad that we aren't using store_one_arg for libcalls.
>> The code calculating upper_bound and lower_bound looks different, and I
>> can't figure out at the moment why, so that's probably best kept at the
>> current location. ?The version in store_one_arg goes back to revision
>> 201 by rms, the other one was added by Jeff in r13902, which was so long
>> ago he's probably forgotten why it's done differently.
> IIRC, that was done for the mn102/mn103 ports which I believe were the first
> ports that could emit a libcall sequence (such as mulsi3) in the middle of
> expanding a normal call. ?If arguments to the libcall happened to overlap in
> memory with arguments to the normal call, then the libcall with obviously
> overwrite the arguments that were already set up for the normal call.
>> Another thought is that maybe with tree-ssa, we should just avoid having
>> nested CALL_EXPRs that cause this kind of problem? ?We could probably
>> delete lots of code in calls.c if we decided to do that.
> Unnesting would be good, but I don't think it's sufficient since we have to
> deal with libcalls. ?Now if the function's arguments were guaranteed to be
> regs, SSA_NAMEs or the like, then we'd have a fighting chance of greatly
> simplifying that code.
We shouldn't see any nested calls during expansion (well, unless
you possibly need libcalls for argument setup for aggregates passed
by values). All TER needs now to be performed explicitly (it only
expands TERed expressions next to its single use but doesn't build
large trees automagically anymore).