[LLVMbugs] [Bug 19924] New: Excessive copying of temporaries on ARM

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Jun 2 14:28:07 PDT 2014


            Bug ID: 19924
           Summary: Excessive copying of temporaries on ARM
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm-bugs at quasiparticle.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Some code seems to confuse clang/LLVM massively under arm-none-eabi with
-ffreestanding. The code below allocates three temporaries on the stack and
copies from one to another, on all optimization levels.

This behaviour is not triggered under a number of slightly different

 * no -ffreestanding, or for x86, or x86_64
 * T::status is larger than char
 * Struct::set cpy is Struct, not Struct&&
 * main x is allocated as x{}, x{{0,0}} or anything else, with or without x.x.*
 * set called at most twice
 * set doesn't write cpy.x.status
 * T::status is preceded by another char member
 * or two
 * or by a short, but not a short and a char

I'm pretty sure there's a lot more in here that can flip this around. I've gone
through the standard am I'm convinced that this piece of code does not exhibit
undefined behaviour, and since clang does the right thing(tm) under a lot of
different circumstances, I think this is actually a corner case of some
optimizer pass.


struct T {
    void* p;
    char status;

    T() : p(0), status(0) {}

struct Struct {
    T x;

    Struct set()
        auto&& cpy = Struct(*this);
        return cpy;

int main()
    Struct x;


    return 0;

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/20140602/822edbdb/attachment.html>

More information about the llvm-bugs mailing list