https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
>
> Agree.
>
> > Now, with the original code,
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
--- Comment #2 from Frank Heckenbach ---
Since I can't easily upgrade to trunk, I need to know if the warning is bogus
in 12.2 and I can safely disable it, or do I need to worry about the generated
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Andrew Pinski changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 109563, which changed state.
Bug 109563 Summary: accessing 9223372036854775810 or more bytes at offsets [2,
9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at
offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Bug ID: 109563
Summary: accessing 9223372036854775810 or more bytes at offsets
[2, 9223372036854775807] and 1 may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:57e7229a29ca0e9929b61051e4f5857f0b41b6c7
commit r14-105-g57e7229a29ca0e9929b61051e4f5857f0b41b6c7
Author: Jiufu Guo
Date: Tue Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
--- Comment #1 from Andrew Pinski ---
>/usr/include/stdio.h:189:24: error: expected ‘,’ or ‘;’ before ‘__attr_dealloc’
Hmm, --disable-multilib is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
Bug ID: 109562
Summary: Failed to build native GCC 12.2.0 on RISC-V64 linux
machine
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109561
Bug ID: 109561
Summary: -Wmaybe-uninitialized false positive false positive
false positive false positive false positive
Product: gcc
Version: 12.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
panigstein at hotmail dot com changed:
What|Removed |Added
CC||panigstein at hotmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
Andrew Pinski changed:
What|Removed |Added
Component|other |testsuite
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
Bug ID: 109560
Summary: new test case g++.dg/ext/int128-8.C from
r14-88-ged32ec26697cc7 fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> First, note, 'allocated(f())' throws an error.
Agree.
> Now, with the original code,
>
> is_allocated(f())
>
> The function reference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #2 from Marek Polacek ---
Originally this happened when including boost headers, function_template.hpp in
particular, where newer versions suppress a lot of warnings:
commit b75386f628b46f1060a20b6e015931bac37b7da7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Marek Polacek changed:
What|Removed |Added
Summary|Unexpected |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Bug ID: 109559
Summary: Unexpected -Wmaybe-uninitialized warning when inlining
with system header
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #16 from Steve Kargl ---
On Wed, Apr 19, 2023 at 07:15:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:58b7dbf865b146a4e65dbda9be6df78f212c03b6
commit r14-92-g58b7dbf865b146a4e65dbda9be6df78f212c03b6
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58538
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #13)
> Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> text. I suppose one can claim that gfortran should throw an
> error when a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #13 from Steve Kargl ---
On Wed, Apr 19, 2023 at 05:25:20PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> I'm trying to check with the issue reporter how extensive is his
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #7 from qinzhao at gcc dot gnu.org ---
Okay, thanks for the comment. I see why this should not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109551
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #12 from Leandro Lupori ---
(In reply to anlauf from comment #11)
> Do you have anybody else supporting the view that the code in question
> should work as an extension?
>
I know there is some usage of this extension, in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:90361bc6f4edb444e86380b6d1e08475fa74
commit r13-7227-g90361bc6f4edb444e86380b6d1e08475fa74
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
commit r14-91-g5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Jason Merrill changed:
What|Removed |Added
Known to work|13.0|
Summary|[12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #5 from Martin Uecker ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Uecker from comment #3)
> > I general the pointer could point to the first object of an array that has
> > more elements, or to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #22 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:7b30f13b904f137c77e5180357af7917a3b47af0
commit r12-9447-g7b30f13b904f137c77e5180357af7917a3b47af0
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #3)
> I general the pointer could point to the first object of an array that has
> more elements, or to an object of a different type.
How so? p in comment 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479
Jose E. Marchesi changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #0)
> I am wondering for
> p.3_1 = p;
> _2 = __builtin_object_size (p.3_1, 0);
>
> why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
> size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481
Jose E. Marchesi changed:
What|Removed |Added
CC||jemarch at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #6 from Jakub Jelinek ---
Indeed, the reduction got stuck at around 1.4M size and didn't reduce further
until I've killed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #1 from Siddhesh Poyarekar ---
The __bdos call itself cannot succeed in main() because it cannot see the
allocation in store(). One way it could succeed is if store() was inlined, but
for some reason it doesn't, even if you make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #40 from qinzhao at gcc dot gnu.org ---
I had an initial patch to support the element_count attribute and use this
attribute in builtin_dynamic_object_size(), for the following testing case:
1 #include
2 #include
3 #ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Bug ID: 109558
Summary: bpf: support BTF and DWARF tag annotations for BPF
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Bug ID: 109557
Summary: __builtin_dynamic_object_size() does not work for
simple testing case
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #3)
> Note I disagree with load_uint32_t having a warning. the pointer might be
> have a const qualifier on it does not mean the location is const overall.
And the doc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection,|
|needs-reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
--- Comment #3 from Andrew Pinski ---
Note I disagree with load_uint32_t having a warning. the pointer might be have
a const qualifier on it does not mean the location is const overall.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:04a9209dc865dafe3c9615f5c868aa3fd89b96cf
commit r14-89-g04a9209dc865dafe3c9615f5c868aa3fd89b96cf
Author: Andrew Pinski
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #6 from Jeffrey A. Law ---
And just an FYI, the tester is flagging conditional move failures for mips64-*
rx-elf and s390-linux-gnu. Most likely these are additional cases where the
hook is indicating the transformation isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #21 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ed32ec26697cc77492d094b31a0d2eebc0535644
commit r14-88-ged32ec26697cc77492d094b31a0d2eebc0535644
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Andreas Schwab changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
--- Comment #9 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724
commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak
Date: Wed Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #15 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724
commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #24 from Jakub Jelinek ---
You're right. libstdc++.so.6 would then initialize just the old symver copy
and not the new one, which could be used by newer shared libraries.
So that leaves the asm (".globl _Zwhatever"); in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #23 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #20)
> So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts
> into the binary not just one but both symbols and so the aliasing isn't
> broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
--- Comment #10 from Ilya Leoshkevich ---
This bug was fixed and backported to gcc-12:
commit 06254d97b8fa3a5d1c8b6b4e091d851700801385
Author: Ilya Leoshkevich
Date: Fri Jul 29 16:14:10 2022 +0200
PR106342 - IBM zSystems: Provide vsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Khokholkov Vladimir changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #22 from Jakub Jelinek ---
extern int cinalias __attribute__((__symver__ ("_ZSt4cin@GLIBCXX_3.4")));
void foo ()
{
cinalias++;
}
doesn't work to refer to older symver, but
extern int cinalias;
asm (".symver cinalias,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #21 from Sam James ---
The commits got reverted in r14-76-ga6e4b81b12e57b and r14-77-gfac24d43e68838
after marxin reported a segfault with mold in #gcc and fweimer reported an
issue with cmake at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #3 from Jakub Jelinek ---
Reproduced, reducing now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #4 from Jeffrey A. Law ---
x86's tuning does have some support for avoiding multiple cmovs in a single
if-converted sequence. I'll double check if that's kicking in here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #2 from Fabian Sauter
---
Created attachment 54884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54884=edit
Preprocessed Source
Ah, it failed to upload with: "The file you are trying to attach is 2505
kilobytes (KB) in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Bug ID: 109556
Summary: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1927
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #3 from Andrew Pinski ---
(In reply to niXman from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Note branchless might be worse.
>
> really?
> could you explain please?
Yes cache misses. That is the second load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #2 from niXman ---
(In reply to Andrew Pinski from comment #1)
> Note branchless might be worse.
really?
could you explain please?
> Anyways there is a duplicate of this bug
> already. I think I filed it.
thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #1 from Andrew Pinski ---
Note branchless might be worse. Anyways there is a duplicate of this bug
already. I think I filed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
Bug ID: 109555
Summary: suboptimal code for comparing strings with string
literals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> Btw, is there an API to std::move the (possibly) allocated string out of
> the std::string and make it available as C string pointer?
No, ownership always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
--- Comment #2 from Xi Ruoyao ---
And it's clearly documented in https://gcc.gnu.org/gcc-8/changes.html:
Flowing off the end of a non-void function is considered unreachable and may be
subject to optimization on that basis. As a result of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
--- Comment #7 from Richard Biener ---
Heuristic to not unroll loops with prefetches is missing. The aprefetch pass
could set ->unroll to 1 in the loop structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a243ce2a52a6c62bc0d6be0b756a85dd9c1bceb7
commit r14-71-ga243ce2a52a6c62bc0d6be0b756a85dd9c1bceb7
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109554
Bug ID: 109554
Summary: Compiler generates incorrect code when the function
declared with returned parameterm but no 'return' in
its body
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109553
Bug ID: 109553
Summary: Atomic operations vs const locations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
--enable-languages=fortran,c,c++
--enable-checking=all --disable-multilib --disable-bootstrap" and the version
is
"gcc version 14.0.0 20230419 (experimental) (GCC)".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
--- Comment #2 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:6d7e0bcfa49e4ddc84dabe520bba8a023bc52692
commit r14-70-g6d7e0bcfa49e4ddc84dabe520bba8a023bc52692
Author: Xi Ruoyao
Date: Wed Apr 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Richard Biener changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815
Martin Liška changed:
What|Removed |Added
Summary|[10/11/12/13/14 Regression] |[10/11 Regression] Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237
--- Comment #15 from Richard Biener ---
Spread pretty evenly now. Everything >= 5%
tree CFG cleanup : 5.25 ( 8%) 0.00 ( 0%) 5.27 ( 7%)
89k ( 0%)
expand : 3.22 ( 5%) 0.18 ( 2%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103366
Paul Thomas changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ade0a1ee5c6707b950ba284adcfed0514866c12d
commit r14-65-gade0a1ee5c6707b950ba284adcfed0514866c12d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:76f44fbfea1f11e53d4b7e83f0debd029c94a1b3
commit r14-64-g76f44fbfea1f11e53d4b7e83f0debd029c94a1b3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815
--- Comment #4 from Paul Thomas ---
Hi Martin,
This is fixed in 12-branch onwards.
I have not been able to find the fix - could you find it, please? I tried
comparing the diff in comment #2 with the current head but the differences in
the
1 - 100 of 118 matches
Mail list logo
