This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR fortran/39626: Implement Fortran 2008's BLOCK construct
- From: Tobias Burnus <burnus at net-b dot de>
- To: Daniel Kraft <d at domob dot eu>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 29 Sep 2009 08:19:08 +0200
- Subject: Re: [Patch, Fortran] PR fortran/39626: Implement Fortran 2008's BLOCK construct
- References: <4AC0CC6D.5030707@domob.eu>
Am 28.09.2009 16:47, schrieb Daniel Kraft:
> here's my revised patch to implement the BLOCK construct that will
> appear in the upcoming Fortran 2008 standard. I personally believe that
> this is some really nice feature that missed for a long time, and also
> heard others say they'd like to have something like this in Fortran.
I also missed it a couple of times when I wanted to temporary add some
debugging WRITEs. One usually needs additionally variables which was
inconvenient for lengthy subroutines.
> The patch is against today's trunk and passed both a full bootstrap and
> regression test on GNU/Linux-x86-32. Ok for trunk?
The patch looks good to me. It sometimes makes the diagnostics less
useful, e.g. for
recursive function func(i)
integer :: i, func
func = 1
entry func2(i)
block
func2 = func(1)
end block
end function func
But the same "Unclassifiable statement" one gets if one not only removes
"(end )block" but also "recursive".
> PPS: In block_2.f08, is there an easy way to check that the local
> allocatable array gets free'ed on exit of the block? (Marked by an XXX
> comment) If not, I think it won't hurt much to just get rid of the
> comment and not check this, but if there is, it would be cool to add
> this check.
You could try -fdump-tree-original together with some pattern in
! { dg-final { scan-tree-dump-times "<pattern>" <count> "original" } }
Tobias