flang-compiler/flang

Flang is a Fortran language front-end designed for integration with LLVM.

Flang

Flang (also known as "Classic Flang") is an out-of-tree Fortran compiler targeting LLVM. It is an open-sourced version of pgfortran, a commercial Fortran compiler from PGI/NVIDIA. It is different from the new Flang (formerly known as "F18"; see https://flang.llvm.org/), which has been part of the LLVM project since 2020, although both are developed by the same community. It is also unrelated to other projects of the same name, such as https://github.com/llvm-flang/flang and https://github.com/isanbard/flang.

Classic Flang is used in several downstream commercial projects like the AMD, Arm and Huawei compilers, and continues to be maintained, but the plan is to replace Classic Flang with the new Flang in the future.

Visit the Flang wiki for more information:

https://github.com/flang-compiler/flang/wiki

To sign up for the developer mailing lists for announcements and discussions, visit:

https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

We have a flang-compiler channel on Slack. Slack is invitation-only but anyone can join with the invitation link below:

https://join.slack.com/t/flang-compiler/shared_invite/MjExOTEyMzQ3MjIxLTE0OTk4NzQyNzUtODQzZWEyMjkwYw

Building Flang

Instructions for building Flang can be found on the Flang wiki:

https://github.com/flang-compiler/flang/wiki/Building-Flang

Compiler Options

For a list of compiler options, enter:

% flang -help

Flang accepts all Clang compiler options and supports many, as well as the following Fortran-specific compiler options:

-noFlangLibs          Do not link against Flang libraries
-mp                   Enable OpenMP and link with with OpenMP library libomp
-nomp                 Do not link with OpenMP library libomp
-Mbackslash           Treat backslash in quoted strings like any other character
-Mnobackslash         Treat backslash in quoted strings like a C-style escape character (Default)
-Mbyteswapio          Swap byte-order for unformatted input/output
-Mfixed               Assume fixed-format source
-Mextend              Allow source lines up to 132 characters
-Mfreeform            Assume free-format source
-Mpreprocess          Run preprocessor for Fortran files
-Mrecursive           Generate code to allow recursive subprograms
-Mstandard            Check standard conformance
-Msave                Assume all variables have SAVE attribute
-module               path to module file (-I also works)
-Mallocatable=95      Select Fortran 95 semantics for assignments to allocatable objects
-Mallocatable=03      Select Fortran 03 semantics for assignments to allocatable objects (Default)
-static-flang-libs    Link using static Flang libraries
-M[no]daz             Treat denormalized numbers as zero
-M[no]flushz          Set SSE to flush-to-zero mode
-Mcache_align         Align large objects on cache-line boundaries
-M[no]fprelaxed       This option is ignored
-fdefault-integer-8   Treat INTEGER and LOGICAL as INTEGER*8 and LOGICAL*8
-fdefault-real-8      Treat REAL as REAL*8
-i8                   Treat INTEGER and LOGICAL as INTEGER*8 and LOGICAL*8
-r8                   Treat REAL as REAL*8
-fno-fortran-main     Don't link in Fortran main

flang's Issues

Coarray support

Dear flang team,

I would like to know if you have planned to add support for Coarray, as for the Fortran 2008 standard or the draft 2015. The OpenCoarrays team could be very interested to integrate your compiler into their workflow and user like me interested into CAF could be very interested into using your compiler if it will support CAF.

My best regards.

FORALL segfaults

FORALL causes a segfault. Serializing the loops via DO eliminate the segfault. Details below.

Code excerpt

  abserr = 0.0d0
  forall (j=1:order,i=1:order)
      abserr = abserr + (B(i,j) - A(i,j))**2
  endforall
  abserr = sqrt(abserr)

Source Files

bad.txt
good.txt

for i in good bad ; do mv $i.txt $i.f90 ; done

(The original source comes from https://github.com/ParRes/Kernels)

Compile

$ for i in good bad ; do flang -Mpreprocess -O2 \
-DPRKVERSION="'2.16'" $i.f90 -o $i ; done

Bug

$ ./bad 10 1000 32
Parallel Research Kernels version       2.16
Pretty Fortran Matrix transpose: B
Matrix order         =     1000
Number of iterations =       10
Segmentation fault (core dumped)

Fixed

$ ./good 10 1000 32
Parallel Research Kernels version       2.16
Pretty Fortran Matrix transpose: B
Matrix order         =     1000
Number of iterations =       10
Solution validates
Rate (MB/s):   7165.633621 Avg time (s):   0.002233

Version

I recompiled everything a few hours ago.

$ flang -v
clang version 3.9.1 (https://github.com/flang-compiler/clang.git cb5013ead73a56e27eefc282d713ae24095076fa) (https://github.com/llvm-mirror/llvm.git a093ef43dd592b729da46db4ff3057fef9a46023)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/pgi-flang/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64

windows support?

Is windows support likely to be added for this project?

Unable to ./configure: add_library cannot create target "gtest"

Full traceback:

[siddhart@greina0 build]$ cmake ../clang/
-- Found LLVM_CONFIG as /users/siddhart/polly/llvm_build/bin/llvm-config
-- Building with -fPIC
CMake Error at /users/siddhart/polly/llvm_build/lib/cmake/llvm/AddLLVM.cmake:424 (add_library):
  add_library cannot create target "gtest" because an imported target with
  the same name already exists.
Call Stack (most recent call first):
  /users/siddhart/polly/llvm_build/lib/cmake/llvm/AddLLVM.cmake:560 (llvm_add_library)
  /users/siddhart/polly/llvm/utils/unittest/CMakeLists.txt:48 (add_llvm_library)


CMake Error at /users/siddhart/polly/llvm_build/lib/cmake/llvm/AddLLVM.cmake:531 (target_link_libraries):
  Cannot specify link libraries for target "gtest" which is not built by this
  project.
Call Stack (most recent call first):
  /users/siddhart/polly/llvm_build/lib/cmake/llvm/AddLLVM.cmake:560 (llvm_add_library)
  /users/siddhart/polly/llvm/utils/unittest/CMakeLists.txt:48 (add_llvm_library)


-- Configuring incomplete, errors occurred!
See also "/users/siddhart/build/flang/build/CMakeFiles/CMakeOutput.log".
See also "/users/siddhart/build/flang/build/CMakeFiles/CMakeError.log".

CMakeError.log

siddhart@greina0 build]$ cat CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test C_SUPPORTS_WERROR_DATE_TIME failed with the following output:
Change Dir: /users/siddhart/build/flang/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_0846e/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_0846e.dir/build.make CMakeFiles/cmTC_0846e.dir/build
gmake[1]: Entering directory `/home/siddhart/build/flang/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_0846e.dir/src.c.o
/usr/bin/cc    -fPIC -DC_SUPPORTS_WERROR_DATE_TIME   -Werror -Werror=date-time -o CMakeFiles/cmTC_0846e.dir/src.c.o   -c /users/siddhart/build/flang/build/CMakeFiles/CMakeTmp/src.c
cc1: error: -Werror=date-time: no option -Wdate-time
gmake[1]: *** [CMakeFiles/cmTC_0846e.dir/src.c.o] Error 1
gmake[1]: Leaving directory `/home/siddhart/build/flang/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTC_0846e/fast] Error 2

Source file was:
int main(void) { return 0; }
Performing C++ SOURCE FILE Test CXX_SUPPORTS_WERROR_DATE_TIME failed with the following output:
Change Dir: /users/siddhart/build/flang/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_34c49/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_34c49.dir/build.make CMakeFiles/cmTC_34c49.dir/build
gmake[1]: Entering directory `/home/siddhart/build/flang/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_34c49.dir/src.cxx.o
/usr/bin/c++     -fPIC -fvisibility-inlines-hidden -DCXX_SUPPORTS_WERROR_DATE_TIME   -Werror -Werror=date-time -o CMakeFiles/cmTC_34c49.dir/src.cxx.o -c /users/siddhart/build/flang/build/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: -Werror=date-time: no option -Wdate-time
gmake[1]: *** [CMakeFiles/cmTC_34c49.dir/src.cxx.o] Error 1
gmake[1]: Leaving directory `/home/siddhart/build/flang/build/CMakeFiles/CMakeTmp'
gmake: *** [cmTC_34c49/fast] Error 2

Source file was:
int main() { return 0; }

flang seems to ignore F2003 C583

I've tried a number of compiler options to trigger F2003:C583, but have failed. The
following code is invalid for a number of reasons:

   program foo
   integer*4 i(2)
   integer*8 j
   data i/2*Z'55555555'/
   equivalence(j,i)
   print '(2z8)', i
   print '(z16)', j
   end

Neither of the following commands issue warnings/errors.

% flang -c -std=f2003 -Wall -pedantic a.f
% flang -c -std=f95 -Wall -pedantic a.f

Error building Flang

I received the following error message when building Flang on an Intel Xeon SandyBridge machine. I am using the LLVM 4.0 versions of llvm, clang, and openmp compiled with gcc/g++/gfortran 5.3.0.

[ 22%] Building C object tools/flang2/flang2exe/CMakeFiles/flang2.dir/iliutil.c.o
/usr/projects/eap/users/aperry/flang-src/flang/tools/flang2/flang2exe/iliutil.c:1357:11: error: 15 enumeration values not handled in switch: 'MSZ_SBYTE',
'MSZ_SHWORD', 'MSZ_SWORD'... [-Werror,-Wswitch]
switch (*siz) {
^
1 error generated.

tools/flang2/flang2exe/cgmain.c: triple is permanently set to LLVM_DEFAULT_TARGET_TRIPLE in cg_llvm_init()

This arrangement effectively hardens cross-compilation efforts: the LLVM_DEFAULT_TARGET_TRIPLE value is taken from the host LLVM, ignoring "-target" setting passed to Flang's CMake. In effect, cross-compilation environment which quietly does wrong things is created.

Fails to build libxc-3.0.0

Error:

libtool: compile:  flang -O3 -c libxc.f90  -o .libs/libxcf90_la-libxc.o
Lowering Error: unknown operator for LHS or argument [ast=0,asttype=0,datatype=0]
Lowering Error: unexpected data type at load [ast=0,asttype=0,datatype=0]

Please note that the error message doesn't contain the file:line information.

http://www.tddft.org/programs/octopus/download/libxc/
Found on the FreeBSD 11.

flang revision 5af07d4

Fails to build SLATEC Common Mathematical Library: Instruction does not dominate all uses!

flang   -O -c genbun.f -o genbun.o
Instruction does not dominate all uses!
  %.pre126 = sext i32 %64 to i64, !dbg !100
  %208 = shl nsw i64 %.pre126, 2, !dbg !99
fatal error: error in backend: Broken function found, compilation aborted!
clang-3.9: error: clang frontend command failed with exit code 70 (use -v to see invocation)

slatec-4.1

flang was not found in the PATH.

Following instructions in the README.md yields an error that flang cannot be found:

$ cmake -DTARGET_OS=Linux -DTARGET_ARCHITECTURE='x86_64' -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_Fortran_COMPILER=flang ..
-- The C compiler identification is Clang 3.9.1
-- The CXX compiler identification is Clang 3.9.1
-- Check for working C compiler: /usr/lib/ccache/bin/clang
-- Check for working C compiler: /usr/lib/ccache/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LLVM_CONFIG as /usr/bin/llvm-config
-- Performing Test LLVM_NO_OLD_LIBSTDCXX
-- Performing Test LLVM_NO_OLD_LIBSTDCXX - Success
-- Performing Test C_SUPPORTS_FPIC
-- Performing Test C_SUPPORTS_FPIC - Success
-- Performing Test CXX_SUPPORTS_FPIC
-- Performing Test CXX_SUPPORTS_FPIC - Success
-- Building with -fPIC
-- Performing Test SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG
-- Performing Test SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG - Success
-- Performing Test C_SUPPORTS_WERROR_DATE_TIME
-- Performing Test C_SUPPORTS_WERROR_DATE_TIME - Success
-- Performing Test CXX_SUPPORTS_WERROR_DATE_TIME
-- Performing Test CXX_SUPPORTS_WERROR_DATE_TIME - Success
-- Performing Test CXX_SUPPORTS_CXX11
-- Performing Test CXX_SUPPORTS_CXX11 - Success
-- Performing Test C_SUPPORTS_FNO_FUNCTION_SECTIONS
-- Performing Test C_SUPPORTS_FNO_FUNCTION_SECTIONS - Success
-- Performing Test C_SUPPORTS_FFUNCTION_SECTIONS
-- Performing Test C_SUPPORTS_FFUNCTION_SECTIONS - Success
-- Performing Test CXX_SUPPORTS_FFUNCTION_SECTIONS
-- Performing Test CXX_SUPPORTS_FFUNCTION_SECTIONS - Success
-- Performing Test C_SUPPORTS_FDATA_SECTIONS
-- Performing Test C_SUPPORTS_FDATA_SECTIONS - Success
-- Performing Test CXX_SUPPORTS_FDATA_SECTIONS
-- Performing Test CXX_SUPPORTS_FDATA_SECTIONS - Success
-- Found PythonInterp: /usr/bin/python2.7 (found version "2.7.12")
-- Flang version: 3.9.1
-- The ASM compiler identification is Clang
-- Found assembler: /usr/lib/ccache/bin/clang
-- The Fortran compiler identification is unknown
CMake Error at runtime/flang/CMakeLists.txt:17 (enable_language):
  The CMAKE_Fortran_COMPILER:

    flang

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
  path to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "/home/junghans/computing/flang/build/CMakeFiles/CMakeOutput.log".
See also "/home/junghans/computing/flang/build/CMakeFiles/CMakeError.log".

Internal compiler error. gen_funcret: illegal dtype, sym

The following code compiles cleanly for GNU, Intel, and PGI compilers but produces an internal compiler error when compiled with Flang.

module c_binding_module

use iso_c_binding, only : c_double

implicit none

real, parameter :: param  = 2.7182818

type, bind(C) :: myType
   real(c_double) :: param
end type myType

contains

  pure type(myType) function loadMyType() bind(C, name="loadMyType")

    ! implicit conversion from real to c_double                                                                                                                  
    loadMyType%param          = param

  end function loadMyType

end module c_binding_module

The exact error message produced is:

F90-S-0000-Internal compiler error. gen_funcret: illegal dtype, sym     315 (c_binding_module.f90: 22)
  0 inform,   0 warnings,   1 severes, 0 fatal for loadmytype

Commenting out bind(C, name="loadMyType") causes the code to compile cleanly for all four compilers.

Makefile.txt
c_binding_module.f90.txt

Assumed-size local const init'd from expr not supported at f2008 level

Given the following test case mumble.f08:

subroutine mumble
integer, dimension (*), parameter :: foo = (/2, 3, 5/)
end subroutine mumble

where foo is a assumed-size constant ("parameter" would be a misleading term here, I think) initialized from a constant array. Compiled with the following command-line:

flang -std=f2008 -c mumble.f08

I get (with version 460ef03, sorry for not pulling latest) the following error message:

 F90-S-0084-Illegal use of symbol foo - a named constant array must have constant extents (mumble.f08: 2)

It's in our codebase because it is a handy way to code, but I have to admit that I don't know if this is actually in the Fortran 2008 standard, or if it is a letter-after-F vendor extension, so I am prepared that it is put on the wish-list.

Contribution to flang?

Is the contribution to this project "flang" open to anyone or it's restricted to Nvidia/PGI developers ?

Plans to extend OS support beyond Linux?

Thanks for all the work on this exciting project.
Are there any plans for flang to support other OS'es than "Linux", which seems to be the only supported one based on the content of CMakeLists.txt. Specifically, is there any hope for "Darwin" support?

POWER Supported?

I (after a few unsuccessful attempts) managed to compile flang on a POWER8 system.
Unfortunately, the README.md-mentioned Hello World does not compile:

$ flang hello.f90
/gpfs/homeb/zam/aherten/opt/software/llvm+flang/3.9/bin/../lib/libflang.so: undefined reference to `llvm.ppc.vsx.xsnmsubadp'
/gpfs/homeb/zam/aherten/opt/software/llvm+flang/3.9/bin/../lib/libflang.so: undefined reference to `llvm.ppc.vsx.xsmaddadp'
/gpfs/homeb/zam/aherten/opt/software/llvm+flang/3.9/bin/../lib/libflang.so: undefined reference to `llvm.ppc.vsx.xsmaddasp'
/gpfs/homeb/zam/aherten/opt/software/llvm+flang/3.9/bin/../lib/libflang.so: undefined reference to `llvm.ppc.vsx.xsnmsubasp'

Did I do something wrong? Is this a bug? Is the POWER architecture supported at all?

Support for gfortran ABI ?

I built a recent master of flang and tried to build a non trivial piece of fortran code, scipy. The build went well, and I could even run some of the tests, but then the test suite crashes when calling BLASdotu function. I suspect this is because the default BLAS/LAPACK on my debian system is built with the gfortran ABI. Is there a way to control the ABI for emitted code by flang ?

OpenMP reduction segfaults

OpenMP reductions cause a segfault. Serializing the loops or removing the line that performs the reduction eliminate the segfault. Details below.

Code excerpt

  abserr = 0.0
  addit = (0.5*iterations) * (iterations+1)
  !$omp parallel default(none)                                        &
  !$omp&  shared(B)                                                   &
  !$omp&  firstprivate(order,iterations,addit)                        &
  !$omp&  private(i,j,temp)                                           &
  !$omp&  reduction(+:abserr)
  !$omp do collapse(2)
  do j=1,order
    do i=1,order
      temp = ((real(order,REAL64)*real(i-1,REAL64))+real(j-1,REAL64)) &
           * real(iterations+1,REAL64)
      abserr = abserr + abs(B(i,j) - (temp+addit)) ! THIS SEGFAULTS
    enddo
  enddo
  !$omp end do nowait
  !$omp end parallel

Source Files

bad.txt
fix.txt
good.txt

for i in good bad fix ; do mv $i.txt $i.f90 ; done

(The original source comes from https://github.com/ParRes/Kernels)

Compile

$ for i in good bad fix ; do flang -Mpreprocess -O2 \
-DPRKVERSION="'2.16'" -mp $i.f90 -o $i ; done

Bug

$ ./bad 10 1000 32
Parallel Research Kernels version       2.16
Fortran OpenMP Matrix transpose: B = A^T
Number of threads    =       16
Matrix order         =     1000
Tile size            =       32
Number of iterations =       10
Segmentation fault (core dumped)

Remove statement that GDB blames for the segfault

$ ./good 10 1000 32
Parallel Research Kernels version       2.16
Fortran OpenMP Matrix transpose: B = A^T
Number of threads    =       16
Matrix order         =     1000
Tile size            =       32
Number of iterations =       10
Solution validates
Rate (MB/s):  11205.423425 Avg time (s):   0.001428

Serialize the reduction

$ ./fix 10 1000 32
Parallel Research Kernels version       2.16
Fortran OpenMP Matrix transpose: B = A^T
Number of threads    =       16
Matrix order         =     1000
Tile size            =       32
Number of iterations =       10
Solution validates
Rate (MB/s):   6674.982582 Avg time (s):   0.002397

Relationship with llvm-flang

Hi, sorry if this is not the right place to ask, but I can't seem to figure out what's the relationship of this project with https://github.com/llvm-flang/flang. Are they simply two distinct projects with the same name, or do they have common ancestry?

Internal compiler error with array constructor at -O2

$ cat test.f90 
      program ice_corrupt_std
!
      implicit none
      integer :: n
      character(len=7) :: strs(10)
!
      strs(:) = 'hi'
      n = 7
!
      print *, (/ strs(1:n) /)
!
      end program ice_corrupt_std
$
$ flang -O2 test.f90 
F90-S-0000-Internal compiler error. remove_stmt: corrupt STD or deleting statement twice      22 (test.f90: 12)
  0 inform,   0 warnings,   1 severes, 0 fatal for ice_corrupt_std
$
$ flang -O1 test.f90 
$
$ flang --version
clang version 3.9.1 (https://github.com/flang-compiler/clang.git cb5013ead73a56e27eefc282d713ae24095076fa) (https://github.com/llvm-mirror/llvm.git a093ef43dd592b729da46db4ff3057fef9a46023)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /.../llvm/install/bin

Cannot finish cmake

-- Found PythonInterp: /usr/bin/python2.7 (found version "2.7.13") 
-- Flang version: 4.0.0
-- The ASM compiler identification is Clang
-- Found assembler: /home/thomas/JKU/flang/clang/build/bin/clang
-- The Fortran compiler identification is unknown
CMake Error at runtime/flang/CMakeLists.txt:21 (enable_language):
  The CMAKE_Fortran_COMPILER:

    flang

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
  path to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!

It seems like the following line in CMakeLists.txt does not work as intended on my system:

# In order to bootstrap the runtime library we need to skip
# CMake's Fortran tests
SET(CMAKE_Fortran_COMPILER_WORKS 1)

I'm using cmake 3.8.0 and working on a x64 Arch Linux system

Broken links in Release Notes.rst

The following hyperlinks in ReleaseNotes.rst are broken:

• the Flang Team
• Flang 0.0 Release Notes
• Flang Web Site

Incorrect include

https://github.com/flang-compiler/flang/blob/master/runtime/CMakeLists.txt#L43
include_directories($(CMAKE_CURRENT_SOURCE_DIR)/include)
should be
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)

error: unable to execute command: Executable "flang1" doesn't exist!

OS: Fedora 25

!----[start test.f90]----------------------
program main
write(*,*)"ok"
end
!----[end test.f90]----------------------
$ flang test.f90
clang-3.9: error: unable to execute command: Executable "flang1" doesn't exist!

Ability to identify flang by preprocessor

Currently flang only defines __PGIC__, __PGIC_MINOR__ and __PGIC_PATCHLEVEL__ which make it difficult to differentiate flang from the regular PGI compiler.

Given that PGI and flang do have different compiler options available, making that distinction is also useful in regards to CMake support, as CMake right now recognizes it as "PGI 99.99.1", due to this logic and will pass -Mipa=fast, which is not recognized by flang.

Having a way to tell them apart on preprocessor level would solve solve this and also pave the way for eventual first class CMake support.

Cannot run the bitcode

Hello,

For the hello world example, the normal executable works. However, when I do
flang -emit-llvm hello.f90 -c -o hello.bc

and try to run using lli ( lli hello.bc), I get the error message:

'main' function not found in module.

In case of C++, this works as expected. What am I missing here?

problem with OpenMP and the CONTIGUOUS attribute (ICE: ll_make_uplevel_type: character len PARREF not set)

Hi,
please consider this reduced test case:

program test

   implicit none

   type spm
      integer, dimension(:), contiguous, pointer :: ip
   end type

   type(spm) :: spmat
   integer :: i

!$omp parallel do
   do i = 1,100
      call do_something(spmat%ip)
   end do
!$omp end parallel do

contains

   subroutine do_something(arr)
      integer, dimension(:), intent(inout) :: arr
      ! whatever
   end subroutine

end

Compiling with flang -mp gives me:

F90-W-0000-Internal compiler error. ll_make_uplevel_type: character len PARREF not set     306 (test.f90: 12)
F90-F-0000-Internal compiler error. gen_sptr(): unexpected storage type       0 (test.f90: 18)

It goes away if I remove the CONTIGUOUS attribute. The error message is almost identical to the one in #109 (except for the number '306', whatever it means).

Cheers,
Janus

Multiple crashes

See the commit diorcety@3c60ed0
I'm pointing 3 places where there is uninitialized value variable usage.

flang causes clang warnings: clang-3.9: warning: -lflang: 'linker' input unused

flang -Wall -m64 -fPIC -c dsptri.f -o dsptri.o
clang-3.9: warning: -lflang: 'linker' input unused
clang-3.9: warning: -lflangmain: 'linker' input unused
clang-3.9: warning: -lflangrti: 'linker' input unused
clang-3.9: warning: -lompstub: 'linker' input unused
clang-3.9: warning: -lexecinfo: 'linker' input unused
clang-3.9: warning: argument unused during compilation: '-L/usr/local/flang/lib'

• found this on FreeBSD 11.

installation issue: .mod files interfere with other compilers

I have installed flang on an Ubuntu xenial system in the default path (/usr/local). I see that the include directory contains a couple of .mod files for intrinsic modules:

/usr/local/include$ ls *.mod
ieee_arithmetic.mod  ieee_exceptions.mod  ieee_features.mod  iso_c_binding.mod  iso_fortran_env.mod  omp_lib_kinds.mod  omp_lib.mod

The problem with having them in this location is that they can interfere with other compilers. On my system they break ifort, which now spits out stuff like this:

fortcom: Error: This module file was not generated by any release of this compiler.   [ISO_C_BINDING]

I guess it would be more reasonable to rather put the .mod files into a specific subdir for flang, like /usr/local/include/flang, right?

Best regards,
Janus

Please support llvm-4.0

I tried to build and run with llvm-4.0 on the FreeBSD and it works fine.
Unless there are specific llvm-4.0-related failures, please update the supported version.

Building cosp_types.F90 from 527.cam4_r benchmark with -gline-tables-only compiler flag consumes around 60GB of RAM

As in the topic, on smaller AArch64 machines, building cosp_types.F90 file from 527.cam4_r benchmark with -gline-tables-only compiler flag causes flang2 process to get killed by OOM killer. On bigger AArch64 machines it succeeds, however, my examination reveals that its peak demand for memory is around 60GB.

backslash flags wrong

Something wrong with backslash flags:

$ flang -help | grep backslash
  -fbackslash             Treat backslash as C-style escape character
  -fno-backslash          Treat backslash as C-style escape character
  -Mbackslash             Treat backslash like any other character in character strings
  -Mnobackslash           Treat backslash like any other character in character strings
$ cat z.f90
write (*,*) "\"
end
$ flang z.f90
F90-S-0026-Unmatched quote (z.f90: 1)
  0 inform,   0 warnings,   1 severes, 0 fatal for MAIN
$ ./a.out
$ flang -Mbackslash z.f90
F90-S-0026-Unmatched quote (z.f90: 1)
  0 inform,   0 warnings,   1 severes, 0 fatal for MAIN
$ ./a.out
$

pgfortran 16.3-0 has:

-M[no]backslash     Treat backslash like any other character in character strings

$ pgfortran z.f90 
PGF90-S-0026-Unmatched quote (z.f90: 1)
  0 inform,   0 warnings,   1 severes, 0 fatal for MAIN
$ pgfortran -Mbackslash z.f90 
$ ./a.out 
 \
$  

Flang fails to compile ALLOCATE statements in OpenMP parallel region

Following program:

PROGRAM build_test()
  IMPLICIT NONE

  INTEGER :: t

  TYPE my_field_type
     REAL(KIND=8),    DIMENSION(:,:), ALLOCATABLE :: density
  END TYPE my_field_type
  TYPE(my_field_type), DIMENSION(10) :: field

!$OMP PARALLEL
!$OMP DO
  DO t=1,2
    ALLOCATE(field(t)%density(1:10, 1:10))
  ENDDO
!$OMP END DO
!$OMP END PARALLEL

END PROGRAM build_test

Causes following assertion in flang2, it happens only when building with -fopenmp:

F90-W-0000-Internal compiler error. ll_make_uplevel_type: character len PARREF not set     300 (build_test3.f90: 11)
F90-W-0000-Internal compiler error. ll_make_uplevel_type: character len PARREF not set     302 (build_test3.f90: 11)
F90-W-0000-Internal compiler error. ll_make_uplevel_type: character len PARREF not set     303 (build_test3.f90: 11)
F90-S-0000-Internal compiler error. get_llvm_name: bad stype for       1 (build_test3.f90: 19)
F90-F-0000-Internal compiler error. gen_sptr(): unexpected storage type       0 (build_test3.f90: 19)

Apparently, when ALLOCATE statement is used inside of OpenMP parallel region, it can't handle allocatable fields of derived data type variable. A workaround for program above can use Fortran2003 allocate-on-assignment feature to proceed with dynamic allocation. It costs additional allocate/deallocate operation on every allocation within parallel region:

PROGRAM build_test()
  IMPLICIT NONE

  INTEGER :: t

  TYPE my_field_type
     REAL(KIND=8),    DIMENSION(:,:), ALLOCATABLE :: density
  END TYPE my_field_type
  TYPE(my_field_type), DIMENSION(10) :: field

  REAL(KIND=8),    DIMENSION(:,:), ALLOCATABLE :: density

!$OMP PARALLEL
!$OMP DO PRIVATE(density)
  DO t=1,2
    ALLOCATE(density(1:10, 1:10))
    field(t)%density = density
    DEALLOCATE(density)
    field(t)%density(1, 1) = 0.0
  ENDDO
!$OMP END DO
!$OMP END PARALLEL

END PROGRAM build_test

Support for FreeBSD (patches available)

Hi,

I've added the patches I created to compile flang on FreeBSD amd64 in my fork .

Is there a chance of getting them upstream? If so, what rules should I consider?

Thanks!

"Modern" Fortran support

Dear flang team,

First of all I would like to thank you very much for your great work, it is really appreciated.

I opened this issue with the only aim to let you know that I am really interested to use your compiler, but it is currently seems to have limitations about modern Fortran support. In particular, I use a lot of Fortran 2003/2008 OOP features that block me to use your great compiler.

I hope you will find the funding/time to add the support for your compiler.

My best regards.

Internal compiler error. get_int_cval-not ST_CONST

Dear flang team,

compiling the attached file minkowski.f90 (had to rename to txt to attach) with the current master results in an ICE:

$ flang minkowski.f90 
F90-F-0000-Internal compiler error. get_int_cval-not ST_CONST       0 (minkowski.f90: 62)
F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted

I'm pretty sure it's valid Fortran (95?) code. At least I'm aware of four other compilers which can handle it without a problem (gfortran, ifort, sunf95, pgf95). The example is a reduced version of https://github.com/janusw/GiBUU_2016/blob/master/code/numerics/minkowski.f90.

Cheers,
Janus

Internal compiler error. copy_specifics src or dest not user generic or operator

The following compiles cleanly for GNU and Intel compilers, but produces an internal compiler error for both Flang and PGI compilers.

module user_op

 implicit none

  private

  interface myOperator
  end interface

  interface OPERATOR (.myOperator.)
     module procedure myOperator_Real
  end interface

contains

  function myOperator_Real (x, y) result (myOperator)
    real, intent(in) :: x, y
    logical :: myOperator
    myOperator = 1 < 0
    return
  end function myOperator_Real

end module user_op

The exact error message is:

(PG)F90-S-0000-Internal compiler error. copy_specifics src or dest not user generic or operator       0 (user_op.f90)
  0 inform,   0 warnings,   1 severes, 0 fatal for user_op
  0 inform,   0 warnings,   1 severes, 0 fatal for user_op

Removing either one of the interfaces causes the code to compile cleanly for all four compilers.

Makefile.txt
user_op.f90.txt

OpenMP 4.0 task dependencies support

OpenMP 4.0 task dependencies are not currently supported by flang and the clauses are not checked for correctness, e.g. faulty clause referring to non-existing variable is accepted by flang.

Internal compiler error. Unsafe type for inttoptr 32

Hi,

it looks like there is an issue when you combine omp threadprivate common blocks with alternate returns of subroutines. At least that is what I boiled this error down to in the following example. flang as built by the README with llvm 3.9 crashes as follows:

% flang -fopenmp -o test flang.f
F90-F-0000-Internal compiler error. Unsafe type for inttoptr 32 (flang.f: 15)
F90/x86-64 Flang - 1.5 2017-05-01: compilation aborted

The code I use is:

   program hello
    implicit none

    print *, 'hello world'
  end

  subroutine hello(p,*)
    implicit none
    real p
    real :: cutoff
    common/cutoff_common/cutoff

!$omp threadprivate(/cutoff_common/)

    return 1
  end subroutine

If you remove the alternate return (*) it compiles again. If you remove the omp threadprivate it compiles again.

TBAA: wrf miscomparison

Given following example Fortran code:

        PROGRAM MAIN
          IMPLICIT NONE
          REAL, DIMENSION(0:50) :: PXL
          INTEGER :: I

          DO I = 0,50
            PXL(I) = I
          ENDDO
          CALL FOO(PXL,50,2.)
        END PROGRAM

        SUBROUTINE FOO(BUF, LAST, LIMIT)
          IMPLICIT NONE
          REAL, DIMENSION(0:LAST), INTENT(IN) :: BUF
          INTEGER, INTENT(IN) :: LAST
          REAL, INTENT(IN) :: LIMIT

          REAL, DIMENSION(0:LAST) :: TMP
          REAL :: RES
          INTEGER :: J

          RES = 0.
          DO J = 0,LAST
            TMP(J) = BUF(J)
            IF (TMP(J).LT.LIMIT) THEN
              CALL BAR(TMP(J))
            ENDIF
            RES = RES + TMP(J)
          ENDDO

          PRINT *, 'res=', RES
        END

        SUBROUTINE BAR(X)
          IMPLICIT NONE
          REAL, INTENT (INOUT) :: X
          X = X + 5.5
        END

Result printed when built with:

    gfortran -O0, -O1 or -O2: res= 1286.00000
    flang -O0 or -O1: res= 1286.000
    flang -O2: res= 1275.000

The failure looks to be caused by invalid TBAA information generated by flang.

The test generates different results when built with -O2. By manually disabling load elimination within llvm (via DisableGVNLoadPRE) and comparing the resulting IR, you can see that when "bar" is inlined into "foo" the store within L.LB2_361 is assumed not to alias with the load in L.LB2_328 and so the wrong value is used when eliminating the load in L.LB2_331. Looking at the address generation for the memory accesses proves the addresses to be identical but this fact is ignored because of the attached TBAA metadata.

The accesses within block L.LB2_361 are tagged with "!tbaa !10" with relevant the matching accesses within L.LB2_328 and L.LB2_331 tagged with !tbaa !8. Looking at the metadata within either of those files shows there to be no "parent relation" between these tags and thus can be considered non-aliasing. This is not true as "bar" is directly accessing storage allocated under "foo".

ICE: charlen: sym not adjustable-length char

With the current 4.0 (also 3.9) I get an internal compiler error

F90-S-0000-Internal compiler error. charlen: sym not adjustable-length char 324 (bug.f90: 6)
0 inform, 0 warnings, 1 severes, 0 fatal for get_buffer

with this example

subroutine get_buffer(cptr, buflen, buffer)
  use,intrinsic :: iso_c_binding, only: c_char, c_size_t, c_ptr, c_f_pointer
  type(c_ptr), intent(in) :: cptr
  integer(c_size_t), intent(in) :: buflen
  character(:,kind=c_char), pointer, intent(out) :: buffer
  buffer => f_string_pointer(cptr, buflen)
contains
  function f_string_pointer(cptr, len) result(fptr)
    type(c_ptr), intent(in) :: cptr
    integer(c_size_t), intent(in) :: len
    character(len,kind=c_char), pointer :: fptr
    call c_f_pointer(cptr, fptr)
  end function
end subroutine get_buffer

ilmtp.n and ilitp.n files for aarch64 and ppc64le refer non-existing ilmindex.n and iliindex.n files

ilmtp.n for aarch64 and ppc64le both contain following line:

.so ilmindex.n

The ilmindex.n file does not exist. Such line is not present in case of x86_64 ilmtp.n file.

The same situation is with ilitp.n files.

problem with OpenMP and a dummy procedure (ICE: ll_make_uplevel_type: character len PARREF not set)

Another OpenMP-related ICE similar to #109 and #139 ...

module m

   implicit none

CONTAINS

   subroutine insert(a)
      integer, intent(inout) :: a
   end subroutine

   subroutine filter(func)
      interface
         logical function func(j)
            integer, intent(in) :: j
         end function
      end interface
      integer :: i, alt

!$omp parallel do
         do i = 0, 12
            if (func(i)) then
               call insert(alt)
            end if
         end do
!$omp end parallel do

   end subroutine

end module

Compiling with flang -c -mp yields:

F90-W-0000-Internal compiler error. ll_make_uplevel_type: character len PARREF not set       1 (YYYFilter.f90: 19)
  0 inform,   1 warnings,   0 severes, 0 fatal for filter

If I remove 'func' from the argument list of 'filter', the error goes away.

Cheers,
Janus

Debug Build Type cannot be built

I've built LLVM (release_40 branch, SHA f3d3277bb713bb8aced9a7ac2e9b05c52d2844ee) with Clang from flang-compiler (flang_release_40 branch, SHA 1210030915d1e1441d62eea54976f4ced7f6ad88). For this build I've selected -DCMAKE_BUILD_TYPE=Debug in CMake. Then I tried to build Flang (master branch), also with -DCMAKE_BUILD_TYPE=Debug set in CMake. It failed with following error:

[ 36%] Building Fortran object runtime/flang/CMakeFiles/flang_static.dir/ieee_arithmetic.F95.o
fragment covers entire variable
  tail call void @llvm.dbg.value(metadata i32 %1, i64 0, metadata !1064, metadata !1065), !dbg !1059
!1064 = !DILocalVariable(name: "ix", scope: !1060, file: !3, line: 630, type: !28)
!1065 = !DIExpression(DW_OP_LLVM_fragment, 0, 32)
.
.
.
fragment covers entire variable
  tail call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !1330, metadata !1064), !dbg !1326
!1330 = !DILocalVariable(name: "ix", scope: !1327, file: !3, line: 936, type: !28)
!1064 = !DIExpression(DW_OP_LLVM_fragment, 0, 32)
clang-4.0: lib/IR/Verifier.cpp:4498: virtual bool {anonymous}::VerifierLegacyPass::doFinalization(llvm::Module&): Assertion `!V->hasBrokenDebugInfo() && "Module contains invalid debug info"' failed.

WORKAROUND is to set following environmental variables before running cmake:
FFLAGS="-O0"
FCFLAGS="-O0"

UNFORTUNATELY, Flang built that way fails to compile many of the source files when started with -g on the optimization level 2 and higher, due to the same assertion as above ("Module contains invalid debug info").
Example workload that fails to build with -g -O2 using Debug Build Type Flang:
https://codesign.llnl.gov/lulesh/LULESH_serial.F90

Please support the i386 architecture

flang can't be adopted as a mainstream fortran compiler without it, because this major architecture is missing.

Fails to build lapack-3.5.0: F90-W-0130-Floating point underflow

F90-W-0130-Floating point underflow. Check constants and constant expressions (slamch.f: 113)
F90-W-0130-Floating point underflow. Check constants and constant expressions (dlamch.f: 113)
F90-S-0126-Name etime is not an intrinsic function (second_INT_ETIME.f: 53)

Clang error due to missing parentheses

I am building following https://github.com/jeffhammond/flang/blob/install-prefix-docs-fix/README.md, which is equivalent to the standard build except for paths. I updated to the latest HEAD (3ff534c).

[ 30%] Building C object tools/flang1/flang1exe/CMakeFiles/flang1.dir/semsmp.c.o
/home/jrhammon/Work/LLVM/pgi-flang/tools/flang1/flang1exe/semsmp.c:5762:22: error: & has lower precedence than !=; != will be
      evaluated first [-Werror,-Wparentheses]
          (mp_iftype & type != (IF_TARGET | IF_PARALLEL))) {
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jrhammon/Work/LLVM/pgi-flang/tools/flang1/flang1exe/semsmp.c:5762:22: note: place parentheses around the '!=' expression
      to silence this warning
          (mp_iftype & type != (IF_TARGET | IF_PARALLEL))) {
                     ^
                       (                                )
/home/jrhammon/Work/LLVM/pgi-flang/tools/flang1/flang1exe/semsmp.c:5762:22: note: place parentheses around the & expression to
      evaluate it first
          (mp_iftype & type != (IF_TARGET | IF_PARALLEL))) {
                     ^
           (               )
1 error generated.
tools/flang1/flang1exe/CMakeFiles/flang1.dir/build.make:2006: recipe for target 'tools/flang1/flang1exe/CMakeFiles/flang1.dir/semsmp.c.o' failed
make[2]: *** [tools/flang1/flang1exe/CMakeFiles/flang1.dir/semsmp.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:1585: recipe for target 'tools/flang1/flang1exe/CMakeFiles/flang1.dir/all' failed
make[1]: *** [tools/flang1/flang1exe/CMakeFiles/flang1.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

strange messages on ishft call ("iliutil.c: case IL_KISHFT:")

Not sure if this counts as a bug, but if I use flang to compile this fragment ...

   subroutine shift(s)
      integer(8) :: s
      s=ishft(s,21)
   end subroutine

... I see the output ...

iliutil.c: case IL_KISHFT:

... which is kind of confusing. Might be a reminder for implementing a missing case in a switch statement? Looking into iliutil.c, it seems like the implementation is present at least for x86_64. It sounds like other archs will throw an additional error, so maybe the printf output is not really needed for x86_64?

Cheer,
Janus

REAL_KINDS in the ISO_FORTRAN_ENV wrong

flang does not implement REAL_KINDS in the ISO_FORTRAN_ENV intrinsic module correctly.
Consider the following source

program foo
use iso_fortran_env
write(,'(4(I0,1X))') real_kinds
write(,'(4(I0,1X))') integer_kinds
end program foo

This produces
4 8 -1
1 2 4 8

REAL_KINDS(3) = -1 is invalid. REAL_KINDS should be [4 8]. From the F2008 standard:

13.8.2.20 REAL KINDS

The values of the elements of the default integer array constant REAL KINDS are
the kind values supported by the processor for variables of type real. The order of
the values is processor dependent. The rank of the array is one, its lower bound is
one, and its size is the number of real kinds supported.

along with C408 show -1 is invalid.

C408 (R405) The value of scalar-int-constant-expr shall be nonnegative and shall
specify a representation method that exists on the processor.

ARM builds: Stop struct_member* being treated as struct_member**

Due to missing 'else' in tools/flang2/flang2exe/cgmain.c gen_address_operand() function, the tasking tests from OpenMP Validation Site are failing. This affects only ARM builds as the code is guarded by #ifdef TARGET_LLVM_ARM. The 'else' is missing right before #endif.