From sourav0311 at gmail.com  Thu Aug  8 07:10:35 2019
From: sourav0311 at gmail.com (Sourabh Singh Tomar)
Date: Thu, 8 Aug 2019 16:40:35 +0530
Subject: [Flang-dev] GDB reporting Cannot access memory for formal arguments
 FLANG
Message-ID: <CAN-SHprwqWRknhMEidBmb7mtByYQQgjS1a4mgv81cFY-HjbBkA@mail.gmail.com>

Hello Everyone,

I was working on issues with debug information in FLANG, struck in a issue
Test case:
 subroutine sub(a,b,c,d,e)
                integer a, e
                real b
                double precision c, a_s
                character (len=1) d
                a_s = b + e
                e = e + c
        end
        program main
                integer a
                real b
                double precision c
                character (len=1) d
                integer arr(4)
                arr(4) = 21
                a=789
                b=2.0
                c=3.d0
                d='S'
                call sub(a,b,c,d,arr(4))
        end

When, putting  a breakpoint at subroutine sub and running the program.  GDB
emits  --
Breakpoint 1, sub (a=<error reading variable: Cannot access memory at
address 0xffffe1d000000315>, b=<error reading variable: Cannot access
memory at address 0x31540000000>,
    c=<error reading variable: Cannot access memory at address
0x4008000000000000>, d=<error reading variable: Cannot access memory at
address 0x800000000000053>,
    e=<error reading variable: Cannot access memory at address 0x15>) at
test1.f90:1
1               subroutine sub(a,b,c,d,e)

GDB is not able access subroutine arguments.

.debug_loc section contents

    00000000 00000000002010f0 000000000020113c (DW_OP_breg5 (rdi): 0;
DW_OP_deref)
    00000015 <End of list>
    00000025 00000000002010f0 00000000002010fa (DW_OP_breg4 (rsi): 0;
DW_OP_deref)
    0000003a 00000000002010fa 000000000020113c (DW_OP_breg7 (rsp): -24;
DW_OP_deref; DW_OP_deref)
    00000050 <End of list>
    00000060 00000000002010f0 00000000002010ff (DW_OP_breg1 (rdx): 0;
DW_OP_deref)
    00000075 00000000002010ff 000000000020113c (DW_OP_breg7 (rsp): -32;
DW_OP_deref; DW_OP_deref)
    0000008b <End of list>
    0000009b 00000000002010f0 0000000000201112 (DW_OP_breg2 (rcx): 0;
DW_OP_deref)
    000000b0 <End of list>
    000000c0 00000000002010f0 0000000000201104 (DW_OP_breg8 (r8): 0;
DW_OP_deref)
    000000d5 0000000000201104 000000000020113c (DW_OP_breg7 (rsp): -40;
DW_OP_deref; DW_OP_deref)
    000000eb <End of list>

On analzsing the stack and memory using content of location list, it seems
arguments are their but location list description incorrect.

Can anybody help me with this.

Thanks in anticipation!
Sourabh Singh Tomar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190808/43a892dc/attachment.html>

From robyn.sampson at intel.com  Wed Aug 14 09:36:20 2019
From: robyn.sampson at intel.com (Sampson, Robyn)
Date: Wed, 14 Aug 2019 13:36:20 +0000
Subject: [Flang-dev] Updated paper for today's Flang Community Tech Call
Message-ID: <AF9B80EA7DED3C4BBFE7ACFB3B1AD57C766064F0@FMSMSX126.amr.corp.intel.com>

Attached is an updated version of the paper on Fortran Alias Analysis.  The section on Subroutine Parameter Aliasing has been updated.

Thanks,

Robyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190814/336381ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FortranAliasAnalysis.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 136979 bytes
Desc: FortranAliasAnalysis.docx
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190814/336381ee/attachment-0001.docx>

From Kiran.Chandramohan at arm.com  Fri Aug 16 12:13:25 2019
From: Kiran.Chandramohan at arm.com (Kiran Chandramohan)
Date: Fri, 16 Aug 2019 16:13:25 +0000
Subject: [Flang-dev] Flang Technical Call : Summary of presentation on
 OpenMP for Flang
Message-ID: <AM7PR08MB530368928A2D627CAF5861FC8CAD0@AM7PR08MB5303.eurprd08.prod.outlook.com>

Hi,

This mail is a summary of the presentation that I gave on 31st August about supporting OpenMP in Flang (F18). Link to presentation: https://drive.google.com/open?id=1Q2Y2fIavewq9oxRDruWoi8TaItlq1g9l
The mail follows the contents of the presentation and should be read in conjunction with the slides. It also includes feedback provided during and outside the presentation. It would be great to receive further feedback.

