This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: "Rouson, Damian" <rouson at sandia dot gov>, Mikael Morin <mikael dot morin at sfr dot fr>, gfortran <fortran at gcc dot gnu dot org>, Paul Thomas <paul dot richard dot thomas at gmail dot com>, Alessandro Fanfarillo <fanfarillo dot gcc at gmail dot com>, "Morris, Karla NMN" <knmorri at sandia dot gov>
- Date: Wed, 31 Oct 2012 16:14:41 +0100
- Subject: Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- References: <CCB314C5.16750%rouson@sandia.gov> <8BD04F8FCECE2F43BE5F3D8C4EDB452D4D0B166B@EXMB09.srn.sandia.gov> <CAKwh3qg8Po3gOkCn3tDUtoKVJ90WOHUeNX0_Sa1KPJMqc03ePA@mail.gmail.com> <CAKwh3qi2fieN3ojBK5DGrxXUf8ccwiP_dMJiWNHrRdAyM0X=9w@mail.gmail.com> <CAKwh3qh0gWPyLH+eE8y6x2jhu3umfbwY1bGXQi13gw6WTK5B_Q@mail.gmail.com> <509112CB.3040804@net-b.de>
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
- References:
- Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8
- Re: [EXTERNAL] Re: [Patch, F03, RFC] FINAL support in 4.8