This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value
- From: Andre Vehreschild <vehre at gmx dot de>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>, GCC-Fortran-ML <fortran at gcc dot gnu dot org>
- Date: Fri, 8 May 2015 15:31:46 +0200
- Subject: Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value
- Authentication-results: sourceware.org; auth=none
- References: <20150415200304 dot 7101aca9 at gmx dot de> <55337CF3 dot 9010002 at sfr dot fr> <20150423200052 dot 2e7a1311 at gmx dot de> <553CBC80 dot 2050208 at sfr dot fr> <20150505110026 dot 7ecbc229 at gmx dot de> <554B3B23 dot 3050800 at sfr dot fr> <20150508125444 dot 50e234d6 at gmx dot de> <554CB85A dot 70901 at sfr dot fr>
Hi Mikael,
> > ?? I don't get you there? What do you mean? Do you think the
> > alloc_comp_class_3/4.* are not correctly testing the issue? Any idea of how
> > to test this better? I mean the pr is about this artificial constructs. I
> > merely struck it in search of a pr about allocatable components.
>
> I was talking about the bug you found with t_init above. :-)
> the compiler is not ready to accept that function in a testcase.
> The alloc_omp_class_3/4 are fine.
Oh, sorry, I misunderstood you there. Now let's see, where that one is hiding.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
- References:
- Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value
- Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value
- Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value
- Re: [Patch, Fortran, PR58586, v3] ICE with derived type with allocatable component passed by value