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
