public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization
Date: Thu, 02 May 2024 23:42:04 +0000	[thread overview]
Message-ID: <bug-114923-4-4CYvjBSJ7K@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114923-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to nfxjfg from comment #7)
> > Note also the order of the writes to reg1 and reg2 might happen in a different order in HW so you need to have a full (HW) write barrier between them to make sure the write is done in the correct order.
> 
> Seriously? That breaks literally all code that uses volatile for register
> access (which, in our firmwares, is ALL code). This just fuels my belief
> that gcc and C compiler developers in general turned C into a useless,
> fragile language that can't do anything correctly.
> 
> Is there a way to prevent reordering of volatile accesses?

Yes you need to use inline-asm to get a hw write barrier.
This has been this way for the last 20+ years even when it comes to out of
order processors. 

https://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf should be
very useful. Basically volatile means the compiler not to remove the store/load
from it but it does not mean the HW will reorder the stores/loads. 

Oh and GCC even documents part of this:
https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

"Accesses to non-volatile objects are not ordered with respect to volatile
accesses. You cannot use a volatile object as a memory barrier to order a
sequence of writes to non-volatile memory. "

The documentation does not mention hw memory barriers since that is outside of
the compiler view really. This has been standard behavior with GCC and hardware
with weak memory systems for over 20 years.

That is even if GCC outputs the writes in order in the assembly the hardware
(or future hardware depending on the definition of the hardware) might reorder
the writes. RISCV IIRC has both a weak and strong memory consistency models.
https://riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTutorial.pdf
for more details on it. GCC will never output the needed instructions directly.

  parent reply	other threads:[~2024-05-02 23:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-02 12:51 [Bug c/114923] New: " nfxjfg at googlemail dot com
2024-05-02 12:52 ` [Bug c/114923] " nfxjfg at googlemail dot com
2024-05-02 13:24 ` amonakov at gcc dot gnu.org
2024-05-02 13:44 ` nfxjfg at googlemail dot com
2024-05-02 13:56 ` amonakov at gcc dot gnu.org
2024-05-02 19:07 ` [Bug middle-end/114923] " pinskia at gcc dot gnu.org
2024-05-02 19:15 ` pinskia at gcc dot gnu.org
2024-05-02 23:03 ` nfxjfg at googlemail dot com
2024-05-02 23:42 ` pinskia at gcc dot gnu.org [this message]
2024-05-03  0:30 ` nfxjfg at googlemail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-114923-4-4CYvjBSJ7K@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).