This presentation discusses the design of how OpenMP can be represented in the IR and how it can be translated to LLVM IR. The design is intended to be modular so that other frontends (C/C++) can reuse it in the future. The design should also enable reuse of OpenMP code from Clang (LLVM IR generation, Outlining etc). It should also be acceptable to Flang, MLIR, Clang communities. And most importantly should allow for any OpenMP optimisation desired.

The designs presented uses the following two components.
a) MLIR [3]: Necessary since MLIR has already been chosen as the framework for building the Fortran IR (FIR) for Flang.
b) OpenMP IRBuilder [2]: For sharing of OpenMP code with Clang.

The current sequential code flow in Flang (Slide 5) can be summarised as follows,
[Fortran code] -> Parser -> [AST] -> Lowering -> [FIR MLIR] -> Conversion -> [LLVM MLIR] -> Translation -> [LLVM IR]

Four design plans are presented. These plans add OpenMP support to the sequential code flow. All the plans assume that FIR is augmented with a pass-through operation which represents OpenMP constructs.
Plan 1 (Slide 6)
The first plan extends LLVM MLIR with OpenMP operations. The pass-through OpenMP operation in FIR is converted to the OpenMP operation in LLVM MLIR. The OpenMP operation in LLVM MLIR can be converted to LLVM IR during translation. The translation process can call the OpenMP IR Builder to generated the LLVM IR code.
Pros: Easy to implement, Can reuse Clang OpenMP code.
Cons: Not acceptable to MLIR community [1]. By design LLVM MLIR should be similar to LLVM IR (OpenMP is a form of parallelism. Has concepts of nested regions etc which do not map directly to LLVM IR and hence to LLVM MLIR).

Plan 2 (Slide 7)
In the second plan, LLVM MLIR is not extended. Here the pass-through OpenMP operation in FIR has to be converted to existing LLVM MLIR. This would involve outlining, privatisation etc during the conversion of FIR to LLVM MLIR.
Pros: Easy to implement.
Cons: Cannot be shared with other users (C/C++) and non-LLVM targets (accelerators). Cannot re-use Clang OpenMP code.

Plan 3 (Slide 8)
The third plan defines a separate MLIR dialect for OpenMP. The pass-through OpenMP operation in FIR can be converted to Operations in the OpenMP MLIR dialect. OpenMP specific optimisations can be performed in this dialect. This dialect will be lowered to the LLVM dialect and outlining etc will happen at this time.
Pros: MLIR dialect can be used by other users. Acceptable to MLIR community [1].
Cons: Cannot reuse code from Clang for OpenMP

Plan 4: The proposed design (Slide 9)
The proposed design also involves creating an OpenMP dialect in MLIR. The difference lies in the fact that the OpenMP dialect has some ties to the LLVM dialect like sharing the types and using the translation library of the LLVM dialect. The Fortran IR (FIR) will be lowered to a mix of OpenMP and LLVM dialect. The translation library of LLVM dialect will be extended to create a new translation library which can then lower the mix to LLVM IR. The new translation library can make use of the LLVM IRBuilder.
Pros: Other users (C/C++) can use it. Can reuse Clang OpenMP code. Acceptable to MLIR community [1].
Cons: Has some ties to the LLVM dialect.

OpenMP dialect
The proposed plan involves writing an MLIR dialect for OpenMP. An MLIR dialect has types and operations. Types will be based on the LLVM dialect. Operations will be a mix of fine and coarse-grained. e.g. Coarse: omp.parallel, omp.target, Fine: omp.flush. The detailed design of the dialect is TBD and will be based on what should be optimized. The OpenMP dialect creation in the proposed plan is from FIR, this would require pass-through OpenMP operations in FIR. Another approach would be to lower F18 AST with OpenMP directly to a mix of OpenMP and FIR dialects. This would require that FIR co-exist with the OpenMP dialect.

Next Steps
-> Address feedback provided after the presentation. And reach an agreement on a plan
-> Design a minimum viable MLIR dialect and get community acceptance.
-> Help with progressing the OpenMP IRBuilder.
-> Implement the accepted plan. Implementation would follow a vertical plan (going construct by construct).
-> Represent construct in OpenMP MLIR
-> Refactor the code for the construct in OpenMP IRBuilder
-> Set up the translation library for OpenMP in MLIR to call the IRBuilder
-> Set up the transformation from the frontend to OpenMP MLIR for this construct

