This is the mail archive of the gcc@gcc.gnu.org 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: [RFC] PR61300 K&R incoming args

From: Florian Weimer <fweimer at redhat dot com>
To: gcc at gcc dot gnu dot org
Date: Mon, 02 Jun 2014 12:00:41 +0200
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>

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? I think I remember tracking down abug which was related to a lack of float -> double promotion because thecall was prototyped, and the old-style function definition wasn't. Thiswould have been on, ugh, SPARC. I think this happened only in certaincases (float arguments, probably).

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


--
Florian Weimer / Red Hat Product Security Team

Follow-Ups:
- Re: [RFC] PR61300 K&R incoming args
  - From: Alan Modra
- Re: [RFC] PR61300 K&R incoming args
  - From: Joseph S. Myers

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