how to make gcc warn about arithmetic signed overflow

how to make gcc warn about arithmetic signed overflow

[wempwer]

Hello,

I am trying to C learn language on a quite high level. I spend a
couple of days learning about unsigned and signed
arithmetic/conversion overflow, integer promotion and arithmetic
conversion. From what I understand the following snippet causes an
undefined behavior on all platforms:

int ab = 50000;
int bc = 50000;
int r = ab * bc;

In the first and second line we assign 50000 to signed int, nothing
bad happens here because on my computers int is 32 bits long so there
is no overflow. If it was an overflow, it is implementation defined
and would cause wraparound on most platforms. However, in the third
line there is no integer promotion performed because both operands are
already of type int but we have an arithmetic overflow because 50000 *
50000 doesn't fit in 32 bits signed integer. According to the C
standard this is an undefined behavior but again on most platforms it
comes down to wraparound. Value r is printed in printf with %d
specifier as -1794967296 using two's complement mechanism. To my
surprise gcc doesn't print any warnings in the 3rd line. I tried
several options such as -Wall, -Wstrict-overflow=5, -pedantic, -Wextra
but nothing produces a warning. Is it possible for gcc to produce a
warning in such situation?

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 21 September 2013 17:46,  wrote:
> Is it possible for gcc to produce a
> warning in such situation?

If ab and bc are 'const' then G++ will warn:

o.cc: In function ‘int main()’:
o.cc:5:14: warning: integer overflow in expression [-Woverflow]
 int r = ab * bc;
              ^

The C compiler still doesn't warn though, due to different rules for
how constants are handled between C and C++.

Re: how to make gcc warn about arithmetic signed overflow

[Brian Drummond]

On Sat, 2013-09-21 at 18:46 +0200, wempwer@gmail.com wrote:
> int ab = 50000;
> int bc = 50000;
> int r = ab * bc;
> 
> Is it possible for gcc to produce a
> warning in such situation?

Yes, gcc the Gnu Compiler Collection can produce such a warning:

procedure test_ovf is
   ab : integer := 50000;
   bc : integer := 50000;
   r : integer := ab * bc;
begin
   null;
end test_ovf;

gcc -c test_ovf.adb
test_ovf.adb:4:22: warning: value not in range of type
"Standard.Integer"
test_ovf.adb:4:22: warning: "Constraint_Error" will be raised at run
time
However I'm not sure it is allowed to do the same with C. 

- Brian

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 06:24:13PM +0100, Jonathan Wakely wrote:
> On 21 September 2013 17:46,  wrote:
> > Is it possible for gcc to produce a
> > warning in such situation?
> 
> If ab and bc are 'const' then G++ will warn:
> 
> o.cc: In function ‘int main()’:
> o.cc:5:14: warning: integer overflow in expression [-Woverflow]
>  int r = ab * bc;
>               ^
> 
> The C compiler still doesn't warn though, due to different rules for
> how constants are handled between C and C++.

Hmm, I don't know too much about C++ but why would a C++ compiler
produce a warning only if two operands were const? I learned that in C
`const' modifier only means that I promise to the compiler that this
variable will be read-only, its value can be changed using pointers
but the result is undefined and that const != constant expression. So
are the differences in const between C and C++ so much complex or is
it just a compiler that decides to act this way? From what you said, I
believe the differnces are more complex than I thought.

Anyway, do you know how to make gcc warn about this in pure C?
-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 06:37:09PM +0100, Brian Drummond wrote:
> On Sat, 2013-09-21 at 18:46 +0200, wempwer@gmail.com wrote:
> > int ab = 50000;
> > int bc = 50000;
> > int r = ab * bc;
> > 
> > Is it possible for gcc to produce a
> > warning in such situation?
> 
> Yes, gcc the Gnu Compiler Collection can produce such a warning:
> 
> procedure test_ovf is
>    ab : integer := 50000;
>    bc : integer := 50000;
>    r : integer := ab * bc;
> begin
>    null;
> end test_ovf;
> 
> gcc -c test_ovf.adb
> test_ovf.adb:4:22: warning: value not in range of type
> "Standard.Integer"
> test_ovf.adb:4:22: warning: "Constraint_Error" will be raised at run
> time
> However I'm not sure it is allowed to do the same with C. 

Wow, what's the language you use here? It looks like some kind of
Pascal.

Sorry guys for not being 100% clear in this question - I am only
interested in C language.  

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Marc Glisse]

On Sat, 21 Sep 2013, Jonathan Wakely wrote:

> On 21 September 2013 17:46,  wrote:
>> Is it possible for gcc to produce a
>> warning in such situation?
>
> If ab and bc are 'const' then G++ will warn:
>
> o.cc: In function ‘int main()’:
> o.cc:5:14: warning: integer overflow in expression [-Woverflow]
> int r = ab * bc;
>              ^
>
> The C compiler still doesn't warn though, due to different rules for
> how constants are handled between C and C++.

It does warn with -O though... (still only with const)

That's just the compiler not being good enough. I was going to mention 
-fsanitize=undefined for gcc-4.9 for a runtime warning, but it doesn't 
handle this yet, and -ftrapv never really worked.

-- 
Marc Glisse

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 07:53:01PM +0200, Marc Glisse wrote:
> On Sat, 21 Sep 2013, Jonathan Wakely wrote:
> 
> >On 21 September 2013 17:46,  wrote:
> >>Is it possible for gcc to produce a
> >>warning in such situation?
> >
> >If ab and bc are 'const' then G++ will warn:
> >
> >o.cc: In function ‘int main()’:
> >o.cc:5:14: warning: integer overflow in expression [-Woverflow]
> >int r = ab * bc;
> >             ^
> >
> >The C compiler still doesn't warn though, due to different rules for
> >how constants are handled between C and C++.
> 
> It does warn with -O though... (still only with const)
> 
> That's just the compiler not being good enough. I was going to
> mention -fsanitize=undefined for gcc-4.9 for a runtime warning, but
> it doesn't handle this yet, and -ftrapv never really worked.

It tried -O2 and it also worked. However on my system it only said:

warning: integer overflow in expression

How did you get gcc to produce this part:

[-Woverflow]

I use gcc 4.5.2. But when I use gcc like this I also do not get any
warnings:

gcc -Woverflow main.c -o main

I wonder:

1) why -Woverflow appears in your gcc output?
2) why `gcc -Woverflow main.c -o main' does not produce a warning?
3) why does `gcc -O main.c -o main' produce warning in the first place
and why does it do this only when two operands are const?

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 21 September 2013 19:09,  <wempwer@gmail.com> wrote:
>
> It tried -O2 and it also worked. However on my system it only said:
>
> warning: integer overflow in expression
>
> How did you get gcc to produce this part:
>
> [-Woverflow]
>
> I use gcc 4.5.2. But when I use gcc like this I also do not get any
> warnings:
>
> gcc -Woverflow main.c -o main

4.5.2 is quite old now. More recent versions show the warning option
that triggered the warning, that's what the [-Woverflow] part is.

> I wonder:
>
> 1) why -Woverflow appears in your gcc output?

Because it's a recent version.

> 2) why `gcc -Woverflow main.c -o main' does not produce a warning?

