[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[eieio at google dot com]

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

Corey Tabaka  changed:

   What|Removed |Added

 CC||eieio at google dot com

--- Comment #11 from Corey Tabaka  ---
Clang already (In reply to Jakub Jelinek from comment #9)
> COMDAT is implemented in different ways.  If it is through the ELF comdat
> groups, then in theory this can be handled, by putting the COMDAT variable
> (from template instantiation, or inline variable, static var in inline
> function etc.) into the section with the given name and use the comdat group
> we would normally use.
> If ELF comdat groups aren't supported, then we use .gnu.linkonce.* sections
> and in that case it can't be really supported.  Nor in the non-ELF cases...

Clang already takes the approach of applying the given section name and using
the normal COMDAT group for ELF targets. It would be helpful for GCC and Clang
to match behaviors.

Example: https://godbolt.org/z/w-Hy-z

[Bug c++/82478] New: Rejects valid access to private member type that should be allowed by friend

[eieio at google dot com]

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

Bug ID: 82478
   Summary: Rejects valid access to private member type that
should be allowed by friend
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eieio at google dot com
  Target Milestone: ---

Created attachment 42325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42325&action=edit
Complete source file that reproduces the issue.

Hello,

Attached is a source file that reproduces the issue. It appears that in some
contexts the friend declaration is not being honored, causing the compiler to
reject access to a private member type. If this bug turns out to be issue of
interpretation of the spec it would be helpful to understand the interpretation
so that we can discuss with our other compiler maintainers.

We reproduced this issue on various versions of GCC. For this bug submission we
used Compiler Explorer (https://gcc.godbolt.org/) to prepare the reproduction
example.

Thanks!

The following is the compiler output and settings as requested in the FAQ:

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-7.2.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-7.2.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-multilib --disable-bootstrap --disable-multiarch --with-arch-32=i586
--enable-clocale=gnu --enable-languages=c,c++,go,fortran --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.2.0 (GCC-Explorer-Build) 
COLLECT_GCC_OPTIONS='-g' '-o'
'/tmp/compiler-explorer-compiler11798-16759-19s20vn.7r70wo2yb9/output.s'
'-masm=intel' '-S' '-std=c++14' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/opt/compiler-explorer/gcc-7.2.0/bin/../libexec/gcc/x86_64-linux-gnu/7.2.0/cc1plus
-quiet -v -iprefix
/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/
-D_GNU_SOURCE  -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip
/tmp/compiler-explorer-compiler11798-16759-19s20vn.7r70wo2yb9/output.s -g
-std=c++14 -version -o
/tmp/compiler-explorer-compiler11798-16759-19s20vn.7r70wo2yb9/output.s
GNU C++14 (GCC-Explorer-Build) version 7.2.0 (x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/x86_64-linux-gnu

/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0

/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
 /opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/include

/opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-7.2.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C++14 (GCC-Explorer-Build) version 7.2.0 (x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-he

[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend

[eieio at google dot com]

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

--- Comment #2 from Corey Tabaka  ---
From section 11.3.2 of the C++14 draft spec:

"Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in the
base-specifiers and member declarations of the befriended class."

I take "can be accessed in base-specifiers" to mean any expression in the base
specifiers of class B is granted access to private and protected members of
class A if class A declares class B to be a friend. Do you agree that this is a
valid interpretation?

Furthermore, regardless of the interpretation above, in the example supplied
the class Outer should have friend access to private members of A, and thus the
nested definition of Outer::HasPrivate should have valid access to A::PRIVATE.
This also fails to compile with a similar error as the top-level example --
clearly this is not the correct behavior.

[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend

[eieio at google dot com]

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

--- Comment #4 from Corey Tabaka  ---
Ah, you are right. Late night mixup...

The outer class friend should work though, correct?

[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend

[eieio at google dot com]

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

--- Comment #5 from Corey Tabaka  ---
>From what I can tell the standard is not very explicit about the access rules
in the argument list of a partial specialization specifically. However, there
are examples in the spec that demonstrate friend access does apply when
evaluating template arguments in general.

Here's the example from 11.0.6:

class A {
   typedef int I;
   I f();
   friend I g(I);
   static I x;
   template struct Q;
   template friend struct R;
   protected:
   struct B { };
};

A::I A::f() { return 0; }
A::I g(A::I p = A::x);
A::I g(A::I p) { return 0; }
A::I A::x = 0;
template struct A::Q { };
template struct R { };
struct D: A::B, A { };

Considering that "template struct R" is allowed it seems reasonable that
"template<> struct X" should also be allowed if X is a friend of A as
well.

What do you think?