[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #38 from pault at gcc dot gnu dot org  2006-10-17 11:33 ---
(In reply to comment #37)
Sorry all, I screwed up on the PR number - it should have been 29541

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #37 from pault at gcc dot gnu dot org  2006-10-16 22:29 ---
Subject: Bug 20541

Author: pault
Date: Mon Oct 16 22:29:46 2006
New Revision: 117797

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117797
Log:
2006-10-17  Paul Thomas [EMAIL PROTECTED]

PR fortran/20541
* trans-array.c (gfc_trans_array_bounds): Test for and set
negative stride of a non-constant bound array to zero.

PR fortran/29392
* data.c (create_character_intializer): Copy and simplify
the expressions for the start and end of a sub-string
reference.

2006-10-17  Paul Thomas  [EMAIL PROTECTED]

PR fortran/29392
* gfortran.dg/data_char_3.f90: New test.

PR fortran/20541
* gfortran.dg/negative_automatic_size.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/data_char_3.f90
trunk/gcc/testsuite/gfortran.dg/negative_automatic_size.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #35 from pault at gcc dot gnu dot org  2006-10-08 16:22 ---
Subject: Bug 20541

Author: pault
Date: Sun Oct  8 16:21:55 2006
New Revision: 117558

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117558
Log:
2006-10-05  Erik Edelmann [EMAIL PROTECTED]
Paul Thomas [EMAIL PROTECTED]

PR fortran/20541
* interface.c (gfc_compare_derived_types): Add comparison of
the allocatable field.
* intrinsic.c (add_subroutines): Add MOVE_ALLOC.
* trans-expr.c (gfc_conv_aliased_arg, gfc_trans_subarray_assign,
gfc_trans_subcomponent_assign, gfc_conv_string_parameter,
gfc_trans_scalar_assign): Add extra arguments l_is_temp
and r_is_var to references to latter function.
(gfc_conv_function_call): Add enum for types of argument and
an associated variable parm_kind. Deallocate components of
INTENT(OUT) and non-variable arrays.
(gfc_trans_subcomponent_assign): Add block to assign arrays
to allocatable components.
(gfc_trans_scalar_assign): Add block to handle assignments of
derived types with allocatable components, using the above new
arguments to control allocation/deallocation of memory and the
copying of allocated arrays.
* trans-array.c (gfc_array_allocate): Remove old identification 
of pointer and replace with that of an allocatable array. Add
nullify of structures with allocatable components. 
(gfc_conv_array_initializer): Treat EXPR_NULL.
(gfc_conv_array_parameter): Deallocate allocatable components
of non-variable structures.
(gfc_trans_dealloc_allocated): Use second argument of library
deallocate to inhibit, without error, freeing NULL pointers.
(get_full_array_size): New function to return the size of a
full array.
(gfc_duplicate_allocatable): New function to allocate and copy
allocated data.
(structure_alloc_comps): New recursive function to deallocate,
nullify or copy allocatable components.
(gfc_nullify_alloc_comp, gfc_deallocate_alloc_comp,
gfc_copy_alloc_comp): New interface functions to call previous.
(gfc_trans_deferred_array): Add the code to nullify allocatable
components, when entering scope, and to deallocate them on
leaving. Do not call gfc_trans_static_array_pointer and return
for structures with allocatable components and default
initializers.
* symbol.c (gfc_set_component_attr): Set allocatable field.
(gfc_get_component_attr): Set the allocatable attribute.
* intrinsic.h : Prototype for gfc_check_move_alloc.
* decl.c (build_struct): Apply TR15581 constraints for
allocatable components.
(variable_decl): Default initializer is always NULL for
allocatable components.
(match_attr_spec): Allow, or not, allocatable components,
according to the standard in force.
* trans-array.h : Prototypes for gfc_nullify_alloc_comp,
gfc_deallocate_alloc_comp, gfc_copy_alloc_comp and
gfc_duplicate_allocatable.
* gfortran.texi : Add mention of TR15581 extensions.
* gfortran.h : Add attribute alloc_comp, add
gfc_components field allocatable and add the prototype
for gfc_expr_to_initialize.
* trans-stmt.c (generate_loop_for_temp_to_lhs,
generate_loop_for_rhs_to_temp, gfc_trans_where_assign,
gfc_trans_where_3): Add extra arguments to calls to
gfc_trans_scalar_assign and set appropriately.
(gfc_trans_allocate): Nullify allocatable components.
(gfc_trans_deallocate): Deallocate to ultimate allocatable
components but stop at ultimate pointer components.
* module.c (mio_symbol_attribute, mio_symbol_attribute,
mio_component): Add module support for allocatable
components.
* trans-types.c (gfc_get_derived_type): Treat allocatable
components.
* trans.h : Add two boolean arguments to
gfc_trans_scalar_assign.
* resolve.c (resolve_structure_cons): Check conformance of
constructor element and the component.
(resolve_allocate_expr): Add expression to nullify the
constructor expression for allocatable components.
(resolve_transfer): Inhibit I/O of derived types with
allocatable components.
(resolve_fl_derived): Skip check of bounds of allocatable
components.
* trans-decl.c (gfc_get_symbol_decl): Add derived types
with allocatable components to deferred variable.
(gfc_trans_deferred_vars): Make calls for derived types
with allocatable components to gfc_trans_deferred_array.
(gfc_generate_function_code): Nullify allocatable
component function result on entry.
* parse.c (parse_derived): Set symbol attr.allocatable if
allocatable components are 

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #36 from pault at gcc dot gnu dot org  2006-10-08 16:27 ---
Fixed in gcc-4.2

Paul and Erik


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[patchapp at dberlin dot org]

--- Comment #34 from patchapp at dberlin dot org  2006-10-05 05:00 ---
Subject: Bug number PR20541

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00231.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[sfilippone at uniroma2 dot it]

--- Comment #33 from sfilippone at uniroma2 dot it  2006-10-03 15:48 ---
The latest patch alloc_comp1002.diff has survived everything I could throw at
it in the last few hours. Go for it. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[sfilippone at uniroma2 dot it]

--- Comment #31 from sfilippone at uniroma2 dot it  2006-10-02 07:21 ---
For the record: my test application runs to completion with good results
snapshot 20060930 + alloc_comps0929.diff. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #32 from pault at gcc dot gnu dot org  2006-10-02 21:54 ---
Created an attachment (id=12373)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12373action=view)
A patch that fixes test_ab9.f90

You will see the modification in trans-types.c.  This is the first bit of the
patch that is not specific to allocatable components, although I am hard
pressed to find a case that doesn't involve them.  If you feel uncomfortable
with breaking the hermetic seal, I could make it specific.  That said, this
does regtest OK, including all , the other derived type association tests.

I will write a test case tomorrow sometime and so have included my reduced
version of test_ab9.f90 from Slavatore Filippone to ensure that the audit trail
makes sense.

The problem arises because of the assignment that is used to initialize the
INTENT(OUT) derived type in gfc_conv_function_call. This exercises an
association that, I think, would not otherwise be possible.  It is fixed by
usin the current namespace to start the search for like types, from any
namespace where there is no parent.  The case where the derived type found is
the same as 'self' is eliminated from the search by a continue statement.

Paul

module modA
  type dt
 integer, allocatable :: i(:)
  end type dt
end module modA

Module modB
  interface
 subroutine foo(x)
   use modA
   type(dt), intent(out)   :: x
 end subroutine foo
  end interface
end module modB

subroutine test_ab9()
  use modB ! putting this after USE modA clears the problem
  use modA

  type(dt)  :: a

  call foo(a)

  return

end subroutine test_ab9



-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12350|0   |1
is obsolete||
  Attachment #12354|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #29 from howarth at nitro dot med dot uc dot edu  2006-10-02 
03:10 ---
Latest version builds fine and shows no regressions on Darwin PPC at -m32 and
-m64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[jvdelisle at gcc dot gnu dot org]

--- Comment #30 from jvdelisle at gcc dot gnu dot org  2006-10-02 04:15 
---
alloc_comps0929.diff tests OK for me on i686-linux.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #28 from pault at gcc dot gnu dot org  2006-09-29 15:00 ---
Created an attachment (id=12354)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12354action=view)
Patch that fixes Salvatore's latest

