[Bug c++/53360] New: Problems with -std=gnu++0x

[Bug c++/53360] New: Problems with -std=gnu++0x

[andigor at mail dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360

             Bug #: 53360
           Summary: Problems with -std=gnu++0x
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: andigor@mail.ru


I have such code:


template<class CppType>
struct make_literal;

template<>
struct make_literal<int> {
  typedef int type;
};

template<class T>
struct make_expression {
  typedef typename make_literal<T>::type type;
};

struct column {
  template<class T>
  typename make_expression<T>::type operator= (const T& t) const {
    return typename make_expression<T>::type(t);
  }
};

struct expression : column
{
    expression() { }
    using column::operator =;
};

int main()
{
    expression ex;
    ex = 2;

    return 0;
}

which failed to compile with such command line:
c++ -std=gnu++0x file.cpp

Compiler produces such error:
bug.cpp: In instantiation of ‘make_expression<column>’:
bug.cpp:31:10:   instantiated from here
bug.cpp:12:42: error: invalid use of incomplete type ‘struct
make_literal<column>’
bug.cpp:3:8: error: declaration of ‘struct make_literal<column>’

[Bug c++/53360] Problems with -std=gnu++0x

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360

--- Comment #1 from Marc Glisse <marc.glisse at normalesup dot org> 2012-05-15 15:00:58 UTC ---
clang and gcc reject it, but intel and oracle accept it.

[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This seems to be fixed in 11+.

[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed by r11-7289:

    c++: Tweak PR969626 patch

    It occurred to me that other types of conversions use
rvaluedness_matches_p,
    but those uses don't affect overload resolution, so we shouldn't look at
the
    flag for them.  Fixing that made decltype64.C compile successfully, because
    the non-template candidate was a perfect match, so we now wouldn't consider
    the broken template.  Changing the argument to const& makes it no longer a
    perfect match (because of the added const), so we again get the infinite
    recursion.

    This illustrates the limited nature of this optimization/recursion break;
it
    works for most copy/move constructors because the constructor we're looking
    for is almost always a perfect match.  If it happens to help improve
compile
    time for other calls, that's just a bonus.

    gcc/cp/ChangeLog:

            PR c++/96926
            * call.c (perfect_conversion_p): Limit rvalueness
            test to reference bindings.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/decltype64.C: Change argument to const&.

Which was a follow-up to r11-7287:

    c++: Tuple of self-dependent classes [PR96926]

    When compiling this testcase, trying to resolve the initialization for the
    tuple member ends up recursively considering the same set of tuple
    constructor overloads, and since two of them separately depend on
    is_constructible, the one we try second fails to instantiate
    is_constructible because we're still in the middle of instantiating it the
    first time.

    Fixed by implementing an optimization that someone suggested we were
already
    doing: if we see a non-template candidate that is a perfect match for all
    arguments, we can skip considering template candidates at all.  It would be
    enough to do this only when LOOKUP_DEFAULTED, but it shouldn't hurt in
other
    cases.

    gcc/cp/ChangeLog:

            PR c++/96926
            * call.c (perfect_conversion_p): New.
            (perfect_candidate_p): New.
            (add_candidates): Ignore templates after a perfect non-template.

    gcc/testsuite/ChangeLog:

            PR c++/96926
            * g++.dg/cpp0x/overload4.C: New test.

Thi might be a dup of PR 96926 but we could add the testcase to be sure.