https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #9 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118351
Wilco changed:
What|Removed |Added
Last reconfirmed||2025-01-10
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117675
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117675
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=117292
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117292
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=110061
Wilco changed:
What|Removed |Added
Target Milestone|14.3|13.4
--- Comment #21 from Wilco ---
Fixed on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #12 from Wilco ---
This came out of the AArch64 Atomic ABI design work:
https://github.com/ARM-software/abi-aa/pull/256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #7 from Wilco ---
(In reply to Andrew Pinski from comment #6)
> https://gitlab.com/x86-psABIs/i386-ABI/-/issues/1 for x86_64 abi.
>
> Aarch64 should most likely also do the same ...
Yes, that's why I raised this - GCC only over ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #5 from Wilco ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > Not sure what the x86 psABI says here (possibly nothing for aggregate
> > _Atomic).
>
> It doesn't consider _Atomic [i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
Bug ID: 115954
Summary: Alignment of _Atomic structs incompatible between GCC
and LLVM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886
Bug 105886 depends on bug 103100, which changed state.
Bug 103100 Summary: [11 Regression] unaligned access generated with memset or
{} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115188
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115342
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115342
Wilco changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Wilco ---
(In rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #7 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115342
Bug ID: 115342
Summary: [14/15 Regression] AArch64: Function multiversioning
initialization incorrect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115188
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115153
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=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: nor
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 g
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 W
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 to
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 t
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 Wi
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 us
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)
> sin
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;
> > *p
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 d
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);
> memmove
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
Component
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
h
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 Wi
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 Wi
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
Assignee|una
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 Wi
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 gcc
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 the
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 W
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 Wi
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
> > > > mi
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 writ
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 Wi
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
Pri
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 Wi
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
Prior
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
> `__builtin_c
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 even
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 we
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 a
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 Wi
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 s
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 W
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
Sta
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 Wi
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
1 - 100 of 135 matches
Mail list logo
