gfortran: internal compiler error (ICE) for assumed-size type specification n ALLOCATE statement

[FortranFan]

Fyi, here's an internal compiler error with another type with length parameters, the (in)famous CHARACTER variable, for a code example that is equivalent to that in Bug 82649 - (PDT) Invalid error for assumed parameters in ALLOCATE typespec:

--- begin example ---
character(len=42), allocatable :: foo

call alloc( foo )

print *, "len(foo) = ", len(foo), "; expected = 42"

contains

subroutine alloc( bar )

character(len=*), allocatable :: bar

allocate( character(len=*) :: bar )

end subroutine

end
--- end example ---

Compilation output:

gfortran.exe -g p.f90 -o p.o
p.f90:13:0:
allocate( character(len=*) :: bar )

internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


Upon compilation and execution with Intel Fortran, the output is:

len(foo) = 42 ; expected = 42


P.S.> Over the last 2-3 years, I've made several attempts to open an account at GCC Bugzilla site and have been rejected, now I refuse to try!!! :-))
https://www.brainyquote.com/quotes/quotes/g/grouchomar122546.html

[paul.rich...@gmail.com]

This is Bug #82934 and it will be fixed on 8.0.0 by the time you read this. 6- and 7-branches will follow shortly.

Thanks

Paul

[Ev. Drikos]

On 09/11/2017 22:00, FortranFan wrote:
> ... >
> --- begin example ---
> ...
> --- end example ---
> ...

> internal compiler error: Segmentation fault

> ...

In case someone needs to bypass that problem, there is always the option
of gfortran 4.8.5 on RHEL,CentOS, & compatible systems.

An unofficial up to date porting for macOS 10.12 (perhaps 10.13) can be
found at github/pc :-)

[Ev. Drikos]

On 10/11/2017 14:45, Ev. Drikos wrote:

> An unofficial up to date porting for macOS 10.12 (perhaps 10.13) can be
> found at github/pc :-)
>

The address isn't accurate (perhaps, too much laughing):
https://github.com/drikosev/pc

[paul.rich...@gmail.com]

This was just done.

Paul

[Blokbuster]

For general interest (I'm not making demands!), I recently raised a couple of character-related ICEs on bugzilla, 82923 (automatic allocation of a deferred-length character array from a function result) and 82814 (submodule character function).

cheers
WB

[FortranFan]

On Tuesday, November 14, 2017 at 1:10:31 PM UTC-5, paul.rich...@gmail.com wrote:

> ..

>
> This was just done.
>
> Paul

Super, great effort!

[paul.rich...@gmail.com]

Thanks WB! We are going through the reports as fast as we can. I was aware of PR82814 as part of my submodule "after-sales" service. I'll take a look at PR82923 but make no promises.

Best regards

Paul

[FortranFan]

On Tuesday, November 14, 2017 at 1:10:31 PM UTC-5, paul.rich...@gmail.com wrote:

> ..

> This was just done. ..


@Paul,

You're really on a roll and I was wondering if you can be convinced to fix a long outstanding issue in gfortran with named constants of a derived type with a fixed length character type component. Here's a reproducer:

--- begin case ---
integer, parameter :: ell = 42

type :: t
character(len=ell) :: s
end type t

type(t), parameter :: foo = t( "a" )

print *, "length of foo%s = ", len(foo%s), ", expected length is ", ell

end
--- end case ---

Upon execution of compilation output using GCC version 8.0.0 (experimental), the result is

--- begin output ---
length of foo%s = 1 , expected length is 42
--- end output ---

Please note the above code conforms to the Fortran 95 standard (and I would have to check, it might conform to the Fortran 90 revision as well). When code built with Compaq Visual Fortran compiler dated 2001, the output is the following which, as you can expect, agrees with that using the latest Intel Fortran compiler 18.0 update 1:

length of foo%s = 42 , expected length is 42

It'll be cool if this gfortran issue can finally be resolved.

Thanks much,

[steve kargl]

FortranFan wrote:

> Fyi, here's an internal compiler error with another type with length parameters, the (in)famous CHARACTER variable, for a code example that is equivalent to that in Bug 82649 - (PDT) Invalid error for assumed parameters in ALLOCATE typespec:
>
> --- begin example ---
> character(len=42), allocatable :: foo
>
> call alloc( foo )
>
> print *, "len(foo) = ", len(foo), "; expected = 42"
>
> contains
>
> subroutine alloc( bar )
>
> character(len=*), allocatable :: bar
>
> allocate( character(len=*) :: bar )
>
> end subroutine
>
> end
> --- end example ---
>
> Compilation output:
>
> gfortran.exe -g p.f90 -o p.o
> p.f90:13:0:
> allocate( character(len=*) :: bar )
>
> internal compiler error: Segmentation fault
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
>
>
> Upon compilation and execution with Intel Fortran, the output is:
>
> len(foo) = 42 ; expected = 42
>

Did you report the bug to Intel? The code is invalid.
But, I suppose a compiler can choose to do anything
as this doesn't violate a numbered constraint.

--
steve

[steve kargl]

The bug has been re-open. ;-)

