Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

flang-new 19 crash when compiling following code #98644

Closed
mfvalin opened this issue Jul 12, 2024 · 9 comments
Closed

flang-new 19 crash when compiling following code #98644

mfvalin opened this issue Jul 12, 2024 · 9 comments
Assignees
@jeanPerier
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] flang:ir

Comments

@mfvalin
Copy link

mfvalin commented Jul 12, 2024

flang-new --version
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 8681202)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm-beta/bin
Build config: +assertions

cat serializer.F90
module rmn_jar
use ISO_C_BINDING
implicit none
private
interface
function libc_malloc(sz) result(ptr) BIND(C, name='malloc')
import :: C_SIZE_T, C_PTR
implicit none
integer(C_SIZE_T), intent(IN), value :: sz
type(C_PTR) :: ptr
end function libc_malloc
end interface
logical, save, private :: debug_mode = .false.

integer, parameter, public :: JAR_ELEMENT = C_INT64_T !< We want 64-bit elements in the jars

!> Same as c_jar, but with type bound procedures
type, public :: jar
    private
    integer(JAR_ELEMENT) :: size_elem = 0             !< capacity of jar, in number of elements
    integer(JAR_ELEMENT) :: top       = 0             !< last posision "written" (cannot write beyond size)
    integer(JAR_ELEMENT) :: bot       = 0             !< last position "read" (cannot read beyond top)
    integer(JAR_ELEMENT) :: opt       = 0             !< option flags (0 owner of data memory, 1 not owner)
    type(C_PTR)          :: ptr       = C_NULL_PTR    !< address of actual data
end type

contains
!> Create a new data jar (size specified with a 64-bit integer), allocate data storage
function jar_new_i8(jar_instance, data_size) result(ok)
implicit none
class(jar), intent(INOUT) :: jar_instance !> Data jar instance
integer(C_INT64_T), intent(IN), value :: data_size !> Number of elements in jar
logical :: ok !> .true. if jar was successfully created, .false. otherwise

    integer(C_SIZE_T)    :: data_size_byte
    integer(JAR_ELEMENT) :: dummy_jar_element

    data_size_byte = data_size * (storage_size(dummy_jar_element) / 8)
    ! size in bytes
    jar_instance%ptr = libc_malloc(data_size_byte)
    ok = .true.
end function jar_new_i8

subroutine jar_print_data(jar_instance, max_elem)
    implicit none
    class(jar), intent(IN) :: jar_instance               !> Data jar instance
    integer(JAR_ELEMENT), intent(IN), value :: max_elem  !> Maximum number of data elements to print

    integer, dimension(:), pointer :: jar_data

    call C_F_POINTER(jar_instance%ptr, jar_data, [jar_instance%size_elem])
end subroutine jar_print_data

end module

