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. > 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.