--
steve

[FortranFan]

On Thursday, December 7, 2017 at 7:40:23 PM UTC-5, steve kargl wrote:

> On Thursday, November 9, 2017 at 3:00:40 PM UTC-5, FortranFan wrote
> ..
>
> Did you report the bug to Intel? The code is invalid. ..


I disagree with @steve kargl's comment above: my own understanding per current Fortran standard is the code in the original post is conforming and as such I don't see any basis whatsoever to report a bug to Intel.

[steve kargl]

Apologies to FortranFan. I went looking for a number constraint and
somehow completely missed F2008:C631 (R626). I'll blame it on the
cold medicine I've been taking.

It, however, turns out Paul's fix for the bug is incomplete, and needs some
adjustment to actually enforce C631.

--
steve

[steve kargl]

PS: One might argument that it is a defect in the F2008 standard. Page 50
has

R401 type-param-value is scalar-int-expr
or *
or :
...

An asterisk as a type-param-value specifies that a length type
parameter is an assumed type parameter. It is used for a dummy
argument to assume the type parameter value from the effective
argument, for an associate name in a SELECT TYPE construct to
assume the type parameter value from the corresponding selector,
and for a named constant of type character to assume the character
length from the constant-expr.

Note, the above paragraph says nothing about a type-spec in an
ALLOCATE statement.

[FortranFan]

On Friday, December 8, 2017 at 1:22:58 PM UTC-5, steve kargl wrote:

> ..
> PS: One might argument that it is a defect in the F2008 standard. ..


On this aspect at least, I don't find any defect in the standard. The issue at hand is an internal compiler error, an ICE that is always a compiler error, with the ALLOCATE statement. And the section on ALLOCATE statement is as clear and descriptive and prescriptive as all the other good parts of the standard.

[kargl]

I never claimed that the the ICE wasn't a bug. I claimed your code
was invalid based on reading Section 7.2, where the possible use
cases of an asterick are listed. Using an asterick in a type-spec in an
ALLOCATE statement is not among the use cases listed. Thus, I drew
an erroneous conclusion from the Fortran Standard that your code
was invalid. The defet in the Standard is that the paragraph with
use cases should either list all possible uses of an asterick or it
should be removed, so a reader won't draw a wrong conclusion.

PS: Paul fixed the ICE (the hard part). I fixed the bug.
You're welcomed.

--
steve

[FortranFan]

On Saturday, December 9, 2017 at 2:49:53 PM UTC-5, kargl wrote:

> .. The defet in the Standard is that the paragraph with

> use cases should either list all possible uses of an asterick or it

> should be removed, so a reader won't draw a wrong conclusion. ..


"all possible uses" not listed in the standard is not a defect.

