[Bug c++/116011] New: Bogus template redefinition error between pointer-to-member &T::x versus pointer &(T::x)

[Bug c++/116011] New: Bogus template redefinition error between pointer-to-member &T::x versus pointer &(T::x)

[hstong at ca dot ibm.com]

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

            Bug ID: 116011
           Summary: Bogus template redefinition error between
                    pointer-to-member &T::x versus pointer &(T::x)
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the following, the definitions of two template functions that differ in the
presence of parentheses around the operand to a unary & operator are diagnosed
by GCC as being duplicate definitions of the same function.


### SOURCE (<stdin>):
struct A { int x; };

char q(int *);
short q(int A::*);

template <typename T>
constexpr int f(char (*)[sizeof(q(&T::x))]) { return 1; }

template <typename T>
constexpr int f(char (*)[sizeof(q(&(T::x)))]) { return 2; }

constexpr int g(char (*p)[sizeof(char)] = 0) { return f<A>(p); }
constexpr int h(char (*p)[sizeof(short)] = 0) { return f<A>(p); }

static_assert(g() == 2);
static_assert(h() == 1);


### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -xc++ -


### ACTUAL OUTPUT:
<stdin>:10:15: error: redefinition of 'template<class T> constexpr int f(char
(*)[sizeof (q((& T::x)))])'
<stdin>:7:15: note: 'template<class T> constexpr int f(char (*)[sizeof (q((&
T::x)))])' previously declared here
<stdin>: In function 'constexpr int g(char (*)[1])':
<stdin>:12:60: error: cannot convert 'char (*)[1]' to 'char (*)[2]'
<stdin>:7:17: note:   initializing argument 1 of 'constexpr int f(char
(*)[sizeof (q((& T::x)))]) [with T = A]'
<stdin>:12:64: error: body of 'constexpr' function 'constexpr int g(char
(*)[1])' not a return-statement
<stdin>: At global scope:
<stdin>:15:19: error: non-constant condition for static assertion
<stdin>:15:16: error: 'constexpr int g(char (*)[1])' called in a constant
expression
<stdin>:12:15: note: 'constexpr int g(char (*)[1])' declared here


### EXPECTED OUTPUT:
(clean compile)


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240719 (experimental) (GCC)

[Bug c++/116011] Bogus template redefinition error between pointer-to-member &T::x versus pointer &(T::x)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Clang also rejects this:
```
<source>:13:55: error: no matching function for call to 'f'
   13 | constexpr int g(char (*p)[sizeof(char)] = 0) { return f<A>(p); }
      |                                                       ^~~~
<source>:8:15: note: candidate function template not viable: no known
conversion from 'char (*)[1]' to 'char (*)[2]' for 1st argument
    8 | constexpr int f(char (*)[sizeof(q(&T::x))]) { return 1; }
      |               ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:11:15: note: candidate function template not viable: no known
conversion from 'char (*)[1]' to 'char (*)[2]' for 1st argument
   11 | constexpr int f(char (*)[sizeof(q(&(T::x)))]) { return 2; }
      |               ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:16:15: error: static assertion expression is not an integral constant
expression
   16 | static_assert(g() == 2);
      |               ^~~~~~~~
```

MSVC rejects it the same way as GCC:
```

<source>(11): error C2995: 'int f(char (*)[])': function template has already
been defined
<source>(8): note: see declaration of 'f'
<source>(13): error C3615: constexpr function 'g' cannot result in a constant
expression
<source>(13): note: failure was caused by control reaching the end of a
constexpr function
<source>(14): error C3615: constexpr function 'h' cannot result in a constant
expression
<source>(14): note: failure was caused by control reaching the end of a
constexpr function
<source>(16): error C2131: expression did not evaluate to a constant
<source>(16): note: function violates 'constexpr' rules or has errors
<source>(16): note: see usage of 'g'
<source>(16): note: the call stack of the evaluation (the oldest call first) is
<source>(16): note: while evaluating function 'int g(char (*)[1])'
<source>(17): error C2131: expression did not evaluate to a constant
<source>(17): note: function violates 'constexpr' rules or has errors
<source>(17): note: see usage of 'h'
<source>(17): note: the call stack of the evaluation (the oldest call first) is
<source>(17): note: while evaluating function 'int h(char (*)[2])'
```

