Date: Fri, 15 Jul 2022 11:38:29 -0400
On Fri, Jul 15, 2022 at 11:16 AM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 15/07/2022 16.19, Hubert Tong wrote:
> > On Fri, Jul 15, 2022 at 3:36 AM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 15/07/2022 02.20, Hubert Tong via SG5 wrote:
> > > In DTS 12907, 8.8 [stmt.tx] paragraph 6, bullet 6.7:
> > >
> > > * dynamic initialization of a variable with thread storage
> duration.
> > >
> > > Is this intended to cover the case where the dynamic
> initialization for a non-local variable of thread storage duration is
> evaluated within the atomic block because the initialization was deferred
> ([basic.start.dynamic]) and can be deferred no further?
> >
> > This is primarily concerned with local variables with thread storage
> duration,
> > where we have express synchronization effects.
> >
> > However, it seems safer to exclude such dynamic initialization in
> general
> > (as the wording implies).
> >
> >
> > Would you entertain a core issue to add a note to clarify that the wider
> scope is as intended?
>
> This is the Transactional Memory TS, which is (possibly) done after the
> July
> plenary, so a Core issue is lacking any defined ship vehicle.
>
> Do we want to add that change to the NB comment resolution paper as an
> add-on fix?
>
Perhaps. Dynamic initialization of non-local variables essentially leads to
(implementation-wise) the invocation of non-inline functions.
>
> Jens
>
>
> On 15/07/2022 16.19, Hubert Tong wrote:
> > On Fri, Jul 15, 2022 at 3:36 AM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 15/07/2022 02.20, Hubert Tong via SG5 wrote:
> > > In DTS 12907, 8.8 [stmt.tx] paragraph 6, bullet 6.7:
> > >
> > > * dynamic initialization of a variable with thread storage
> duration.
> > >
> > > Is this intended to cover the case where the dynamic
> initialization for a non-local variable of thread storage duration is
> evaluated within the atomic block because the initialization was deferred
> ([basic.start.dynamic]) and can be deferred no further?
> >
> > This is primarily concerned with local variables with thread storage
> duration,
> > where we have express synchronization effects.
> >
> > However, it seems safer to exclude such dynamic initialization in
> general
> > (as the wording implies).
> >
> >
> > Would you entertain a core issue to add a note to clarify that the wider
> scope is as intended?
>
> This is the Transactional Memory TS, which is (possibly) done after the
> July
> plenary, so a Core issue is lacking any defined ship vehicle.
>
> Do we want to add that change to the NB comment resolution paper as an
> add-on fix?
>
Perhaps. Dynamic initialization of non-local variables essentially leads to
(implementation-wise) the invocation of non-inline functions.
>
> Jens
>
>
Received on 2022-07-15 15:38:56