Runtime Compatible Types?

[Ev. Drikos]

Is Fortran years ahead of the competition or I've
to file a PR for gfortran?


$ gfortran8 dream-casting.f90 && ./a.out
allocated x = d1(ind=1,i=1)
allocated v = d2(ind=2,j=2)
assigned v = x, now v%ind= 1 j= 1
$ cat dream-casting.f90
program test
implicit none

type :: d0
integer :: ind
end type d0

type, extends(d0) :: d1
integer :: i
end type d1

type, extends(d0) :: d2
integer :: j
end type d2

class(d1), allocatable :: x
class(d2), allocatable :: v

allocate ( x , source = d1(1,1))
print *, "allocated x = d1(ind=1,i=1)"

allocate ( v , source = d2(2,2))
print *, "allocated v = d2(ind=2,j=2)"

v = x
print *, "assigned v = x, now v%ind=", v%ind, "j=", v%j

end program test

[Árpád Lukács]

Well, definitely not ahead of the competition:

$ cat structp.c
#include <stdio.h>
#include <stdlib.h>

struct s1{
int a;
};

struct s2{
int b;
}


main(){
struct s1* c;
struct s2* d;

c = malloc(sizeof(struct s1));
c -> a = 137;
d = c;
printf("d->b: %d\n", d->b);
}


$ gcc -s -O2 structp.c -o structp
structp.c: In function ‘main’:
structp.c:19:7: warning: assignment to ‘struct s2 *’ from incompatible pointer type ‘struct s1 *’ [-Wincompatible-pointer-types]
19 | d = c;
| ^

main(){
struct s1* c;
struct s2* d;

c = malloc(sizeof(struct s1));
c -> a = 137;
d = c;
printf("d->b: %d\n", d->b);
}

[Ev. Drikos]

On 24/01/2021 21:07, Árpád Lukács wrote:
> On Sunday, 24 January 2021 at 19:54:02 UTC+1, Ev. Drikos wrote:
>> Is Fortran years ahead of the competition or I've
>> to file a PR for gfortran?

>> ...

>>
>> end program test
> Well, definitely not ahead of the competition:
>

> ...

Of course in C this would be valid, and one can also avoid warnings:

memcpy( (void*) d, (void *) c, sizeof(struct s1));


The code in my OP is a short version of a test case where these
classes have allocatable components and finalizers:

https://gist.github.com/drikosev/a9e9e8357dbc45aeb02773198069222b#file-realloc_class_6-f90


In short, I'm not confident if the Fortran code is valid or invalid.


Thank you,
Ev. Drikos

[Steve Lionel]

On 1/24/2021 1:53 PM, Ev. Drikos wrote:
> Is Fortran years ahead of the competition or I've
> to file a PR for gfortran?

The latter.

The assignment "v = x" is not allowed because it violates this rule:

"if the variable is polymorphic it shall be type compatible with expr"
(10.2.1.2p1(4))

"A polymorphic entity that is not an unlimited polymorphic entity is
type compatible with entities of the same declared type or any of its
extensions" (7.3.2.3p5)

Note that it says "declared type", not "dynamic type". The declared type
of v is d2, the declared type of x is d1. d1 is not an extension of d2.

I explore this general topic in
https://stevelionel.com/drfortran/2020/06/30/doctor-fortran-in-not-my-type/

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[gah4]

On Sunday, January 24, 2021 at 2:49:29 PM UTC-8, Steve Lionel wrote:
> On 1/24/2021 1:53 PM, Ev. Drikos wrote:
> > Is Fortran years ahead of the competition or I've
> > to file a PR for gfortran?
> The latter.

> The assignment "v = x" is not allowed because it violates this rule:

> "if the variable is polymorphic it shall be type compatible with expr"
> (10.2.1.2p1(4))

> "A polymorphic entity that is not an unlimited polymorphic entity is
> type compatible with entities of the same declared type or any of its
> extensions" (7.3.2.3p5)

How about for SEQUENCE or BIND(C) types?

