From Newsgroup: comp.arch

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> writes:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation

Sounds like a bug to me.

But then, weak consistency, when documented, is a "feature" in the
sense of: Don't fix your bugs, document them as features; and some
have, at length; how many pages is the description of this bug in the
ARM manual, again?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 2026-Aug-16 08:18, Thomas Koenig wrote:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .

Are you sure your example is correct because that wouldn't work at all.
It would force the writer to insert store fences all over the place
just in case there was a copy of [x] in some other cache,
and that fence would stall the writer until all updates had reached
all readers and kill performance.

If this is correct then wow, they are in for a festival of buggy race conditions.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 2026-Aug-16 11:08, EricP wrote:

On 2026-Aug-16 08:18, Thomas Koenig wrote:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

-a-a-a x = 1;
-a-a-a x = 2;

and on the reader side

-a-a a = x;
-a-a b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .

Are you sure your example is correct because that wouldn't work at all.
It would force the writer to insert store fences all over the place
just in case there was a copy of [x] in some other cache,
and that fence would stall the writer until all updates had reached
all readers and kill performance.

If this is correct then wow, they are in for a festival of buggy race conditions.

The above could occur if the coherence protocol is write-update,
so store values are broadcast to all other cores,
AND the coherence network allows packets between to cores to be
reordered and processed out of order, such that two packets sent
in the order PKT1 then PKT2 arrive in the inbound queue in the
order PKT2 then PKT1. A network might reorder packets if there
are multiple packets in flight and one gets a retransmission,
or if the interconnect mesh allows the packets to take separate
paths with different transit times.

Most coherence protocols would avoid this by requiring
updates be multi-copy atomic, which basically forces use
of a write-invalidate protocol, and requires packets between
two nodes appear to be delivered in the order sent
(which can introduce deadlocks into a protocol that have to
be dealt with).



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

On 2026-Aug-16 08:18, Thomas Koenig wrote:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .

Are you sure your example is correct because that wouldn't work at all.

Yes, and apparently...

It would force the writer to insert store fences all over the place
just in case there was a copy of [x] in some other cache,
and that fence would stall the writer until all updates had reached
all readers and kill performance.

Yes.

If this is correct then wow, they are in for a festival of buggy race conditions.

Like somebody with a longsoon.cn address wrote in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935#c15

# Data race is clear, since neither M0 nor M1 cover this case;
# However, Loong64 is week ordered( even same address read after
# read is out of order), #3 is reordered by cpu and see u->s is NULL
# before #1;
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

I think what you want to say is that::

x = 1;
other instructions;
x = 2;

otherwise:
a) the compiler should be free to elide the first store
b) the write buffer should be free to elide the first store
c) write combining should be able to elide the first store

Then on the reading side::

a = *<some fancy address which points at x>;
b = *<some other address which points at x>;

Because the read buffer can notice that the same address is used twice
and only perform 1 read. Otherwise you have to introduce the notion of volatility (C level) or processor ordering rules (HW level).

I can see why a modern design team would want memory to be this weakly
ordered (I did so once a long time ago--and learned). What remains to
be seen is if they continue this path of difficulty, to learn and come
to their senses.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 8/16/2026 8:00 AM, Anton Ertl wrote:

Thomas Koenig <tkoenig@netcologne.de> writes:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

x = 1;
x = 2;

and on the reader side

a = x;
b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation

Sounds like a bug to me.

But then, weak consistency, when documented, is a "feature" in the
sense of: Don't fix your bugs, document them as features; and some
have, at length; how many pages is the description of this bug in the
ARM manual, again?

Huh? How is weak consistency a bug, or am I misunderstanding you?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 8/16/2026 8:08 AM, EricP wrote:

On 2026-Aug-16 08:18, Thomas Koenig wrote:

This is one is interesting, and even weaker than the Alpha,

On LoongArch, you if you read from the same address twice,
you cannot be sure without synchronization that you get
the reads ordered correctly,

So, if on the the writer side, you have (where x is in memory)

-a-a-a x = 1;
-a-a-a x = 2;

and on the reader side

-a-a a = x;
-a-a b = x;

you can have a=2 and b=1 as a result.

They don't even have this in their English documentation (I would
guess that LoongArch is for the Chinese market only, then) but it
caused a bug in gfortran recently, gcc.gnu.org/PR118935 .

Are you sure your example is correct because that wouldn't work at all.
It would force the writer to insert store fences all over the place
just in case there was a copy of [x] in some other cache,
and that fence would stall the writer until all updates had reached
all readers and kill performance.

If this is correct then wow, they are in for a festival of buggy race conditions.

Only from the programmers that don't know what they are doing?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:

On 8/16/2026 8:08 AM, EricP wrote:

If this is correct then wow, they are in for a festival of buggy race
conditions.

Only from the programmers that don't know what they are doing?

Here's the automated translation of the Chinese original.

2.1.9.1 Sequential Execution of Load Operations at the Same Address

When the Loongson architecture adopts a weakly consistent memory
coherence model, hardware support for the sequential execution of
load operations at the same address is not required by default. In
this case, the software must insert data barrier instructions (it is recommended to use `dbar 0x700`) where necessary to ensure correct
programme execution. If a specific processor implementation supports
sequential execution of load operations at the same address, it
must be ensured that the return value of CPUCFG.3.LD_SEQ_SA[bit23]
is 1, so that the software can identify this feature and carry
out relevant performance optimisations.

And yes, this causes real bugs in software that has
been written and tested for other processors.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 8/16/2026 1:45 PM, Thomas Koenig wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:

On 8/16/2026 8:08 AM, EricP wrote:

If this is correct then wow, they are in for a festival of buggy race
conditions.

Only from the programmers that don't know what they are doing?

Here's the automated translation of the Chinese original.

2.1.9.1 Sequential Execution of Load Operations at the Same Address

When the Loongson architecture adopts a weakly consistent memory
coherence model, hardware support for the sequential execution of
load operations at the same address is not required by default. In
this case, the software must insert data barrier instructions (it is recommended to use `dbar 0x700`) where necessary to ensure correct
programme execution. If a specific processor implementation supports sequential execution of load operations at the same address, it
must be ensured that the return value of CPUCFG.3.LD_SEQ_SA[bit23]
is 1, so that the software can identify this feature and carry
out relevant performance optimisations.

And yes, this causes real bugs in software that has
been written and tested for other processors.

Weaker than an Alpha that needs a membar even for data-dependent
loads... Therefore the arch MUST have sync instructions? Right?
--- Synchronet 3.22a-Linux NewsLink 1.2