https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119145
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7950d4cceb9fc7559b1343c95fc651cefbe287a0
commit r15-7883-g7950d4cceb9fc7559b1343c95fc651cefbe287a0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119145
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[13/14/15 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118068
--- Comment #8 from Jakub Jelinek ---
Created attachment 60675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60675&action=edit
gcc15-pr118068.patch
Better version of the patch, this one doesn't cause any
GXX_TESTSUITE_STDS=98,11,14,17,20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Jakub Jelinek changed:
What|Removed |Added
Target||2019-11-08 0:00
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #23 from GCC Commits ---
The releases/gcc-12 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:149b38a44d041d3b4142f50a9b2d6e1190df3b11
commit r12-10980-g149b38a44d041d3b4142f50a9b2d6e1190df3b11
Author: Christophe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
--- Comment #5 from Filip Kastl ---
I measured (-O2 -march=native -flto on an AMD Zen3 machine)
r15-7400-gd3ff498c478ace and r15-7852-ge836d80374aa03 and there is an 11%
speedup which means we're back to the execution time before
r15-7400-gd3ff4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
--- Comment #6 from Sam James ---
Note that the patch got reverted (PR119142) but should be reapplied later today
with some tweaks from H.J. That may affect your benchmarking depending on when
you run it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #7 from Li Pan ---
Yes, double checked, the result of tree.optimized looks right, details as
below.
Then should be a backend issue now.
will take a look into it.
206 │[local count: 56478818]:
207 │ _114 = MEM[(short int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
--- Comment #4 from Jakub Jelinek ---
(In reply to Michael Leuchtenburg from comment #2)
> Created attachment 60672 [details]
> fixed patch
The formatting is wrong.
The GNU Coding Conventions want
if (iter->entry_count == max_fanout_inner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119141
--- Comment #6 from Jonathan Wakely ---
There's an open issue about that wording, because it's not clear what it's
supposed to mean: https://cplusplus.github.io/LWG/issue3090
It's impossible to constrain the constructor so that it won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #9 from Robin Dapp ---
I suspect the problem lies somewhere here:
_11 = .VEC_EXTRACT (mask__83.22_110, 0);
_23 = MEM[(short int *)&t + 20B];
_24 = _23 & _132;
_25 = _24 != 0;
_121 = () _25;
_157 = _11 ^ _121;
For
_121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119141
--- Comment #7 from Jonathan Wakely ---
And the note you quoted is about "implicit truncation" to a lower resolution
duration i.e. preventing milliseconds being implicitly converted to seconds,
which would lose precision.
It has nothing to do w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119141
--- Comment #8 from Nikl Kelbon ---
I saw example, yes, its unclear what standard means here. May be this lines was
written with something interesting in mind, such as 'duration is not just
integer under templates', instead may be some overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #12 from Li Pan ---
(In reply to Robin Dapp from comment #9)
> I suspect the problem lies somewhere here:
>
> _11 = .VEC_EXTRACT (mask__83.22_110, 0);
> _23 = MEM[(short int *)&t + 20B];
> _24 = _23 & _132;
> _25 = _24 != 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119162
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118339
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118339
Andrew Pinski changed:
What|Removed |Added
CC||Alfie.Richards at arm dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119161
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117477
--- Comment #9 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:b191e8bdecf881d11c1544c441e38f4c18392a15
commit r15-7895-gb191e8bdecf881d11c1544c441e38f4c18392a15
Author: Richard Sandiford
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #29 from Alejandro Colomar ---
Hi Kees,
(In reply to GCC Commits from comment #28)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:622968990beee7499e951590258363545b4a3b57
I guess I should have re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #1 from Vineet Gupta ---
The RISC-V mode switching state machine tracks transitions into call insn and
out of call insn, going from MODE_DYN to MODE_CALL and back to MODE_DYN.
However when the call happens to be last insn of BB (not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
--- Comment #4 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:f0ff7539626e25341c1b450b537e69f86e0bd1f6
commit r15-7904-gf0ff7539626e25341c1b450b537e69f86e0bd1f6
Author: Sandra Loosemore
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117467
--- Comment #16 from Jeffrey A. Law ---
OK. Funny I'd just been looking at this problem in a different context.
When an RTX is encountered when handling uses that the code does not know how
to handle it will, in effect, continue normal iterati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #17 from Robin Dapp ---
> No you got it wrong.
> _121 will either be -1 or 0. _11 should be -1 or 0 too.
> So the question is what was the VEC_EXTRACT doing the right thing? Is it
> 0/-1 or 0/1?
I literally mentioned VEC_EXTRACT in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #21 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:7deb498425799aceb7659ea25614175a49533184
commit r15-7891-g7deb498425799aceb7659ea25614175a49533184
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117512
--- Comment #7 from Marek Polacek ---
I think the problem is that we create something like
d = MEM [(struct A *)&TARGET_EXPR [(struct A *)(const struct A &) &e], TARGET_EXPR
in build_over_call:
t = build2 (MODIFY_EXPR, void_type_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119165
Bug ID: 119165
Summary: Missing use of movk
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
-20250307135039-r15-7886-g2427793af1e545-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250307 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119156
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
--- Comment #2 from Tomasz Kamiński ---
The issue is caused by the fact that we do not check `move_constructible &&
regular_invocable` (required by [range.zip.transform] p2.1.1) for
`sizeof...(_Ts) == 0` case.
```
struct _ZipTransform
{
templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
--- Comment #3 from Richard Biener ---
There's also the issue that
inline unsigned int
vect_known_alignment_in_bytes (dr_vec_info *dr_info, tree vectype,
poly_int64 offset = 0)
{
int misalignment = dr_misalig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:e8651b80aeb86da935035e218747a6b41b611497
commit r15-7881-ge8651b80aeb86da935035e218747a6b41b611497
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
--- Comment #4 from Richard Biener ---
OK, so the BB vect case (or contiguous loop) ends up with doing
align = known_alignment (DR_TARGET_ALIGNMENT (first_dr_info));
if (alignment_support_scheme == dr_aligned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
Bug ID: 119157
Summary: ice in gfc_enforce_clean_symbol_state, at
fortran/symbol.cc:4459
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
Tomasz Kamiński changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100553
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #21 from GCC Commits ---
The releases/gcc-14 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:1c99a8f255ae7a68e477b7653df7a8dcf936cbeb
commit r14-11391-g1c99a8f255ae7a68e477b7653df7a8dcf936cbeb
Author: Christophe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
--- Comment #9 from rguenther at suse dot de ---
On Fri, 7 Mar 2025, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
>
> --- Comment #8 from David Binderman ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119156
Bug ID: 119156
Summary: Placement of PTRUE instructions prevents PTEST
elimination
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #20 from GCC Commits ---
The trunk branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:b1d0ac28de643e7c810e407a0668737131cdcc00
commit r15-7882-gb1d0ac28de643e7c810e407a0668737131cdcc00
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #4 from Robin Dapp ---
Very weird indeed. It looks like we're not even vectorizing? I mean, sure, we
use vector instructions but they are all broadcast from scalars?
(VMAT_INVARIANT) And in the end we extract the first element wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:5ae621e2e86c00d1fb13ef6839d0c3bace762ac8
commit r15-7880-g5ae621e2e86c00d1fb13ef6839d0c3bace762ac8
Author: Richard Sandiford
Da
15-7886-g2427793af1e545-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250307 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #22 from GCC Commits ---
The releases/gcc-13 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:8b79adbb92f80cecf447e4ec75d6c6e7ca62ac1e
commit r13-9417-g8b79adbb92f80cecf447e4ec75d6c6e7ca62ac1e
Author: Christophe L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119150
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119150
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119110
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #10 from Robin Dapp ---
The test passes with -fno-vrp, so maybe the optimized tree isn't correct after
all?
Folding statement: _157 = _26 ? -1 : 0;
Matching expression match.pd:161, gimple-match-10.cc:33
Matching expression match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119160
--- Comment #1 from Jakub Jelinek ---
Miscompilation started with r15-6464-gc86e1c54c6f8771d08a8c070717b80607f990f8a
Not sure if we can consider it a regression though, as the
-favoid-store-forwarding
option has only been added in
r15-5640-g1d8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119160
--- Comment #3 from Sam James ---
(That's why I removed the blocker.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119160
--- Comment #4 from Sam James ---
(In reply to Jakub Jelinek from comment #1)
It'll arguably be a 16 regression as the plan is to enable it by default for
some targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119160
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117029
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:aa247ea8c3e443a6d60f382e2db2ef5c0069f879
commit r15-7888-gaa247ea8c3e443a6d60f382e2db2ef5c0069f879
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:aa247ea8c3e443a6d60f382e2db2ef5c0069f879
commit r15-7888-gaa247ea8c3e443a6d60f382e2db2ef5c0069f879
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119161
Bug ID: 119161
Summary: ICE for declaration with target_clones containing
unknown version string
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #6 from Robin Dapp ---
As convoluted (and redundant) as it looks but the optimized tree looks at least
correct to me. Maybe a backend issue?
But I don't see costing for what we emit in the vectorizer and I didn't yet
find where we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
--- Comment #5 from Richard Biener ---
Created attachment 60676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60676&action=edit
patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
--- Comment #8 from Sam James ---
Yes, but if their benchmarking LNS or whatever runs today before the
reapplication, it won't see an improvement (not that H.J.'s fixes change
performance).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464
--- Comment #16 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:9798ba2c6b4cccb17277a9d5fc04d285bf48f742
commit r15-7884-g9798ba2c6b4cccb17277a9d5fc04d285bf48f742
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
--- Comment #2 from Sam James ---
I seem to be able. It needs default _FORTIFY_SOURCE. Those won't appear with
-O0 vs -O1 which may explain the crash, dunno.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #10 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:9798ba2c6b4cccb17277a9d5fc04d285bf48f742
commit r15-7884-g9798ba2c6b4cccb17277a9d5fc04d285bf48f742
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100553
--- Comment #2 from Luke Dalessandro ---
This still fails in 14.2 but looks like it's been resolved in trunk (15?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117029
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119134
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
--- Comment #7 from Sam James ---
(In reply to Igor Machado Coelho from comment #6)
> I just discovered, and came here to complement this issue, that I found a
> very similar situation with -U_FORTIFY_SOURCE.
>
Just to state it explicitly in c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
--- Comment #6 from Igor Machado Coelho ---
I just discovered, and came here to complement this issue, that I found a very
similar situation with -U_FORTIFY_SOURCE.
When I built without -U_FORTIFY_SOURCE, like:
g++-15 -std=c++23 -O3 -fmodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119159
Bug ID: 119159
Summary: [15 Regression] 6% slowdown of 520.omnetpp_r on
aarch64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119159
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
Tomasz Kamiński changed:
What|Removed |Added
Last reconfirmed||2025-03-07
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15 Regression] ICE: |[14 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
Jakub Jelinek changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464
--- Comment #17 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:2427793af1e545506e0315f8ec06adf73d76b3cc
commit r15-7886-g2427793af1e545506e0315f8ec06adf73d76b3cc
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #11 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:2427793af1e545506e0315f8ec06adf73d76b3cc
commit r15-7886-g2427793af1e545506e0315f8ec06adf73d76b3cc
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #8 from Li Pan ---
252 │ vect__81.20_52 = vect_cst__142 & _164; // {3}
253 │ mask__82.21_53 = vect__81.20_52 != { 0, 0, 0, 0, 0, 0, 0, 0 };//
0xff
254 │ _31 = mask__82.21_53 ^ mask__57.18_81; // 0xff
255 │ mask__8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
Tamar Christina changed:
What|Removed |Added
Summary|[14/15 Regression] Unsafe |[14 Regression] Unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
--- Comment #9 from Filip Kastl ---
Ah, I see. Thanks, I'll make a mental note of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
--- Comment #5 from Jakub Jelinek ---
Though
===pr119154-1.C===
#include "pr119154-1.h"
import foo;
int main(){return 0;}
===pr119154-1.h===
extern "C" {
extern wchar_t *wmemset (wchar_t *__s, wchar_t __c, __SIZE_TYPE__ __n) noexcept
(true);
#if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #5 from Li Pan ---
(In reply to Robin Dapp from comment #4)
> Very weird indeed. It looks like we're not even vectorizing? I mean, sure,
> we use vector instructions but they are all broadcast from scalars?
> (VMAT_INVARIANT) And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119158
Bug ID: 119158
Summary: Using __attribute__((cold)) results in error:
Assembler messages: Error: can't resolve
.text.unlikely - .L2
Product: gcc
Version: 14.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119154
--- Comment #3 from Jakub Jelinek ---
I really hate these hidden options/tweaks, it is complete nightmare for bug
reporting.
In any case, confirmed, bits/std.cc needs to be compiled with -O3
-D_FORTIFY_SOURCE (or =2 or =3), the #c0 main.cpp can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
--- Comment #6 from Filip Kastl ---
I've measured this again. I used -O2 -march=generic -flto PGO on an AMD Zen4
machine.
Between
r15-7400-gd3ff498c478ace
r15-7852-ge836d80374aa03
the slowdown disappears. So, as with pr118959, I think the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #19 from rguenther at suse dot de ---
On Thu, 6 Mar 2025, vvinayag at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
>
> vvinayag at arm dot com changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #6 from Richard Biener ---
(In reply to Richard Sandiford from comment #5)
> (In reply to Richard Biener from comment #3)
> > We document
> >
> > class dr_with_seg_len
> > {
> > ...
> > /* The minimum common alignment of DR's st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
Bug ID: 119155
Summary: Aligned vector element accesses emitted for packed
struct access
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #7 from Richard Biener ---
PR119155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e1c49f413c8c892a61612b3b89de0607ff7ba893
commit r15-7878-ge1c49f413c8c892a61612b3b89de0607ff7ba893
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104277
Bug 104277 depends on bug 118801, which changed state.
Bug 118801 Summary: Excessive compile time with -g -O2 -fpeel-loops
-fno-var-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
What|Removed |Ad
1 - 100 of 150 matches
Mail list logo
