Hi all,
as this is a 5/6 regression and the patch now lived for some time in the 6
branch without any complaints, I like to propose the same patch for the
5-branch.
Bootstraps and regtests fine on x86_64-linux-gnu/f21.
Ok for trunk-5 (aka gcc-5-branch)?
Regards,
Andre
On Fri, 17 Jul 2015 12:17:07 +0200
Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Paul,
>
> thanks for the review, commited as r225928.
>
> Regards,
> Andre
>
> On Wed, 15 Jul 2015 13:40:29 +0200
> Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>
> > Dear Andre,
> >
> > I am still in the bizarre situation that the testcase compiles and
> > runs correctly on a clean trunk!
> >
> > That said, the patch applies cleanly and, at very least from my point
> > of view, does not do any harm :-)
> >
> > OK for trunk
> >
> > Thanks for the patch
> >
> > Paul
> >
> > On 11 July 2015 at 14:08, Andre Vehreschild <vehre@gmx.de> wrote:
> > > Hi Mikael,
> > >
> > >> > @@ -7030,7 +7053,8 @@ gfc_trans_subcomponent_assign (tree dest,
> > >> > gfc_component * cm, gfc_expr * expr, gfc_add_expr_to_block (&block,
> > >> > tmp); }
> > >> > else if (init && (cm->attr.allocatable
> > >> > - || (cm->ts.type == BT_CLASS && CLASS_DATA
> > >> > (cm)->attr.allocatable)))
> > >> > + || (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
> > >> > + && expr->ts.type != BT_CLASS)))
> > >> > {
> > >> > /* Take care about non-array allocatable components here. The
> > >> > alloc_* routine below is motivated by the alloc_scalar_allocatable_for_
> > >> > @@ -7074,6 +7098,14 @@ gfc_trans_subcomponent_assign (tree dest,
> > >> > gfc_component * cm, gfc_expr * expr, tmp = gfc_build_memcpy_call (tmp,
> > >> > se.expr, size); gfc_add_expr_to_block (&block, tmp);
> > >> > }
> > >> > + else if (cm->ts.type == BT_CLASS && expr->ts.type == BT_CLASS)
> > >> > + {
> > >> > + tmp = gfc_copy_class_to_class (se.expr, dest, integer_one_node,
> > >> > + CLASS_DATA
> > >> > (cm)->attr.unlimited_polymorphic);
> > >> > + gfc_add_expr_to_block (&block, tmp);
> > >> > + gfc_add_modify (&block, gfc_class_vptr_get (dest),
> > >> > + gfc_class_vptr_get (se.expr));
> > >> > + }
> > >> > else
> > >> > gfc_add_modify (&block, tmp,
> > >> > fold_convert (TREE_TYPE (tmp), se.expr));
> > >> But this hunk is canceled by the one before, isn't it?
> > >> I mean, If the condition here is true, the condition before was false?
> > >
> > > You are absolutely right. The second hunk is dead code and removed in the
> > > attached patch. That must have been the first attempt to address the issue
> > > and later on I did not perceive that it was useless. Sorry for that.
> > >
> > > Regards,
> > > Andre
> > > --
> > > 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: pr66035_5_1.clog
Type: application/octet-stream
Size: 721 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20150721/7d2c93a9/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr66035_5_1.patch
Type: text/x-patch
Size: 2428 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20150721/7d2c93a9/attachment.bin>