[llvm-bugs] [Bug 32824] New: Possible incorrect code generation on use of initializer_list in range-based for loop

[via llvm-bugs]

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

            Bug ID: 32824
           Summary: Possible incorrect code generation on use of
                    initializer_list in range-based for loop
           Product: clang
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jasonr at 3db-labs.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

This issue was originally posted at
http://stackoverflow.com/questions/43624400/is-this-unsafe-usage-of-a-braced-initializer-list-in-a-range-based-for-loop
- I didn't get much of an answer there, and I'm inclined to think it might be a
clang bug.

My example program is as follows:

    #include <initializer_list>
    #include <memory>

    struct Test
    {
        int x;
    };

    int main()
    {
        std::unique_ptr<Test> a(new Test);
        std::unique_ptr<Test> b(new Test);
        std::unique_ptr<Test> c(new Test);
        int id = 0;
        for(auto t : std::initializer_list<Test*>({a.get(), b.get(), c.get()}))
            t->x = id++;
        return 0;
    }

I compile this with the following command line:

    clang++ -std=c++11 -O3 crash.cc -o crash

The example is online at https://godbolt.org/g/r9uOEd as well.

When I compile the code using clang versions less than or equal to 3.8.1, I get
what I would expect; the generated assembly looks like:

    main:                                   # @main
            xor     eax, eax
            ret

No problem there. For clang 3.9.0, 3.9.1, and 4.0.0 (I haven't tested anything
newer), I get the following:

    main:                                   # @main
            mov     rax, qword ptr [rsp - 24]
            mov     dword ptr [rax], 0
            mov     rax, qword ptr [rsp - 16]
            mov     dword ptr [rax], 1
            mov     rax, qword ptr [rsp - 8]
            mov     dword ptr [rax], 2
            xor     eax, eax
            ret

It looks like the compiler optimized away the construction of the `Test`
objects; it never invokes `operator new` to allocate memory for them, but it
still runs the body of the for loop, dereferencing pointers that were never
initialized. This obviously results in a segfault.

If I subtly tweak the example, taking out the parentheses used in the
construction of the initializer_list in the range-based for loop, like this:

    #include <initializer_list>
    #include <memory>

    struct Test
    {
        int x;
    };

    int main()
    {
        std::unique_ptr<Test> a(new Test);
        std::unique_ptr<Test> b(new Test);
        std::unique_ptr<Test> c(new Test);
        int id = 0;
        for(auto t : std::initializer_list<Test*>{a.get(), b.get(), c.get()})
            t->x = id++;
        return 0;
    }

Then I get good code generation on all clang versions that I've tried. What
I've been trying to understand is whether this is a compiler bug or undefined
behavior. In the first example, is the inner braced initializer treated as a
temporary whose lifetime ends after the range-based for loop is initialized,
and therefore gets optimized out?

-- 
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/20170427/82c53f18/attachment.html>