How should integer return value should be extended?

[hon...@gmail.com]

From

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? What do other x86
compilers do?

[Michael Matz]

Hi,

On Tue, 24 Jul 2007, hon...@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.

[hon...@gmail.com]

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,
>