Le jeudi 17 janvier 2013 01:48:01, Michael Matz a écrit : > Hi, > > > Pointer to integer conversions (and back) are implementation defined, the > only requirement being that if the integer type is (u)intptr_t that a > pointer converted to that one and back to a pointer shall compare equal to > the original pointer. > > So, depending on how the compiler implements this conversion (and > > documents this) one might get different results: > > $ gcc -o long_long long_long.c && ./long_long > > [SNIP gcc warnings] > > -66 -66 -66 -66 -66 -66 > > This is a correct result for ILP32 (i.e. 32bit code). GCC sign extends > pointers when the pointer representation needs fewer bits than the target > type. > > > $ clang -o long_long long_long.c && ./long_long > > -66 -66 -66 -66 4294967230 4294967230 > > And this is also a correct result for 32bit code, when the compiler > defines pointer to integer conversion to be zero-extending when the target > type has more bits than a pointer. IMO sign-extending is more useful, and > as GCC set the precedent a long time ago I would declare clang to at least > have an QoI issue with compatibility with GCC. In other words: tcc has no > bug here.
Thanks a lot for your explaination Michael. There is also the p -= 0x700000000042; assignment which is compiler-specific for C11 (not sure for C99) I think because nothing in the standard say there should be overflow. The compiler can do crazy things with it, as explained in http://lwn.net/Articles/511259/. Ok so no bug on tcc here, good :) > > > Ciao, > Michael. Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
