From: Chris Hall <gcc@gmch.uk>
To: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ?
Date: Sat, 7 Mar 2020 13:04:19 +0000 [thread overview]
Message-ID: <89e37e83-9470-54f7-c211-e82f00302266@gmch.uk> (raw)
In-Reply-To: <CAH6eHdRH1Sby8hB-fOPe4SMZfJKZjEFzZmqNmJt5xPTmwq4HYw@mail.gmail.com>
On 06/03/2020 17:45, Jonathan Wakely wrote:
> On Fri, 6 Mar 2020 at 16:17, Chris Hall <gcc@gmch.uk> wrote:
>>> Sure. But the Standard atomic_fetch_add() takes an _Atomic(xxx)* (as
>>> the first parameter), and for the reasons given, I understand that
>>> uint64_t* is not compatible with _Atomic(uint64_t)*.
> I don't think GCC is treating them as though they are compatible. It
> just accepts a broader range of types than only _Atomic ones, and
> does the right thing for them all (apart from pointers where the
> arithmetic is wrong).
>> FWIW: clang gets this right, and where the Standard says a parameter
>> must be an _Atomic(foo_t)* [for a standard atomic_xxx()], clang rejects
>> foo_t* arguments.
> It's not clear to me that C actually requires it to be rejected, or if
> it's just undefined (in which case GCC's decision to accept it and do
> the obvious thing is OK).
The subtlety of the distinction between "only defined to accept" and
"defined to only accept" had escaped me for a moment :-(
Of course, for all the machines I know well enough I can say that there
is no difference between, inter alia, uint64_t and _Atomic(uint64_t).
So what I have observed GCC doing is, arguably, helpful.
For all I know, GCC may be equally helpful on machines where uint64_t
and _Atomic(uint64_t) are not the same -- and issue some form of
diagnostic. Hopefully an error, rather than a
-Wincompatible-pointer-types warning, since a warning would (probably?)
not prevent the resulting code from crashing and burning.
If I write:
uint64_t px(uint64_t* p) { return *p ; }
char m[] = "There's glory for you!" ;
printf("%lu", px(m+9)) ;
GCC chips in a -Wincompatible-pointer-types (if suitably prompted...
-Wall ?).
Now, if I make a conscious decision to ignore all machines which may
crash or otherwise misbehave for unaligned uint64_t reads, I can cast
the m+9 -- and anything I then get is my fault.
I wonder if, by extension, the atomic_xxx() should (at least) warn when
the _Atomic() parameters are passed not-_Atomic() arguments ?
As I have said elsewhere, I think the real problem is that the Standard
fails to define vital things as Implementation Defined, leaving the
programmer guessing as to what their code is going to do when compiled
for some machine/system they are not familiar with.
I note
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4013.html --
courtesy of Andrew Haley -- suggests new facilities to check at compile
time specifically for this case. IMO there should also be facilities to
check for "wait-free" -- unless "lock-free" already does that job... but
that's another story.
Chris
next prev parent reply other threads:[~2020-03-07 16:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <72f6344e-d8b2-bab4-b047-63e298063492@gmch.uk>
2020-02-27 17:27 ` Chris Hall
2020-02-28 15:23 ` Jim Wilson
2020-02-28 21:04 ` Chris Hall
2020-03-06 16:17 ` Chris Hall
2020-03-06 17:46 ` Jonathan Wakely
2020-03-07 11:00 ` Andrew Haley
2020-03-07 19:27 ` Jonathan Wakely
2020-03-07 13:04 ` Chris Hall [this message]
2020-03-07 19:29 ` Jonathan Wakely
2020-03-08 20:11 ` Martin Sebor
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=89e37e83-9470-54f7-c211-e82f00302266@gmch.uk \
--to=gcc@gmch.uk \
--cc=gcc-help@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).