[flang][ICE] Unexpected interaction between two subroutines

[pawosm-arm]

Hello,

I've found a piece of Fortran code which exposes a puzzling behavior of the flang-new compiler:

MODULE minimal

  USE, INTRINSIC :: ISO_C_BINDING, ONLY: c_ptr, c_null_ptr, c_size_t

  INTERFACE
    FUNCTION c_malloc(size) BIND(C, name = 'malloc')
      IMPORT :: c_ptr, c_size_t
      IMPLICIT NONE
      INTEGER(c_size_t), VALUE :: size
      TYPE(c_ptr) :: c_malloc
    END FUNCTION
  END INTERFACE

CONTAINS
  SUBROUTINE something1(la, ia)
    LOGICAL, INTENT(OUT) :: la(1)
    INTEGER, INTENT(IN) :: ia(1)

    la = ia
  END SUBROUTINE

  SUBROUTINE something2()
    TYPE(c_ptr) :: ptr

    ptr = c_malloc(1)
  END SUBROUTINE
END MODULE

Trying to compile this results in an ICE:

error: loc("minimal.f90":19:5): 'llvm.call' op result type mismatch: '!llvm.ptr' != 'i64'
error: Lowering to LLVM IR failed
flang-new: llvm-project/llvm/lib/IR/Instructions.cpp:2444: void llvm::InsertValueInst::init(llvm::Value*, llvm::Value*, llvm::ArrayRef<unsigned int>, const llvm::Twine&): Assertion `ExtractValueInst::getIndexedType(Agg->getType(), Idxs) == Val->getType() && "Inserted value must match indexed type!"' failed.

It is sufficient to either replace the ptr = c_malloc(1) line with the ptr = c_null_ptr line in the something2 subroutine or remove the la = ia line in the something1 subroutine to make this problem go away. Also, replacing the LOGICAL and INTEGER types in something1 with matching types (e.g. with both LOGICAL or both INTEGER) makes the problem go away.

I've also tried the explicit bbc -> tco -> opt -> llc path, and the ICE did not occur.

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Paul Osmialowski (pawosm-arm)

Hello,

I've found a piece of Fortran code which exposes a puzzling behavior of the flang-new compiler:

MODULE minimal

  USE, INTRINSIC :: ISO_C_BINDING, ONLY: c_ptr, c_null_ptr, c_size_t

  INTERFACE
    FUNCTION c_malloc(size) BIND(C, name = 'malloc')
      IMPORT :: c_ptr, c_size_t
      IMPLICIT NONE
      INTEGER(c_size_t), VALUE :: size
      TYPE(c_ptr) :: c_malloc
    END FUNCTION
  END INTERFACE

CONTAINS
  SUBROUTINE something1(la, ia)
    LOGICAL, INTENT(OUT) :: la(1)
    INTEGER, INTENT(IN) :: ia(1)

    la = ia
  END SUBROUTINE

  SUBROUTINE something2()
    TYPE(c_ptr) :: ptr

    ptr = c_malloc(1)
  END SUBROUTINE
END MODULE

Trying to compile this results in an ICE:

error: loc("minimal.f90":19:5): 'llvm.call' op result type mismatch: '!llvm.ptr' != 'i64'
error: Lowering to LLVM IR failed
flang-new: llvm-project/llvm/lib/IR/Instructions.cpp:2444: void llvm::InsertValueInst::init(llvm::Value*, llvm::Value*, llvm::ArrayRef<unsigned int>, const llvm::Twine&): Assertion `ExtractValueInst::getIndexedType(Agg->getType(), Idxs) == Val->getType() && "Inserted value must match indexed type!"' failed.

It is sufficient to either replace the ptr = c_malloc(1) line with the ptr = c_null_ptr line in the something2 subroutine or remove the la = ia line in the something1 subroutine to make this problem go away. Also, replacing the LOGICAL and INTEGER types in something1 with matching types (e.g. with both LOGICAL or both INTEGER) makes the problem go away.

I've also tried the explicit bbc -> tco -> opt -> llc path, and the ICE did not occur.

[llvmbot]

@llvm/issue-subscribers-bug

