Re: [PATCH] Alignment fault during function call

[Jeff Law <law at redhat dot com>]

 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.

jeff

ps.  I tried real hard to forget stack slot saving...  I'll probably 
have nightmares tonight.