[Bug c/30475] assert(int+100 > int) optimized away

["pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- 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,
> and lo and behold, multithreaded code will be much faster!  It will also be
> broken, but apparently, that's not much of a concern around here.

No, because it is not undefined for pthread_mutex_lock unlike this case.

> The most time critical code I have, I just benchmarked.
> 
>   $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c
> add.c mul.c write.c read.c comba.c
>   $ ./t
>   adding two bignums: 84 cycles
>   multiply two bignums: 1414 cycles
>   writing a bignum as radix 10: 207488 cycles
>   comba: 1467 cycles
>   $ gcc -O3 -fomit-frame-pointer -funroll-loops -march=athlon64 -o t t.c misc.c
> add.c mul.c write.c read.c comba.c -fwrapv
>   adding two bignums: 82 cycles
>   multiply two bignums: 1414 cycles
>   writing a bignum as radix 10: 202761 cycles
>   comba: 1465 cycles
>   $
> 
> So, uh, where does the optimization part about your "optimization" come in? 

Most of the time it is loops.  Try adding bounds checking to the code and try
again.  You will then see the difference,  This is an important optimization
for C++ code that has bound checked array accesses, Java code and Fortran code.

> This is code that has no integer overflow checks.

Your specific code has no code which benifits that much.  Try again with some
C++ code which uses vector and get.  You will see a huge difference in the code
there.

>  So my conjecture is: your
> "optimization" makes code faster in exactly those cases where it removes
> security checks from it, endangering people on the way.

You are missunderstanding, your one piece of code does not benifit so you can
just alway turn on -fwrapv if you really depend on signed integer overflow
wrapping.  You need to look at the bigger picture:
1) security is important
2) code generation is important

which one is better for the users, all of the above.  Just because the person
who wrote the security checks in the code you are looking at got it wrong is no
reason to penality the people who actually got it right by using the way
decribed in the comp.lang.c faq.  This is my point, you are trying to penality
the people who wrote their security checks so it is defined C.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475