Feedback (during the call):
-> Johaness agrees with this proposed plan (Plan 4) and does not see the ties to LLVM as being a disadvantage.
-> Hal Finkel informs that the OpenMP IRBuilder proposal does not have any opposition in the Clang community and hence that probably is not a major risk.
Feedback (other):
-> Eric Schweitz: "I like the idea of adding OpenMP as its own dialect.  I think the design should allow this dialect to coexist with FIR and other dialects.  The dialect should be informed by the specific optimizations you plan to perform on the OpenMP semantic level, of course." Would prefer to lower F18 AST to a mix of OpenMP and FIR dialects. And would like the FIR to have nothing to do with OpenMP.
-> Steve Scalpone: "I think the design needs to be vetted against some of the scenarios that?ll be encountered when generating executable OpenMP code.  I have no reason to doubt what you?ve proposed will work but I do think it is important to consider how certain scenarios will be implemented.
Some topics to consider:
- How to implement loop collapse?
- How to implement loop distribution?
- How to implement simd?
- Is an outliner needed?  In MLIR, before, after?  Model to reference shared variables?
- How will target offload be implemented?
- Where will the OpenMP runtime API be exposed?"

References
1. OpenMP MLIR dialect discussion.
https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/4Aj_eawdHiw
2. Johaness? OpenMP IRBuilder proposal.
http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html
3. MLIR
https://github.com/tensorflow/mlir

Thanks,
Kiran
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190816/e0c3754a/attachment.html>

From gklimowicz at nvidia.com  Fri Aug 16 13:04:25 2019
From: gklimowicz at nvidia.com (Gary Klimowicz)
Date: Fri, 16 Aug 2019 17:04:25 +0000
Subject: [Flang-dev] Flang Biweekly Sync - Notes from August 7, 2019 call
Message-ID: <BYAPR12MB2741C32944E75F1D22FD4AFCA4AF0@BYAPR12MB2741.namprd12.prod.outlook.com>

Flang team,

Here are the notes from the August 7th, 2019 Flang biweekly call. Updates are in bold.

Please be sure to let us know if you have any questions and agenda topics for the next call.

The next Flang biweekly call will be August 21st, 2019 at 8:30 AM Pacific Time.

Thank you.

Gary Klimowicz


Agenda

  *   Flang Community Technical Call ? OpenMP discussion
  *   F18 development update
  *   Flang development update


Highlights


  *   Supercomputing 2019
     *   Hal submitted for an LLVM BoF session at SC 2019.
     *   There won?t be an LLVM in HPC Workshop this year.


  *   Flang Community Technical Biweekly Call
     *   Hal Finkel is hosting this call on Bluejeans<https://bluejeans.com/625064848>, Wednesdays 8:30 Pacific Time, the weeks alternating with this call. The notes for all these calls can be found in Google Docs here<https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/>.
     *   The July 31st call had Arm and NVIDIA presenting plans for OpenMP implementation for F18.
     *   The next call is scheduled for August 14th, 8:30 AM PDT. The scheduled agenda topic is aliasing information and LLVM enhancements.


  *   F18 as an LLVM project
     *   The LLVM-hosted flang-dev mailing list has been set up. Subscribe at https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev.
     *   We will continue to support the original flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org> through August 2019.
     *   Plan is still to upload documentation for F18 before the code, to help establish the project goals and design strategy before uploading the code. This should help establish context for the project.


  *   F18 update
     *   Working on allowing forward references to derived types in component definitions.
     *   Improved handling of generics with the same name as a type or procedure.
     *   Implemented folding of LBOUND and UBOUND intrinsics.
     *   Extracting binary-to-decimal and decimal-to-binary conversion code so it can also be used in runtime.
     *   Made pull requests to MLIR to help support Fortran Intermediate Representation.
     *   More work on DO loop semantics and constraint checking, including DO CONCURRENT locality specifications.
     *   More work on OpenMP directive parsing and semantic checks, including OpenMP parse tree node definitions and parsing.



  *   Flang Dev news and updates
     *   More bug fixes in queue to send to Flang.
     *   Improved build support for Windows and Mac.


Where we can use your help

  *   Subscribe to the new LLVM Flang email list: https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev. We will be cross-posting to both flang-dev mailing lists until September.
  *   Please provide any additional feedback to the RFC regarding the compiler driver submitted to flang-dev. The thread can be found in the cfe-dev email list here<http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html>.
  *   Please comment on the DEBUG metadata enhancement proposed for LLVM (CHARACTER intrinsic type). This is the last Flang debug metadata enhancement that has not been upstreamed to LLVM: https://reviews.llvm.org/D54114.
  *   Topics for the next biweekly community call and technical community call.
  *   Let us know if you have presentations or meetings relevant to the Flang community. We will publicize them in these notes.


Details


  1.  Flang on GitHub
