Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28794 Discussions

ICE with assigning a character pointer

Arjen_Markus
Honored Contributor I
720 Views

I tried to solve a problem with character length mismatches via a pointer assignment. In FORTRAN 77 or with assumed-length strings this is not a particular problem, but we wanted to be more strict. So I thought I could do this by defining a pointer for strings of length A and let it point to strings of length B. That does not work - gfortran refuses to compile it with a proper error message, but Intel oneAPI gives an ICE, both ifort and ifx and version 2023.1.0 and 2024.0.0.

Here is the program:

! chkstring.f90 --
!     Convert a character string via a pointer?
!
program chkstring
    implicit none

    character(len=1), target   :: c(100)
    character(len=12), pointer :: pc(:)

    c = '1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ'

    pc(1:100/len(pc))(1:12) => c

    write(*,*) pc(1)
    write(*,*) pc(2)
end program chkstring

 

As you can see, it is a very simple program, but the output I get is:

ifx -o chkstring chkstring.f90
          #0 0x000000000232d5da
          #1 0x0000000002394df7
          #2 0x0000000002394dc6
          #3 0x000000000237f88c
          #4 0x0000000002437730
          #5 0x000000000243726b
          #6 0x00000000023d2f57
          #7 0x00000000023d26bc
          #8 0x00000000023e12fa
          #9 0x00000000023e3305
         #10 0x00000000023e38e5
         #11 0x00000000023e605d
         #12 0x00000000023e3305
         #13 0x00000000023e06aa
         #14 0x00000000023e3305
         #15 0x00000000022703e6
         #16 0x000000000226fd9e
         #17 0x0000000002452e7e
         #18 0x00007fa72e6e7d85 __libc_start_main + 229
         #19 0x00000000020ab129

chkstring.f90(1): error #5623: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
! chkstring.f90 --
^
compilation aborted for chkstring.f90 (code 3)

SImilar but shorter with ifort.

1 Solution
FortranFan
Honored Contributor III
695 Views

@Arjen_Markus ,

It goes without further elaboration Intel Support Team will be keen to address the ICE and get the processor to provide meaningful response(s) to the code which is decidedly problematic.

First, note your "c = '123..'" assignment is simply equivalent to c(1) = '1'; c(2) = '1'; c(3) = '1'; .. , c(100) = '1'.

Re: "defining a pointer for strings of length A and let it point to strings of length B. That does not work," I suggest you consider the following that based on a rather quick analysis per my mental compiler is standard-conforming:

 

   use, intrinsic :: iso_c_binding, only : c_loc, c_f_pointer
   character(len=:), allocatable :: dat
   character(len=1), target :: c(100)
   character(len=12), pointer :: pc(:)
   integer :: i
   dat = "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"
   c = "" ; c(1:len(dat)) = [( dat(i:i), i = 1, len(dat) )]
   call c_f_pointer( cptr=c_loc(c), fptr=pc, shape=[ len(c)*size(c)/len(pc) ] )
   print *, "c: ", c
   print *, "pc: ", pc
   print *, "size(pc) = ", size(pc)
end

 

  • Response below using gfortran

 

C:\temp>gfortran -ffree-form p.f -o p.exe

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
 size(pc) =            8

 

  • Response using Intel processors below, both IFORT and IFX:

 

C:\temp>ifort /free /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 size(pc) =  8

C:\temp>ifx /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0 Build 20230627
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 size(pc) =  8

 

If you have access to NAG compiler, I suggest you try this code out with that compiler as well.

View solution in original post

3 Replies
FortranFan
Honored Contributor III
696 Views

@Arjen_Markus ,

It goes without further elaboration Intel Support Team will be keen to address the ICE and get the processor to provide meaningful response(s) to the code which is decidedly problematic.

First, note your "c = '123..'" assignment is simply equivalent to c(1) = '1'; c(2) = '1'; c(3) = '1'; .. , c(100) = '1'.

Re: "defining a pointer for strings of length A and let it point to strings of length B. That does not work," I suggest you consider the following that based on a rather quick analysis per my mental compiler is standard-conforming:

 

   use, intrinsic :: iso_c_binding, only : c_loc, c_f_pointer
   character(len=:), allocatable :: dat
   character(len=1), target :: c(100)
   character(len=12), pointer :: pc(:)
   integer :: i
   dat = "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"
   c = "" ; c(1:len(dat)) = [( dat(i:i), i = 1, len(dat) )]
   call c_f_pointer( cptr=c_loc(c), fptr=pc, shape=[ len(c)*size(c)/len(pc) ] )
   print *, "c: ", c
   print *, "pc: ", pc
   print *, "size(pc) = ", size(pc)
end

 

  • Response below using gfortran

 

C:\temp>gfortran -ffree-form p.f -o p.exe

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
 size(pc) =            8

 

  • Response using Intel processors below, both IFORT and IFX:

 

C:\temp>ifort /free /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.10.0 Build 20230609_000000
Copyright (C) 1985-2023 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 size(pc) =  8

C:\temp>ifx /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.2.0 Build 20230627
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
 c: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 pc: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

 size(pc) =  8

 

If you have access to NAG compiler, I suggest you try this code out with that compiler as well.

Arjen_Markus
Honored Contributor I
664 Views

Thank you! I admit I simply overlooked that the somewhat stupid assignment of the characters would not have the intended effect, but then my focus was on the ICE.

Your solution is ingenious :). I had not thought of going that route.

0 Kudos
Barbara_P_Intel
Employee
642 Views

I filed a bug on the ICE, CMPLRLLVM-54004. Compiler shouldn't do that!

Nice workaround, @FortranFan.



0 Kudos
Reply