Re: [PATCH][C/C++] Do not promote return arguments

[Richard Guenther <rguenther at suse dot de>]

On Mon, 6 Aug 2007, Ian Lance Taylor wrote:

> Andrew Haley <aph-gcc@littlepinkcloud.COM> writes:
> 
> > Ian Lance Taylor writes:
> >  > Richard Guenther <rguenther@suse.de> writes:
> >  > 
> >  > > 2007-07-05  Richard Guenther  <rguenther@suse.de>
> >  > > 
> >  > > 	cp/
> >  > > 	* decl.c (start_preparsed_function): Do not promote return type.
> >  > > 
> >  > > 	* c-decl.c (start_function): Do not promote return type.
> >  > 
> >  > This is OK.
> >  > 
> >  > Thanks.
> >  
> > This is an externally visible change that causes return values not to
> > be zero- or sign-extended.  This breaks code.  I don't think this
> > should be done.
> > 
> > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843 for more discussion.
> 
> It's a struggle for me to imagine valid C/C++ code which is broken by
> this change.  The PR refers to libffi code, and libffi is obviously
> implementation dependent.

Right.

> Andrew, can you show any examples of valid C/C++ code which this
> breaks?
> 
> That said, Richi, what is the advantage of this patch?  Should we
> avoid disturbing the status quo?

The advantage is less IL created (so memory and compile-time savings)
and the possibility to generate tail/sibling calls for return types 
smaller than int (notably bool in C++).  If we promote at the tree
level then the tree level sibcall optimizer finds mismatched types
for the return.

Note that as to breaking the ABI for assembly code interfacing we
have the statement from the intel folks that the upper halves of %eax
are undefined (so we would not need to do any extension at all) and
the fact that frontends other than C or C++ already always do
zero extension (I checked with a fortran example).

So, if we want to do consistent sign/zero extension for sigend/unsigned
return values we should do so with a backend fix.  But I would prefer
to omit _any_ extension there instead as we seem to be allowed.

As to what libffi should do I have no strong opinion, though I think
it should match the stated ABI and not decide on its own and do
sign/zero extension.  After all it should match both C and Fortran
behavior (which is inconsistent before the patch), no?

Richard.