||2016-10-12
CC||jason at redhat dot com,
||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
--- Comment #4 from Ville Voutilainen ---
Clang accepts
||2016-10-07
CC||jason at redhat dot com,
||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
||2016-10-05
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
--- Comment #4 from Ville Voutilainen ---
This bug could use some lovin', projects like
https://github.com/Eelis/geordi
are also
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
First test:
#include
int main()
{
std::pair x{42, 666};
}
Second test:
#include
int main()
{
std::tuple y{1,2,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77802
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77802
--- Comment #2 from Ville Voutilainen ---
Mine.
||2016-09-30
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77781
Ville Voutilainen changed:
What|Removed |Added
Keywords||rejects-valid
CC|
at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77727
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
Ville Voutilainen changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77717
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77727
--- Comment #2 from Ville Voutilainen ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01777.html
||2016-09-26
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen
||2016-09-23
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen ---
Ah, Jonathan fixed the problem for std::experimental::string_view in r238609,
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
Ville Voutilainen changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
Ville Voutilainen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
--- Comment #5 from Ville Voutilainen ---
There's a fairly decent chance, sure. :) I'll cook up a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #10 from Ville Voutilainen ---
And yes, I plan to port this fix to experimental::optional on trunk and then
backport that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #9 from Ville Voutilainen ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
Ville Voutilainen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77619
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77619
--- Comment #2 from Ville Voutilainen ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01131.html
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #1 from Ville Voutilainen ---
Mine.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test:
int main()
{
[](auto...){}();
}
prog.cc: In function 'int main()':
prog.cc:3:19: error: no match for call to '(main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77537
--- Comment #1 from Ville Voutilainen ---
See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01230.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77495
Ville Voutilainen changed:
What|Removed |Added
Depends on||77288
--- Comment #1 from Ville
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
--- Comment #6 from Ville Voutilainen ---
Fixed on trunk, backporting to the gcc-6 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
--- Comment #4 from Ville Voutilainen ---
And now the hopefully final patch at
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01990.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
--- Comment #2 from Ville Voutilainen ---
Right, patch available at
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01983.html
Currently fixing negative test failures for it...
||2016-08-29
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #7 from Ville Voutilainen ---
See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01634.html for what the
aforementioned superior approach looks like.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #6 from Ville Voutilainen ---
There's a superior fix that retains conversions but doesn't cause this
regression. Stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #5 from Ville Voutilainen ---
Ah. That would indeed mean that every converting assignment introduces
a temporary. Design-wise I'd rather have it so that optional doesn't convert
at all in the assignment. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
--- Comment #3 from Ville Voutilainen ---
>Now behaviour is the same as in gcc 5.1 - operator=(_Up&& __u) is chosen in 2
>situations:
>1. _Up is NOT optional
>2. _Up is optional AND _Up is same as _Tp modulo cv-qualifiers, references etc.
How
||2016-08-18
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #2 from Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77264
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71886
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
--- Comment #3 from Ville Voutilainen ---
Fixed on trunk so far, backporting to gcc-6 and gcc-5 shortly.
||2016-06-06
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71364
--- Comment #3 from Ville Voutilainen ---
Which version of range-v3? I cloned https://github.com/ericniebler/range-v3.git
and its tests seem to pass on the current trunk.
||2016-06-01
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #2 from Ville Voutilainen ---
I'll do some bisecting and other analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #13 from Ville Voutilainen ---
Right, that was fixed in the immediately following revision,
https://gcc.gnu.org/viewcvs/gcc?view=revision=236823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #11 from Ville Voutilainen ---
I don't see how any of that code or the failure is in any way related to
std::tuple...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #8 from Ville Voutilainen ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01914.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70845
Ville Voutilainen changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70845
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528
--- Comment #10 from Ville Voutilainen ---
(In reply to Jonathan Wakely from comment #8)
> I don't know how to implement is_default_constructible without using that
> decltype, or something similar that will cause the same problem.
>
> If we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70437
--- Comment #2 from Ville Voutilainen ---
Created attachment 38179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38179=edit
First stab at a patch
Initial patch done, testsuite additions to follow, will submit once
compile-farm testing is
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #1 from Ville Voutilainen ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528
--- Comment #1 from Ville Voutilainen ---
A shorter reproducer for the funny part where the error arises:
template
struct I {
};
struct J {
struct K {
int First = 0;
};
I FunctionMDInfo;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037
--- Comment #1 from Ville Voutilainen ---
The trace:
error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
"tuple<> is eligible for EBO" );
^
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Created attachment 37838
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37838=edit
Preprocessed test
Hav
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test:
template concept bool Large = sizeof(T) > 1;
template
struct X
{
X() requires Large = default;
X() requires !Large = default;
};
int m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|SUSPENDED
--- Comment #2 from Ville
||2016-02-17
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen
||2016-02-06
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
Known to fail||4.9.2, 5.2.0, 6.0
--- Comment #2 from Ville Voutilainen ---
clang and msvc accept
|UNCONFIRMED |NEW
Last reconfirmed||2016-02-06
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
Known to fail||4.9.2, 5.2.0, 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42329
Ville Voutilainen changed:
What|Removed |Added
CC||filip.roseen at gmail dot com
---
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #5 from Ville Voutilainen ---
I'll see what I can do. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69178
Ville Voutilainen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69178
--- Comment #1 from Ville Voutilainen ---
This check happens in check_bases(), which doesn't take complain flags, so
wherever that check fails, it's always a hard error. I suppose the checking
function call chains that go to that function should
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test snippet:
template struct S : T {};
template concept bool ConcreteDerivableFrom()
{
return requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #7 from Ville Voutilainen ---
Not so simple, still working on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #6 from Ville Voutilainen ---
Should be a simple matter of doing the _NonNestedTuple checks before other
checks. Patch coming in a couple of days.
||2015-12-20
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #5 from Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276
--- Comment #5 from Ville Voutilainen ---
The enhancement PR is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68989.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276
--- Comment #4 from Ville Voutilainen ---
The current approach still needs to catch bad_new_array_length exceptions. That
is intended to be solved by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1992 so once we get
to stage 1 for
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1992, we can
remove the catch
||2015-12-18
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen ---
And it's mine. :) I'll keep Jason up to date about the library needs here
once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68989
Ville Voutilainen changed:
What|Removed |Added
Target Milestone|--- |7.0
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
Ville Voutilainen changed:
What|Removed |Added
Target Milestone|--- |7.0
Severity|normal
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #2 from Ville Voutilainen ---
Mine.
||2015-12-15
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #2 from Ville Voutilainen ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68139
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68784
--- Comment #5 from Ville Voutilainen ---
And to add insult to injury, msvc accepts binding lvalue reference to
temporaries, and chances are that their thread constructor does what it does
partly because of that non-conforming core language
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #2 from Ville Voutilainen ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68138
--- Comment #1 from Ville Voutilainen ---
The test works if operator== is not a member. There's something fairly fishy
going on here.
||2015-11-11
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
Known to fail||4.8.2, 4.9.2, 5.2.0, 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67813
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #1 from Ville Voutilainen ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 58566, which changed state.
Bug 58566 Summary: [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
--- Comment #4 from Ville Voutilainen ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01075.html
||2015-10-11
CC||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
Ever confirmed|0 |1
--- Comment #3 from Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566
--- Comment #5 from Ville Voutilainen ---
Ahem, make that https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01076.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362
--- Comment #5 from Ville Voutilainen ---
Oh, some crash with -std=c++1z but not with the current default of -std=c++14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67844
--- Comment #3 from Ville Voutilainen ---
Patch available https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00358.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67844
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||ville.voutilainen at gmail dot
com
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
--- Comment #2 from Ville Voutilainen ---
To the extent anything in this area is obvious, yes. :) The check for
non-nested tuple ends up in infinite
||ville.voutilainen at gmail dot
com
Resolution|--- |FIXED
--- Comment #9 from Ville Voutilainen ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537
--- Comment #4 from Ville Voutilainen ---
I'll see if I can do a reasonable library fix, even if the problem is
caused by a buggy front-end.
201 - 300 of 553 matches
Mail list logo
