Bug 30625

Summary: Array pointers to components of derived type arrays do not work
Product: gcc Reporter: Paul Thomas <pault>
Component: fortranAssignee: Paul Thomas <pault>
Status: RESOLVED FIXED    
Severity: normal CC: burnus, dfranke, gcc-bugs, tkoenig, tobi
Priority: P3 Keywords: wrong-code
Version: 4.3.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2007-09-03 11:48:03
Bug Depends on: 29606    
Bug Blocks: 32834    

Description Paul Thomas 2007-01-28 20:13:51 UTC
This:

type :: a
  real :: r = 3.14159
  integer :: i = 42
end type a
type(a), target :: dt(2)
integer, pointer :: ip(:)

ip => dt%i
print *, ip
end

produces
$ ./a
  1078530000          42
with gfortran, whereas the correct result should be two 42s

Paul
Comment 1 Thomas Koenig 2007-01-28 20:33:47 UTC
Confirmed.

Is this related to PR 29606?
Comment 2 Tobias Schlüter 2007-01-29 00:16:41 UTC
Wasn't there a bug for byte-sized strides in array descriptors?  This bug should depend on it, and PR29606 as well.
Comment 3 Paul Thomas 2007-01-29 07:50:01 UTC
(In reply to comment #2)
> Wasn't there a bug for byte-sized strides in array descriptors?  This bug
> should depend on it, and PR29606 as well.
> 
Both of you are right about PR29606.  The byte-sized strides I do not remember.  It is one way to go but I do not think that it is the correct one.  I think that we need a new field in the descriptor or, maybe, a new species of descriptor. This field could serve two functions:
(i) If present for an intrinsic type, it carries the base stride in bytes; and
(ii) If present for a derived type it carries the size in bytes.
The present size subfield should be used to carry a unique code for the type, so that classes can be implemented, including abstract classes.

Paul
Comment 4 Daniel Franke 2007-02-01 11:28:12 UTC
As I came across this once more: is it possible to issue a compile-time warning that "array pointers to components of derived type arrays" are allowed by the standard but are not yet implemented in gfortran (gfc_todo, maybe)? 

This would prevent some users (e.g. me) from using it right now. If otherwise the code compiles fine, one silently gets unusable results ...
Comment 5 Paul Thomas 2007-02-02 19:20:24 UTC
Subject: Re:  Array pointers to components of derived type
 arrays do not work

dfranke at gcc dot gnu dot org wrote:
> ------- Comment #4 from dfranke at gcc dot gnu dot org  2007-02-01 11:28 -------
> As I came across this once more: is it possible to issue a compile-time warning
> that "array pointers to components of derived type arrays" are allowed by the
> standard but are not yet implemented in gfortran (gfc_todo, maybe)? 
>
> This would prevent some users (e.g. me) from using it right now. If otherwise
> the code compiles fine, one silently gets unusable results ...
>
>
>   
Daniel,

I'll see what I can come up with  - I have also been feeling round the
edges of how this might be cured.  Implementation of F2003 classes will
require another field in the descriptor.  I am trying to figure out how
best to do this without completely breaking the library API but I
am attempting to design this field to fulfill both functions.

Best regards

Paul


Comment 6 Francois-Xavier Coudert 2007-02-10 21:18:13 UTC
Paul, I take it you are aware of PR21881 ("Array descriptors limit derived type sizes")... I don't fully grasp the way array descriptor work for derived types, but I wanted to mention that PR to you... just in case.
Comment 7 Paul Thomas 2007-02-11 09:52:36 UTC
(In reply to comment #6)
> Paul, I take it you are aware of PR21881 ("Array descriptors limit derived type
> sizes")... I don't fully grasp the way array descriptor work for derived types,
> but I wanted to mention that PR to you... just in case.
> 
FX, I was aware of the problem but not of the PR; I'll be honest if I say tha I am not sure that the size limit on derived types is an issue.  After all, pointers or allocatable components can be used to keep the size of the derived type down.

I think that I need to sketch out a design and post it on the list; it'll have to be CC'd to Paul Brooks and Steven Bosscher because they are responsible for the present layout of descriptors.  They maybe have opinions about how to proceed.

Paul 


Comment 8 Joost VandeVondele 2007-07-04 06:33:50 UTC
target milestone 4.3.0 ?
Comment 9 Thomas Koenig 2007-08-18 18:28:31 UTC
Some discussion is here:

http://gcc.gnu.org/ml/fortran/2007-04/msg00115.html
Comment 10 Paul Thomas 2007-09-16 09:18:19 UTC
Subject: Bug 30625

Author: pault
Date: Sun Sep 16 09:17:49 2007
New Revision: 128523

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128523
Log:
2007-09-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/29396
	PR fortran/29606
	PR fortran/30625
	PR fortran/30871
	* trans.h : Add extra argument to gfc_build_array_ref. Rename
	gfc_conv_aliased_arg to gfc_conv_subref_array_arg.  Move
	prototype of is_aliased_array to gfortran.h and rename it
	gfc_is_subref_array.  Add field span to lang_decl, add a new
	decl lang specific flag accessed by GFC_DECL_SUBREF_ARRAY_P
	and a new type flag GFC_DECL_SUBREF_ARRAY_P.
	* trans.c (gfc_build_array_ref): Add the new argument, decl.
	If this is a subreference array pointer, use the lang_decl
	field 'span' to calculate the offset in bytes and use pointer
	arithmetic to address the element.
	* trans-array.c (gfc_conv_scalarized_array_ref,
	gfc_conv_array_ref): Add the backend declaration as the third
	field, if it is likely to be a subreference array pointer.
	(gfc_conv_descriptor_dimension, gfc_trans_array_ctor_element,
	gfc_trans_array_constructor_element, structure_alloc_comps,
	gfc_conv_array_index_offset): For all other references to
	gfc_build_array_ref, set the third argument to NULL.
	(gfc_get_dataptr_offset): New function.
	(gfc_conv_expr_descriptor): If the rhs of a pointer assignment
	is a subreference array, then calculate the offset to the
	subreference of the first element and set the descriptor data
	pointer to this, using gfc_get_dataptr_offset.
	trans-expr.c (gfc_get_expr_charlen): Use the expression for the
	character length for a character subreference.
	(gfc_conv_substring, gfc_conv_subref_array_arg): Add NULL for
	third argument in call to gfc_build_array_ref.
	(gfc_conv_aliased_arg): Rename to gfc_conv_subref_array_arg.
	(is_aliased_array): Remove.
	(gfc_conv_function_call): Change reference to is_aliased_array
	to gfc_is_subref_array and reference to gfc_conv_aliased_arg to
	gfc_conv_subref_array_arg.
	(gfc_trans_pointer_assignment): Add the array element length to
	the lang_decl 'span' field.
	* gfortran.h : Add subref_array_pointer to symbol_attribute and
	add the prototype for gfc_is_subref_array.
	* trans-stmt.c : Add NULL for third argument in all references
	to gfc_build_array_ref.
	* expr.c (gfc_is_subref_array): Renamed is_aliased_array.
	If this is a subreference array pointer, return true.
	(gfc_check_pointer_assign): If the rhs is a subreference array,
	set the lhs subreference_array_pointer attribute.
	* trans-decl.c (gfc_get_symbol_decl): Allocate the lang_decl
	field if the symbol is a subreference array pointer and set an
	initial value of zero for the 'span' field.
	* trans-io.c (set_internal_unit): Refer to is_subref_array and
	gfc_conv_subref_array_arg.
	(nml_get_addr_expr): Add NULL third argument to
	gfc_build_array_ref. 
	(gfc_trans_transfer): Use the scalarizer for a subreference
	array.

2007-09-16  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/29396
	PR fortran/29606
	PR fortran/30625
	PR fortran/30871
	* gfortran.dg/subref_array_pointer_1.f90: New test.
	* gfortran.dg/subref_array_pointer_2.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_1.f90
    trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog

Comment 11 Paul Thomas 2007-09-16 09:39:40 UTC
Fixed on trunk

Paul