Because without optimisation the compiler doesn't do the necessary
analysis to realise that in the multiplication expression it knows the
values.

> 3) why does `gcc -O main.c -o main' produce warning in the first place
> and why does it do this only when two operands are const?

Because the optimiser can track the values of constants (because they
don't change) and see that the values in the multiplication are known.

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 21 September 2013 18:42,  <wempwer@gmail.com> wrote:
>
> Hmm, I don't know too much about C++ but why would a C++ compiler
> produce a warning only if two operands were const? I learned that in C
> `const' modifier only means that I promise to the compiler that this
> variable will be read-only,

So the compiler knows that the values of ab and bc, because they must
always have the values they were initialized with.

If the compiler was smarter it would be able to also warn for
non-const values if it can prove that nothing has modified the
variables since they were initialized.

> its value can be changed using pointers

No, that's not true. You can't change the value of a const object in a
valid program.

> but the result is undefined and that const != constant expression.

In C++ a const of integral type is a constant expression.

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 07:30:02PM +0100, Jonathan Wakely wrote:
> On 21 September 2013 18:42,  <wempwer@gmail.com> wrote:
> >
> > Hmm, I don't know too much about C++ but why would a C++ compiler
> > produce a warning only if two operands were const? I learned that in C
> > `const' modifier only means that I promise to the compiler that this
> > variable will be read-only,
> 
> So the compiler knows that the values of ab and bc, because they must
> always have the values they were initialized with.
> 
> If the compiler was smarter it would be able to also warn for
> non-const values if it can prove that nothing has modified the
> variables since they were initialized.
> 
> > its value can be changed using pointers
> 
> No, that's not true. You can't change the value of a const object in a
> valid program.
> 
> > but the result is undefined and that const != constant expression.

I think I can but it may cause an undefined behavior:

const int bc = 50000;
int *p = &bc;
*p = 10;
printf("Modified const: %d\n", bc); 

10 will be printed.

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 07:27:20PM +0100, Jonathan Wakely wrote:
> On 21 September 2013 19:09,  <wempwer@gmail.com> wrote:
> >
> > It tried -O2 and it also worked. However on my system it only said:
> >
> > warning: integer overflow in expression
> >
> > How did you get gcc to produce this part:
> >
> > [-Woverflow]
> >
> > I use gcc 4.5.2. But when I use gcc like this I also do not get any
> > warnings:
> >
> > gcc -Woverflow main.c -o main
> 
> 4.5.2 is quite old now. More recent versions show the warning option
> that triggered the warning, that's what the [-Woverflow] part is.
> 
> > I wonder:
> >
> > 1) why -Woverflow appears in your gcc output?
> 
> Because it's a recent version.
> 
> > 2) why `gcc -Woverflow main.c -o main' does not produce a warning?
> 
> Because without optimisation the compiler doesn't do the necessary
> analysis to realise that in the multiplication expression it knows the
> values.
> 
> > 3) why does `gcc -O main.c -o main' produce warning in the first place
> > and why does it do this only when two operands are const?
> 
> Because the optimiser can track the values of constants (because they
> don't change) and see that the values in the multiplication are known.

But compiler also knows the operand values even if they are not
constant? These values must be known to produce the multiplication
result. Is this warning produced only when two operands are constant
and optimization is turned on because this is just the way gcc does it
and the warnings could also be produced for non-const operands if a
compiler worked in a different way?

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Jędrzej Dudkiewicz]

>> No, that's not true. You can't change the value of a const object in a
>> valid program.
>
> I think I can but it may cause an undefined behavior:

Note, that Jonathan wrote "in a valid program". Your program is not
valid, as it contains undefined behaviour - you change const int via
pointer to non-const int.

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 09:55:07PM +0200, Jędrzej Dudkiewicz wrote:
> >> No, that's not true. You can't change the value of a const object in a
> >> valid program.
> >
> > I think I can but it may cause an undefined behavior:
> 
> Note, that Jonathan wrote "in a valid program". Your program is not
> valid, as it contains undefined behaviour - you change const int via
> pointer to non-const int.

Is p pointer in my code a pointer to non-const int? It points to bc
int memory address and bc is constant. Does C language bind constness
to an indentifier instead of memory address?

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Jędrzej Dudkiewicz]

>> > I think I can but it may cause an undefined behavior:
>>
>> Note, that Jonathan wrote "in a valid program". Your program is not
>> valid, as it contains undefined behaviour - you change const int via
>> pointer to non-const int.
>
> Is p pointer in my code a pointer to non-const int? It points to bc
> int memory address and bc is constant. Does C language bind constness
> to an indentifier instead of memory address?

Yes. I don't know about your version of gcc, but with 4.8.1 I get:

[jd@megalodon ~]$ cat x.c
int main() {
        const int i = 10;
        int* pc = &i;
        *pc = 1;
        return *pc;
}

[jd@megalodon ~]$ gcc x.c -o x
x.c: In function ‘main’:
x.c:3:12: warning: initialization discards ‘const’ qualifier from
pointer target type [enabled by default]
  int* pc = &i;

Which means that pc doesn't inherit constness of pointed ...memory?
value? I'm not sure how to call it.
-- 
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.

Re: how to make gcc warn about arithmetic signed overflow

[wempwer]

On Sat, Sep 21, 2013 at 10:52:22PM +0200, Jędrzej Dudkiewicz wrote:
> >> > I think I can but it may cause an undefined behavior:
> >>
> >> Note, that Jonathan wrote "in a valid program". Your program is not
> >> valid, as it contains undefined behaviour - you change const int via
> >> pointer to non-const int.
> >
> > Is p pointer in my code a pointer to non-const int? It points to bc
> > int memory address and bc is constant. Does C language bind constness
> > to an indentifier instead of memory address?
> 
> Yes. I don't know about your version of gcc, but with 4.8.1 I get:
> 
> [jd@megalodon ~]$ cat x.c
> int main() {
>         const int i = 10;
>         int* pc = &i;
>         *pc = 1;
>         return *pc;
> }
> 
> [jd@megalodon ~]$ gcc x.c -o x
> x.c: In function ‘main’:
> x.c:3:12: warning: initialization discards ‘const’ qualifier from
> pointer target type [enabled by default]
>   int* pc = &i;
> 
> Which means that pc doesn't inherit constness of pointed ...memory?
> value? I'm not sure how to call it.

Oh, my gcc shows me the same warning. Thank you for clarification.

-- 
<wempwer@gmail.com>

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 21 September 2013 20:33,  <wempwer@gmail.com> wrote:
>
> But compiler also knows the operand values even if they are not
> constant? These values must be known to produce the multiplication
> result.

No, in general the processor produces the result of multiplying two
variables, not the compiler.


> Is this warning produced only when two operands are constant
> and optimization is turned on because this is just the way gcc does it
> and the warnings could also be produced for non-const operands if a
> compiler worked in a different way?

Yes, Marc and I have both said that, please read our replies more carefully.

Re: how to make gcc warn about arithmetic signed overflow

[James K. Lowden]

On Sat, 21 Sep 2013 19:30:02 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> > its value can be changed using pointers
> 
> No, that's not true. You can't change the value of a const object in a
> valid program.

I don't know if we're talking C or C++ at this point, but const_cast
will surely let you change the value of a const object without treading
into undefined behavior.  

Regarding the OP's query

> > int r = ab * bc;

although the provided example is simple enough, it's the compiler's
job is to generate object code, not to do static analysis.  

Even if the values are const, in the general case they could be
modified by another module or another thread.  The compiler simply
doesn't have enough information to warn of every runtime overflow.  

--jkl

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 23 September 2013 05:03, James K. Lowden wrote:
> On Sat, 21 Sep 2013 19:30:02 +0100
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>> > its value can be changed using pointers
>>
>> No, that's not true. You can't change the value of a const object in a
>> valid program.
>
> I don't know if we're talking C or C++ at this point, but const_cast
> will surely let you change the value of a const object without treading
> into undefined behavior.

No, it surely won't!

If an object is defined as const in the first place then it is
undefined behaviour to change it.

1.9 [intro.execution]/4:
"Certain other operations are described in this International Standard
as undefined (for example, the effect of attempting to modify a const
object)."

5.2.11 [expr.const.cast]/7:
"[ Note: Depending on the type of the object, a write operation
through the pointer, lvalue or pointer
to data member resulting from a const_cast that casts away a
const-qualifier may produce undefined
behavior (7.1.6.1). — end note ]"

And the definitive reference, 7.1.6.1 [dcl.type.cv]/4:
"Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during its lifetime
(3.8) results in undefined behavior."

You can't even do it by destroying an a const objehct and recreating a
new object at the same address:

3.8 [basic.life]/9
"Creating a new object at the storage location that a const object
with static, thread, or automatic storage duration occupies or, at the
storage location that such a const object used to occupy before its
lifetime ended results in undefined behavior."


> Regarding the OP's query
>
>> > int r = ab * bc;
>
> although the provided example is simple enough, it's the compiler's
> job is to generate object code, not to do static analysis.
>
> Even if the values are const, in the general case they could be
> modified by another module or another thread.  The compiler simply
> doesn't have enough information to warn of every runtime overflow.

Unless they're automatic variables and the compiler can determine
their addresses haven't been taken or haven't escaped the current
scope. Escape analysis should be able to do that, ideally.

Re: how to make gcc warn about arithmetic signed overflow

[David Brown]

On 21/09/13 21:33, wempwer@gmail.com wrote:
> On Sat, Sep 21, 2013 at 07:27:20PM +0100, Jonathan Wakely wrote:
>> On 21 September 2013 19:09,  <wempwer@gmail.com> wrote:
>>>
>>> It tried -O2 and it also worked. However on my system it only said:
>>>
>>> warning: integer overflow in expression
>>>
>>> How did you get gcc to produce this part:
>>>
>>> [-Woverflow]
>>>
>>> I use gcc 4.5.2. But when I use gcc like this I also do not get any
>>> warnings:
>>>
>>> gcc -Woverflow main.c -o main
>>
>> 4.5.2 is quite old now. More recent versions show the warning option
>> that triggered the warning, that's what the [-Woverflow] part is.
>>
>>> I wonder:
>>>
>>> 1) why -Woverflow appears in your gcc output?
>>
>> Because it's a recent version.
>>
>>> 2) why `gcc -Woverflow main.c -o main' does not produce a warning?
>>
>> Because without optimisation the compiler doesn't do the necessary
>> analysis to realise that in the multiplication expression it knows the
>> values.
>>
>>> 3) why does `gcc -O main.c -o main' produce warning in the first place
>>> and why does it do this only when two operands are const?
>>
>> Because the optimiser can track the values of constants (because they
>> don't change) and see that the values in the multiplication are known.
> 
> But compiler also knows the operand values even if they are not
> constant? These values must be known to produce the multiplication
> result. Is this warning produced only when two operands are constant
> and optimization is turned on because this is just the way gcc does it
> and the warnings could also be produced for non-const operands if a
> compiler worked in a different way?
> 

The compiler can only produce warnings here if it knows the values you
are using for the calculations.  If you write "r = ab * bc;" then
compiler assumes that you know what you are doing, and using sensible
values for "ab" and "bc".  But if the compiler can calculate the values
involved (it requires -O1 or above for many of these calculations and
analysis passes), and it can see there is definitely an error, then it
can give a warning.

So it needs the values to be "compile-time constants".  That does not
necessarily mean values declared with "const", such as "const int ab =
50000;".  It also includes values set with #define, enumeration
constants, literals (i.e., "50000"), as well as statements, expressions
and function calls using these if the compiler knows all the details at
compile-time.

Note that the compiler /can/ give a warning in such cases, but it does
not have to do so.  gcc is a fantastic compiler, and gives better
compile-time warnings and static analysis than any other compiler I have
used - but it has limits.  If it can easily do the calculations at
compile-time, /and/ you have optimisation flags to enable such passes,
/and/ you have enabled the appropriate warnings - /then/ gcc will give
you the warnings.

Re: how to make gcc warn about arithmetic signed overflow

[James K. Lowden]

On Mon, 23 Sep 2013 08:54:57 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> > const_cast
> > will surely let you change the value of a const object without
> > treading into undefined behavior.
> 
> No, it surely won't!
> 
> If an object is defined as const in the first place then it is
> undefined behaviour to change it.
...
> And the definitive reference, 7.1.6.1 [dcl.type.cv]/4:
> "Except that any class member declared mutable (7.1.1) can be
> modified, any attempt to modify a const object during its lifetime
> (3.8) results in undefined behavior."

Oh, gee, someone is wrong on the Internet again.  Thanks for the
correction.  

As far as I can make out, the only remaining reliable use of const_cast
is to convert a type that was passed as a const reference back to
original (non-const) type, if such it was.  

7.1.6 is itself mutable, it turns out.  My yellowed ARM, copyright
1990, is considerably more relaxed on the question. (And considerably
easier to read.  I don't know how anyone learns C++ these days, so
dense is the technical terminology.)    

Stroustrup's commentary says, "adding const to a declaration ensures
that an object to which the const is applied cannot have its value
changed ... unless an explicit type conversion is used....  const does
not mean 'store in readonly memory' nor does it mean 'compile time
constant'."

Regarding errors, it mentions only that a const object might wind up in
"readonly" memory, in which case attempts to modify it will result in a
runtime error: "The effect of a write operation on any part of [a
const] object is either an addressing exception or the same as if the
object had been non-const".  That is, either it works or you get an
exception from the hardware, depending on whether the computer can
execute the code.  

Notably missing from that description is the possibility that the
compiler can do anything it wants because the programmer colored
outside the lines.  The purpose of const was to aid the programmer in
preventing accidental changes to a variable.  Because compiler writers
care more for efficiency than convenience, it's slowly metastasizing
into a no man's land between programmer and machine.  

--jkl

Re: how to make gcc warn about arithmetic signed overflow

[Dave Allured - NOAA Affiliate]

On Sun, Sep 22, 2013 at 10:03 PM, James K. Lowden
<jklowden@schemamania.org> wrote:
> Regarding the OP's query
>
>> > int r = ab * bc;
>
> although the provided example is simple enough, it's the compiler's
> job is to generate object code, not to do static analysis.
>
> Even if the values are const, in the general case they could be
> modified by another module or another thread.  The compiler simply
> doesn't have enough information to warn of every runtime overflow.

I believe the CPU overflow flag is updated after most integer
arithmetic instructions.  Does GCC have any facility for checking this
flag after each integer operation?  This would be a runtime check, of
course, not a compile time check.

--Dave

Re: how to make gcc warn about arithmetic signed overflow

[Oleg Endo]

On Mon, 2013-09-23 at 13:38 -0600, Dave Allured - NOAA Affiliate wrote:
> On Sun, Sep 22, 2013 at 10:03 PM, James K. Lowden
> <jklowden@schemamania.org> wrote:
> > Regarding the OP's query
> >
> >> > int r = ab * bc;
> >
> > although the provided example is simple enough, it's the compiler's
> > job is to generate object code, not to do static analysis.
> >
> > Even if the values are const, in the general case they could be
> > modified by another module or another thread.  The compiler simply
> > doesn't have enough information to warn of every runtime overflow.
> 
> I believe the CPU overflow flag is updated after most integer
> arithmetic instructions.  Does GCC have any facility for checking this
> flag after each integer operation?  This would be a runtime check, of
> course, not a compile time check.
> 

See -ftrapv option.  Although trapping math is not supported on every
target properly.
E.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
or SH related http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272

Cheers,
Oleg

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/23/2013 08:38 PM, Dave Allured - NOAA Affiliate wrote:
> I believe the CPU overflow flag is updated after most integer
> arithmetic instructions.  Does GCC have any facility for checking this
> flag after each integer operation?  This would be a runtime check, of
> course, not a compile time check.

It wouldn't help with optimized code.  GCC reorganizes code, and it
assumes that overflow doesn't happen.  GCC inserts some arithmetic
instructions while optimizing and deletes others.  So, even if an
overflow happens in your code, it doesn't necessarily happen at
runtime.

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[Dave Allured - NOAA Affiliate]

On Mon, Sep 23, 2013 at 1:42 PM, Oleg Endo <oleg.endo@t-online.de> wrote:
> On Mon, 2013-09-23 at 13:38 -0600, Dave Allured - NOAA Affiliate wrote:
>>
>> I believe the CPU overflow flag is updated after most integer
>> arithmetic instructions.  Does GCC have any facility for checking this
>> flag after each integer operation?  This would be a runtime check, of
>> course, not a compile time check.
>
> See -ftrapv option.  Although trapping math is not supported on every
> target properly.
> E.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
> or SH related http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272

Oleg, thanks for the tip.  "-ftrapv is seriously broken and nobody
wants to fix it", and that was 5.6 years ago.  Too bad, it seems like
a useful thing when you need it.  I use gcc's -ffpe-trap routinely to
guard fortran floating point stuff, and it has done many favors for
me.

--Dave

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 23 September 2013 16:47, James K. Lowden wrote:
>
> 7.1.6 is itself mutable, it turns out.  My yellowed ARM, copyright
> 1990, is considerably more relaxed on the question. (And considerably
> easier to read.  I don't know how anyone learns C++ these days, so
> dense is the technical terminology.)

The standard isn't meant to be a tutorial and noone should try to
learn C++ from the standard. Stroustrup's 4th edition of The C++
Programming Language is much easier to read (but not all that much
shorter) than the standard.

Re: how to make gcc warn about arithmetic signed overflow

[James K. Lowden]

On Mon, 23 Sep 2013 20:48:23 +0100
Andrew Haley <aph@redhat.com> wrote:

> On 09/23/2013 08:38 PM, Dave Allured - NOAA Affiliate wrote:
> > I believe the CPU overflow flag is updated after most integer
> > arithmetic instructions.  Does GCC have any facility for checking
> > this flag after each integer operation?  This would be a runtime
> > check, of course, not a compile time check.
> 
> It wouldn't help with optimized code.  GCC reorganizes code, and it
> assumes that overflow doesn't happen.  GCC inserts some arithmetic
> instructions while optimizing and deletes others.  So, even if an
> overflow happens in your code, it doesn't necessarily happen at
> runtime.

Could you unpack that a bit?  Regardless of optimization, the CPU, not
the compiler, executes the ADD or MUL operation, or whatever, and sets
or does not set the overflow bit accordingly, right?  Why can't the
compiler generate code that senses that, and raises a runtime error?
It's no different than answering divide-by-zero.  

I've written a lot of SAFE_CAST macros that check the return of sizeof
or strlen(3) before casting it to an int and assigning the result to
something that *must* be an int.  That code is terribly inefficient,
clumsy to read, noise on the screen, really.  But made necessary IMO
because the compiler conceals what the processor reports.  

--jkl

Re: how to make gcc warn about arithmetic signed overflow

[James K. Lowden]

On Mon, 23 Sep 2013 22:50:09 +0100
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On 23 September 2013 16:47, James K. Lowden wrote:
> >
> > 7.1.6 is itself mutable, it turns out.  My yellowed ARM, copyright
> > 1990, is considerably more relaxed on the question. (And
> > considerably easier to read.  I don't know how anyone learns C++
> > these days, so dense is the technical terminology.)
> 
> The standard isn't meant to be a tutorial and noone should try to
> learn C++ from the standard. Stroustrup's 4th edition of The C++
> Programming Language is much easier to read (but not all that much
> shorter) than the standard.

Granted, but no one ever confused the ARM with a tutorial.  It *was*
the standard, 23 years ago. It defined the language, with commentary,
in under 500 pages, and gave the compiler precious few UB
opportunities.  An experienced programmer could read it, learn the
language and rely on what he'd read.  

I understand the language has grown somewhat, but the equivalent book
would be 3000 pages today.  (The standard alone is 1300.)  A good deal
of it is devoted to Get Out of Jail Free cards for the compiler:
describing what might compile and not produce a deterministic result.
As with all the tut-tutting about type-punning, for example.  

When did this become a good idea?  

The compiler's job is to convert C ++ logic into machine logic, and to
reject anything it cannot do so with absolute assurance.  If I could
wish something for C++14, it would be a 90% reduction in UB
descriptions.  Let's define the behavior and be done with it.  By
removing ambiguity, maybe the definition the language would become
readable again.  

--jkl

Re: how to make gcc warn about arithmetic signed overflow

[Jonathan Wakely]

On 23 September 2013 23:43, James K. Lowden wrote:
> On Mon, 23 Sep 2013 22:50:09 +0100
> The compiler's job is to convert C ++ logic into machine logic, and to
> reject anything it cannot do so with absolute assurance.  If I could
> wish something for C++14, it would be a 90% reduction in UB
> descriptions.  Let's define the behavior and be done with it.  By
> removing ambiguity, maybe the definition the language would become
> readable again.

There's a study group looking into that, see the note on SG12 at
http://isocpp.org/std/the-committee

Getting involved with the group would be a lot more effective than wishing :-)

Re: how to make gcc warn about arithmetic signed overflow

[Brian Drummond]

On Mon, 2013-09-23 at 13:38 -0600, Dave Allured - NOAA Affiliate wrote:
> On Sun, Sep 22, 2013 at 10:03 PM, James K. Lowden
> <jklowden@schemamania.org> wrote:
> > Regarding the OP's query
> >
> >> > int r = ab * bc;
> >
> > although the provided example is simple enough, it's the compiler's
> > job is to generate object code, not to do static analysis.
> >
> > Even if the values are const, in the general case they could be
> > modified by another module or another thread.  The compiler simply
> > doesn't have enough information to warn of every runtime overflow.
> 
> I believe the CPU overflow flag is updated after most integer
> arithmetic instructions.  Does GCC have any facility for checking this
> flag after each integer operation?  

Of course it has. See documentation for the -gnato flag (which,
annoyingly, isn't on by default)

> This would be a runtime check, of
> course, not a compile time check.

Not at all : gcc seems to be quite good at eliminating runtime checks if
it can prove (from integer subtype ranges for example) that they can
never be triggered. For the few remaining checks it does have to plant
runtime code. 

In practice in at least one sizeable example, the overhead from overflow
checks turns out to be about 1%.

In this mode, optimisation such as code reordering poses no trouble:
only assignment to the final variable enforces the constraint.
Intermediate arithmetic, however reordered, is required to have adequate
length (have the pseudo-type Universal Integer.

Unfortunately, as this (AFAIK) only applies to gcc when compiling Ada,
both this and the quite revealing C++ discussion are equally off topic
to the original question.

- Brian

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/23/2013 11:00 PM, James K. Lowden wrote:
> On Mon, 23 Sep 2013 20:48:23 +0100
> Andrew Haley <aph@redhat.com> wrote:
> 
>> On 09/23/2013 08:38 PM, Dave Allured - NOAA Affiliate wrote:
>>> I believe the CPU overflow flag is updated after most integer
>>> arithmetic instructions.  Does GCC have any facility for checking
>>> this flag after each integer operation?  This would be a runtime
>>> check, of course, not a compile time check.
>>
>> It wouldn't help with optimized code.  GCC reorganizes code, and it
>> assumes that overflow doesn't happen.  GCC inserts some arithmetic
>> instructions while optimizing and deletes others.  So, even if an
>> overflow happens in your code, it doesn't necessarily happen at
>> runtime.
> 
> Could you unpack that a bit?  Regardless of optimization, the CPU, not
> the compiler, executes the ADD or MUL operation, or whatever, and sets
> or does not set the overflow bit accordingly, right?  Why can't the
> compiler generate code that senses that, and raises a runtime error?

Because the compiler does a lot of rewriting.  There is not a one-to-
one mapping between operations in your source program and
instructions.  An operation might occur in your program but not in the
object code.  For example, say you do this:

   int n = m + BIG_NUMBER;
   return n - BIG_NUMBER;

There is an overflow in your source, but not in the object code.  So
no trap will occur.

> I've written a lot of SAFE_CAST macros that check the return of sizeof
> or strlen(3) before casting it to an int and assigning the result to
> something that *must* be an int.  That code is terribly inefficient,
> clumsy to read, noise on the screen, really.  But made necessary IMO
> because the compiler conceals what the processor reports.  

I'm not quite sure what you mean by this.  Why would you want to cast
it to an int, anyway?  Desperately short of space?

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[James K. Lowden]

On Tue, 24 Sep 2013 18:48:08 +0100
Andrew Haley <aph@redhat.com> wrote:

> > Regardless of optimization, the CPU, not
> > the compiler, executes the ADD or MUL operation, or whatever, and
> > sets or does not set the overflow bit accordingly, right?  Why
> > can't the compiler generate code that senses that, and raises a
> > runtime error?
> 
> Because the compiler does a lot of rewriting.  There is not a one-to-
> one mapping between operations in your source program and
> instructions.  An operation might occur in your program but not in the
> object code.  For example, say you do this:
> 
>    int n = m + BIG_NUMBER;
>    return n - BIG_NUMBER;
> 
> There is an overflow in your source, but not in the object code.  So
> no trap will occur.

I thought that's what you meant.  I was confused by "in your source"
because of course source code doesn't overflow.  (Well, I've seem some
code bases that I'd describe that way, but that's a different issue!)  

You mean that a naïve rendering of the source code implies an overflow
where none might exist in the actual emitted object code.  And,
presumably, the converse: that even if the source is written such that
there logically can't be an overflow, the compiler might render object
code that does.  

As far as I'm concerned, that's neither here nor there.  When the
compiler is done, there is object code that does execute on a real CPU
and does -- on some architectures -- set an overflow bit in the status
word for overflowing integer operations.  

I saw recommendations here for -ftrapv, said to be broken (?), defined
only for signed integer operations, and -gnato, which afaict is for
Ada.  So in C and C++ there appears to be no option to utilize the
processor's integer overflow status bit.  

> > I've written a lot of SAFE_CAST macros that check the return of
> > sizeof or strlen(3) before casting it to an int and assigning the
> > result to something that *must* be an int.  That code is terribly
> > inefficient, clumsy to read, noise on the screen, really.  But made
> > necessary IMO because the compiler conceals what the processor
> > reports.  
> 
> I'm not quite sure what you mean by this.  Why would you want to cast
> it to an int, anyway?  Desperately short of space?

Many communication protocols use 16 or 32 bits to represent a value
that will *surely* fit, such as the size of a packet.  Compute that
size with sizeof or strlen, and suddenly you're in size_t space.
Unless there's an error, it's perfectly safe to assign the results to
type required by the protocol.  Me, I'm conservative in what I emit;
I trust but verify.  

It's also not very hard to find libraries in common use -- some recently
defined, sadly -- that use int for lengths.  ODBC and Apache Thrift
come to mind.  

--jkl

Re: how to make gcc warn about arithmetic signed overflow

[Vincent Lefevre]

On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
> You mean that a naïve rendering of the source code implies an overflow
> where none might exist in the actual emitted object code.  And,
> presumably, the converse: that even if the source is written such that
> there logically can't be an overflow, the compiler might render object
> code that does.

The converse is forbidden.

> I saw recommendations here for -ftrapv, said to be broken (?),
> defined only for signed integer operations, [...]

It's defined only for signed integer operations, because there
are never overflows with unsigned integer operations (except for
conversions from floating-point types).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
>> You mean that a naïve rendering of the source code implies an overflow
>> where none might exist in the actual emitted object code.  And,
>> presumably, the converse: that even if the source is written such that
>> there logically can't be an overflow, the compiler might render object
>> code that does.
> 
> The converse is forbidden.

You'll find it hard to justify that by any language in the standard.

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[Vincent Lefevre]

On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
> > On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
> >> You mean that a naïve rendering of the source code implies an overflow
> >> where none might exist in the actual emitted object code.  And,
> >> presumably, the converse: that even if the source is written such that
> >> there logically can't be an overflow, the compiler might render object
> >> code that does.
> > 
> > The converse is forbidden.
> 
> You'll find it hard to justify that by any language in the standard.

What do you mean?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/26/2013 03:29 AM, James K. Lowden wrote:
> On Tue, 24 Sep 2013 18:48:08 +0100
> Andrew Haley <aph@redhat.com> wrote:
> 
>>> Regardless of optimization, the CPU, not
>>> the compiler, executes the ADD or MUL operation, or whatever, and
>>> sets or does not set the overflow bit accordingly, right?  Why
>>> can't the compiler generate code that senses that, and raises a
>>> runtime error?
>>
>> Because the compiler does a lot of rewriting.  There is not a one-to-
>> one mapping between operations in your source program and
>> instructions.  An operation might occur in your program but not in the
>> object code.  For example, say you do this:
>>
>>    int n = m + BIG_NUMBER;
>>    return n - BIG_NUMBER;
>>
>> There is an overflow in your source, but not in the object code.  So
>> no trap will occur.
> 
> I thought that's what you meant.  I was confused by "in your source"
> because of course source code doesn't overflow.

Well, overflows occur in terms of the virtual machine in which
standard C is specified.  So, IMO, it's not unreasonable to say that
the overflows are there in your source.

> You mean that a naïve rendering of the source code implies an
> overflow where none might exist in the actual emitted object code.

No, I don't.  If, say, you add two ints together and the sum is
greater than the maximum size, then a overflow occurs.  Whether this
overflow actually causes a machine overflow is another matter.

> And, presumably, the converse: that even if the source is written
> such that there logically can't be an overflow, the compiler might
> render object code that does.
> 
> As far as I'm concerned, that's neither here nor there.  When the
> compiler is done, there is object code that does execute on a real
> CPU and does -- on some architectures -- set an overflow bit in the
> status word for overflowing integer operations.

And what use would that be?  I can't think of any.  You'd have
erroneous programs that do overflow still not raising the overflow
flag because GCC helpfully removes the overflowing code.  It can do
that.  So you'd still have erroneous results.

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/26/2013 06:02 PM, Vincent Lefevre wrote:
> On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
>> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
>>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
>>>> You mean that a naïve rendering of the source code implies an overflow
>>>> where none might exist in the actual emitted object code.  And,
>>>> presumably, the converse: that even if the source is written such that
>>>> there logically can't be an overflow, the compiler might render object
>>>> code that does.
>>>
>>> The converse is forbidden.
>>
>> You'll find it hard to justify that by any language in the standard.
> 
> What do you mean?

There is no reason why a compiler should not generate an overflow
where none is written in the program, as long as it doesn't generate
a different result.

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[Vincent Lefevre]

On 2013-09-26 18:30:10 +0100, Andrew Haley wrote:
> On 09/26/2013 06:02 PM, Vincent Lefevre wrote:
> > On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
> >> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
> >>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
> >>>> You mean that a naïve rendering of the source code implies an overflow
> >>>> where none might exist in the actual emitted object code.  And,
> >>>> presumably, the converse: that even if the source is written such that
> >>>> there logically can't be an overflow, the compiler might render object
> >>>> code that does.
> >>>
> >>> The converse is forbidden.
> >>
> >> You'll find it hard to justify that by any language in the standard.
> > 
> > What do you mean?
> 
> There is no reason why a compiler should not generate an overflow
> where none is written in the program, as long as it doesn't generate
> a different result.

OK, I wouldn't call that an overflow, then. I thought you meant
rewrite the code in an intermediate step, generating an overflow,
before knowing the consequences at the target level. The term
"overflow" has a connotation of exception / undefined behavior.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/27/2013 08:57 AM, Vincent Lefevre wrote:
> On 2013-09-26 18:30:10 +0100, Andrew Haley wrote:
>> On 09/26/2013 06:02 PM, Vincent Lefevre wrote:
>>> On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
>>>> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
>>>>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
>>>>>> You mean that a naïve rendering of the source code implies an overflow
>>>>>> where none might exist in the actual emitted object code.  And,
>>>>>> presumably, the converse: that even if the source is written such that
>>>>>> there logically can't be an overflow, the compiler might render object
>>>>>> code that does.
>>>>>
>>>>> The converse is forbidden.
>>>>
>>>> You'll find it hard to justify that by any language in the standard.
>>>
>>> What do you mean?
>>
>> There is no reason why a compiler should not generate an overflow
>> where none is written in the program, as long as it doesn't generate
>> a different result.
> 
> OK, I wouldn't call that an overflow, then.

As far as the processor is concerned, what sets the overflow flag is
an overflow.  That's the context of this discussion.

> I thought you meant rewrite the code in an intermediate step,
> generating an overflow, before knowing the consequences at the
> target level. The term "overflow" has a connotation of exception /
> undefined behavior.

Sure.  No disagreement there.

Andrew.

Re: how to make gcc warn about arithmetic signed overflow

[Vincent Lefevre]

On 2013-09-27 09:23:35 +0100, Andrew Haley wrote:
> On 09/27/2013 08:57 AM, Vincent Lefevre wrote:
> > On 2013-09-26 18:30:10 +0100, Andrew Haley wrote:
> >> On 09/26/2013 06:02 PM, Vincent Lefevre wrote:
> >>> On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
> >>>> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
> >>>>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
> >>>>>> You mean that a naïve rendering of the source code implies an overflow
> >>>>>> where none might exist in the actual emitted object code.  And,
> >>>>>> presumably, the converse: that even if the source is written such that
> >>>>>> there logically can't be an overflow, the compiler might render object
> >>>>>> code that does.
> >>>>>
> >>>>> The converse is forbidden.
> >>>>
> >>>> You'll find it hard to justify that by any language in the standard.
> >>>
> >>> What do you mean?
> >>
> >> There is no reason why a compiler should not generate an overflow
> >> where none is written in the program, as long as it doesn't generate
> >> a different result.
> > 
> > OK, I wouldn't call that an overflow, then.
> 
> As far as the processor is concerned, what sets the overflow flag is
> an overflow.  That's the context of this discussion.

No, it isn't. If you regard the CPU overflow flag as a part of the
result, then the compiler is not allowed to generate overflows not
expressed in the source. Never. For instance, it would be really
wrong to get spurious crashes with -ftrapv just because gcc modified
the order of operations or just because the overflow flag has been
set with an unsigned operation (at the C level).

If you disregard the CPU overflow flag, then what the CPU does is
not regarded as an overflow.

Note that Dave Allured asked whether there is a way to check the
CPU overflow flag on an example where there may be an overflow
*in the source*.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: how to make gcc warn about arithmetic signed overflow

[Andrew Haley]

On 09/27/2013 10:28 AM, Vincent Lefevre wrote:
> On 2013-09-27 09:23:35 +0100, Andrew Haley wrote:
>> On 09/27/2013 08:57 AM, Vincent Lefevre wrote:
>>> On 2013-09-26 18:30:10 +0100, Andrew Haley wrote:
>>>> On 09/26/2013 06:02 PM, Vincent Lefevre wrote:
>>>>> On 2013-09-26 15:49:05 +0100, Andrew Haley wrote:
>>>>>> On 09/26/2013 09:29 AM, Vincent Lefevre wrote:
>>>>>>> On 2013-09-25 22:29:58 -0400, James K. Lowden wrote:
>>>>>>>> You mean that a naïve rendering of the source code implies an overflow
>>>>>>>> where none might exist in the actual emitted object code.  And,
>>>>>>>> presumably, the converse: that even if the source is written such that
>>>>>>>> there logically can't be an overflow, the compiler might render object
>>>>>>>> code that does.
>>>>>>>
>>>>>>> The converse is forbidden.
>>>>>>
>>>>>> You'll find it hard to justify that by any language in the standard.
>>>>>
>>>>> What do you mean?
>>>>
>>>> There is no reason why a compiler should not generate an overflow
>>>> where none is written in the program, as long as it doesn't generate
>>>> a different result.
>>>
>>> OK, I wouldn't call that an overflow, then.
>>
>> As far as the processor is concerned, what sets the overflow flag is
>> an overflow.  That's the context of this discussion.
> 
> No, it isn't. If you regard the CPU overflow flag as a part of the
> result, then the compiler is not allowed to generate overflows not
> expressed in the source. Never. For instance, it would be really
> wrong to get spurious crashes with -ftrapv just because gcc modified
> the order of operations or just because the overflow flag has been
> set with an unsigned operation (at the C level).

Sure, but if -ftrapv is turned off, gcc can generate instructions that
will overflow.  I suspect that it would be very hard to get GCC to do
this correctly in all cases when -ftrapv is turned on.

> If you disregard the CPU overflow flag, then what the CPU does is
> not regarded as an overflow.

It is by the CPU.  And it is by me.  If you choose not to regard that
as an overflow, I have no quarrel with you, but I will not agree.  By
the definition I am using, what sets the overflow flag is an overflow.

> Note that Dave Allured asked whether there is a way to check the
> CPU overflow flag on an example where there may be an overflow
> *in the source*.

Well, there probably isn't.  As I have explained.

Andrew.