The Intel compiler people say:
---
I think callers need to assume that return value is in %al and that
the upper bits of %eax are undefined. If the caller needs a 32-bit
sign- or zero-extended value, it needs to do the extend itself. I
believe GCC, ICC, and MSVC all behave this way.
Given that, it shouldn't matter how the callee handles the upper
bits. It should do whatever is most convenient.
---
So Richard's change is OK as far as x86 backend is concerned.
H.J.
On Jul 24, 8:04 am, Michael Matz <m...@suse.de> wrote:
> Hi,
> On Tue, 24 Jul 2007, hong...@gmail.com wrote:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
> > it seems that ia32 psABI doesn't specify how an integer return value
> > should be extended. For
> > example,
> > signed char
> > return_sc (signed char *sc)
> > {
> > return *sc;
> > }
> > The return value is in eax. Should it be sign extended or zero
> > extended?
> I actually think it shouldn't matter. The caller should only rely on the
> parts of %eax which are covered by the return type.
> So problems can only arise if the caller for some reason doesn't know the
> exact return type (like in the bugreport the ffi library, which simply
> assumes that the return type is ffi_arg). If we want to define something
> for that case (I think outside the C standard, but the ABI doesn't need to
> confine itself to only valid programs), then we can't specify either sign
> or zero extension exclusively, as the extension needs to be value
> preserving.
> Hence I think we can only say that before returning, %eax should be sign
> extended when the actual return type was a signed one, or zero extended if
> not. I don't think we should go that route, though.
> Ciao,
> Michael.
