List of optimizations enabled by -O1 seems incorrect

List of optimizations enabled by -O1 seems incorrect

[Nikos Chantziaras]

I'm trying to discover which GCC optimization is responsive for a 
runtime error reported by Valgrind:

   "Conditional jump or move depends on uninitialised value(s)"

This pops up when compiling with -O1 and above.  The code in question is 
C++ and is of this form:

   if (!foo && !bar)

The uninitialized variable is 'bar'.  However, it shouldn't be evaluated 
at all due to short-circuit if rules.  Of course the optimizer is free 
to evaluate it anyway if there are no side-effects when doing so.

So just out of interest, I'm trying to find out which optimization is 
responsible for this.  I looked up the GCC info pages and I compiled 
with -O1 and then disabled the optimizations enabled by -O1 one by one, 
in hope to hit the one that triggers the error, until all of them were 
disabled in the end:

   -O1 -fno-auto-inc-dec -fno-cprop-registers -fno-dce -fno-defer-pop
   -fno-delayed-branch -fno-dse -fno-guess-branch-probability
   -fno-if-conversion2 -fno-if-conversion -fno-inline-small-functions
   -fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants
   -fno-split-wide-types -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename
   -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre
   -fno-tree-sra -fno-tree-ter -fno-unit-at-a-time

However, the error still appears which makes me conclude that the above 
list of -O1 optimizations is not complete.  Which ones am I missing?

I tested with GCC 4.3.4 and 4.4.1.

Re: List of optimizations enabled by -O1 seems incorrect

[Andrew Haley]

Nikos Chantziaras wrote:
> I'm trying to discover which GCC optimization is responsive for a
> runtime error reported by Valgrind:
> 
>   "Conditional jump or move depends on uninitialised value(s)"
> 
> This pops up when compiling with -O1 and above.  The code in question is
> C++ and is of this form:
> 
>   if (!foo && !bar)
> 
> The uninitialized variable is 'bar'.  However, it shouldn't be evaluated
> at all due to short-circuit if rules.  Of course the optimizer is free
> to evaluate it anyway if there are no side-effects when doing so.
> 
> So just out of interest, I'm trying to find out which optimization is
> responsible for this.  I looked up the GCC info pages and I compiled
> with -O1 and then disabled the optimizations enabled by -O1 one by one,
> in hope to hit the one that triggers the error, until all of them were
> disabled in the end:
> 
>   -O1 -fno-auto-inc-dec -fno-cprop-registers -fno-dce -fno-defer-pop
>   -fno-delayed-branch -fno-dse -fno-guess-branch-probability
>   -fno-if-conversion2 -fno-if-conversion -fno-inline-small-functions
>   -fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants
>   -fno-split-wide-types -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename
>   -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre
>   -fno-tree-sra -fno-tree-ter -fno-unit-at-a-time
> 
> However, the error still appears which makes me conclude that the above
> list of -O1 optimizations is not complete.  Which ones am I missing?

Not all optimizations are switchable.  If you want to know the complete
set of switches, compile with -fverbose-asm and look at the .s file.

If you really want to know when a particular optimization was done,
you'll have to look at the dumps.

Andrew.

Re: List of optimizations enabled by -O1 seems incorrect

[Nikos Chantziaras]

On 08/13/2009 09:06 PM, Andrew Haley wrote:
> Nikos Chantziaras wrote:
>> I'm trying to discover which GCC optimization is responsive for a
>> runtime error reported by Valgrind:
>>
>>    "Conditional jump or move depends on uninitialised value(s)"
>>
>> This pops up when compiling with -O1 and above.  The code in question is
>> C++ and is of this form:
>>
>>    if (!foo&&  !bar)
>>
>> The uninitialized variable is 'bar'.  However, it shouldn't be evaluated
>> at all due to short-circuit if rules.  Of course the optimizer is free
>> to evaluate it anyway if there are no side-effects when doing so.
>>
>> So just out of interest, I'm trying to find out which optimization is
>> responsible for this.  I looked up the GCC info pages and I compiled
>> with -O1 and then disabled the optimizations enabled by -O1 one by one,
>> in hope to hit the one that triggers the error, until all of them were
>> disabled in the end:
>>  [...]
>>
>> However, the error still appears which makes me conclude that the above
>> list of -O1 optimizations is not complete.  Which ones am I missing?
>
> Not all optimizations are switchable.  If you want to know the complete
> set of switches, compile with -fverbose-asm and look at the .s file.