This patch moves the addition of EXPR_NULL for allocatable components to
expr.c(gfc_default_initializer).  The consequence of this is that ALL
structures with allocatable components get a default initializer, even if it
only contains EXPR_NULL. Whilst this is OK for the static initialization, it is
unnecessary because of the nullification that is done upon coming into scope. 
Thus, translation of such intitializer expressions is skipped in
trans-expr.c(gfc_conv_structure).

ALLOCATE now does an assignment of this potentially compound default
initializer expression to each and every allocatable component.  Being a
variable assignment, this produces extra code that checks for non-NULL data
fields to see if they should be deallocated.  This ups the dealloactions
counted by alloc_comp_basics_1.f90 to 38.

With this modification, the patch regtests OK.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2006-09-28 14:06 ---
Created an attachment (id=12350)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12350action=view)
The latest version, incorporating all fixes so far.

This latest has an increasingly complete set of testcases and fixes for the
problems found by Salvatore Filippone.

What is missing is the setting of scalar assignment flags for WHERE
blocks/statements and another attempt to understand what is broken with zero
length strings (for iso_varying_string).

A ChangeLog exists, which is about two days behind.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12320|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #24 from pault at gcc dot gnu dot org  2006-09-24 17:31 ---
Created an attachment (id=12320)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12320action=view)
Patch + testcases for allocatable components

