This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Infinite loop in dcraw with current GCC versions


>      This sounds like a compiler bug to me.  A statement
> of the form:
>
>     for (i=0; i < 12; i++) {
>       <code that doesn't change "i">
>     }
>
>      should never generate an infinite loop.

If there is undefined behavior, then not only can generate an infinite
loop but many kinds of nasty effects. The reasons are difficult to
explain, but you just have to think that at some moment the code has
to be converted to something like:

if(x) goto Y
else goto Z

and some optimization may decide that x is always false or always true
(because of something that goes inside the for-loop that cannot happen
ever has started a possibly long chain of transformations that
ultimately leads to that conclusion) Voilá: infinite loop.

GCC does not say: UB detected->let's generate an infinite loop to mess
up with developers.
Instead: this var++ operation which is at such a lower level that you
cannot see it in the original code may result in effect A or B, but
'B' cannot happen because it would be undefined behavior, thus it must
be A always, thus....ok, let's look at this function again...because
of that let's move this there and that here...and
then...thus...and...then...x is always false, remove this useless
goto.

Now, if you have figured out a way that GCC can detect a particular UB
triggered by user code and give an error (or even introduce an easy to
debug trap) and it has a low rate of false positives (false negatives
are acceptable) and those false positives are easy to work around,
then please open a PR and explain it in detail. Patches are even
better.

Those options that you are silencing:

-Wno-aggressive-loop-optimizations -Wno-maybe-uninitialized -Wno-array-bounds

are trying very hard to warn you about possible problems that are very
hard to debug. Yes, they are not perfect, but it may be worth it to
examine case by case whether they point to real problems and disable
them only for false positives (that is what "#pragma GCC diagnostics"
are for). You could also open PRs in gcc bugzilla for the false
positives, some of them get eventually fixed and the warnings get
better in every release.

Cheers,

Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]