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
next prev parent 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).