Date: Fri, 2 Apr 2021 12:13:40 +0200
Jens,
I have now gone through your remarks and I hope that we will have a
new version, soon. Comments, also to your original mail, below.
on Thu, 25 Mar 2021 12:13:26 +0100 you (Jens Maurer <Jens.Maurer_at_[hidden]>) wrote:
> On 25/03/2021 11.12, Jens Gustedt wrote:
> >> Special-casing call_once in all of this seems to be very much a
> >> quality-of-implementation concern. Every implementation should
> >> choose whether it wants to teach its optimizer about the
> >> special "call_once" properties. (After all, this is all about
> >> optimizations, which are optional anyway.)
> >
> > I think that I don't agree completely. The text should make
> > guarantees about the data dependencies that can be induced by calls
> > to C library functions. `call_once` is one of them, and in addition
> > it has very special semantics that are relevant for the properties
> > at hand. So something should be said in one form or another.
>
> Ok, but maybe that's a property of this particular function
> (that should be stated near where it's specified) instead
> of something we need to talk about in the specification of the
> attributes.
We added a text to the introductory part of that clause that describes
why this exception is necessary.
> This has practical impact for C++: We "inherit" (almost) all
> of the C standard library, but none of the core language.
> So, if the relevant text for call_once goes into the
> call_once specification, chances are we'll get its properties
> "for free" into C++. (Hm... I just realized C++ doesn't
> provide <threads.h> at all, so maybe the "inheritance" argument
> doesn't apply for this particular situation.)
Yes, you don't have `call_once` because C++ has other means to
initialized static variables dynamically. So a C++ implementation
should then relate to these mechanisms and explain if (or not) they
are impacted.
> > on Thu, 25 Mar 2021 10:44:09 +0100 you (Jens Maurer via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> >> These look like possibly useful attributes for C++ as well,
> >> but the wording needs to be totally redone.
> >>
> >> First of all, these attributes assert certain facts about a
> >> function to the compiler, which possibly cannot be deduced by
> >> the compiler.
> >> This is most useful if the compiler cannot "see" the definition
> >> of the function. However, this wording contains quite a bit
> >> of text talking about "is implied", meaning that the
> >> compiler analyzes a function definition and then implicitly
> >> adds the attribute to the definition. But if the
> >> compiler can "see" the function definition, there is little
> >> need for an implied attribute in the first place, because the
> >> compiler already has all the information it can possibly infer
> >> about the function (and it might inline the call anyway).
> >>
> >> I'd like to see some explanation in the prose why the "is implied"
> >> parts of the proposal are worth having. If "is implied" goes
> >> away, the wording should be rephrased in the form of
> >> assertions that the user makes, and should give the user
> >> liberty to assert any function, without further constraints
> >> on what the function actually does.
As said, all of these fall through the cracks because WG14 didn't like
them either.
> >> ...
> >>
> >>
> >> - It would help me if the wording would show monospace font where
> >> the standard does, for example in 6.7.11.1 p2 (list of attribute
> >> names) and 6.7.11.6 p1 (same).
yes, that's the disadvantage of not working on the LaTeX sources
directly. I try my best for the next version
> >> ...
> >> - 6.7.11.6.1 noleak: Any function -> All functions
> >>
> >> Why do we have to mention allocation functions explicitly? They
> >> certainly don't carry the "noleak" attribute, so the first bullet
> >> covers them nicely.
No, allocation functions only change the state of the memory system by
returning a new pointer, they have themselves no leak (hopefully). So
by the definition as presented here they could have the attribute.
> >> - 6.7.11.6.1 noleak: p3 This appears to define the term "storage
> >> leak", but it's not used going forward. "can be deduced by the
> >> translator" seems vague at best: some compilers can deduce more
> >> than others; the specification of the standard needs to draw the
> >> line by explicitly saying what's going on.
> >>
> >> - p4 "with the exception of an allocated return value"
> >> What does that mean, exactly? When is a return value "allocated"?
> >> Also "shall be" sounds like a Constraint, not a Description.
This was probably not so well formulated. Hope this will be clearer, then.
> >> ...
> >> - 6.7.11.6.3 p2 "are const qualified variables that may range over
> >> the whole admissible set" This feels like "value" is missing
> >> somewhere, e.g. "whose values may range over..." What's the
> >> "admissible set" of function arguments? Using const-qualified
> >> variables as function arguments doesn't do anything, because the
> >> function parameter values are copies of those arguments anyway.
> >> Also, I don't think the fact that something is const-qualified is
> >> the point here, but the fact that no writes happen (you can choose
> >> not to write to a non-const variable, too).
yes, reformulated just with values
Thanks
the C Jens
I have now gone through your remarks and I hope that we will have a
new version, soon. Comments, also to your original mail, below.
on Thu, 25 Mar 2021 12:13:26 +0100 you (Jens Maurer <Jens.Maurer_at_[hidden]>) wrote:
> On 25/03/2021 11.12, Jens Gustedt wrote:
> >> Special-casing call_once in all of this seems to be very much a
> >> quality-of-implementation concern. Every implementation should
> >> choose whether it wants to teach its optimizer about the
> >> special "call_once" properties. (After all, this is all about
> >> optimizations, which are optional anyway.)
> >
> > I think that I don't agree completely. The text should make
> > guarantees about the data dependencies that can be induced by calls
> > to C library functions. `call_once` is one of them, and in addition
> > it has very special semantics that are relevant for the properties
> > at hand. So something should be said in one form or another.
>
> Ok, but maybe that's a property of this particular function
> (that should be stated near where it's specified) instead
> of something we need to talk about in the specification of the
> attributes.
We added a text to the introductory part of that clause that describes
why this exception is necessary.
> This has practical impact for C++: We "inherit" (almost) all
> of the C standard library, but none of the core language.
> So, if the relevant text for call_once goes into the
> call_once specification, chances are we'll get its properties
> "for free" into C++. (Hm... I just realized C++ doesn't
> provide <threads.h> at all, so maybe the "inheritance" argument
> doesn't apply for this particular situation.)
Yes, you don't have `call_once` because C++ has other means to
initialized static variables dynamically. So a C++ implementation
should then relate to these mechanisms and explain if (or not) they
are impacted.
> > on Thu, 25 Mar 2021 10:44:09 +0100 you (Jens Maurer via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> >> These look like possibly useful attributes for C++ as well,
> >> but the wording needs to be totally redone.
> >>
> >> First of all, these attributes assert certain facts about a
> >> function to the compiler, which possibly cannot be deduced by
> >> the compiler.
> >> This is most useful if the compiler cannot "see" the definition
> >> of the function. However, this wording contains quite a bit
> >> of text talking about "is implied", meaning that the
> >> compiler analyzes a function definition and then implicitly
> >> adds the attribute to the definition. But if the
> >> compiler can "see" the function definition, there is little
> >> need for an implied attribute in the first place, because the
> >> compiler already has all the information it can possibly infer
> >> about the function (and it might inline the call anyway).
> >>
> >> I'd like to see some explanation in the prose why the "is implied"
> >> parts of the proposal are worth having. If "is implied" goes
> >> away, the wording should be rephrased in the form of
> >> assertions that the user makes, and should give the user
> >> liberty to assert any function, without further constraints
> >> on what the function actually does.
As said, all of these fall through the cracks because WG14 didn't like
them either.
> >> ...
> >>
> >>
> >> - It would help me if the wording would show monospace font where
> >> the standard does, for example in 6.7.11.1 p2 (list of attribute
> >> names) and 6.7.11.6 p1 (same).
yes, that's the disadvantage of not working on the LaTeX sources
directly. I try my best for the next version
> >> ...
> >> - 6.7.11.6.1 noleak: Any function -> All functions
> >>
> >> Why do we have to mention allocation functions explicitly? They
> >> certainly don't carry the "noleak" attribute, so the first bullet
> >> covers them nicely.
No, allocation functions only change the state of the memory system by
returning a new pointer, they have themselves no leak (hopefully). So
by the definition as presented here they could have the attribute.
> >> - 6.7.11.6.1 noleak: p3 This appears to define the term "storage
> >> leak", but it's not used going forward. "can be deduced by the
> >> translator" seems vague at best: some compilers can deduce more
> >> than others; the specification of the standard needs to draw the
> >> line by explicitly saying what's going on.
> >>
> >> - p4 "with the exception of an allocated return value"
> >> What does that mean, exactly? When is a return value "allocated"?
> >> Also "shall be" sounds like a Constraint, not a Description.
This was probably not so well formulated. Hope this will be clearer, then.
> >> ...
> >> - 6.7.11.6.3 p2 "are const qualified variables that may range over
> >> the whole admissible set" This feels like "value" is missing
> >> somewhere, e.g. "whose values may range over..." What's the
> >> "admissible set" of function arguments? Using const-qualified
> >> variables as function arguments doesn't do anything, because the
> >> function parameter values are copies of those arguments anyway.
> >> Also, I don't think the fact that something is const-qualified is
> >> the point here, but the fact that no writes happen (you can choose
> >> not to write to a non-const variable, too).
yes, reformulated just with values
Thanks
the C 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-04-02 05:13:50