Re: Integer Overflow/Wrap and GCC Optimizations
On 1/24/2013 10:02 AM, Jeffrey Walton wrote: What I am not clear about is when an operation is deemed undefined or implementation defined. The compiler is free to assume that no arithmetic operation on signed integers results in overflow. It is allowed to take advantage of such assumptions in generating code (and it does so). You have no right to assume *anything* about the semantics of code that has an integer overflow (let alone make asssumptions about the generated code). This is truly undefined, not implementation defined, and if your program has such an overflow, you cannot assume ANYTHING about the generated code.
Re: Integer Overflow/Wrap and GCC Optimizations
[ gcc-h...@gcc.gnu.org ? ] On Thu, 24 Jan 2013, Jeffrey Walton wrote: Hi All, I have a question on integer overflow and wrap, and GCC optimizations. I have a small library that uses inline assembly to check OV/CY flags for both x86/x64 and ARM. x86/x64 uses FLAGS/EFLAGS, while ARM uses CPSR. Do I have to worry about GCC optimizing out addition, subtractions, etc under any circumstances? It would help to see what kind of code you are worried about. If the addition is done in an inline asm, gcc doesn't know it is an addition and doesn't optimize it. If it is done outside the asm, you don't have any guarantee that once the asm starts the flags are still what you want. Note that using unsigned types would avoid a lot of issues. -- Marc Glisse
Re: Integer Overflow/Wrap and GCC Optimizations
On Thu, Jan 24, 2013 at 10:06 AM, Robert Dewar de...@adacore.com wrote: On 1/24/2013 10:02 AM, Jeffrey Walton wrote: What I am not clear about is when an operation is deemed undefined or implementation defined. The compiler is free to assume that no arithmetic operation on signed integers results in overflow. It is allowed to take advantage of such assumptions in generating code (and it does so). You have no right to assume *anything* about the semantics of code that has an integer overflow (let alone make asssumptions about the generated code). Well, I kind of agree with you. When taking arbitrary inputs, how does one know 'a priori'? In this case, I claim we must perform the operation. Its the result that we can't use under some circumstances (namely, overflow or wrap). This is truly undefined, not implementation defined, and if your program has such an overflow, you cannot assume ANYTHING about the generated code. Signed integers that suffer overflow are operating in undefined behavior territory. Does the C/C++ standard specify what to do in this case? Currently, I believe GCC removes the code rather than performing the operation or failing the compile. Unsigned integers that wrap/carry enjoy implementation defined behavior. The GCC maintainers are free to do what they want with implementation defined. At the moment, GCC handles wrap/carry as expected - they perform the operation. Jeff
Re: Integer Overflow/Wrap and GCC Optimizations
On 01/24/2013 03:33 PM, Jeffrey Walton wrote: On Thu, Jan 24, 2013 at 10:06 AM, Robert Dewar de...@adacore.com wrote: This is truly undefined, not implementation defined, and if your program has such an overflow, you cannot assume ANYTHING about the generated code. Signed integers that suffer overflow are operating in undefined behavior territory. Does the C/C++ standard specify what to do in this case? No. As the saying does, demons might fly out of your nose. Currently, I believe GCC removes the code rather than performing the operation or failing the compile. Unsigned integers that wrap/carry enjoy implementation defined behavior. The GCC maintainers are free to do what they want with implementation defined. No, unsigned integers must wrap around. A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. Andrew.
Re: Integer Overflow/Wrap and GCC Optimizations
On 01/24/2013 04:02 PM, Jeffrey Walton wrote: I have a small library that uses inline assembly to check OV/CY flags for both x86/x64 and ARM. x86/x64 uses FLAGS/EFLAGS, while ARM uses CPSR. Please show some sample code. You can check the flags set by a preceding arithmetic/logical instruction in the *same* asm statement. You cannot use asm statements to access such flags set by other asm statements, or by code emitted by GCC. -- Florian Weimer / Red Hat Product Security Team
Re: Integer Overflow/Wrap and GCC Optimizations
On 1/24/2013 10:33 AM, Jeffrey Walton wrote: In this case, I claim we must perform the operation. Its the result that we can't use under some circumstances (namely, overflow or wrap). You do not have to do the operation if the program has an overflow. The compiler can reason about this, so for example a = b + 1; if (a b) ... The compiler can assume that the test is true, because the only conceivable way it would be false is on an overflow that wraps, but that's undefined. If a is not used other than in this test, the compiler can also eliminate the addition and the assignment