?         There have been 1,483 total commits (1,466 in the previous update).
?         There are 470 people who have ?starred? the flang repo and 69 forks.
?         172 people are following f18 in 22 forks. There have been 2,288 commits.


  1.  Flang Community Technical Call

     *   This 30-minute biweekly call is hosted by Hal Finkel at https://bluejeans.com/625064848 on the Wednesdays we do not have this call, at 8:30 AM Pacific time.
     *   Hal sent an invitation to flang-dev.
     *   Notes from the call can be found in this <https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/edit#heading=h.oiag5i748hyl> Google doc.
     *   The most recent call was held July 31st, 8:30 AM Pacific time. We discussed the plans for OpenMP implementation.
     *   The next call is scheduled for August 14th. The agenda topic is aliasing information and LLVM enhancements.
     *   Future Topics and tentative dates:
        *   LLVM transition (mailing lists, git/monorepo, etc.)
        *   Aliasing information and LLVM enhancements (2019-08-14)
        *   Module files (2019-08-28?)


  1.  Flang community

  *   Website: www.flang-compiler.org<http://www.flang-compiler.org> redirects to http://github.com/flang-compiler/flang.
  *   Wiki: https://github.com/flang-compiler/flang/wiki is the Flang wiki page where the most up-to-date build instructions and news can be found.
  *   Issues: Bug reports for Flang can be reported to https://github.com/flang-compiler/flang/issues.
  *   Mailing lists: There are three mailing lists for Flang: flang-dev, flang-sync and flang-announce at http://lists.flang-compiler.org/.

     *   You can reach the general Flang community by emailing flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org>.
     *   Occasional announcements are sent to flang-announce at lists.flang-compiler.org<mailto:flang-announce at lists.flang-compiler.org>.
     *   These notes will then be sent to flang-dev and flang-sync at lists.flang-compiler.org<mailto:flang-sync at lists.flang-compiler.org>. You should be able to subscribe and unsubscribe yourself from flang-sync and flang-dev as you desire.

  *   LLVM mailing lists: There are now two mailing lists hosted by llvm.org. We will be transitioning to using these lists:
     *   The flang-dev mailing list has been set up. Subscribe at https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev. These biweekly notes will now be sent to this email list.
     *   The flang-commits mailing list has been set up. Subscribe at https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-commits.
     *   Please migrate to the LLVM project mailing lists. We will be turning off the  flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org> on September 1, 2019.
  *   Slack: flang-compiler.slack.com is used for informal real-time communication in the Flang community. Add yourself via the invite <https://join.slack.com/t/flang-compiler/shared_invite/enQtMjExOTEyMzQ3MjIxLTZkMDNlODc2YjgxZDY1NTQ2YWJiZWVhOGU2YWY0NDNiOWY0ZjQzNjYyZTNlZjBlNjgxY2U1ZjFjMmY5NzIwMzA> link.
  *   Supercomputing 2019
     *   It?s time to think about Flang and LLVM-related activity at Supercomputing.
     *   Hal submitted for an LLVM BoF session at SC 2019.
     *   There won?t be a specific LLVM in HPC Workshop this year.
     *   There may also be a social event. Nothing specific yet.




  1.  What we?re up to


  *   F18 Fortran 2018 compiler

  *   On GitHub: The source code f18 is available on flang-compiler.github.com/f18<https://github.com/flang-compiler/f18/>. It?s recommended to start in the ?documentation? directory.
  *   Status: We continue development on the new Fortran 2018 front-end. Recent work includes:

     *   Worked on forward references to derived types in component definitions.
     *   Improved handling of generics with the same name as a type or procedure.
     *   Implemented folding of LBOUND and UBOUND intrinsics.
     *   Extracting binary-to-decimal and decimal-to-binary conversion code so it can also be used in runtime.
     *   Made pull requests to MLIR to help support Fortran Intermediate Representation.
     *   More work on DO loop semantics and constraint checking, including DO CONCURRENT locality specifications.
     *   More work on OpenMP directive parsing and semantic checks, including OpenMP parse tree node definitions and parsing to add more source provenance information.
     *   We are close to the point where we will turn on semantic processing by default. This will make it easier for people to check existing codes against f18 and expanding the test suite in f18.
     *   Additional fixes for semantic issues identified by running internal test suites against f18.


  *   LLVM Project:

     *   The flang-dev email list has been set up on llvm.org. You can subscribe here: https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev. Archives are also available.
     *   The flang-commits email list has also been set up. There is no content yet, as we haven?t migrated to the LLVM monorepo.
     *   The plan is to first upload some of the top-level documentation so the community can read the project goals and strategy before we do a big code dump. This should happen mid-June.


  *   Recent updates to Flang:
