This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gfortran links to bug lists
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, Daniel Franke <franke dot daniel at gmail dot com>, Brooks Moses <brooks dot moses at codesourcery dot com>, Tobias Sc hlüter <tobias dot schlueter at physik dot uni-muenchen dot de>, blomqvist dot janne at gmail dot com
- Date: Fri, 20 Jul 2007 19:47:03 +0200
- Subject: Re: gfortran links to bug lists
- References: <469E793B.4010004@wanadoo.fr> <469EC4E2.5030400@verizon.net>
Jerry, Daniel, Brooks, Tobias and Janne,
Thanks for your replies. As you might have gathered, my ability to stay
in touch is a bit limited at present - hence the delay in replying.
I find it a bit concerning that the focus has shifted so far to F2003
that I have had to resurrect my own Bugzilla lists. Is this really
what we want to be doing right now? If so, OK, I'll plough my own
furrow but I'd rather that we all pulled together.
I agree we need to focus on the bug list.
Good - I apologise if I gave the impression that I thought that others
were not attending to F95 bugs - the furrow that I was referring to was
that of how to list the PRs!
I was very disappointed at the complete lack of interest in revamping
the parser to carry out some fairly fundamental inprovements to
gfortran. Whilst we are doing OKish on Polyhedron execution tests,
we are still not scoring very well on diagnostics and module usage is
woefully slow. (Try to get your heads around F2003 classes without
sorting this out.)
I will work with you on this.
That would be great :-)
Maybe we should take a month and focus a few of us on one area and see
what we can do. I am OK with that.
That would help a lot - perhaps a spring cleaning at the Wiki is
overdue? We did have a "baddest bugs" page at one stage. I am unable
to look at the Wiki as I write this and so cannot check what is there.
On the question of missing F95 features:
As far as I know, the ability to point to sub-objects, eg. substrings in
arrays or components of arrays of derived types is indeed about the only
missing feature. You might recall the exchange on the list around 11th
April this year. Paul Brook and I discussed the approach to be taken to
this. There were three options:
byte-sized strides
an addition to the pointer decl to carry the target info
or a library function
He offered the opinion:
"Ideally we would use this as an excuse to expose proper multi-d addressing to
the middle-end. I'm not sure how practical/hard work that is though. In that
case we can factor out the stride multiplication and put it directly into the
ARRAY_REF.
I recommend asking on gcc@ what the best representation would be. There's been
some discussion recently about the representation of indirect references.
Given we're changing things it makes sense to coordinate with the
middle-end/loop optimizer folks to get the right representation.
It would probably be helpful to write a C implementation of what we want, so
that folks not familiar with gfortran can understand what we're trying to
achieve."
I am afraid that I became distracted by the daytime job and did not follow this up.
Without this sort of reform, I have concluded that a similar mechanism to GFC_ARRAY_TYPE_P's is the only way to prevent the addition of "extended pointers" (for want of a better name) from reducing the performance of gfortran in ordinary indexed references. ie. we introduce DECL_LANG_FLAG_6 to identify such a pointer and the TYPE_LANG_SPECIFIC field should carry the required information about the offset and the span.
Cheers
Paul