[Steve Lionel]

SEQUENCE or BIND(C) do not go along with polymorphic.

[Themos Tsikas]

On Sunday, 24 January 2021 at 20:35:55 UTC, Ev. Drikos wrote:
>
>
> In short, I'm not confident if the Fortran code is valid or invalid.

Steve Lionel gave chapter and verse, nagfor emits:

Error: /tmp/drikos.f90, line 25: Left-hand-side of intrinsic assignment statement is of type D2 but right-hand-side is of type D1

Themos Tsikas, NAG Ltd

[FortranFan]

On Sunday, January 24, 2021 at 1:54:02 PM UTC-5, Ev. Drikos wrote:

> Is Fortran years ahead of the competition or I've
> to file a PR for gfortran?

> ..

@Ev. Drikos,

As explained by comments in all the replies and the error message per NAG compiler, your code in the original post does not confirm to the type compatible requirements of the *intrinsic* assignment facility in the standard. The message issued by IFORT Intel Fortran compiler is as follows:

c.f90(25): error #7497: The variable must be type compatible with the expression and of the same rank. [V]
v = x
---^
compilation aborted for c.f90 (code 1)

By the way, with some of your other recent threads involving polymorphic types, are you trying to investigate gfortran and submit PR's or develop bug fixes toward outstanding bug reports?

Anyways, you will know the Fortran standard provides a facility toward *defined* assignment which can then override the intrinsic assignment to permit assignments involving types on RHS and LHS that are otherwise incompatible. Here's an example you can try if you're interested: note you can ponder over various possibilities and language support and compiler response - what if the defined assignment procedure (i.e., the equivalent of 'assign_d2-d1') has dummy arguments which are not polymorphic, or a combination thereof; what if the INTENT attribute of first dummy argument is INTENT(INOUT) versus INTENT(OUT), etc. There are several possibilities and as many or more chances of compiler implementation issues!

program test
implicit none

type :: d0
integer :: ind
end type d0

type, extends(d0) :: d1
integer :: i
end type d1

type, extends(d0) :: d2
integer :: j
end type d2

interface assignment(=)
procedure assign_d2_d1
end interface

class(d1), allocatable :: x
class(d2), allocatable :: v

allocate ( x , source = d1(1,1))
print *, "allocated x = d1(ind=1,i=1)"

allocate ( v , source = d2(2,2))
print *, "allocated v = d2(ind=2,j=2)"

v = x
print *, "assigned v = x, now v%ind=", v%ind, "j=", v%j

contains

subroutine assign_d2_d1( lhs, rhs )
class(d0), allocatable, intent(out) :: lhs
class(d0), intent(in) :: rhs
! suitable assignment actions
allocate( lhs, source=rhs ) !<-- one possible action a programmer might choose
end subroutine

end program test

[Ev. Drikos]

On 25/01/2021 17:49, FortranFan wrote:
> On Sunday, January 24, 2021 at 1:54:02 PM UTC-5, Ev. Drikos wrote:
>

>> ...

>
> By the way, with some of your other recent threads involving polymorphic types, are you trying to investigate gfortran and submit PR's or develop bug fixes toward outstanding bug reports?
>

> ...

At first, my motivation was to understand finalizers but it wasn't easy.
Whereas ie C++ destructors in gcc-3.x run smoothly, at least since 2003.
IMHO, credible finalizers are important in object oriented programming,
unless there is a garbage collector available (ie Java).

Currently, I'm trying to write some test cases that won't become
invalid on a subsequent bug fix. As explained in a previous post, some
deallocation issues in gfortran are obviously related but the bug fixes
may be separated, depending ie if a variable is polymorphic or not.

So, one can avoid a lot of side effects in existing test cases and a
large bug fix that requires good knowledge of both gfortran and Fortran.
That's why I currently focus on polymorphic, mainly scalar, variables. I
think I've a working solution for class objects in my own working tree.

Thanks everyone who has helped me to understand better this topic.

Ev. Drikos