Thanks Michael. I was in a meeting and could not attend; these minutes are appreciated

Le mer. 17 avr. 2019 à 15:32, Michael Wong via SG14 <sg14@lists.isocpp.org> a écrit :
 meeting minutes by michael

On Wed, Apr 17, 2019 at 8:42 AM Michael Wong <fraggamuffin@gmail.com> wrote:
Sorry I need to add Niall's paper to the Pointer providence discussion. I have already linked to Hal's paper and Paul McKenney's paper.

On Wed, Apr 17, 2019 at 8:38 AM Michael Wong <fraggamuffin@gmail.com> wrote:
Hi we are switching to Zoom instead of Webex for our SG14 meetings. Please let me know if there are additional agenda items.

Michael Wong is inviting you to a scheduled Zoom meeting.

Topic: SG14 Low Latency Monthly
Time: Apr 17, 2019 2:00 PM Eastern Time (US and Canada)
    Apr 17, 2019 2:00 PM
    May 8, 2019 2:00 PM
    Jun 12, 2019 2:00 PM
    Jul 10, 2019 2:00 PM
    Aug 14, 2019 2:00 PM
    Sep 11, 2019 2:00 PM
    Oct 9, 2019 2:00 PM
    Please download and import the following iCalendar (.ics) files to your calendar system.
    Monthly: https://iso.zoom.us/meeting/406503386/ics?icsToken=8d46c9bf03730dd553cc4f9306ceedfc45867014725c0aca989cb39d9602ae7c

Join from PC, Mac, Linux, iOS or Android: https://iso.zoom.us/j/406503386

Or iPhone one-tap :
    US: +16468769923,,406503386#  or +16699006833,,406503386#
Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
        US: +1 646 876 9923  or +1 669 900 6833  or +1 408 638 0968  or 877 369 0926 (Toll Free) or 877 853 5247 (Toll Free)
    Meeting ID: 406 503 386
    International numbers available: https://zoom.us/u/abhaIjFKLZ

Or Skype for Business (Lync):
    https://iso.zoom.us/skype/406503386


Agenda:

1. Opening and introductions

1.1 Roll call of participants

 Guy Davidson, Jan Wilmans, Ben Craig, Niall , Andreas Fertig, Steven Varga, Grafik Robot (Rene Rivera
), Michael Wong, Andreas Weis, Hubert Tong, Maged Michael, Paul McKenney, Staffan TJ, Jens Maurer, John Macfarlane, Charles Bay


1.2 Adopt agenda


Yes

1.3 Approve minutes from previous meeting, and approve publishing  previously approved minutes to ISOCPP.org

Yes

1.4 Action items from previous meetings

2. Main issues (125 min)

2.1 General logistics

Review last call discussions.


CPPCON SG14 meeting is now up for attendance


2.2 Paper reviews

2.2.1 Embedded/freestanding vs hosted

Summary of freestanding evening session discussions

http://wiki.edg.com/bin/view/Wg21kona2019/SG14FreestandingImplementations


we did do polls on library stuff, added EWG, LWG, outside of SG14 SG1
1. add library feature to FS subset that dont use troublesome: 11/11/5/0/1
2. same as 1 but adds eh: 3/12/7/4/1
strongly against was chandler: concerned about being able to ship a compiler that does not have a std library, and relies on an external vendor for std library
have a lowest module that have the interestign bits that requires compiler knowledge,
What part of proposal is inhibiting Chandler? he wants to ship FS impl with little as possible and have others layer the hosted part on top
if we add stringview and std sort then it adds a lot on implementation, its not libC++ that is providing it, he should provide a product that is partial or non conforming and let the user adds what ever is still needed

what about method on classes that throws, e.g. std array at, array makes a lot of sense in FS, but at throws if out of range

lot of neutrals on this poll
Make calls to potentially-throwing library functions ill-formed. (7/6/10/1/2)dont provide std array at
Make the library turn throw statements into abort (for example, by preprocessor), as is common practice in no exception builds. (1/7/7/6/5) today we terminate and going away from that is not realistic, Ben may have a way through this with some std weasel wording, nonrmative: in a program with no catch statement, it is untectable diff between callign std terminate and throwing an exception and your impl does not unwind the stack when an uncaught exception is thrown i.e. if you have no exception mode, then just call terminate because program has no catch statement
Make the library turn throw statements into terminate (for example, by preprocessor). (1/5/14/2/4)
Make the exception handling strategy implementation defined. (0/5/10/6/2)

