https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114190
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #43 from rguenther at suse dot de ---
On Mon, 4 Mar 2024, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
>
> --- Comment #41 from Richard Sandiford ---
> (In reply to Richard Biener from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #4 from Uroš Bizjak ---
(In reply to Sam James from comment #0)
> (insn 160 159 161 26 (parallel [
> (set (reg:V2QI 250 [ vect_patt_207.470_183 ])
> (minus:V2QI (reg:V2QI 251)
> (reg:V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114108
--- Comment #8 from Tejas Belagod ---
I find this transformation a bit odd:
...
pr114108.c:11:21: note: add new stmt: vect_patt_32.15_181 = .ABD
(vect__3.11_177, vect__7.14_180);
pr114108.c:11:21: note: -->vectorizing statement: patt_31 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #5 from Uroš Bizjak ---
Huh, it looks that optimize_function_for_size_p (cfun) is not stable during
LTO?!
Using:
--cut here--
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 2856ae6ffef..80114494b0b 100644
--- a/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #6 from Richard Biener ---
It's possibly on a cold path (yes, optimize_function_for_size_p should be
stable). Note though that optimize_function_for_size_p might in theory
change between vectorization and RTL expansion, so maybe opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #8 from Richard Biener ---
> grep optimize_ insn-flags.h | wc -l
14
so it's not very many standard patterns that would be affected. I'd say
using these kind of flags on standard patterns is at least fragile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114190
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8ee6d13e32279faf9ef4fd8eabfba0adfca0dfb9
commit r14-9313-g8ee6d13e32279faf9ef4fd8eabfba0adfca0dfb9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114157
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9d2bc5def30830e685ae2e3c2f4d07b967e2be63
commit r14-9314-g9d2bc5def30830e685ae2e3c2f4d07b967e2be63
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:aed445b0fd0c7ed16124c61e7eb732992426f103
commit r14-9315-gaed445b0fd0c7ed16124c61e7eb732992426f103
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] wrong|[13 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114157
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> > grep optimize_ insn-flags.h | wc -l
> 14
>
> so it's not very many standard patterns that would be affected. I'd say
> using these kind of flags on standard p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
--- Comment #12 from Richard Biener ---
So the immediate reason is that between analysis and transform whether we
consider the shift vectorizable changes. That's because we code generated
a live lane which ended up changing operands in stmts we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2024-03-05
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #15 from Sarah Julia Kriesch ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Sarah Julia Kriesch from comment #12)
> A bigger case of what? What do you mean?
Not only one software package is affected by this bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #11 from Richard Biener ---
(In reply to Uroš Bizjak from comment #10)
> Created attachment 57612 [details]
> Prototype patch
>
> Let's try this approach.
Yeah, I guess !TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #44 from Richard Biener ---
(In reply to Richard Sandiford from comment #42)
> Created attachment 57605 [details]
> proof-of-concept patch to suppress peeling for gaps
>
> How about the attached? It records whether all accesses tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
Bug ID: 114234
Summary: [14 Regression] verify_ssa failure with early-break
vectorisation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7890836de20912bd92afaf5abbeaf9d8c5b86542
commit r14-9316-g7890836de20912bd92afaf5abbeaf9d8c5b86542
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> Still, it would be nice to understand what changed
> optimize_function_for_size_p (cfun)
> after IPA. Is something adjusting node->count or node->frequency?
> O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #14 from rguenther at suse dot de ---
On Tue, 5 Mar 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
Richard Biener changed:
What|Removed |Added
Summary|[12/13/14 regression] ICE |[12/13 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114235
Bug ID: 114235
Summary: Object undefined is specific procedure for generic
overload in abstract type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #9 from Jakub Jelinek ---
Still reproduceable with
--- gcc/tree-scalar-evolution.cc
+++ gcc/tree-scalar-evolution.cc
@@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop)
/* Propagate constants immediately, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
Richard Biener changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
--- Comment #9 from Uroš Bizjak ---
Noticed this in passing:
--> movq%rcx, %rdx
addqv(%rip), %rax
adcqv+8(%rip), %rdx
vmovq %rax, %xmm1
vpinsrq $1, %rdx, %xmm1, %xmm0
We could use %rcx instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114236
Bug ID: 114236
Summary: introduce unnecessary store operation when unrolling a
loop
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #15 from Jakub Jelinek ---
Yeah, indeed, the optabs enable flags are cached in the optimization node, so
it is ok
to check the optimization flags in there, or target flags as well, but
optimize_function_for_*_p is not, because it dep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Seems various backends use e.g. optimize_size or !optimize_size or optimize
> > 0 etc. in
> insn-flags.h, so perhaps change optimize_function_for_size_p (cfun)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114206
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #17 from Jakub Jelinek ---
Either change those too, or the splitter needs some variant what to do if there
is a mismatch.
Though, optimize_size implies optimize_function_for_size_p (cfun), so if a
named pattern uses && optimize_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076
--- Comment #3 from Benjamin Buch ---
I [created an overview](https://stackoverflow.com/a/78101462/4821621) with all
cases that currently work on StackOverflow. I think that all these cases should
be valid. For a properly formated version with l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850
Benjamin Buch changed:
What|Removed |Added
CC||benni.buch at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #18 from Jan Hubicka ---
optimize_function_for_size_p is not really affected by LTO or non-LTO.
It does take into account node->count and node->frequency, which is
updated during IPA, so it may change between early opts and late opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850
--- Comment #7 from Benjamin Buch ---
Sorry wrong number; Bug 114076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Bug ID: 114237
Summary: GCC emits no narrowing conversion warning when call is
made indirectly through std::invoke
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #19 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #18)
> But the problem here is more that optab initializations happens only at
> the optimization_node changes and not if we switch from hot function to
> cold?
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #20 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Jan Hubicka from comment #18)
> > But the problem here is more that optab initializations happens only at
> > the optimization_node changes and not
Looking at the prototype patch, why need to change also the splitters?
My original goal was to use splitters to expand to faster code sequences
while having patterns necessary for both variants. This makes it
possible to use optimize_insn_for_size/speed and make decisions using BB
profile, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #21 from Jan Hubicka ---
Looking at the prototype patch, why need to change also the splitters?
My original goal was to use splitters to expand to faster code sequences
while having patterns necessary for both variants. This makes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Bug ID: 114238
Summary: Multiple 554.roms_r run-time regressions (4%-20%)
since r14-9193-ga0b1798042d033
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #22 from rguenther at suse dot de ---
On Tue, 5 Mar 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
>
> --- Comment #17 from Jakub Jelinek ---
> Either change those too, or the splitter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #23 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #21)
> Looking at the prototype patch, why need to change also the splitters?
Purely for implementation reasons, we check for general resp. SSE register in
the operand p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #24 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #22)
> I think optimize_function_for_size_p (cfun) isn't always true if
> optimize_size is since it looks at the function-specific setting
> of that flag, so you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
Bug ID: 114239
Summary: ice: error: definition in block does not dominate use
in block
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
--- Comment #1 from Sam James ---
The testcase is the same as in PR113555 - so should've added to test suite I
suppose. Indeed ICEs on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #25 from Uroš Bizjak ---
Created attachment 57614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57614&action=edit
Proposed patch
Proposed patch that changes optimize_function_for_size_p (cfun) to
optimize_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #26 from Jan Hubicka ---
> I think optimize_function_for_size_p (cfun) isn't always true if
> optimize_size is since it looks at the function-specific setting
> of that flag, so you'd have to use opt_for_fn (cfun, optimize_size).
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
--- Comment #3 from Jakub Jelinek ---
That said, I fail to see why the a/2*2 in there matters.
a*!a is simply always 0 for integral types, both signed and unsigned, including
signed 1-bit precision. If a is 0, the result is 0*1 (or for the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2024-03-05
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #5 from Jonathan Wakely ---
return EnumeratorRange(Enumerator(std::views::single(Intersection(;
This creates a temporary Intersection object, then copies that into a
single_view object. Then that is copied into an Enumerator o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Bug ID: 114240
Summary: sys_days not being parsed with only a date in the
stream
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114236
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #1 from Jonathan Wakely ---
I think the problem is that I just have some generic logic that assumes all
sys_time specializations are a date time, and so require both a date and a
time. But obviously for sys_days we only need a date.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #16 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:2ba3171f161452df476485272cc966bc523d9859
commit r14-9321-g2ba3171f161452df476485272cc966bc523d9859
Author: Saurabh Jha
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #2 from Howard Hinnant ---
In my date lib I just presumed 00:00:00 time of day when parsing time_points,
unless the parse produced another time of day. Though I must admit that this
didn't come through in the spec. So there is a li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111958
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #6 from Richard Biener ---
Thanks, so keeping this open but it will likely end up INVALID.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114241
Bug ID: 114241
Summary: False-positive -Wodr warning when using -flto and
-fno-semantic-interposition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
Bug ID: 114242
Summary: Coroutine with lambda-coroutine and operator new does
not compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #3 from Jonathan Wakely ---
So this would fix it:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -2826,7 +2826,9 @@ namespace __detail
__offset = &__off;
using __format::_Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
Bug ID: 114243
Summary: -fsplit-wide-types bloats code by more than 50%
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111839
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98881
--- Comment #5 from Pilar Latiesa ---
(In reply to Pilar Latiesa from comment #4)
> I can no longer reproduce the issue with 11.3 or 12.1
Because those were releases that didn't have checking enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113611
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
Bug ID: 114244
Summary: Need to use round when parsing fractional seconds
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:067a012bde15bfb62d9af309d9d524ebfe91b705
commit r14-9322-g067a012bde15bfb62d9af309d9d524ebfe91b705
Author: Richard Earnshaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
--- Comment #1 from Andrew Pinski ---
Note IIRC C++26 (maybe even 23) changed in this area over C++20 and GCC is
following (the initial?) C++20 rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
--- Comment #2 from Andrew Pinski ---
Created attachment 57617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57617&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
Andrew Pinski changed:
What|Removed |Added
Keywords||C++-coroutines,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
--- Comment #4 from Andreas Fertig ---
Thanks for looking into the issue!
While CWG 2585 tweaks the wording, my reading is that the code should be valid
even with C++20.
Regardless of that, without the lambda, the code compiles and uses a cust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #24 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #23)
> As it appears, this bug is not fixed completely. For the -mmcu=avrtiny
> architecture, there is still bloat for even the smallest test cases like:
Diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:fca6f6fddb22b8665e840f455a7d0318d4575227
commit r14-9324-gfca6f6fddb22b8665e840f455a7d0318d4575227
Author: Richard Sandiford
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
--- Comment #5 from Andreas Fertig ---
My latest conclusion is that my code is indeed invalid. In the case of the
lambda, I have a class type. http://eel.is/c++draft/dcl.fct.def.coroutine#4
says that in such a case, p1 is an lvalue of *this. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114245
Bug ID: 114245
Summary: Defaulted virtual destructors that do no work
overwrite the vtable with `-O0`
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity
r14-9323-20240305175124-g8776468d9e5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240305 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229
--- Comment #3 from Patrick Palka ---
In the reduced testcase the vtable for basic_streambuf should get emitted
only from 114229_d but it seems to get emitted from 114229_b too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
--- Comment #1 from Georg-Johann Lay ---
May be related to PR110093. As Vladimir noted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093#c5
the problem is that data flow analysis cannot cope with the subregs generated
from lower-subregs,
1 - 100 of 145 matches
Mail list logo
