Upgraded to gfortran 7.2.0

[James Van Buskirk]

I had a problem with a program, so I upgraded to gfortran 7.2.0, which
was long overdue, and recompiled.
Program:
module mod1
type stuff
character(:), allocatable :: key
end type stuff
end module mod1

program main
use mod1
implicit none
type(stuff) nonsense
type(stuff) total
nonsense = stuff('Xe')
total = stuff(nonsense%key)
write(*,*) 'nonsense%key = ',nonsense%key
write(*,*) 'ALLOCATED(total%key) = ',ALLOCATED(total%key)
write(*,*) 'LEN(total%key) = ',LEN(total%key)
write(*,*) 'total%key = ',total%key
end program main

Output with gfortran:
nonsense%key = junk
ALLOCATED(total%key) = T
LEN(total%key) = 0
total%key =

Output with ifort:
nonsense%key = junk
ALLOCATED(total%key) = T
LEN(total%key) = 4
total%key = junk

So upgrading didn't fix this one.

[baf]

I certainly hope that the output of program as listed was not "junk"
from either compiler when you assigned nonsense = stuff('Xe')

[James Van Buskirk]

"baf" wrote in message news:f5k5of...@mid.individual.net...

> On 10/28/2017 12:18 PM, James Van Buskirk wrote:
> > nonsense = stuff('Xe')

> I certainly hope that the output of program as listed was not "junk"
> from either compiler when you assigned nonsense = stuff('Xe')

Sorry, program was out of phase with output. Indeed the line in
the actual program was

nonsense = stuff('junk')

Thanks for pointing out this discrepancy.

[FortranFan]

On Saturday, October 28, 2017 at 3:19:08 PM UTC-4, James Van Buskirk wrote:

> .. upgrading didn't fix this one.


A constant refrain from the gfortran volunteers is for those who want problems to be resolved to do so themselves.

Given all your investigation into the C interoperability aspects in Fortran, you would now be more than capable of working with the gfortran compiler code in C and resolve a number of outstanding issues for yourself and others - what say you, why not give it a try?

[kargl]

FortranFan wrote:

> On Saturday, October 28, 2017 at 3:19:08 PM UTC-4, James Van Buskirk wrote:
>
>> .. upgrading didn't fix this one.
>
>
> A constant refrain from the gfortran volunteers is for those who want problems to be resolved to do so themselves.
>

Ah no. In this case, the refrain is "c.l.f is not an official channel
for gfortran reports. Please file a bug report at
https://gcc.gnu.org/bugzilla/"

But that refrain fails with James and apparently with you also
are incapable of submitting proper bug reports.

https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU

HTH

--
steve

[spectrum]

To get more info, I have tried a slightly modified code with
gfortran-7.2 on OSX10.11, and it reproduced the same behavior
(i.e., the "key" in the second object not defined). My test code looks like this:

=== begin: newtest1.f90 ===

subroutine test
implicit none

type myobj_t
character(:), allocatable :: key
endtype
type( myobj_t ) obj, obj2

! character(20) :: stmp
character(:), allocatable :: stmp

obj = myobj_t ( "orange" )

obj2 = myobj_t ( obj % key ) !! NG (key in obj2 not defined) [1]

