This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gfortran links to bug lists


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]