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

[Tobias Burnus <burnus@net-b.de>]

Dominique Dhumieres wrote:
> (1) Is there any hint of -fno-whole-file misbehavior (as suggested by the
> second point of the "Reasoning")?

The middle end is simply not prepared for having multiple declaration 
for a single file ("translation unit"), which leads to wrong 
optimizations and thus to wrong code.

I think the bug which triggeded my decision to fix all remaining known 
-fno-whole-file issues and then to enable it by default  was PR 44945. 
See also http://gcc.gnu.org/ml/fortran/2010-07/msg00321.html

But there are surely more. Using multiple declarations was simply a 
design bug in the original implementation of gfortran, which was only 
realized rather late - and then deferred. Paul was that brave to fix 
this by implementing -fwhole-file.

> As said in my comment below, if the answer is yes, then IMO this should be
> investigated and fixed before removal.

We did the investigation when switching to -fwhole-file by default. And 
no, I do not want to investigate why the middle end "misbehaves" with 
multiple declarations in a single translation unit - nor do I want to 
fix it. I am content if everything works with -fwhole-file. There is 
really not any advantage of having multiple declarations in a single TU.

> (2) Is the -fwhole-file status ZKB (zero known bug)?
> I am not 100% confident that this the case (see at least PR 45128).

I am not aware of any bug since 4.6. I am rather certain that we fixed 
all known bugs in this area. Neither having remaining mult-decls nor 
issues which wouldn't occur with -fno-whole-file. By now it simply makes 
more sense to fix a bug, ignoring whether it worked by chance with 
-fno-whole-file or not. All recent regressions seem to be unrelated. 
Thus, for users it makes more sense to use an older version or wait for 
the patch than to try -fno-while-file. Given the potential to generate 
wrong-code bugs, I wouldn't trust -fno-whole-file for any code which 
goes beyond a hello-world example.

PR45128 requires the new array descriptor; we have a kludge which allows 
sub-type pointer in some cases. Seemingly, that kludge works in one case 
with -fno-whole-file where it fails with -fwhole-file. But I will 
actively ignore all subpointer PRs until the new array descriptor is 
ready, which will be the right fix.

> (3) What is the confidence that there is no rampant bug in -fwhole-file?

Well, even if there is a bug which doesn't affect -fno-whole-file, using 
-fno-whole-file is no solution, given that -fno-whole-file has many 
known bugs.

And while I am willing to fix -fwhole-file bugs, I will ignore any 
-fno-whole-file ones.

> (4) Is there an easy replacement for -fno-whole-file?

Yes: -fwhole-file :-)  Really, you shouldn't think of -fno-whole-file 
anymore.

> Here the answer is clearly yes: put the different TUs in different files.

Or doing that ;-)

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

Well, the main point of -fno-realloc-lhs is to disable the performance 
penalty of RHS. That is also helped to find some bugs was a side effect. 
For -fno-frontend-optimize I agree that its purpose was indeed to toggle 
the optimization separately from only using -O0 vs -O1.

But there is a difference between -frealloc-lhs, -ffrontend-optimize and 
-fwhole-file: The former two enable a specific feature or optimization 
and valid programs can (should) be produced with either version. By 
contrast, in terms of middle-end assumptions -fno-whole-file is always 
wrong.

I think (ii) does not really apply. We never changed the defaults when a 
serious bug popped up, we always fixed it. [Though we might have 
suggested a command-line option as workaround, cf. (i).] For 
-fno-whole-file, it also didn't help much with localizing the bug. For 
-f(no-)frontend-optimize I agree that it helped several times to isolate 
the bug.

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

You have to search for mult-decl issues. -fwhole-file was the cure of 
that problem; as it had a couple of issues before July 2010 and wasn't 
enabled by default, almost no one used it. Hence, you don't find it in 
the log. And after -fwhole-file became the default, no one cared anymore 
about issues which occurred only with -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

But that's not how the middle end works. It expects that in a single 
file (translation unit), no multiple declarations for the same object exist.

We do not want to change the middle end. Besides, having a single decl 
per object allows for inlining and similar optimization. There is simply 
no reason for -fno-whole-file except that gfortran until 4.5 had it by 
default.

In principle, we could have done the switch without adding 
-f(no-)whole-file; having the flag was only useful because: (i) It 
allowed Paul to sensible put the patch into the trunk even though it was 
not yet completely working. (ii) It allowed to find out that PR44945 was 
only failing with -fno-whole-file. (iii) Mainly in 2010-07, it made it 
easier to find regressions in -fwhole-file. After 2010-07, most issues 
were solved, rendering -f(no-)whole-file less useful.

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

No but with the addition of -fwhole-file. Without, inlining was 
essentially not possible.

> AFAICT most of the speeddup is achieved with -fwhole-program.

But that only works with a single file/TU, unless you use LTO. 
Additionally, -flto and -fwhole-program both enable -fwhole-file. Due to 
the multiple declarations issue, -fno-whole-file -fwhole-program would 
optimize many procedures away, which were actually used - leading to 
linking errors.

> OK, but no time table has been released so far.

In terms of the bugs, I was even considering to remove it for 4.6. I 
think by 2010-08 we had fixed nearly all -fwhole-file specific bugs - 
and no one wanted to go back to -fno-whole-file.

> 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 

As said above: I will actively ignore subpointer bugs! Actually, before 
I thought that -fno-whole-file worked for that file, but as the linker 
error indicates, -fno-whole-file also doesn't work!

Tobias