flang fails to lower to FIR on empty module contains

[jcapriot]

On using flang version 18.1.2 on Windows, distributed through conda-forge I am unable to compile a fortran module with an empty contains section, it fails to lowering.

For example, this simple code fails:

module test
integer, public :: N
end module

with the error message:

error: loc("Path\to\test.f90":2:20): block with no terminator, has "fir.has_value"(%0) : (i32) -> ()
error: verification of lowering to FIR failed

This also fails (with the same error):

module test
integer, public :: N
contains
end module

But this compiles just fine:

module test
integer, public :: N
contains
subroutine _placeholder()
end subroutine
end module

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Joseph Capriotti (jcapriot)

On using `flang` version `18.1.2` on Windows, distributed through `conda-forge` I am unable to compile a fortran module with an empty contains section, it fails to lowering.

For example, this simple code fails:

module test
integer, public :: N
end module

with the error message:

error: loc("Path\to\test.f90":2:20): block with no terminator, has "fir.has_value"(%0) : (i32) -> ()
error: verification of lowering to FIR failed

This also fails (with the same error):

module test
integer, public :: N
contains
end module

But this compiles just fine:

module test
integer, public :: N
contains
subroutine _placeholder()
end subroutine
end module

[jeanPerier]

Thanks for the bug report. I could not reproduce on Linux. The error message is weird since ""fir.has_value" is a terminator.... there may be some undefined behavior hit here.

Could you try the following with your set-up: flang -fc1 -emit-llvm -mmlir --mlir-print-ir-after-failure -o - repro.mlir

Where repro.mlir is:

fir.global @_QMtestEn : i32 {
  %0 = fir.zero_bits i32
  fir.has_value %0 : i32
}

Could you also do flang -fc1 -emit-hlfir -mmlir --mlir-print-ir-after-failure -o - test.f90, where test.f90 is your failing example above, and provide the dumped IR if this command fails?

[jcapriot]

Output of the first command is:

> flang-new -fc1 -emit-llvm -mmlir --mlir-print-ir-after-failure -o - repro.mlir
warning: overriding the module target triple with x86_64-pc-windows-msvc [-Woverride-module]
; ModuleID = 'FIRModule'
source_filename = "FIRModule"
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

@_QMtestEn = global i32 0

; Function Attrs: nocallback nofree nosync nounwind willreturn
declare ptr @llvm.stacksave.p0() #0

; Function Attrs: nocallback nofree nosync nounwind willreturn
declare void @llvm.stackrestore.p0(ptr) #0

attributes #0 = { nocallback nofree nosync nounwind willreturn }

!llvm.module.flags = !{!0}

!0 = !{i32 2, !"Debug Info Version", i32 3}

second command give the same issue as before:

> flang-new -fc1 -emit-hlfir -mmlir --mlir-print-ir-after-failure -o - test.f90
error: loc("Path\\to\\test.f90":2:20): block with no terminator, has "fir.has_value"(%0) : (i32) -> ()
error: verification of lowering to FIR failed

[jcapriot]

So I went through the hoops to build flang myself from source and I'm not getting this error. I suspect it's something to do with an error somewhere in how flang is built on conda-forge.

[jeanPerier]

Thank you @jcapriot for the providing the output and testing with sources from llvm. It could also be a bug that made it in 18.1.2 release but was fixed since then.

[h-vetinari]

Just got made aware of this issue - feel free to ping me for conda-forge related things. I'm not aware of any "mistake" (or substantial divergence from the default) in building flang in conda-forge, so I'm very interested in fixing this. I encountered something similar in #86463.

So I went through the hoops to build flang myself from source and I'm not getting this error.

Can I ask, did you build flang from main or from the 18.x tags (resp. release branch)? If it's built from main, then obviously there are many changes that happened since 18.x branched, so could have been fixed since then, without necessarily implying an error on the part of the conda-forge packaging (though I'm not ruling that out of course!).

[jcapriot]

Just got made aware of this issue - feel free to ping me for conda-forge related things. I'm not aware of any "mistake" (or substantial divergence from the default) in building flang in conda-forge, so I'm very interested in fixing this. I encountered something similar in #86463.

So I went through the hoops to build flang myself from source and I'm not getting this error.

Can I ask, did you build flang from main or from the 18.x tags (resp. release branch)? If it's built from main, then obviously there are many changes that happened since 18.x branched, so could have been fixed since then, without necessarily implying an error on the part of the conda-forge packaging (though I'm not ruling that out of course!).

My working example previously was built off of main. But I've now just re-compiled locally for the 18.1.3 tagged release and tested it against that built version and there is no error.

I then went and installed flang 18.1.3 from conda-forge (in a completely separate environment etc. so I know there's no mixing between my local build and the conda-build), and I get the same issue. It would seem then that there is some inconsistency with the build. Therefore I will open an issue there and provide more details.