In http://reviews.llvm.org/D9198#162375, @petarj wrote:
> In http://reviews.llvm.org/D9198#162163, @dsanders wrote: > > > > IIRC from a recent discussion, unsigned 32-bit int are represented in a > > > 64-bit register as sign-extended value of the 32-bit value (i.e. bit 31 > > > is copied through the top half). So, the caller has to make sure the > > > value is correctly represented before making a call, right? > > > > > > That's correct in general, all the 32-bit operations sign-extend their > > result to 64-bit. The ABI documentation is trying to match this > > architectural behaviour but that didn't seem to be what was actually > > implemented in gcc. > > > My understanding is that the called function should assume sign-extended > (both signed and unsigned) 32-bit integers as inputs on its entry and > compiler can base decisions on that. One [1] of Strahinja's previous patches > was led by a bug when floating point value was NOT sign-extended but > zero-extended before the call, and that led to an incorrect behaviour in the > called function. For that particular case, GCC was sign-extending the value > before making a call. > > I know this area is not well defined, this is why I brought another example > to take into account before any decision is made. > > [1] http://reviews.llvm.org/D7791 Unfortunately, it's even less well defined in the documentation for softfloat float's. I believe both compilers treat them as if they were 32-bit integers which seems like the sensible thing to do. http://reviews.llvm.org/D9198 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
