[flang-dev] RFC: LLVM 11 branch

[David Truby via flang-dev]

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