[cfe-dev] interesting c++ puzzle

[Richard Smith]

On Wed, Jan 16, 2013 at 1:53 PM, reed kotler <rkotler at mips.com> wrote:
> Thanks for the clues on fixing this bug.
>
> I understand that 5.cpp and 6.cpp are not the source of the of the crash,
> but they involve part of what the crash is trying to do and the result was
> unexpected to me so I wanted to understand this better. At least two other
> compilers get a different result for 6.cpp than g++ and clang++.

I would expect that MSVC accepts 6.cpp, because it allows non-const
references to bind to temporaries.

Perhaps the other compiler which accepts it does the same, or perhaps
it doesn't perform semantic checking for elidable copies, or perhaps
it doesn't suppress the implicit copy constructor when a B(B&)
constructor is declared...

> On 01/16/2013 01:37 PM, Richard Smith wrote:
>>
>> Neither 5.cpp nor 6.cpp have the problematic pattern.
>>
>> The issue is that (for the case in PR8539 comment#2), when trying to
>> construct a B from a B temporary, we can't use the B(B&) constructor
>> and try the B(const A&) constructor. That tries to copy-initialize an
>> A temporary from the B temporary, which looks at A's constructors and
>> selects the A(B) constructor.
>>
>> Then overload resolution terminates and we perform the initialization,
>> and that tries to construct a B from a B temporary. And around we go.
>> It should be straightforward to detect this and reject this after
>> constructing an InitializationSequence; if the first step is a
>> SK_ConstructorInitialization which performs the same conversion as the
>> overall sequence, then we have an error.
>>
>> On Wed, Jan 16, 2013 at 1:04 PM, reed kotler <rkotler at mips.com> wrote:
>>>
>>> I'm far from a c++ language lawyer. I decided, in my spare time,  to work
>>> on
>>> some involved language related clang bugs to reverse that situation.
>>>
>>> I picked this one http://llvm.org/bugs/show_bug.cgi?id=8539 .
>>>
>>> I've been trying to understand the rules surrounding this bug, which
>>> interestingly enough used to cause g++ to crash and still causes clang as
>>> well as the sun compiler to crash.
>>>
>>> Here is an interesting pair of test cases I came up with.
>>>
>>> 5.cpp gets the same result on at least 4 compilers. It compiles
>>> correctly,
>>> and prints B(1)
>>>
>>> 6.cpp does not compile on clang++ or g++.
>>>
>>> This seems illogical to me. It does not call the copy constructor in
>>> 5.cpp
>>> but in 6.cpp it tails
>>> to compile because it can't find a valid copy constructor.
>>>
>>> I have a number of other related test cases. I want to make a fix that
>>> really fixes this general class of issues and not just make the crash go
>>> away for that one test case.
>>>
>>> On other compilers, both 5.cpp and 6.cpp get the same result.
>>>
>>> Tia.
>>>
>>> Reed
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>