This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Fwd: Bumping of libgfortran major version number and git
The email from my tablet had mime content.
Paul
---------- Forwarded message ----------
From: Paul Richard Thomas <paul.richard.thomas@gmail.com>
Date: 12 October 2016 at 05:50
Subject: Re: Bumping of libgfortran major version number and git
To: jerry DeLisle <jvdelisle@charter.net>
Cc: kargl@uw.edu, fortran@gcc.gnu.org
Dear All,
Indeed Tobias and I have returned to fortran-dev. When I return from
vacation, I intend to deal with the remaining regressions, do a
further merge to get the tree up to date and deal with the consequent
fall out. Beyond this, there is rather a lot to do: Most notable are
some performance hits; There are failing vectorization opportunities
and; There is a general tidy up todo. In addition, since it is one of
the motivations of the work, pointers to components of derived type
arrays should finally be fixed properly. I am not at all sure that I
can get this done before the end of stage 1, especially since I have
two other stage 1 patches that should be committed: the select type
fix and recursive allocatable components..
By the way, the dimension triplets {lbound, stride measure, extent}
have been implemented. However, to make the overall job easier, we
retained gfc_conv_descriptor_stride/ubound_set/get, even where this
results in multiplication by and division by the stride measure in the
same expression. This is probably the source of the performance hit
annd is not optimized away because there is a guard condition to
prevent division by zero.
Best regards from Thailand
Paul
On 10 Oct 2016 20:32, "Jerry DeLisle" <jvdelisle@charter.net> wrote:
On 10/10/2016 10:23 AM, Steve Kargl wrote:
> On Mon, Oct 10, 2016 at 09:09:46AM -0700, Jerry DeLisle wrote:
>>
>> I plan to submit a patch for approval that will bump the
>> libgfortran version number and do a few cleanup things.
>> I have the impression that we have a consensus on this.
>> I think it should be done before GCC 7 release.
>
> Hopefully, Janne chimes in. I believe he hasi/had thought about
> how to go about addressing some of the issues listed on the wiki.
>
>>
>> I also think the fortran-dev branch is very close to a clean
>> merge with trunk. Of course I could be mistaken (IMHO)
>>
>
> I haven't followed fortran-dev for a few years now. I thought
> development on the array descriptor reform was stalled at adding
> in extent.
>
Tobias and Paul have been bringing descriptor change alive on fortran-dev. There
are a handful of regressions, some of which are coarray related.
Jerry
--
The difference between genius and stupidity is; genius has its limits.
Albert Einstein