: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Sorry for the title, I have no idea how to describe the problem in any better
way :-/
The following program fails, the static_assert() is (wrongly) triggered:
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91155
--- Comment #10 from Daniel Frey ---
Thanks for working on this.
I'm a bit confused about the "Known to work: 9.2.0" - shouldn't this be 9.3.0
given that GCC 9.2 was already released and does not contain this fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91155
--- Comment #1 from Daniel Frey ---
Additionally, other cases are broken as well. Using
dummy< '\'' >
The output with GCC 9.1 is
dummy< ''' >
while it was correct with GCC 8.3:
dummy< '\'' >
This probably means that characters are not escap
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
This is a regression against 8.x:
#include
template< char C > struct dummy {};
template< typename T > void
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Title says it all. In an unevaluated context, the result is never used anyways.
Other compilers do ignore [[nodiscard]] in those contexts
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80736
Daniel Frey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
The following program leads to an infinite recursion:
#include
template< typename T >
struct vector
{
vector() = default;
vector( const vector& ) = def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77462
--- Comment #2 from Daniel Frey ---
(In reply to Manuel López-Ibáñez from comment #1)
Indeed, this is even worse than I thought.
FWIW, here's a reduced example for my code:
static_assert( 2 + 2 == 4, "oops" );
#line 1
static_assert( 2 +
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
When I use #line, I can make the compiler print a source line from another file
when it encounters an error. This is totally misleading.
Consider two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
--- Comment #7 from Daniel Frey ---
(In reply to Jakub Jelinek from comment #6)
> The advantage of __builtin_unreachable () is that it allows better
> optimizations, at the expense of the invalid code not being so nicely
> reported.
> With -fsani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059
--- Comment #8 from Daniel Frey ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Daniel Frey from comment #3)
> > A better O(log N) library-only solution than the linked one is available at
> > https://github.com/taocpp/sequences/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66059
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
--- Comment #2 from Daniel Frey ---
I'm using Ubuntu 14.04 in a VM, packages are installed from
http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu trusty main. Package
version is 5.1.0-0ubuntu11~14.04.1
Output from g++-5 -v:
Using built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #5 from Daniel Frey ---
I don't know if it is possible for GCC to know, but it feels like it should
know. If one type needs to instantiate another type, this goes on until either
everything worked or GCC stops to instantiate a sub-typ
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
Target Milestone: ---
Consider this small and certainly broken program:
struct B {
B* self;
B() : self( this ) { self-&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #3 from Daniel Frey ---
Just a reminder that the error message is basically still the same with GCC 4.9
and does not help to understand the cause of the error. Especially real-world
cases are therefore extremely hard to understand!
I
++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
The following (invalid) program:
template struct A {};
struct B : A {};
template
void dummy( const A< I... >& );
int main()
{
dummy( B() );
}
yields:
$ g++ -std=c++11 t.cc
t.cc: In function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment #2 from
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
The following program fail to compile.
template struct A
{
template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58435
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment #1 from
++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.frey at gmx dot de
When compiling with Clang and -Wall -Wextra -Werror, I get an error on a
mismatched declaration/definition for std::hash wrt the use of "class" vs.
"struct". The problem seems to be an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468
--- Comment #4 from Daniel Frey 2013-02-28 16:14:41 UTC
---
(In reply to comment #1)
I think the first line you added is enough, as evidenced by my "fix" referenced
in the Stack Overflow discussion (see link above). But the second line w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468
Bug #: 56468
Summary: Clang exposes bug with unexpected forward-declaration
of type_info
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56450
Bug #: 56450
Summary: ICE with SFINAE when detecting non-static member
variable
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #2 from Daniel Frey 2011-10-22 13:19:02 UTC
---
I think I'm asking for the word "recursion" or "recursive" in the error
message, bonus points for clearly identifying the cycle. The example is
obviously too simple to demonstrate the us
28 matches
Mail list logo