flang-new -c serializer.F90
error: loc("/home/software/GITHUB-ECCC/librmn/build/serializer.F90":51:9): 'llvm.call' op result type mismatch: '!llvm.ptr' != 'i64'
error: Lowering to LLVM IR failed
flang-new: /dataCMC/my-llvm/llvm/lib/IR/Instructions.cpp:1296: void llvm::StoreInst::AssertOK(): Assertion `getOperand(1)->getType()->isPointerTy() && "Ptr must have pointer type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:

  1.  Program arguments: /opt/llvm-beta/bin/flang-new -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -resource-dir /opt/llvm-beta/lib/clang/19 -mframe-pointer=all -o serializer.o -x f95-cpp-input serializer.F90

#0 0x0000560d4d4fbdc8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/llvm-beta/bin/flang-new+0x128fdc8)
#1 0x0000560d4d4f98fe llvm::sys::RunSignalHandlers() (/opt/llvm-beta/bin/flang-new+0x128d8fe)
#2 0x0000560d4d4fc76d SignalHandler(int) Signals.cpp:0:0
#3 0x0000154a2133e420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x0000154a20d5800b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x0000154a20d37859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x0000154a20d37729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x0000154a20d37729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x0000154a20d48fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x0000560d51be7e15 (/opt/llvm-beta/bin/flang-new+0x597be15)
#10 0x0000560d51be7c2d llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, llvm::Align, llvm::InsertPosition) (/opt/llvm-beta/bin/flang-new+0x597bc2d)
#11 0x0000560d4d1014e5 llvm::IRBuilderBase::CreateAlignedStore(llvm::Value*, llvm::Value*, llvm::MaybeAlign, bool) (/opt/llvm-beta/bin/flang-new+0xe954e5)
#12 0x0000560d4f43ef49 convertOperationImpl(mlir::Operation&, llvm::IRBuilderBase&, mlir::LLVM::ModuleTranslation&) LLVMToLLVMIRTranslation.cpp:0:0
#13 0x0000560d4f95ed77 mlir::LLVM::ModuleTranslation::convertOperation(mlir::Operation&, llvm::IRBuilderBase&, bool) (/opt/llvm-beta/bin/flang-new+0x36f2d77)
#14 0x0000560d4f95f4fb mlir::LLVM::ModuleTranslation::convertBlockImpl(mlir::Block&, bool, llvm::IRBuilderBase&, bool) (/opt/llvm-beta/bin/flang-new+0x36f34fb)
#15 0x0000560d4f962e2c mlir::LLVM::ModuleTranslation::convertOneFunction(mlir::LLVM::LLVMFuncOp) (/opt/llvm-beta/bin/flang-new+0x36f6e2c)
#16 0x0000560d4f964c06 mlir::LLVM::ModuleTranslation::convertFunctions() (/opt/llvm-beta/bin/flang-new+0x36f8c06)
#17 0x0000560d4f966ff8 mlir::translateModuleToLLVMIR(mlir::Operation*, llvm::LLVMContext&, llvm::StringRef, bool) (/opt/llvm-beta/bin/flang-new+0x36faff8)
#18 0x0000560d4db34fcb Fortran::frontend::CodeGenAction::generateLLVMIR() (/opt/llvm-beta/bin/flang-new+0x18c8fcb)
#19 0x0000560d4db38fb7 Fortran::frontend::CodeGenAction::executeAction() (/opt/llvm-beta/bin/flang-new+0x18ccfb7)
#20 0x0000560d4d53453c Fortran::frontend::FrontendAction::execute() (/opt/llvm-beta/bin/flang-new+0x12c853c)
#21 0x0000560d4d51cee2 Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) (/opt/llvm-beta/bin/flang-new+0x12b0ee2)
#22 0x0000560d4d5387c8 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) (/opt/llvm-beta/bin/flang-new+0x12cc7c8)
#23 0x0000560d4d0bd8d6 fc1_main(llvm::ArrayRef<char const*>, char const*) (/opt/llvm-beta/bin/flang-new+0xe518d6)
#24 0x0000560d4d0bc866 main (/opt/llvm-beta/bin/flang-new+0xe50866)
#25 0x0000154a20d39083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#26 0x0000560d4d0bba6e _start (/opt/llvm-beta/bin/flang-new+0xe4fa6e)
flang-new: error: unable to execute command: Aborted (core dumped)
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 8681202)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm-beta/bin
Build config: +assertions
flang-new: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
flang-new: note: diagnostic msg: /tmp/serializer-bdf1fd
flang-new: note: diagnostic msg: /tmp/serializer-bdf1fd.sh
flang-new: note: diagnostic msg:

(added .txt extension to be able to add diagnostic files)
serializer-bdf1fd.txt
serializer-bdf1fd.sh.txt
@DavidTruby
Copy link
Member

This code doesn't look like it should compile to me at a glance, as the first argument to C_F_POINTER has to have type C_PTR and here has type class(jar). It does seem to be accepted without warning by gfortran though, and in any case we shouldn't ICE on it and should catch in semantics if the code is incorrect.

@EugeneZelenko EugeneZelenko added flang:ir crash Prefer [crash-on-valid] or [crash-on-invalid] and removed new issue labels Jul 12, 2024
@llvmbot
Copy link
Member

llvmbot commented Jul 12, 2024

@llvm/issue-subscribers-flang-ir

Author: None (mfvalin)

> flang-new --version flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 8681202) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/llvm-beta/bin Build config: +assertions

> cat serializer.F90
module rmn_jar
use ISO_C_BINDING
implicit none
private
interface
function libc_malloc(sz) result(ptr) BIND(C, name='malloc')
import :: C_SIZE_T, C_PTR
implicit none
integer(C_SIZE_T), intent(IN), value :: sz
type(C_PTR) :: ptr
end function libc_malloc
end interface
logical, save, private :: debug_mode = .false.

integer, parameter, public :: JAR_ELEMENT = C_INT64_T !&lt; We want 64-bit elements in the jars

!&gt; Same as c_jar, but with type bound procedures
type, public :: jar
    private
    integer(JAR_ELEMENT) :: size_elem = 0             !&lt; capacity of jar, in number of elements
    integer(JAR_ELEMENT) :: top       = 0             !&lt; last posision "written" (cannot write beyond size)
    integer(JAR_ELEMENT) :: bot       = 0             !&lt; last position "read" (cannot read beyond top)
    integer(JAR_ELEMENT) :: opt       = 0             !&lt; option flags (0 owner of data memory, 1 not owner)
    type(C_PTR)          :: ptr       = C_NULL_PTR    !&lt; address of actual data
end type

contains
!> Create a new data jar (size specified with a 64-bit integer), allocate data storage
function jar_new_i8(jar_instance, data_size) result(ok)
implicit none
class(jar), intent(INOUT) :: jar_instance !> Data jar instance
integer(C_INT64_T), intent(IN), value :: data_size !> Number of elements in jar
logical :: ok !> .true. if jar was successfully created, .false. otherwise

    integer(C_SIZE_T)    :: data_size_byte
    integer(JAR_ELEMENT) :: dummy_jar_element

    data_size_byte = data_size * (storage_size(dummy_jar_element) / 8)
    ! size in bytes
    jar_instance%ptr = libc_malloc(data_size_byte)
    ok = .true.
end function jar_new_i8

subroutine jar_print_data(jar_instance, max_elem)
    implicit none
    class(jar), intent(IN) :: jar_instance               !&gt; Data jar instance
    integer(JAR_ELEMENT), intent(IN), value :: max_elem  !&gt; Maximum number of data elements to print

    integer, dimension(:), pointer :: jar_data

    call C_F_POINTER(jar_instance%ptr, jar_data, [jar_instance%size_elem])
end subroutine jar_print_data

end module

> flang-new -c serializer.F90
error: loc("/home/software/GITHUB-ECCC/librmn/build/serializer.F90":51:9): 'llvm.call' op result type mismatch: '!llvm.ptr' != 'i64'
error: Lowering to LLVM IR failed
flang-new: /dataCMC/my-llvm/llvm/lib/IR/Instructions.cpp:1296: void llvm::StoreInst::AssertOK(): Assertion `getOperand(1)->getType()->isPointerTy() && "Ptr must have pointer type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/llvm-beta/bin/flang-new -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -resource-dir /opt/llvm-beta/lib/clang/19 -mframe-pointer=all -o serializer.o -x f95-cpp-input serializer.F90
#0 0x0000560d4d4fbdc8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/llvm-beta/bin/flang-new+0x128fdc8)
#1 0x0000560d4d4f98fe llvm::sys::RunSignalHandlers() (/opt/llvm-beta/bin/flang-new+0x128d8fe)
#2 0x0000560d4d4fc76d SignalHandler(int) Signals.cpp:0:0
#3 0x0000154a2133e420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x0000154a20d5800b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x0000154a20d37859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x0000154a20d37729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x0000154a20d37729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x0000154a20d48fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x0000560d51be7e15 (/opt/llvm-beta/bin/flang-new+0x597be15)
#10 0x0000560d51be7c2d llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, llvm::Align, llvm::InsertPosition) (/opt/llvm-beta/bin/flang-new+0x597bc2d)
#11 0x0000560d4d1014e5 llvm::IRBuilderBase::CreateAlignedStore(llvm::Value*, llvm::Value*, llvm::MaybeAlign, bool) (/opt/llvm-beta/bin/flang-new+0xe954e5)
#12 0x0000560d4f43ef49 convertOperationImpl(mlir::Operation&, llvm::IRBuilderBase&, mlir::LLVM::ModuleTranslation&) LLVMToLLVMIRTranslation.cpp:0:0
#13 0x0000560d4f95ed77 mlir::LLVM::ModuleTranslation::convertOperation(mlir::Operation&, llvm::IRBuilderBase&, bool) (/opt/llvm-beta/bin/flang-new+0x36f2d77)
#14 0x0000560d4f95f4fb mlir::LLVM::ModuleTranslation::convertBlockImpl(mlir::Block&, bool, llvm::IRBuilderBase&, bool) (/opt/llvm-beta/bin/flang-new+0x36f34fb)
#15 0x0000560d4f962e2c mlir::LLVM::ModuleTranslation::convertOneFunction(mlir::LLVM::LLVMFuncOp) (/opt/llvm-beta/bin/flang-new+0x36f6e2c)
#16 0x0000560d4f964c06 mlir::LLVM::ModuleTranslation::convertFunctions() (/opt/llvm-beta/bin/flang-new+0x36f8c06)
#17 0x0000560d4f966ff8 mlir::translateModuleToLLVMIR(mlir::Operation*, llvm::LLVMContext&, llvm::StringRef, bool) (/opt/llvm-beta/bin/flang-new+0x36faff8)
#18 0x0000560d4db34fcb Fortran::frontend::CodeGenAction::generateLLVMIR() (/opt/llvm-beta/bin/flang-new+0x18c8fcb)
#19 0x0000560d4db38fb7 Fortran::frontend::CodeGenAction::executeAction() (/opt/llvm-beta/bin/flang-new+0x18ccfb7)
#20 0x0000560d4d53453c Fortran::frontend::FrontendAction::execute() (/opt/llvm-beta/bin/flang-new+0x12c853c)
#21 0x0000560d4d51cee2 Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) (/opt/llvm-beta/bin/flang-new+0x12b0ee2)
#22 0x0000560d4d5387c8 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) (/opt/llvm-beta/bin/flang-new+0x12cc7c8)
#23 0x0000560d4d0bd8d6 fc1_main(llvm::ArrayRef<char const*>, char const*) (/opt/llvm-beta/bin/flang-new+0xe518d6)
#24 0x0000560d4d0bc866 main (/opt/llvm-beta/bin/flang-new+0xe50866)
#25 0x0000154a20d39083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#26 0x0000560d4d0bba6e _start (/opt/llvm-beta/bin/flang-new+0xe4fa6e)
flang-new: error: unable to execute command: Aborted (core dumped)
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 8681202)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm-beta/bin
Build config: +assertions
flang-new: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
flang-new: note: diagnostic msg: /tmp/serializer-bdf1fd
flang-new: note: diagnostic msg: /tmp/serializer-bdf1fd.sh
flang-new: note: diagnostic msg:

