[flang-dev] [EXTERNAL] RFC: LLVM 11 branch

Thu Jul 9 12:41:44 PDT 2020

+1 for extending the flags to include gcc equivalents.

From: Kiran Chandramohan <Kiran.Chandramohan at arm.com>
Date: Thursday, July 9, 2020 at 12:31 PM
To: Steve Scalpone <sscalpone at nvidia.com>, pat <pat at lanl.gov>, "Perry-Holby, Alexis" <aperry at lanl.gov>
Cc: flang-dev <flang-dev at lists.llvm.org>
Subject: Re: [flang-dev] [EXTERNAL] RFC: LLVM 11 branch

External email: Use caution opening links or attachments

Thanks Alexis for submitting this patch.

Most of the flags (Mfixed, Mfree, Mextend etc) accepted by the current driver are based on pgfortran. And the default compiler is pgfortran, this makes it possible to use llvm/flang as a replacement for the pgfortran compiler in an existing build flow.
If we make gfortran the default compiler then this results in a mismatch between options accepted by llvm/flang driver and the default gfortran compiler. And this results in a situation where llvm/flang cannot be used as a replacement for any compiler.
I think if we are making gfortran the default then we should also change the driver flags to gfortran equivalent ones or add the gfortran flags as aliases of existing pgfortran flags.

--Kiran
________________________________
From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of Perry-Holby, Alexis via flang-dev <flang-dev at lists.llvm.org>
Sent: 09 July 2020 17:20
To: Steve Scalpone <sscalpone at nvidia.com>; McCormick, Pat <pat at lanl.gov>
Cc: flang-dev at lists.llvm.org <flang-dev at lists.llvm.org>
Subject: Re: [flang-dev] [EXTERNAL] RFC: LLVM 11 branch

If F18_FC is not set, the current throwaway driver does give an error, but it’s not all that helpful unless you know a thing or two about the driver (execvp(pgf90) failed: No such file or directory).  Basically, it looks for pgf90 by default.  I submitted a patch (https://reviews.llvm.org/D83488) that changes the default behavior to look for gfortran instead and uses more generic variable names where appropriate.  Reviews are appreciated.

Thanks!

-- Alexis

From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of Steve Scalpone via flang-dev <flang-dev at lists.llvm.org>
Reply-To: Stephen Scalpone <sscalpone at nvidia.com>
Date: Wednesday, July 8, 2020 at 5:36 PM
To: "McCormick, Pat" <pat at lanl.gov>
Cc: "flang-dev at lists.llvm.org" <flang-dev at lists.llvm.org>
Subject: Re: [flang-dev] [EXTERNAL] RFC: LLVM 11 branch

The existing throwaway driver uses an environment variable F18_FC to specify the target compiler.  That works well for me with pgf90 and gfortran.

A command-line option is a little more difficult to use with CMake, but not by much.  You’d have to say:

FC=”f18 -fc gfortran” cmake …

The reason that the environment variable is F18_FC instead of FC is because typically FC would be set to f18:

F18_FC=gfortran FC=f18 cmake …

If F18_FC is not set, it might be nice for the throwaway driver to issue an error message if it is asked to link a program.

- Steve

From: pat <pat at lanl.gov>
Date: Wednesday, July 8, 2020 at 4:00 PM
To: Steve Scalpone <sscalpone at nvidia.com>
Cc: Hal Finkel <hfinkel at anl.gov>, David Truby <David.Truby at arm.com>, flang-dev <flang-dev at lists.llvm.org>
Subject: Re: [EXTERNAL] [flang-dev] RFC: LLVM 11 branch

External email: Use caution opening links or attachments

Somewhere I have a version of the “dummy” driver that allows you to specify the target compiler to hand off to.  I can try and track that code down (as I recall it was pretty simple patch as it used an environment variable).   It should be quick to fix in the latest code base and we could potentially also consider making it a CMake settings/parameter if that is an easier (more user friendly) path for use cases we have across the community.

Thoughts?

—Pat

On Jul 8, 2020, at 4:54 PM, Steve Scalpone via flang-dev <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>> wrote:

No objections to removing the dependencies on pgf90; however, I agree that the existing FC mechanism should preserve the ability to use other compilers to generate code.  Camille Coti post a patch to enable linking with additional libraries, but it's not integrated anywhere that I know of.  David, if you are going to undertake this change, let me know & I'll fwd the email to you.

- Steve

On 7/8/20, 11:46 AM, "flang-dev on behalf of Hal Finkel via flang-dev" <flang-dev-bounces at lists.llvm.org<mailto:flang-dev-bounces at lists.llvm.org> on behalf of flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>> wrote:

   External email: Use caution opening links or attachments

   On 7/8/20 3:58 AM, David Truby via flang-dev wrote:

Hi all,

The LLVM 11 branch is happening soon so we should have a discussion
about what we want Flang to look like in that branch.

tldr; I see a couple of issues currently that we should discuss for the
release:

* Flang defaults to calling a proprietary compiler (pgfortran)
* Flang enables Werror by default
* Shared library builds don't work

Does anyone else see any other things we should consider that I haven't
listed here?

To elaborate on my issues list:

I think it's reasonable for us to leave flang in the release,

   Yes, we should make clear that this is essentially in a developer-only
   mode (excepting any specific tests that we want to ask people to run).

 rather
than for example removing it, and add info in the Release Notes about
the state of Flang (e.g. that it fully parses and semantically analyses
Fortran 2018 code but then calls out to another compiler to build it).

The biggest issue I see with this is that currently flang defaults to
calling out to a proprietary compiler that many people in an open
source community like LLVM are unlikely to have installed. I would
propose that we either add a CMake flag to select the default compiler
to call out to, or that we rely on the existing mechanism of defining
FC, but that either way we should default to gfortran if no other
compiler is specified. That way we would be calling out to a compiler
that almost anyone interested in Fortran is likely to have installed,
and if not it is at least easily available.

   +1

The other major issue I forsee is that we currently enable Werror by
default in flang. This is likely to break the release for people
building it with as-yet-unreleased compilers, with downstream
proprietary compilers we haven't tested with, or other unforseen
circumstances. I think there are too many potential issues for Werror
by default to go into a release version of LLVM.

   +1

   I thought that we had consensus to change this.

Shared library builds also don't currently work due to a circular
dependency between two libraries. I think it's farily uncontroversial
to say that this should be fixed, and I am happy to start working on it
personally.

   Yes, shared-library builds should work.

   We can also discuss these on Monday's call.

     -Hal

Does anyone have any thoughts on this?

Thanks
David Truby
_______________________________________________
flang-dev mailing list
flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

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

   _______________________________________________
   flang-dev mailing list
   flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>
   https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

_______________________________________________
flang-dev mailing list
flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200709/8f708b71/attachment-0001.html>