_______________________________________________meeting minutes by michaelOn 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 MonthlyTime: 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
Yes1.3 Approve minutes from previous meeting, and approve publishing previously approved minutes to ISOCPP.org
Yes1.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 hostedSummary of freestanding evening session discussions
http://wiki.edg.com/bin/view/Wg21kona2019/SG14FreestandingImplementationswe did do polls on library stuff, added EWG, LWG, outside of SG14 SG11. add library feature to FS subset that dont use troublesome: 11/11/5/0/12. same as 1 but adds eh: 3/12/7/4/1strongly 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 libraryhave 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 topif 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 neededwhat 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 rangelot of neutrals on this pollMake calls to potentially-throwing library functions ill-formed. (7/6/10/1/2)dont provide std array atMake 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 statementMake 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++23every meeting I had to update the paper, like a giant merge conflictso split P0829 into multiple small papersupdating our editorial technique so other papers in flight can ride alongalso touch on feature testing macroscore language side: have exception as the most important but most contentiouswill discuss next monthteh size cost of ehreturn value is smaller costsby Belfast, plan for an exception runtime paper to show happy paths to start providing more paperoperator new and delete a paper on that through ewg, this seems one of the easier one to acceptthis will say dont require allocating form of op new and delete, you can provide your own just like you can todayby default they are not required to be thereHerb 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 clausemake code with throw statements compilable, but make it no differentAW: yes when std library throws eh, what is semantics, then semantics does not change,upshot is you can compile these librariesBC: must meet same requirement as on hosted implementations, so in those mode they would provide an array atHT: 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 unwindso there is still burden for implementor imvestigationI know GCC documents throwing with no catch does not unwind stack, clang might unwindJW: this could force them to all do it the same waycould be whether they use libunwnd or libgcc_ehor it could be the type info is not properly encoded when they have noexcept fn calling something that is noexcept codeOutcome 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 requiresBut there are other possible directions* Freestanding should be as small as possible* Freestanding has all the same core language features as hostedNov Evening Session: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1376r0.html2.2.2 Pointer Provedence:Pointer Provenance. I know this is a WG14 paper. But there is now interest in following this with a WG21 paper.
push from cambridge, peter Sewell's team trying to formalize C MM mathematicallyChandler opposedSG12 did more work work with C, Han did most of the liasion,also was at Euro LLVM, this is Niall's interpretationif object;'s lifetime, all conforming impl may have all pointers pointing at that object invalidif you new an item using placement new, then reuse that address, previous pointers are invalid, new pointers to the new object is validthese 2 ptrs can potentially equal, and this can cause problemsthe rationale behind std launder which can point to an area to tell lifetime is not what the compiler expectsC is now bringing this into their standardhopefully get reconcilliation between the 2compare equal and substitute one for the other are 2 different thingszap pointer life timeare they bitwise identical if pointed to the same objectN2369:History on why we set it this wayWhat 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 bitsdifference 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 derefthis has been since C99, been there for a long timefor concurrent programming , this is too restrictiveUse after free bugshave the free fn invalidate the pointer, std says you can do that, useful for diagnoticsenables some optimizations,if compiler can see ptr has it lifetime ending, then can kill one of the branch, just use the else clauseAlso future hardware can also traps on the loadptr 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 thatLIFO is old since 1973classic algo push stuff on the stackthen atomically pop things off the stack and operate on itset the next ptr, if we fail then try againas soon as we load the value on the stack, this can become indeterminatelist_pop_all, get old value, just before excahnage, might get top of stack and then we delaywe sequence through the stack, capture next ptr, calls foo on itnow copies of p and all ptrs to it become indeterminateafter psets p to nextas long as you dont mind having work done in reverse order, all you want to compare the pointerThis should not work in C++, but some implementations might make it workNiall says only trap derefernce then this algo will work fineif you have additional pointer indirection, it could work, but will not scale and invalidate decades of concurrent algoif you coincidentally retrieve the same address, so spec use this death trap to prevent impl from creating new memory, otherwise stack's won't workNiall: 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 valueHT: 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 comparisonmight 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 listNo 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 definedto have it reliably work, then we need to do this, so we can do more with invalid ptr valuesPossibly the same wording, equality compare offer false positive, introduce the idea of address space and say invalid ptr value just represents an addressits ok to say they are not equal when they aremake this work for distinct source code, there is push backexisting source code using these algo needs to continue to work, because our civilization depends on itif impl change in a place where behaviour is undefined, then change would only affect use cases in that categorywe can check the behaviour of implementationsJens 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 identicalbut 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 Cso const member can have different values on these things, old ptr can retain old value, but might see the new value as wellstack auto variable can return nullif you are happy to split difference between stack vs heap, this is the solution based on storage durationthis might invaldate some algorithms but we dont know what those are2.2.3 Linear Algebra update from April 3rdNext call: May 1 3 PM ET2.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 Trychta2.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. Review4.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 agendaMay 8
5.2 Future meetingApr 17: todays callMay 8June 12: June 17 mailing deadlineJuly 10: likely cancelled due to Cologne Meeting July 15
SG14 mailing list
SG14@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/sg14