: 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
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++ -st
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;
>
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 lik
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71243
Michele Caini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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 { };
te
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 e
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
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
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
: 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
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
++
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() {
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
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
ormal
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:
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-
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-
erity: 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-defi
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
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
++
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
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 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77474
--- Comment #3 from Michele Caini ---
The same applies using member function template.
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
: 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
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 abo
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
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
32 matches
Mail list logo
