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