https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Wilco changed:
What|Removed |Added
Target||aarch64-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Bug ID: 114991
Summary: [14/15 Regression] AArch64: LDP pass does not handle
some structure copies
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Wilco changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Bug ID: 114890
Summary: [14/15 Regression] Big-endian addp intrinsics reorder
operands
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #17 from Wilco ---
(In reply to Andrew Pinski from comment #16)
> Patch posted with all of the testcases included:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650080.html
Not nearly enough testcases... What about:
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #13 from Wilco ---
(In reply to Andrew Pinski from comment #11)
> I have a fix for aarch64, able to produce now:
> ```
> f:
> .LFB0:
> .cfi_startproc
> stp x0, x1, [sp, -32]!
> .cfi_def_cfa_offset 32
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #7 from Wilco ---
(In reply to Tamar Christina from comment #6)
> and the exact armv9-a cost model you quoted, also does the right codegen.
> https://godbolt.org/z/obafoT6cj
>
> There is just an inexplicable penalty being applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #2 from Wilco ---
It looks like the underlying bug is '^' being incorrectly treated like '?' in
record_reg_classes (which is never used during reload). Fixing that results in
the expected code being generated in all cases. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #8 from Wilco ---
(In reply to Sainan from comment #7)
> (In reply to Wilco from comment #6)
> > That does not make any sense. The only thing I think might happen is that
> > your structure is not correctly aligned (for example by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #6 from Wilco ---
(In reply to Sainan from comment #5)
> (In reply to Wilco from comment #4)
> > The atomic will also set correct struct alignment.
>
> My thinking was that maybe this is not the case (= standard library issue)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #4 from Wilco ---
(In reply to Sainan from comment #3)
> I seem to be having a related issue, although in my case the struct looks
> like this:
>
> template
> struct Data
> {
> T* data;
> std::atomic_uint count;
> bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #31 from Wilco ---
(In reply to Andrew Pinski from comment #29)
> Looking back at this one, I (In reply to Wilco from comment #8)
> > Here is a much simpler example:
> >
> > void f (int *p, int y)
> > {
> > int a = y & 14;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
--- Comment #4 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #13 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646189.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Wilco changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
--- Comment #3 from Wilco ---
(In reply to Richard Biener from comment #2)
> It might be good to recognize this pattern in strlenopt or a related pass.
>
> A purely local transform would turn it into
>
> memcpy (temp, a, 64);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Bug ID: 113618
Summary: [14 Regression] AArch64: memmove idiom regression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #16 from Wilco ---
Fixed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112573
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-11-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693
--- Comment #6 from Wilco ---
Thanks Jakub - with the 2nd patch we get the expected sequence on AArch64:
sub x1, x0, #1
eor x0, x0, x1
cmp x0, x1
csetx0, hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112465
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Wilco changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
Wilco changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #24 from Wilco ---
Patch to avoid emitting unaligned LDP/STP with -mstrict-align:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631022.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-09-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
--- Comment #3 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630358.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404
Bug ID: 111404
Summary: [AArch64] 128-bit __sync_val_compare_and_swap is not
atomic
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95751
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
Wilco changed:
What|Removed |Added
Target Milestone|--- |14.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-08-23
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
Bug ID: 21
Summary: AArch64: MOPS memmove operand corruption
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #17 from Wilco ---
(In reply to Mark Brown from comment #13)
> The kernel hasn't got any problem with BTI as far as I am aware - when built
> with clang we run the kernel with BTI enabled since clang does just insert a
> BTI C at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110791
Wilco changed:
What|Removed |Added
Ever confirmed|0 |1
Component|rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110791
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #14 from Wilco ---
(In reply to Wilco from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to Wilco from comment #11)
> >
> > > > Then the compiler (and the standard) is not what they consider. Such
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #13 from Wilco ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to Wilco from comment #11)
>
> > > Then the compiler (and the standard) is not what they consider. Such
> > > misunderstandings are everywhere and this has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #11 from Wilco ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Xi Ruoyao from comment #8)
> > > (In reply to Wilco from comment #7)
> > > > I don't see the issue you have here. GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #9 from Wilco ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Wilco from comment #7)
> > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > compare exchange for atomic load (which always does a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-05-31
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Bug ID: 110061
Summary: libatomic: 128-bit atomics should be lock-free on
AArch64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
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=108891
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108891
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108891
Bug ID: 108891
Summary: libatomic: AArch64 SEQ_CST 16-byte load missing
barrier
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #21 from Wilco ---
(In reply to Gabriel Ravier from comment #19)
> If the original code being branchless makes it faster, wouldn't that imply
> that we should use the table-based implementation when generating code for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #17 from Wilco ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Wilco from comment #15)
> > It would make more sense to move x86 backends to CTZ_DEFINED_VALUE_AT_ZERO
> > == 2 so that you always get the same result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #15 from Wilco ---
(In reply to Jakub Jelinek from comment #14)
> The patch does:
> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval)
> == 2;
> +
> + /* Skip if there is no value defined at zero, or if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #11 from Wilco ---
(In reply to Niall Douglas from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > (In reply to Wilco from comment #8)
> > > Yes that sounds like a reasonable approach.
> >
> > I don't think so. Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #8 from Wilco ---
(In reply to Niall Douglas from comment #7)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Niall Douglas from comment #3)
> > > You may be interested in reading https://reviews.llvm.org/D110069. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #21 from Wilco ---
(In reply to Jakub Jelinek from comment #20)
> __attribute__((noinline, optimize ("rounding-math"))) static int
> round_to_nearest (void) { return 1.0f - __FLT_MIN__ == 1.0f + __FLT_MIN__; }
Wouldn't that always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108006
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 107413, which changed state.
Bug 107413 Summary: Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with
r8-7132-gb5b33e113434be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #15 from Wilco ---
(In reply to Rama Malladi from comment #14)
> This fix also improved performance of 538.imagick_r by 15%. Did you have a
> similar observation? Thank you.
No, but I was using -mcpu=neoverse-n1 as my baseline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
Wilco changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #7 from Wilco ---
(In reply to Rama Malladi from comment #5)
> So, looks like we aren't impacted much with this commit revert.
>
> I haven't yet tried fp_reassoc_width. Will try shortly.
The revert results in about 0.5% loss on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107316
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107316
Bug 107316 depends on bug 106583, which changed state.
Bug 106583 Summary: Suboptimal immediate generation on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106583
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106583
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105773
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106323
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
--- Comment #3 from Wilco ---
(In reply to David Binderman from comment #2)
> (In reply to Wilco from comment #1)
> > iwmmxt has been dead for 2 decades now - it's support has most likely
> > bitrotted, so I'm surprised anyone is trying to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #6 from Wilco ---
(In reply to Qing Zhao from comment #4)
> > On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org
> > wrote:
> >
> > Note that GCC could split huge .text sections automatically to allow
> > insertion
> > of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #5 from Wilco ---
(In reply to Jose E. Marchesi from comment #3)
> Wilco: The assessment in comment 1 was extracted from an internal discussion
> on an issue that is still under investigation. We are certainly hitting a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Wilco changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
--- Comment #12 from Wilco ---
(In reply to Jakub Jelinek from comment #11)
> How can changing the constructor priority in libgcc affect anything?
> Constructor priorities are within the same shared library or within the same
> executable, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #49 from Wilco ---
(In reply to d_vampile from comment #48)
> (In reply to Jiu Fu Guo from comment #41)
> > (In reply to Wilco from comment #40)
> > > (In reply to Jiu Fu Guo from comment #39)
> > > > I’m thinking to draft a patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100966
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #17 from Wilco ---
Here is the current medium code model proposal:
https://github.com/ARM-software/abi-aa/pull/107/files
1 - 100 of 111 matches
Mail list logo
