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 44541: wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD


>> Actually I only copied this from the BT_DERIVED case, assuming this
>> condition would be the same for both. So probably we should also
>> change this for BT_DERIVED dummies, right? How about:
>
> I thought I saw about a year ago a PR that gfortran _warns_ if one does not
> assign to an INTENT(OUT) variable - as the value is set. I thus think
> gfortran most of the time already initializes BT_DERIVED variables.
>
>
>> @@ -12179,7 +12148,6 @@ resolve_symbol (gfc_symbol *sym)
>> ? ? ? described in 14.7.5, to those variables that have not already
>> ? ? ? been assigned one. ?*/
>> ? ?if (sym->ts.type == BT_DERIVED
>> -&& ?sym->attr.referenced
>> ? ? ? ?&& ?sym->ns == gfc_current_ns
>> ? ? ? ?&& ?!sym->value
>> ? ? ? ?&& ?!sym->attr.allocatable
>
> That looks fine but ...
>
>> @@ -12187,13 +12155,17 @@ resolve_symbol (gfc_symbol *sym)
>> ? ? ?{
>> ? ? ? ?symbol_attribute *a =&sym->attr;
>>
>> - ? ? ?if ((!a->save&& ?!a->dummy&& ?!a->pointer
>> + ? ? ?if ((!a->save&& ?!a->dummy&& ?!a->pointer&& ?a->referenced
>> ? ? ? ?&& ?!a->in_common&& ?!a->use_assoc
>> ? ? ? ?&& ?!(a->function&& ?sym != sym->result))
>> ? ? ? ? ?|| (a->dummy&& ?a->intent == INTENT_OUT&& ?!a->pointer))
>> ? ? ? ?apply_default_init (sym);
>> ? ? ?}
>
> I don't think that's correct: We do not want to default initialize unused
> (local) variables. Only dummy arguments - and there is no a->referenced
> ?check for them.

I don't see what you mean. The intention here was to check the
'referenced' attribute only for non-dummies, but anyway ...


> The question is: Why are INTENT(OUT) variables already assigned a value? I
> do not want to change the code until one has understood, why the following
> currently works - or until one has found an example which fails the the
> current code. The following example prints "1":
>
> type t
> ?integer :: i = 1
> end type t
> type(t) :: a
> a%i = 8
> call init(a)
> print *, a
> contains
> subroutine init(x)
> ?type(t), intent(out) :: x
> end subroutine
> end

... since everything seems to work for BT_DERIVED, I'll just leave
that case alone ...


>> + ?if (sym->ts.type == BT_CLASS&& ?sym->ns == gfc_current_ns
>> +&& ?sym->attr.dummy&& ?sym->attr.intent == INTENT_OUT)
>> + ? ?apply_default_init (sym);
>
> As in the BT_DERIVED checks above, you probably should also check for
> !pointer and !allocatable.


... and commit the attached patch with the following hunk:

@@ -12194,6 +12163,11 @@ resolve_symbol (gfc_symbol *sym)
 	apply_default_init (sym);
     }

+  if (sym->ts.type == BT_CLASS && sym->ns == gfc_current_ns
+      && sym->attr.dummy && sym->attr.intent == INTENT_OUT
+      && !sym->attr.pointer && !sym->attr.allocatable)
+    apply_default_init (sym);
+
   /* If this symbol has a type-spec, check it.  */
   if (sym->attr.flavor == FL_VARIABLE || sym->attr.flavor == FL_PARAMETER
       || (sym->attr.flavor == FL_PROCEDURE && sym->attr.function))


Cheers,
Janus

Attachment: pr44541_v2.diff
Description: Binary data


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