This version has all the known issues fixed and includes a number of testcases
- some complete and some in 'draft' form.

We are nearly there!

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12106|0   |1
is obsolete||
  Attachment #12313|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #25 from howarth at nitro dot med dot uc dot edu  2006-09-25 
05:09 ---
Paul,
The current patch builds fine on Darwin PPC and shows no regressions
in the gfortran testsuite at either -m32 or -m64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[jvdelisle at gcc dot gnu dot org]

--- Comment #26 from jvdelisle at gcc dot gnu dot org  2006-09-25 05:53 
---
Paul,

OK here too. i686-linux


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[paul dot thomas at jet dot uk]

--- Comment #21 from paul dot thomas at jet dot uk  2006-09-23 16:18 ---
Created an attachment (id=12313)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12313action=view)
Latest patch

This version fixes the problem with constructors of structures that have
allocatable components of structures with allocatable components.  It also
fixes Salvatore's problem with initializers (thanks!). Finally, the problems
with forall seem to have fixed themeselves...,I think.

Paul 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #22 from howarth at nitro dot med dot uc dot edu  2006-09-23 
16:24 ---
Paul,
Could you please include the testsuite testcases when you post the
patch? It's rather hard to regression test without those.
 Jack


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #23 from howarth at nitro dot med dot uc dot edu  2006-09-23 
18:41 ---
Paul,
 The new patch doesn't allow gfortran to build. I get an error...

/sw/src/fink.build/gcc4-4.1.-20060923/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060923/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -c   -g -O2 -mdynamic-no-pic -DIN_GCC
  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute -Werror -fno-common  
-DHAVE_CONFIG_H -I. -Ifortran -I../../gcc-4.2-20060923/gcc
-I../../gcc-4.2-20060923/gcc/fortran -I../../gcc-4.2-20060923/gcc/../include
-I./../intl -I../../gcc-4.2-20060923/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.2-20060923/gcc/../libdecnumber -I../libdecnumber -I/sw/include  
../../gcc-4.2-20060923/gcc/fortran/trans-expr.c -o fortran/trans-expr.o
../../gcc-4.2-20060923/gcc/fortran/trans-expr.c: In function
'gfc_conv_structure':
../../gcc-4.2-20060923/gcc/fortran/trans-expr.c:2902: error: 'gfc_constructor'
has no member named 'allocatable'
make[3]: *** [fortran/trans-expr.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pinskia at gcc dot gnu dot org]

--- Comment #20 from pinskia at gcc dot gnu dot org  2006-09-19 16:41 
---
*** Bug 29142 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dir at lanl dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #18 from howarth at nitro dot med dot uc dot edu  2006-08-20 
14:37 ---
With the latest changes to gcc/fortran/trans-expr.c the current proposed patch
no longer applies. The code which is tangling up the patch is...

***
*** 2664,2683 
  }