Thanks for the tip.  Looking at the generated assembly files, I finally 
solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both 
variables in one CPU instruction.  It's faster but circumvents 
short-circuit "if" rules and Valgrind prints an error.

Re: List of optimizations enabled by -O1 seems incorrect

[Kevin P. Fleming]

Nikos Chantziaras wrote:

> Thanks for the tip.  Looking at the generated assembly files, I finally
> solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both
> variables in one CPU instruction.  It's faster but circumvents
> short-circuit "if" rules and Valgrind prints an error.

Then that seems very broken; you should not have to have initialized a
variable to avoid this issue, since short-circuit evaluation is defined
in the C standard.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: List of optimizations enabled by -O1 seems incorrect

[Andrew Haley]

Kevin P. Fleming wrote:
> Nikos Chantziaras wrote:
> 
>> Thanks for the tip.  Looking at the generated assembly files, I finally
>> solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both
>> variables in one CPU instruction.  It's faster but circumvents
>> short-circuit "if" rules and Valgrind prints an error.
> 
> Then that seems very broken; you should not have to have initialized a
> variable to avoid this issue, since short-circuit evaluation is defined
> in the C standard.

Yes, but it's covered by the "as if" rule: if no conforming program could
ever notice the difference, an optimization is allowed.

Andrew.

Re: List of optimizations enabled by -O1 seems incorrect

[Kevin P. Fleming]

Andrew Haley wrote:
> Kevin P. Fleming wrote:
>> Nikos Chantziaras wrote:
>>
>>> Thanks for the tip.  Looking at the generated assembly files, I finally
>>> solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both
>>> variables in one CPU instruction.  It's faster but circumvents
>>> short-circuit "if" rules and Valgrind prints an error.
>> Then that seems very broken; you should not have to have initialized a
>> variable to avoid this issue, since short-circuit evaluation is defined
>> in the C standard.
> 
> Yes, but it's covered by the "as if" rule: if no conforming program could
> ever notice the difference, an optimization is allowed.

Well, I guess that was my point, stated in another way. I'm certainly no
C standard expert, but I didn't think his program was 'non-conforming'
in any way.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: List of optimizations enabled by -O1 seems incorrect

[Ian Lance Taylor]

"Kevin P. Fleming" <kpfleming@digium.com> writes:

> Andrew Haley wrote:
>> Kevin P. Fleming wrote:
>>> Nikos Chantziaras wrote:
>>>
>>>> Thanks for the tip.  Looking at the generated assembly files, I finally
>>>> solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both
>>>> variables in one CPU instruction.  It's faster but circumvents
>>>> short-circuit "if" rules and Valgrind prints an error.
>>> Then that seems very broken; you should not have to have initialized a
>>> variable to avoid this issue, since short-circuit evaluation is defined
>>> in the C standard.
>> 
>> Yes, but it's covered by the "as if" rule: if no conforming program could
>> ever notice the difference, an optimization is allowed.
>
> Well, I guess that was my point, stated in another way. I'm certainly no
> C standard expert, but I didn't think his program was 'non-conforming'
> in any way.

Andrew's point was not that the program was non-conforming.  His point
was that a conforming program could not detect this optimization.  And,
indeed, it couldn't.  The issue was reported by valgrind, not by the
program itself.

Ian

Re: List of optimizations enabled by -O1 seems incorrect

[Kevin P. Fleming]

Ian Lance Taylor wrote:

> Andrew's point was not that the program was non-conforming.  His point
> was that a conforming program could not detect this optimization.  And,
> indeed, it couldn't.  The issue was reported by valgrind, not by the
> program itself.

OK, I get it now. This is the same sort of thing we see when strlen()
reads past the end of the string, but doesn't actually use the extra
bytes it read as part of its operation... valgrind complains, but the
program works as expected.

