https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Ville Voutilainen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119061
--- Comment #3 from Ville Voutilainen ---
Should.. ..the version for this be 16? That's when we expect to do an upstream
push.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119061
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119061
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=117268
--- Comment #2 from Ville Voutilainen ---
Possibly. It makes fair amounts of sense that predefined macros are reapplied
after an options scope is exited. But it does break existing code. See
https://bugreports.qt.io/browse/QTBUG-130381
c
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Godbolt: https://godbolt.org/z/c99oj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115601
--- Comment #2 from Ville Voutilainen ---
Created attachment 58499
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58499&action=edit
Preprocessed source
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
See
https://godbolt.org/z/s8dWGzb9r
When passing a (pointer to) function as a predicate
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
See https://wandbox.org/permlink/SICxkVAe2gVql3Ae
tl;dr:
struct Base1 {
virtual void g(int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
--- Comment #5 from Ville Voutilainen ---
And the papers that changed this are
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1091r3.html and
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1381r1.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
Ville Voutilainen changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
--- Comment #4 from Ville V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107049
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
--- Comment #7 from Ville Voutilainen ---
Since this is a 13 regression, we can close this, right? There's no backports
needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
--- Comment #4 from Ville Voutilainen ---
(In reply to Tom Honermann from comment #3)
> I believe this issue can be resolved as fixed via commit
> 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release.
Yes, it's normal procedure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567
--- Comment #1 from Ville Voutilainen ---
Repro without std::vector:
template
void urgh()
{
const V x[] = {V(0), V(1), V(2), V(0)};
[&]() {
for (auto& v : x) {}
}();
}
void no_urgh()
{
using V = int;
const V x[]
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test:
#include
template
void urgh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Ville Voutilainen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Testcase:
#include
struct oink : std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470
--- Comment #7 from Ville Voutilainen ---
We should close this, the fixes are in 11 and the related bugs have been closed
without backports. I'm happy to let JWakely do that closing, but I don't think
he'll disagree on it. :P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470
--- Comment #6 from Ville Voutilainen ---
I think this was fixed by the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274
Ville Voutilainen changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Created attachment 49957
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49957&action=edit
Preprocessed source
Compile wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #10 from Ville Voutilainen ---
Right - that's the Qt bug I'm hoping to fix, but I don't get far because of the
ICE. :) The libstdc++ headers have been reorganized, so Qt's expectations that
numeric_limits is available without includin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #8 from Ville Voutilainen ---
Also, you can just try the actual build, if you follow
https://wiki.qt.io/Building_Qt_6_from_Git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #7 from Ville Voutilainen ---
(In reply to Martin Liška from comment #5)
> Still can't reproduce it.
> Please send me also output of --verbose.
Yeah, I fed that output to g++, and then it compiles just fine. But when it's
in the actu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #6 from Ville Voutilainen ---
Created attachment 49946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49946&action=edit
Output of --verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #4 from Ville Voutilainen ---
Created attachment 49943
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49943&action=edit
Output of gcc -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
--- Comment #3 from Ville Voutilainen ---
..or maybe I'm just too dumb to invoke g++ -E properly, and the rest of the
options confuse the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054
--- Comment #4 from Ville Voutilainen ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560591.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054
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=96269
--- Comment #9 from Ville Voutilainen ---
Ha, well spotted. In general, in a spaceship world, you do want to provide
comparisons symmetrically and const-correctly, and that also works in the
pre-spaceship world, thus:
#include
struct X {
tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #5 from Ville Voutilainen ---
Oh, and if you define a spaceship operator for your type, then things work
again, with or without FLIP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663
Ville Voutilainen changed:
What|Removed |Added
CC||jason at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449
--- Comment #2 from Ville Voutilainen ---
Patch available:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556323.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. I have a patch for it already, doing testing and submission chores...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95904
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91807
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
dot com
CC||ville.voutilainen at gmail dot
com
--- Comment #3 from Ville Voutilainen ---
Mine.
dot com
Status|NEW |ASSIGNED
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
Ville Voutilainen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
--- Comment #1 from Ville Voutilainen ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549030.html
||2020-06-26
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
>From Patrice Roy:
The following code compiled in C++17 but seems broken in C++20, at least
according the Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #17 from Ville Voutilainen ---
(In reply to Ville Voutilainen from comment #16)
> (In reply to Iain Sandoe from comment #14)
> > (In reply to Ville Voutilainen from comment #12)
> > The idea of bringing the lambda's captures into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #12 from Ville Voutilainen ---
It sure seems to me that a coroutine lambda's captures should be copied to the
coroutine state. I don't think the standard says that anywhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
--- Comment #7 from Ville Voutilainen ---
..and as expected, std::optional is broken the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
--- Comment #8 from Ville Voutilainen ---
(In reply to Marek Polacek from comment #6)
> Thanks Ville. What I should have said...
>
> (In reply to Marek Polacek from comment #4)
> > My current theory is that it is not a bug.
>
> ...in the compi
dot com
CC||ville.voutilainen at gmail dot
com
Last reconfirmed||2020-05-01
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94197
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94149
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Test:
template
void f() requires b &&a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947
--- Comment #3 from Ville Voutilainen ---
Any chance of progress on this before 10 ships?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92570
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92947
--- Comment #1 from Ville Voutilainen ---
Based on some debugging work, build_functional_cast_1 looks like a plausible
place where we might need to add understanding of parenthesized aggregates. The
previous bug report has an incomplete (because
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
struct aggressive_aggregate
{
int a;
int b;
};
int main()
{
sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #9 from Ville Voutilainen ---
This seems to do the right thing for __is_constructible. I haven't looked at
decltype or noexcept yet.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 97c27c51ea3..4b8daf8634f 100644
--- a/gcc/cp/me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #8 from Ville Voutilainen ---
One more thing besides the __is_constructible; this aggregate doesn't seem to
work in an unevaluated context. Both
decltype(aggressive_aggregate(1,2))
and
noexcept(aggressive_aggregate(1,2))
are rejec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #7 from Ville Voutilainen ---
__is_constructible is incorrectly false for such an aggregate:
struct aggressive_aggregate
{
int a;
int b;
};
int main()
{
static_assert(__is_constructible(aggressive_aggregate, int, int));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #1 from Ville Voutilainen ---
Wishlist item: please add a C++2a mode libstdc++ test that verifies that
make_unique and make_shared work with aggregates. Bonus points for
std::allocator_traits>::construct.
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
//#include
struct aggressive_aggregate
{
int a;
int b;
};
int main()
{
auto x = aggressive_aggregat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #11 from Ville Voutilainen ---
(In reply to Jonathan Wakely from comment #10)
> I don't think it has been written yet.
Right; I decided against it, since the cats are out of the bag and shipping
implementations voted with their feet,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #7 from Ville Voutilainen ---
Innocent users are going to hit it: https://bugreports.qt.io/browse/QTBUG-75210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #6 from Ville Voutilainen ---
Any chance of moving this warning out of -Wextra and re-considering adding it
there for GCC 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89825
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
--- Comment #10 from Ville Voutilainen ---
Assignment can be made to avoid double-visitation, instead of using
_M_destructive_move/copy. Other than that, getting it to generate fewer table
items needs the idea from the other bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
||2019-03-25
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=89816
--- Comment #8 from Ville Voutilainen ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01200.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
--- Comment #7 from Ville Voutilainen ---
Looks good - I'll do a patch shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
--- Comment #5 from Ville Voutilainen ---
Correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
--- Comment #3 from Ville Voutilainen ---
The problem here is that the older approach knows that it's always from type X1
to type X1, never from type X4 to X2. The visitation approach generates
combinations that we never use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #2 from Ville Voutilainen ---
This is not just a Qt problem. I will write a proposal to undeprecate this
deprecation for C++20 before the next committee meeting.
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
Consider code like this:
struct X
{
protected:
~X() {}
};
struct Y : X
{
Y() = default;
Y(const Y& other)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #16 from Ville Voutilainen ---
(In reply to Florian Weimer from comment #15)
> (In reply to Ville Voutilainen from comment #13)
> > Well, Jonathan found this http://lists.isocpp.org/core/2018/06/4643.php
>
> Would you please summariz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #14 from Ville Voutilainen ---
(In reply to fiesh from comment #12)
> X(double) : X(X(42)) {} // clang doesn't like this
>
> is also enough to show the difference, no need for an operator.
Yeah. The list-archive link that you probab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #13 from Ville Voutilainen ---
Well, Jonathan found this http://lists.isocpp.org/core/2018/06/4643.php
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
Ville Voutilainen changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #10 from Ville Voutilainen ---
Here's another one where gcc and clang disagree:
https://wandbox.org/permlink/UsViiOoDRgdismAy
The disagreement is over
X(bool b) : X((b, X(42))) {}
where b is unused, gcc elides the temporary and clan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #9 from Ville Voutilainen ---
See https://wandbox.org/permlink/snAuT59ocie38DU5
Here's a tl;dr:
struct NonTrivial {NonTrivial(const NonTrivial&) {}};
struct X {
X() : x(42) {}
X(bool b) : X(b ? X(42): X(666)) {} // clang doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #8 from Ville Voutilainen ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to fiesh from comment #0)
> > (If this is true, is it
> > a separate gcc bug that it does not delete the union's constructor?)
>
> Yes, I think s
1 - 100 of 561 matches
Mail list logo