else if (cm-dimension)
  {
-   tmp = gfc_trans_subarray_assign (dest, cm, expr);
-   gfc_add_expr_to_block (block, tmp);
  }
else if (expr-ts.type == BT_DERIVED)
  {
/* Nested derived type.  */
-   tmp = gfc_trans_structure_assign (dest, expr);
gfc_add_expr_to_block (block, tmp);
  }
else
  {
/* Scalar component.  */
-   gfc_se lse;
- 
gfc_init_se (se, NULL);
gfc_init_se (lse, NULL);

where we now have an additional if (expr-expr_type != EXPR_STRUCTURE)
inserted. Is the current proposed patch still valid in this section with minor
adjustments so that it applies or will the proposed code have to be modified
due to the changes here?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[eedelman at gcc dot gnu dot org]

--- Comment #19 from eedelman at gcc dot gnu dot org  2006-08-20 17:38 
---
Created an attachment (id=12106)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12106action=view)
Updated patch

Fixes the conflicts with recently committed patches.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12060|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #16 from howarth at nitro dot med dot uc dot edu  2006-08-10 
13:31 ---
My first attempt to build with this revised patch was unsuccessful...

/sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin/
-B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem
/sw/lib/gcc4/powerpc-apple-darwin8/include -isystem
/sw/lib/gcc4/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.2-20060809/libgfortran -I.
-iquote../../../gcc-4.2-20060809/libgfortran/io
-I../../../gcc-4.2-20060809/libgfortran/../gcc
-I../../../gcc-4.2-20060809/libgfortran/../gcc/config -I../.././gcc
-D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c
../../../gcc-4.2-20060809/libgfortran/intrinsics/malloc.c -o malloc.o
/dev/null 21
make[3]: *** No rule to make target `intrinsics/move_alloc.c', needed by
`move_alloc.lo'.  Stop.
make[2]: *** [all] Error 2
make[1]: *** [all-target-libgfortran] Error 2
make: *** [all] Error 2
### execution of /var/tmp/tmp.2.82ybS7 failed, exit code 2
Failed: phase compiling: gcc4-4.1.999-20060809 failed


I'll double check that I didn't drop any part of the patch by accident
but I do recall any errors when patching.



(In reply to comment #15)
 Created an attachment (id=12049)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049action=view) [edit]
 Updated patch
 
 Fix the problem reported by Jack.
 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[eedelman at gcc dot gnu dot org]

--- Comment #17 from eedelman at gcc dot gnu dot org  2006-08-10 20:23 
---
Created an attachment (id=12060)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12060action=view)
New version.

Yup, the previous patch wasn't complete (it lacked
libgfortran/intrinsics/move_alloc.c); this one should be better.  It also
addresses the issue pointed out by Thomas Koenig at 2006-05-09.

Thanks for testing!


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #12049|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[eedelman at gcc dot gnu dot org]

--- Comment #15 from eedelman at gcc dot gnu dot org  2006-08-09 21:55 
---
Created an attachment (id=12049)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049action=view)
Updated patch

Fix the problem reported by Jack.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #11975|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2006-08-06 
22:47 ---
The current patch doesn't seem to work any more. I get a compile error on the
current gcc trunk svn
pull...

../../gcc-4.2-20060806/gcc/fortran/parse.c: In function 'parse_derived':
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: 'c' undeclared (first
use in this function)
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: (Each undeclared
identifier is reported only once
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: for each function it
appears in.)

Looking at parse.c, it appears that gfc_component has been removed from the
parse_derived call breaking
the section of the patch that looks for allocatable components.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[eedelman at gcc dot gnu dot org]

--- Comment #13 from eedelman at gcc dot gnu dot org  2006-07-30 21:38 
---
Created an attachment (id=11975)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11975action=view)
Latest version

Fixed a bunch of problems, added some documentation, and moved MOVE_ALLOC to a
file of it's own.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[paul dot richard dot thomas at cea dot fr]

--- Comment #12 from paul dot richard dot thomas at cea dot fr  2006-07-18 
14:35 ---
Created an attachment (id=11910)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11910action=view)
The latest version of the patch