EDG is also rejects it the same way as GCC:
```
"<source>", line 11: error: function template "f" has already been defined
(previous definition at line 7)
  constexpr int f(char (*)[sizeof(q(&(T::x)))]) { return 2; }
                ^

"<source>", line 13: error: no instance of function template "f" matches the
argument list
            argument types are: (char (*)[1])
  constexpr int g(char (*p)[sizeof(char)] = 0) { return f<A>(p); }
                                                        ^
"<source>", line 8: note: function template "f" does not match because argument
#1 does not match parameter
  constexpr int f(char (*)[sizeof(q(&T::x))]) { return 1; }
                ^

"<source>", line 17: error: static assertion failed
  static_assert(h() == 1);
  ^

```

[Bug c++/116011] Bogus template redefinition error between pointer-to-member &T::x versus pointer &(T::x)

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong <hstong at ca dot ibm.com> ---
The fix for Clang is in the works:
https://github.com/llvm/llvm-project/pull/89713#issuecomment-2240767267

An issue has been filed against the Itanium ABI:
https://github.com/itanium-cxx-abi/cxx-abi/issues/188

[Bug c++/116011] Bogus template redefinition error between pointer-to-member &T::x versus pointer &(T::x)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The reality of the issue comes down to accepting this:
```
struct foo { int val; };

int main() { decltype(&(foo::val)) ptr; }
```

[Bug c++/116011] accepting &(T::x) as a pointer to member in an unevulated context and not treating it differently from &T::x

[hstong at ca dot ibm.com]

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

