Note to me: 215 seems to be a Lynn-special Draft Agenda for J3 Meeting 217 1. Monday, October 15, 2018 8:00 am ------------------------------------------------------------------------- 1.1 Opening business D. Nagle Remarks from the chair D. Nagle J3's deep sorrow at passing of long-time member, Stan Whitlock. Prosecute the work list. Subgroups should get requirements, use cases, as far as possible for syntax. Adoption of agenda D. Nagle Jon/Steve UC Approval of Meeting 216 minutes D. Nagle Gary/Tom UC INCITS report (if any) D. Nagle One thing for Thursday afternoon; Do we want the 2 TS's to continue IEEE/754 report (if any) R. Corbett Currently chaired by David Hough. New editor is Mike Cowlishaw. Mission statement: to be completed by 2018 to avoid reaffirming old standard. No major new features, but minor features include augmented arithmetic. Current status: email ballot in August froze the technical content; all changes are supposed to be editorial. One can join the ballot committee (for $56/$252 fee). One late feature is recommendation that language standards include a mapping of IEEE operations to language features. Possible tech change: C standard does not quite conform to current IEC doc, and wants a change to IEEE to make C conformant. WG23 report (if any) D. Nagle Published a new rev out for draft with new C, Ada annexes. Starting soon, Dan will be able to work on the Fortran annex. MPI Liaison report (if any) B. Long From the June, 2018 MPI forum meeting: The biggest news at the MPI Forum in Austin: (1) persistent collectives passed its first vote, (2) a limited subset of ULFM might make it into MPI 4.0, and (3) the accelerated schedule for MPI 4.0. (March, 2020). Virtual meetings are already being used to speed up working group discussions, and we discussed an extra in-person meeting each year until MPI 4.0 is published. The hybrid working group discussed 5 issues: Clarification of "process" in the MPI standard. This requires reviewing the entire MPI standard and making any necessary changes to any text containing the word "process". Pavan asked if anyone was willing to help with this effort. No one volunteered. Detecting if there are more than one MPI processes in an OS process. Support for per-object locks. User visible endpoints. It was generally agreed that user-visible endpoints aren't a performance win. Most people decided that "wait-and-see" was the best path to take for user-visible endpoints. Modified/new thread support levels. The sessions WG still wasn't entirely sure what sessions are, or what we should call them ("instances", maybe?). Nonetheless, the goal was to start writing some of the standard-ese for sessions. We managed to write the prototypes for MPI_Session_init and MPI_Session_finalize. Here's the result: MPI_Session_init( INOUT MPI_Flags *flags, IN MPI_Info info, IN MPI_Errhandler errhandler, OUT MPI_Session *session) MPI_Session_finalize(INOUT MPI_Session *session) Session initialization is intended to be local, but there was some discussion if this is the right path to take. James Dinan argued that it's more efficient for all ranks to be wired up at the beginning of the job. MPI_Session_finalize is not collective (although there was some discussion about this). However, it can block waiting for destruction of objects derived from the session handle. The collectives working group discussed an info key that would force persistent collectives to start in order across the communicator. This could be useful for implementing persistent collectives using hardware support for collectives. The fault tolerance working group generally agreed that ULFM needs to be broken into four pieces. The first three most people like, but the fourth is controversial. 1) general definitions --> process failure, changes to existing functions 2) failure notification/discovery --> MPI_ERR_PROC_FAILED, MPI_COMM_FAILURE_ACK/GET_ACKED 3) fault tolerant agreement --> MPI_Comm_agree 4) failure recovery [contentious, need to address composibility concerns] --> MPI_Comm_shrink, MPI_Comm_revoke The first three parts are likely to make it into MPI 4.0. MPI 4.0 is expected to be ready by March 2020 (assuming we consistently meet quorum, continue virtual meetings, and maybe add an extra in-person meeting). MPI 4.0 is expected to contain: - persistent collectives - large count - (maybe) MPI_T events - (maybe) "create from group" functions for sessions - (maybe) FP16 OpenSHMEM report (if any) B. Long Nothing this meeting OpenMP Liaison report (if any) B. Long Since last June, the OpenMP language committee released a comment draft and have been primarily in quality control mode for the spec. There are some last minute changes that have gone in: (1) Fixes for mapping Fortran array sections based off of pointers on device constructs (2) Some added combined taskloop constructs for usability (3) Some changes to how declare variant works (the directive now goes on the base function and specifies different variants to be used depending on the context in which the base function is invoked). Removed "implements" clause from declare target, since declare variant now provides that functionality. (4) OMP_NESTED, omp_set_nested, and omp_get_nested now use the same internal control variable as OMP_MAX_ACTIVE_LEVELS. Other than that, there was a F2F meeting last week that included some more discussions on future directions. The final draft for OpenMP 5.0 is currently being prepared for a final vote by the OpenMP ARB, and should be publicly released at SC'18. UPC Liaison report (if any) B. Friesen GasNET-ex still getting support from DoE, otherwise little or no new development. There will be a workshop at Supercomputer on this. OpenACC Liaison report (if any) G. Klimowicz Information about OpenACC, including the current standard document, training materials, and upcoming events can be found at http://www.openacc.org/. The current OpenACC 2.6 standard includes support for manual deep copy of data structures to target processors. There are over 110 applications in production or development using OpenACC, including: - Gaussian 16 - ANSYS Fluent - VASP - MPAS-A - COSMO - GAMERA for GPU - Quantum Espresso There is one more "hackathons" coming up in 2018, where researchers bring their codes to work alongside with OpenACC experts to accelerate their applications. Event dates are posted at https://www.openacc.org/events. - ORNL GPU Hackathon October 22-26 There is an OpenACC online course being taught beginning October 18th, 2018. There are three classes planned so far. Experience with OpenACC or GPU programming is not assumed. Date Topic ---------- ----------------------------------------------- October 18 #1 - OpenACC Basics (1 hour lecture and 30 minutes Q&A) October 25 #2 - GPU Programming with OpenACC (1 hour lecture and 30 minutes Q&A) November 1 #3 - Optimizing and Best Practices for OpenACC (1 hour lecture and 30 minutes Q&A) You can register at https://www.openacc.org/events/openacc-online-course-2018. OpenACC is working on version 2.7: Things they really want to get into the spec in the fall: 1. Make it clear that the host can be a device. 2. Listing which fortran intrinsics and math. h functions should be supported. 3. Fortran bindings for API routines. 4. Treat reduction as a data clause (for parallel loop reduction). 5. Clarify that the host data construct used without "use device" means nothing Two more things they'd really like to get in: 6. Array reductions 7. "acc parallel self" - run this in parallel on the current device We also understand that at the OpenMP face-to-face meeting this fall that the OpenMP group is planning to create a roadmap for how OpenACC constructs are mapped to OpenMP constructs. This would effectively mean that "#pragma acc" would be treated as a new way to spell "#pragma omp" and dramatically reduce the porting problem for codes that used both. Flang open-source report G. Klimowicz Flang is an open source compiler for Fortran, sponsored by the US Department of Energy (particularly, LLNL, Sandia and LANL). The goals of the project are to - Create a new, open source Fortran 2018 compiler with Apache 2.0 licensing, - that can be used for language and parallelization experimentation, - that exists as a peer in the LLVM community of languages, like Clang, - that can rely on LLVM code generation and parallelism support for CPUs and GPUs. The initial version of Flang is derived from the PGI Fortran compiler, with some proprietary features removed (OpenACC support, inter-procedure analysis). It was published on GitHub in May 2017 at github.com/flang-compiler, and consists of several subprojects (including the Flang driver and compiler itself, and changes to LLVM to support Fortran debug metadata to be upstreamed). The current compiler supports Fortran 2003 and some Fortran 2008 features. Recent improvements to Flang include: - Support for SUBMODULE - Support for DO CONCURRENT - Support for internal procedure pointers - Many bug fixes and enhancements from the PGI compiler Flang is available for Linux on x86-64, OpenPOWER and Arm processors, and is the basis of the Arm commercial Fortran compiler. Members of the community are also working on ports to Mac OS X and packages for OpenBSD and FreeBSD. There are flang-dev and flang-announce mailing lists you can join for discussion of Flang at http://lists.flang-compiler.org/ and a Slack channel, http://flang-compiler.slack.com/ for more interactive communication with the Flang community. The Flang project team recognizes that the older code base used to seed Flang is not going to meet the long-term goals of the project, and NVIDIA has begun a new project to rewrite the Fortran front-end in C++ to better align with the LLVM and Clang communities and to better leverage the existing tools and techniques from these communities. This new front-end, which we call F18, is available at https://github.com/flang-compiler/f18. All development for F18 is being done on the open source repository, and you can follow the pull request activity from our developers there. We delivered two webinars introducing F18 tot he Flang, Clang and LLVM communities in July. The recording for the second webinar (slightly expanded from the first) can be found at https://nvmeet.webex.com/nvmeet/ ldr.php?RCID=8b42b4ab49dec35519867c7fea8719e0. We are currently working on declaration and type processing, expression evaluation for compile-time expressions, and statement semantics (DO and DO CONCURRENT). We now have enough of the infrastructure for parsing, symbol table, error handling and semantic representation that we encourage developers outside NVIDIA to participate. There is a biweekly half-hour conference call providing status updates on Flang, every other Wednesday at 8:30 AM Pacific time (the next is October 17, 2018). If you are interested in participating in these calls, please let Gary Klimowicz (gklimowicz@nvidia.com) know and he will forward the meeting invitation. WG2.5 Van Had meeting in Sydney after last WG5 meeting. WG9 Van Meeting next week. Responsible for 7 docs; one is language standards, plus 6 other standards. Working on 202x standard. Papers 18-261 and 18-261r1.pdf are the agenda for the next meeting Beginning Treasurer's report J. Steidel No expenses since February, and so the balance is still: $2683.36 We are unable to get PayPal, but INCITS can directly bill for meeting fee, for those committee members who are otherwise having problems with internal accounting. Motion to waive meeting fee at 218 & 219 [Steidel/Snyder) Unanimous consent (UC) Beginning membership report L. Menard 12 Voting members (the usual suspects) plus one prospective member; OakRidge. They have paid, but their representative needs to be a visitor once. In attendance: Corbett Robert Corbett Cray Inc Bill Long IBM Corporation Daniel Chen Intel Corporation Lorri Menard, Jon Steidel Jet Propulsion Laboratory Van Snyder Kernelyze LLC * Lawrence Berkeley National Laboratory Brian Friesen Lionel Steve Lionel, Malcolm Cohen, Vipul Parekh NASA Tom Clune National Center for Atmospheric Research (NCAR) Dan Nagle NVidia Corporation Gary Klimowicz Oak Ridge National Labs * United States Dept of Energy Damian Rouson, Craig Rasmussen 11 represented here by 15 people Possibility that Craig can become alternate to Oak Ridge; Craig to contact David E. Berhnoldt. Local arrangements D. Nagle If you have any requests for meeting-snacks, please let Dan know before lunch, as he will be stocking up then. J3 is good thru EOY2019 with this hotel, may change to different venue after that due to so many issues (they've thrown away many items from the storage-tub we've left here for years; they can't find the contract) Comments from members 1.2 Tutorials (if needed) Not a tutorial per se, but Dan and Malcolm explained what our goal is for this meeting. We have a worklist of topics (18-010) many of which already have explanatory papers, and some are still needed. There also have been some papers submitted for other features to be considered for F202x. The goal for this meeting and next is to process all the existing papers, and to update 18-010 with the set of features that J3 proposes to Wg5 for consideration at the next joint meeting in June 2019. For these purposes, "passing a paper" means that it will go forward for consideration and renovation, not that it is guaranteed to be in the next standard, in the exact form it was described in the paper that passed. 1.3 Subgroup organization D. Nagle /JoR Dan Nagle (head) Steve Lionel, Gary Klimowicz, Lorri Menard Initial papers: 18-238,18-242,18-243,18-247,18-248,18-249,18-253,18-257, 18-258,18-259,18-266,18-268 /Data Malcolm Cohn (head) Van Snyder, Tom Clune, Bob Corbett, Craig Rasmussen, Damian Rouson 18-237,18-239,18-240,18-241,18-244,18-245,18-254,18-255, 18-256,18-260,18-265 /HPC Bill Long (head) Brian Friesen, Daniel Chen, Jon Steidel 18-246,18-264,18-277,18-280,18-281 /Edit: No plan to meet 18-267 /Interp: Malcolm Cohen Recessed to subgroup at 9:00 1.4 Subgroup meetings 1.5 Subgroup reports (4:30 pm) /JoR For vote tomorrow: 18-238r1, 18-253r1, 18-266r1, 18-268 No action on: 18-242 "Irregularities (index variables)" Seemingly syntax-sugar change would have semantic effect. No value seen. 18-243 "Medium-grain parallelism" This topic not on work list Some features interesting; essentially vector subscripts 18-248 "Supporting rank variability" No action; no need to add something we can already do 18-249 "Supporting generic programming" No action; no use cases /Data 18-237 "Asynchronous Procedure Execution" no action because existing parallel tools, posix or OpenMP, do an excellent job. 18-239 "logical short-circuits" No action on this paper because 13-234 is an improvement on this, and will reappear as a new paper. 18-241 "(DIN) Persistency option for dummy argument attributes" Subgroup has been studying, no comment yet 18-240r1 "On the semantic options for templates/generics" Subgroup has spent much time with this, no comment yet 18-254 "real-complex interoperability" No action on this paper; will be replaced by one with an example of using c_f_pointer. /HPC 18-246 "Synchronizing variables" No action; to be considered as part of 18-237 18-264 "Inconsistencies between LOCAL and BLOCK" There is a 18-264r1 in main folder, to be transfered to /Interp 18-267 "Syntax errors in example codes" No action this meeting, but will hang onto the paper. This points out two simple typo errors in examples, but this is not the meeting for typo changes /Interp 18-264r1; no action Adjourned for the day at 5:00PM 2. Tuesday, October 16, 2018 8:00 am --------------------------------------------------------------- 2.1 F202x Plenary (13-010) Subgroup Heads /JoR 18-238r1 "Minimum-width Character Format" [Nagle] ** Motion to continue working on this feature (Nagle/Lionel) Discussion: Malcolm says too many issues as it is; the change to G0, inconsistency with other '0', etc. Vote: 6 to continue 2 do not continue rest undecided, and motion carries. 18-253r1 "line length and/or statement length" [Nagle] ** Motion to continue working on this feature (Nagle/Clune) Discussion: Malcolm: Max token length is more interesting. In principle, good idea Bill: Suggests reasonable limit on line length, with more continuation lines. Bob: #include "filename" can easily exceed a line. Suggests no line limit in freeform. Craig: truly needed. Motion carried to continue working on this feature. 18-266r1 "Add reductions to DO CONCURRENT" [Klimowicz] (Nagle/Klimowicz) ** Motion to continue working on this feature (Nagle/Klimowicz) Discussion: Malcolm: Better if limited to +,*. Tell the processor what the reduction is. Bill: Typo/technical problems with paper Tom: Never used multiply, only plus. Daniel: Have the operator, finite number. Craig: Look to OpenMP and their experience Damian: Temp arrays have performance hit. Van: Why can't we be consistent with REDUCE intrinsic Motion carried to continue working on this feature. 18-268, "Control of leading zero in formatted numeric output" [Lionel] ** Motion to continue working on this feature (Nagle/Lionel) Discussion: Bill: Possibly useful. Skeptical it solves actual problem, due to fp diffs. Bob: Yes, especially for list-directed and namelist. Malcolm: Useful for F0 format output. Van: Some languages require the leading zero. Motion carried to continue working on this feature. /Data No papers for this morning /HPC No papers for this morning /Interp No papers for this morning 2.2 Tutorials : Craig Rasmussen led a discussion about the Future of Fortran HP Scientific applications. Doesn't seem like people know about Fortran anymore. Long discussion about putting TASKS into Fortran, so that GPU's could be used more effectively. 2.3 Subgroup meetings 2.4 Subgroup reports (4:30 pm) /JoR For vote and/or discussion tomorrow: 18-238r2, 18-253r2, 18-257r1, 18-259r1, 18-266r2, 18-272, 18-273 /Data 18-263 "Construct association in an ASSOCIATE construct" No further action as section 19.5.1.6 covers it. 18-239 "logical short-circuits" No further action because superceded by 18-274 18-274 "If-then or else" for vote tomorrow 18-241 "Persistency option for dummy argument attributes" no further action, 18-271 is response. 18-244 "Irregularities (associate names)" no action, no response 18-254 "real-complex interoperability" no further action, response is 18-275 /HPC No papers for tomorrow; if you want a preview, peruse the HPC folder /Interp For vote tomorrow: 18-236r1, 18-251r1 Adjourned for the day at 5:00PM 3. Wednesday, October 17, 2018 8:00 am ---------------------------------------- 3.1 F202x Plenary (13-010) Subgroup Heads /JoR ** Motion 18-238r2 "Minimum-width Character Format" [Nagle] (Nagle/Lionel) Discussion: Malcolm: Detest changing G0, trailing blanks part of value With G0 should strip leading blanks too Van: More details with G0 (put up front) Jon: Doesn't like G0/A0 meaning two different things and doesn't like G0 changing. Motion amended that A0 becomes AT, and G0 stays the same. Motion as amended: UC ** Motion 18-253r2 "line length and/or statement length" [Nagle] (Nagle/Lionel) Discussion: Bill: Number of continuations is wrong. Van: Should it say "at least 10K". Which "10K" Malcolm: Source form is in processor character set, not related to any particular character kind max line length shall be processor dependent, but processor limit shall not be less than 10K Motion amended to specify default characters and that maximum line length be a minimum of 10K although processor may extend that. Motion passed as amended: UC ** Motion 18-257r1 "log and friends" [Nagle] (Nagle/Menard) Discussion: Malcolm: first paragraph wrong, because it is possible, just cumbersome 8-bit should say logical with storage size of 8 bits Damian: Can we use LOGICAL rather than LOG Motion amended to address these two concerns. Motion passed as amended: UC ** Motion 18-259r1 "part 2 functions as amended" [Nagle] (Nagle/Klimowicz) Straw vote: Do the functions listed in the paper as: Intrisics - intrinsic module procedures - don't do - no opinion 1 11 1 2 Discussion: Malcolm: Not removed; no longer being maintained. Bill: Add option to straw vote to not do at all Malcolm: Make generic. There are some useful things in the I/O, particularly with alloc strings on input Or, have an ANNEX with option Vipul: Industry would like more string functions. Motion passed as amended per the straw vote above: UC ** Motion 18-266r2 "Add reductions to DO CONCURRENT" [Klimowicz] (Nagle/Rousson) Discussion: Jon: Add XOR to the list to be consistent with OpenMP Want the semantics to be similar to local_init not shared, and partial results are combined at end of loop. Daniel: Not shared. Don't allow derived type. Damian: Would like to see derived types as part of this, with user-defined operators. For example, also add derived types to SUM intrinsic. Malcolm: Add iand, etc Van: Make consistent with REDUCE intrinsic, in particular the operator-function Daniel: Syntax doesn't match OpenMP (operator:sym) Van: should it be in parens to be consistent Jon: Spoke out against magic initializations, and carry initial value in. Malcolm: Not really magic, just identity value. Besides, you don't add the initial value N times, only once. Jon: OpenMP allows arrays; do we want to keep it scalar? Malcolm: Yes. Gary: Yes. Daniel: Can there be allocatable scalars? Malcolm: Yes, but it must be allocated outside, and is not allowed to be alloc/dealloc inside DO CONCURRENT Dan: Do we want to go thru the straw votes? Straw votes: 1: Do we add more operators? YES Add bitwise, logicals 2: Do we restrict the form of the expression to: variable = variable oper YES 3: Do we allow multiple reductions per DO CONCURRENT. YES 4: Do we allow something more general? NO 5: Do we allow just scalar and elemental array reductions? YES Motion was withdrawn for rewrite. ** Motion 18-272 "Degree trigonometric functions" (Nagle/Menard) Discussion: Malcolm: Typo in use cases; remove everything after "degrees" Also, is it worth adding SINPI, COSPi, ATANPI, ATAN2PI which are in IEEE standard recommended function list. Bob: degrees are used more than SINPI (and friends) Bill: wants this. Straw vote: Do we add the "pi" functions? Yes No Undecided 10 0 5 Motion passed as amended per the straw vote: UC ** Motion 18-273 "virtuous procedures" [Nagle] (Nagle/Clune) Discussion: Malcolm: maybe SIMPLE as the placeholder. Bob: Rounding mode might change results; note this is a global state Craig: When hears PURE thinks attributes of function. Would prefer "stacked" attributes, like SIMPLE PURE or STRICT PURE Damian: "purely functional" googles to "deterministic". Malcolm: If we have a placeholder that is not acceptable, it will be a distraction, and proposal will die. Discussion of candidates for term (may vote for multiple) LOCAL PURE : 3 SUPER PURE : 3 STRICT PURE: 9 SIMPLE PURE: 11 Straw vote on the top two choices (vote for one) SIMPLE STRICT 7 8 Motion passed as amended, and with the comment that ERROR STOP would be allowed. UC /Data Discussion 18-274 "If-then or else" [Cohen] Dan: Possible to do this with MERGE? Bob: Oracle does it already Steve: Sympathetic to keyword version, but it's awkward and like COBOL. Van: Interns come in and understand verbose form even with Java or Python background Bill: What's obvious depends on who's looking. The keyword version looks like a mistake. Van: This is a block-if with a value. Malcolm: Line-noise version is compact. Keyword is verbose. Vipul: use a { instead of (? since it looks like what a person would write Damian: Vote for MERGE (retracted) Dan: Can make MERGE special by adding an argument Gary: Proposed something combined keywords and line noise. Straw vote: Continue to develop conditional expressions yes no undec 13 0 1 Favors keywords vs line noise KW LN Undec 6 5 3 Subgroup has direction. 18-254 "real-complex interoperability" no further action, response is 18-275 /HPC No papers, no business. /Interp For vote this afternoon: 18-236r1 ACOSH result value error/typo F18/0001 18-251r1 Are internal procedures allowed in generic interface blocks F18/0002 3.2 Tutorials (if needed) 3.3 Subgroup meetings 3.4 Subgroup reports (4:30 pm) Report from meeting with Valerie: It looks feasible to move to a different Marriot property here. Two contenders are the Residence Inn across the street from where we are, and Springhill, down past the convention center. Valerie will be meeting with her financial guys to set prices; GSA is our upper limit. /JoR For vote tomorrow: 18-258r1, 18-266r3, 18-276, 18-278, 18-279 /Data 18-262 is being transferred to /Interp 18-271 "Response to 18-241" [Cohen] is an info paper 18-275 "real-complex interoperability" [Cohen] is an info paper /HPC For vote tomorrow: 18-277, 18-280, 18-281 /Interp For vote tomorrow: 18-262r1 From this morning: 18-236r1 "ACOSH result value error/typo F18/0001" [Shterenlikht, Cohen](Cohen/Snyder) As amended; UC Malcolm has post. 18-251r1 "Are internal procedures allowed in generic interface blocks F18/0002" [Steidel](Cohen/Steidel) Passed UC Recessed for the evening at 5:00 4. Thursday, October 18, 2018 8:00 am --------------------------------------- 4.1 F202x Plenary (13-010) Subgroup Heads /JoR ** Motion 18-258r1, "cstring-fstring" [Nagle] (Nagle/Lionel) Discussion: Bill: two blocks with same label; one should be C->Fortran Part 3, end of second line CHAR(0) should be C_NULL_CHAR Malcolm: doesn't like c_f_string. MAXLEN is an invitation to to buffer overflow; maybe OK as optional. For c_f_string, allow either char-array or c_ptr Suggestion: Return a char(:),pointer Bill: In this situation, making copies is not a concern, because this won't be in performance-sensitive code so making a copy is not a problem. Van: If have both array and cptr, prefer to have result be the same for both styles. Malcolm: If you want to make a copy, need to remember to delete it, copy it again to pass back to C and add trailing null, etc etc Van: String argument doesn't specify what type (only kind) Vipul: Dangers to returning pointers. Malcolm: Look at C_LOC/C_F_POINTER Motion withdrawn for further work in subgroup ** Motion 18-266r3 "Add reductions to DO CONCURRENT" [Klimowicz] (Nagle/Klimowicz) Bill: Cosmetic: Reference might be 18-007r1(but doesn't matter) Use cases: first example, has comment. Second example has same comment but could be done with minval. Daniel: use "reduce" or "reduction". No big push to do so, so keeping it. Malcolm: "all bits on" is NOT zero, so use that instead. As amended; UC and Gary has the post. ** Motion 18-276 "IEEE pi trigonometric functions" [Menard] (Nagle/Menard) Bill: Want to give the equations in the paper. Van: Numerical analysts will like it because it will be more accurate. Bob: ATAN is now 1 or 2; should we actually do ATAN2 Tom and Bob to check; as amended UC Lorri has post. ** Motion 18-278 "sign of zero on write" [Corbett] (Nagle/Corbett) Bob: Is this just for floating? If so, can you use float numbers in discussion. What's the difference between SS and ZN; we already have something with signs. Malcolm: Zero-sign mode. Steve: Recommend that specifier be signed-zero to go along with lead-zero (Malcolm won) As amended: UC Bob has post ** Motion 18-279 Extending usability of deferred-length strings [Clune/Lionel] (Nagle/Lionel) Bill: found the "unallocates" Malcolm: Don't remember discussing in data Van: Is it a problem with generics? Malcolm: Ambiguous with insufficient length (2.1) suggestion change "insufficient" with 'different" Problem if out-of-memory Bill: Difference between internal write and errmsg Dan: His RT guy doesn't think the functionality would fly Tom: The internal write is most important to him. Dan: Break into two? Internal write and everyone else. Malcolm: Fix the missing right paren in ALLOCATE example Add piece at end saying that WRITE could be separable and recommends the rest. Maybe in section 3, add paragraph that says a user program that wishes to avoid overhead by this functionality by simply using (:) on the name of the variable. As amended: UC Steve will rewrite, and has post /Data 18-256r1 for this evening (enums) /HPC ** Motion 18-277 "Put with notify" [Steidel] (Long/Steidel) Malcolm: Understand difference between EVENT and NOTIFY types Lorri: Can notify-wait be done in a PURE subroutine? Tom: Timing Jon: Notify/wait/until_count is there an issue with someone posting events to the same variable As amended: UC Bill has edits&post ** Motion 18-280 "Constraint C825" [Filippone/Rouson/Long] (Long/Clune) Van: Quote at beginning, and suggestion to remove constraint. Do you really just mean to simply remove allocatable from constraint? Malcolm: Will have to go thru all references to coarray to make sure that this change doesn't affect it. As amended: UC Bill has post ** Motion 18-281 "Templates" [Long] (Long/Steidel) Tom: Not really like C++ Vipul: Use case only talking about templating from kind point of view. More like the swap function (Malcolm says that's a toy) More use cases may reveal what really trying to Tom: Use cases have been submitted. Add to 010 doc so we can find it. Is it the intent that this will be expanded to template type Is it the intent that a template function can return a different type Plug for conditionals; do this if not character (for example) Some sort of looping mechanism, or rank-based Dan: Likes the approach; wants to understand what generic we have now Malcolm: Kind of array already works, don't invent something new Vipul: To do STL need to have all pieces there. Learn from C++ and C# Amendments: Spelling, suggestion of KIND, insert email from Paul Thomas As amended: Vote to keep on the pile: UC Bill to do post /Interp For vote this afternoon: 18-262r1 4.2 Tutorials (if needed) 4.3 Subgroup meetings 4.4 US TAG (4:15 pm) IR Company Cinterop Parallel Features ----------------------------------------------------------- Corbett y y Cray Inc y y IBM Corporation y y Intel Corporation y y Jet Propulsion Laboratory y y Kernelyze LLC not present not present Lawrence Berkeley National Laboratory y y Lionel y y NASA y y National Center for Atmospheric Research y y NVidia Corporation y y Oak Ridge National Labs not present not present Sandia National Labs y y -------------------------------- 11 votes 11 votes 4.5 Subgroup reports (4:30 pm) /JoR ** Motion 18-258r2, "cstring-fstring" [Nagle] (Nagle/Lionel) UC /Data 18-240r1 "On the semantic options for templates/generics" [Clodius] Thank you for the background, no action on paper 18-260 "Generic programming in future Fortran" [DIN] Thank you for input and background, no action on paper 18-245 "In support of containers" [Snyder] Discussion about generics; prefer named parameters rather than magic Thank you for input, no action on paper 18-255 "new types from old" [Nagle] No action, understand the desire but contradiction between different bits; generic resolution would be ambiguous, intrinsic operators interconnect in interesting ways (math functions, intrinsics, etc) 18-265 "Protected components" [Long] Didn't get to it; deferred to m218 18-256r1 "enums" [Nagle/Cohen] (Cohen/Snyder) Discussion about scope of names: Jon: what is the scope of the names of the enumerators. If we go with scope of e-type, then there is less interference with user namespace Tom: Can enumerators be public? Given type e_type enumerator e_one, e_two, e_fred end type e_type type(e_type)x Straw vote: Which name is accessible a) e_fred b) e_type%e_fred c) both a and b d) undecided A - 3 B - 5 C - 5 D - 2 Do we move forward with it? UC /HPC No papers for tomorrow /Interp; something to vote on ** Motion 18-262r1 "Pointer association of component of non-definable selector" F18/0003 [Snyder] (Cohen/Snyder) As amended; UC 5. Friday, October 19, 2018 8:00 am -------------------------------------- 5.1 F202x Plenary (13-010) Subgroup Heads /JoR 18-258r2 "cstring-fstring" (Nagle/Lionel) UC 5.2 Closing business 5.3 Review of action items (if any) - Secretary to forward our tag vote (Done 10/18 in the evening) - Hotel saga: Exchange of email since yesterday, salesrep has come back and said "Sorry, please give a $ estimate for how to make things right" Van to forward a list of missing stuff with an estimated price to the manager. 5.4 Future meetings D. Nagle m218 Feb 11-15 2019 Craig Rasmussen m219 Aug 5-9 (Tokyo) m220 Oct 14-18 2019 Van Snyder m221 Feb 10-14 2020 Jon Steidel 5.5 Treasurer's report J. Steidel 15 Oct 2018 Opening balance $ 2682.36 17 Oct 2018 Meeting fees 700.00 ------- Subtotal $ 3382.36 18 Oct 2018 Fairfield Inn - 0.00 ------- 18 Oct 2018 Closing balance $ 3382.36 Meeting fee waived for m218, m219 5.6 Closing membership report L. Menard No memberships in jeopardy. => Remind Craig to contact David Bernholdt 5.7 Comments from members Lunch at Gordon Biersch; still have 10% off coupons at the front desk. Meet at 11 in the lobby. Adjournment 8:30