This patch is the last version that I will post until after I return from
vacation.  As well as allocatable components, it fixes the two issues raised by
Salvatore Filippone on the gfortran list.  It also includes a test version of
move_alloc that runs the following correctly:

  integer, allocatable :: x(:), y(:), temp(:)
  character(4), allocatable :: a(:), b(:)
  allocate (x(2))
  allocate (a(2))

  x = (/42, 77/)

  print *, allocated(x), allocated(y)
  if (allocated (x)) print *, x
  call move_alloc (x, y)
  print *, allocated(x), allocated(y)
  if (allocated (y)) print *, y


  a = (/abcd, efgh/)
  print *, allocated(a), allocated(b)
  if (allocated (a)) print *, a
  call move_alloc (a, b)
  print *, allocated(a), allocated(b)
  if (allocated (b)) print *, b

! Now one of the intended applications of move_alloc; resizing

  call move_alloc (to = temp, from = y)
  allocate (y(6))
  y(1:2) = temp
  y(3:) = 99
  print *, y
end


Paul 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[paul dot richard dot thomas at cea dot fr]

--- Comment #9 from paul dot richard dot thomas at cea dot fr  2006-07-12 
14:20 ---
Created an attachment (id=11867)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11867action=view)
For discussion, perusal and testing: a beta-release of the TR15581 patch

This patch represents some months of work by Erik and myself.  It is still not
complete and has at least one residual source of memory leakage (derived type
constructors with function array-valued actuals). That withstanding, it does
most of the memory management required by the standard, it does assignments
correctly and handless allocatable components in contructors.  There is still a
way to go before it is submittable but it's getting there!

What does it do?

(i) It runs most of the iso_varying_string testsuite (vst16.f95 fails in io,
vst28.f95, vst30.f95 and vst31.f95 need modification to catch zero length
strings).

(ii) This tests the basic functionality:

! { dg-do run}
! { dg-options -O2 -fdump-tree-original }
!
! Check some basic functionality of allocatable components, including that they
! are nullified when created and automatically deallocated when
! 1. A variable goes out of scope
! 2. INTENT(OUT) dummies
! 3. Function results
!
module alloc_m

implicit none

type :: alloc1
real, allocatable :: x(:)
end type alloc1

end module alloc_m


program alloc

use alloc_m

implicit none

type :: alloc2
type(alloc1), allocatable :: a1(:)
integer, allocatable :: a2(:)
end type alloc2

type(alloc2) :: b
integer :: i
type(alloc2), allocatable :: c(:)

if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'main - 1'
call abort()
end if

! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(b)
call check_alloc2(b)

do i = 1, size(b%a1)
! 1 call to _gfortran_deallocate
deallocate(b%a1(i)%x)
end do

! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(b)

call check_alloc2(return_alloc2())
! 3 calls to _gfortran_deallocate (function result)

allocate(c(1))
! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(c(1))
! 4 calls to _gfortran_deallocate
deallocate(c)

! 7 calls to _gfortran_deallocate (b (3) and c(4) goes aout of scope)

contains

subroutine allocate_alloc2(b)
type(alloc2), intent(out) :: b
integer :: i

if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'allocate_alloc2 - 1'
call abort()
end if

allocate (b%a2(3))
b%a2 = [ 1, 2, 3 ]

allocate (b%a1(3))

do i = 1, 3
if (allocated(b%a1(i)%x)) then
write (0, *) 'allocate_alloc2 - 2', i
call abort()
end if
allocate (b%a1(i)%x(3))
b%a1(i)%x = i + [ 1.0, 2.0, 3.0 ]
end do

end subroutine allocate_alloc2


type(alloc2) function return_alloc2() result(b)
if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'return_alloc2 - 1'
call abort()
end if

allocate (b%a2(3))
b%a2 = [ 1, 2, 3 ]

allocate (b%a1(3))

do i = 1, 3
if (allocated(b%a1(i)%x)) then
write (0, *) 'return_alloc2 - 2', i
call abort()
end if
allocate (b%a1(i)%x(3))
b%a1(i)%x = i + [ 1.0, 2.0, 3.0 ]
end do
end function return_alloc2


subroutine check_alloc2(b)
type(alloc2), intent(in) :: b

