catastrophic error

[Izaak_Beekman]

I have a suspicion that this might be fixed in a more recent version of ifort, but I am seeing catastrophic errors for the following code.

[fortran]MODULE mymod
IMPLICIT NONE
CONTAINS
FUNCTION mv_char(in) RESULT(out)
CHARACTER(:), POINTER, INTENT(in) :: in
CHARACTER(:), POINTER :: out

ALLOCATE(CHARACTER(LEN(TRIM(ADJUSTL(in)))) :: out)
out = TRIM(ADJUSTL(in))
END FUNCTION mv_char
END MODULE mymod

PROGRAM caterr
USE mymod
IMPLICIT NONE
CHARACTER(:), POINTER :: mystr=>NULL(), foo=>NULL()

ALLOCATE(CHARACTER(3) :: foo)
foo = 'foo'
mystr => mv_char(foo)

END PROGRAM caterr[/fortran] When compiled:
[bash]$ ifort cat_err.f90
cat_err.f90(20): catastrophic error: **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.
mystr => mv_char(foo)
-----------^
compilation aborted for cat_err.f90 (code 3)[/bash] If line 5 is changed from [fortran] CHARACTER(:), POINTER, INTENT(in) :: in[/fortran] to[fortran] CHARACTER(*), POINTER, INTENT(in) :: in[/fortran] I get the following compilation error which i can't understand:
[bash]$ ifort cat_err.f90
cat_err.f90(20): error #8298: If a dummy argument is allocatable or a pointer, the associated actual argument shall have deferred length parameter if and only if the dummy argument has deferred length parameter. [FOO]
mystr => mv_char(foo)
-------------------^
compilation aborted for cat_err.f90 (code 1)[/bash] Is this a bug that has been seen before and is now fixed in the latest release?

In the second form of the code, is the compiler correct in issuing that error?

Thanks,
-Z

[Izaak_Beekman]

I almost forgot to say which version I am using:

[bash]$ ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1    Build 20090630 Package ID: l_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.[/bash]

[TimP]

Yes, a more recent version gives the error message
error #8307: If a dummy argument is allocatable or a pointer, the associated actual argument shall have deferred length parameter if and only if the dummy argument has deferred length parameter. [FOO]
mystr => mv_char(foo)
-------------------------^
compilation aborted

Still perhaps not as explicit as something like "Fortran 77 (*) notation (f90 assumed size) not compatible with POINTER

[Izaak_Beekman]

I'm still a bit confused as to what this means. mystr whether an allocatable scalar or a pointer of type character(:) (same for foo and out) throws this error. What is the correct way to return a variable length string from a function or subroutine?

[TimP]

(:) notation would be right for a length determined at compile time. For a general length Fortran string, len=* is fine, and, in order to support C interop, it's compatible with an assumed size array of char (len=1). The current support of deferred length removes one of the reasons for POINTER, Your example doesn't show your motivation for trying to combine POINTER with one or another type of variable length character string. In some contexts, you might use one or another type of C_PTR, possibly even in a pure Fortran environment.

[Izaak_Beekman]

I have also tried making it allocatable (rather than a pointer) and this fails too. How does one have a variable length string that is intent(out) in a subroutine or a function result? Everything I try gives me a syntax error I don't completely understand or a catastrophic failure.

[Steven_L_Intel1]

The deferred-length character feature, CHARACTER(:), is not implemented in version 11.1. This is a Fortran 2003 feature implemented in version 12.0 and is usually used in conjunction with ALLOCATABLE. It is less useful with POINTER.

I have rewritten your program to use the feature correctly (and added a PRINT of the result). Note that no explicit ALLOCATE is required. (Your original program compiles successfully in version 12.1.)

[fortran]    MODULE mymod 
      IMPLICIT NONE 
    CONTAINS 
      FUNCTION mv_char(in) RESULT(out) 
        CHARACTER(*), INTENT(in) :: in 
        CHARACTER(:), ALLOCATABLE :: out 
     
        out = TRIM(ADJUSTL(in)) 
      END FUNCTION mv_char 
    END MODULE mymod 
     
    PROGRAM caterr 
      USE mymod 
      IMPLICIT NONE 
      CHARACTER(:), ALLOCATABLE:: mystr, foo
       
      foo = 'foo' 
      mystr = mv_char(foo) 
      print *, mystr
     
    END PROGRAM caterr  [/fortran]

[Izaak_Beekman]

Thanks steve. This is what i thought the correct behaviour should be. I need to convince the sys admin to build out the 12.x Intel + MPI toolchain

[Xj_Kong]

Hi, please help with problem when used the both of pointer Character and assumed-length Character as arguments. The pointer character alone works fine, but the assumed-length character cannot pass correctly. So the result string mystr =='foo1' , while it is supposed to be 'foo1foo2'

Thanks.

[Izaak_Beekman]

Which version of the Intel compilers are you using, and how are you building the executable? (What flags etc. are you passing to ifort?) What architecture/OS are you on?

[Steven_L_Intel1]

I can reproduce the problem. Something is not being passed correctly. I will let the developers know. Issue ID is DPD200249515.

[Xj_Kong]

Hi, please help with problem when used the both of pointer Character and assumed-length Character as arguments.

Either the pointer character or  assumed-length character as argument alone works fine, but if there is pointer character before the assumed-length character in the argument list, assumed-length character is blocked and cannot pass correctly. 

I tested the examples under "Compiling with Intel(R) Visual Fortran Compiler XE 13.1.3.198 [IA-32]"

Thanks.

[Xj_Kong]

Thank you very much, Steve! It is the 2nd time I tried to solve problem through this forum and I am really moved that so many warmhearted people are helping each other and IVF really needs this contribution.

Thanks to Zaak. It is your example that excited me to revert back to this issue.

Steve, specially thank you. You have solved countless problems for us and IVF.

Kong

[Steven_L_Intel1]

Kong, the problem you reported is fixed for a release later this year.

[Xj_Kong]

That is great!

Thanks!