This is the mail archive of the 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: [PATCH] Fix PR32843, testsuite bug wrt sign/zero-extension of return values

On Fri, 27 Jul 2007, Andrew Haley wrote:

> Andrew Haley writes:
> OK, I've looked and every libffi target except x86 has explicit code
> to do sign extend retvals.  I presume that such code isn't present for
> x86 because hitherto $eax has always been properly sign extended for
> the return type.
> So, are we *absolutely* sure that gcc hasn't broken the ABI?  I can
> certainly imagine some cases where a change like this one (gcc no
> longer sign extends retvals) would break code in interesting ways.

Well, if every other libffi target has explicit sign extension code
then the change (which is to generic code!) if it breaks the ABI shows
that the x86 target machinery is lacking code to do sign extend retvals.

Of course I'd like to see what other language frontends to for returning
signed/unsigned quantities of QImode or HImode on x86.  For example
Fortran does zero extension in 4.2.1 (well, really the backend is -
the frontend simply returns HImode, like mainline now does for C as well
after the change):

        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %eax
        movzwl  (%eax), %eax
        popl    %ebp

function foo(bar)
  integer*2 foo,bar
  foo = bar

if backends other than x86 still sign-extend for QImode returns in C
the it is the x86 backend that needs to be fixed if we decide that
it makes a difference that we need to care about.


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