if (.NOT.(allocated(b%a2) .AND. allocated(b%a1))) then
write (0, *) 'check_alloc2 - 1'
call abort()
end if
if (any(b%a2 /= [ 1, 2, 3 ])) then
write (0, *) 'check_alloc2 - 2'
call abort()
end if
do i = 1, 3
if (.NOT.allocated(b%a1(i)%x)) then
write (0, *) 'check_alloc2 - 3', i
call abort()
end if
if (any(b%a1(i)%x /= i + [ 1.0, 2.0, 3.0 ])) then
write (0, *) 'check_alloc2 - 4', i
call abort()
end if
end do
end subroutine check_alloc2

end program alloc
! { dg-final { scan-tree-dump-times deallocate 24 original } }
! { dg-final { cleanup-tree-dump original } }


(iii) The following tests constructors:
program
  type :: mytype
integer, allocatable :: a(:, :)
  end type mytype
  type (mytype) :: x
  integer :: y(0:1, -1:0) = reshape ((/42, 99, 55, 77/), (/2,2/))
  x = mytype (y)
  call foo (x, y)
  x = mytype (reshape ((/42, 99, 55, 77/), (/2,2/)))
  call foo (x, reshape ((/42, 99, 55, 77/), (/2,2/)))
  x = mytype (bar (y))
  call foo (x, y**3)
contains
  subroutine foo (x, y)
type(mytype) :: x
integer y(:,:)
if (any (x%a .ne. y)) call abort ()
  end subroutine foo
  function bar (x)
integer, dimension(:,:) :: x
   

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[paul dot richard dot thomas at cea dot fr]

--- Comment #10 from paul dot richard dot thomas at cea dot fr  2006-07-12 
14:23 ---
Bother! Forget the last test - it is an old, incorrect version.  I will post
the right one tonight.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2006-07-12 19:41 ---
Created an attachment (id=11871)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11871action=view)
An unpolluted version of the beta-release patch

I do apologise; the previous diff was relative to a development tree that had
another patch with it.  The net result was that it undid the committed patch
and caused regressions.  The new attachment includes the three test cases; it
regtests on tonight's trunk.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #11867|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2006-05-09 21:27 ---
Eric,

when you work on this, watch out for the following test case:

PROGRAM MAIN
  TYPE foo
 INTEGER, DIMENSION(:), ALLOCATABLE :: array
  END TYPE foo

  type(foo),pointer,dimension(:) :: mol

  ALLOCATE (mol(1))
  ALLOCATE (mol(1)%array(5))
  ALLOCATE (mol(1)%array(5),stat=i)
  if (i == 0) call abort

END PROGRAM MAIN

This is the reverse (more or less) of PR 27470.
Thomas


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[eedelman at gcc dot gnu dot org]

-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |eedelman at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2006-03-12 19:53 ---
Good luck Erik.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|Intel Opteron   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[erik dot edelmann at iki dot fi]

--- Additional Comments From erik dot edelmann at iki dot fi  2005-09-29 
19:48 ---
(In reply to comment #5)
 Working on a patch.

Turned out to be much more work than I first thought.  I'll leave it for now.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[erik dot edelmann at iki dot fi]

--- Additional Comments From erik dot edelmann at iki dot fi  2005-09-27 
15:21 ---
Working on a patch.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[post at tillmann-wegst dot de]

--- Additional Comments From post at tillmann-wegst dot de  2005-07-29 
08:21 ---
I found that code containing allocatable fields in type statements compiles 
without complaints using g95, so I was a bit perplex when moving to gfortran 
and getting the same error as reported here. 

Consulting Metcalf et al, fortran 95/2003 explained, chap. 7.12, pages 149f., 
I did not find anything as to a conflict between attributes allocatable 
and dimension. Has there been a change in the Fortran95 specs? 

If it is not a gfortran bug, what would be a work-around? Declare the variable 
as a pointer, allocate the array in a subroutine and then direct the pointer 
variable to it? That seems like a way out, though clumsy. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-22 
12:42 ---
This prevents compiling the common iso_varying_string module by Rich Townsend.

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Last reconfirmed|2005-03-20 18:08:03 |2005-04-22 12:42:25
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541