https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78506
lucdanton at free dot fr changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I managed to reduce to this testcase:
//
#include
#include
struct aggr {
std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
My understanding of the new inheriting constructor rules is a bit shaky so I
may be off here. The testcase
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
On r245381, the demonstration program does not complain when compiled.
//--
template
struct [[nodiscard]] missiles {};
missiles make() { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79143
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I'm not entirely sure is the ice-on-invalid tag is warranted here.
$ g++-trunk -std=c++1z main.cpp
main.cpp: In function 'int main
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The spec and intent looks straightforward to me, i should be an lvalue.
//--
struct one {
int i;
};
int main()
{
auto&& [i] = one {};
// error
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I noticed an std::unique_ptr destructor was being called on a bogus
pointer in an own::optional<std::unique_ptr> te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124
--- Comment #2 from lucdanton at free dot fr ---
I ran into a different program that regressed starting at r241187 (again, only
for -std=c++1z), this time not involving explicit constructors:
//--
struct aggr {
int x;
};
struct base
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 40042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40042=edit
untested patch
Curren
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
While trying to compile Boost.Locale with trunk in C++1z mode I ran into the
following regression (simplified):
// error: 'std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I have bisected this regression to r241188.
The program fails to compile in C++1z mode on trunk, yielding this:
$ g++-trunk -std=c++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78073
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372
--- Comment #1 from lucdanton at free dot fr ---
On 7 trunk (rev. 239680) it looks like the program now triggers an ICE:
$ g++-trunk -std=c++1z -fconcepts main.cpp
main.cpp: In substitution of 'template requires C... void
foo::bar(X
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The included program compiles on 6.1 and I think on the 6.2 branch (I would
need definite confirmation however), with either -std=c++14 or -std=c++1z.
On 7 trunk (rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437
--- Comment #1 from lucdanton at free dot fr ---
This compiles using tip of the trunk. Presumably the concepts overhaul took
care
of it.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using the following program:
//--
template struct list {};
template
concept bool Sequence = true;
template
struct zip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72415
--- Comment #2 from lucdanton at free dot fr ---
I completely failed to make note that this used to compile on GCC 6.1, too
(modulo the missing definition, again).
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using rev. 238737 with the following minimal testcase:
//--
template
struct indices {};
template
struct foo_type {
template
static void impl(indices
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
ICE on both 6.1 and 7 trunk (rev. 238124), although I can't verify if the
stacktraces are similar. I don't know if the code should be rejected or not.
$ cat main.cpp
template
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The following produces an ICE on both GCC 6.1 and trunk (rev. 236974):
$ cat main.cpp
struct inner;
template concept bool CompoundReq = requires {
// fine
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
On rev. 236761 it looks like performing member access on a fold expression
produces an 'insufficient
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
struct move_only {
move_only() = default;
move_only(move_only&&) = default;
};
struct base {
base(m
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The following program emits a warning when compiled with
-Wzero-as-null-pointer-constant:
int main()
{
int* no_warn = {};
// main.cpp:5:33: warning: zero as null
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 37641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37641=edit
Minimal testcase
It appears that GCC behaves differen
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The testcase was mechanically reduced.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20160208 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using 6.0.0 20160122, testcase compiled with:
g++-trunk -std=c++1z main.cpp
results in:
main.cpp:13:5: error
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
PR69288 may be related as it also observes some differences in how a
constrained template behaves depending on whether
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 37262
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37262=edit
Preprocessed source
Mechanically reduced preproces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983
--- Comment #8 from lucdanton at free dot fr ---
(In reply to Jason Merrill from comment #7)
> (In reply to lucdanton from comment #6)
> > I've independently run into this bug and applying this patch to HEAD doesn't
> > help on m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Tested on 5.2.0, 5.2.1 and 6.
I believe the testcase is incorrectly rejected. Clang accepts the program. Note
that leaving
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Happens with GCC 5.2.1 and 6.
$ g++-trunk -std=c++14 main.cpp
main.cpp:20:37: error: invalid use of incomplete type 'const
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using 6.0.0 20151208. Compiling yields:
$ g++-trunk -std=c++1z main.cpp
main.cpp: In instantiation of 'struct foo<int, long int, double>':
main.cpp:12:32: require
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using 6.0.0 20151208 the last two asserts fire, whereas they don't with GCC
5.2.1 (as expected). The issue seems constexpr related as not marking
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 36877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36877=edit
Reduced testcase
Using 6.0.0 20151201 (experimen
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The source program was mechanically reduced.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151130 (experimental)
Copyright (C) 2015 Free
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Possibly related to PR c++/68206, which could also be exhibiting both this and
a potentially unrelated ICE.
$ g++-trunk --version
g++-trunk
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 36817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36817=edit
Reduced testcase
Using g++-trunk (GCC) 6.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Testcase compiles fine in C++11 and C++14 modes, ICE is in C++1z mode only.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151124
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 36775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36775=edit
Minimal testcase
This is usin
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I can't really understand the error and I don't know the rules very well, but
here goes.
$ g++-trunk --version
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288
--- Comment #2 from lucdanton at free dot fr ---
(In reply to TC from comment #1)
> This behavior looks correct to me. (Clang behaves identically.)
>
> 0e1_e+0 is a valid pp-number, so per max munch it must be parsed that way,
>
: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I'm seeing this behaviour with GCC 6, GCC 5.2.0 and GCC 4.9.2.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151103 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 35801
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35801action=edit
Minimal
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 35651
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35651action=edit
Minimal testcase
$ g
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 35076
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35076action=edit
Minimal testcase
$ g++-trunk --version
g++-trunk (GCC
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34981
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34981action=edit
Reduced testcase
This is an ICE on invalid code.
$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20150307
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34866
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34866action=edit
Reduced testcase
Using:
$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20150223 (experimental
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34858
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34858action=edit
Minimal testcase
$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20150223
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34300
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34300action=edit
Minimal testcase
Using:
g++-trunk (GCC) 5.0.0 20141218 (experimental)
Testcase:
templatebool B struct
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34122
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34122action=edit
Program exhibiting ICE
GCC version output:
g++-trunk (GCC) 5.0.0 20141126
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 33696
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33696action=edit
Minimal testcase
Attempting to compile
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20140828 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ cat main.cpp
templatetypename T struct tuple_size {};
templatetypename T struct tuple_sizeT const: tuple_sizeT {};
templatetypename T, typename = void
struct query
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600
--- Comment #5 from lucdanton at free dot fr ---
(In reply to Martin Jambor from comment #2)
Well, this is ICE on code with undefined behavior. Function test
calls itself with a parameter which is a reference to an object of
type child2
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 32404
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32404action=edit
Testcase
$ g++-trunk --version
g++-trunk (GCC) 4.9.0 20140319 (experimental)
$ cat main.cpp
struct data {
data
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Using trunk (g++-trunk (GCC) 4.9.0 20140222 (experimental)):
$ cat main.cpp
// fine
// decltype(auto) qux() { return 42; }
struct foo {
// also ICEs
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Using ‘gcc version 4.9.0 20140123 (experimental) (GCC)’ with the following
snippet:
//
struct foo {
typedef void(*ptr)(int);
operator ptr() const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59329
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
--- Comment #1 from lucdanton at free dot fr ---
Happens too with GCC 4.9 (20140105), as well as when using decltype(auto).
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 31114
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31114action=edit
Testcase
Using:
$ gcc-snapshot --version
gcc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-snapshot --version
g++-snapshot (GCC) 4.9.0 20130806 (experimental)
$ cat main.cpp
templatetypename... T
struct foo {
static constexpr auto N
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-snapshot --version
g++-snapshot (Debian 20130603-1) 4.9.0 20130603 (experimental) [trunk revision
199603]
$ cat main.cpp
struct foo {
unsigned i: 32;
};
int main()
{
foo f
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Using 4.9.0 20130509 (experimental) [trunk revision 198734] with flags
-std=c++11:
$ cat main.cpp
struct base {
using base_type = base;
using
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Following the resolution of 57253
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57253) it seems worthwhile to
point out that there are missing specializations of std::function such that
e.g
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 30099
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30099action=edit
Minimal testcase
$ g++-snapshot --version
g++-snapshot (Debian 20130509-1
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-snapshot --version
g++-snapshot (Debian 20130509-1) 4.9.0 20130509 (experimental) [trunk revision
198734]
$ cat main.cpp
templatetypename T
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Using 4.9.0 20130509 (experimental) [trunk revision 198734] and -std=c++11 the
following is rejected:
//---
struct foo {
templatetypename T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
--- Comment #3 from lucdanton at free dot fr 2013-04-28 00:37:37 UTC ---
I do make use of the variable in the pack; that the pack may be empty for some
instantiations may or may not be something to look out for, but I don't think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56953
Bug #: 56953
Summary: [4.9]Inheriting constructors triggers instantiation of
parameters at point of declaration
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
Bug #: 56958
Summary: Spurious unused variable warning in empty pack
expansion
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56452
Bug #: 56452
Summary: [C++11] Using declaration for inheriting constructors
taints template parameter
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56285
Bug #: 56285
Summary: [C++11] Arguments to an inheriting constructor is not
forwarded properly
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56065
Bug #: 56065
Summary: Constant expression incorrectly recognized not as such
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55463
Bug #: 55463
Summary: Result of std::mem_fn doesn't accept rvalues
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55408
Bug #: 55408
Summary: ICE for member template definition with non-type
variadic parameter
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54912
Bug #: 54912
Summary: [C++11] Non-type argument to alias template is not a
constant expression
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
Bug #: 52830
Summary: ICE: canonical types differ for identity types ...
when attempting SFINAE with member type
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49447
Summary: operator= (and compound assignment ops) does not
perfectly forward
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
85 matches
Mail list logo
