Re: [PATCH] PR ld/16746: Don't issue a warning for reference in LTO IR

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Mar 25, 2014 at 3:39 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Mar 25, 2014 at 01:39:52PM -0700, H.J. Lu wrote:
>>       case WARNC:
>> -       /* Issue a warning and cycle.  */
>> -       if (h->u.i.warning != NULL)
>> +       /* Issue a warning and cycle.  Don't issue a warning for
>> +          reference in LTO IR which may be removed by LTO later. */
>> +       if (h->u.i.warning != NULL
>> +           && (abfd->flags & BFD_PLUGIN) == 0)
>
> So here you're handling references in LTO IR for warning symbols
> defined in real object files or other LTO IR files..

Yes.

>>       case WARN:
>> +       /* Don't issue a warning for reference in LTO IR which may be
>> +          removed by LTO later.  Make a warning symbol instead.  */
>> +       if ((hash_entry_bfd (h)->flags & BFD_PLUGIN) != 0)
>> +         goto mwarn;
>> +
>
> And here you have the case where the new symbol is a warning symbol,
> in either LTO IR or real object files, but the reference was in an LTO
> IR file.

Yes.

> What about the CWARN case, where you already have a definition that
> may have been referenced, and the new symbol is a warning symbol?
> You'll need to test h->non_ir_ref I think.

It is:

https://sourceware.org/bugzilla/show_bug.cgi?id=12760

We are getting:

[hjl@gnu-6 pr12760]$ cat pr12760a.c
extern void bar ();

void
foo ()
{
  bar ();
}
[hjl@gnu-6 pr12760]$ cat pr12760b.c
#define linker_warning(x, msg) \
static const char __warn_##x[] \
__attribute__((used, section(".gnu.warning." #x))) \
= msg

void bar (void) {}
linker_warning(bar, "Bad bar");
[hjl@gnu-6 pr12760]$ make
gcc -B./    -c -o pr12760a.o pr12760a.c
gcc -B./ -flto -O2 -ffat-lto-objects   -c -o pr12760b.o pr12760b.c
ar rcs libpr12760.a pr12760b.o
gcc -B./ -O2 -Wl,-e,foo -nostdlib -flto -fuse-linker-plugin -o foo
pr12760a.o -Wl,--start-group libpr12760.a -Wl,--end-group
pr12760b.o (symbol from plugin): warning: Bad bar
[hjl@gnu-6 pr12760]$

It is similar to:

https://sourceware.org/bugzilla/show_bug.cgi?id=16756

Since we don't keep the undefined reference when seeing
a definition, we lose the reference info.  We can't get the
correct warning message.

-- 
H.J.