On 21.07.2017 13:41, Richard Biener wrote:
On Thu, Jul 20, 2017 at 3:18 PM, Georg-Johann Lay <a...@gjlay.de> wrote:
Hi, this patch fixes some minor problems in lto-plugin:
Some older mingw32 host environments have broken asprintf.
As far as I can tell, the problem is that the mingw asprintf
implementation calls _vsnprintf (NULL, 0, ...) which always
returns -1 as length on the host.
The patch fixes this by using xasprintf from libiberty with
the additional benefit of easier use and unified error reporting
in the case when there is actually no more memory available, i.e.
it will use the same error massages like xmalloc then.
Moreover, the old implementation calls asprintf as
asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
for large archives when the high 32 bits (hi) are non-zero.
This looks like a typo: the high part must come first to yiels
a proper 64-bit value.
Bootstrapped & re-tested on x86_64-linux gnu and also on
mingw32 which popped the "ld.exe: asprintf failed".
Ok for trunk?
Ok.
I wonder if any of the other plain asprintf calls in GCC are
problematic. From a quick look they are all inside code
only exercised when dumping/debugging. But maybe we
should replace those as well.
Richard.
Maybe I just didn't run into such spots yet. I just started using
a different cross-toolchain for canadian cross builds. With my old
i386-mingw32 (3.4.5) I never saw such problems, but the new v8
(maybe also v7) no more gave sane build result, i.e. the generated
cross-compiler to run under mingw just hangs. Must be somewhere
around tree dump no. 62, but I couldn't even find out which pass
actually hangs. So I used 4.9.3 x64 -> mingw cross compiler in
the hope that it works better than good old 3.4.5 which did a very
good job for a really long time.
Johann
lto-plugin/
PR lto/81487
* lto-plugin.c (claim_file_handler): Use xasprintf instead of
asprintf.
[hi!=0]: Swap hi and lo arguments supplied to xasprintf.
