[Bug bootstrap/98340] New: gcc trunk build with clang failure, part 2

[Bug bootstrap/98340] New: gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com]

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

            Bug ID: 98340
           Summary: gcc trunk build with clang failure, part 2
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

More fallout from Nathan's new module code. Probably.

../../trunk.git/gcc/cp/module.cc:2722:28: error: 'uintset<unsigned
int>::values' is not a member of class 'uintset<unsigned int>::hash'
                             + sizeof (uintset::values) * n);
                                       ~~~~~~~~~^
../../trunk.git/gcc/cp/module.cc:7550:22: note: in instantiation of member
function 'uintset<unsigned int>::hash::add' requested here
        if (!pending_table->add (key_ident, ~ident))
                            ^
../../trunk.git/gcc/cp/module.cc:2747:28: error: 'uintset<tree_node *>::values'
is not a member of class 'uintset<tree_node *>::hash'
                     + (sizeof (uintset::values) << p2alloc));
                                ~~~~~~~~~^
../../trunk.git/gcc/cp/module.cc:8086:24: note: in instantiation of member
function 'uintset<tree_node *>::hash::create' requested here
        set = attached_table->create (DECL_UID (inner), num, NULL_TREE);
    ../../trunk.git/gcc/cp/module.cc:2722:28: error: 'uintset<tree_node
*>::values' is not a member of class 'uintset<tree_node *>::hash'
                             + sizeof (uintset::values) * n);
                                       ~~~~~~~~~^
../../trunk.git/gcc/cp/module.cc:18493:23: note: in instantiation of member
function 'uintset<tree_node *>::hash::add' requested here
  if (attached_table->add (DECL_UID (ctx), decl))
                      ^
                          ^

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu.org

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
As expected, git blame indicates Nathan.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This boils down to:

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 ();

This is rejected by g++ up to 4.5.x, icc 13 and clang (all versions) and
accepted by gcc 4.6 and later and icc 16 and later.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Before r0-99643-g2defb926479247a61fe0fffbcf95597722a94c40 this used to be
rejected with:
pr98340.C: In member function ‘int uintset<T>::hash::foo() [with T = int]’:
pr98340.C:33:18:   instantiated from here
pr98340.C:29:33: error: type ‘uintset<int>’ is not a base type for type
‘uintset<int>::hash’

clang++ rejects the above testcase even if it is just struct traits {};
i.e. not derived from delete_ptr_hash <uintset>, but accepts it if
uintptr<T>::hash isn't derived from hash_table<traits> but say hash_table<int>
(rejects if it is derived
from hash_table<uintptr<T>::traits> though).
I guess a C++ language lawyer would need to have a look if it is a clang++ bug
or g++ bug in accepting it.  Of course, even if it is clang++ bug, a workaround
is possible, e.g. it could use sizeof (T) rather than sizeof (uintset::values),
after all, when it multiplicates by n, I guess it wants sizeof
(uintset<T>::values[0]) anyway, because it uses trailing array of Ts rather
than T[1]s.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-12-17

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Created attachment 49789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49789&action=edit
try this

I tried building with clang, but it barfed about invalid utf8 in libiberty.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Nathan Sidwell from comment #4)
> Created attachment 49789 [details]
> try this

Thanks. That seemed to build ok.

> I tried building with clang, but it barfed about invalid utf8 in libiberty.

I got an ok build with clang of gcc trunk hash 6f8486523f61bf0a,
with your patch.

I am no expert, but maybe you could share the error message. These
problems frequently go away after some random tinkering with locale.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Now I look carefully, it appears to be trying to compile libiberty.a (the
library) as a source file.  Of course that'll barf.  
Configured using "CXX='clang -x c++ -std=c++11'  CC=clang"  (Of course I didn't
look for any instructions :)

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:2d7a40fa60fb8b9870cfd053a37fc67404353ee2

commit r11-6237-g2d7a40fa60fb8b9870cfd053a37fc67404353ee2
Author: Nathan Sidwell <nathan@acm.org>
Date:   Thu Dec 17 09:53:01 2020 -0800

    c++: Fix clang problem [PR 98340]

    Clang didn't like sizeot (uintset::value) in a templated context.  Not sure
    where the problem lies -- ambiguous std, gcc erroneous accept or clang
erroneous
    reject.  Anyway, this avoids that construct.

            PR c++/98340
            gcc/cp/
            * module.cc (uintset<T>::hash::add): Use uintset (0u).MEMBER,
            rather than uintset::MEMBER.

[Bug bootstrap/98340] gcc trunk build with clang failure, part 2

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Fixed

* 2d7a40fa60f 2020-12-17 | c++: Fix clang problem [PR 98340] (HEAD -> master,
origin/master, origin/HEAD) [Nathan Sidwell]