--- Comment #4 from Hubert Tong <hstong at ca dot ibm.com> ---
(In reply to Andrew Pinski from comment #3)
> The reality of the issue comes down to accepting this:
> ```
> struct foo { int val; };
> 
> int main() { decltype(&(foo::val)) ptr; }
> ```

Yes, which was added in C++11. GCC (unlike Clang and EDG) accepts even in
SFINAE contexts under pre-C++11 modes though:
```
template <typename T> void f(char (*)[sizeof(T::x)] = 0);
template <typename T> void f(char * = 0);
struct A { int x; };
void g() { f<A>(); } // OK in C++03 with Clang and EDG
```

[Bug c++/116011] Template declaration matching does not differentiate between &(T::x) and &T::x; only the latter can form a pointer to member

[hstong at ca dot ibm.com]

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

Hubert Tong <hstong at ca dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|accepting &(T::x) as a      |Template declaration
                   |pointer to member in an     |matching does not
                   |unevulated context and not  |differentiate between
                   |treating it differently     |&(T::x) and &T::x; only the
                   |from &T::x                  |latter can form a pointer
                   |                            |to member

--- Comment #5 from Hubert Tong <hstong at ca dot ibm.com> ---
I updated the summary title again to reflect that the issue is specific to
declaration matching.

GCC does differentiate between &(T::x) and &T::x (except that it conflates them
when matching templated declarations.

For example, the following compiles:
```
struct A { int x; };

char q(int *);
short q(int A::*);

template <typename T>
constexpr int f1(char (*)[sizeof(q(&T::x))]) { return 1; }

template <typename T>
constexpr int f2(char (*)[sizeof(q(&(T::x)))]) { return 2; }

constexpr int g(char (*p)[sizeof(char)] = 0) { return f2<A>(p); }
constexpr int h(char (*p)[sizeof(short)] = 0) { return f1<A>(p); }

static_assert(g() == 2, "");
static_assert(h() == 1, "");
```

[Bug c++/116011] Template declaration matching does not differentiate between &(T::x) and &T::x; only the latter can form a pointer to member

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is not just templates though.
It is unevulated context where the issue comes into play.

[Bug c++/116011] accepting &(T::x) as a pointer to member in an unevulated context and not treating it differently from &T::x

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hubert Tong from comment #5)
> I updated the summary title again to reflect that the issue is specific to
> declaration matching.
> 
> GCC does differentiate between &(T::x) and &T::x (except that it conflates
> them when matching templated declarations.
> 
> For example, the following compiles:
> ```
> struct A { int x; };
> 
> char q(int *);
> short q(int A::*);
> 
> template <typename T>
> constexpr int f1(char (*)[sizeof(q(&T::x))]) { return 1; }
> 
> template <typename T>
> constexpr int f2(char (*)[sizeof(q(&(T::x)))]) { return 2; }
> 
> constexpr int g(char (*p)[sizeof(char)] = 0) { return f2<A>(p); }
> constexpr int h(char (*p)[sizeof(short)] = 0) { return f1<A>(p); }
> 
> static_assert(g() == 2, "");
> static_assert(h() == 1, "");
> ```

Those are all unevulated context.that is sizeof and decltype are both
considered unevulated context. In them, gcc does not think &(T::x) and &T::x
act differently. Gcc does the right thing outside of unevulated context though.

[Bug c++/116011] accepting &(T::x) as a pointer to member in an unevulated context and not treating it differently from &T::x

[hstong at ca dot ibm.com]

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

--- Comment #8 from Hubert Tong <hstong at ca dot ibm.com> ---
(In reply to Andrew Pinski from comment #7)
> Those are all unevulated context.that is sizeof and decltype are both
> considered unevulated context. In them, gcc does not think &(T::x) and &T::x
> act differently.

I am not seeing how you reached the conclusion that GCC does not think &(T::x)
and &T::x act differently.

GCC compiles this fine (that is, the second `f` accepts an `int *`):
```
struct A { int x; };

template <typename T>
int f(decltype(&T::x) pm, T *tp) {
  return tp->*pm;
}

template <typename T>
int f(decltype(&(T::x)) p) {
  return *p;
}

int g(A *ap, int i) {
  return f<A>(&A::x, ap) + f<A>(&i);
}
```

[Bug c++/116011] accepting &(T::x) as a pointer to member in an unevulated context and not treating it differently from &T::x

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-07-20
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hubert Tong from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > Those are all unevulated context.that is sizeof and decltype are both
> > considered unevulated context. In them, gcc does not think &(T::x) and &T::x
> > act differently.
> 
> I am not seeing how you reached the conclusion that GCC does not think
> &(T::x) and &T::x act differently.

I said outside of an unevaluated context. the uses you have are inside an
unevaluated context still.

Try this:
```

struct A { int x; };

template <typename T>
constexpr auto f() {
  return &T::x;
}

template <typename T>
constexpr auto f1() {
  return &(T::x);
}

auto g = f<A>();
auto g1 = f1<A>();
```

You will see GCC rejects the definition of f1<A> correctly.

[Bug c++/116011] accepting &(T::x) as a pointer to member in an unevulated context and not treating it differently from &T::x

[hstong at ca dot ibm.com]

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

--- Comment #10 from Hubert Tong <hstong at ca dot ibm.com> ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Hubert Tong from comment #8)
> > (In reply to Andrew Pinski from comment #7)
> > > Those are all unevulated context.that is sizeof and decltype are both
> > > considered unevulated context. In them, gcc does not think &(T::x) and &T::x
> > > act differently.
> > 
> > I am not seeing how you reached the conclusion that GCC does not think
> > &(T::x) and &T::x act differently.
> 
> I said outside of an unevaluated context. the uses you have are inside an
> unevaluated context still.
> 
> Try this:
> ```
> 
> struct A { int x; };
> 
> template <typename T>
> constexpr auto f() {
>   return &T::x;
> }
> 
> template <typename T>
> constexpr auto f1() {
>   return &(T::x);
> }
> 
> auto g = f<A>();
> auto g1 = f1<A>();
> ```
> 
> You will see GCC rejects the definition of f1<A> correctly.

The standard explicitly makes an exception for the use in an unevaluated
context: https://wg21.link/expr.prim.id.general#4.3

When GCC accepts the use in an unevaluated context, it is right (and it is
getting the correct type) afaict.

The only proximate issue with GCC that I have found is the template declaration
matching issue.