[committed, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted as array and Re: [Patch, Fortran, v1] Cosmetics and code simplify

Andre Vehreschild vehre@gmx.de
Tue Mar 24 11:51:00 GMT 2015


Dear Paul, Dear Mikael, hi all,

thanks for reviewing. I have just committed the patches for:

[Patch, Fortran, pr55901, v1] [OOP] type is (character(len=*)) misinterpreted
	as array, and
[Patch, Fortran, v1] Cosmetics and code simplify

as r221627.

Regards,
	Andre

2015-03-24  Andre Vehreschild  <vehre@gmx.de>

        PR fortran/55901
        * trans-expr.c (gfc_conv_structure): Fixed indendation.
        Using integer_zero_node now instead of explicitly
        constructing a integer constant zero node.
        (gfc_conv_derived_to_class): Add handling of _len component,
        i.e., when the rhs has a string_length then assign that to
        class' _len, else assign 0.
        (gfc_conv_intrinsic_to_class): Likewise.

On Mon, 23 Mar 2015 12:28:03 +0100
Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:

> Dear Andre,
> 
> Yes, that's right.  The first three (vtab rework 1/2 and pr64787) are
> combined and reformatted in the .diff file that I sent you. Please use
> that and then apply the pr55901 patch. This is what I am okaying.
> 
> Cheers
> 
> Paul
> 
> On 23 March 2015 at 10:45, Andre Vehreschild <vehre@gmx.de> wrote:
> > Hi Paul,
> >
> > thanks for the reviews. Let me ask one questions before I do something
> > wrong. You have reviewed and approved (with changes) the patches:
> >
> > - vtab_access_rework1_v1.patch
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html
> > - vtab_access_rework2_v1.patch
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html
> > - pr64787_v2.patch
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
> > and
> > - pr55901_v1.patch
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html
> > , right?
> >
> > I am asking so explicitly, because there are four more patches from me in
> > the wild, that await review (not necessarily from you, Paul), namely:
> >
> > - pr60322_base_1.patch
> >         https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html
> > - pr60322_3.patch
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00032.html
> > - crashfix2_v1.patch (small patch, ~100 loc))
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00063.html
> > and
> > - cosm_simp.patch (tiny patch, ~20 loc)
> >         https://gcc.gnu.org/ml/fortran/2015-03/msg00088.html
> >
> > Please don't get me wrong on this. I just want to prevent misunderstandings
> > here. The latter four patches are not yet approved, right?
> >
> > I will now apply the 4.9-trunk patch and wait for your answer before
> > applying the above four on vtab_rework pr64787 and pr55901.
> >
> > Regards,
> >         Andre
> >
> >
> >
> > On Mon, 23 Mar 2015 08:33:51 +0100
> > Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> >
> >> Dear Andre,
> >>
> >> I am persuaded by the arguments of Jerry and Dominique that this is
> >> good for trunk. Please commit as early as possible in order that any
> >> regressions can be caught, if possible, before release.
> >>
> >> Thanks
> >>
> >> Paul
> >>
> >> On 21 March 2015 at 15:11, Paul Richard Thomas
> >> <paul.richard.thomas@gmail.com> wrote:
> >> > Dear Andre,
> >> >
> >> > I have applied the three preliminary patches but have not yet applied
> >> > the attached one for PR55901. As advertised the composite patch
> >> > bootstraps and regtests on FC21,x86_64.
> >> >
> >> > I went through gfc_trans_allocate and cleaned up the formatting and
> >> > some of the text in the comments. You did a heroic job to tidy up this
> >> > function and so I thought that I should do my bit - one of the
> >> > feature, previously, was that the line length often went well in
> >> > excess of the gcc style guide limit of 72 and this tended to make it
> >> > somewhat unreadable. I have not been rigorous about this, especially
> >> > when readability would be impaired thereby, but it does look a lot
> >> > better now. The composite diff is attached.
> >> >
> >> > Not only does the Metcalf example run correctly but also the PGI
> >> > Insider linked list example.  I have attached a version of this
> >> > modified to function as a gfortran.dg testcase. With the attributions
> >> > in there, I do not think that there are any copyright issues. The
> >> > article itself has no copyright notice.
> >> >
> >> > I would very much like to say that this is OK for trunk but we are
> >> > hard up against the end of stage 4 and so it should really wait for
> >> > backporting to 5.2.
> >> >
> >> > Thanks for the patches
> >> >
> >> > Paul
> >> >
> >> > On 19 March 2015 at 16:13, Andre Vehreschild <vehre@gmx.de> wrote:
> >> >> Hi all,
> >> >>
> >> >> please find attached the parts missing to stop valgrind's complaining
> >> >> about the use of uninitialized memory. The issue was, that when
> >> >> constructing a temporary class-object to call a routine with unlimited
> >> >> polymorphic arguments, the _len component was never set. This is fixed
> >> >> by this patch now.
> >> >>
> >> >> Note, the patch is based on all these preliminary patches:
> >> >>
> >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html
> >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html
> >> >> https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
> >> >>
> >> >> Bootstraps and regtests ok on x86_64-linux-gnu/F20.
> >> >>
> >> >> Please review!
> >> >>
> >> >> - Andre
> >> >> --
> >> >> Andre Vehreschild * Email: vehre ad gmx dot de
> >> >
> >> >
> >> >
> >> > --
> >> > Outside of a dog, a book is a man's best friend. Inside of a dog it's
> >> > too dark to read.
> >> >
> >> > Groucho Marx
> >>
> >>
> >>
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr55901_cosm_simp.patch
Type: text/x-patch
Size: 6331 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150324/f81a0cb6/attachment.bin>


More information about the Gcc-patches mailing list