Bug in lto-plugin.c ?

[Richard Biener]

On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
> Hi, I tried to build a canadian cross with Configured with
> --build=x86_64-linux-gnu
> --host=i686-w64-mingw32
> --target=avr
>
> While the result appears to work under wine, I am getting the
> following error from ld in a non-LTO compile + link:
>
> e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../../avr/bin/ld.exe:
> error: asprintf failed
>
> After playing around I found that -fno-use-linker-plugin avoids that
> message, and I speculated that the error is emit by lto-plugin.c
>
> In claim_file_handler() we have:
>
>
>       /* We pass the offset of the actual file, not the archive header.
>          Can't use PRIx64, because that's C99, so we have to print the
>          64-bit hex int as two 32-bit ones. */
>       int lo, hi, t;
>       lo = file->offset & 0xffffffff;
>       hi = ((int64_t)file->offset >> 32) & 0xffffffff;
>       t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
>              : asprintf (&objname, "%s@0x%x", file->name, lo);
>       check (t >= 0, LDPL_FATAL, "asprintf failed");
>
>
> If hi != 0, then why is hi printed at the low end? Shouldn't hi and lo
> be swapped like so
>
>       t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, hi, lo)
>
> if this is supposed to yield a 64-bit print?

Looks odd indeed...  I suppose such large archives are the exception ;)

>
> What else could lead to an "asprintf failed" ?  Unfortunately I have
> no idea how to debug that on the host...

memory allocation failure I guess.

Richard.

> Johann
>