!-- obj2 = myobj_t ( trim( obj % key ) ) !! runs but loses 6 bytes [2]
!-- obj2 = myobj_t ( obj % key // "" ) !! runs but loses 6 bytes [3]

!-- stmp = obj % key ; obj2 = myobj_t ( stmp ) !! OK (no leak) [4]

print *, "obj % key = ", obj % key
print *, "obj2 % key = ", obj2 % key
end

program main
call test
end

=== end: newtest1.f90 ===

If I compile it as
$ gfortran -O0 -g -fbacktrace newtest1.f90
the output is

obj % key = orange
obj2 % key =

and
$ valgrind a.out
gives

==13431== Invalid write of size 2
==13431== at 0x10000BE90: _platform_memmove$VARIANT$Ivybridge (in /usr/local/Cellar/valgrind/3.12.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==13431== by 0x100000C96: test_ (newtest1.f90:14)
==13431== by 0x100000E0F: MAIN__ (newtest1.f90:26)
==13431== by 0x100000E48: main (newtest1.f90:27)
==13431== Address 0x100cf7d60 is 0 bytes inside a block of size 1 alloc'd <--- [*]
==13431== at 0x100009681: malloc (in /usr/local/Cellar/valgrind/3.12.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==13431== by 0x100000C66: test_ (newtest1.f90:14)
==13431== by 0x100000E0F: MAIN__ (newtest1.f90:26)
==13431== by 0x100000E48: main (newtest1.f90:27)
==13431==

If I compile as

$ gfortran -O0 -fdump-tree-original newtest1.f90

then the output log file ("newtest1.f90.003t.original") contains some lines like

test()
{
....
myobj_t.0.key = (character(kind=1)[1:0] *) __builtin_malloc (6);
myobj_t.0._key_length = 6;
....
myobj_t.1.key = (character(kind=1)[1:0] *) __builtin_malloc (1); <---- [**]
myobj_t.1._key_length = 0;
}

and the lines [*] and [**] look to be somehow related (just based on "1" and "0").

Also, using the -fsanitize option as
$ gfortran -O0 -g -fbacktrace -fsanitize=address newtest1.f90
gives

==13483==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000001f1 at pc 0x0001027f6749 bp 0x7fff5d655120 sp 0x7fff5d6548d0
WRITE of size 6 at 0x6020000001f1 thread T0

# here, "6" is probably the length of "orange".

-----
Interestingly, if I comment out Line [1] and uncomment [2] or [3], the program
runs successfully with the result

obj % key = orange
obj2 % key = orange

but valgrind reports that 6 bytes are lost...
On the other hand, if I uncomment Line [4] (where a temporary string is used),
then the result is OK with no memory leaks.

So, maybe a workaround is to use a temporary string...? (if a structure constructor
is to be definitely used)

[James Van Buskirk]

"spectrum" wrote in message
news:d4f3319e-aafa-41e5...@googlegroups.com...

> To get more info, I have tried a slightly modified code with
> gfortran-7.2 on OSX10.11, and it reproduced the same behavior
> (i.e., the "key" in the second object not defined). My test code looks
> like this:

[snip]

Thanks for further investigating and using valgrind. I wrote some
more test code on my own and found that the bug is really specific
which is why it wasn't detected before. I tried using a structure
constructor with inputs other that an allocatable-length component
and gfortran handled it OK. Even assigning allocatable component
to allocatable component was OK. Allocatable SIZE rather than LEN
was OK.

C:\>type bug4.f90
module mod1
implicit none
type s1
character(:), allocatable :: key
end type s1
type s2
character, allocatable :: key(:)
end type s2
contains
subroutine sub(x)
character(*) x
type(s1) z
z = s1(x)
write(*,'(*(g0))') 'ALLOCATED(z%key) = ',ALLOCATED(z%key)
write(*,'(*(g0))') 'LEN(z%key) = ',LEN(z%key)
write(*,'(*(g0))') 'z%key = ',z%key
end subroutine sub

end module mod1

program main
use mod1
implicit none

type(s1) x
type(s1) z
type(s1) w
character(:), allocatable :: u
type(s1) v
type(s2) a
type(s2) b
x = s1('Sojin')
write(*,'(*(g0))') 'ALLOCATED(x%key) = ',ALLOCATED(x%key)
write(*,'(*(g0))') 'LEN(x%key) = ',LEN(x%key)
write(*,'(*(g0))') 'x%key = ',x%key
x = s1('Yura')
z = s1(x%key)
write(*,'(*(g0))') 'ALLOCATED(z%key) = ',ALLOCATED(z%key)
write(*,'(*(g0))') 'LEN(z%key) = ',LEN(z%key)
write(*,'(*(g0))') 'z%key = ',z%key
x = s1('Minah')
w%key = x%key
write(*,'(*(g0))') 'ALLOCATED(w%key) = ',ALLOCATED(w%key)
write(*,'(*(g0))') 'LEN(w%key) = ',LEN(w%key)
write(*,'(*(g0))') 'w%key = ',w%key
call sub('Hyeri')
u = 'Jihae'
v = s1(u)
write(*,'(*(g0))') 'ALLOCATED(v%key) = ',ALLOCATED(v%key)
write(*,'(*(g0))') 'LEN(v%key) = ',LEN(v%key)
write(*,'(*(g0))') 'v%key = ',v%key
a = s2(transfer('Jiin',['x']))
write(*,'(*(g0))') 'ALLOCATED(a%key) = ',ALLOCATED(a%key)
write(*,'(*(g0))') 'SIZE(a%key) = ',SIZE(a%key)
write(*,'(*(g0))') 'a%key = ',a%key
a = s2(transfer('Jisun',['x']))
b = s2(a%key)
write(*,'(*(g0))') 'ALLOCATED(b%key) = ',ALLOCATED(b%key)
write(*,'(*(g0))') 'SIZE(b%key) = ',SIZE(b%key)
write(*,'(*(g0))') 'b%key = ',b%key
end program main

C:\>gfortran bug4.f90 -obug4

C:\>bug4
ALLOCATED(x%key) = T
LEN(x%key) = 5
x%key = Sojin
ALLOCATED(z%key) = T
LEN(z%key) = 0
z%key =
ALLOCATED(w%key) = T
LEN(w%key) = 5
w%key = Minah
ALLOCATED(z%key) = T
LEN(z%key) = 5
z%key = Hyeri
ALLOCATED(v%key) = T
LEN(v%key) = 5
v%key = Jihae
ALLOCATED(a%key) = T
SIZE(a%key) = 4
a%key = Jiin
ALLOCATED(b%key) = T
SIZE(b%key) = 5
b%key = Jisun

[James Van Buskirk]

"kargl" wrote in message news:ot3l22$lr9$1...@dont-email.me...

> Ah no. In this case, the refrain is "c.l.f is not an official channel
> for gfortran reports. Please file a bug report at
> https://gcc.gnu.org/bugzilla/"

> But that refrain fails with James and apparently with you also
> are incapable of submitting proper bug reports.

Maybe if bugzilla had an option to make bug reports PD rather
than GPL...

82774 thanks for looking at this anyway, Steve. I have been
trying to find closely related bugs but haven't found any. One
problem is that I had a hard enough time installing gfortran 7.2
but testing the following code requires 8.0. I can't even check
it for correctness in ifort 16.0.2 because it causes an ICE. If
someone could try it on a couple of more recent compiler
builds I would be grateful.

module mod1
implicit none
type s3(selector)
integer, len :: selector
character key(selector)
end type s3
type s4
type(s3(:)), allocatable :: key
end type s4

end module mod1

program main
use mod1
implicit none

type(s3(:)), allocatable :: x
type(s3(:)), allocatable :: z
type(s4) u
type(s4) v
x = s3(2)(transfer('Xe',['x']))
write(*,*) 'ALLOCATED(x) = ',ALLOCATED(x)
write(*,*) 'x%selector = ',x%selector
write(*,*) 'x%key = ',x%key
z = x
write(*,*) 'ALLOCATED(z) = ',ALLOCATED(z)
write(*,*) 'z%selector = ',z%selector
write(*,*) 'z%key = ',z%key
u = s4(x)
write(*,*) 'ALLOCATED(u%key) = ',ALLOCATED(u%key)
write(*,*) 'u%key%selector = ',u%key%selector
write(*,*) 'u%key%key = ',u%key%key
v = u
write(*,*) 'ALLOCATED(v%key) = ',ALLOCATED(v%key)
write(*,*) 'v%key%selector = ',v%key%selector
write(*,*) 'v%key%key = ',v%key%key
end program main

[Ev. Drikos]

On 31/10/2017 20:41, James Van Buskirk wrote:
> ...   If

> someone could try it on a couple of more recent compiler
> builds I would be grateful.
>
> module mod1
>   implicit none
>   type s3(selector)
>      integer, len :: selector
>      character key(selector)
>   end type s3
>   type s4
>      type(s3(:)), allocatable :: key
>   end type s4
> end module mod1

> ...

It's syntactically ok but what's the selector that makes gfortran go out
of rails?

[FortranFan]

On Tuesday, October 31, 2017 at 2:41:39 PM UTC-4, James Van Buskirk wrote:

> ..

> type s3(selector)
> integer, len :: selector
> character key(selector)
> end type s3

> ..
> type(s3(:)), allocatable :: x
>..

> x = s3(2)(transfer('Xe',['x']))

@James Van Buskirk,

Intel Fortran 18.0 compiler also generates an ICE with the CHARACTER array of key in the structure constructor.

With the following variant:

module mod1
implicit none
type s3(selector)
integer, len :: selector

character(len=selector) :: key

end type s3
type s4
type(s3(:)), allocatable :: key
end type s4
end module mod1

program main

use, intrinsic :: iso_fortran_env, only : compiler_version

use mod1

implicit none

type(s3(:)), allocatable :: x
type(s3(:)), allocatable :: z
type(s4) u
type(s4) v

print *, "Compiler Version: ", compiler_version()

x = s3(selector=2)( key="Xe" )

write(*,*) 'ALLOCATED(x) = ',ALLOCATED(x)
write(*,*) 'x%selector = ',x%selector
write(*,*) 'x%key = ',x%key
z = x
write(*,*) 'ALLOCATED(z) = ',ALLOCATED(z)
write(*,*) 'z%selector = ',z%selector
write(*,*) 'z%key = ',z%key
u = s4(x)
write(*,*) 'ALLOCATED(u%key) = ',ALLOCATED(u%key)
write(*,*) 'u%key%selector = ',u%key%selector
write(*,*) 'u%key%key = ',u%key%key
v = u
write(*,*) 'ALLOCATED(v%key) = ',ALLOCATED(v%key)
write(*,*) 'v%key%selector = ',v%key%selector
write(*,*) 'v%key%key = ',v%key%key

end program main

The output is:

Compiler Version:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32,

Version 18.0.0.124 Build 20170811

ALLOCATED(x) = T
x%selector = 2
x%key = Xe
ALLOCATED(z) = T
z%selector = 2
z%key = Xe
ALLOCATED(u%key) = T
u%key%selector = 2
u%key%key = Xe
ALLOCATED(v%key) = T
v%key%selector = 2
v%key%key = Xe

gfortran 8.0.0 falls over with a couple of statements in both your code as well as this variant, suggesting more work for Paul Rich Thomas too with his PDT implementation if he is dialing into this thread.

[FortranFan]

On Tuesday, October 31, 2017 at 3:21:13 PM UTC-4, Ev. Drikos wrote:

> .. what's the selector that makes gfortran go out
> of rails?


I presume it is the parameterized derived type (PDT) syntax:

type s3(selector)
integer, len :: selector
character key(selector)
end type s3

introduced in the standard starting with 2003 revision but which has been implemented only in the gfortran 8.0.0 (Experimental) version.

[James Van Buskirk]

"Ev. Drikos" wrote in message
news:59f8cd26$0$721$1472...@news.sunsite.dk...

This is my first attempt at a parameterized derived type. Looking
at 10-007.pdf, section 4.5.2.1, the syntax seems to be

TYPE type-name(type-param-name-list)

So I filled out the form above with type-name = s3 and
type-param-name-list = selector, so that my sole
parameter is called selector. Then the next line is the
type-param-def-stmt for my selector parameter and
section 4.5.3.1 says the syntax for that is

INTEGER, type-param-attr-spec :: type-param-decl-list

I wanted a length-type parameter (like the LEN of a character
variable rather than the KIND of a real variable) so I filled out
type-param-attr-spec = LEN and of course
type-param-decl-list = selector because that again is the name
of my parameter.

Then I can use selector as a specification expression further
within my derived type definition, so my component-part just
consists of one data-component-def-stmt,

character key(selector)

Parameterized derived types were introduced in gfortran 8.0
so this sort of example just isn't going to fly in 7.2. I'm not sure
about the syntax for a structure constructor if the derived type
has a parameter, but my best guess was

x = s3(2)(transfer('Xe',['x']))

However, this caused the ICE in ifort 16.0.2, so maybe it's just
not syntactically correct. Reviewing my example, I notice that
it doesn't have the specific syntax that tripped up gfortran
when the component was an allocatable deferred-length
character component. Let me append code that really makes
the intended test:

module mod1
implicit none
type s3(selector)
integer, len :: selector
character key(selector)
end type s3
type s4
type(s3(:)), allocatable :: key
end type s4
end module mod1

program main
use mod1
implicit none
type(s3(:)), allocatable :: x
type(s3(:)), allocatable :: z
type(s4) u
type(s4) v

type(s4) w

x = s3(2)(transfer('Xe',['x']))
write(*,*) 'ALLOCATED(x) = ',ALLOCATED(x)
write(*,*) 'x%selector = ',x%selector
write(*,*) 'x%key = ',x%key
z = x
write(*,*) 'ALLOCATED(z) = ',ALLOCATED(z)
write(*,*) 'z%selector = ',z%selector
write(*,*) 'z%key = ',z%key
u = s4(x)
write(*,*) 'ALLOCATED(u%key) = ',ALLOCATED(u%key)
write(*,*) 'u%key%selector = ',u%key%selector
write(*,*) 'u%key%key = ',u%key%key
v = u
write(*,*) 'ALLOCATED(v%key) = ',ALLOCATED(v%key)
write(*,*) 'v%key%selector = ',v%key%selector
write(*,*) 'v%key%key = ',v%key%key

w = s4(u%key)
write(*,*) 'ALLOCATED(w%key) = ',ALLOCATED(w%key)
write(*,*) 'w%key%selector = ',w%key%selector
write(*,*) 'w%key%key = ',w%key%key
end program main

[FortranFan]

On Tuesday, October 31, 2017 at 4:06:39 PM UTC-4, James Van Buskirk wrote:

> ..
>

> x = s3(2)(transfer('Xe',['x']))
>
> However, this caused the ICE in ifort 16.0.2, so maybe it's just

> not syntactically correct. ..

As noted often elsewhere, an ICE is always a compiler bug and I've filed an incident at the Intel's Online Service Center for the following:
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/747930

Anyways, my read is the syntax is alright. The following variant works:

use, intrinsic :: iso_fortran_env, only : compiler_version

type :: t(ell)
integer, len :: ell
character(len=1) :: s(ell)
end type

integer, parameter :: N = 2
type(t(ell=:)), allocatable :: foo

print *, "Compiler Version: = ", compiler_version()

allocate( t(ell=N) :: foo )
foo%s = transfer(source=repeat("x",ncopies=N), mold=[ character(len=1) :: ], size=N)
print *, "foo%s = ", foo%s

end

Upon execution,

Compiler Version: =
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel( R) 64, Version 18.0.0.124 Build 20170811

foo%s = xx

[James Van Buskirk]

"FortranFan" wrote in message
news:2111792f-53b8-4a8d...@googlegroups.com...

> Intel Fortran 18.0 compiler also generates an ICE with the CHARACTER
> array of key in the structure constructor.

Thanks for testing this F**2. It's surprising that ifort can't deal
with this syntax because it's similar to 10-007.pdf, NOTE 4.61

general_point(dim=3) ( [ 1., 2., 3. ] )

Except with a CHARACTER array rather than a REAL one.

> x = s3(selector=2)( key="Xe" )

OK, that seems to support my attempt at the correct syntax.

> Compiler Version:
> Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on
> IA-32,

> Version 18.0.0.124 Build 20170811

> gfortran 8.0.0 falls over with a couple of statements in both
> your code as well as this variant

Thanks again for all the tests. That's one of the fun things
about this forum: you can get feedback on what your code
does on multiple compilers if you make your examples
sufficiently self-contained and catch other posters on a
receptive day :)

[steve kargl]

James Van Buskirk wrote:

> "kargl" wrote in message news:ot3l22$lr9$1...@dont-email.me...
>
>> Ah no. In this case, the refrain is "c.l.f is not an official channel
>> for gfortran reports. Please file a bug report at
>> https://gcc.gnu.org/bugzilla/"
>
>> But that refrain fails with James and apparently with you also
>> are incapable of submitting proper bug reports.
>
> Maybe if bugzilla had an option to make bug reports PD rather
> than GPL...
>

Not sure where you got the above information. If you go to

https://gcc.gnu.org/gccmission.html

You find the 4th bullet: "Other components (runtime libraries, testsuites,
etc) will be available under various free licenses with copyrights being
held by individual authors or the FSF."

If you go to gcc/testsuite/gfortran.dg and do

% grep -i copyright *
derived_pointer_recursion.f90:! copyright 1996 Loren P. Meissner -- May be distributed if this line is included.
dg.exp:# Copyright (C) 2004-2017 Free Software Foundation, Inc.
dtio_5.f90:! Copyright (c) 2015, NVIDIA CORPORATION. All rights reserved.
module_equivalence_5.f90:! COPYRIGHT 1999 SPACKMAN & HENDRICKSON, INC.
pdt_5.f03:! Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved.
unlimited_polymorphic_24.f03:! Copyright 2015 NVIDIA Corporation
use_only_3.inc:! Copyright (C) 2001-2005 Quantum-ESPRESSO group
use_only_3.inc:! Copyright (C) 2002 FPMD group

dp.exp is the Dejagnu test script written by GCC contributors. If you
submit a piece of code for a bug report with something like,

!
! Copyright (c) 2017 James van Buskirk. All rights reserved.
! Permission to use, copy, modify, and distribute this
! software is freely granted, provided that this notice
! is preserved.
!
Code fragment here.

The above should be allowed in the testsuite.

Of course, I'm not a lawyer.

--
steve

[Ev. Drikos]

On 31/10/2017 22:06, James Van Buskirk wrote:
> "Ev. Drikos"  wrote in message
> news:59f8cd26$0$721$1472...@news.sunsite.dk...

> ...
>
>> It's syntactically ok but what's the selector that makes gfortran go
>> out of rails?
>
> This is my first attempt at a parameterized derived type.  Looking
> at 10-007.pdf, section 4.5.2.1, the syntax seems to be
>

> ...
>

Ok, I got it. You use templates to define the array length.

> Let me append code that really makes
> the intended test:
>

...

[Thomas Koenig]

James Van Buskirk <not_...@comcast.net> schrieb:

> This is my first attempt at a parameterized derived type. Looking
> at 10-007.pdf, section 4.5.2.1, the syntax seems to be

PDTs have been added by Paul Thomas to the current trunk, 8.0;
they will not be backported to the gcc 7 version.

If you want to try this out, either get a current trunk, or
wait for gcc 8 to be released, and then until your distribution
povides this as a package.

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

This has been added to Bug #82482 as comment 1.

Thanks

Paul