Re: strange optimisation behaviour

[Paul Pluzhnikov]

Gav Wood <gav@cs.york.ac.uk> writes:

> with
> optimisations (-O2) seems to make gcc compile this code instead:
> 
> Child c;
> while(1)
> {
>         c = Child(parent, someEndOfLifeAction);
>         // do something with the child
> }
> 
> this would work fine except for the problem that two children coexist at the
> same time, breaking my system.

We use the same pattern quite a lot, and had no problem with any
of the versions of g++ (but see below [1]). 

It is quite likely that your diagnosis is incorrect, but impossible
to tell for sure without a test case.

You should always (a) suspect your own code before you suspect the
compiler/runtime libraries/OS etc.

And (b) always begin convincing yourself that it is your own bug
by trying to construct the simplest test case possible, which still
demonstrates the problem.

If you manage to construct such a case (often you'll discover your
bug yourself while trying to make the test case), post it (here) and
specify which version of g++ and on which platform, and your mistake
will be pointed out to you :-) or someone will confirm that this
is a gcc bug, and you'll be able to file it with the gcc maintainers.

> from looking around on google, i see that a likely suspect is
> -fstrength-reduce.

Anything is a likely suspect, but your code is the likeliest
of all.

> is there anyway i can disable gcc's optimisation purely for my Child/parent
> system (or at least on some particular loops) without actually turning the
> offendinf optimisation off?

There is probably a set of optimization options that makes your bug
(if it is your bug, which is likely) to hide.

Don't do it -- the bug will show up again, as incorrect results of
computation, or something else quite embarrassing ...

> if i was to turn off globally for my system (and any extensions), would it
> likely cause a significant speed hit (given the software is mostly
> mathematical stuff with potentially a few loops in?)

That's quite likely, but there is no way for anybody but you to tell:
measure it, and you'll know the answer.

[1] I did recently see is a bug in g++-2.95.3 for code like this:

    while (1) {
      ...
       label: ...
       Child c(...); ...
       goto label; // ~Child should fire here, but doesn't for g++2.95.3
    }

That bug is fixed in all g++-3.x revisions I've tried.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.