[llvm-bugs] [Bug 29118] LLVM O2: LLVM opt -O2 did wrong optimization happened on Power / x86.

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=29118

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #9 from Richard Smith <richard-llvm at metafoo.co.uk> ---
(In reply to comment #8)
> Hi Richard,
> 
> What is the C++ program source code you reduced into?

I assume you meant to ask someone else this?


(In reply to comment #7)
> I'm not seeing a clear reference for reading uninitialized memory in the
> working draft of the C++ standard from 2014-11-19, and the wording/behavior
> may have changed between C and C++?

See http://eel.is/c++draft/dcl.init#12 (at the time of writing; paragraph
numbers are subject to change...)

The only thing you can do with an uninitialized 'unsigned char' object is copy
it around (and doing so effectively makes the destination uninitialized). You
can't inspect it; in particular, comparing it (even to itself) results in
undefined behavior. (For types other than 'unsigned char', or 'char' if it is
unsigned, you can't even copy an uninitialized value around.)

So, in C++, this is UB.

In C, the rules are similar but different. An object initially holds an
indeterminate value (C 6.2.4/6). Such a value can be a trap representation, and
if it's accessed by an lvalue that is not of character type, the behavior is
undefined (C 6.2.6.1/5). However, if a character type is used to access an
uninitialized object, a valid value must (apparently) be produced, and absent
other requirements, it seems like that value must be the same across repeated
access to the same object -- but see
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1747.htm, some resolution to
which will presumably eventually be part of C.

Nonetheless, the C rules are known-broken today, and it seems reasonable to
implement some variant of the C++ rules even in C.

(In reply to comment #8)
> No matter what condition happened, it is no reason and does not make sence
> that the object doesn't equal to itself. The optimizer can not change the
> functionality.

As you yourself has observed, it can, and in this case it did.

> Whether we use GCC or IBM XLC, they all pass with optimization.

Undefined behavior can result in anything happening, including exactly what you
expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160829/5ed7e0a4/attachment.html>