From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joern Rennecke To: wilson@cygnus.com (Jim Wilson) Cc: egcs@cygnus.com Subject: Re: Applying FUNCTION_ARG_PADDING to register arguments Date: Fri, 24 Oct 1997 06:41:00 -0000 Message-id: <199710241340.OAA22084@phal.cygnus.co.uk> References: <199710240016.RAA27996@cygnus.com> X-SW-Source: 1997-10/msg01017.html > The first problem is that MUST_PASS_IN_STACK macro in expr.h forces BLKmode > arguments to be passed in the stack if the padding is opposite the natural > direction. This is wrong for irix6. In general, MUST_PASS_IN_STACK should > not be overriding FUNCTION_ARG if FUNCTION_ARG says that something is only > passed in registers. This seems to be a relic left over from GCC 1.x. I > suspect that other ports may also be generating incorrect (non ABI compliant) > code because of this. For instance, I noticed that the standard MIPS ABI > support suffers from this bug also. However, at this point, it seems unsafe to > just delete this macro, because that will introduce unexpected and unnecessary > incompatibilites for targets where gcc is the only compiler. Providing a > way for tm.h files to override MUST_PASS_IN_STACK seems the safest way for > now. For now I have just modified expr.h but I don't think this is safe. Actually this modification would be sufficient to solve the problem I've originally set out to fix. Thus, I think the way to go is to change MUST_PASS_IN_STACK in expr.h not to take padding into account (like in your patch), and make the definition conditional on #ifndef MUST_PASS_IN_STACK. The targets that actually want this double argument passing can then define MUST_PASS_IN_STACK to be identical to the old definition. I have gone through the 35 configurations in egcs, and found that for most of them, this change would have no effect, due to their endianness / definition of FUNCTION_ARG_PADDING, definition of FUNCTION_ARG, or in the case of dsp16xx, BITS_PER_UNIT being ideintical to PARM_BOUNDARY. For the SH, the proposed change would be a bugfix. So that leaves nine targets where I'm not sure if we'd like to define MUST_PASS_IN_STACK in the old way: arc arm h8300 (problem only for TARGET_QUICKCALL, but still...) m32r mips pa pyr romp sparc If we can't resolve the issue for one or more of these targets in a timely manner, we can just put in the old definition of MUST_PASS_IN_STACK into the respective tm.h file, with a comment that it is unknown if that is actually intentional, but kept for backward compatibility.