Re: Bug in lto-plugin.c ?
On Wed, Jul 19, 2017 at 5:43 PM, Georg-Johann Lay wrote:
> On 19.07.2017 12:46, Richard Biener wrote:
>>
>> On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay 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 & 0x;
>>>hi = ((int64_t)file->offset >> 32) & 0x;
>>>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.
>
>
> hm, as I still have no idea how to debug, played around by changing
> lto-plugin.c. I managed to get the host on virtual box so that it's
> less of a pain trying around...
>
> My guess is that asprintf on that host is broken. config.log says
> that asprintf prototypes are available and host stdio.h shows them.
>
> When I am replacing asprintf with allocation by hand like so:
>
> #if 0
> t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
> : asprintf (&objname, "%s@0x%x", file->name, lo);
> #else
> objname = xmalloc (30 + strlen (file->name));
> if (objname)
> {
> if (hi)
> sprintf (objname, "%s@0x%x%08x", file->name, hi, lo);
> else
> sprintf (objname, "%s@0x%x", file->name, lo);
> t = 1;
> }
> else
> t = -2;
> #endif
>
> then it works fine. I also hooked into xmalloc to find other
> questionable allocations, but all calls of xmalloc look sane.
>
> For the case in question, 84 bytes are requested and with
> xmalloc + sprintf it works fine, so the host-asprintf is broken
> somehow.
>
> I also tried to remove the asprintf from host-stdio.h and hoped that
> after re-configure libiberty would jump in... but no. Also I'd expected
> that auto-host.h should be included before libiberty.h?
It should be included via system.h which lto-plugin.c doesn't include.
Does including that after config.h work? (not sure why we check
for HAVE_CONFIG_H there...). Most if not all system header includes
should go away then as well.
> Would a change like above be in order? (without the #if 0 of course)
> It's tad that a host's function is broken, but in that case the length
> is easy to compute.
>
> Any why is all this stuff executed anyway? It's a non-LTO compilation
> with -O0, hence it's a bit surprising that ld needs to look into
> libgcc.a.
With the linker plugin we invoke the plugin for all compilations since we no
longer require explicit -flto at link time. So we have to see whether any
input contains LTO sections.
Richard.
>
> Johann
Re: How to configure a bi-arch PowerPC GCC?
On 30/01/17 11:38, Sebastian Huber wrote:
On 25/01/17 18:55, Segher Boessenkool wrote:
On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote:
>I still get a lot of ICEs with the attached two patches (examples):
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function
>'__multc3':
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error:
>unrecognizable insn:
> }
> ^
>(insn 59 58 60 2 (set (reg:CCFP 219)
> (compare:CCFP (reg/v:TF 193 [ x ])
> (reg/v:TF 193 [ x ])))
>"/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1
> (nil))
>/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal
>compiler error: in extract_insn, at recog.c:2311
The IEEE128 code almost certainly has some bugs on non-Linux
configurations.
You could try debugging it, or you could avoid it (for now) by e.g.
making
long double the same as double.
If I set rs6000_long_double_type_size to 64, then I can build all
libgcc multilibs including the one for -m64 -mcpu=e6500. I am a bit
surprised that the GCC support for 64-bit PowerPC is so extremely
Linux-dependent. I guess that I have to figure out all the magic
configuration bits to get everything set up like it is on Linux. It
would be nice if the working Linux configuration bits are the default.
With rs6000_long_double_type_size == 128, then I get the attached ICEs.
I would be glad to get some advice how I can debug them, since I have
no idea how the compiler works actually if it comes to code generation.
I gave it a new try after the SPE split up. I still have problems to
build a bi-arch PowerPC compiler for RTEMS. I get an ICE with this test
case:
typedef float TFtype __attribute__ ((mode (TF)));
void
f (TFtype b)
{
if (b - b) {
__asm__ volatile ("");
}
}
xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -mcpu=e6500
-m64 -O2 -fpreprocessed -S test-v0.i -o /dev/null 2>&1
test-v0.i: In function 'f':
test-v0.i:8:1: error: unrecognizable insn:
}
^
(insn 12 11 13 2 (set (reg:CCFP 126)
(compare:CCFP (reg:TF 123)
(reg:TF 124))) "test-v0.i":5 -1
(nil))
during RTL pass: vregs
test-v0.i:8:1: internal compiler error: in extract_insn, at recog.c:2311
0x40a233 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:108
0x40a252 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/archive/gcc-git/gcc/rtl-error.c:116
0x965abf extract_insn(rtx_insn*)
/home/EB/sebastian_h/archive/gcc-git/gcc/recog.c:2311
0x71dd73 instantiate_virtual_regs_in_insn
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1589
0x71dd73 instantiate_virtual_regs
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:1957
0x71dd73 execute
/home/EB/sebastian_h/archive/gcc-git/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
I built a native GCC on gcc112. It produces:
./install-gcc-git/bin/gcc -S -O2 -mcpu=e6500 -m64 -o - test.c
.file "test.c"
.abiversion 2
.globl __gcc_qsub
.section".text"
.align 2
.p2align 4,,15
.globl f
.type f, @function
f:
.LCF0:
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry f,.-f
fmr 4,2
mflr 0
fmr 3,1
std 0,16(1)
stdu 1,-32(1)
bl __gcc_qsub
nop
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lfd 12,0(9)
lfd 13,8(9)
fcmpu 7,1,12
bne 7,$+8
fcmpu 7,2,13
beq- 7,.L1
.L1:
addi 1,1,32
ld 0,16(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,0,0,0
.size f,.-f
.section.rodata.cst16,"aM",@progbits,16
.align 4
.LC0:
.long 0
.long 0
.long 0
.long 0
.ident "GCC: (GNU) 8.0.0 20170720 (experimental) [master
revision f37822f:0bf6d30:61658d61fdbd0e76bb1b7ea20c3bb8dc334568cd]"
.gnu_attribute 4, 5
.section.note.GNU-stack,"",@progbits
So, I looked for " __gcc_qsub" in the GCC sources. It seems this is
generated by rs6000_init_libfuncs() for some "sub_optab" stuff. If I run
my bi-arch GCC in GDB, then I get:
Breakpoint 1, rs6000_init_libfuncs () at
/home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:18670
18670 if (TARGET_FLOAT128_TYPE)
(gdb) n
18677 if (TARGET_LONG_DOUBLE_128)
(gdb)
18684 init_float128_ieee (TFmode);
(gdb) s
init_float128_ieee (mode=TFmode) at
/home/EB/se
gcc-7-20170720 is now available
Snapshot gcc-7-20170720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170720/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 250404 You'll find: gcc-7-20170720.tar.xzComplete GCC SHA256=75e4cdef948e53028b106e07d31b01d7996fd65f040b81f31695afbcebd69854 SHA1=f4c761e2cbdfbbf63038cd8b910992d98b17d997 Diffs from 7-20170713 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Add support to trace comparison instructions and switch statements
Hi Jeff I have signed the copyright assignment, and used the name 'Wish Wu' . Should I send you a copy of my assignment ? The attachment is my new patch with small changes. Codes are checked by ./contrib/check_GNU_style.sh, except some special files. With -- From:Jeff Law Time:2017 Jul 14 (Fri) 15:37 To:Wish Wu ; gcc ; gcc-patches Cc:wishwu007 Subject:Re: Add support to trace comparison instructions and switch statements On 07/10/2017 06:07 AM, 吴潍浠(此彼) wrote: > Hi > > I write some codes to make gcc support comparison-guided fuzzing. > It is very like > http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow . > With -fsanitize-coverage=trace-cmp the compiler will insert extra > instrumentation around comparison instructions and switch statements. > I think it is useful for fuzzing. :D > > Patch is below, I may supply test cases later. Before anyone can really look at this code you'll need to get a copyright assignment on file with the FSF. See: https://gcc.gnu.org/contribute.html If you've already done this, please let me know and I'll confirm with the FSF copyright clerk. Jeff gcc-svn-201707171129.patch Description: Binary data
