Sure, but then you deserve what you get...
Sure, but then you deserve what you get...
Posted May 24, 2011 23:14 UTC (Tue) by iabervon (subscriber, #722)In reply to: Sure, but then you deserve what you get... by marcH
Parent article: What Every C Programmer Should Know About Undefined Behavior #3/3
Actually, I suspect that gcc actually transforms the condition to "val < 0x104030200". How would gcc, a C program, compute the result of a signed overflow without risking crashing? It's more comprehensible as "step 1 assumes that, because there is no signed overflow, the arbitrary-precision value of the expression 0x03020100 + (i*0x04040404) is the value of val; step 2 notices that the condition is always true due to the limited range of the variable."
This also avoids the issue that it would be really hard to determine that "val != 0x04030200" is always true without determining that the code actually hits a signed overflow.
Actually, the first transformed code is probably:
int *value;
int val;
for (val = 0x03020100; val < 0x104030200; val += 0x04040404, value++)
*value = val;
Eliminating "i" is reasonably likely to be huge on x86 come register allocation, so it's a good optimization if it works. And gcc can assume it works because the programmer can't let signed arithmetic overflow. Of course, at this point, it already doesn't work as expected; the second optimization just makes the assembly confusing. The second optimization is really for "if (size >= 0x100000000) return -EINVAL;" where the programmer cares about a 32-bit limit in code that could be built with either 32-bit or 64-bit ints; in some builds it's important, and in all builds it's correct, but the compiler can eliminate it in cases where it doesn't matter.
Posted May 25, 2011 5:12 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
Have you seen this page? Specifically the libraries part? Do you know why GMP, MPFR and MPC are requirements, not options? Actually I think this particular optimization does not use multiprecision arithmetic, but if it's needed in some passes it is available to GCC despite the fact that it's C program. P.S. Note that is you really want "overflow", not "undefined behavior" you can do that and the fact that GCC is a C program does not stop you.
Posted May 25, 2011 5:44 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (3 responses)
Those libraries compute the well-defined results of calculations with large numbers; they don't give the result of signed overflow. They aren't going to help for figuring out the results of running (unoptimized, on the target machine):
because that's a matter of processor architecture, not mathematics. And certainly gcc isn't going to try eliciting the undefined behavior itself and replicating it, because the undefined behavior might be "your compiler crashes processing unreachable code", which the C specification doesn't allow.
Posted May 26, 2011 8:27 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (2 responses)
Of course they can do this; the latter is just one modulus operation away from the former.
> because that's a matter of processor architecture, not mathematics.
Surprise: processors architectures are rooted in arithmetics. All of them, even though they differ with each other.
Posted May 27, 2011 9:45 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (1 responses)
Still not a matter of mathematics: both 1's and 2's compliment are equally correct. The matter is about the choice made by the processor designers, and thus, a matter of processor architecture.
Posted May 27, 2011 14:03 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
GMP or else can help for the latter (of course not for the former).
Have you seen this page?
How would gcc, a C program, compute the result of a signed overflow without risking crashing?
Have you seen this page?
if (MAXINT + 1 == -MAXINT) printf("Wow, 1's complement!\n");
Have you seen this page?
Have you seen this page?
Have you seen this page?