Date: Wed, 10 Feb 2021 20:33:24 +0000
On Wed, 10 Feb 2021, Jens Gustedt via Liaison wrote:
> on Wed, 10 Feb 2021 18:51:15 +0000 you (Joseph Myers via Liaison
> <liaison_at_[hidden]>) wrote:
>
> > (I realise that some things that can be done with direct assignment
> > operators have no corresponding stdatomic.h operations; for example,
> > atomic compound assignment for floating-point types with all the
> > corresponding implications for handling floating-point exception
> > state. However, such operations could be added to stdatomic.h, so
> > allowing an explicit memory order to be specified, independent of any
> > way to apply atomic operations to non-atomic data.)
>
> I tried to add that with several papers, it didn't fly.
My concern with those changes was not with adding new operations, it was
that there were changes included in N2389 "Clean up atomics, non-normative
changes" that seemed unambiguously normative to me (disallowing a trap
from atomic integer /= 0, for example, so requiring implementations to
generate more complicated code around such integer compound assignment to
deal with such cases - anything requiring implementation changes is surely
a normative change). (I also think such additional requirements on
existing operations are of questionable merit.) Other committee members
may of course have had other concerns with those papers.
> on Wed, 10 Feb 2021 18:51:15 +0000 you (Joseph Myers via Liaison
> <liaison_at_[hidden]>) wrote:
>
> > (I realise that some things that can be done with direct assignment
> > operators have no corresponding stdatomic.h operations; for example,
> > atomic compound assignment for floating-point types with all the
> > corresponding implications for handling floating-point exception
> > state. However, such operations could be added to stdatomic.h, so
> > allowing an explicit memory order to be specified, independent of any
> > way to apply atomic operations to non-atomic data.)
>
> I tried to add that with several papers, it didn't fly.
My concern with those changes was not with adding new operations, it was
that there were changes included in N2389 "Clean up atomics, non-normative
changes" that seemed unambiguously normative to me (disallowing a trap
from atomic integer /= 0, for example, so requiring implementations to
generate more complicated code around such integer compound assignment to
deal with such cases - anything requiring implementation changes is surely
a normative change). (I also think such additional requirements on
existing operations are of questionable merit.) Other committee members
may of course have had other concerns with those papers.
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-02-10 14:33:47