* Does `-fwhole-program' make sense when compiling shared libraries?
@ 2010-05-17 17:49 Dave Korn
2010-05-17 17:57 ` Toon Moene
0 siblings, 1 reply; 6+ messages in thread
From: Dave Korn @ 2010-05-17 17:49 UTC (permalink / raw)
To: gcc
Hi!
PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
the compiler optimises away the entire library body, because there's no
dependency chain related to 'main' to anchor it.
It's pointed out that we could perhaps resolve this by inferring attribute
externally_visible anywhere we see dllexport is applied, but I wondered
whether Linux (or any other target) does anything like this (perhaps based on
default visibility or explicit attributes?), or if you are just expected to
annotate all your externally-visible functions if you want to be able to
meaningfully combine -fwhole-program with -shared compilation?
cheers,
DaveK
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Does `-fwhole-program' make sense when compiling shared libraries?
2010-05-17 17:49 Does `-fwhole-program' make sense when compiling shared libraries? Dave Korn
@ 2010-05-17 17:57 ` Toon Moene
2010-05-17 18:24 ` Joe Buck
[not found] ` <4BF18A6B.5030603@gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: Toon Moene @ 2010-05-17 17:57 UTC (permalink / raw)
To: Dave Korn; +Cc: gcc
On 05/17/2010 08:08 PM, Dave Korn wrote:
>
> Hi!
>
> PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
> the compiler optimises away the entire library body, because there's no
> dependency chain related to 'main' to anchor it.
Aren't "shared library" and "whole program" mutually exclusive concepts ?
The mere fact that you are building a library means that it cannot be
the whole program, and because a shared library cannot be determined to
have being used by any fixed program, by definition cannot be "the whole
program".
Or so I'd think.
Kind regards,
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Does `-fwhole-program' make sense when compiling shared libraries?
2010-05-17 17:57 ` Toon Moene
@ 2010-05-17 18:24 ` Joe Buck
2010-05-17 21:33 ` Jan Hubicka
[not found] ` <4BF18A6B.5030603@gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: Joe Buck @ 2010-05-17 18:24 UTC (permalink / raw)
To: Toon Moene; +Cc: Dave Korn, gcc
On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> On 05/17/2010 08:08 PM, Dave Korn wrote:
> >
> > Hi!
> >
> > PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
> > the compiler optimises away the entire library body, because there's no
> > dependency chain related to 'main' to anchor it.
Not a bug, but perhaps the beginning of a reasonable enhancement project.
> Aren't "shared library" and "whole program" mutually exclusive concepts ?
>
> The mere fact that you are building a library means that it cannot be
> the whole program, and because a shared library cannot be determined to
> have being used by any fixed program, by definition cannot be "the whole
> program".
>
> Or so I'd think.
The concept would need to be extended so that the compiler would be told
exactly what interfaces of the shared library are considered free, and
which are considered internal calls. Then a -fwhole-library could make
sense.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Does `-fwhole-program' make sense when compiling shared libraries?
2010-05-17 18:24 ` Joe Buck
@ 2010-05-17 21:33 ` Jan Hubicka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Hubicka @ 2010-05-17 21:33 UTC (permalink / raw)
To: Joe Buck; +Cc: Toon Moene, Dave Korn, gcc
> On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> > On 05/17/2010 08:08 PM, Dave Korn wrote:
> > >
> > > Hi!
> > >
> > > PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
> > > the compiler optimises away the entire library body, because there's no
> > > dependency chain related to 'main' to anchor it.
>
> Not a bug, but perhaps the beginning of a reasonable enhancement project.
This is what __attribute__ ((externally_visible)) is intended for. If you want to build
shared library with whole program, you need to explicitely mark all the entry points.
Alternatively with LTO we might take the existing hidden linkage hints for same effect,
but this is not implemented (yet).
Honza
>
> > Aren't "shared library" and "whole program" mutually exclusive concepts ?
> >
> > The mere fact that you are building a library means that it cannot be
> > the whole program, and because a shared library cannot be determined to
> > have being used by any fixed program, by definition cannot be "the whole
> > program".
> >
> > Or so I'd think.
>
> The concept would need to be extended so that the compiler would be told
> exactly what interfaces of the shared library are considered free, and
> which are considered internal calls. Then a -fwhole-library could make
> sense.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Does `-fwhole-program' make sense when compiling shared libraries?
[not found] ` <4BF18A6B.5030603@gmail.com>
@ 2010-05-18 13:58 ` Dave Korn
2010-05-18 14:13 ` Jan Hubicka
0 siblings, 1 reply; 6+ messages in thread
From: Dave Korn @ 2010-05-18 13:58 UTC (permalink / raw)
To: gcc
[ hmf. This one got lost to an smtp error when I sent it yesterday. It
appears there's more or less agreement that at the moment you're supposed to
manually annotate all external entry points if you want to use -fwhole-program
on a library. On windows, where we often do that anyway, it looks like it
would make a great deal of sense to infer externally_visible from dllexport. ]
On 17/05/2010 19:26, Dave Korn wrote:
> On 17/05/2010 18:57, Toon Moene wrote:
>> On 05/17/2010 08:08 PM, Dave Korn wrote:
>>> Hi!
>>>
>>> PR42904 is a bug where, when compiling a windows DLL using
>>> -fwhole-program,
>>> the compiler optimises away the entire library body, because there's no
>>> dependency chain related to 'main' to anchor it.
>> Aren't "shared library" and "whole program" mutually exclusive concepts ?
>>
>> The mere fact that you are building a library means that it cannot be
>> the whole program, and because a shared library cannot be determined to
>> have being used by any fixed program, by definition cannot be "the whole
>> program".
>>
>> Or so I'd think.
>
> Well, indeed that is strictly the case, but a shared library is also a
> self-contained bundle of dependencies, and if all the externally visible
> functions were treated as roots like 'main', I would have thought
> -fwhole-program could usefully do its thing. So I wondered if anyone had
> thought about making it work. (I guess the PR should be treated as an
> enhancement request.)
>
> cheers,
> DaveK
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Does `-fwhole-program' make sense when compiling shared libraries?
2010-05-18 13:58 ` Dave Korn
@ 2010-05-18 14:13 ` Jan Hubicka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Hubicka @ 2010-05-18 14:13 UTC (permalink / raw)
To: Dave Korn; +Cc: gcc
> [ hmf. This one got lost to an smtp error when I sent it yesterday. It
> appears there's more or less agreement that at the moment you're supposed to
> manually annotate all external entry points if you want to use -fwhole-program
> on a library. On windows, where we often do that anyway, it looks like it
> would make a great deal of sense to infer externally_visible from dllexport. ]
dllexport is attribute and I think you can quite easilly make frontend hook to
drop externally_visible attribute while handling it. This would indeed make
sense.
Honza
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-18 14:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-17 17:49 Does `-fwhole-program' make sense when compiling shared libraries? Dave Korn
2010-05-17 17:57 ` Toon Moene
2010-05-17 18:24 ` Joe Buck
2010-05-17 21:33 ` Jan Hubicka
[not found] ` <4BF18A6B.5030603@gmail.com>
2010-05-18 13:58 ` Dave Korn
2010-05-18 14:13 ` Jan Hubicka
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).