Work continues on the Fortran 2008 BLOCK construct. We are working on appropriate allocations and deallocations at block entry and exit.
Continued work on polymorphic allocatable assignment statements.
Started work on debug metadata for inlined procedures (helpful for profiling).

     *   More PGI bug fixes
        *   #719 libpgmath: windows and osx support (as PR#770)


     *   Upcoming changes to Flang (in review):
        *   More PGI bug fixes
        *   F2008 vector NORM2
        *   Debug support for Fortran allocatables
        *   Pull request #573 ? libpgmath: make it clang friendly; addresses bug #557 (reviewing)
        *   Pull request #695 ? Remove duplicate files
        *   Pull request #716 ? Make NCAR Kernels tests into longtests


     *   Assigned for work:
        *   #226 Unlimited polymorphic type does not work with transfer intrinsic
        *   #298 norm2 intrinsic
        *   #402 Compiler error on regular code
        *   #404 Internal compiler error with polymorphic subroutine parameters and nested derived types
        *   #426 Failures in #include of OpenMPI's mpif.h
        *   #461 OpenMP TeaLeaf_ref: local pointer variable not captured into parallel region
        *   #477 Pull request for module variable import debug test
        *   #498 Error while compiling libpgmath
        *   #512 Flang rejects polymorphic assignment
        *   #577 Procedure pointers to internal procedures
        *   #602 fd_sincos_scalar.cpp: "error: ?__builtin_complex? was not declared in this scope"
        *   #604 Flang errors out on a final subroutine with parameterized derived types
        *   #608 gdwarf-<version> flag is not honoured
        *   #610 No debug generated for namelists
        *   #662 Regression : Segfault in taskloop code
        *   Pull request #695 runtime: remove duplicate files
        *   Pull request #710 Test case for capturing procedure pointers to OpenMP parallel regions
        *   Pull request #719 libpgmath: windows and osx support


  *   Outstanding pull requests:

  *   #521 Add OpenBSD as a recognized OS (pending test on new OpenBSD systems internally)
  *   #529 runtime: PoC: generate call to LLVM intrinsic instead of calling runtime functions when possible; handling NINT for a beginning (proposed expansion of this pull request)
  *   #530 AArch64: disable test cases invalid on aarch64 (working on)
  *   #532 runtime: remove duplicate files (need to validate on all compilers)
  *   #546 Loosen ties to x86 (working on)
  *   #572 libpgmath: respect LIBPGMATH_WITH_GENERIC setting; fixes #559 (reviewing)
  *   #592 add support for macOS (awaiting CLA)
  *   #622 Add explicit braces to avoid dangling else problem (failed NVIDIA testing)
  *   #642 AArch64: significantly improve formatted input performance by using optimized libc functions on ARM64
  *   #647 Introduce buffered I/O and replace getc with buffered read
  *   #655 Add missing signed integer to a pointer conversion in DATA statement
  *   #658 Fix in preprocessing for Flexi app
  *   #659 Changes to support transpose intrinsic during initialization
  *   #660 Enable support for simd directives
  *   #672 Support isnan() GNU extension (Arm reviewing)
  *   #689 Fix for segfault in multiple entries OpenMP functions
  *   #693 runtime: ARM64 is a 64-bit architecture
  *   #694 libpgmath sanity: do not call sleep() in Linux systems
  *   #695 runtime: remove duplicate files
  *   #701 Fix for ICE in taskloop
  *   #702 Fix for random_seed when seeds have zeroes in LSB
  *   #710 Test case for capturing procedure pointers to OpenMP parallel regions
  *   #711 Make the NCAR Kernels tests into longtests
  *   #717 Support building libpgmath with clang 6
  *   #723 Support building flang with clang
  *   #725 Check for gregset_t before using it
  *   #726 Remove linux references where unneeded
  *   #737 TRAILZ function added to the fortran compiler (resubmitted)
  *   #738 Fix for issue #550
  *   #742 Implement UNROLL directive


  *   Public plan: NVIDIA has published a brief plan for upcoming Flang work on github.io at https://github.com/flang-compiler/flang/wiki/Roadmap. This has been recently updated to reflect current Flang and F18 priorities and to provide better context for the project and its long-term goals.


  *   Creating pull requests: NVIDIA requires contributor agreements from developers wishing to make pull requests. The Individual CLA is here: https://flang-compiler.github.io/files/Flang-ICLA-v4.pdf. The Corporate CLA is here: https://flang-compiler.github.io/files/Flang-CCLA-v2.pdf. Send completed CLAs to flang-cla at nvidia.com<mailto:flang-cla at nvidia.com>. Assuming the pull request builds and passes ?make check-flang?, NVIDIA will take on the internal testing of the pull request using the full test suite available internally and provide feedback to the contributor as appropriate. Once we have the quality of the pull request established, it will be incorporated into Flang.

  *   LLVM is switching to a new Apache license with LLVM exceptions that we need to incorporate into our CLAs after it is adopted by LLVM community. The LLVM license can be found at http://llvm.org/foundation/relicensing/LICENSE.txt. A web page describing the relicensing effort can be found at http://llvm.org/foundation/relicensing/.



  *   OpenMP 4.5 support:
