public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "keno at juliacomputing dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
Date: Tue, 24 May 2022 00:47:30 +0000	[thread overview]
Message-ID: <bug-105708-4-Tj4lZrsmUa@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105708-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from Keno Fischer <keno at juliacomputing dot com> ---
I'm probably talking in circles at this point, but let me try just one more
time. I just want to clarify that I understand that this is not technically a
libgcc bug. But it's not really an rr bug either. Existing hardware already
barely supports rr and we're still working with a number of silicon vendors to
address microarchitecture bugs that are causing issues. We'll also keep
advocating for hardware support for ll/sc emulation/trapping, but as you can
imagine that's a big lift. It's not a matter of rr just fixing some code - the
hardware support required for this does not currently exist. These limitations
are proactively communicated to the user and there are appropriate error
messages for unsupported situations (e.g. use of a broken microarchitecture or
recording of an application that used ll/sc). I was hoping by making this
change in libgcc we could increase the number of situations where rr does work,
without putting significant extra burden on the distribution maintainers. That
said, if this really is a hard WONTFIX here, then we'll work with the
distribution maintainers to start carrying a libgcc patch as necessary :(. It's
gonna be messy and I'm not looking forward to it, but I don't really know what
else to say to make my case here.

  parent reply	other threads:[~2022-05-24  0:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 23:46 [Bug libgcc/105708] New: " keno at juliacomputing dot com
2022-05-23 23:57 ` [Bug libgcc/105708] " pinskia at gcc dot gnu.org
2022-05-24  0:00 ` pinskia at gcc dot gnu.org
2022-05-24  0:03 ` keno at juliacomputing dot com
2022-05-24  0:08 ` pinskia at gcc dot gnu.org
2022-05-24  0:22 ` keno at juliacomputing dot com
2022-05-24  0:27 ` pinskia at gcc dot gnu.org
2022-05-24  0:47 ` keno at juliacomputing dot com [this message]
2022-05-24  0:50 ` pinskia at gcc dot gnu.org
2022-05-24  6:22 ` roc at ocallahan dot org
2022-05-24 10:00 ` wilco at gcc dot gnu.org
2022-05-24 10:21 ` jakub at gcc dot gnu.org
2022-05-24 11:15 ` wilco at gcc dot gnu.org
2022-05-24 13:56 ` wilco at gcc dot gnu.org
2022-05-25 14:54 ` cvs-commit at gcc dot gnu.org
2022-10-24 21:41 ` pinskia at gcc dot gnu.org

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-105708-4-Tj4lZrsmUa@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).