From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] Updated LTO early debug patch
Date: Mon, 31 Aug 2015 17:39:00 -0000 [thread overview]
Message-ID: <20150831161713.GB1940@x4> (raw)
In-Reply-To: <alpine.LSU.2.11.1508311642360.5523@zhemvz.fhfr.qr>
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
And it breaks quickly during Firefox build, e.g.:
trippels@gcc2-power8 angle % cat glslang_lex.ii
struct A;
template <typename = int> 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
template <typename = int> class B {
^
<record_type 0x3fffa9d4cb70 A readonly type_5 VOID
align 8 symtab 0 alias set -1 canonical type 0x3fffa9d4cb70 context <translation_unit_decl 0x3fffb2770078 D.1>
full-name "const struct A"
n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fffa9d4ccc0>>
<record_type 0x3fffa9d4d3f8 value_type readonly used type_5 VOID
align 8 symtab -1446640944 alias set -1 canonical type 0x3fffa9d4cb70
fields <field_decl 0x3fffa9c44c00 staticUse
type <integer_type 0x3fffa9b90690 int public type_6 SI
size <integer_cst 0x3fffa9b416b0 constant 32>
unit size <integer_cst 0x3fffa9b416c8 constant 4>
align 32 symtab 0 alias set -1 canonical type 0x3fffa9b90690 precision 32 min <integer_cst 0x3fffa9b41668 -2147483648> max <integer_cst 0x3fffa9b41680 2147483647>
pointer_to_this <pointer_type 0x3fffa9b917a0>>
decl_3 VOID file glslang_lex.ii line 7 col 7
align 1 offset_align 1 context <record_type 0x3fffa9d4c780 A>
chain <type_decl 0x3fffa9c44b68 A type <record_type 0x3fffa9d4d158 A>
nonlocal decl_4 VOID file glslang_lex.ii line 6 col 10
align 1 context <record_type 0x3fffa9d4c780 A> result <record_type 0x3fffa9d4c780 A>
>> context <translation_unit_decl 0x3fffb2770078 D.1>
full-name "const value_type"
n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fffa9d4d4a0>>
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 <http://gcc.gnu.org/bugs.html> for instructions.
--
Markus
next prev parent reply other threads:[~2015-08-31 16:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 14:51 Richard Biener
2015-08-31 17:39 ` Markus Trippelsdorf [this message]
2015-09-01 8:01 ` Richard Biener
2015-09-01 8:15 ` Markus Trippelsdorf
2015-09-01 8:22 ` Richard Biener
2015-09-01 11:15 ` Jan Hubicka
2015-09-01 11:20 ` Markus Trippelsdorf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150831161713.GB1940@x4 \
--to=markus@trippelsdorf.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).