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

[Douglas Gregor]

On Jul 29, 2010, at 10:09 AM, Michael Jackson wrote:

> 
> 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? 

Yes, you can use -S -emit-llvm on your command line to get LLVM IR. It's a fairly readable intermediate representation.

	- Doug