[Bug c++/70077] New: 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
Bug ID: 70077
Summary: noexcept, inheriting constructors and the invalid use
of an incomplete type that is actually complete
Product: gcc
Version: 5.3.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: ---
The following code does not compile:
struct B {
B(int) noexcept { }
virtual void f() = 0;
};
struct D: public B {
using B::B;
D() noexcept(noexcept(D{42})): B{42} { }
void f() override { }
};
int main() {
B *b = new D{};
}
The error output is as follows:
test.cpp:8:31: error: invalid use of incomplete type ‘struct D’
D() noexcept(noexcept(D{42})): B{42} { }
Anyway, the type D is actually a complete type and the noexcept should work as
expected.
Other version of GCC works fine indeed, see
http://coliru.stacked-crooked.com/a/fdbd0c1c70e74f64 as an example.
[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++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp:8:31: error: invalid use of incomplete type 'struct D'
D() noexcept(noexcept(D{42})): B{42} { }
^
main.cpp:6:8: note: definition of 'struct D' is not complete until the closing
brace
struct D: public B {
^
Still, is it valid code? It looks valid to me, but it could be a corner case of
the language, not sure about that honestly.
[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;
> D() noexcept(noexcept(D{42})): B{42} { }
> void f() override { }
> };
>
> int main() {
> B *b = new D{};
> }
>
>
> The error output is as follows:
>
> test.cpp:8:31: error: invalid use of incomplete type ‘struct D’
> D() noexcept(noexcept(D{42})): B{42} { }
>
> Anyway, the type D is actually a complete type and the noexcept should work
> as expected.
> Other version of GCC works fine indeed, see
> http://coliru.stacked-crooked.com/a/fdbd0c1c70e74f64 as an example.
Sorry, the example at http://coliru.stacked-crooked.com/a/fdbd0c1c70e74f64
contains an error and does not make much sense.
Please, consider the other link:
http://coliru.stacked-crooked.com/a/81552252ead0d349
[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 like the bug is confirmed. Not sure about that (unfortunately I'm not so skilled), but it can be a valuable resource.
[Bug c++/71243] New: Implicitly defined assignment operator is not constexpr even though it should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71243
Bug ID: 71243
Summary: Implicitly defined assignment operator is not
constexpr even though it should be
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
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:
struct S {
constexpr S& operator=(const S &) = default;
};
int main() { }
Tested on debian (Testing), g++ v5.3.1-19.
The same applies to g++ v5.3.0, while it works with g++ v6.1.0 (tested on
godbolt.org).
The error is:
2 : error: explicitly defaulted function 'constexpr S& S::operator=(const
S&)' cannot be declared as constexpr because the implicit declaration is not
constexpr:
constexpr S& operator=(const S &) = default;
^
Compilation failed
According to 12.8p26, it should compile for the one implicitly defined ought to
be constexpr too.
[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 be closed as FIXED because of that. I suspect it has been fixed as a side-effect of another issue, for I've not been able to find a bug report for this.
[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|--- |FIXED --- Comment #3 from Michele Caini --- Works on debian sid (unstable), g++ v5.3.1-20. It seems to be fixed somehow. I've not been able to find a ticket to which to link this one.
[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 --- Confirmed on GCC v6.1.0
[Bug c++/71377] New: SFINAE expression compiles, but it should not because of 14.5.5p8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71377
Bug ID: 71377
Summary: SFINAE expression compiles, but it should not because
of 14.5.5p8
Product: 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:
#include
#include
templateM)>* =
nullptr>
struct S: public S { };
template
struct S { };
int main() {
S<0, 1> c{};
}
I thought erroneously it is a clang bug, for it refused to compile it.
Instead, it seems to be a bug of GCC that accepts to compile it.
The code should be rejected because of 14.5.5p8:
http://eel.is/c++draft/temp.class.spec#8
This is the discussion on stackoverflow from which I got the ref to the
standard (thanks to the one that pointed my mistake out):
http://stackoverflow.com/a/37579096/4987285
[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 enough to say how the standard applies in this case, I'm sorry.
[Bug c++/71502] New: Fold expression unpacks (I < ...) the wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502
Bug ID: 71502
Summary: Fold expression unpacks (I < ...) the wrong way
Product: 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 this proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4191.html and the
following fold expression:
(args < ...)
It should be equivalent to:
((args$0 < args$1) < ...) + args$n
Consider the following code:
#include
int main() { assert((0 < 42) < 3); }
The assert doesn't fail as expected (note that the result is not ((0 < 42) and
(42 < 3)), the expression itself is quite unusual and meaningless).
On the other side, when using a fold expression:
template
static constexpr bool f() { return (I < ...); }
int main() {
static_assert(f<0, 42, 3>(), "!");
}
The assert fails at compile time.
I'd expect it to compile because of what contained in the proposal.
It should succeed for it is equivalent to the example above that doesn't
involve fold expressions.
The unpacked expression should be indeed: ((0 < 42) < 3).
[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 I consider it an error.
The actual issue is related to the fold expression.
[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++/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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71534
Bug ID: 71534
Summary: 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
Product: 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:
template
struct S { static constexpr int bar = T::foo; };
struct U: S { static constexpr int foo = 42; };
int main() { }
GCC compiles it, but it shouldn't.
The type T is not a complete type when bar is initialized.
Here is a discussion on stackoverflow where reasons are discussed:
http://stackoverflow.com/questions/37816186/initializing-a-static-constexpr-data-member-of-the-base-class-by-using-a-static
Link to the standard (working draft) are provided as well in the discussion.
Other compilers (mostly clang) correctly reject it.
[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: std::false_type { };
template
struct has_foo: std::true_type { };
struct S: has_foo {
static constexpr int foo = 42;
};
int main() {
// S does not have foo...
static_assert(not S::value, "!");
// ... really?
static_assert(S::foo == 42, "!");
}
The result is unexpected indeed.
So subtle an issue to find, that one.
[Bug c++/78722] New: noexcept and function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78722
Bug ID: 78722
Summary: noexcept and function pointers
Product: gcc
Version: 6.2.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:
void f() noexcept {}
void func(void(*ptr)() noexcept) {
static_assert(noexcept(ptr()), "!");
}
int main() {
func(&f);
}
GCC 6.2 wrongly rejects it.
GCC 7 accepts it instead.
[Bug c++/78785] New: Internal compiler error: segmentation fault - mixin based on lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78785
Bug ID: 78785
Summary: Internal compiler error: segmentation fault - mixin
based on lambdas
Product: 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: ---
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.
---
template struct tag: tag {};
template<> struct tag<0> {};
template
struct B;
template
struct B: F, B {
B(F f, O... o): F{f}, B(o...) {}
using B::operator();
template
void operator()(tag, A... a) { F::operator()(a...); }
};
template<>
struct B<> { void operator()(); };
template
struct S: B {
S(F... f): B{f...} {}
template
void operator()(A... a) { B::operator()(tag{}, a...); }
};
int main() {
auto l1 = [](auto){};
auto l2 = [](auto){};
S s{l1, l2};
s(42);
}
[Bug c++/78986] New: template inner classes are not affected by visibility specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
Bug ID: 78986
Summary: template inner classes are not affected by visibility
specifiers
Product: gcc
Version: 7.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:
class B { struct T {}; };
class D: B { template struct U: T {}; };
int main() {}
GCC accepts it, but it shouldn't for T is private in B and U cannot inherit
from it in D.
GCC correctly rejects the code below:
class B { struct T {}; };
class D: B { struct U: T {}; };
int main() {}
[Bug c++/77474] New: sizeof and function template don't work properly together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77474
Bug ID: 77474
Summary: sizeof and function template don't work properly
together
Product: 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: ---
The following code compiles:
void f() { }
int main() {
sizeof(&f);
}
The following does not instead:
template
void f() { }
int main() {
sizeof(&f);
}
The error returned is:
error: address of overloaded function with no contextual type information
According to expr.sizeof, both of them should compile.
[Bug c++/77566] New: Warnings (-Wextra) disappear for a public reference to the this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77566
Bug ID: 77566
Summary: Warnings (-Wextra) disappear for a public reference to
the this pointer
Product: gcc
Version: 6.2.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: ---
I'm referring to this question on SO:
http://stackoverflow.com/questions/39449946/reference-to-the-this-pointer-gcc-vs-clang
The following code compiles with warnings with -Wextra:
struct A {
private:
A* const& this_ref{this};
};
int main() {
A a{};
(void)a;
}
Relevant warning:
/data/user/0/com.n0n3m4.droidc/files/temp.c: In constructor 'constexpr A::A()':
/data/user/0/com.n0n3m4.droidc/files/temp.c:1:8: warning: a temporary bound to
'A::this_ref' only persists until the constructor exits [-Wextra]
struct A {
^
The following code (public data member) has no warning instead:
struct A {
A* const& this_ref{this};
};
int main() {
A a{};
(void)a;
}
I guess the same diagnostic issue should be detected for the second snippet.
[Bug c++/77591] New: decltype(auto) and ternary operator allow returning local reference without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77591
Bug ID: 77591
Summary: decltype(auto) and ternary operator allow returning
local reference without a warning
Product: gcc
Version: 6.2.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: ---
I'm referring to this question on SO:
http://stackoverflow.com/questions/39490912/decltypeauto-foo-returns-local-reference-without-any-warning
The following code compiles with a warning when compiled with -Wall -O0:
decltype(auto) foo_warn() {
Counter c;
return (c);
}
The code below compiles with no warnings instead:
decltype(auto) foo_no_warn() {
Counter c;
return 1==1 ? c : c;
}
Anyway, a reference to a local variable is returned in both cases.
Using -O2 the warning appears in both cases.
[Bug c++/77731] New: Parameter pack expansion doesn't work when used to define argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77731
Bug ID: 77731
Summary: Parameter pack expansion doesn't work when used to
define argument list
Product: gcc
Version: 6.2.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: ---
I refer to there questions on SO:
*
http://stackoverflow.com/questions/39690166/can-i-expand-a-parameters-pack-and-define-an-arguments-list-with-it
*
http://stackoverflow.com/questions/39665300/gcc-vs-clang-variadic-template-and-pointers-to-member-methods
In particular, GCC fails to compile the following snippets, but it should work
according with [temp.variadic]:
// Snippet 1
template
struct S {
template
void m() {}
};
int main() {
S s;
s.m<0, 'c'>();
// This works, but it shouldn't instead
s.m<>();
}
// Snippet 2
struct S { void f() { } };
struct T { void f() { } };
template
struct U: M... {
template
void g() { }
void f() {
g<&M::f...>();
}
};
int main() {
U u;
u.f();
}
The same applies to GCC v7.
[Bug c++/77792] New: Generic lamdba scope issue when working with list::remove_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77792
Bug ID: 77792
Summary: Generic lamdba scope issue when working with
list::remove_if
Product: gcc
Version: 6.2.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:
#include
#include
template
struct S {
using FT = void(*)();
struct T { FT func; };
template
static void f() { }
std::list l{ { &f }, { &f } };
void run() {
l.remove_if([](const T &t) { return t.func == &f; }); // (1)
l.remove_if([](const auto &t) { return t.func == &f; }); //
(2)
}
};
int main() {
S s;
s.run();
}
(1) compiles fine, (2) doesn't compile with the error:
> error: 'f' was not declared in this scope
Note also that it compiles if modified as it follows:
l.remove_if([](const auto &t) { return t.func == &S::f; }); // (2)
[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++/77914] New: Wrong lambda definition accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77914
Bug ID: 77914
Summary: Wrong lambda definition accepted
Product: gcc
Version: 6.2.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: ---
GCC accepts the following code, that is not valid according to the standard:
int main() {
auto l = [](){};
l.operator()();
}
Flags -Wall -pedantic, no warnings, no errors.
It doesn't seem to be an extension of the compiler.
Here is a question on SO related to the issue:
http://stackoverflow.com/questions/39948567/is-typename-a-valid-lambda-definition
[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 been able to find the docs - in this case, a pedwarn should be emitted at least).
[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++/78048] New: noexcept operator does not work properly when substitution required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78048
Bug ID: 78048
Summary: noexcept operator does not work properly when
substitution required
Product: gcc
Version: 6.2.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: ---
The following code performs an invalid substitution:
#include
struct S {
template
std::enable_if_t::value>
g() {}
};
int main() {
static_assert(noexcept(&S::g), "!");
}
GCC compiles it, but it should be rejected.
---
Here a discussion on SO:
http://stackoverflow.com/questions/40141702/noexcept-operator-and-enable-if-t-do-they-work-together
[Bug c++/78216] New: Segfault when dealing with a parameter pack of member functions pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78216
Bug ID: 78216
Summary: Segfault when dealing with a parameter pack of member
functions pointers
Product: gcc
Version: 6.2.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: ---
The following code causes an ICE (segfault):
template
struct S;
template
struct S {
template
void f() {}
};
struct A { void f() {} };
struct B { void f() {} };
int main() {
S s;
s.f<&A::f, &B::f>();
}
GCC 7 is affected by a similar problem (ICE with no segfault).
[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 about that.
[Bug c++/78244] New: Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244
Bug ID: 78244
Summary: Narrowing conversion is accepted in a function
template, but it should be rejected
Product: gcc
Version: 6.2.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:
auto f() -> decltype(int{0.}, void()) { }
int main() { f(); }
It fails to compile with the following error:
> narrowing conversion of '0.0' from 'double' to 'int' inside { }
On the other side, the following function is accepted:
template
auto f(T) -> decltype(int{0.}, void()) { }
int main(){
f(0);
}
Narrowing conversion still present.
[Bug c++/78286] New: typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286
Bug ID: 78286
Summary: typename, type members and non-type members: code
should be rejected, but it is not
Product: gcc
Version: 6.2.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:
struct S {
struct foo {};
foo foo;
};
int main() {
typename S::foo t;
(void) t;
}
GCC compiles the code with no errors, but it should be rejected.
The non-type member foo hides the type member foo and the keyword typename
cannot help to disambiguate.
Moreover, in this case foo is not a dependent name and typename couldn't be
used.
