This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8


Janus Weil wrote:
I don't think that it is a good idea to finalize SAVE variables by default, if they declared in the main program.
In fact, the current patch does it only for non-SAVE variables
(although SAVE should not really make much of a difference for
variables declared in the main program, right?).

In terms of the Fortran standard (F2008, 5.3.16 SAVE attribute), the non-SAVE doesn't make sense as:


"A variable, common block, or procedure pointer declared in the scoping unit of a main program, module, or submodule implicitly has the SAVE attribute, which may be confirmed by explicit specification."

In other words, your patch doesn't finalizes main-program variables which have an explicit SAVE attribute, except for those which got it implicitly, but, I presume, not if they got it via a SAVE
statement without a saved entity list. ;-)



I concur that it is unclear why the
standard is as it is, but I don't think to break the standard with default
options (-std=gnu is the default) is a good idea.
Well, yeah. I guess one can argue about this.

On one hand, a good Fortran compiler should clearly obey the Fortran
standard. And with the -std=... switch, we even have a nice way of
supporting different versions of the standard.

On the other hand, I'd rather implement something that "makes sense"
than something that blindly obeys some (screwed-up) standard. So, the
first thing should be of course to find out whether this was in fact
"screwed up" in the standard, or if it was done on purpose (and if
yes, for what reason).

I think it was done on purpose - or at least consciously. The only purpose might be that it was done for consistency as variables SAVE or it might have a deeper reason.


You should really ask at the J3 mailing list, maybe they have a good answer.

Regarding extensions: The idea of extensions is usually to provide additional features without breaking the (current) standard. Your proposal on purpose breaks the standard.

My idea behind implementing it as an extension was to support both
options, and let the user choose which one he wants. However, I agree
that using the non-standard version by default may be dangerous. Since
we probably don't want to make -std=f2008 the default (for reasons of
backward compatibility), one alternative might be to add a separate
switch ("-finalize-main" or whatever).

I wouldn't oppose against an extra flag; although, I probably wouldn't use it.


It is a patch, you proposed in some regression PR.
Me, really? I don't quite remember this ;)

PR 53718.


Tobias


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