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

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

------- 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 leads to code that does unexpected things, such as
breaking existing security checks.

> >I don't see why making make_range in fold-const.c 
> It is already if you use -fwrapv.

No, it is not.  What happens is that make_range will generate invalid ranges in
any case, and then optimizations depending on those ranges will be skipped when
-fwrapv is specified.  (Please correct me if I'm reading the code wrong, even
though I'm maintaining an open source compiler myself, I don't have much
experience reading gcc code.)

What this means is that in the example you posted above, even though the
compiler *could* compute a correct range and properly fold the if statement
even given LIA-1 compliant overflow behaviour, gcc will skip the optimization
when passed -fwrapv.

After reading the code, I can certainly see why making -fwrapv is something
you'd rather avoid: it makes a lot of optimizations go down the drain. But:
this wouldn't have to happen if you fixed make_range to do something sensible
instead.  I wonder why this didn't jump right into the face of the person who
implemented -fwrapv, it must have been a real pain to track down all the
usages.

> The problem here is that the people who added these security checks in the
> first place did not know C.  So either GCC can be changed or these programs can
> be fixed by the way comp.lang.c faq recommends or by using -fwrapv.  If we
> change GCC, you punish the people who actually write defined C so that is out
> of the question.  

Well, maybe they didn't.  I did a non-representative survey with the C
programmers I know: everybody assumed overflow of signed ints would behave as
it does for the underlying machine representation.  Not a single one was aware
of the danger.  And we're talking of people with 20+ years of professional
experience in the field here.

And I think people who do know can be expected to read the gcc manual to figure
out that there were a -fnowrapv option to make their code go a wee bit faster.

Did I mention that I have yet to see a convincing example of a case where
undefinedness of signed overflow actually makes code go faster that isn't per
definition a security problem?  Especially after having learned from reading
the gcc code that -fwrapv turns off a whole lot more optimizations than it has
to?

> I think the real issue that some of the security folks want to check after the
> fact that something happened instead of before it happend which is the correct
> way to do anything.

No, I would call any security expert who refuses to learn that there is a
problem with signed overflow and how to check for that correctly an idiot.  The
issue here is really how to deal with the existing body of code out there that
was written in the implicit assumption of LIA-1 compliant behaviour.

This is about risk management for all the Linux systems out there.  It is not
about "whose fault is it".  It's about "Houston, we have a problem, and need it
fixed".


-- 


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