: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
According to gcc.godbolt.org GCC 7.1 up to 9.2 fail to compile this piece of
code:
template struct EnumWrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87841
--- Comment #5 from Ole Kniemeyer ---
Thanks for asking the committee. I think the standard makes sense as it is,
because otherwise there is no chance to name the template parameter (that's
what I need in my specific situation where I found the b
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
Attribute arguments may be arbitrary token sequences as long as they are
balanced regarding () [] {}. From C++17 10.6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87841
--- Comment #3 from Ole Kniemeyer ---
Yes, I also tried other compilers, and all of them fail. But in [temp.local] it
is explicitly stated that "the name of a member of the class template hides the
name of a template-parameter of any enclosing cl
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
The following code example from C++17 standard 17.6.1.7 does not compile:
template struct A {
struct B { /* ... */ };
typedef
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
The following code example from C++17 standard 17.6.1.7 does not compile:
template struct A {
struct B { /* ... */ };
typedef
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
Target Milestone: ---
According to the calling conventions of System V AMD64 ABI (e.g.
https://www.uclibc.org/docs/psABI-x86_6
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
This is related to Bug 51253: While that bug was about wrong compiled code and
is reported to be fixed, GCC 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
--- Comment #7 from Ole Kniemeyer ---
OK, thanks for your comments. I wasn't aware of the ongoing discussion about
this issue (I was referring to the the draft version N3376 of the C++11
standard).
A B-copy would be OK, but as I said copying B in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
--- Comment #5 from Ole Kniemeyer ---
Ops, sorry, of course I meant "... to older C++ standards."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
--- Comment #4 from Ole Kniemeyer ---
As I commented in the cpp example, the C++11 standard shows exactly this
example in sections 8.5.3. So this is definitely a bug according to C++11. I
think the GCC behaviour is correct according to older C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
Ole Kniemeyer changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
--- Comment #2 from Ole Kniemeyer ---
Created attachment 30301
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30301&action=edit
cpp file (without any #includes) which shows the bug
: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
14 matches
Mail list logo
