[llvm-bugs] [Bug 36929] New: [Regression] Clang 6 generated code produces incorrect result with -02 and above

[via llvm-bugs]

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

            Bug ID: 36929
           Summary: [Regression] Clang 6 generated code produces incorrect
                    result with -02 and above
           Product: clang
           Version: 6.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: budai at tresorit.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20137
  --> https://bugs.llvm.org/attachment.cgi?id=20137&action=edit
Source code, runner script and results for the original example

We have a code that uses a custom allocator with `std::vector` to provide some
extra memory safety features. After switching to Clang 6, our tests started to
fail on 32-bit x86 Linux platforms.

We boiled down our code to this simple example with no dependencies but STL:

    #include <cstddef>
    #include <vector>

    template<typename T>
    struct my_allocator {
        typedef T value_type;

        T* allocate(size_t n) {
            return new T[n];
        }

        void deallocate(T* p, size_t n) {
            delete[] p;
        }

        template<typename U, typename... A>
        void construct(U* p, A... a) {
            new ((void*)p)U(std::forward<A>(a)...);
        }
    };

    int main() {
        std::vector<char, my_allocator<char>> vec(32, 'a');
        vec.insert(vec.begin(), 1, 'b');
        return vec.size() == 33 ? 0 : 1;
    }

This code should extend `vec` by one by inserting a single element on the
beginning, but it produces incorrect results (exit code 1) with Clang 6 with
libcxx, cross-compiling from 64 to 32-bit Linux in optimization level 2 and
above:

    clang 5, x86_32, libstdc++, -O0: ok
    clang 5, x86_32, libstdc++, -O1: ok
    clang 5, x86_32, libstdc++, -O2: ok
    clang 5, x86_32, libstdc++, -O3: ok
    clang 5, x86_32, libc++, -O0: ok
    clang 5, x86_32, libc++, -O1: ok
    clang 5, x86_32, libc++, -O2: ok
    clang 5, x86_32, libc++, -O3: ok
    clang 5, x86_64, libstdc++, -O0: ok
    clang 5, x86_64, libstdc++, -O1: ok
    clang 5, x86_64, libstdc++, -O2: ok
    clang 5, x86_64, libstdc++, -O3: ok
    clang 5, x86_64, libc++, -O0: ok
    clang 5, x86_64, libc++, -O1: ok
    clang 5, x86_64, libc++, -O2: ok
    clang 5, x86_64, libc++, -O3: ok
    clang 6, x86_32, libstdc++, -O0: ok
    clang 6, x86_32, libstdc++, -O1: ok
    clang 6, x86_32, libstdc++, -O2: ok
    clang 6, x86_32, libstdc++, -O3: ok
    clang 6, x86_32, libc++, -O0: ok
    clang 6, x86_32, libc++, -O1: ok
    clang 6, x86_32, libc++, -O2: fail 1
    clang 6, x86_32, libc++, -O3: fail 1
    clang 6, x86_64, libstdc++, -O0: ok
    clang 6, x86_64, libstdc++, -O1: ok
    clang 6, x86_64, libstdc++, -O2: ok
    clang 6, x86_64, libstdc++, -O3: ok
    clang 6, x86_64, libc++, -O0: ok
    clang 6, x86_64, libc++, -O1: ok
    clang 6, x86_64, libc++, -O2: ok
    clang 6, x86_64, libc++, -O3: ok

With using either Clang 5, stdlibc++, or x86_64 target, or removing/changing
the `construct` method fixes the generated code, yielding in correct results.

You can find the source code, runner script and the above results in the
attachment `original.tar.gz`.

-- 
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/20180328/083b73c9/attachment.html>