* how to make gcc warn about arithmetic signed overflow @ 2013-09-21 16:45 wempwer 2013-09-21 17:24 ` Jonathan Wakely 2013-09-21 17:36 ` Brian Drummond 0 siblings, 2 replies; 40+ messages in thread From: wempwer @ 2013-09-21 16:45 UTC (permalink / raw) To: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 16:45 how to make gcc warn about arithmetic signed overflow wempwer @ 2013-09-21 17:24 ` Jonathan Wakely 2013-09-21 17:41 ` wempwer 2013-09-21 17:53 ` Marc Glisse 2013-09-21 17:36 ` Brian Drummond 1 sibling, 2 replies; 40+ messages in thread From: Jonathan Wakely @ 2013-09-21 17:24 UTC (permalink / raw) To: wempwer; +Cc: gcc-help 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++. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 17:24 ` Jonathan Wakely @ 2013-09-21 17:41 ` wempwer 2013-09-21 18:30 ` Jonathan Wakely 2013-09-21 17:53 ` Marc Glisse 1 sibling, 1 reply; 40+ messages in thread From: wempwer @ 2013-09-21 17:41 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 17:41 ` wempwer @ 2013-09-21 18:30 ` Jonathan Wakely 2013-09-21 18:50 ` wempwer 2013-09-23 4:04 ` James K. Lowden 0 siblings, 2 replies; 40+ messages in thread From: Jonathan Wakely @ 2013-09-21 18:30 UTC (permalink / raw) To: wempwer; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 18:30 ` Jonathan Wakely @ 2013-09-21 18:50 ` wempwer 2013-09-21 19:55 ` Jędrzej Dudkiewicz 2013-09-23 4:04 ` James K. Lowden 1 sibling, 1 reply; 40+ messages in thread From: wempwer @ 2013-09-21 18:50 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 18:50 ` wempwer @ 2013-09-21 19:55 ` Jędrzej Dudkiewicz 2013-09-21 20:16 ` wempwer 0 siblings, 1 reply; 40+ messages in thread From: Jędrzej Dudkiewicz @ 2013-09-21 19:55 UTC (permalink / raw) To: wempwer; +Cc: gcc-help >> 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 19:55 ` Jędrzej Dudkiewicz @ 2013-09-21 20:16 ` wempwer 2013-09-21 20:52 ` Jędrzej Dudkiewicz 0 siblings, 1 reply; 40+ messages in thread From: wempwer @ 2013-09-21 20:16 UTC (permalink / raw) To: Jędrzej Dudkiewicz; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 20:16 ` wempwer @ 2013-09-21 20:52 ` Jędrzej Dudkiewicz 2013-09-21 21:07 ` wempwer 0 siblings, 1 reply; 40+ messages in thread From: Jędrzej Dudkiewicz @ 2013-09-21 20:52 UTC (permalink / raw) To: wempwer; +Cc: gcc-help >> > 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 20:52 ` Jędrzej Dudkiewicz @ 2013-09-21 21:07 ` wempwer 0 siblings, 0 replies; 40+ messages in thread From: wempwer @ 2013-09-21 21:07 UTC (permalink / raw) To: Jędrzej Dudkiewicz; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 18:30 ` Jonathan Wakely 2013-09-21 18:50 ` wempwer @ 2013-09-23 4:04 ` James K. Lowden 2013-09-23 7:55 ` Jonathan Wakely 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 1 sibling, 2 replies; 40+ messages in thread From: James K. Lowden @ 2013-09-23 4:04 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 4:04 ` James K. Lowden @ 2013-09-23 7:55 ` Jonathan Wakely 2013-09-23 15:47 ` James K. Lowden 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 1 sibling, 1 reply; 40+ messages in thread From: Jonathan Wakely @ 2013-09-23 7:55 UTC (permalink / raw) To: James K. Lowden; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 7:55 ` Jonathan Wakely @ 2013-09-23 15:47 ` James K. Lowden 2013-09-23 21:50 ` Jonathan Wakely 0 siblings, 1 reply; 40+ messages in thread From: James K. Lowden @ 2013-09-23 15:47 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 15:47 ` James K. Lowden @ 2013-09-23 21:50 ` Jonathan Wakely 2013-09-23 22:44 ` James K. Lowden 0 siblings, 1 reply; 40+ messages in thread From: Jonathan Wakely @ 2013-09-23 21:50 UTC (permalink / raw) To: James K. Lowden; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 21:50 ` Jonathan Wakely @ 2013-09-23 22:44 ` James K. Lowden 2013-09-23 23:20 ` Jonathan Wakely 0 siblings, 1 reply; 40+ messages in thread From: James K. Lowden @ 2013-09-23 22:44 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 22:44 ` James K. Lowden @ 2013-09-23 23:20 ` Jonathan Wakely 0 siblings, 0 replies; 40+ messages in thread From: Jonathan Wakely @ 2013-09-23 23:20 UTC (permalink / raw) To: James K. Lowden; +Cc: gcc-help 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 :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 4:04 ` James K. Lowden 2013-09-23 7:55 ` Jonathan Wakely @ 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 2013-09-23 19:43 ` Oleg Endo ` (2 more replies) 1 sibling, 3 replies; 40+ messages in thread From: Dave Allured - NOAA Affiliate @ 2013-09-23 19:38 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate @ 2013-09-23 19:43 ` Oleg Endo 2013-09-23 20:37 ` Dave Allured - NOAA Affiliate 2013-09-23 19:48 ` Andrew Haley 2013-09-24 7:42 ` Brian Drummond 2 siblings, 1 reply; 40+ messages in thread From: Oleg Endo @ 2013-09-23 19:43 UTC (permalink / raw) To: Dave Allured - NOAA Affiliate; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 19:43 ` Oleg Endo @ 2013-09-23 20:37 ` Dave Allured - NOAA Affiliate 0 siblings, 0 replies; 40+ messages in thread From: Dave Allured - NOAA Affiliate @ 2013-09-23 20:37 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 2013-09-23 19:43 ` Oleg Endo @ 2013-09-23 19:48 ` Andrew Haley 2013-09-23 22:00 ` James K. Lowden 2013-09-24 7:42 ` Brian Drummond 2 siblings, 1 reply; 40+ messages in thread From: Andrew Haley @ 2013-09-23 19:48 UTC (permalink / raw) To: Dave Allured - NOAA Affiliate; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 19:48 ` Andrew Haley @ 2013-09-23 22:00 ` James K. Lowden 2013-09-24 17:48 ` Andrew Haley 0 siblings, 1 reply; 40+ messages in thread From: James K. Lowden @ 2013-09-23 22:00 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 22:00 ` James K. Lowden @ 2013-09-24 17:48 ` Andrew Haley 2013-09-26 2:30 ` James K. Lowden 0 siblings, 1 reply; 40+ messages in thread From: Andrew Haley @ 2013-09-24 17:48 UTC (permalink / raw) To: James K. Lowden; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-24 17:48 ` Andrew Haley @ 2013-09-26 2:30 ` James K. Lowden 2013-09-26 8:29 ` Vincent Lefevre 2013-09-26 17:41 ` Andrew Haley 0 siblings, 2 replies; 40+ messages in thread From: James K. Lowden @ 2013-09-26 2:30 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 2:30 ` James K. Lowden @ 2013-09-26 8:29 ` Vincent Lefevre 2013-09-26 14:49 ` Andrew Haley 2013-09-26 17:41 ` Andrew Haley 1 sibling, 1 reply; 40+ messages in thread From: Vincent Lefevre @ 2013-09-26 8:29 UTC (permalink / raw) To: gcc-help 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 8:29 ` Vincent Lefevre @ 2013-09-26 14:49 ` Andrew Haley 2013-09-26 17:03 ` Vincent Lefevre 0 siblings, 1 reply; 40+ messages in thread From: Andrew Haley @ 2013-09-26 14:49 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 14:49 ` Andrew Haley @ 2013-09-26 17:03 ` Vincent Lefevre 2013-09-26 18:19 ` Andrew Haley 0 siblings, 1 reply; 40+ messages in thread From: Vincent Lefevre @ 2013-09-26 17:03 UTC (permalink / raw) To: gcc-help 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 17:03 ` Vincent Lefevre @ 2013-09-26 18:19 ` Andrew Haley 2013-09-27 7:58 ` Vincent Lefevre 0 siblings, 1 reply; 40+ messages in thread From: Andrew Haley @ 2013-09-26 18:19 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 18:19 ` Andrew Haley @ 2013-09-27 7:58 ` Vincent Lefevre 2013-09-27 8:23 ` Andrew Haley 0 siblings, 1 reply; 40+ messages in thread From: Vincent Lefevre @ 2013-09-27 7:58 UTC (permalink / raw) To: gcc-help 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-27 7:58 ` Vincent Lefevre @ 2013-09-27 8:23 ` Andrew Haley 2013-09-27 9:28 ` Vincent Lefevre 0 siblings, 1 reply; 40+ messages in thread From: Andrew Haley @ 2013-09-27 8:23 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-27 8:23 ` Andrew Haley @ 2013-09-27 9:28 ` Vincent Lefevre 2013-09-27 9:43 ` Andrew Haley 0 siblings, 1 reply; 40+ messages in thread From: Vincent Lefevre @ 2013-09-27 9:28 UTC (permalink / raw) To: gcc-help 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-27 9:28 ` Vincent Lefevre @ 2013-09-27 9:43 ` Andrew Haley 0 siblings, 0 replies; 40+ messages in thread From: Andrew Haley @ 2013-09-27 9:43 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-26 2:30 ` James K. Lowden 2013-09-26 8:29 ` Vincent Lefevre @ 2013-09-26 17:41 ` Andrew Haley 1 sibling, 0 replies; 40+ messages in thread From: Andrew Haley @ 2013-09-26 17:41 UTC (permalink / raw) To: James K. Lowden; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 2013-09-23 19:43 ` Oleg Endo 2013-09-23 19:48 ` Andrew Haley @ 2013-09-24 7:42 ` Brian Drummond 2 siblings, 0 replies; 40+ messages in thread From: Brian Drummond @ 2013-09-24 7:42 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 17:24 ` Jonathan Wakely 2013-09-21 17:41 ` wempwer @ 2013-09-21 17:53 ` Marc Glisse 2013-09-21 18:09 ` wempwer 1 sibling, 1 reply; 40+ messages in thread From: Marc Glisse @ 2013-09-21 17:53 UTC (permalink / raw) To: Jonathan Wakely; +Cc: wempwer, gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 17:53 ` Marc Glisse @ 2013-09-21 18:09 ` wempwer 2013-09-21 18:27 ` Jonathan Wakely 0 siblings, 1 reply; 40+ messages in thread From: wempwer @ 2013-09-21 18:09 UTC (permalink / raw) To: gcc-help; +Cc: Jonathan Wakely 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 18:09 ` wempwer @ 2013-09-21 18:27 ` Jonathan Wakely 2013-09-21 19:32 ` wempwer 0 siblings, 1 reply; 40+ messages in thread From: Jonathan Wakely @ 2013-09-21 18:27 UTC (permalink / raw) To: wempwer; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 18:27 ` Jonathan Wakely @ 2013-09-21 19:32 ` wempwer 2013-09-22 15:52 ` Jonathan Wakely 2013-09-23 13:04 ` David Brown 0 siblings, 2 replies; 40+ messages in thread From: wempwer @ 2013-09-21 19:32 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 19:32 ` wempwer @ 2013-09-22 15:52 ` Jonathan Wakely 2013-09-23 13:04 ` David Brown 1 sibling, 0 replies; 40+ messages in thread From: Jonathan Wakely @ 2013-09-22 15:52 UTC (permalink / raw) To: wempwer; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 19:32 ` wempwer 2013-09-22 15:52 ` Jonathan Wakely @ 2013-09-23 13:04 ` David Brown 1 sibling, 0 replies; 40+ messages in thread From: David Brown @ 2013-09-23 13:04 UTC (permalink / raw) To: wempwer; +Cc: Jonathan Wakely, gcc-help 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 16:45 how to make gcc warn about arithmetic signed overflow wempwer 2013-09-21 17:24 ` Jonathan Wakely @ 2013-09-21 17:36 ` Brian Drummond 2013-09-21 17:45 ` wempwer 1 sibling, 1 reply; 40+ messages in thread From: Brian Drummond @ 2013-09-21 17:36 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: how to make gcc warn about arithmetic signed overflow 2013-09-21 17:36 ` Brian Drummond @ 2013-09-21 17:45 ` wempwer 0 siblings, 0 replies; 40+ messages in thread From: wempwer @ 2013-09-21 17:45 UTC (permalink / raw) To: Brian Drummond; +Cc: gcc-help 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2013-09-27 9:43 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-09-21 16:45 how to make gcc warn about arithmetic signed overflow wempwer 2013-09-21 17:24 ` Jonathan Wakely 2013-09-21 17:41 ` wempwer 2013-09-21 18:30 ` Jonathan Wakely 2013-09-21 18:50 ` wempwer 2013-09-21 19:55 ` Jędrzej Dudkiewicz 2013-09-21 20:16 ` wempwer 2013-09-21 20:52 ` Jędrzej Dudkiewicz 2013-09-21 21:07 ` wempwer 2013-09-23 4:04 ` James K. Lowden 2013-09-23 7:55 ` Jonathan Wakely 2013-09-23 15:47 ` James K. Lowden 2013-09-23 21:50 ` Jonathan Wakely 2013-09-23 22:44 ` James K. Lowden 2013-09-23 23:20 ` Jonathan Wakely 2013-09-23 19:38 ` Dave Allured - NOAA Affiliate 2013-09-23 19:43 ` Oleg Endo 2013-09-23 20:37 ` Dave Allured - NOAA Affiliate 2013-09-23 19:48 ` Andrew Haley 2013-09-23 22:00 ` James K. Lowden 2013-09-24 17:48 ` Andrew Haley 2013-09-26 2:30 ` James K. Lowden 2013-09-26 8:29 ` Vincent Lefevre 2013-09-26 14:49 ` Andrew Haley 2013-09-26 17:03 ` Vincent Lefevre 2013-09-26 18:19 ` Andrew Haley 2013-09-27 7:58 ` Vincent Lefevre 2013-09-27 8:23 ` Andrew Haley 2013-09-27 9:28 ` Vincent Lefevre 2013-09-27 9:43 ` Andrew Haley 2013-09-26 17:41 ` Andrew Haley 2013-09-24 7:42 ` Brian Drummond 2013-09-21 17:53 ` Marc Glisse 2013-09-21 18:09 ` wempwer 2013-09-21 18:27 ` Jonathan Wakely 2013-09-21 19:32 ` wempwer 2013-09-22 15:52 ` Jonathan Wakely 2013-09-23 13:04 ` David Brown 2013-09-21 17:36 ` Brian Drummond 2013-09-21 17:45 ` wempwer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).