(added .txt extension to be able to add diagnostic files)
serializer-bdf1fd.txt
serializer-bdf1fd.sh.txt

@klausler
Copy link
Contributor

the first argument to C_F_POINTER has to have type C_PTR and here has type class(jar).

The ptr component of that derived type is what's passed and it does have type C_PTR.

@mfvalin
Copy link
Author

mfvalin commented Jul 12, 2024

this is a "reduced" code excerpt from a functional piece of code (tested with gnu C/aocc C/Nvidia C/Intel C)

@DavidTruby
Copy link
Member

The ptr component of that derived type is what's passed and it does have type C_PTR.

So it is, I can't read this afternoon apparently. Ignore my comment above!

@mfvalin
Copy link
Author

mfvalin commented Jul 18, 2024

if this is of any help to pinpoint the problem:

replacing
call C_F_POINTER(jar_instance%ptr, jar_data, [jar_instance%size_elem])
with
integer(C_SIZE_T), dimension(1) :: size_elem
size_elem = jar_instance%size_elem
call C_F_POINTER(jar_instance%ptr, jar_data, size_elem)
allows to compile

size_elem = [jar_instance%size_elem]
is also reported as an error by the compiler

@jeanPerier
Copy link
Contributor

Most likely the same root cause as #97325. I will look at it.

