https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
--- Comment #7 from MARK BOURGEAULT ---
>> See PR 100070 for suggestions to deal with such iterators better.
Unless I'm missing something, there's nothing in that PR that a *user* can do
to achieve the gcc 10.3 performance w/ std::iota_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
--- Comment #1 from Andrew Pinski ---
This seems like a bug in circle ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438
--- Comment #10 from Bernie Innocenti ---
Still present on GCC 12.2.
Could someone look into it please, or point me at the point in ipa-icf.cc where
the array-bounds analysis information should have been updated after merging
the template insta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
Bug ID: 108490
Summary: circle compiler support for libstdc++
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Attachment #54289|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> That's because iota_view's iterator is only an input iterator in gcc-10,
I meant to say gcc-10.4 there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
--- Comment #4 from Jonathan Wakely ---
That's because iota_view's iterator is only an input iterator in gcc-10, as a
result of r10-9796-g1cb39945993c89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:48f544ad5c98b668d8d345eaafcf09cc0bd44635
commit r13-5276-g48f544ad5c98b668d8d345eaafcf09cc0bd44635
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #14 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jerry DeLisle
:
https://gcc.gnu.org/g:6d307fda2b9ba71fe18f1449f7444bed7ff05193
commit r12-9055-g6d307fda2b9ba71fe18f1449f7444bed7ff05193
Author: Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
Nate Eldredge changed:
What|Removed |Added
CC||nate at thatsmathematics dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2023-01-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #12 from Andrew Pinski ---
This is just a latent bug exposed by Richi's copyprop improvement.
Folding statement: ivtmp_37 = ivtmp_38 - 1;
gimple_simplified to ivtmp_37 = 1;
Folded into: ivtmp_37 = 1;
Folding statement: if (ivtmp_3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #6 from Martin Uecker ---
Actually, I meant PR84305 for C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
--- Comment #5 from Martin Uecker ---
Probably related to PR88256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #11 from Steven Sun ---
(In reply to Andrew Pinski from comment #10)
> https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2392
>
> "potentially-evaluated".
Oh, I realized that,
According to the DR 2392 accepted as a DR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #14 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031
commit r13-5274-g442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031
Author: Iain Sandoe
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #11 from David Binderman ---
It looks to me like g:af96500eea72c674a5686b35c66202ef2bd9688f
is the culprit.
Over to Richard for their best advice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #9 from David Binderman ---
(In reply to David Binderman from comment #8)
> Current range is about 151 revisions.
After a few more rounds, current range seems to be g:fbad7a74aaaddea3
to g:c16c40808331a029, some 10 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
Alexander Monakov changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #3 from Alexa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> (In reply to David Binderman from comment #6)
> > (In reply to David Binderman from comment #5)
> > > (In reply to David Binderman from comment #0)
> > > > T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #7 from David Binderman ---
(In reply to David Binderman from comment #6)
> (In reply to David Binderman from comment #5)
> > (In reply to David Binderman from comment #0)
> > > The bug seems to exist since sometime before g:02c03108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated
> > 20221220.
>
> I tried out a re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #0)
> The bug seems to exist since sometime before g:02c031088ac0bbf7, dated
> 20221220.
I tried out a revision from a month earlier, dated 2022-11-20,
g:59cc4da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
--- Comment #2 from MARK BOURGEAULT ---
>> For fn1, assembly of the inner loop should be identical, so I think the 20%
>> you were seeing may result from different loop alignment with respect to 32b
>> fetch boundary
Yes, it does appear that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106307
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2023-01-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #5 from Georg-Johann Lay ---
...ok, yes, building outside srcdir won't fix this one. But points 1) and 2)
still apply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #4 from Georg-Johann Lay ---
Well, updating or creating some auto-generated files is intentional.
What's not supported as of GCC documentation is configure'ing in the source
tree:
https://gcc.gnu.org/install/configure.html
> First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489
--- Comment #2 from Jan Wilmans ---
tested: fails on all GCC versions after 10.1, including trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489
--- Comment #1 from Jan Wilmans ---
remove line 18, to make it compile, and fail at runtime using ASAN
-std=c++20 -O3 -Wconversion -Wsign-conversion -Werror -Wall -Wpedantic
-fcoroutines -fsanitize=address -fsanitize=undefined -freport-bug
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108489
Bug ID: 108489
Summary: internal_error adding data fields in a promise_type
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #7 from Jakub Jelinek ---
If it needs to be used in constant expression and you want warnings for the
non-void * cases with pointers, not arrays and errors for use of void *
pointers except for NULL, then maybe:
typedef __SIZE_TYPE__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487
Alexander Monakov changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #6 from Jakub Jelinek ---
Seems kernel has #define NULL ((void *)0), so if it is solely about allowing
NULL,
you could also
#define ARRAY_SIZE_MAYBENULL(x) _Generic((x), void*: (BUG_ON(x), 0), default: \
sizeof(x)/sizeof(_Generic((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472
Dennis Clarke changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
39 matches
Mail list logo
