flang-compiler / flang Goto Github PK
View Code? Open in Web Editor NEWFlang is a Fortran language front-end designed for integration with LLVM.
License: Other
Flang is a Fortran language front-end designed for integration with LLVM.
License: Other
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.
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.
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?
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
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!
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".
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.
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!
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.
Is windows support likely to be added for this project?
See the commit diorcety@3c60ed0
I'm pointing 3 places where there is uninitialized value variable usage.
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.
Is the contribution to this project "flang" open to anyone or it's restricted to Nvidia/PGI developers ?
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
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
\
$
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?
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'
flang can't be adopted as a mainstream fortran compiler without it, because this major architecture is missing.
The following hyperlinks in ReleaseNotes.rst are broken:
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 ?
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
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.
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
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.
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
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.
-- 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
OpenMP reductions cause a segfault. Serializing the loops or removing the line that performs the reduction eliminate the segfault. Details below.
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
for i in good bad fix ; do mv $i.txt $i.f90 ; done
(The original source comes from https://github.com/ParRes/Kernels)
$ for i in good bad fix ; do flang -Mpreprocess -O2 \
-DPRKVERSION="'2.16'" -mp $i.f90 -o $i ; done
$ ./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)
$ ./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
$ ./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
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.
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
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)
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?
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
[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; }
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)
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
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
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
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.
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
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.
$ 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
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.
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?
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.
FORALL
causes a segfault. Serializing the loops via DO
eliminate the segfault. Details below.
abserr = 0.0d0
forall (j=1:order,i=1:order)
abserr = abserr + (B(i,j) - A(i,j))**2
endforall
abserr = sqrt(abserr)
for i in good bad ; do mv $i.txt $i.f90 ; done
(The original source comes from https://github.com/ParRes/Kernels)
$ for i in good bad ; do flang -Mpreprocess -O2 \
-DPRKVERSION="'2.16'" $i.f90 -o $i ; done
$ ./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)
$ ./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
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
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
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.
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".
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.