[Bug c/32843] [4.3 Regression] : libffi.call/return_sc.c

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #1 from rguenth at gcc dot gnu dot org  2007-07-24 10:11 -------
The problem seems to be a backend one(?).  What happens is that for

signed char return_sc (signed char sc)
{
  return sc;
}

the return value is now zero-extended instead of sign-extended (the sign
extension was done in the C frontend code).  The C standard in 6.8.6.4
specifies that for the return statement _only_ if the expression has
a different type from the return type of the function then
'the value is converted as if by assignment to an object having the return
type of the function'.  Which reading either way doesn't specify whether
the return value is implicitly sign-extended or not (AFAIK whether in
this case the value is sign or zero extended should be / is specified by the
target ABI).

On x86_64 we get

return_sc:
.LFB12:
        movl    %edi, %eax
        ret

...
        movl    $-127, %edi
        call    return_sc

which is why we may be lucky here(?).  On i686 we pass on the stack like

return_sc:
        pushl   %ebp
        movl    %esp, %ebp
        movzbl  8(%ebp), %eax
        popl    %ebp
        ret

...
        movl    $-127, (%esp)
        call    return_sc

explicitly doing zero-extension.  Now the libffi testcase explicitly checks
for sign-extension(!) of the return value:

  for (sc = (signed char) -127;
       sc < (signed char) 127; sc++)
    {
      ffi_call(&cif, FFI_FN(return_sc), &rint, values);
      CHECK(rint == (ffi_arg) sc);
    }

as rint is of type ffi_arg (unsigned long) and sc is signed char.  I wonder
whether this is desired or not.  Andreas?

Micha, how is promotion of the return value specified in the x86 ABI?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de,
                   |                            |andreast at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843