Hi Jason,
> The testcase in 57728 demonstrates that we have been treating
> functions explicitly defaulted in the class body inconsistently with
> explicit instantiation: an extern instantiation causes them not to be
> generated, but a normal explicit instantiation doesn't cause them to
> be emitted, leading to link errors.
>
> After discussing this issue with other vendors (who had the same bug),
> we have decided to treat these functions like implicitly declared
> members, so explicit instantiation consistently doesn't affect them.
>
> The second patch addresses a FIXME I noticed while looking at this:
> there's no reason for us to be calling a trivial default constructor
> in the first place.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
[...]
> diff --git a/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> b/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> new file mode 100644
> index 0000000..5c14c01
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> @@ -0,0 +1,17 @@
> +// PR c++/57728
> +// { dg-do link { target c++11 } }
[...]
> diff --git a/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> b/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> index 5c14c01..912d507 100644
> --- a/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> +++ b/gcc/testsuite/g++.dg/cpp0x/explicit12.C
> @@ -15,3 +15,5 @@ int main()
> {
> A<int> a;
> }
> +
> +// { dg-final { scan-assembler-not "_ZN1AIiEC1Ev" } }
>
This test currently shows up as UNRESOLVED, and g++.log has
g++.dg/cpp0x/explicit12.C -std=c++11 : output file does not exist
Was this meant as a compile instead of link test, like the companion
explicit11.C?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
