> -----Original Message----- > From: Cary Coutant [mailto:ccout...@google.com] > Sent: 09 June 2010 18:43 > To: Richard Guenther > Cc: Bingfeng Mei; Jan Hubicka; gcc@gcc.gnu.org > Subject: Re: externally_visible and resoultion file > > >> Yes, this is also what I saw without plugin. I just wonder why > "vvvvv" > >> is linked with plugin if resolution file is not used to eliminate > need > >> 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 > file. > - 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? > > -cary 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.
