bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC optimizes integer overflow: bug or feature?


From: Robert Dewar
Subject: Re: GCC optimizes integer overflow: bug or feature?
Date: Thu, 21 Dec 2006 23:02:07 -0500
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

Paul Brook wrote:

Who says the optimisation is valid? The language standard?

The example was given as something that's 100% safe to optimize. I'm disagreeing with that assertion. The use I describe isn't that unlikely if the code was written by someone with poor knowledge of C.

My point is that it's not that hard to invent plausible code that "breaks" when pretty much any transformation is applied. We have to decide how close to the standard we want to fly.

I did not find that plausible at all, for someone to depend on memory
mapped references without using volatile is indeed such junk code that
we don't need to care about it.

"Optimization should never change the behavior of a valid program" is useful definition because it forces you to define what constitutes a valid program.

No, no, let's not start calling these programs that violate the standard
valid. That's going much too far. Also, sometimes code is inherently
non-deterministic, so you have to be careful talking about change of
behavior.

"Optimization should never result in violating the required semantics of
a valid (standard) C program"

is of course criterion 1

Criterion 2 is something like "Optimization should not cause non-valid
non-standard programs to fail as a result of using a common idiom, which
though non-standard is generally expected to "work", unless the optimization can be demonstrated to be valuable enough to be worth
generating the effective incompatibility with expected practice"

is a half baked statement of criterion 2 (and it is not so easy to
bake this one!)

There's actually a much better reason why the transformation is not safe. Consider a data structure where a byte of 1 indicates the end of the object. Under normal circumstances short-circuiting of the && operator prevents anything bad happening. If you merge the two accesses you've just read past the end of the object and all kinds of bad things may happen (eg. a segfault).

You may well know that it is safe to go one past the last object (generally this will be the case, because of the strange semantics
of being allowed to address past the last byte). You do indeed have
to be careful of this

P.S. I think I'm repeating myself now, so this is the last time I intend to comment on this thread.

OK!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]