https://bugs.llvm.org/show_bug.cgi?id=36610
Andriy Gapon <a...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #8 from Andriy Gapon <a...@freebsd.org> ---
Also, a counter-example or, rather, an example of Clang being inconsistent:
uint32_t
combine(uint16_t x, uint16_t y)
{
uint32_t r;
r &= 0xffff0000u;
r |= x;
r &= 0x0000ffffu;
r |= (uint32_t)y << 16;
return (r);
}
This code is compiled correctly.
In this statement
r = r & 0xffff0000u;
there is an access to unspecified value, so Clang was free to deem it the
undefined behavior, which it didn't.
I do not see any dramatic difference from the code using xor.
So, I still think that Clang has a problem reasoning about xor.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
