> On Jun 14, 2017, at 9:06 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
>
> On 14 June 2017 at 16:58, David Barto wrote:
>> I have the following code. It is compiled at -O3 using g++
>> with the -std=gnu++14 option.
>>
>> The code in question is the following:
>>
>> if ( !testbit(rec_scan0,63) && f20type == URI ) {
>>
>> Valgrind claims that the "Conditional jump or move depends on uninitialized value(s)"
>>
>> Well, only if !testbit(rec_scan0,63) should we check the f20type value,
>> right? Apparently GCC is reordering the expression. This makes no
>> sense to me, from the old school of C coding.
>>
>> My question is 2 fold:
>> 1 - is this legal (and I think it is) and if so would someone point to the relevant
>> part of the C++ standard. (I can’t find it)
>
> It depends on whether the default && is used, or if the types of the
> expressions on either side cause an user-defined operator&& to be
> used. The built-in && short-circuits, and the LHS should not be
> evaluated if the RHS is false. An overloaded operator&& doesn't
> short-circuit.
>
> Assuming the types of the LHS and RHS are both bool, it should
> short-circuit and shouldn't evaluate the RHS if the LHS is false.
The && operator is not overloaded in this case. This is generic ‘C’ code
being compiled by the C++ compiler. The fact that the compiler is
reordering to evaluate the right hand size first is what I’m wondering
about. It doesn’t make sense.
David Barto
barto@xxxxxxxxxxxxxxxxxxxxxx
Sometimes, my best code does nothing. Most of the rest of it has bugs.
