Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clang 3.5.0 generates invalid code for the conditional/ternary operator with -O1 or above in some cases #22424

Closed
llvmbot opened this issue Dec 29, 2014 · 1 comment
Labels
bugzilla Issues migrated from bugzilla worksforme Resolved as "works for me"

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 29, 2014

Bugzilla Link 22050
Resolution WORKSFORME
Resolved on Dec 29, 2014 13:29
Version trunk
OS Linux
Attachments example code
Reporter LLVM Bugzilla Contributor
CC @majnemer

Extended Description

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.

@majnemer
Copy link
Mannequin

majnemer mannequin commented Dec 29, 2014

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)

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
@Quuxplusone Quuxplusone added the worksforme Resolved as "works for me" label Jan 20, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla worksforme Resolved as "works for me"
Projects
None yet
Development

No branches or pull requests

2 participants