Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file

[dominiq at lps dot ens dot fr (Dominique Dhumieres)]

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