[Bug c++/78986] New: template inner classes are not affected by visibility specifiers

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: class B { struct T {}; }; class D: B { template struct U: T {}; }; int main() {} GCC accepts

[Bug c++/78785] New: Internal compiler error: segmentation fault - mixin based on lambdas

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- The following snippet doesn't compile. GCC 6.1.0 stops working with an ICE due to a segfault. It works with GCC 6.2 and GCC 7

[Bug c++/78722] New: noexcept and function pointers

++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: void f() noexcept {} void func(void(*ptr)() noexcept) { static_assert(noexcept(ptr()), "!"); } int main() {

[Bug c++/78286] New: typename, type members and non-type members: code should be rejected, but it is not

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: struct S { struct foo {}; foo foo; }; int main

[Bug c++/78244] New: Narrowing conversion is accepted in a function template, but it should be rejected

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: auto f() -> decltype(int{0.}, void()) { } int main() { f(); } It fa

[Bug c++/78216] Segfault when dealing with a parameter pack of member functions pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78216 --- Comment #1 from Michele Caini --- Link to a question on SO: http://stackoverflow.com/questions/40431236/gcc-ice-segfault-and-clang-compiles-just-fine-is-this-valid-code I suspect the code is valid and should be accepted, but I'm not sure

[Bug c++/78216] New: Segfault when dealing with a parameter pack of member functions pointers

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- The following code causes an ICE (segfault): template struct S; template struct S<R(A...)

[Bug c++/78048] New: noexcept operator does not work properly when substitution required

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- The following code performs an invalid substitution: #include struct S { template std::enable_if_t

[Bug c++/77474] sizeof and function template don't work properly together

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77474 --- Comment #3 from Michele Caini --- The same applies using member function template.

[Bug c++/77914] Wrong lambda definition accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77914 --- Comment #3 from Michele Caini --- (In reply to Jakub Jelinek from comment #1) > Shall we remove that altogether, or just pedwarn on it? I suspect it should be rejected, unless it is an intended extension of the compiler (for which I've not

[Bug c++/77914] New: Wrong lambda definition accepted

++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- GCC accepts the following code, that is not valid according to the standard: int main() { auto l = [](){}; l.operator()(); } Flags -Wall -pedantic, no warnings

[Bug c++/77792] Generic lamdba scope issue when working with list::remove_if

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77792 --- Comment #1 from Michele Caini --- See also this question on SO: http://stackoverflow.com/q/39766467/4987285

[Bug c++/77792] New: Generic lamdba scope issue when working with list::remove_if

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: #include #include template struct S { using FT = void(*)(); struct T { FT

[Bug c++/77731] New: Parameter pack expansion doesn't work when used to define argument list

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- I refer to there questions on SO: * http://stackoverflow.com/questions/39690166/can-i-expand-a-parameters-pack-and-define

[Bug c++/77591] New: decltype(auto) and ternary operator allow returning local reference without a warning

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- I'm referring to this question on SO: http://stackoverflow.com/questions/39490912/decltypeauto-foo-returns-local

[Bug c++/77566] New: Warnings (-Wextra) disappear for a public reference to the this pointer

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- I'm referring to this question on SO: http://stackoverflow.com/questions/39449946/reference-to-the-this-pointer-gcc-vs-clang

[Bug c++/77474] New: sizeof and function template don't work properly together

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- The following code compiles: void f() { } int main() { sizeof(); } The following does not instead: template

[Bug c++/71534] Initializing a static constexpr data member of a base class by using a static constexpr data member of a derived class should be an error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71534 --- Comment #2 from Michele Caini --- The fact that it compiles it is misleading at least. Consider the following code: #include template using void_t = void; template> struct has_foo:

[Bug c++/71534] New: Initializing a static constexpr data member of a base class by using a static constexpr data member of a derived class should be an error

: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code

[Bug c++/71502] Fold expression unpacks (I < ...) the wrong way

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502 --- Comment #2 from Michele Caini --- Example on godbolt.org with GCC 6.1.0: https://godbolt.org/g/9meqv4

[Bug c++/71502] Fold expression unpacks (I < ...) the wrong way

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502 --- Comment #1 from Michele Caini --- I notice that there is a flaw in the text. I expect this to compile and run with no errors, as it happens indeed: #include int main() { assert((0 < 42) < 3); } From what I wrote, it would seem that

[Bug c++/71502] New: Fold expression unpacks (I < ...) the wrong way

ent: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4191.html and the following fold expression: (args < ...) It should be equi

[Bug c++/71377] SFINAE expression compiles, but it should not because of 14.5.5p8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71377 --- Comment #2 from Michele Caini --- Right, got it. Actually it's more like a complex way of writing a static assert. Should it be considered a bug anyway? I mean, it's correct for GCC to accept it or it should reject the code? I'm not skilled

[Bug c++/71377] New: SFINAE expression compiles, but it should not because of 14.5.5p8

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Consider the following code: #include #include templateM)>* = nullptr> struct S: public S&

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70077 Michele Caini changed: What|Removed |Added Version|5.3.1 |6.1.0 --- Comment #4 from Michele Caini

[Bug c++/71243] Implicitly defined assignment operator is not constexpr even though it should be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71243 Michele Caini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/71243] Implicitly defined assignment operator is not constexpr even though it should be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71243 --- Comment #2 from Michele Caini --- According to https://gcc.gnu.org/projects/cxx-status.html#cxx14, GCC5 should fully implement the C++14 rules. Am I wrong? Anyway, tested on debian sid (unstable), g++ v5.3.1-20 and it works. I guess this can

[Bug c++/71243] New: Implicitly defined assignment operator is not constexpr even though it should be

Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- Explicitly defaulted constexpr assignment operator fails to compile. See the minimal, failing example below

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70077 --- Comment #3 from Michele Caini --- On SO there is a discussion about this issue: http://stackoverflow.com/questions/35790350/noexcept-inheriting-constructors-and-the-invalid-use-of-an-incomplete-type-that The standard is cited and it looks

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70077 --- Comment #2 from Michele Caini --- (In reply to Michele Caini from comment #0) > The following code does not compile: > > struct B { > B(int) noexcept { } > virtual void f() = 0; > }; > > struct D: public B { > using B::B; >

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70077 --- Comment #1 from Michele Caini --- Actually, the same example does not compile on the web compiler previously mentioned. See http://coliru.stacked-crooked.com/a/81552252ead0d349 for further details. The error is a bit more meaningful: g++

[Bug c++/70077] New: noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michele.caini at gmail dot com Target Milestone: --- The following code does not compile: struct B { B(int) noexcept { } virtual void f