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

Fri Jul 10 06:12:43 PDT 2020

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!

-----Original Message-----
From: Richard Barton 
Sent: 9 July, 2020 16:41
To: David Truby <David.Truby at arm.com>; alastair.mckinstry at sceal.ie
Subject: RE: [flang-dev] RFC: LLVM 11 branch

Hi all

+1 on what David said regarding classic flang. That will certainly be a better choice for Fortran compiler in Debian's LLVM 11 support. LLVM11 with classic flang is on various vendor's roadmap for this autumn, so one of us will do it I'm sure.

> > > * Flang defaults to calling a proprietary compiler (pgfortran)

My 2c worth. I think the best default for this is actually no default and a friendly error message if you don't set one and try to run flang. We saw a recent post [1] by someone who was surprised by the default behaviour of flang and I think we could quite easily improve this experience with a few small tweaks to the current driver.

I think the cmake flag to set a default is a great idea and I think we should support both that and the current environment variable as both are cheap to maintain and so as to minimise the impact of this change to those that rely on it currently.

There are a few pgfortran options which are mapped specifically in the driver and I think we should keep these in on the same basis. With a new driver, these can be re-evaluated at that time, perhaps fitting into an API like clang's ToolChains.

> > > * Flang enables Werror by default

+1 from me also on switching the -Werror default to off, in line with the other projects.

> (Hal)     I thought that we had consensus to change this.

I think we still need to agree here.

The rationale for the current default (i.e. warnings are errors) is that it is not good to have a warnings in your build and we should fix them. I agree with that, but I think it is not practical to enforce this for the full combination platforms that we need to support in flang as an LLVM sub-project. Although we are still growing this picture out, we will ultimately need to support multiple major and minor versions of gcc and clang, on multiple Unix platforms and in combination with multiple linkers and libraries. As time goes on, this need will grow as new versions of gcc and clang are released. We will also add Windows into the mix one day and have to support again multiple MSVC versions, clang -cl, etc. there too, which grows over time. There is also the other types of compilers that David mentions.

I think we should align with the wider LLVM strategy of not enforcing -Werror in flang by default and between us, covering -Werror builds with only the compilers/platforms combinations that we all care about the most, on public or private buildbots. Public buildbots are the way to do this 'for free' because contributors who's patches introduce warnings into the build will be required to fix them up or face reversion. Downstream builders mean that the owners need to post patches that fix warnings themselves.

Ta
Rich

[1] http://lists.llvm.org/pipermail/flang-dev/2020-June/000398.html

> -----Original Message-----
> From: flang-dev <flang-dev-bounces at lists.llvm.org> On Behalf Of David
> Truby via flang-dev
> Sent: 9 July, 2020 11:31
> To: alastair.mckinstry at sceal.ie; flang-dev at lists.llvm.org
> Subject: Re: [flang-dev] RFC: LLVM 11 branch
> 
> 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
> 
> On Wed, 2020-07-08 at 20:29 +0100, Alastair McKinstry via flang-dev
> wrote:
> > 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
> >
> > On 08/07/2020 09:58, 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,
> > > 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
> > > _______________________________________________
> > > flang-dev mailing list
> > > 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev