[Bug c++/98360] New: sizeof in template difference between g++/icc and clang++

[Bug c++/98360] New: sizeof in template difference between g++/icc and clang++

[jakub at gcc dot gnu.org]

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

            Bug ID: 98360
           Summary: sizeof in template difference between g++/icc and
                    clang++
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: dcb314 at hotmail dot com, jakub at gcc dot gnu.org,
                    marxin at gcc dot gnu.org, nathan at gcc dot gnu.org
        Depends on: 98340
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #98340 +++

template <typename T>
struct delete_ptr_hash
{
};

template <typename T>
struct hash_table
{
};

template <typename T>
struct uintset
{
  T values[1];
  struct traits : delete_ptr_hash <uintset>
  {
  };
  struct hash : hash_table <traits>
  {
    int foo ();
  };
  hash h;
};

template <typename T>
int
uintset<T>::hash::foo ()
{
  return sizeof (uintset::values);
}

uintset<int> s;
int x = s.h.foo ();

As stated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340#c2
the above has been rejected by g++ before
r0-99643-g2defb926479247a61fe0fffbcf95597722a94c40 and by icc 13 and is
rejected by all clang++ versions I've tried (but each compiler different
diagnostic), while it is accepted by g++ 4.6+ and icc 16+.

Is this an accepts-invalid bug in g++ or ice-on-invalid in clang++?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98340
[Bug 98340] gcc trunk build with clang failure, part 2

[Bug c++/98360] sizeof in template difference between g++/icc and clang++

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
I think this is reject-valid in clang++.

[expr.prim.id.general]/2 ( http://eel.is/c++draft/expr.prim.id.general#2 ):

> An id-expression that denotes a non-static data member or non-static member function of a class can only be used:
>
> - [...]
> - if that id-expression denotes a non-static data member and it appears in an unevaluated operand.

[Bug c++/98360] sizeof in template difference between g++/icc and clang++

[ensadc at mailnesia dot com]

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

--- Comment #2 from ensadc at mailnesia dot com ---
Apparently clang++ rewrites `uintset::values` in question to
`this->uintset::values`, because it believes that `uintset::values` is valid
only if someone specializes `uintset<foo>::traits` to make it inherit from
`uintset<foo>`, but clang++ seems to fail at realizing that `uintset::values`
appears in an unevaluated operand.

[Bug c++/98360] sizeof in template difference between g++/icc and clang++

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC, ICC and MSVC all agree that this is valid code and all produce 4.
clang is the only one which rejects it.

Here is an even more reduced testcase:
template <typename T>
struct uintset
{
  T values[1];
  struct traits  {  };
  struct hash : traits
  {
    int foo () {
      return sizeof (uintset::values);
    }
  };
  hash h;
};
uintset<int> s;
int x = s.h.foo ();

If you remove the base class or change it not to dependent type, the code is
accepted. 

The defect reports in this area:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#198

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html is the paper
which resolves 613.


I suspect GCC is correct if I go by this paper.