From: dominiq@lps.ens.fr (Dominique Dhumieres)
To: fortran@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org, pault@gcc.gnu.org, burnus@net-b.de
Subject: Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
Date: Mon, 07 Jan 2013 16:22:00 -0000 [thread overview]
Message-ID: <20130107162204.DBBE43BC70@mailhost.lps.ens.fr> (raw)
Sorry for the late and lengthy answer. To make the story short, I think
the decision to remove -fno-whole-file should be based on the answer to the
following questions:
(1) Is there any hint of -fno-whole-file misbehavior (as suggested by the
second point of the "Reasoning")?
As said in my comment below, if the answer is yes, then IMO this should be
investigated and fixed before removal.
(2) Is the -fwhole-file status ZKB (zero known bug)?
I am not 100% confident that this the case (see at least PR 45128).
(3) What is the confidence that there is no rampant bug in -fwhole-file?
While I cannot remember any recent PR in this area (thanks Paul), at the
same time I did not see recent reports (in buzilla or in comp.lang.fortran)
about the common errors which have plagued the f77 to f90 transition.
(4) Is there an easy replacement for -fno-whole-file?
Here the answer is clearly yes: put the different TUs in different files.
So to summarize, I think the key point is the answer to the first
question. I think the answer is no, but this was not what I understood
from the original post.
> This patch "removes" -fno-whole-file. (Actually, it turns it into
> "Ignore".)
>
> Reasoning:
>
> * -fwhole-file/-fno-whole-file was added in 4.5 to make the transition
> easier; -fwhole-file is the default since 4.6.
My understanding of -fno-whole-file as well as -fno-realloc-lhs,
-fno-frontend-optimize, or any of the -fno-* options is two fold:
(i) to provide a workaround to user hit by a bug in the corresponding area,
(ii) to help the maintainers to locate the bug or to change the default in
case of a too severe bug.
So the decision to remove an option should be based on the answer to the
questions (2) and (3) above.
> * There are many wrong-code issues and probably also some ICEs with
> -fno-whole file.
I think the wording is misleading. I have checked bugzilla for open PR
containing -fno-whole-file and I have found only 2 (48939 and 52621).
None of them are related to wrong-code issue due to -fno-whole-file.
My understanding of the -fno-whole-file option is that it is (should be)
strictly equivalent to put all the TUs in separate files. If it exists an
example for which this is not true, I think it would be a bug, a PR should
be filled for it, and indeed, the removal of -fno-whole-file should be
delayed after it the bug(s) is (are) fixed.
If the meaning of the quoted sentence is that -fwhole-file gives errors
for invalid code (missing interface, argument mismatches, ...), hence
prevents "wrong-code" issues, this is true. However such errors can only
be catched if all the involved TUs are in the same file, e.g. I won't get
any error if I mess up the arguments of a subroutine in the lapack library
unless I add it (and its dependencies) to my source.
> * The generated code of -fwhole-file is faster as it allows for inlining.
This has nothing to do with the removal of -fno-whole-file.
AFAICT most of the speeddup is achieved with -fwhole-program.
In addition the code has to be in a single file. On platforms with the
right linker and the right plugin (i.e. not Darwin) the speedup for split
files can be obtained by compiling the different files with -flto.
> * -fno-whole-file has been deprecated since 4.6 and announced for
> removal.
>
OK, but no time table has been released so far.
> * Code cleanup is always nice (diff -w): 17 insertions(+), 80
> deletions(-)
OK
> Build and regtested on x86-64-gnu-linux.
>
> OK for the trunk?
>
> PS: Dominique pointed out that PR 45128 is a -fwhole-file "regression".
> However, it mainly shows that gfortran needs the new array descriptor to
> fix such subpointer issues (and other PRs).
Compiling PR 45128 with -fwhole-file gives an ICE: Segmentation fault,
while with -fno-whole-file it gives a linking error
Undefined symbols:
"_span.0", referenced from:
...
as it does if the two TUs are put is different files.
Dominique
next reply other threads:[~2013-01-07 16:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 16:22 Dominique Dhumieres [this message]
2013-01-07 18:23 ` Tobias Burnus
-- strict thread matches above, loose matches on Subject: below --
2013-01-04 23:31 Tobias Burnus
2013-01-07 14:14 ` Tobias Burnus
2013-02-13 18:20 ` Tobias Burnus
2013-02-13 19:29 ` Steve Kargl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130107162204.DBBE43BC70@mailhost.lps.ens.fr \
--to=dominiq@lps.ens.fr \
--cc=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=pault@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).