This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: PR29098 - allocation of a pointer to a derived type crashes
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Paul Thomas <paulthomas2 at wanadoo dot fr>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, vahtras at pdc dot kth dot se
- Date: Sat, 16 Sep 2006 11:28:16 -0700
- Subject: Re: PR29098 - allocation of a pointer to a derived type crashes
- References: <450C3CC8.50205@wanadoo.fr>
On Sat, Sep 16, 2006 at 08:04:56PM +0200, Paul Thomas wrote:
> I'd like an opinion or two on fixes for this PR. It arises because a
> derived type with default initializers on some but not all of the
> components causes resolve_call to return FAILURE when trying to resolve
> an interface assign. This happens because resolve_expr returns FAILURE
> for the second argument of the subroutine - correctly because it cannot
> be resolved. I have two fixes in mind:
>
> (i) Is posted on the PR - provide an expression and set EXPR_NULL for
> all the remaining un-initialized components. This correctly sets zeros
> for everything under the sun, to my considerable surprise (and puts in
> mind a default initialization scheme... but that is another story) .
>
> (ii) Is to catch the failure to resolve the actual argument list in the
> case that the code is an EXEC_ASSIGN_CALL. ie:
>
(snip)
>
> Both regtest fine and my preference is for the first because everything
> is resolved but both seem to be sound.
(i) seems clean. Should gfortran issue a warning about the
unitialized components being forcibly initialized?
--
Steve