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
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following code shows ABI inconsistencies between GCC and LLVM:
#include
#include
#include
_Atomic struct A3 { char a[3
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
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
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The CPU features initialization code uses CPUID registers. It uses incorrect
comparisons so that for example SVE is not
|1
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Last reconfirmed||2024-05-23
--- Comment #2 from Wilco ---
(In reply to Andrew Pinski from comment #1)
> At first I thought it was the same failure as PR 115153 but it
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|---
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example no longer emits LDP/STP since GCC14:
#include
typedef struct { int arr[20]; } S;
void g (S *);
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Wilco changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example:
#include "arm_neon.h"
uint32x4_t test (uint32x4_t v1, uint32x4_t v2)
{
return vpaddq_u32 (v1, v2);
}
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
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
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
dot gnu.org |wilco at gcc dot gnu.org
--- Comment #11 from Wilco ---
Yes the default for "conds" attribute is incorrect and at odds with the
"predicable" attribute. The fix should work but will disable conditional
execution on a few ARM-only patterns that just have &q
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
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following is often used as an idiom for memmove since GCC mid-end and most
back-ends have no support for inlining memmove:
void move64 (char *a, char *b)
{
char
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
|1
CC||wilco at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #3 from Wilco ---
We should reassociate the immediate last for more optimal addressing like LLVM:
adrpx8, a
add x8, x8
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
||wilco at gcc dot gnu.org
Last reconfirmed||2023-09-14
Target||arm-*
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Component
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
This compiles
__int128 f(__int128 *p, __int128 *q, __int128 x)
{
return __sync_val_compare_and_swap (p, *q, x);
}
into:
f:
ldp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Assignee
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|
gcc dot gnu.org |wilco at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||12.0, 13.0
Status|UNCONFIRMED |ASSIGNED
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Since GCC 12.0 the following example corrupts x0 when built with -O2
-march=armv8.6-a+mops:
int *f (int *p, int *q, long n) { memmove (p, q, n); return p; }
f:
cpyp
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
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
> > > > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=80878
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Status|RESOLVED|NEW
Resolution|DUPLICATE
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
128-bit atomics should be lock-free on AArch64. This is what most users expect,
gives better performance and makes it possible to inline
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|---
||2023-02-23
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
LSE2 uses the following sequence for a 16-byte atomic load:
ldp res0, res1, [x0]
dmb ish
The AArch64 memory model allows the LDP to be
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
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
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. It's
||2022-11-04
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #10 from Wilco ---
(In reply to Rama Malladi from comment #9)
> (In reply to Rama Malladi from comment #8)
> > (In reply
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 Ne
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
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Wilco ---
As Andrew says, it's a duplicate so fixed now.
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
1 - 100 of 724 matches
Mail list logo