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=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
--- 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=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 #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 #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
Wilco changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #16 from Wilco ---
Fixed by
h
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=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
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=115388
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #7 from
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=115342
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=115188
Wilco changed:
What|Removed |Added
Status|ASSIGNED|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=103100
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=115153
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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
--- 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 #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=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=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=117292
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=117675
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=118142
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #9 from
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 #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 -
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=118955
Wilco changed:
What|Removed |Added
Target Milestone|--- |16.0
Target|
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
--- 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=118999
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Last reconfirmed
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
--- 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=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=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=110773
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
701 - 742 of 742 matches
Mail list logo
