https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #66 from Daniel Marjamäki ---
Thanks! I can appreciate that it's not very simple. Well using a flag is
totally acceptable. I don't trust the sanitizer completely but those that do
can use the optimisation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #65 from Jakub Jelinek ---
And the warning went away in r8-3771-g6358a676c3eb4c6df013ce8319bcf429cd14232b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #63 from Daniel Marjamäki ---
Sorry. I should have mentioned I am a Cppcheck developer in my comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Daniel Marjamäki changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #61 from Marian ---
Thanks for your reply
> The GCC 8 Changes page[*] says -Wstrict-overflow is deprecated (even if it is
> supposed to still work) and recommends to use
> -fsanitize=signed-integer-overflow to get a run-time warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #59 from Marian ---
Thanks for the fast replay
wget http://ptrace.fefe.de/int.c
gcc -Wstrict-overflow=1 -Wall -Wextra -pedantic -o int int.c
does not produce a warning (except for the missing `#include `) on gcc
8.2.0 on Alp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #58 from Andreas Schwab ---
-Wstrict-overflow=1 is enabled by -Wall.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Marian changed:
What|Removed |Added
CC||marian.buschsieweke at ovgu
dot de
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Jackie Rosen changed:
What|Removed |Added
CC||jackie.rosen at hushmail dot
com
--- Comm
--- Comment #55 from js at linuxtv dot org 2007-03-08 16:22 ---
Point taken. I was misled by the mentioning of C99 6.3.1.3
in comment #18, that this would apply to integer conversion.
Funnily enough, C99 3.4.3 even says "An example of undefined
behavior is the behavior on integer overfl
--- Comment #54 from pinskia at gcc dot gnu dot org 2007-03-08 01:14
---
(In reply to comment #53)
> I read all this and the mailing list thread with great interest,
> however I think there is a fundamental flaw in the reasoning:
>
> C90 6.2.1.2 / C99 6.3.1.3 defines signed integer ove
--- Comment #53 from js at linuxtv dot org 2007-03-08 01:03 ---
I read all this and the mailing list thread with great interest,
however I think there is a fundamental flaw in the reasoning:
C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow
as "implementation-defined behaviour",
--- Comment #52 from kargl at gcc dot gnu dot org 2007-01-23 00:45 ---
(In reply to comment #51)
> Sure, new security checks can be written in a compliant manner.
>
> But what plan do you suggest to find instances of non-compliant overflow
> checking in the existing body? Think somethi
--- Comment #51 from andreas at andreas dot org 2007-01-22 23:10 ---
Sure, new security checks can be written in a compliant manner.
But what plan do you suggest to find instances of non-compliant overflow
checking in the existing body? Think something like a whole Linux
distribution.
--- Comment #50 from pinskia at gcc dot gnu dot org 2007-01-22 22:27
---
There is no nothing special about signed integer overflow in C, it is just
undefined behavior at runtime. I had forgot to mention the SPEC results
because I don't feel SPEC CPU or any benchmark is a good way to me
--- Comment #49 from ian at airs dot com 2007-01-22 20:16 ---
In the C language standard "undefined behaviour" meants that the compiler can
do anything at all. It means that the program is specifically undefined.
When you say that the compiler should not eliminate the test because the
--- Comment #48 from felix-gcc at fefe dot de 2007-01-22 19:50 ---
Oh wow, another wise cracking newbie who comments without actually
understanding the issue. I AM NOT RELYING ON UNDEFINED BEHAVIOR. On the
contrary. gcc is fine to assign 23 instead of a negative number. But if it
doe
--- Comment #47 from andreas at andreas dot org 2007-01-22 18:36 ---
It was suggested to me that this issue should be discussed on the mailing list.
If you have an opinion, come there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #46 from pinskia at gcc dot gnu dot org 2007-01-22 18:33
---
> PS: Mr Simon, that link to a how-to that says "btw this doesn't work for this
> special input", is that supposed to impress anyone? It certainly does not
> impress me very much, really.
yes and the special inpu
--- Comment #45 from steven at gcc dot gnu dot org 2007-01-22 18:26 ---
Marking this as WONTFIX leaves the impression that here is a bug here at all.
This should have been closed as INVALID.
First commandment of using C: "Thou shall not rely on undefined behavior."
--
http://gcc.g
--- Comment #44 from pinskia at gcc dot gnu dot org 2007-01-22 17:14
---
Again this really has nothing to do with security except for the fact some
developers wrote security checking code that depends on overflow being defined
as wrapping which is not what the C standard says and what G
--- Comment #43 from felix-gcc at fefe dot de 2007-01-22 13:02 ---
No, it WAS about the security. Now that you made me check and I saw that the
optimization also doesn't give any actual speed increase, I want it removed on
that grounds, too. And I want it removed for reasons of sanity.
--- Comment #42 from pinskia at gcc dot gnu dot org 2007-01-22 02:27
---
(In reply to comment #41)
> So I tested some C++ vector code using at, in a desperate attempt to find ANY
> case where this so called "optimization" actually produces faster code.
Try looking at real code instead
--- Comment #41 from felix-gcc at fefe dot de 2007-01-22 02:18 ---
So I tested some C++ vector code using at, in a desperate attempt to find ANY
case where this so called "optimization" actually produces faster code.
http://ptrace.fefe.de/vector2.C
$ gcc -O3 -o vector2 vector2.C
$
--- Comment #40 from tromey at gcc dot gnu dot org 2007-01-21 21:52 ---
I've read through the comments in this PR.
I thought it would be useful to point out that a decision on how
GCC will optimize in the absence of -fwrapv will not be decided
by this PR. This change has been extensive
--- Comment #39 from pinskia at gcc dot gnu dot org 2007-01-21 20:14
---
No reason to keep this open as you are violating the C standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-01-21 19:46
---
(in reply to comment #35)
It is true that in the face of -fwrapv gcc does not optimize as good as it does
for unsigned numbers (that wrap, too). I am in the progress of fixing that
for the value range propagation
--- Comment #37 from pluto at agmk dot net 2007-01-21 18:16 ---
(In reply to comment #36)
> Now, to summarize.
you're leading to undefined behaviour - do you understand this simple fact?
in such cases compiler can do *anything* with your code.
> current behavior is bad for a lot of pe
--- Comment #36 from felix-gcc at fefe dot de 2007-01-21 17:47 ---
I think the actual root issue here is that the gcc argumentation is
fundamentally wrong. I am complaining that gcc removes my checks, not that
signed integer overflow is undefined.
Also, note that it is everything BUT u
--- Comment #35 from andreas at andreas dot org 2007-01-21 17:29 ---
(In reply to comment #34)
> > The range analysis has nothing to do with just assuming integers can't wrap.
> Partly wrong, range analysis is helped by the fact assuming integers can't
> wrap.
And in those cases then le
--- Comment #34 from pinskia at gcc dot gnu dot org 2007-01-21 16:31
---
> The range analysis has nothing to do with just assuming integers can't wrap.
Partly wrong, range analysis is helped by the fact assuming integers can't
wrap. If range analysis dependent on pointer overflow bein
--- Comment #33 from felix-gcc at fefe dot de 2007-01-21 13:53 ---
so now you give us... a straw man?
The range analysis has nothing to do with just assuming integers can't wrap.
But more to the point: the Intel compiler does not assume signed integers can't
wrap, and IT STILL PRODUCES
--- Comment #32 from andreas at andreas dot org 2007-01-21 12:49 ---
Oh, and besides, proper range analysis could optimize the above code, even in
the presence of correct (and I mean LIA-1) overflow behaviour of signed ints.
It seems you still didn't even manage to come up with an examp
--- Comment #31 from andreas at andreas dot org 2007-01-21 12:23 ---
And who will go over the existing millions lines of code, and verify the
overflow checks everywhere? Or add -fwrapv to all the Makefiles for unaidited
code? Obviously not you. It seems to be easier to pretend you're no
--- Comment #30 from pinskia at gcc dot gnu dot org 2007-01-21 08:58
---
GCC is not going to change. There is no reason why you can't either use
-fwrapv or change the security checks to be before the overflow happens. There
are now good reasons why -fwrapv is not on by default, if you
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-01-18 17:36
---
Oh and I meant "at", not get or []. at does bounds checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #28 from felix-gcc at fefe dot de 2007-01-18 15:23 ---
Mhh, so I wondered, how can it be that the code is exactly as fast. So I
disassembled the binary. You know what? IT'S THE EXACT SAME CODE.
So, my conjecture is, again: your "optimization" does exactly NO good
whatsoev
--- Comment #27 from felix-gcc at fefe dot de 2007-01-18 15:20 ---
Oh, so C++ code using vector gets faster, you say? Let's see...
This is vector.C from http://ptrace.fefe.de/vector.C
It does some assignments to a vector. It runs the loop 10 times and takes the
minimum cycle counter.
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-01-17 19:17
---
(In reply to comment #25)
> Well, duh. You removed the security checks.
Which were wrong to begin with, See the comp.lang.c faq.
>
> Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock,
--- Comment #25 from felix-gcc at fefe dot de 2007-01-17 19:04 ---
Well, duh. You removed the security checks.
Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock,
and lo and behold, multithreaded code will be much faster! It will also be
broken, but apparentl
--- Comment #24 from pinskia at gcc dot gnu dot org 2007-01-17 18:43
---
Try doing some timings with and without -fwrapv and see what happens for normal
code.
You will see that without -fwrapv code runs faster.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #23 from felix-gcc at fefe dot de 2007-01-17 18:23 ---
In earlier gcc versions this only happened if the optimizer was on. So your
argument might hold some water there, if I squint my eyes enough.
But gcc 4.1 removes that code even with the optimizer turned off.
There goes
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-17 17:42
---
(In reply to comment #21)
> I DID NOT WRITE THE BROKEN CODE.
But you wrote the bug so I assumed you wrote it.
> Trying to trivialize the issue or insult me will not make it go away.
How about this has not change
--- Comment #21 from felix-gcc at fefe dot de 2007-01-17 17:20 ---
I DID NOT WRITE THE BROKEN CODE.
Trying to trivialize the issue or insult me will not make it go away.
So, please tell me, which part of the argument in comment #9 were you unable to
follow? I could try using less comp
--- Comment #20 from amacleod at redhat dot com 2007-01-17 17:14 ---
Perhaps comment #12 and comment #13 would have the same results if they both
used the same options? One has -O and the other does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-17 17:12
---
Again your code is broken to the standard and the comp.lang.c faq mentions a
way to not dependent on the undefined code so this again is not really a bug.
The question about security is what do you trust, the inpu
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-17 17:05
---
There is no single change that led to this situation and "reverting" it from
current development sources will not satisfy you anyway because old versions
are then still "affected".
The correct way to test for this
--- Comment #17 from felix-gcc at fefe dot de 2007-01-17 17:02 ---
You misunderstand.
We don't want you to say anything.
We want to you make your "optimization" off by default, or remove it
altogether.
You could also try to convince us that there is any actual tangible performance
gai
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-01-17 16:56
---
http://c-faq.com/misc/sd26.html is all I am going to say from now on. It tell
you explictly how to dectect an overflow before an overflow is going to happen.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #15 from erdgeist-gcc at erdgeist dot org 2007-01-17 16:54
---
(In reply to comment #11)
> Btw. your testcase "fails" with gcc 2.95.3 for me as well, so no news here.
Putting your struggles here aside, I'd like to see a type-agnostic assert from
you C-cracks to use for my s
--- Comment #14 from felix-gcc at fefe dot de 2007-01-17 16:37 ---
1. "apologist", in contrast to "asshole", is not a cuss word. Apparently you
are as ignorant about English as you are about the issue at hand.
2. I showed my gcc -v, why don't you? Maybe it's platform dependent? For a
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-17 16:32
---
[EMAIL PROTECTED]:/tmp> /space/rguenther/install/gcc-2.95/bin/gcc -o int int.c
-O
[EMAIL PROTECTED]:/tmp> ./int
200 100
-2147483549 2147483647
stock 2.95.3 sources. Don't tell people words, it makes you look lik
--- Comment #12 from felix-gcc at fefe dot de 2007-01-17 15:21 ---
(In reply to comment #11)
> Btw. your testcase "fails" with gcc 2.95.3 for me as well, so no news here.
>
Bullshit.
$ ./gcc2 -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-17 14:31
---
Btw. your testcase "fails" with gcc 2.95.3 for me as well, so no news here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-17 14:26
---
You need to improve your communication skills - pissing people off doesn't help
your agenda. Btw, pointer overflow is undefined and we use that fact.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #9 from felix-gcc at fefe dot de 2007-01-17 13:55 ---
Hey Andrew, do you really think this issue goes away if you keep closing the
bugs fast enough?
Let me tell you something: that INT_MAX way to do it is bogus. These checks
are there so that it is obvious the int overflow
--- Comment #8 from gcc at mailinator dot com 2007-01-16 07:24 ---
The original poster might want to read http://c-faq.com/misc/intovf.html and
http://c-faq.com/misc/sd26.html to see how he might "prevent people from
getting hacked" correctly.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #7 from pluto at agmk dot net 2007-01-16 07:00 ---
(In reply to comment #6)
> I forgot to mention GCC already has an option to trap on every signed
> overflow,
> -ftrapv, which might be faster than doing it by hand.
and it doesn't work -> PR19020
--
http://gcc.gnu.org/
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-16 04:47 ---
I forgot to mention GCC already has an option to trap on every signed overflow,
-ftrapv, which might be faster than doing it by hand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-15 20:04 ---
> THIS IS NOT A JOKE. FIX THIS! NOW!
I am not joking, the C standard explictly says signed integer overflow is
undefined behavior.
See PR 27257 and others.
*** This bug has been marked as a duplicate of 27257 **
--- Comment #4 from felix-gcc at fefe dot de 2007-01-15 19:57 ---
(In reply to comment #2)
> signed type overflow is undefined by the C standard, use unsigned int for the
> addition or use -fwrapv.
You have GOT to be kidding?
All kinds of security issues are caused by integer wraps, an
--- Comment #3 from felix-gcc at fefe dot de 2007-01-15 19:50 ---
even stranger, if I assert ((int)(a+100) > 0) then it STILL gets optimized
away.
WTF!?
--
felix-gcc at fefe dot de changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-15 19:47 ---
signed type overflow is undefined by the C standard, use unsigned int for the
addition or use -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from felix-gcc at fefe dot de 2007-01-15 19:46 ---
Mhh, if I change "int+100" to "(int)(int+100)", the assert still gets optimized
away.
So it's not an integer promotion issue. Both sides are definitely int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
66 matches
Mail list logo