o    OpenMP 4.5 is supported on multicore CPUs, mapping all target regions across all the cores, with the following known limitations:

        *   We map the directives directly for host==device with very predictable behavior and good performance results.
        *   Task depend/priority is not supported
        *   OMP do clauses linear, order(n), and schedule (modifier) are not supported
        *   SIMD construct, Declare SIMD, and SIMD clause: private/reduction/lastprivate/collapse clauses on SIMD construct are supported, SIMD clause/construct are used as a hint to vectorize through metadata generation
        *   There is a bug if target construct is enclosed by task construct

o    No update



  *   Outstanding issues:

     *   Please refer to the Issues section on GitHub for flang-compiler/flang<https://github.com/flang-compiler/flang/issues> and flang-compiler/flang-driver<https://github.com/flang-compiler/clang/issues>.


  *   Debug Metadata:
     *   LLVM Debug metadata changes posted to LLVM Phabricator for review; responding to review comments.
        *   https://reviews.llvm.org/D54114 [CHARACTER intrinsic data type] Review for this is not complete, and we would like to get additional comments or alternate proposals.
     *   LLVM Debug metadata changes upstreamed to LLVM:
        *   https://reviews.llvm.org/D54043 [ELEMENTAL, PURE and RECURSIVE PROCEDURES]
        *   https://reviews.llvm.org/D54327 [COMMON blocks]


  *   Packaging and Binary Releases:

  *   Binary release: We post binary releases at least quarterly. March binary releases of Flang for x86-64 and OpenPOWER (LLVM 7.0) have been posted to http://github.com/flang-compiler/flang/releases.
  *   Spack: Spack packages for Flang have been reviewed by the Spack team and pulled into Spack for flang_20180921. We are still working through issues with defining the spack package for flang. Brian Homerding is starting to work on Spack changes for the LLVM and Flang for the LLVM Git monorepo.


  *   Testing updates:

  *   NCAR Kernels tests take a long time to execute on some architectures, so we are planning to move them to longtests, based on Arm pull request.


  *   Application updates:
     *   No update.



  1.  Fortran 2008 features
Some Fortran 2008 features in development for pgfortran will flow into Flang soon.

  *   Support for the G0 Edit descriptor has been requested by LLNL. Work is complete and is being upstreamed to Flang.
  *   BLOCK construct. Work has begun on BLOCK.
  *   Pointer default initialization. Work is scheduled to begin in shortly.
  *   Allocation of polymorphic variables. Work is scheduled to begin in shortly.
  *   EXECUTE_COMMAND_LINE intrinsic. Work is scheduled to begin in shortly.
  *   NORM2 intrinsic. Work has completed and is being upstreamed to Flang.

The following items are considered complete. Please report GitHub issues if you identify any problems.

  *   ERROR STOP
  *   Pointers to internal procedures
  *   SUBMODULE
  *   Serial implementation of F2018 DO CONCURRENT (there is no multi-core implementation planned at this time)
  *   BACK optional argument support for MINLOC/MAXLOC.

________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190816/c28ff3ee/attachment-0001.html>

From hfinkel at anl.gov  Fri Aug 16 14:36:53 2019
From: hfinkel at anl.gov (Finkel, Hal J.)
Date: Fri, 16 Aug 2019 18:36:53 +0000
Subject: [Flang-dev] Time For Flang Community Technical Call
Message-ID: <c2125f89-9f81-6d51-06eb-f7bbca73bc13@anl.gov>

Hi, everyone,

As I mentioned on the call this week, our current Flang community 
technical call has the unfortunate feature of overlapping with the 
community loop-optimization call. I've made a Doodle poll with some 
other times that work for me (and including our current time, for 
comparison). Please fill this out so we can see if there is another time 
that might work for us. I included a few times 30 minutes later than our 
current time as well (in case the attendees in Europe can join a bit later).

 ? https://doodle.com/poll/66m8mvavg7ag2t49

Thanks again,

Hal

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From prashanth.nr at gmail.com  Mon Aug 19 09:53:17 2019
From: prashanth.nr at gmail.com (Prashanth N R)
Date: Mon, 19 Aug 2019 19:23:17 +0530
Subject: [Flang-dev] FC: A new LLVM based Fortran Frontend
Message-ID: <CAEMPOObLHNtd_yBm8E1zae1f=Sc=h8rGQ58v9tk0n+EsUP9uuQ@mail.gmail.com>

