Re: fwhole-program issue

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Jul 4, 2012 at 9:52 AM, Manfred Schwarb <manfred99@gmx.ch> wrote:
> Am 04.07.2012 07:55, schrieb Tobias Burnus:
>
>> Hi,
>>
>> Manfred Schwarb wrote:
>>>
>>> I'm somewhat puzzled: for me the dead simple program
>>> # cat wholeprogram1.f
>>>       subroutine wholeprogram1
>>>       print*,"wholeprogram1"
>>>       end
>>> # cat wholeprogram2.f
>>>       program wholeprogram2
>>>       call wholeprogram1
>>>       end
>>> does not compile with -fwhole-program
>>
>>
>> That's not surprising:
>>     gfortran -fwhole-program -c wholeprogram1.f
>> can optimize "wholeprogram1" away as it is not called in that file.
>>
>
> Well, it is compiled without optimization here, and the issue appeared for
> me
> in a much larger program where such optimization is definitely not the case.
>
>
>
>> Recall that -fwhole-program work per translation/compilation unit (TU,
>> i.e. per file), which is also indicated in the manual:
>>
>> "-fwhole-program
>>             Assume that the current compilation unit represents the whole
>> program being compiled. [...]"
>>
>
> I have read this differently, namely "per compiler invocation", thanks for
> explanation.
> I thought it is actually the intention to do some overall optimization.
> If this works only on a per-file base, this option seems to be somewhat
> worthless.
> Sad.

True.  That's what we invented LTO for ;)

>> Thus, -fwhole-program should either only be used if one has only a single
>> file (or for the file which contains only the main program). Or together
>> with link-time optimization (LTO), enabled by "-flto".
>>
>> Thus, you should add "-flto".
>
>
> Thanks, this seems to be the way to go, although it increases compilation
> time.
> My intention was to get more accurate warnings during development, so
> compilation
> time is important, too.
> And AFAIK lto does not warn about unused functions, it simply strips them
> away.

Yes, nobody has bothered to add this kind of static analysis diagnostics
to the LTO code yet.

Richard.

> Thanks!
> Manfred
>
>>
>> Tobias
>>
>
>