[Bug c++/68807] New: operator->* returning a temporary T will in some cases be treated as returning an lvalue

["adrianbibbywalther at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 68807
           Summary: operator->* returning a temporary T will in some cases
                    be treated as returning an lvalue
           Product: gcc
           Version: 5.3.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adrianbibbywalther at gmail dot com
  Target Milestone: ---

Created attachment 36968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36968&action=edit
A short peice of code that triggers the bug

Namely inside an expression of a function template where a typename template
parameter is not involved in the expression.
The attached code explains it better than I can. Compile with:
    g++ -std=c++11 main.cpp
fails with:
    main.cpp: In function âvoid test3(T)â:
    main.cpp:14:57: error: cannot bind âstruct_aâ lvalue to âstruct_a&&â
     template <typename T> void test3(T){ func(struct_b()->*0); }
                                                             ^
    main.cpp:3:6: note: in passing argument 1 of âvoid func(struct_a&&)â
     void func(struct_a &&){}
          ^

You can also try switching out ->* with * and the code will suddenly compile as
it should.

I tested this both with a freshly compiled version of GCC 5.3.0 on Xubuntu,
configured and built with:
    ./configure --with-build-config="bootstrap-lto bootstrap-O3"
    make BOOT_CFLAGS="-march=native" profiledbootstrap -j 4
As well as MinGW-w64 GCC 5.2.0 on Windows, with whatever they built it with.

As the code does not #include any files nor does it use any other #stuff the
preprocessed source file is the same as the input file with the exception of a
few # 1 "stuff" at the top of the file.

Adding -Wall and -Wextra to the command line gives an extra warning about the
left operand of the comma operator simply being ignored, which is true, but
completely irrelevant to the bug, as the only point of the comma operator is to
make the expression dependant on the template parameter.
Other than that -Wall and -Wextra adds no other warnings to the code, and as
the code fails to compile I did not even try -fno-strict-aliasing or -fwrapv as
they should not affect whether the code compiles or not (please correct me if I
am wrong here).