public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Martin Uecker <ma.uecker@gmail.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: reordering of trapping operations and volatile
Date: Sat, 08 Jan 2022 18:33:57 +0100	[thread overview]
Message-ID: <2089811.irdbgypaU6@fomalhaut> (raw)
In-Reply-To: <2e1783a9e2a107dff24ecc4944bd43b1903746f1.camel@gmail.com>

> Most C programmers would assume that volatile accesses already
> provides this guarantee, so actually doing so would be good.

I'm a little skeptical of this statement: if it was true, how come the most 
recent version of the standard does not provide it 30 years after the language 
was first standardized?

> Or a more practical example: While debugging some embedded
> device, it would also be very annoying if the compilers reorders
> some trap before some debugging output. I could easily imagine
> loosing hours figuring out what happens.

The thing to do to avoid losing these hours is to debug the code at -O0.

-- 
Eric Botcazou



  reply	other threads:[~2022-01-08 17:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-08  8:32 Martin Uecker
2022-01-08 12:41 ` Richard Biener
2022-01-08 13:50   ` Martin Uecker
2022-01-08 14:13     ` Marc Glisse
2022-01-08 14:41     ` Eric Botcazou
2022-01-08 15:27       ` Martin Uecker
2022-01-08 17:33         ` Eric Botcazou [this message]
2022-01-08 15:03 ` David Brown
2022-01-08 16:42   ` Martin Uecker
2022-01-08 18:35 ` Andrew Pinski
2022-01-08 21:07   ` Martin Uecker
2022-01-10  9:04     ` Richard Biener
2022-01-10 17:36       ` Martin Uecker
2022-01-11  7:11         ` Richard Biener
2022-01-11  8:17           ` Martin Uecker
2022-01-11  9:13             ` Richard Biener
2022-01-11 20:01               ` Martin Uecker
2022-01-13 16:45                 ` Michael Matz
2022-01-13 19:17                   ` Martin Uecker
2022-01-14 14:15                     ` Michael Matz
2022-01-14 14:58                       ` Paul Koning
2022-01-15 21:28                         ` Martin Sebor
2022-01-15 21:38                           ` Paul Koning
2022-01-16 12:37                             ` Martin Uecker
2022-01-14 15:46                       ` Martin Uecker
2022-01-14 19:54                       ` Jonathan Wakely
2022-01-15  9:00                         ` Martin Uecker
2022-01-15 16:33                           ` Jonathan Wakely
2022-01-15 18:48                             ` Martin Uecker
2022-01-17 14:10                               ` Michael Matz
2022-01-18  8:31                                 ` Richard Biener
2022-01-21 16:21                                   ` Martin Uecker
2022-01-11 18:17           ` David Brown

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=2089811.irdbgypaU6@fomalhaut \
    --to=ebotcazou@libertysurf.fr \
    --cc=gcc@gcc.gnu.org \
    --cc=ma.uecker@gmail.com \
    --cc=richard.guenther@gmail.com \
    /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).