@jeanPerier jeanPerier self-assigned this Jul 18, 2024
@jeanPerier jeanPerier mentioned this issue Jul 23, 2024
Merged
jeanPerier added a commit that referenced this issue Jul 24, 2024
@jeanPerier
[flang] fix C_PTR function result lowering (#100082)
1ead51a 
Functions returning C_PTR were lowered to function returning intptr (i64
on 64bit arch). This caused conflicts when these functions were defined
as returning !fir.ref<none>/llvm.ptr in other compiler generated
contexts (e.g., malloc).

Lower them to return !fir.ref<none>.

This should deal with #97325
and #98644.
llvmbot pushed a commit to llvmbot/llvm-project that referenced this issue Jul 24, 2024
@jeanPerier @llvmbot
[flang] fix C_PTR function result lowering (llvm#100082)
dc9f9c4 
Functions returning C_PTR were lowered to function returning intptr (i64
on 64bit arch). This caused conflicts when these functions were defined
as returning !fir.ref<none>/llvm.ptr in other compiler generated
contexts (e.g., malloc).

Lower them to return !fir.ref<none>.

This should deal with llvm#97325
and llvm#98644.

(cherry picked from commit 1ead51a)
tru pushed a commit to llvmbot/llvm-project that referenced this issue Jul 24, 2024
@jeanPerier @tru
[flang] fix C_PTR function result lowering (llvm#100082)
5f8189c 
Functions returning C_PTR were lowered to function returning intptr (i64
on 64bit arch). This caused conflicts when these functions were defined
as returning !fir.ref<none>/llvm.ptr in other compiler generated
contexts (e.g., malloc).

Lower them to return !fir.ref<none>.

This should deal with llvm#97325
and llvm#98644.

(cherry picked from commit 1ead51a)
yuxuanchen1997 pushed a commit that referenced this issue Jul 25, 2024
@jeanPerier @yuxuanchen1997
[flang] fix C_PTR function result lowering (#100082)
3fa709a 
Summary:
Functions returning C_PTR were lowered to function returning intptr (i64
on 64bit arch). This caused conflicts when these functions were defined
as returning !fir.ref<none>/llvm.ptr in other compiler generated
contexts (e.g., malloc).

Lower them to return !fir.ref<none>.

This should deal with #97325
and #98644.

Test Plan: 

Reviewers: 

Subscribers: 

Tasks: 

Tags: 


Differential Revision: https://phabricator.intern.facebook.com/D60250769
Harini0924 pushed a commit to Harini0924/llvm-project that referenced this issue Aug 1, 2024
@jeanPerier @Harini0924
[flang] fix C_PTR function result lowering (llvm#100082)
1a748c9 
Functions returning C_PTR were lowered to function returning intptr (i64
on 64bit arch). This caused conflicts when these functions were defined
as returning !fir.ref<none>/llvm.ptr in other compiler generated
contexts (e.g., malloc).

Lower them to return !fir.ref<none>.

This should deal with llvm#97325
and llvm#98644.
@hakostra
Copy link

The code now compiles without any errors on a recent main branch build of flang-new:

$ flang-new --version
flang-new version 20.0.0git (https://github.com/llvm/llvm-project.git 7792b4ae79e5ac9355ee13b01f16e25455f8427f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/llvm-project/install/bin

@jeanPerier
Copy link
Contributor

Fixed by #100082. Thanks for the fix verification @hakostra.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jeanPerier jeanPerier

Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] flang:ir
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@DavidTruby @mfvalin @hakostra @EugeneZelenko @jeanPerier @klausler @llvmbot