> Am 01.03.2025 um 15:24 schrieb Martin Uecker :
>
> Am Samstag, dem 01.03.2025 um 16:52 +0300 schrieb Alexander Monakov:
>>> On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
>>>
>>> Sorry for being a bit slow. This is still not clear to me.
>>>
>>> In vect/pr65206.c the following loop can
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> > > What was the reason to disallow those optimizations that
> > > could be allowed by default?
> >
> > -fallow-store-data-races guards transforms that we know to be incorrect
> > for source code that may become a part of a multithreaded progr
Am Samstag, dem 01.03.2025 um 16:52 +0300 schrieb Alexander Monakov:
> On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
>
> > Sorry for being a bit slow. This is still not clear to me.
> >
> > In vect/pr65206.c the following loop can be vectorized
> > with -fallow-store-data-races.
> >
> > #def
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> Sorry for being a bit slow. This is still not clear to me.
>
> In vect/pr65206.c the following loop can be vectorized
> with -fallow-store-data-races.
>
> #define N 1024
>
> double a[N], b[N];
>
> void foo ()
> {
> for (int i = 0; i < N;
Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
> >
> > I have one follow-up question: What is the reason
> > that we have stronger semantics for stores by default (i.e.
> > when not using -fallow-store-data-races) than f
Am Freitag, dem 28.02.2025 um 20:21 +0100 schrieb Richard Biener:
>
> > Am 28.02.2025 um 20:02 schrieb Martin Uecker :
> >
> > Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> > > > On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
> > > >
> > > >
> > > > I have one follo
I have one follow-up question: What is the reason
that we have stronger semantics for stores by default (i.e.
when not using -fallow-store-data-races) than for reads
given that the standard would allow more freedom.
Only that for reads this is more difficult to have?
Or other specific reasons w
> Am 28.02.2025 um 20:02 schrieb Martin Uecker :
>
> Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
>>> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>>>
>>>
>>> I have one follow-up question: What is the reason
>>> that we have stronger semantics for stores by def
On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
> I have one follow-up question: What is the reason
> that we have stronger semantics for stores by default (i.e.
> when not using -fallow-store-data-races) than for reads
> given that the standard would allow more freedom.
Why would it? On
Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc:
> On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote:
> >
> >
> > Hi all,
> >
> > one area where the Linux kernel people are unhappy with C's
> > memory model is where they now have to use the READ_ONCE,
> > WRITE_ONCE m
On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote:
>
>
> Hi all,
>
> one area where the Linux kernel people are unhappy with C's
> memory model is where they now have to use the READ_ONCE,
> WRITE_ONCE macros. These are cases where they do not want
> a compiler to duplicate a load, e.g. to relo
Hi all,
one area where the Linux kernel people are unhappy with C's
memory model is where they now have to use the READ_ONCE,
WRITE_ONCE macros. These are cases where they do not want
a compiler to duplicate a load, e.g. to reload a value
later because registers were not available to cache it.
12 matches
Mail list logo
