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] |
>> 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] |