future progress: on std library got go head to push it along for C++23
every meeting I had to update the paper, like a giant merge conflict
so split P0829 into multiple small papers

updating our editorial technique so other papers in flight can ride along
also touch on feature testing macros

core language side: have exception as the most important but most contentious
will discuss next month
teh size cost of eh
return value is smaller costs
by Belfast, plan for an exception runtime paper to show happy paths to start providing more paper
operator new and delete a paper on that through ewg, this seems one of the easier one to accept
this will say dont require allocating form of op new and delete, you can provide your own just like you can today
by default they are not required to be there


Herb and I talked at ACCU, he advises taht we we get what agreement we can in SG14 where SG14 is in full agreement, then go to EWG with SG14 blessing.
but first makes sure we can get SG14 agreement first.

JM likes the split exception idea making a case indistinguishable if there is no catch clause
make code with throw statements compilable, but make it no different 
AW: yes when std library throws eh, what is semantics, then semantics does not change,
upshot is you can compile these libraries
BC: must meet same requirement as on hosted implementations, so in those mode they would provide an array at

HT: that latter point of doing no unwinding unless you find a handler, if you have a binary distributed mode, of yoru library and it does throw, any stack unwinding that may happen in the library will be enough to kill this.
For those impl if they want to stay conforming, then they dont provide at, or dont unwind
so there is still burden for implementor imvestigation

I know GCC documents throwing with no catch does not unwind stack, clang might unwind

JW: this could force them to all do it the same way
could be whether they use libunwnd or libgcc_eh
or it could be the type info is not properly encoded when they have noexcept fn calling something that is noexcept code





Outcome from Dec call:
In the SG14 session, he mentioned 2 that he prefers
* Freestanding is signal / interrupt safe
* Freestanding requires no special dispensation from the operating environment above what freestanding C99 requires

But there are other possible directions
* Freestanding should be as small as possible
* Freestanding has all the same core language features as hosted



2.2.2 Pointer Provedence:

push from cambridge, peter Sewell's team trying to formalize C MM mathematically
Chandler opposed
SG12 did more work work with C, Han did most of the liasion,
also was at Euro LLVM, this is Niall's interpretation
if object;'s lifetime, all conforming impl may have all pointers pointing at that object invalid
if you new an item using placement new, then reuse that address, previous pointers are invalid, new pointers to the new object is valid
these 2 ptrs can potentially equal, and this can cause problems
the rationale behind std launder which can point to an area to tell lifetime is not what the compiler expects

C is now bringing this into their standard
hopefully get reconcilliation between the 2
compare equal and substitute one for the other are 2 different things

zap pointer life time
are they bitwise identical if pointed to the same object

N2369:
History on why we set it this way
What does C  say,
best you can say is that if someone free a ptr, compiler is within its right to cause indeterminate all copies of that pointer in the program no matter where they are, cant load, compare or deref or touch the bits

difference in C++ lifetime (object lifetime) and storage duration (what paul is talkign about)

What is the difference with C++?

If you free obj, all copies will be inderterminate, or at best have a trap rep, cant load, store, or deref
this has been since C99, been there for a long time

for concurrent programming ,  this is too restrictive

Use after free bugs
have the free fn invalidate the pointer, std says you can do that, useful for diagnotics
enables some optimizations,
if compiler can see ptr has it lifetime ending, then can kill one of the branch, just use the else clause
Also future hardware can also traps on the load

ptr becoming indeterminate when obj lifetime ends in C (when you use storage free and when stackframe dies),, can we have a motivating use case for that

LIFO is old since 1973
classic algo push stuff on the stack
then atomically pop things off the stack and operate on it
set the next ptr, if we fail then try again
as soon as we load the value on the stack, this can become indeterminate

