This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran] Allocatable function results.


On Thu, Mar 09, 2006 at 06:50:42PM +0100, Paul Thomas wrote:
> (ii)  In principle, the standard requires that the function result be 
> allocated on return.  I have attached a patch to trans-expr.c that does 
> this.  It is, however, of limited utility.  The segfaults that result 
> from assigning to unallocated arrays mask most of the cases where this 
> might act.  Perhaps this addition should be part of array bounds checking?

I did think about this a little bit.  My thoughts were something
along the lines of

1. As you say, trying to assign anything to the unallocated
result variable will currently cause a segfault.  Something we
might want to do at some point is some runtime checking for
assignments to unallocated allocatable variables (be they result
variables or not).  On the other hand, we could also implement
the "automatically allocate allocatables on assignment"-stuff in
F2003 some day :-).

2. The cases left to check are when the result variable isn't
only left unallocated, but left unset as well.  For these kinds
of cases we may want to implement some kind of general check that
the result variable is set (for all kinds of functions, be they
allocatable or not).

> >testsuite/
> >2006-03-08  Erik Edelmann  <eedelman@gcc.gnu.org>
> >
> >       * gfortran.dg/allocatable_function_1.f90: New.
> >       * gfortran.dg/allocatable_function_2.f90: New.
> >
> I have extended allocatable_function_1.f90, as described above.  It 
> probably needs cleaning up a bit but it does a belt-and-braces job on 
> checking that allocatable results work in evry situation that I could 
> think of.
> 
> I have also appended a compile only version of this test that uses the 
> option -fdump-tree-original and counts that the allocatable result 
> arrays are freed the right number of times. It's possibly neurotic but 
> it's worth the check IMHO.  It does actually run under DejaGnu with this 
> check in place, so the two could be combined.

Cool, thanks! I spent a few seconds thinking it would be nice to
check that the functions results are freed, but decied that it
probably wasn't doable ...  I'll take a look at your version of
the testcase it before I commit.

> On the patch itself: could you please use tabs.  I know that fortran is 
> meant to be a tab free zone but the compiler (mostly) uses them.

Personally I prefer spaces for formatting, regardless of which
language I'm using.  But it's not something I have very strong
feelings about (the GNU coding standards isn't my usual coding
style anyway). I can use tabs if that's prefered in GCC/gfortran.

> The patch regtests fine on Athlon/FC3.
> 
> Subject to these remarks/modifications - OK to commit.

Thanks for the review!  I'll try to find time to commit tomorrow.

> If you need any help to implement the allocatable components, I am game; 
> just let me know.

I intend to start on sunday.  Let's see how difficult it gets ...


        Erik


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]