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


Hi,

>> Note that the patch also does end-of-program finalization as a GNU
>> extension (i.e. it is done with -std=gnu, but not with -std=f2003),
>> after no one could explain to me so far why it would be bad to do it,
>> or why the standard does not require it
>
> 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?).


> 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).

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).

Also I would like to hear some comments from the user perspective.
Damian, Karla: Would end-of-program finalization be something you
could use? Or would it interfere with your usage of FINAL?


>> Some other minor points:
>>   * The patch includes some parts which remove GFC_DECL_PUSH_TOPLEVEL,
>> but I don't quite understand why. Tobias?
>
> It breaks some code. Try reverting it.

I'll try ...


> It is a patch, you proposed in some regression PR.

Me, really? I don't quite remember this ;)

Do you know which PR it was?

Cheers,
Janus


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