list_pop_all, get old value, just before excahnage, might get top of stack and then we delay
we sequence through the stack, capture next ptr, calls foo on it
now copies of p and all ptrs to it become indeterminate
after p
sets p to next
as long as you dont mind having work done in reverse order, all you want to compare the pointer

This should not work in C++, but some implementations might make it work

Niall says only trap derefernce then this algo will work fine

if you have additional pointer indirection, it could work, but will not scale and invalidate decades of concurrent algo

if you coincidentally retrieve the same address, so spec use this death trap to prevent impl from creating new memory, otherwise stack's won't work

Niall: I vaguely remember somebody on WG14 has a C compiler implementing the trapping pointer thing. I thought it only traps dereference though, so basically it's the same as setting all pointers to end of lifetimed objects to null (though they don't do that)
In fact, the guy explained it that pointers get set to something like NaN, so a non-bit-equal trap value

HT: if you compare ptrs, have to chaneg what compare means, between addr of old and new object, for this to work to what people want, then have to change spec to say what you want,
needto change definition of equality, if one or more ptr is to a lifetime end of object, then it would have to be ok, to give a false positive equality comparison
might not be a problem for C++

Niall:I thought the comparison of pointers of differing provenance is in the proposed new C memory model? So, specifically, pointer to alive never compares equal to pointer to dead?

Please post to Wg14 and C++ parallel mailing list

No one objects to moving forward with some intermediate solution that is not the status quo for C.

Move forward for C++: because invalid ptr value is the same case for C++, C++ says its implementation defined
to have it reliably work, then we need to do this, so we can do more with invalid ptr values

Possibly the same wording, equality compare offer false positive, introduce the idea of address space and say invalid ptr value just represents an address
its ok to say they are not equal when they are

make this work for distinct source code, there is push back
existing source code using these algo needs to continue to work, because our civilization depends on it
if impl change in a place where behaviour is undefined, then change would only affect use cases in that category

we can check the behaviour of implementations

Jens M: I've been told multiple times that (equality) comparisons are not in scope of the "provenance" papers.

2 ptrs that compare equal mght be same type, but in C++, can placement new replace object in same storage,
ptr to old object, ptr to new object, same type, they will compare bitwise identical
but those pointers are not interchangeable, because the object is not there any more,
this is why storage duration and lifetime, is more distinct in C++ then C

so const member can have different values on these things, old ptr can retain old value, but might see the new value as well

stack auto variable can return null

if you are happy to split difference between stack vs heap, this is the solution based on storage duration
this might invaldate some algorithms but we dont know what those are











 

2.2.3 Linear Algebra update from April 3rd

Next call: May 1 3 PM ET

2.2.4: Any serious study on cost of Exception vs cost of Error Codes


2.2.5 any other proposal for reviews?



2.3 Domain-specific discussions

2.3.1  Embedded domain discussions: Ben Craig, Wooter and Odin Holmes
2.3.3  Games Domain: John McFarlane, Guy Davidson and Paul Hampson
2.3.4  Finance Domain: Carl Cooke, Neal Horlock, Mateusz Pusz and Clay Trychta

2.4 Other Papers and proposals


2.5 Future F2F meetings:

2.6 future C++ Standard meetings:

https://isocpp.org/std/meetings-and-participation/upcoming-meetings
  • 2019-07-15 to 20: Cologne, Germany; Nicolai Josuttis
  • 2019-11-04 to 09: Belfast, Northern Ireland; Archer Yates

  • 2020-02-10 to 15: Prague, Czech Republic
  • 2020-06-01 to 06: Bulgaria
  • 2020-11: (New York, tentative)
  • 2021-02-22 to 27: Kona, HI, USA

3. Any other business 
Reflector
https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!forum/sg14
As well as look through papers marked "SG14" in recent standards committee paper mailings:
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/

Code and proposal Staging area
https://github.com/WG21-SG14/SG14
4. Review

4.1 Review and approve resolutions and issues [e.g., changes to SG's working draft]

4.2 Review action items (5 min)


5. Closing process


5.1 Establish next agenda 

May 8


5.2 Future meeting

Apr 17: todays call
May 8
June 12: June 17 mailing deadline
July 10: likely cancelled due to Cologne Meeting July 15

_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/sg14