https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
--- Comment #6 from Andrew Pinski ---
I actually just ran into a problem caused by having this check here.
I was modifying tree-ssa-ifcombine to optimize the case where we have the same
condition on both bb from a bb like:
```
int g();
int h();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #8 from john.harper at vuw dot ac.nz ---
I couldn't see the program teste0es0en0.f90 that is in your bugzilla but
I could see that it does have 691 bytes. So does one of the two versions
that I now have in my own computer. The
(หากคุณกำลังมองหาเงินทุนหมุนเวียนระยะสั้น)
สำหรับผู้ประกอบการ โรงงานฯ หจก. บริษัท ธุรกิจ SME
อนุมัติง่ายกว่าธนาคาร | ไม่เช็คบูโร | ลดต้น ลดดอกเบี้ย | ไม่ต้องมีคนค้ำ |
อนุมัติทันที หลังส่งเอกสารครบถ้วน 1 ช.ม
หากคุณสนใจบริการของเรา โทรด่วนหาเรา
โทร 082 5928519 คุณเอก
โทร 063 2543219 ตะวัน
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Jerry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60
Bug ID: 60
Summary: ICE on assigning volatile through ternary operator
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #5 from Paul Eggert ---
(In reply to Alexander Monakov from comment #4)
> To evaluate scheduling aspect, keep 'mov eax, 1' while changing 'add rbx,
> rax' to 'add rbx, 1'.
Adding the (unnecessary) 'mov eax, 1' doesn't affect the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Andrew Pinski changed:
What|Removed |Added
Known to work||2.95.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed|2023-08-08 00:00:00 |2023-08-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #2 from Andrew Pinski ---
So I think this is because ethread can understand `(a & b)!=0` but not
`(a*c)!=0` that is a*c != 0 means that a or c will both be non-zero (especially
since a*c is known to not to overflow as c as a range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> One thing I noticed (I don't know if causes the missed optimization) is that
> we have before PRE:
> ```
>[local count: 1073531371]:
> if (a.0_1 != 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
--- Comment #3 from Andrew Pinski ---
One thing I noticed (I don't know if causes the missed optimization) is that we
have before PRE:
```
[local count: 1073531371]:
if (a.0_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
--- Comment #2 from Andrew Pinski ---
Looks to be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59
Bug ID: 59
Summary: [13 Regression] False positive -Wdangling-reference
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #54 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.
Wildly speculating, it would be this commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #53 from Jürgen Reuter ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102409
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483
--- Comment #3 from Marek Polacek ---
The error comes from verify_constant, which doesn't explain anything.
verify_constant uses reduced_constant_expression_p which just says yes/no but
doesn't explain anything. reduced_constant_expression_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
--- Comment #2 from Vineet Gupta ---
Test case to help drive some of this:
unsigned long long f5(unsigned long long i)
{
return i * 0x0202020202020202ULL;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #3 from Martin Jambor ---
Simple C testcase:
-- pr57_0.c --
/* { dg-lto-do run } */
/* { dg-lto-options { { -O2 -flto=auto } } } */
/* { dg-extra-ld-options { -flto-partition=1to1 } } */
extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58
Bug ID: 58
Summary: diagnostics, colors, and std::same_as
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111013
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d9a0d692ffc6951c5670f54c3f4f17ec64a58600
commit r14-3486-gd9a0d692ffc6951c5670f54c3f4f17ec64a58600
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
Askar Safin changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #9 from Thomas Koenig ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Thomas Koenig from comment #7)
> > Would it make sense to document this somewhere? Or did I just miss it? :-)
>
> Possibly, but I've no idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #3 from David Binderman ---
Reduced C code seems to be:
struct median_estimator {
long median;
long step
} median_diff_ts[];
median_estimator_update_data, median_estimator_update_diff,
median_estimator_update_median,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
--- Comment #2 from David Binderman ---
The bug first seems to appear sometime between g:93f803d53b5ccaab
and g:68f7cb6cf9e8b9f2, some 39 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
--- Comment #14 from David Binderman ---
Sorry wrong bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #1 from Martin Jambor ---
interestingly, the issue goes away with -flto-partition=one
It is triggered by propagating 0 as the last parameter of point.constprop.isra
which however looks correct, all four calls to the function (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:6df8dcec7196e42ca2eed69e1ae455bae8d0fe93
commit r14-3485-g6df8dcec7196e42ca2eed69e1ae455bae8d0fe93
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 35095, which changed state.
Bug 35095 Summary: DATA with implied-do: Improve bounds checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:4024ddbe50c2d1cb54c75304c72817d3fc63cdb6
commit r14-3484-g4024ddbe50c2d1cb54c75304c72817d3fc63cdb6
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110341
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Bug ID: 57
Summary: 416.gamess fails with a run-time abort when compiled
with -O2 -flto after r14-3226-gd073e2d75d9ed4
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Bug ID: 56
Summary: [14 Regression] aarch64
aarch64/sve/mask_struct_store_4.c failures
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108310
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559
--- Comment #3 from Robin Dapp ---
I got back to this again today, now that pressure-aware scheduling is the
default. As mentioned before, it helps but doesn't get rid of the spills.
Testing with the "generic ooo" scheduling model it looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34422
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|egallager at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665
--- Comment #6 from Eric Gallager ---
WIP: I stubbed in a start on this in my autotools-tinkering branch a bit:
https://github.com/gcc-mirror/gcc/commit/c2caa289485edb40eddcd240a7fc655cfd7c38ba
(it's got some unrelated parts in it that I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55
Bug ID: 55
Summary: RFE: better diagrams for string operations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:845ee9c7107956845e487cb123fa581d9c70ea1b
commit r14-3480-g845ee9c7107956845e487cb123fa581d9c70ea1b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> I think when overflow wraps we cannot do this transform at all, independent
> on the "sign" of 'c'.
>
> Maybe
>
> @@ -6970,8 +6972,11 @@ extract_muldiv_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #4 from Richard Biener ---
Created attachment 55794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55794=edit
fold "dumping"
This adds DUMP_FOLD, but I get
/home/rguenther/src/trunk/gcc/fold-const.cc:6808:22: warning: ISO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Richard Biener changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54
Richard Biener changed:
What|Removed |Added
Blocks||88443
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973
--- Comment #4 from Filip Kastl ---
(In reply to Martin Jambor from comment #3)
> There was also a 7.7% regression on zen3 with generic march (these
> measurements are without LTO):
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Charles Blake changed:
What|Removed |Added
CC||charlechaud at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54
--- Comment #1 from Tomas Chang ---
Forgot to mention, this bug can only be produced in 'AARCH64' platform.
Native compile the attached test case in "aarch64" machine,
or cross-compile the source code using aarch64 toolchain, can trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #15 from waffl3x ---
Created attachment 55793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55793=edit
inital support for P0847 explicit-object-parameter
Alright, I finalized something that I hope is worthy of criticism. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54
Bug ID: 54
Summary: vect-cost-model=dynamic triggers false warning on
array operation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
--- Comment #1 from Robin Dapp ---
We seem to decide that a slightly more expensive loop (one instruction more)
without an epilogue is better than a loop with an epilogue. This looks
intentional in the vectorizer cost estimation and is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53
Bug ID: 53
Summary: RISC-V: Incorrect Vector cost model for reduction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110345
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a739bac402ea5a583e43dbd01c14ebaff317c885
commit r14-3477-ga739bac402ea5a583e43dbd01c14ebaff317c885
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064
Filip Kastl changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52
--- Comment #3 from Filip Kastl ---
Ah, sorry. Didn't notice I'm making a duplicate.
The Zen3 regression isn't that big and could just be noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Richard Biener changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52
--- Comment #2 from Hongtao.liu ---
> With Zen3 -O2 generic lto pgo the regression is less noticeable (only 4%)
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=694.457.0
Not sure about this part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28
Richard Biener changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52
Bug ID: 52
Summary: ~7-9% performance regression on 510.parest_r SPEC 2017
benchmark
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #4 from Robin Dapp ---
All gather-scatter tests pass for me again (the given example in particular)
after applying this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108271
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #3 from Richard Biener ---
A similar aarch64 ICE is fixed with the following:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index ebee8037e02..23c6e8259e7 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection, wrong-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-08-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Bug ID: 51
Summary: [12/13/14 Regression] Wrong code at -O0 on
x86_64-pc-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30
--- Comment #2 from David Binderman ---
(In reply to Richard Biener from comment #1)
> duplicate of PR28?
Yes. Fixed in this morning's compiler, that has your fix for that
bug in it.
Also, the git range I specified contains the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50
Bug ID: 50
Summary: (vec CMP vec) != (vec CMP vec) should just produce
(vec CMP vec) ^ (vec CMP vec)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064
--- Comment #4 from Hongtao.liu ---
The loop is like
doublefoo (double* a, unsigned* b, double* c, int n)
{
double sum = 0;
for (int i = 0; i != n; i++)
{
sum += a[i] * c[b[i]];
}
return sum;
}
After
96 matches
Mail list logo
