Hi,
since it came up on IRC again, and on the pcc-list, but I don’t have
the original list of results handy… here’s a posting, for the archives:
results of division and modulo of the most negative integer and -1
across Debian and Debian-Ports architectures (OS doesn’t matter).
I don’t have access to hppa at the moment.
alpha ok
armel ok
armhf ok
ia64 ok
mips ok
mipsel ok
s390x ok
sh4 ok
m68k no -2147483648 -1 -2147483648 32
powerpc no -2147483648 -1 0 -2147483648
ppc64 no -2147483648 -1 0 -2147483648
powerpcspe no -2147483648 -1 2147483647 -1
sparc no -2147483648 -1 2147483647 -1
sparc64 no -2147483648 -1 2147483647 -1
amd64 SIGFPE
i386 SIGFPE
x32 SIGFPE
s390 SIGFPE
The numbers are: operand1 operand2 divresult modresult
Expected values: -2147483648 -1 -2147483648 0
Fun facts:
• amd64, i386, x32 are the same CPU architecture, basically
• s390 and s390x aren’t (31-bit vs. 64-bit, not a typo the 31),
but ARE THE SAME MACHINE (hardware, real bare metal)!!!
• m68k gets the div right but not the modulo
• Interesting how RISC machines have similar/close bugs… at
least the ones with the most ugly asm syntax *ever*
• powerpc and ppc64 (same) swap division and modulo results
• powerpcspe differs from powerpc, why precisely? the only
difference in the CPU architecture is that powerpcspe does
not come with any FPU at all (as seen by e.g. klibc diffs)
• IA64 is ok, why precisely, dear Intel? You seem to think
SIGFPE is a good thing to throw in that situation, earlier.
• While ISO C, and thus POSIX, allows it, no architecture
compiled this to code running system("rm -rf ~ /"); to
fully exploit Undefined Behaviour™. Or at least, none of
that were noticed. I’d not say it’s beyond GCC to do so…
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
