From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86185 invoked by alias); 1 Sep 2015 08:01:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 86172 invoked by uid 89); 1 Sep 2015 08:01:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_50,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 01 Sep 2015 08:01:03 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 02D06AB9D; Tue, 1 Sep 2015 08:01:00 +0000 (UTC) Date: Tue, 01 Sep 2015 08:01:00 -0000 From: Richard Biener To: Markus Trippelsdorf cc: gcc-patches@gcc.gnu.org, Jan Hubicka , ccoutant@gmail.com, hjl.tools@gmail.com Subject: Re: [PATCH] Updated LTO early debug patch In-Reply-To: <20150831161713.GB1940@x4> Message-ID: References: <20150831161713.GB1940@x4> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1609908220-504696650-1441094459=:5523" X-SW-Source: 2015-09/txt/msg00005.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-504696650-1441094459=:5523 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-length: 8354 On Mon, 31 Aug 2015, Markus Trippelsdorf wrote: > On 2015.08.31 at 16:44 +0200, Richard Biener wrote: > > > > So the state below now will pass LTO bootstrap (fingers crossing, > > stage3 running) as well as regular bootstrap. Iff I didn't break > > sth in the last minute. You need up-to-date trunk (watch out, > > fortran seems to be broken) to pull the fixes for trunk LTO bootstrap. > > Gold doesn't work at all (internal error in read_script_file, at script.cc:1608). > > Even simple programs don't link anymore: > > trippels@gcc2-power8 ~ % echo "int main () {}" | g++ -x c++ - -flto > /home/trippels/bin/ld: /home/trippels/tmp/ccPhF9Ar.o: plugin needed to handle lto object > /home/trippels/bin/ld: /home/trippels/tmp/ccjOv4bXdebugobj: plugin needed to handle lto object Ah, I didn't notice that because I failed to pass -fuse-ld=gold to the linker command doing the incremental debug link (and my default linker is GNU ld). With that fixed I can reproduce the error. The gold ICE is new though, no idea what triggers it this time :/ Maybe it doesn't like INPUT()s in the script. Ok - when feeding the inputs as regular arguments it "works" up to the point that re-invokes the plugin recursively on the objects (despite -fno-use-linker-plugin...), eventually failing with a too long command-line: 17625 execve("./collect2", ["./collect2", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-fuse-ld=gold", "-o", "/tmp/cctrgtNXdebugobj", "-r", "-L.", "-L/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", "-L/lib/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64/../lib64", .... , "-L/lib/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64", "-L/lib/../lib64/../lib64", ...], [/* 96 vars */] The original gold invocation is: 17546 execve("./xgcc", ["./xgcc", "-B", ".", "-fuse-ld=gold", "-fno-use-linker-plugin", "-o", "/tmp/ccAB4HkPdebugobj", "-r", "-nostdlib", "-Wl,--debug=script", "-Wl,--whole-archive", "-Wl,-T", "/tmp/ccCUUlgyscript", "/tmp/ccqOITb3.o", "/tmp/cc2UtXYj.o"], [/* 96 vars */] ... 17548 execve("/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../bin/ld.gold", ["/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../bin/ld.gold", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-fuse-ld=gold", "-o", "/tmp/ccAB4HkPdebugobj", "-r", "-L.", "-L/lib/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", "-L.", "-L/lib/../lib64", "-L/usr/lib/../lib64", "--debug=script", "--whole-archive", "-T", "/tmp/ccCUUlgyscript", "/tmp/ccqOITb3.o", "/tmp/cc2UtXYj.o"], [/* 96 vars */]) = 0 so not sure how it figures to use (and which?) LTO plugin. Possibly by auto-loading? I can't find a '-no-plugin' option or sth similar. Oh, and with GNU ld the behavior is the same, so using actual arguments to the link seems to be a no-go unless that can be fixed somehow. Hmm, and somehow collect-ld doesn't handle -fuse-ld=... in response files: [pid 19703] execve("./xgcc", ["./xgcc", "@/tmp/cclYNnH0"], [/* 96 vars */] ... [pid 19704] execve("./collect2", ["./collect2", "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-fuse-ld=gold", "-o", "/tmp/ccvlTEtRdebugobj", "-r", "-L.", "-L/lib/../lib64/../lib64", "-L/usr/lib/../lib64/../lib64", "-L/lib/../lib64", "-L/usr/lib/../lib64", "-L/lib/../lib64", ...], [/* 96 vars */] ... [pid 19705] execve("./collect-ld", ["./collect-ld", "@/tmp/ccjliwz5"], [/* 96 vars */] ... [pid 19705] execve("/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld", ["/usr/lib64/gcc/x86_64-suse-linux"..., "@/tmp/ccjliwz5"], [/* 96 vars */]) = 0 that's when passing true to fork_execute. So I don't have a workaround for GOLD and early LTO debug (apart from eventually forcing a -fuse-ld=bfd for the incremental link). As said, the final version will require support from the linkers but it seems https://sourceware.org/bugzilla/show_bug.cgi?id=18837 is stalled. > And it breaks quickly during Firefox build, e.g.: > > trippels@gcc2-power8 angle % cat glslang_lex.ii > struct A; > template class B { > typedef A value_type; > void m_fn1(const value_type &); > }; > struct A { > int staticUse; > B<> fields; > }; > > trippels@gcc2-power8 angle % g++ -g -c glslang_lex.ii > glslang_lex.ii: In instantiation of ‘class B<>’: > glslang_lex.ii:8:5: required from here > glslang_lex.ii:2:33: error: TYPE_CANONICAL is not compatible Hum, but that looks more like an issue for Honzas type verifier (which already has quite a few bugs ...). dwarf2out certainly doesn't modify types. Anyway, thanks for trying ;) Richard. > template class B { > ^ > align 8 symtab 0 alias set -1 canonical type 0x3fffa9d4cb70 context > full-name "const struct A" > n_parents=0 use_template=0 interface-unknown reference_to_this > > align 8 symtab -1446640944 alias set -1 canonical type 0x3fffa9d4cb70 > fields type size > unit size > align 32 symtab 0 alias set -1 canonical type 0x3fffa9b90690 precision 32 min max > pointer_to_this > > decl_3 VOID file glslang_lex.ii line 7 col 7 > align 1 offset_align 1 context > chain > nonlocal decl_4 VOID file glslang_lex.ii line 6 col 10 > align 1 context result > >> context > full-name "const value_type" > n_parents=0 use_template=0 interface-unknown reference_to_this > > glslang_lex.ii:2:33: internal compiler error: verify_type failed > 0x10d74f97 verify_type(tree_node const*) > ../../gcc/gcc/tree.c:13583 > 0x10633373 gen_type_die_with_usage > ../../gcc/gcc/dwarf2out.c:20824 > 0x10633c17 gen_type_die_with_usage > ../../gcc/gcc/dwarf2out.c:20922 > 0x10635347 gen_type_die > ../../gcc/gcc/dwarf2out.c:21018 > 0x10635a43 gen_formal_types_die > ../../gcc/gcc/dwarf2out.c:18564 > 0x10636843 gen_subprogram_die > ../../gcc/gcc/dwarf2out.c:19341 > 0x10638067 gen_decl_die > ../../gcc/gcc/dwarf2out.c:21668 > 0x1064fdd7 gen_member_die > ../../gcc/gcc/dwarf2out.c:20516 > 0x1064fdd7 gen_struct_or_union_type_die > ../../gcc/gcc/dwarf2out.c:20600 > 0x1064fdd7 gen_tagged_type_die > ../../gcc/gcc/dwarf2out.c:20801 > 0x10633caf gen_type_die_with_usage > ../../gcc/gcc/dwarf2out.c:20963 > 0x10635347 gen_type_die > ../../gcc/gcc/dwarf2out.c:21018 > 0x10638443 gen_decl_die > ../../gcc/gcc/dwarf2out.c:21691 > 0x106392ef dwarf2out_decl > ../../gcc/gcc/dwarf2out.c:22161 > 0x10652bb7 dwarf2out_type_decl > ../../gcc/gcc/dwarf2out.c:21871 > 0x1093143f rest_of_type_compilation(tree_node*, int) > ../../gcc/gcc/passes.c:347 > 0x1028284b finish_struct_1(tree_node*) > ../../gcc/gcc/cp/class.c:6747 > 0x1023f92f instantiate_class_template_1 > ../../gcc/gcc/cp/pt.c:10189 > 0x1023f92f instantiate_class_template(tree_node*) > ../../gcc/gcc/cp/pt.c:10229 > 0x10316453 complete_type(tree_node*) > ../../gcc/gcc/cp/typeck.c:138 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See for instructions. ---1609908220-504696650-1441094459=:5523--