public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janus Weil <janus@gcc.gnu.org>
To: Damian Rouson <damian@sourceryinstitute.org>
Cc: Paul Richard Thomas <paul.richard.thomas@gmail.com>,
	gfortran <fortran@gcc.gnu.org>
Subject: Re: [Patch, fortran] Parameterized Derived Types
Date: Sat, 09 Sep 2017 19:08:00 -0000	[thread overview]
Message-ID: <CAKwh3qgJRaSTi5ynGafiJiwN3YY1AsWWz6X47P=cdJsdSRTBUQ@mail.gmail.com> (raw)
In-Reply-To: <etPan.59b3d019.503a691c.bb4e@sourceryinstitute.org>

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

2017-09-09 13:27 GMT+02:00 Damian Rouson <damian@sourceryinstitute.org>:
>
> Hooray!!!! Great work, Paul.

+1 :D


As promised, I have done some testing by now, and found several
problems (ICE-on-invalid, accepts-invalid and rejects-valid), see the
attached test cases. Nothing too severe I guess.



> One small step for gfortran.  One big step for the Fortran world.

I have never looked very closely into PDTs, but now that I do, it
seems like the step for the Fortran world is not quite as big as it
could be (or as I had hoped).

The restriction that KIND parameters cannot be assumed/deferred is a
pretty severe one, isn't it? In terms of "generic programming" it
makes PDTs far less powerful than e.g. C++ templates (I knew that they
are less powerful, but with this restriction it's worse than I
thought).

In particular, it seems that I can define a nice 'generic' type that
deals with arbitrary KIND values in theory, but then all the functions
/ TBPs that work on my type need to be implemented separately for each
KIND value (which means lots of cod duplication), right? Or am I
overlooking anything here? Is anyone aware if this restriction is
lifted in F08 or later, or is planned to be lifted?

Cheers,
Janus




> On September 9, 2017 at 4:15:37 AM, Paul Richard Thomas (paul.richard.thomas@gmail.com(mailto:paul.richard.thomas@gmail.com)) wrote:
>
>> Dear All,
>>
>> The patch has been committed as revision 251925.
>>
>> I look forward to "feedback" (aka PRs) in the coming weeks. I will
>> return to Parameterized Derived Types at the end of this month to
>> clear up some of the known deficiencies (see the notes attached to the
>> patch submission) and any PRs that arise.
>>
>> Regards
>>
>> Paul
>

[-- Attachment #2: pdt1.f90 --]
[-- Type: text/x-fortran, Size: 561 bytes --]

! ICE on invalid & accepts invalid

implicit none

type :: param_matrix(c,r)
  integer, len :: c,r
  real :: m(c,r)
end type

type real_array(k)
  integer, kind :: k
  real(kind=k), allocatable :: r(:)
end type

type(param_matrix(1)) :: m1       ! segfault in gfc_get_pdt_instance (decl.c)
type(param_matrix(1,2)) :: m2     ! ok
type(param_matrix(1,2,3)) :: m3   ! accepted, but invalid
type(param_matrix(1,2.5)) :: m4   ! accepted, but invalid

type(real_array(4)) :: a1        ! ok
type(real_array(5)) :: a2        ! segfault in tree_class_check (tree.h)
end

[-- Attachment #3: pdt2.f90 --]
[-- Type: text/x-fortran, Size: 259 bytes --]

! accepts invalid

implicit none
type :: t(k,i,a,x,y)
  integer, kind :: k
  integer :: i              ! KIND or LEN missing
  integer :: a(3)           ! must be scalar
  real :: x                 ! must be integer
  ! y is not declared at all
end type

end

[-- Attachment #4: pdt3.f90 --]
[-- Type: text/x-fortran, Size: 266 bytes --]

! rejects valid

implicit none

type :: param_matrix(k,c,r)
  integer, kind :: k
  integer, len :: c,r
  real(kind=k) :: m(c,r)
end type

type(param_matrix(8,3,2)) :: mat
real(kind=mat%k) :: m    ! Error: Parameter ‘mat’ at (1) has not been declared or ...

end

[-- Attachment #5: pdt4.f90 --]
[-- Type: text/x-fortran, Size: 696 bytes --]

! rejects valid

module my_matrix
  type :: param_matrix(k,c,r)
    integer, kind :: k
    integer, len :: r
    integer, len :: c
    real(kind=k) :: m(c,r)
  end type param_matrix

  interface process_matrix
    module procedure process_matrix_4
    module procedure process_matrix_8
  end interface

contains

  subroutine process_matrix_4(m)
    type(param_matrix(4,*,*)) :: m   ! Derived type ‘pdtparam_matrix_4’ at (1) is being used before it is defined
  end subroutine process_matrix_4

  subroutine process_matrix_8(m)
    type(param_matrix(8,*,*)) :: m   ! Derived type ‘pdtparam_matrix_8’ at (1) is being used before it is defined
  end subroutine process_matrix_8

end module

  reply	other threads:[~2017-09-09 19:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-09 11:15 Paul Richard Thomas
2017-09-09 11:27 ` Damian Rouson
2017-09-09 19:08   ` Janus Weil [this message]
2017-09-10  8:18     ` Paul Richard Thomas
2017-09-11 20:23       ` Janus Weil
2018-09-07  8:43 ` Bernhard Reutner-Fischer
  -- strict thread matches above, loose matches on Subject: below --
2017-09-06 14:55 Paul Richard Thomas
2017-09-06 13:05 Paul Richard Thomas
2017-09-06 17:38 ` Janus Weil
2017-09-06 18:37 ` Damian Rouson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKwh3qgJRaSTi5ynGafiJiwN3YY1AsWWz6X47P=cdJsdSRTBUQ@mail.gmail.com' \
    --to=janus@gcc.gnu.org \
    --cc=damian@sourceryinstitute.org \
    --cc=fortran@gcc.gnu.org \
    --cc=paul.richard.thomas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).