https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108580
Bug ID: 108580
Summary: gcc treats shifts as signed operation, does wrong
promotion
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579
Bug ID: 108579
Summary: Requires-expression that checks constructor on
non-template constructor of template class got
rejected
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88570
--- Comment #6 from Hongtao.liu ---
1. knot should be cheaper than vector compare to mask register.
2. for test2, we failed to eliminate
vcmppd k1, ymm1, ymm2, 1
which is exactlt the same as
vcmppd k1, ymm2, ymm1, 14
Note: pass_combine f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #13 from Jerry DeLisle ---
(In reply to anlauf from comment #11)
> (In reply to Jerry DeLisle from comment #8)
> > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> > suggest we make all of these P5 or Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
--- Comment #5 from Marek Polacek ---
Candidate fix:
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index be99bec17e7..6718c29b0cd 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -4301,9 +4301,13 @@ cxx_eval_array_referenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
--- Comment #2 from David Malcolm ---
Looking at the reduced reproducer, -fanalyzer is considering the case where
wu->Contexts is initially non-NULL and thus the loop is entered, but it doesn't
know about the insides of Tick64 and thus considers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108574
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #35 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #34)
> Seems right now DECL_NONALIASED is only used on these coverage vars and on
> Fortran caf tokens, so perhaps a quick workaround would be on the LRA side
> ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108557
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108535
--- Comment #2 from Jamie Bainbridge ---
Ah, I've misunderstood how the analyzer works, my apologies.
(In reply to David Malcolm from comment #1)
> It sounds like what you really want is for GCC -fanalyzer to be faster on
> this particular tran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
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=108432
David Malcolm changed:
What|Removed |Added
CC||jamie.bainbridge at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107566
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108578
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108578
Bug ID: 108578
Summary: typedef inside a struct error message should be
improved
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #12 from Thomas Koenig ---
(In reply to anlauf from comment #11)
> (In reply to Jerry DeLisle from comment #8)
> > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> > suggest we make all of these P5 or Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108577
Bug ID: 108577
Summary: [meta-bug] Fortran 2023 support
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
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=108575
--- Comment #4 from Nikos Tosis ---
(In reply to Andrew Pinski from comment #1)
> What is the command line you are using to compile the sources?
>
> Does -fno-strict-aliasing help?
> Does it work at -O0?
I use -mcpu=cortex-m4 -std=gnu11 -g -DD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108574
--- Comment #2 from Zhendong Su ---
Another likely related test case.
Compiler Explorer: https://godbolt.org/z/G514hnMeY
[537] % gcctk -O3 small.c
[538] % timeout -s 9 5 ./a.out
Killed
[539] % gcctk -O1 small.c
[540] % ./a.out
[541] %
[541]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
--- Comment #3 from Nikos Tosis ---
(In reply to Christophe Lyon from comment #2)
> I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the
> 3rd parameter of the function, so you pass &UnitDelay_DSTATE,
> while you pass &Sig_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
ValdikSS changed:
What|Removed |Added
CC||iam at valdikss dot org.ru
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108568
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12596
Sergey Fedorov changed:
What|Removed |Added
CC||vital.had at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104787
Andrew Pinski changed:
What|Removed |Added
CC||sergey at polovko dot me
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108576
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108576
--- Comment #1 from Sergey Polovko ---
Sorry, this line
> * https://godbolt.org/z/8Gq4fjacr (12.3)
should mention GCC 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108576
Bug ID: 108576
Summary: False positive for -Werror=return-type
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108568
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:815e5740162d2d0b7b54031f72c201065016d58c
commit r13-5461-g815e5740162d2d0b7b54031f72c201065016d58c
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #13 from Jakub Jelinek ---
Created attachment 54364
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54364&action=edit
gcc13-pr108463.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108394
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #12 from Jakub Jelinek ---
So, the reason for the -g0 vs. -g differences is that we create while
processing the huge DEBUG_INSN among other things 3 MEMs for
(mem:SI (plus:DI (reg:DI sp) (const_int some_offset)) [1 S4 A256])
(at tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575
Bug ID: 108575
Summary: Bug in gcc arm non eabi
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #11 from Jakub Jelinek ---
Anyway, seems that cselib_invalidate_mem on
(mem/c:V4SI (plus:DI (reg/f:DI 7 sp) (const_int -120 [0xff88])) [1
S16 A128])
invalidates all the entries from first_containing_mem chain, except for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #10 from Steve Kargl ---
On Fri, Jan 27, 2023 at 02:06:12AM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
>
> --- Comment #7 from Jerry DeLisle ---
>
> Well we sure are not going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #33 from Jakub Jelinek ---
It is the default unless -pthread is specified:
%{fprofile-arcs|fprofile-generate*|coverage:\
%{!fprofile-update=single:\
%{pthread:-fprofile-update=prefer-atomic}}}
So, when one uses -fprofile-arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #32 from Linus Torvalds ---
Brw, where does the -fprofile-update=single/atomic come from?
The kernel just uses
CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage
for this case. So I guess 'single' is just the default value?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108574
--- Comment #1 from Zhendong Su ---
Here is another reproducer likely for the same bug.
Compiler Explorer: https://godbolt.org/z/Efvczc6f8
[556] % gcctk -O3 small.c
[557] % ./a.out
Floating point exception
[558] %
[558] % cat small.c
int a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #31 from Linus Torvalds ---
(In reply to Richard Biener from comment #26)
>
> Now, in principle we should have applied store-motion and not only PRE which
> would have avoided the issue, not tricking the RA into reloading the value
--enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230127 (experimental) [master r12-4647-g3f861a5c8fd] (GCC)
[579] %
[579] % gcctk -O3 small.c
[580] % ./a.out
Floating point exception
[581] %
[581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #14 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:7486fe153adaa868f36248b72f3e78d18b1b3ba1
commit r13-5458-g7486fe153adaa868f36248b72f3e78d18b1b3ba1
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Andrew Pinski changed:
What|Removed |Added
CC||fsb4000 at yandex dot ru
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108570
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #30 from Linus Torvalds ---
(In reply to Richard Biener from comment #26)
> And yes, to IV optimization the gcov counter for the loop body is just
> another IV candidate that can be used, and in this case it allows to elide
> the oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #10 from Jakub Jelinek ---
I've put a watchpoint on n_useless_values and it seems it first diverges
(assuming it should be the same between -g and -g0) when processing the
(insn:TI 1074 1073 1087 2 (set (mem/c:V4SI (plus:DI (reg/f:DI
-trunk-r13-5455-20230127153300-gdef6e12e348-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230127 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #16 from Andrew Macleod ---
(In reply to Richard Biener from comment #15)
> In GCC 13.
Whups. Didn't even notice that. Same patch ok for GCC12 once testing
completes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108557
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #10 from qinzhao at gcc dot gnu.org ---
shall we support the following multi-level nesting?
struct A { int len; char data[]; };
struct B { int n; struct A a; };
struct C { int m, struct B b; };
struct C *outer;
__builtin_object_siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108554
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3adf6dd508491d26e21840a8a70b016f876edd53
commit r13-5454-g3adf6dd508491d26e21840a8a70b016f876edd53
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #29 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #27)
> Well, we could in -fprofile-update=single (or perhaps in a new single-like
> mode) mark the gcov artificial vars volatile or with some flag that would at
> lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #28 from Richard Biener ---
(In reply to Jakub Jelinek from comment #27)
> (In reply to Richard Biener from comment #25)
> > Ah, reading more comments, no - it probably doesn't. Jakub correctly says
> > that there seems to be a data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108306, which changed state.
Bug 108306 Summary: [12 Regression] false-positive -Warray-bounds warning
emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #27 from Jakub Jelinek ---
(In reply to Richard Biener from comment #25)
> Ah, reading more comments, no - it probably doesn't. Jakub correctly says
> that there seems to be a data race necessary to trigger this, so it doesn't
> see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #26 from Richard Biener ---
And yes, to IV optimization the gcov counter for the loop body is just another
IV candidate that can be used, and in this case it allows to elide the
otherwise
unused original IV.
Now, in principle we sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #25 from Richard Biener ---
(In reply to Richard Biener from comment #24)
> Does
>
> diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
> index 0dd47910f97..f780c0ce08c 100644
> --- a/gcc/tree-ssa-loop-ivopts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #24 from Richard Biener ---
Does
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 0dd47910f97..f780c0ce08c 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -2241,7 +2241,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #43 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6cdb4d4bcd52c95cb6d367b93a82eb599d4e26f0
commit r13-5452-g6cdb4d4bcd52c95cb6d367b93a82eb599d4e26f0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #44 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b799acef461bcb78d77819dd27c8e4806177d841
commit r13-5453-gb799acef461bcb78d77819dd27c8e4806177d841
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #42 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:ed0a765ef9b7be420fc4cf6e653fc7350f84981c
commit r13-5451-ged0a765ef9b7be420fc4cf6e653fc7350f84981c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #41 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:31949fba1222692548b501e4dfa4ddcf7b7fc7c6
commit r13-5450-g31949fba1222692548b501e4dfa4ddcf7b7fc7c6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108306, which changed state.
Bug 108306 Summary: [12/13 Regression] false-positive -Warray-bounds warning
emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #13 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:f884c133dde519b4d8fc89f2f151711d1b0eb368
commit r13-5449-gf884c133dde519b4d8fc89f2f151711d1b0eb368
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #26 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:ec5e99e95954fd629283a9c9572193dd95471fea
commit r13-5448-gec5e99e95954fd629283a9c9572193dd95471fea
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #23 from Jakub Jelinek ---
We could mark the __gcov* artificial vars with some flag (unless they are
already) and try to avoid using IVs loaded from those in IVOPTs, but as can be
seen above, the chosen IV really isn't that memory bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Bug ID: 108572
Summary: -gz=none produces gcc: error: -gz=zstd is not
supported in this configuration
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #22 from Uroš Bizjak ---
BTW: It is the reload pass that duplicates read from
__gcov0.prep_compound_page[7].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #20 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #19)
> __gcov0.prep_compound_page. But as shown in Comment #15, we have two
Comment #16, actually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #19 from Uroš Bizjak ---
Some further analysis:
pretmp_94 = __gcov0.prep_compound_page[7]; <--
_179 = pretmp_94 + 1; <--
ivtmp.1725_211 = (unsigned long long) _179;
_135 = (unsigned int) nr_pages_11;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108561
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Uroš Bizjak changed:
What|Removed |Added
Component|target |tree-optimization
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #17 from Uroš Bizjak ---
The assembly is just mirroring what tree optimizers prepare:
pretmp_94 = __gcov0.prep_compound_page[7];
_179 = pretmp_94 + 1;
ivtmp.1725_211 = (unsigned long long) _179;
...
[local count: 95563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #16 from Uroš Bizjak ---
addl$1, __gcov0.prep_compound_page+48
adcl$0, __gcov0.prep_compound_page+52
cmpl$1, %ebx
jle .L1470
leal1(%edi), %eax
movl__gcov0.prep_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987
--- Comment #2 from CVS Commits ---
The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:27b6fb155dfefae8dc6ac8d8264851f104dff4e4
commit r12-9073-g27b6fb155dfefae8dc6ac8d8264851f104dff4e4
Author: Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #9 from Jakub Jelinek ---
Note, we already distinguish between n_useless_values and
n_useless_debug_values:
if (had_locs && cselib_useless_value_p (v))
{
if (setting_insn && DEBUG_INSN_P (setting_insn))
n_useless_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #8 from Jakub Jelinek ---
Ah, the difference is that in the -g0 case, value 3:3946 has 2 locs still at
the true_dependence spot of 1204 vs. 1116 instructions, one (reg/f:DI 7 sp)
like
in the -g case, but also
(plus:DI (value/c:DI 2:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #50 from rguenther at suse dot de ---
On Fri, 27 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
>
> --- Comment #49 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #7 from Jakub Jelinek ---
So, on the first difference without -g the 2 memories are
(gdb) p pending_mem->element ()
$1 = (mem/c:V4SI (plus:DI (value/c:DI 2:2 @0x39559d8/0x39359d0)
(const_int -472 [0xfe28])) [1 S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> I suspect 'operator new' is not returns_nonnull for the variant that isn't
> noexcept. That would be my first stab at improving things. Not sure
> what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85364
Thomas Schwinge changed:
What|Removed |Added
Keywords||openacc
Last reconfirmed|2018-04-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #15 from Uroš Bizjak ---
Sorry, %esi/%edi is the correct order.
-24(%ebp): some value previously saved to stack frame
%ecx: address to write to
%eax/%edx: loop iterator
%esi/%edi: termination value
.L1469:
movl%eax, __g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108558
--- Comment #4 from Tobias Burnus ---
Fixed on mainline (GCC 13); still need to backport to GCC 12 as the original
feature was added in r12-7161-gbbb7f8604e1dfc08f44354cfd93d2287f2fdd489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #14 from Uroš Bizjak ---
The loop is actually pretty simple, please see the interpretation below
-24(%ebp): some value previously saved to stack frame
%ecx: address to write to
%eax/%edx: loop iterator
%edi/%esi: termination value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108571
Bug ID: 108571
Summary: Fix for PR96373 regresses fabd_1.c with
-ftrapping-math
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108565
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 122 matches
Mail list logo
