Andriy Gapon <> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #8 from Andriy Gapon <> ---
Also, a counter-example or, rather, an example of Clang being inconsistent:
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

Reply via email to