However, in this case, valgrind didn't say it was a read of an
uninitialized variable, it said the conditional jump depended on the
value of an uninitialized variable; either that's a valgrind bug, or the
jump may take different paths based on that content, or I'm not really
awake enough this morning yet :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: List of optimizations enabled by -O1 seems incorrect

[Andrew Haley]

Kevin P. Fleming wrote:
> Ian Lance Taylor wrote:
> 
>> Andrew's point was not that the program was non-conforming.  His point
>> was that a conforming program could not detect this optimization.  And,
>> indeed, it couldn't.  The issue was reported by valgrind, not by the
>> program itself.
> 
> OK, I get it now. This is the same sort of thing we see when strlen()
> reads past the end of the string, but doesn't actually use the extra
> bytes it read as part of its operation... valgrind complains, but the
> program works as expected.
> 
> However, in this case, valgrind didn't say it was a read of an
> uninitialized variable, it said the conditional jump depended on the
> value of an uninitialized variable; either that's a valgrind bug, or the
> jump may take different paths based on that content, or I'm not really
> awake enough this morning yet :-)

gcc looks at

  if (!foo && !bar)
    ...

and turns it into

  if (foo|bar)
    goto x;
  ...
 x:

So, from Valgrind's point of view, the branch depends on the value of
bar, which is uninitialized.  We know that if foo is nonzero there is
no such dependency, but Valgrind would have to do some heavyweight
dependency analysis to figure that one out.

Andrew.

Re: List of optimizations enabled by -O1 seems incorrect

[Kevin P. Fleming]

Andrew Haley wrote:

> gcc looks at
> 
>   if (!foo && !bar)
>     ...
> 
> and turns it into
> 
>   if (foo|bar)
>     goto x;
>   ...
>  x:
> 
> So, from Valgrind's point of view, the branch depends on the value of
> bar, which is uninitialized.  We know that if foo is nonzero there is
> no such dependency, but Valgrind would have to do some heavyweight
> dependency analysis to figure that one out.

Ding-ding-ding... and the winner is, I'm not awake enough yet this
morning :-) Thanks for the explanation!

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: List of optimizations enabled by -O1 seems incorrect

[Nikos Chantziaras]

On 08/13/2009 10:38 PM, Kevin P. Fleming wrote:
> Nikos Chantziaras wrote:
>
>> Thanks for the tip.  Looking at the generated assembly files, I finally
>> solved the "mystery": GCC uses SSE/SSE2 instructions to fetch both
>> variables in one CPU instruction.  It's faster but circumvents
>> short-circuit "if" rules and Valgrind prints an error.
>
> Then that seems very broken; you should not have to have initialized a
> variable to avoid this issue, since short-circuit evaluation is defined
> in the C standard.

Damn, I thought that was it.  Turns out it has nothing to do with SSE 
(and the like) since compiling for -m32 -march=i386 and additionally 
specifying -mno-sse/-mno-sse2/-mno-sse3/etc also triggers the "bug".

It has to be a "hidden" optimization that has no command-line switch. 
The biggest problem is that I'm not able to produce a test case for it.

RE: List of optimizations enabled by -O1 seems incorrect

[John (Eljay) Love-Jensen]

Hi Nikos,

> However, the error still appears which makes me conclude that the above list of -O1 optimizations is not complete.  Which ones am I missing?

Most optimizations are enabled with -O1 that do not have an individually twiddle-able corresponding -fSomething flag.

Sincerely,
--Eljay

Re: List of optimizations enabled by -O1 seems incorrect

[Bill McEnaney]

What would it turn this into, Andrew?

if (!(foo || bar))

> Andrew Haley wrote:
> 
> > gcc looks at
> > 
> >   if (!foo && !bar)
> >     ...
> > 
> > and turns it into
> > 
> >   if (foo|bar)
> >     goto x;
> >   ...
> >  x:
> > 
> > So, from Valgrind's point of view, the branch depends on the value of
> > bar, which is uninitialized.  We know that if foo is nonzero there is
> > no such dependency, but Valgrind would have to do some heavyweight
> > dependency analysis to figure that one out.
> 
> Ding-ding-ding... and the winner is, I'm not awake enough yet this
> morning :-) Thanks for the explanation!
> 
> -- 
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: kpfleming@digium.com
> Check us out at www.digium.com & www.asterisk.org
> 
> 

________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org