Author: Paul Osmialowski (pawosm-arm)

Hello,

I've found a piece of Fortran code which exposes a puzzling behavior of the flang-new compiler:

MODULE minimal

  USE, INTRINSIC :: ISO_C_BINDING, ONLY: c_ptr, c_null_ptr, c_size_t

  INTERFACE
    FUNCTION c_malloc(size) BIND(C, name = 'malloc')
      IMPORT :: c_ptr, c_size_t
      IMPLICIT NONE
      INTEGER(c_size_t), VALUE :: size
      TYPE(c_ptr) :: c_malloc
    END FUNCTION
  END INTERFACE

CONTAINS
  SUBROUTINE something1(la, ia)
    LOGICAL, INTENT(OUT) :: la(1)
    INTEGER, INTENT(IN) :: ia(1)

    la = ia
  END SUBROUTINE

  SUBROUTINE something2()
    TYPE(c_ptr) :: ptr

    ptr = c_malloc(1)
  END SUBROUTINE
END MODULE

Trying to compile this results in an ICE:

error: loc("minimal.f90":19:5): 'llvm.call' op result type mismatch: '!llvm.ptr' != 'i64'
error: Lowering to LLVM IR failed
flang-new: llvm-project/llvm/lib/IR/Instructions.cpp:2444: void llvm::InsertValueInst::init(llvm::Value*, llvm::Value*, llvm::ArrayRef<unsigned int>, const llvm::Twine&): Assertion `ExtractValueInst::getIndexedType(Agg->getType(), Idxs) == Val->getType() && "Inserted value must match indexed type!"' failed.

It is sufficient to either replace the ptr = c_malloc(1) line with the ptr = c_null_ptr line in the something2 subroutine or remove the la = ia line in the something1 subroutine to make this problem go away. Also, replacing the LOGICAL and INTEGER types in something1 with matching types (e.g. with both LOGICAL or both INTEGER) makes the problem go away.

I've also tried the explicit bbc -> tco -> opt -> llc path, and the ICE did not occur.

[pawosm-arm]

I've tried this with gfortran, but it's very explicit regarding integer types, so it needed a slight change in the something2 subroutine:

  SUBROUTINE something2()
    TYPE(c_ptr) :: ptr
    INTEGER(c_size_t), PARAMETER :: size = 1

    ptr = c_malloc(size)
  END SUBROUTINE

Nevertheless, this slight change does not prevent the ICE in flang-new, while gfortran is able to compile the entire module.

[pawosm-arm]

Turned out, tco works with -O2 by default. I've tried to compile this code with flang-new -O2 and it worked!

[Leporacanthicus]

Turned out, tco works with -O2 by default. I've tried to compile this code with flang-new -O2 and it worked!

Worked as in "compiles to something that doesn't ICE" - does it actually make sense? And does it fail with -O1 in tco?

[pawosm-arm]

Sadly, -O2 has been hardcoded

llvm-project/flang/tools/tco/tco.cpp

Line 136 in 5ee53d4

MLIRToLLVMPassPipelineConfig config(llvm::OptimizationLevel::O2);

[Leporacanthicus]

Sadly, -O2 has been hardcoded

llvm-project/flang/tools/tco/tco.cpp

Line 136 in 5ee53d4

MLIRToLLVMPassPipelineConfig config(llvm::OptimizationLevel::O2);

Oh, that's not useful... I wonder if we should make a change - but I guess it's more important to figure out why it fails in -O1 (which I think is the default in flang-new)

[jeanPerier]

The issue may be exposed by O2, but this is not related. You can crash with flang-new -c [edit: regardless of -O levels] if you add the following to your example:

  subroutine test(x, y)
    real :: x(:), y(:)
    call bar(x+y)
  end subroutine

We should change the way TYPE(C_PTR) results are handled in FIR. The AbstractResult pass is rewriting them here to integer results, which is "OK"
if this hits the assembly stage without meeting a conflicting usage. But malloc is inserted with the correct signature when lowering fir.allocmem (and probably other things), which conflicts.

edit: The -O difference probably comes from the fact that fir.allocmem are "raised" to alloca when possible here, which prevents the introduction of the conflicting malloc usage.