[llvm-bugs] [Bug 40402] using optimizations yields different output

[via llvm-bugs]

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

Tim Northover <t.p.northover at gmail.com> changed:

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

--- Comment #6 from Tim Northover <t.p.northover at gmail.com> ---
Unfortunately there are more problems in the source. I probably should have
read it more thoroughly the first time but I just ran -fsanitize=undefined over
it.

This time the issue is that all objects in C and C++ can only have one type,
and must always be used as that type (or "char *", known as the "omnipotent
char"). It's not valid to access a single object through both a "uint64_t *" to
a "uint16_t *" for example.

If you need to do that kind of thing in C, the recommended solution is to
memcpy from one object to another with the desired type. The compiler is very
good at spotting that idiom and will generally turn it into the optimal code.
In C++20 there's going to be a "bit_cast<newtype>" function to make it less
clunky.

Alternatively (and this is how I verified it was the issue) both Clang and GCC
support a "-fno-strict-aliasing" option which essentially switches to a dialect
of the language without that rule.

Also, your initial malloc is wonky. -fsanitize=address points out that your
alignment step moves past the end of the object. This isn't what's causing the
problem though, just thought I'd point it out.

I'll close it again for now.

-- 
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/20190302/6a85f1e7/attachment.html>