This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR34820 , PR34143 and PR32795 - some allocatable component bugs
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "Tobias Burnus" <burnus at net-b dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 23 Nov 2008 19:20:44 +0100
- Subject: Re: [Patch, fortran] PR34820 , PR34143 and PR32795 - some allocatable component bugs
- References: <email@example.com> <49256F1B.firstname.lastname@example.org>
Before committing, I have done some work to try to fix your niggles:
> Regarding PR 34820: While the several of the examples of Daniel Franke
> are fixed, my original test case (comment 0; or the FOR line in comment
> 13) still show a memory leak (valgrind --leak-check=full output, see
> comment 0).
Indeed - this will be part of the memory leak PR.
> For PR 34820: Interestingly, the original test case in the TAR file
> compiles without any problems, but compiling the example from comment 3
> gives a segmentation fault (but no ICE anymore) for line 6, namely
> subroutine read_grid_header()
It turns out that this is because the INTENT(OUT) variable is
unreferenced. If you allocate it, for example, the seg fault goes
away. The reason for this is that the automatic array length is not
assigned to the array bounds unless the dummy is referenced.
trans-decl.c(generate_local_decl) is the place to deal with this, in
the same way as unreferenced variable length CHARACTER parameters.
This is trivial.
> For PR 34143: Again, the original test case works, but the example of
> Dominque (comment 13) shows:
> derived type, ik= 4
> bounds, full implicit section -1 2 <-- should not it be 4?
Yes, I had forgotten about this and the discussion before comment 13.
I'll have a wee stab at this tomorrow before committing. If I cannot
fix it, I will raise a PR on it.