A new front end for Fortran (

https://github.com/compiler-tree-technologies/fc ) has been written in the
design spirit of LLVM/Clang. This is a prototype version with approximately
20K+ lines of code. The compiler is close to Fortran 95 standard. The Front
end is a complete end to end solution without semantic analysis. It
compiles and runs 400+ unit test cases and 2 (503.bwaves_r and
548.exchange2_r) SPEC CPU 2017 Fortran benchmarks.

Major supported features inlcudes:
1. Nested do, do-while, where, select-case, forall, implied-do constructs,
2. Handling/Expanding Array Section expressions, Array constructors,
3. IO Handling: File read/write with basic Formatting support.
4. Support for around 40 Fortran Intrinsics like transpose, reshape, min,
max, sum, etc
5. Nested Functions/ Module/ Subroutines.
6. Derived types are partially supported(WIP)
7. Dynamic memory handling (allocate statement) using malloc/free.
8. Very basic Debugging / TBAA support.

LLVM code generated is fairly optimized. The performance in SPEC becnhmarks
are comparable(better in few cases) to flang and gfortran compilers in both
speed and rate runs.

Feedback/ comments are welcome.

Thanks,
Prashantha N.R.
Compiler Tree Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190819/dd8e2fed/attachment.html>

From eric.schweitz at pgroup.com  Mon Aug 19 12:35:04 2019
From: eric.schweitz at pgroup.com (Eric Schweitz (PGI))
Date: Mon, 19 Aug 2019 16:35:04 +0000
Subject: [Flang-dev] Flang Technical Call : Summary of presentation on
 OpenMP for Flang
In-Reply-To: <AM7PR08MB530368928A2D627CAF5861FC8CAD0@AM7PR08MB5303.eurprd08.prod.outlook.com>
References: <AM7PR08MB530368928A2D627CAF5861FC8CAD0@AM7PR08MB5303.eurprd08.prod.outlook.com>
Message-ID: <247afea90b904ab38af01d9c03512673@DRHQMAIL107.nvidia.com>

Re: And would like the FIR to have nothing to do with OpenMP.

This seems stronger than what I meant, so I'll clarify a bit.

FIR should have no dependence on OpenMP, since it is possible to write (vanilla) Fortran programs without OpenMP.  However FIR clearly must also co-exist with an OpenMP dialect.  Stated another way, we don't want a circular dependence between "vanilla Fortran" and OpenMP.  Since OpenMP is a directive-based meta-language that impacts the code gen of a program (whether it is Fortran or some other language), it seems quite natural and necessary that OpenMP be able to operate upon the substrate language  (whether that substrate is FIR or LLVM IR or something else). Fortunately, MLIR allows one to mix dialects, and thus each dialect can focus on the problems it's trying to solve.

--
Eric

From: flang-dev <flang-dev-bounces at lists.flang-compiler.org> On Behalf Of Kiran Chandramohan
Sent: Friday, August 16, 2019 9:13 AM
To: flang-dev at lists.flang-compiler.org
Subject: [Flang-dev] Flang Technical Call : Summary of presentation on OpenMP for Flang

Hi,

This mail is a summary of the presentation that I gave on 31st August about supporting OpenMP in Flang (F18). Link to presentation: https://drive.google.com/open?id=1Q2Y2fIavewq9oxRDruWoi8TaItlq1g9l
The mail follows the contents of the presentation and should be read in conjunction with the slides. It also includes feedback provided during and outside the presentation. It would be great to receive further feedback.

This presentation discusses the design of how OpenMP can be represented in the IR and how it can be translated to LLVM IR. The design is intended to be modular so that other frontends (C/C++) can reuse it in the future. The design should also enable reuse of OpenMP code from Clang (LLVM IR generation, Outlining etc). It should also be acceptable to Flang, MLIR, Clang communities. And most importantly should allow for any OpenMP optimisation desired.

The designs presented uses the following two components.
a) MLIR [3]: Necessary since MLIR has already been chosen as the framework for building the Fortran IR (FIR) for Flang.
b) OpenMP IRBuilder [2]: For sharing of OpenMP code with Clang.

The current sequential code flow in Flang (Slide 5) can be summarised as follows,
[Fortran code] -> Parser -> [AST] -> Lowering -> [FIR MLIR] -> Conversion -> [LLVM MLIR] -> Translation -> [LLVM IR]

