Date: Wed, 10 Feb 2021 10:09:36 +0100
on Wed, 10 Feb 2021 08:29:18 +0000 you ("Uecker, Martin via Liaison"
<liaison_at_[hidden]>) wrote:
> Here is a godbolt link for a test program. I tested only x86 on
> gcc/clang/icc and ABI is already broken. For basic types it works.
> For complex float/double alignment changes. Atomic struct types are
> not supported in ICC at all and ABI is inconsistent between GCC C /
> GCC C++ / clang C++ on the one side and clang C on the other (so also
> between clang C and C++!).
>
> So yes, a complete desaster.
Agreed, and we are only touching the surface with this
discussion. There are already a lot of design inconsistencies on the C
side itself. I would have much prefered that WG14 does some
housecleaning. Unfortunately, that housecleaning never found
sufficiently momentum, I tried several times.
Now it is a bit unfortunate that the `_Atomic()` specifier seems to be
adopted as a macro interface for the interlanguage API, I would much
have prefered a fresh start. E.g, to use a new name such as
`atomic_type()` as I proposed in the C/C++ core document.
(Hans, don't get me wrong, I admire your ability to get this through
WG21, this was certainly not that easy.)
That it seems that some C++ platform (with several implementations)
have not been able to agree on ABI (that's what I understand from what
you are saying, Martin), is worrisome.
On the other hand, MS C having difficulties, is not sooo surprising,
they only recently have adopted a modern version of C, so they
probably have some catching up to do. That CUDA feels the need to have
internal locks, should worry us much more. The possibilities of
threads on a relatively low level (C threads don't even have to
provide mutual access to the stack) is not very explored up to now. So
I think we should be careful not to close doors.
Thanks
Jens
<liaison_at_[hidden]>) wrote:
> Here is a godbolt link for a test program. I tested only x86 on
> gcc/clang/icc and ABI is already broken. For basic types it works.
> For complex float/double alignment changes. Atomic struct types are
> not supported in ICC at all and ABI is inconsistent between GCC C /
> GCC C++ / clang C++ on the one side and clang C on the other (so also
> between clang C and C++!).
>
> So yes, a complete desaster.
Agreed, and we are only touching the surface with this
discussion. There are already a lot of design inconsistencies on the C
side itself. I would have much prefered that WG14 does some
housecleaning. Unfortunately, that housecleaning never found
sufficiently momentum, I tried several times.
Now it is a bit unfortunate that the `_Atomic()` specifier seems to be
adopted as a macro interface for the interlanguage API, I would much
have prefered a fresh start. E.g, to use a new name such as
`atomic_type()` as I proposed in the C/C++ core document.
(Hans, don't get me wrong, I admire your ability to get this through
WG21, this was certainly not that easy.)
That it seems that some C++ platform (with several implementations)
have not been able to agree on ABI (that's what I understand from what
you are saying, Martin), is worrisome.
On the other hand, MS C having difficulties, is not sooo surprising,
they only recently have adopted a modern version of C, so they
probably have some catching up to do. That CUDA feels the need to have
internal locks, should worry us much more. The possibilities of
threads on a relatively low level (C threads don't even have to
provide mutual access to the stack) is not very explored up to now. So
I think we should be careful not to close doors.
Thanks
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2021-02-10 03:09:41