2013/4/12 Tobias Burnus <bur...@net-b.de>: > Am 12.04.2013 00:05, schrieb Janus Weil: > >> Just one minor nit: >> >> + if (sym->ts.type == BT_CLASS && TREE_STATIC (sym->backend_decl) >> + && CLASS_DATA (sym)->attr.allocatable) >> >> I'd find it somewhat clearer to check for "sym->attr.save" instead of >> "TREE_STATIC (sym->backend_decl)", but that may be a matter of taste. > > I think there was a test-suite failure when I tried it. In any case, > variables might be in static memory even if attr.save is not set: > > - Module variables > - Variables of the main program > - Local variables of constant size (instead of allocating them on the > stack), depending on their size > - All local variables with -fno-automatic, which implies SAVE > - If "SAVE" has been specified for the scoping unit
Yes, but for most of them one should have attr.save=SAVE_IMPLICIT (at least for #1, #4 and #5?). And for those that do not have attr.save set, gfc_trans_deferred_vars should take care of initializing the vptr already, right? Do we have a double initlialization for these cases now? > (For the first three items, a static initialization is not required, it > could also be done after the declaration.) Instead of taking care of all > those, I think it is simpler to use TREE_STATIC ;-) > > >> Oh, and can you remind me why this does not need to be done for pointers? > > They are in undefined state. Thus, they need to be nullified, pointer > associated or allocated before they can be used. All those actions will set > both the data and the vptr component. Ok, I guess one could argue that it could not hurt to do the initialization for pointers, too. But since the standard does not seems to require it, let's forget about it. > OK as is? Yes, after answering the double-initialization question above ;) Thanks for the patch ... Cheers, Janus
