This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Alignment fault during function call

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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]