This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 43388: [F2008] ALLOCATE with MOLD=


On Sun, Jun 13, 2010 at 07:25:34PM +0200, Tobias Burnus wrote:
> Tobias Burnus wrote:
> > No, C637 ensures that there is either a MOLD=source-expr or
> > SOURCE=source-expr:
> >
> > "C637 (R626) At most one of source-expr and type-spec shall appear."
> > (F2008 FDIS of 7th June 2010).
> >
> > Does the patch check for this constraint?
> >   
> 
> Other observations regarding ALLOCATE - not necessarily directly related
> to the patch. I have not checked whether there are already PRs for those.
> 
> * MOLD= and default initializer: As Janus has correctly stated, MOLD
> implies that the default initializer is used. If one searches for the
> proposal email at J3, this is explicitly stated there. I think the patch
> does not handle this for CLASS - please note this in the PR.

I believe that this is handled in the patch:

@@ -6419,8 +6433,22 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
   if (!code->expr3)
     {
       /* Add default initializer for those derived types that need them.  */
-      if (e->ts.type == BT_DERIVED
-         && (init_e = gfc_default_initializer (&e->ts)))
+      gfc_expr *init_e = NULL;
+      gfc_typespec ts;
+
+      if (code->ext.alloc.ts.type == BT_DERIVED)
+       ts = code->ext.alloc.ts;
+      else if (code->expr4)
+       ts = code->expr4->ts;
+      else
+       ts = e->ts;
+        
+      if (ts.type == BT_DERIVED)
+       init_e = gfc_default_initializer (&ts);
+      else if (e->ts.type == BT_CLASS)
+       init_e = gfc_default_initializer (&ts.u.derived->components->ts);
+      
+      if (init_e)

> * The constraint C637 (cf. above) does not seem to be checked for.

Yes, I think you're right that C637 prohibits MOLD and SOURCE 
from appearing in the same statement.  I was looking for a 
constraint the explicitly made this statement.

> * The following does not compile although it does not violate C633:
> 
> integer, allocatable :: a(:), b(:)
> allocate (a, source = b)

What's the error message (my gfortran is currently building)?
Technically, the above is invalid because b is undefined.

-- 
Steve


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]