Four design plans are presented. These plans add OpenMP support to the sequential code flow. All the plans assume that FIR is augmented with a pass-through operation which represents OpenMP constructs.
Plan 1 (Slide 6)
The first plan extends LLVM MLIR with OpenMP operations. The pass-through OpenMP operation in FIR is converted to the OpenMP operation in LLVM MLIR. The OpenMP operation in LLVM MLIR can be converted to LLVM IR during translation. The translation process can call the OpenMP IR Builder to generated the LLVM IR code.
Pros: Easy to implement, Can reuse Clang OpenMP code.
Cons: Not acceptable to MLIR community [1]. By design LLVM MLIR should be similar to LLVM IR (OpenMP is a form of parallelism. Has concepts of nested regions etc which do not map directly to LLVM IR and hence to LLVM MLIR).

Plan 2 (Slide 7)
In the second plan, LLVM MLIR is not extended. Here the pass-through OpenMP operation in FIR has to be converted to existing LLVM MLIR. This would involve outlining, privatisation etc during the conversion of FIR to LLVM MLIR.
Pros: Easy to implement.
Cons: Cannot be shared with other users (C/C++) and non-LLVM targets (accelerators). Cannot re-use Clang OpenMP code.

Plan 3 (Slide 8)
The third plan defines a separate MLIR dialect for OpenMP. The pass-through OpenMP operation in FIR can be converted to Operations in the OpenMP MLIR dialect. OpenMP specific optimisations can be performed in this dialect. This dialect will be lowered to the LLVM dialect and outlining etc will happen at this time.
Pros: MLIR dialect can be used by other users. Acceptable to MLIR community [1].
Cons: Cannot reuse code from Clang for OpenMP

Plan 4: The proposed design (Slide 9)
The proposed design also involves creating an OpenMP dialect in MLIR. The difference lies in the fact that the OpenMP dialect has some ties to the LLVM dialect like sharing the types and using the translation library of the LLVM dialect. The Fortran IR (FIR) will be lowered to a mix of OpenMP and LLVM dialect. The translation library of LLVM dialect will be extended to create a new translation library which can then lower the mix to LLVM IR. The new translation library can make use of the LLVM IRBuilder.
Pros: Other users (C/C++) can use it. Can reuse Clang OpenMP code. Acceptable to MLIR community [1].
Cons: Has some ties to the LLVM dialect.

OpenMP dialect
The proposed plan involves writing an MLIR dialect for OpenMP. An MLIR dialect has types and operations. Types will be based on the LLVM dialect. Operations will be a mix of fine and coarse-grained. e.g. Coarse: omp.parallel, omp.target, Fine: omp.flush. The detailed design of the dialect is TBD and will be based on what should be optimized. The OpenMP dialect creation in the proposed plan is from FIR, this would require pass-through OpenMP operations in FIR. Another approach would be to lower F18 AST with OpenMP directly to a mix of OpenMP and FIR dialects. This would require that FIR co-exist with the OpenMP dialect.

Next Steps
-> Address feedback provided after the presentation. And reach an agreement on a plan
-> Design a minimum viable MLIR dialect and get community acceptance.
-> Help with progressing the OpenMP IRBuilder.
-> Implement the accepted plan. Implementation would follow a vertical plan (going construct by construct).
-> Represent construct in OpenMP MLIR
-> Refactor the code for the construct in OpenMP IRBuilder
-> Set up the translation library for OpenMP in MLIR to call the IRBuilder
-> Set up the transformation from the frontend to OpenMP MLIR for this construct

Feedback (during the call):
-> Johaness agrees with this proposed plan (Plan 4) and does not see the ties to LLVM as being a disadvantage.
-> Hal Finkel informs that the OpenMP IRBuilder proposal does not have any opposition in the Clang community and hence that probably is not a major risk.
Feedback (other):
-> Eric Schweitz: "I like the idea of adding OpenMP as its own dialect.  I think the design should allow this dialect to coexist with FIR and other dialects.  The dialect should be informed by the specific optimizations you plan to perform on the OpenMP semantic level, of course." Would prefer to lower F18 AST to a mix of OpenMP and FIR dialects. And would like the FIR to have nothing to do with OpenMP.
-> Steve Scalpone: "I think the design needs to be vetted against some of the scenarios that'll be encountered when generating executable OpenMP code.  I have no reason to doubt what you've proposed will work but I do think it is important to consider how certain scenarios will be implemented.
Some topics to consider:
- How to implement loop collapse?
- How to implement loop distribution?
- How to implement simd?
- Is an outliner needed?  In MLIR, before, after?  Model to reference shared variables?
- How will target offload be implemented?
- Where will the OpenMP runtime API be exposed?"

References
1. OpenMP MLIR dialect discussion.
https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/4Aj_eawdHiw
2. Johaness' OpenMP IRBuilder proposal.
http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html
3. MLIR
https://github.com/tensorflow/mlir

Thanks,
Kiran
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/attachments/20190819/7ef0c7df/attachment-0001.html>