RFC: LLVM 11 branch

Subprojects Flang
1

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, 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.

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.

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.

Does anyone have any thoughts on this?

Thanks
David Truby

2

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

3

Hi

I'm the maintainer of flang in Debian/Ubuntu.

Is flang on LLVM 11 likely to be in usable state for early next year (Q1)?

flang shipped in the last stable release of Debian (20181126) built against LLVM-7.

Now LLVM-7 is removed from Bullseye, the upcoming release, but LLVM 11 is likely to be included.

Could flang with LLVM-11 be built to use gfortran or flang itself instead of pgfortran ?

Best regards

Alastair McKinstry

4

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

    External email: Use caution opening links or attachments

    > 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

5

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

6

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
7

Hi Alastair,

The current flang in the debian repos is the old flang found at
https://github.com/flang-compiler/flang, which I think will support
LLVM 11 at some point (although I'm not the right person to ask about
this).

This discussion is about the new LLVM-integrated flang, which will be a
developer only release in LLVM 11 and not really useful to include in
the Debian repositories as it will still be reliant on other fortran
compilers to generate code.

As a result it's probably more useful to include the flang-
compiler/flang project in the next Debian release I think.

Perhaps someone else can comment more on that though?

David

8

Hi Alastair,

The current flang in the debian repos is the old flang found at
GitHub - flang-compiler/flang: Flang is a Fortran language front-end designed for integration with LLVM., which I think will support
LLVM 11 at some point (although I'm not the right person to ask about
this).

Thanks. Is there any timeline or roadmap for the "legacy flang" compiler ?

9

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!

10

NVIDIA doesn't have a timeline yet for LLVM 11.

I think the other providers for compilers based on "classic Flang" might, though.

Gary

11

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

12

+1 for extending the flags to include gcc equivalents.

13

Thank you for the feedback Kiran and Steve. I’ve extended the flags to include gfortran equivalents for everything beginning with -M and am now testing to see if the help message prints out nicely with my additions.

One question… I noticed that most of the flags the flang throwaway driver understands don’t get passed on to the F18_FC compiler. Should I change this behavior? It seems to me like they should, but I wanted to hear your opinions before including that change in my current patch.

Thanks!

–Alexis

14

The F18_FC compiler operates on the unparsed source, which is free-form, so -Mfixed should not be passed.

Is the backslash option passed through? I’d guess that f18 handles backslash and produces a normalized form (but I didn’t look).

Probably don’t need -Mextend because the unparser probably handled that.

15

The backslash option is not passed through.

I’m asking about this mostly because I remember having to hack the driver to pass through specific options regarding fixed/free form, backslash, and default real/integer kinds in order to compile the specific apps I was testing with at the time. I wasn’t sure if this would be something useful to users in general or not. I’m perfectly happy to keep using my hacked version when I need to if you don’t think this would be a worthwhile addition to the code in general.

–Alexis

16

Darn - I sent this out yesterday evening GMT but did not send to the list by mistake!

I see the conversation has moved on a bit since then, hopefully I am not too late!

17

I agree with no default and giving a nice msg if F18_FC isn't set when it's needed; however, I don't mind if there is a default. Adding the default F18_FC to the CMakefile seems like an unnecessary complication in the CMakefile and build instructions for this throwaway driver but others might have a good case for supporting it.

That said, I think Alexis' patch does the job quite well.

    External email: Use caution opening links or attachments

    Darn - I sent this out yesterday evening GMT but did not send to the list by mistake!

    I see the conversation has moved on a bit since then, hopefully I am not too late!