The point about "use cases should .. list all possible uses" can be a suggestion to make the standard more reader-friendly that perhaps the Fortran standards committee might consider, good luck with that.

But again on the aspect about the ALLOCATE section in the standard in conjunction with the use of asterisk in the length-type parameter specification, there is no defect in the standard

[spectrum]

I even didn't know that CHARACTER(*) could be used in ALLOCATE statement...
If the above interpretation is right, does this possibly belong to
an "undefined behavior" (processor-dependent) category...?

# People in JISCmail seems to assume the use of character(*) in allocate() is OK.
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90

---
Some code I have tried:

module test_m
implicit none
contains

subroutine sub( s )
character(*), allocatable :: s
print *
print *, "sub: len(s) (upon entry) =", len( s )

if ( allocated( s ) ) then
print *, "sub: s = ", s, " len =", len(s)
else
print *, "sub: allocating s"
allocate( character(*) :: s )
s = "hello-from-sub"
endif

print *, "sub: s (upon exit) = ", s
print *
endsubroutine

endmodule

program main
use test_m
implicit none
character(10), allocatable :: s1, s2

allocate( s1 )
s1 = "hi"
print *, "main: s1 (before call) = ", s1
call sub( s1 )
print *, "main: s1 (after call) = ", s1

call sub( s2 )
print *, "main: s2 (after call) = ", s2
!! gfort-7.2 : ICE (on OSX10.11, installed via homebrew)
!! pgi-2017.4, oracle12.5, ifort16 : gives the following output
end

main: s1 (before call) = hi

sub: len(s) (upon entry) = 10
sub: s = hi len = 10
sub: s (upon exit) = hi

main: s1 (after call) = hi

sub: len(s) (upon entry) = 10
sub: allocating s
sub: s (upon exit) = hello-from

main: s2 (after call) = hello-from

[spectrum]

Some more trial program...

module test_m
implicit none
contains

subroutine sub( s )
character(*), allocatable :: s

print *, "sub: s = ", s, " len = ", len( s )

deallocate( s )
allocate( s ) !! accept: ifort16/gfort7.2/pgi17.4/oracle12.5
!-- allocate( character( * ) :: s ) !! accept: ifort16/pgi17.4/oracle12.5
!-- allocate( character( 10 ) :: s ) !! error: ifort16/pgi17.4, accept: oracle12.5
!-- allocate( character( 5 ) :: s ) !! error: ifort16/pgi17.4, accept: oracle12.5
s = "yo"
endsubroutine

end module

program main
use test_m
implicit none
character(10), allocatable :: s

allocate( s )
s = "hi"
call sub( s )
print *, "s (after call) = ", s, " len = ", len( s )
end

In the case of "allocate( character(5) :: ... )" or "allocate( character(10) :: ... )",
ifort16 gives an error message as

error #8231: In an ALLOCATE statement the type parameter values in
type specification shall be an asterisk if and only if each object
being allocated is a dummy argument for which the type parameter is assumed.

and pgi17.4 gives an error message as

Type-Specification is incompatible with type of object s

It is interesting that Oracle12.5 accepts both of this, and after allocate( character(5) :: ... ), the length of 's' in the main program is still 10. (I think Oracle is generally most
generous for accepting various cases, but it is not fully F2003(probably), so it may be not very suitable to make comparison here...)

---
But anyway, because the only accepted case is "allocate( s )" or "allocate( character(*) :: s )", isn't this simply the same as using allocate( s )?

# This may be the same as what is suggested for Case 4 in the following Q/A, but not sure...
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1712&L=comp-fortran-90&D=0&P=61
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=comp-fortran-90;18985767.1712

[spectrum]

On Sunday, December 10, 2017 at 3:39:31 PM UTC+9, spectrum wrote:
> Oracle is generally most generous for accepting various cases,

> but it is not fully F2003(probably), ...

I'm sorry, this is a typo of:
... but because it (= Oracle12.5) supports only part of F2003(08?),
comparison here may be not suitable...