[cfe-dev] Embedded conditionals not being evaluated correctly?

[Michael Jackson]

On Jul 29, 2010, at 1:03 PM, Douglas Gregor wrote:

> 
> On Jul 29, 2010, at 9:03 AM, Michael Jackson wrote:
> 
>> I have code that looks something like this:
>> 
>> 
>> bool evaluate(int i, int j) { return (i < j) ? true : false; }
>> 
>> void function()
>> {
>> int i = 0;
>> int j = 1;
>> if ( evaluate(i, j) == true ) { }
>> else { std::cout << "This is BAD" << std::endl; }
>> 
>> }
>> 
>> when I compile this code with clang (latest SVN head) and then run it I will get
>> the "This is BAD" printed out which is obviously NOT correct. If I change the code
>> to introduce an intermediate variable:
>> 
>> bool b = evaluate(i,j);
>> if ( b == true ) { }
>> else { std::cout << "This is BAD" << std::endl; }
>> 
>> this this compiles and runs just fine.
>> 
>> The fun part in all of this is that I am unable to create a small reproducible test case
>> for a bug report. I have used the OS X 10.6 gdb to debug through the code and verify what
>> should really be going on and that the executable is NOT matching what should be happening.
>> 
>> If I compile my code with GCC then I get the expected results. 
> 
> Unfortunately, that's not much for us to go on, since we don't know the code in question. It may not even be a Clang bug, if there's undefined behavior or order-of-evaluation issues involved.

 Sorry for the light details. I could point you to my actual code base (but it does need a few support libraries built first which I have repos for and is all CMake based). I have spent all morning trying to figure out what is happening and the runtime issues seem to jump around but are all related to this same type of problem.
> 
>> My question is simple: Are there known or questionable issues with clang++ and nested conditionals
>> that evaluate to C++ bool? I did some searches through the clang bugzilla but did not identify my problems.
> 
> 
> Does the actual condition involve temporary objects? The most likely culprit would be our handling of temporaries, e.g., that we destroy a temporary too soon, forget to destroy a temporary that matters, or perform some kind of unsanctioned copy.
> 
> 	- Doug

I _thought_ I noticed that if I instead did thins like "if (false == (true == someexpression()) )" would then exhibit the correct behavior but when I changed the code back and recompiled the error jumped to another line. Is there an intermediate form that I could print out that is human readable so someone could verify what _should_ be happening? My project is known to compile with GCC 4.2 (Apple), VS 2008 (32 and 64 bit) and GCC 4.4 from Ubuntu 10.04 and produces the same test results under all the compilers in question.

Thanks
Mike Jackson