[LLVMbugs] [Bug 12139] New: CLANG copy ctor with default arguments disregard passed-in arguments when invoked with an Rvalue source object

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Feb 29 13:05:22 PST 2012


http://llvm.org/bugs/show_bug.cgi?id=12139

             Bug #: 12139
           Summary: CLANG copy ctor with default arguments disregard
                    passed-in arguments when invoked with an Rvalue source
                    object
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Keywords: miscompilation
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: abigagli at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Disclaimer: I had a hard time trying to squeeze out a meaningful Summary for
this, hope this makes sense after all.

This problem caught me for real while using an open source library, where the
effect was that an object copy constructed in this way didn't get the proper
values from the passed in arguments.

I reproduced a reduced test-case herebelow:


CODE:

#include <iostream>
#include <cstdint>
#include <cstddef>
#include <cassert>

enum value_t 
{ 
     ORIGINAL     = 0
    ,DEFAULT_ARG  = 1
    ,PASSED_IN    = 2
    ,DEFAULT_CTOR = 3
};

struct A
{
    A () : val(DEFAULT_CTOR) {}
    A (A const &rhs, value_t a_val=DEFAULT_ARG) : val(a_val) {}

    A makeA()
    {
        A a;
        return a;
    }

    A makeStaticA()
    {
        static A a;
        return a;
    }

    value_t val;

};

int main(int argc, const char *argv[])
{
    {
        //Rvalue makeA testcase: clang fails (Expected PASSED_IN, Actual
DEFAULT_CTOR), gcc succeeds (Expected PASSED_IN, Actual PASSED_IN)
        A original;
        original.val = ORIGINAL;

        A other(original.makeA(), PASSED_IN);

        std::cout << "Rvalue makeA:       " << (other.val == PASSED_IN) << "
(Expected:" << PASSED_IN << ", Actual:" << other.val << ")" << std::endl;
        //assert (other.val == PASSED_IN); 
    }

    {
        //Rvalue makeStaticA testcase: clang fails (Expected PASSED_IN, Actual
DEFAULT_ARG), gcc succeeds (Expected PASSED_IN, Actual PASSED_IN)
        A original;
        original.val = ORIGINAL;

        A other(original.makeStaticA(), PASSED_IN);

        std::cout << "Rvalue makeStaticA: " << (other.val == PASSED_IN) << "
(Expected:" << PASSED_IN << ", Actual:" << other.val << ")" << std::endl;
        //assert (other.val == PASSED_IN);
    }


    {
        //Lvalue makeA testcase: clang succeeds, gcc succeeds
        A original;
        original.val = ORIGINAL;

        A const &cloned = original.makeA();
        A other(cloned, PASSED_IN);

        std::cout << "Lvalue makeA:       " << (other.val == PASSED_IN) << "
(Expected:" << PASSED_IN << ", Actual:" << other.val << ")" << std::endl;
        //assert (other.val == PASSED_IN);
    }

    {
        //Lvalue makeStaticA testcase: clang succeeds, gcc succeeds
        A original;
        original.val = ORIGINAL;

        A const &cloned = original.makeStaticA();
        A other(cloned, PASSED_IN);

        std::cout << "Lvalue makeStaticA: " << (other.val == PASSED_IN) << "
(Expected:" << PASSED_IN << ", Actual:" << other.val << ")" << std::endl;
        //assert (other.val == PASSED_IN);
    }

    return 0;
}

I think the code is well formed, but when compiled on OSX 10.7.3, with clang++
from trunk (r151190) or Apple's Xcode 4.3 release, the outcome is:

OUTCOME:
Rvalue makeA:       0 (Expected:2, Actual:3)
Rvalue makeStaticA: 0 (Expected:2, Actual:1)
Lvalue makeA:       1 (Expected:2, Actual:2)
Lvalue makeStaticA: 1 (Expected:2, Actual:2)

While, as stated in the comments, all cases pass with gcc-4.6.2.

Either this is expected behavior and I apologize for not understanding the
standard, or it seems like something (related to maybe RVO?) causes the
additional argument to CCTOR to be ignored when an Rvalue for the source object
is passed to the CCTOR.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list