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
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
instructio
On 01/24/2013 03:33 PM, Jeffrey Walton wrote:
> On Thu, Jan 24, 2013 at 10:06 AM, Robert Dewar 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 overfl
On Thu, Jan 24, 2013 at 10:06 AM, Robert Dewar 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 resu
[ 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.
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
