On 14/10/2010 17:12, Dave Korn wrote:
On 14/10/2010 16:24, Richard Guenther wrote:
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn dave.korn.cyg...@gmail.com
wrote:
I *think* that re-adding the stdlibs after all
the new input files in the plugin might work, but haven't tried it yet.
It does
On 14/10/2010 19:11, Ian Lance Taylor wrote:
Dave Korn writes:
The consequence of this is that either there are going to be undefined
symbols in the final executable, or the linker has to perform another round
of
library scanning. It occurred to me that the semantics of this might even
Hello list,
When I compile this source with -flto:
extern int retval;
int func (void)
{
return retval;
}
... the LTO symbol table contains both symbols:
/gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
Contents of section .gnu.lto_.symtab.227b80e3:
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
Hello list,
When I compile this source with -flto:
extern int retval;
int func (void)
{
return retval;
}
... the LTO symbol table contains both symbols:
/gnu/binutils/git.repo/obj/ld/test/func.o:
On 14/10/2010 15:44, Richard Guenther wrote:
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
Nor indeed is there any sign of puts, which is what the generated ltrans0.s
file ends up optimising it to (as indeed does the native code in the original
.o file). I'm
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 14/10/2010 15:44, Richard Guenther wrote:
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn dave.korn.cyg...@gmail.com
wrote:
Nor indeed is there any sign of puts, which is what the generated ltrans0.s
file ends up
On 14/10/2010 16:24, Richard Guenther wrote:
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
On 14/10/2010 15:44, Richard Guenther wrote:
I have no idea about the linker-plugin side, but we could of course
avoid generating any calls that were not there before (by
Dave Korn dave.korn.cyg...@gmail.com writes:
The consequence of this is that either there are going to be undefined
symbols in the final executable, or the linker has to perform another round of
library scanning. It occurred to me that the semantics of this might even not
have been decided
