This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] PR61300 K&R incoming args
- From: Alan Modra <amodra at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 3 Jun 2014 00:17:58 +0930
- Subject: Re: [RFC] PR61300 K&R incoming args
- Authentication-results: sourceware.org; auth=none
- References: <20140526073809 dot GA6679 at bubble dot grove dot modra dot org> <5388DA76 dot 3060103 at redhat dot com> <20140531065625 dot GY6679 at bubble dot grove dot modra dot org> <538C4B49 dot 2080507 at redhat dot com>
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
> 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.
Australia Development Lab, IBM