https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117711
Wilco changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
--- Comment #10 from Wilco ---
(In reply to Andrew Pinski from comment #6)
> I am trying to understand why there were checks for DECIMAL_FLOAT_MODE_P in
> the first place. Removing them allows the testcase to pass.
That was because the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118999
--- Comment #1 from Wilco ---
Thanks for the reproducer, confirmed. It is hard to blame this on scheduling
since the difference is almost exclusively due to a huge increase of branch
mispredictions. The basic block layout is oddly different in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118999
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
--- Comment #3 from Wilco ---
This is a latent issue with zero handling for decimal float, this looks wrong:
/* Return TRUE if rtx X is immediate constant 0.0 (but not in Decimal
Floating Point). */
bool
aarch64_float_const_zero_rtx_p (rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #12 from Wilco ---
(In reply to Richard Biener from comment #9)
> I have also always wondered about that glibc guard, esp. it being the
> kitchen-sink fast-math guard rather than sth more specific (yep, we don't
> have anything for -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #11 from Wilco ---
(In reply to Andrew Pinski from comment #8)
> Though accessing the errno from fortran is almost never done anyways so I
> doubt that will matter here.
The issue is that fast-math is the combination of many differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #6 from Wilco ---
(In reply to Andrew Pinski from comment #5)
> Or you could just do:
> #define TARGET_F951_OPTIONS "%{Ofast|ffast-math|funsafe-math-optimizations: \
> %{!nostdinc: \
>%:fortran-preinclude-file(-fpre-include= mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #2 from Wilco ---
(In reply to Thomas Koenig from comment #1)
> > Since vector
> > functions can have much larger ULP errors, using them by default with -O2
> > seems excessive.
>
> "can have"? Is this indeed the case? I would consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
Wilco changed:
What|Removed |Added
Target Milestone|--- |16.0
Target|
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
This example will use the vector cosf even with -O2:
!GCC$ builtin (cosf) attributes simd (notinbranch)
PARAMETER (NX=100, G=1.4)
DIMENSION T(NX), P(NX)
INTEGER
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
gcc dot gnu.org |wilco at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Wilco ---
Confirmed. I had a quick look - performance counters suggest the increase in
cycles is due to backend stalls, so early
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
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
1 - 100 of 743 matches
Mail list logo
