GCC Bugzilla – Bug 30625
Array pointers to components of derived type arrays do not work
Last modified: 2007-09-16 09:39:40 UTC
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
with gfortran, whereas the correct result should be two 42s
Is this related to PR 29606?
Wasn't there a bug for byte-sized strides in array descriptors? This bug should depend on it, and PR29606 as well.
(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.
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 ...
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 ...
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.
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.
(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.
target milestone 4.3.0 ?
Some discussion is here:
Subject: Bug 30625
Date: Sun Sep 16 09:17:49 2007
New Revision: 128523
2007-09-16 Paul Thomas <email@example.com>
* 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_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.
(gfc_conv_function_call): Change reference to is_aliased_array
to gfc_is_subref_array and reference to gfc_conv_aliased_arg to
(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
* 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
(nml_get_addr_expr): Add NULL third argument to
(gfc_trans_transfer): Use the scalarizer for a subreference
2007-09-16 Paul Thomas <firstname.lastname@example.org>
* gfortran.dg/subref_array_pointer_1.f90: New test.
* gfortran.dg/subref_array_pointer_2.f90: New test.
Fixed on trunk