This is the mail archive of the
mailing list for the GCC project.
RE: externally_visible and resoultion file
> -----Original Message-----
> From: Cary Coutant [mailto:firstname.lastname@example.org]
> Sent: 09 June 2010 18:43
> To: Richard Guenther
> Cc: Bingfeng Mei; Jan Hubicka; email@example.com
> Subject: Re: externally_visible and resoultion file
> >> Yes, this is also what I saw without plugin. I just wonder why
> >> is linked with plugin if resolution file is not used to eliminate
> >> of externally_visible attribute here.
> > Probably because of the same linker-plugin bug that causes bar
> > to be resolved.
> Just to make sure I understand the problem:
> - The IR file for a.c contains definitions for vvvvv and bar.
> - The linker identifies that both symbols are referenced from outside
> the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but
> gcc isn't (yet) reading that info from the resolution file.
> - WPA eliminates bar() and makes vvvvv static in the replacement object
> - There are still references to those symbols in b.o, which was
> compiled outside LTO.
> - The linker should be complaining about undefined symbols in both
> cases, but isn't (perhaps because it's still seeing defs left over
> from the IR files). The symbol bar has a value of 0, while the
> reference to vvvvv seems to have the right address.
> Is that about right? What you're expecting is a link-time error
> reporting both bar and vvvvv as undefined, right?
Yes, I expect link-time errors of undefined reference for both
bar and vvvvvv. Instead, bar is linked to a bogus one (address 0)
and vvvvvv is linked correctly.