[Bug c++/88725] New: fails to deduce template specialization in friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88725
Bug ID: 88725
Summary: fails to deduce template specialization in friend
declaration
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haining.cpp at gmail dot com
Target Milestone: ---
gcc fails to deduce that the friend declaration refers to ::func in the
below
```
template
void func(T);
class Cls {
friend void ::func(int);
};
```
Rejecting with
```
error: 'void func(int)' should have been declared inside '::'
friend void ::func(int);
^
```
I believe this should be allowed by [temp.friend]/1.3:
http://eel.is/c++draft/temp.friend#1.3
see discussion here: https://stackoverflow.com/q/54055575/1013719
[Bug c++/87651] [8/9 Regression] inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651 Ryan R Haining changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail|9.0 | --- Comment #2 from Ryan R Haining --- It looks to be working on head now: https://wandbox.org/permlink/FTjpi30scFEAgGyO
[Bug c++/87652] [8/9 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 Ryan R Haining changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ryan R Haining --- working on head: https://wandbox.org/permlink/4dCLIfaIPWij81Vi
[Bug c++/65799] Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 Ryan R Haining changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ryan R Haining --- code is correctly failing on head: https://wandbox.org/permlink/6vj1agxCRZaTYs7b
[Bug c++/79624] comma separate auto variables deduce different types under dependent lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79624 --- Comment #4 from Ryan R Haining --- still a problem on head: https://wandbox.org/permlink/tPYbCp1jWYmc9O9J
[Bug c++/68423] override/final doesn't cause error in templated class without base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68423 Ryan R Haining changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Ryan R Haining --- Seems like WONTFIX by the last comment
[Bug c++/68423] override/final doesn't cause error in templated class without base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68423 Ryan R Haining changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #3 from Ryan R Haining --- Seems like WONTFIX by the last comment
[Bug c++/85353] New: deprecation warning issued on data member with initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85353
Bug ID: 85353
Summary: deprecation warning issued on data member with
initializer
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haining.cpp at gmail dot com
Target Milestone: ---
The following code issues deprecation warnings. "warning: 'Cls::x' is
deprecated "
struct Cls {
[[deprecated]] int x = 0; // removing = 0 silences warning
};
int main() {
Cls c;
}
The warning is only issued when the `= 0` is present. This code shouldn't be
warning at all. Live at wandbox: https://wandbox.org/permlink/sqR7DvAlMfllCES0
[Bug c++/87652] [8 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 --- Comment #7 from Ryan R Haining --- Still fails in 8.3.0 https://wandbox.org/permlink/69kAYkUWgFD5TTxs
[Bug c++/87651] [8 Regression] inner class with template template friend declaration of same name fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651 --- Comment #5 from Ryan R Haining --- Failing on 8.3.0 https://wandbox.org/permlink/69kAYkUWgFD5TTxs
[Bug c++/87651] New: inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651
Bug ID: 87651
Summary: inner class with template template friend declaration
of same name fails to compile in gcc 8.1, 8.2, and 9.0
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haining.cpp at gmail dot com
Target Milestone: ---
Requirements to repro
1) Outer class must be template
2) Inner class must have template template parameter
Sample program
template class Cls;
template
struct Outer {
template class>
class Failure {
template class>
friend class Failure; // All Failures should be friends
};
using F = Failure;
};
int main() {
Outer::F var;
}
Error message #
prog.cc: In instantiation of 'class Outer::Failure':
prog.cc:15:18: required from here
prog.cc:5:33: error: template parameter 'template template
class'
template class>
^
prog.cc:8:18: error: redeclared here as 'template
class'
friend class Failure;
^~~
Additional Info
wandbox links to errors:
- [gcc-8.1.0](https://wandbox.org/permlink/vpzvcXcPUwVm4ent)
- [gcc-8.2.0](https://wandbox.org/permlink/YaD9sml3aPaJExcm)
- [gcc HEAD 9.0.0 20181017 ](https://wandbox.org/permlink/FXqrijJRqbyNT0ZT)
passing with [gcc-7.3.0](https://wandbox.org/permlink/0HQ9K8PuSJBqRmD1)
This is causing several components of
http://github.com/ryanhaining/cppitertools to fail to compile, and I have no
ideas for a workaround besides making my data members public
[Bug c++/87652] New: inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652
Bug ID: 87652
Summary: inner class template of outer class template can't
access friend's protected data member
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haining.cpp at gmail dot com
Target Milestone: ---
Example program
template
struct Outer {
template
class Inner {
template
friend class Inner; // All Inners should be friends
public:
template
void use_other_x(const Inner& other) const {
(void)other.x; // should be fine, we're all friends
}
private: // no error if private instead
int x;
};
};
int main() {
Outer::Inner i1;
Outer::Inner i2;
i1.use_other_x(i2);
}
Error message
prog.cc: In instantiation of 'void Outer< >::Inner<
>::use_other_x(const Outer<
>::Inner&) const [with T = char; = void;
= int]':
prog.cc:21:20: required from here
prog.cc:11:20: error: 'int Outer::Inner::x' is protected within this
context
(void)other.x;
~~^
prog.cc:14:10: note: declared protected here
int x;
Notes
No problems observed when using private: instead of protected:
[Bug c++/87652] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652
--- Comment #1 from Ryan R Haining ---
ugh, very sorry, I copied the version with private: instead of protected. The
example program should be:
template
struct Outer {
template
class Inner {
template
friend class Inner; // All Inners should be friends
public:
template
void use_other_x(const Inner& other) const {
(void)other.x;
}
protected: // no error if private instead
int x;
};
};
int main() {
Outer::Inner i1;
Outer::Inner i2;
i1.use_other_x(i2);
}
[Bug c++/118777] New: False positive when extending lifetime of temporary containing reference, created by non-static member function [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118777
Bug ID: 118777
Summary: False positive when extending lifetime of temporary
containing reference, created by non-static member
function [-Wdangling-reference]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haining.cpp at gmail dot com
Target Milestone: ---
Created attachment 60405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60405&action=edit
MRE to produce dangling reference warning
gcc version 15.0.1 20250206 (experimental)
(Compiler-Explorer-Build-gcc-9a409f5c862c5b2625c4b94145031394ef28-binutils-2.42)
Configured with: ../gcc-trunk-20250206/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --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=Compiler-Explorer-Build-gcc-9a409f5c862c5b2625c4b94145031394ef28-binutils-2.42
I can reproduce this on 13.3 and 14.2, but not on 12.4
This program:
1. Creates a `Widget`
1. Creates a temporary callable `Wrapper`
1. Invokes `Wrapper::call` on the `Widget`, which creates and returns a
`Holder` with an lvalue reference to the `Widget`
1. Extends the lifetime of the `Holder` with a `const Holder&` in the caller.
```
struct Widget{};
struct Holder {
Widget& data;
};
struct Wrapper {
Holder call(Widget& w) const {
return {w};
}
};
int main() {
Widget w;
const Holder& r = Wrapper{}.call(w);
(void)r;
}
```
```
$ g++ -Wall -Wextra -pedantic-errors -std=c++17 source.cpp
: In function 'int main()':
:16:17: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
16 | const Holder& r = Wrapper{}.call(w);
| ^
:16:21: note: 'Wrapper' temporary created here
16 | const Holder& r = Wrapper{}.call(w);
|
```
The warning reads like gcc thinks I'm binding a reference to the `Wrapper`
object itself. There are many changes that cause the warning to go away:
1. Remove the reference from `Holder`: struct Holder { Widget data; };`
1. Mark `Wrapper::call` as `static`
```
struct Wrapper {
static Holder call(Widget& w) {
return {w};
}
};
1. Change main to not bind a reference to the `Holder`: `Holder r =
Wrapper{}.call(w);`
If `Wrapper::call` constructed `Holder` with a data member or local variable,
then this would of course be a dangling reference, but as-written I don't see
how it could be since the argument is a non-const lvalue reference. There's
also versions of this that actually *do* create a dangling reference, but that
do not trigger any warning:
```
struct Widget{};
struct Holder {
Widget& data;
};
struct Wrapper {
Holder call(Widget w) const { // no &
return {w}; // returning Holder with reference to local
}
};
int main() {
Widget w;
Holder r = Wrapper{}.call(w); // r.data is dangling
(void)r;
}
```
https://godbolt.org/z/eehbY45o5
