[RFC] PR61300 K&R incoming args

[Alan Modra]

On Mon, Jun 02, 2014 at 12:00:41PM +0200, Florian Weimer wrote:
> On 05/31/2014 08:56 AM, Alan Modra wrote:
> 
> >>It's fine to change ABI when compiling an old-style function
> >>definition for which a prototype exists (relative to the
> >>non-prototype case).  It happens on i386, too.
> >
> >That might be so, but when compiling the function body you must assume
> >the worst case, whatever that might be, at the call site.  For K&R
> >code, our error was to assume the call was unprototyped (which
> >paradoxically is the best case) when compiling the function body.
> 
> Is this really a supported use case?

Of course!  We still have K&R code lying around, as evidenced by the
PR.

>  I think I remember tracking
> down a bug which was related to a lack of float -> double promotion
> because the call was prototyped, and the old-style function
> definition wasn't.  This would have been on, ugh, SPARC.  I think
> this happened only in certain cases (float arguments, probably).

Yes, there are some limitations on parameter types that may be used
with unprototyped functions.

> Does this trigger more often on ppc64 ELFv2, to the extend it
> becomes a quality-of-implementation issue?  I'm pretty sure the
> standards do not require a particular behavior in such cases.

The PR isn't about the sort of parameter mismatch that you seem to be
thinking about.  The code in question is perfectly legal old-style
K&R where there is no float/double or int/long/void * trouble.

-- 
Alan Modra
Australia Development Lab, IBM