LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 22050 - clang 3.5.0 generates invalid code for the conditional/ternary operator with -O1 or above in some cases
Summary: clang 3.5.0 generates invalid code for the conditional/ternary operator with ...
Status: RESOLVED WORKSFORME
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-29 09:26 PST by David Nichols
Modified: 2014-12-29 13:29 PST (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
example code (545 bytes, text/x-c++src)
2014-12-29 09:26 PST, David Nichols
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Nichols 2014-12-29 09:26:56 PST
Created attachment 13602 [details]
example code

the following code when built with clang 3.5.0 with -O1 or above is compiled incorrectly:

#include <stdio.h>

union u {
   size_t _refptr;

   void setPtr(int* refptr, bool readonly = false) {
      _refptr = (size_t)refptr;
      if (readonly)
         _refptr |= 1;
   }

   int* getPtr() const {
      // the line below is compiled incorrectly with clang++ 3.5.0 -O1 or above
      return (int*)((_refptr & 1L) ? (_refptr ^ 1L) : _refptr);
   }
};

int main(int argc, char *argv[]) {
   u u;
   int i = 100;
   
   u.setPtr(&i);
   printf("i: %p p(i): %p: %s\n", &i, u.getPtr(), &i == u.getPtr() ? "OK" : "ERROR");

   return 0;
}

-- example output is:
i: 0x7fff6adf3dac p(i): 0x7fff6adf3dad: ERROR

basically the conditional operator is evaluated with the opposite arguments according to its boolean operand expression in this case.

I tried some other simple cases and it was OK - no clue why this is happening, but in my case it's a big bug (I store values in the low bits of some pointers using this trick in some cases to optimize memory usage).

Note that compiling without optimizations results in correct code generation.  Maybe there's something awry with the optimizer with this case.
Comment 1 David Majnemer 2014-12-29 13:29:56 PST
This is almost certainly caused by r210006 which was subsequently fixed in r222856.

I'm afraid that the upcoming 3.5.1 will not have this fix but trunk does and 3.6.0 will.

For the record, it does not reproduce with:
clang version 3.6.0 (trunk 224918) (llvm/trunk 224890)