-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=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=67301
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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=119165
Bug ID: 119165
Summary: Missing use of movk
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
--- Comment #5 from Jerry DeLisle ---
Fixed on gcc-15, preparing backport to 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:3014f8787196d7c0d15d24195c8f07167968ff55
commit r15-7903-g3014f8787196d7c0d15d24195c8f07167968ff55
Author: Jerry DeLisle
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #16 from Andrew Pinski ---
;; _302 = .VEC_EXTRACT (mask__87.22_296, 0);
(insn 198 197 199 (set (reg:DI 332)
(unspec:DI [
(const_int 16 [0x10])
] UNSPEC_VLMAX)) -1
(nil))
(insn 199 198 200 (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #15 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> ;; Same for a BImode but still return a QImode.
> (define_expand "vec_extractbi"
> [(set (match_operand:QI 0 "register_operand")
> (vec_select:Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #14 from Andrew Pinski ---
;; Same for a BImode but still return a QImode.
(define_expand "vec_extractbi"
[(set (match_operand:QI 0 "register_operand")
(vec_select:QI
(match_operand:VB_VLS 1 "register_opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66953
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=119164
--- Comment #3 from Vineet Gupta ---
However the first part of prev fix alone can't pass a glibc build - hitting
bunch of ICE.
Following reduced test (w/ my patch applied) actually segfaults
build: -O2 -c -march=rv64gcv_zvl256b_zba_zbb_zbs_zi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117467
--- Comment #15 from Jeffrey A. Law ---
So what's weird here is on that file for riscv64, after removing the memory
based limiter, I see ext-dce at .94s out of 295s of cpu time and I never see a
major memory spike -- I don't ever see it get much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #30 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ab714e60870d1bb98039652b760918b5e680ac10
commit r15-7901-gab714e60870d1bb98039652b760918b5e680ac10
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #2 from Vineet Gupta ---
I tried to address the first issue by changing the helper called to identify
call as end of insn (in the presence of the label) - I hope that is the right
direction.
Anyways per IRC chat, someone suggested f
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=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=117178
--- Comment #28 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:622968990beee7499e951590258363545b4a3b57
commit r15-7900-g622968990beee7499e951590258363545b4a3b57
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
Bug ID: 119164
Summary: RISC-V: Extra FRM read/writes around call insns
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
--- Comment #6 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:313edeeeb607fe32da5633cfb6f91977add446f6
commit r15-7899-g313edeeeb607fe32da5633cfb6f91977add446f6
Author: Sandra Loosemore
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=119114
--- Comment #11 from Robin Dapp ---
/* In GIMPLE, getting rid of 2 conversions for one new results
in smaller IL. */
(simplify
(convert (bitop:cs@2 (nop_convert:s @0) @1))
(if (GIMPLE
&& TREE_CODE (@1) != INTEGER_CST
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
--- Comment #3 from Jerry DeLisle ---
I will do the commit.
On Fri, Mar 7, 2025, 12:57 PM anlauf at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
>
> --- Comment #2 from anlau
I will do the commit.
On Fri, Mar 7, 2025, 12:57 PM anlauf at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #1)
> > Thanks for PR and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119163
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-03-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119141
--- Comment #9 from Jonathan Wakely ---
No, that's absolutely not what it means.
The original author of that wording and the reference implementation of chrono
is quoted saying what it means at https://cplusplus.github.io/LWG/issue3090
"This r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119163
Bug ID: 119163
Summary: std::equal cannot be used with debug mode iterators in
constant expressions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
--- Comment #5 from Michael Leuchtenburg ---
Some additional eyes on the algorithm change would be quite welcome. I think
I've missed something as I'm still getting some similar crashes, albeit at a
lower rate. The tree structure has the same fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #1)
> Thanks for PR and a patch submitted here:
>
> https://gcc.gnu.org/pipermail/fortran/2025-February/061793.html
>
> In review.
LGTM. I had to manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 118318, which changed state.
Bug 118318 Summary: [15 regression] ICE when building firefox-134.0 with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known
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=119154
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #8
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=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=119158
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119118
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
--- Comment #3 from kargls at comcast dot net ---
(In reply to kargls from comment #1)
> Works for me.
>
> What OS?
>
> How was gcc configured?
Whoops, I take that back. I missed that you were using the -Wall option.
f951: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #16 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cf65235e03d2eb1667624943eae8f7fc355bceaf
commit r15-7894-gcf65235e03d2eb1667624943eae8f7fc355bceaf
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775
Marek Polacek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:aa55a6a30bc4778938af42dac9b624cf67fa4698
commit r15-7893-gaa55a6a30bc4778938af42dac9b624cf67fa4698
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119162
Bug ID: 119162
Summary: missing error with constexpr new
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116708
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
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=116708
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116708
--- Comment #4 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:c781da2c10641a651019f8fe77f57ccdbc49f024
commit r15-7892-gc781da2c10641a651019f8fe77f57ccdbc49f024
Author: Sandra Loosemore
Dat
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=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=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=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=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 #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=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=100553
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
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=112960
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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=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=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=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
--- Comment #3 from Sam James ---
(That's why I removed the blocker.)
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
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=119159
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
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=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=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=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 #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=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 #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=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=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=118464
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
--- 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=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=119154
Jakub Jelinek changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org,
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=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=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=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=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=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=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.
1 - 100 of 150 matches
Mail list logo
