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


On Wed, Sep 01, 2010 at 08:19:04PM +0200, Tobias Burnus wrote:
>  Am 01.09.2010 19:39, schrieb Steve Kargl:
> >On Wed, Sep 01, 2010 at 07:01:02PM +0200, Tobias Burnus wrote:
> >>The question is: Why are INTENT(OUT) variables already assigned a value?
> [...]
> >16.5.5
> >(23) Invocation of a procedure that has a nonpointer nonallocatable
> >      INTENT (OUT) dummy argument causes all nonpointer default-initialized
> >      subcomponents of the dummy argument to become defined.
> >Note there are restrictions on optional arguments.
> 
> Thanks for the reminder of optional arguments; still, I am not sure what 
> your answer is supposed to tell me.
> 
> My point was that - even without touching a derived-type intent-out 
> dummy variable, it gets initialized. (As required by the standard.) 

I could not tell from the thread whether you and janus were
debating whether default initialization must occur or not
for an INTENT(OUT) dummy argument.  So, I provided the text
from the standard.

> Thus, it works even if the code the following code is not executed as 
> attr.referenced is false:

I further may have misunderstood the code in that I thought
attr.referenced was required to trigger the default initialization.
If you're finding that the check for attr.referenced can be 
removed and everything continues to work, then its presence in
the conditional may be a holdever from older code.

> Steve, do you see whether the "&& sym->attr.referenced" in the outer 
> loop is required? If yes, why? If not, why does the DT always seems to 
> be properly intialized? Is this dead code? I would understand a 
> "a->referenced" for the non-dummy part inner if-condition to avoid 
> initialization of unused variables.

I'll need to investigate,  ISTR, a PR or two that default initialization
wasn't working correctly.  A "grep 'default init' ChangeLog*"
doesn't show an apparent smoking gun, but there are some
candidates to check.  It is possible that this is dead code.

2004-05-18  Paul Brook  <paul@codesourcery.com>

        PR fortran/13930
        * decl.c (add_init_expr_to_sym): Remove incorrect check.
        (default_initializer): Move to expr.c.
        (variable_decl): Don't assign default initializer to variables.
        * expr.c (gfc_default_initializer): Move to here.
        * gfortran.h (gfc_default_initializer): Add prototype.
        * resolve.c (resolve_symbol): Check for illegal initializers.
        Assign default initializer.

2004-05-14  Victor Leikehman  <lei@haifasphere.co.il>

        * decl.c (variable_decl): Always apply default initializer.

2006-08-19  Erik Edelmann  <eedelman@gcc.gnu.org>

        PR fortran/25217
        * resolve.c (resolve_fl_variable): Set a default initializer for
        derived types with INTENT(OUT) even if 'flag' is true.
        * trans-expr.c (gfc_conv_function_call): Insert code to
        reinitialize INTENT(OUT) arguments of derived type with default
        initializers.



-- 
Steve


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