This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Array Descriptor Update
Hi Paul,
Paul Richard Thomas wrote:
Janne and Thomas have been contributing to a rather important page on
the gfortran wiki: http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
It starts with, "In some cases it would be nice to improve gfortran's
array descriptors."
This is indeed interesting (I've followed the talk about array
descriptors a bit in the past), and although I'm not really an expert on
this topic, would like to contribute whatever I can.
I think that it has become essential to do this as one of the first
tasks in gcc-4.5, for the reasons given in the wiki page and to
realise such things as allocatable scalars and, I have come to
believe, CLASSES. The reason it might be a good thing for classes is
because of the need to carry a type identifier with the class pointer.
This could be done in the same way as character lengths, as at
present, or as a descriptor field. I do wonder if this is not the
purpose of the reserved word in the Intel descriptor?
If I understand you correctly, we would have one type of descriptor that
would be used for allocated arrays as well as allocatable scalars and
CLASS pointers/pointees, so that would be "the" place to store the
runtime type token?
As you mentioned character lengths, maybe we should think about length
type parameters in general for this project? But that's just an
associative thought, I've no idea at the moment about what length type
parameters really impose on the compiler.
One thing that is noticable about the Intel and the Pathscale
descriptors is that they carry no type or kind information, whereas
gfortran packs this into the DTYPE word. I started looking to see if
gfortran uses this descriptor information anywhere and so far have
drawn a blank; admittedly on a not very thorough search. In addition,
I have not seen any use of the size information either. Does anybody
know if it is used anywhere?
I can't answer your original question, but I believe this information is
not really "needed" as the type is compile time known and gfortran can
insert the appropriate handling for the type at compile time; I guess
that's why we don't need it... But with your proposal for polymorphic
entities, we would want to carry a runtime type. I guess we could
probably drop the static type information (for CLASS(t) it would be "t")
and replace it by the dynamic one (the runtime type).
It crosses my mind that in order to preserve backward compatibility of
the API, we could put extra information after the dimension fields and
leave the latter alone. This would have the disadvantage that the
reform (stride, lbound, ubound) => (lbound, stride, extent) and
handling bytes rather than words would be put off. How important is
backward compatibility?
What I heard from the talk about 4.3 ABI breakage, I got the idea that
in the past each major version of gfortran broke it anyways (maybe
except the upcoming 4.4 now?). So for a descriptor rework in favor of
new features like allocatable scalars or CLASS, I would see it
reasonable to simply go along and do the best of design we can come up
with, not introducing any kludges to try preserving the ABI. But that's
of course only my personal opinion, as someone who didn't really use any
Fortran for large projects yet and does not have any compiled code lying
around...
Thanks for bringing this up!
Daniel
--
Done: Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou