ABI compatibility regression: Return values on x86

[Andrew Haley]

H.J. Lu writes:
 > On Tue, Jan 08, 2008 at 01:57:50PM +0000, Andrew Haley wrote:
 > > H.J. Lu writes:
 > >  > On Mon, Jan 07, 2008 at 06:32:08PM +0000, Andrew Haley wrote:
 > >  > > 
 > >  > > So, what now?  Can we even agree about what the psABI actually says
 > >  > > about sign-extending result values?  Was what we did before correct,
 > >  > > or what we do now?  I don't believe that it doesn't matter.
 > >  > 
 > >  > You can follow up with this thread in ia32 psABI discussion group:
 > >  > 
 > >  > http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269
 > > 
 > > Thanks for the reference.  The attitude there looks surprisingly
 > > complacent, but if Intel and gcc x86 maintainers agree that it doesn't
 > > matter I suppose I'll have to defer to the weight of opinion.
 > > 
 > 
 > My understanding is either way is ia32 psABI compliant. If the
 > caller code generated by gcc is ia32 psABI compliant, that is
 > 
 > ---
 > callers need to assume that return value is in %al/%ax 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.
 > ---
 > 
 > it shouldn't be a problem.

Sure, but it doesn't say "callers need to assume ... are undefined" in
the psABI; AFAICS the Intel engineers just made that up.  I suppose
you could argue that if it isn't explicitly stated there's no
guarantee, but I didn't read it that way.  The core problem is that
the psABI is very badly worded.  

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903