https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
--- Comment #8 from dave.anglin at bell dot net --- On 2019-08-23 7:20 a.m., marxin at gcc dot gnu.org wrote: > Which GCC version are you testing? Do you have following trunk commit: I am testing trunk. The error in Comment #1 was for r274539. > > Fix off-by-one in simple-object-elf.c (PR lto/91228). > > 2019-07-24 Martin Liska <mli...@suse.cz> > > PR lto/91228 > * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): > Find first '\0' starting from gnu_lto + 1. > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273757 > 138bc75d-0d04-0410-961f-82ee72b054a4 The symbols shown by nm in Comment #5 compared r273661 and r273662. Thus, the symbols for r273662 are affected by the off-by-one bug. In order to do regression search, I also had to apply this patch: Index: lto-wrapper.c =================================================================== --- lto-wrapper.c (revision 274037) +++ lto-wrapper.c (working copy) @@ -1112,7 +1112,7 @@ /* Number of CPUs that can be used for parallel LTRANS phase. */ -static unsigned long nthreads_var = 0; +static unsigned long nthreads_var = 1; #ifdef HAVE_PTHREAD_AFFINITY_NP unsigned long cpuset_size; This is because make objects to "-j0". 64-Bit HP ld issues errors or warnings about unstats depending on +[no]allowunsats option. It doesn't help to allow unstats as the dynamic linker will object to unstats in an executable when it is run. So, the symbols that used to turn into gnu_lto_v1 need to turn into a common or defined weak symbol on this target.
