From: Thomas Schwinge <thomas@codesourcery.com>
To: Joseph Myers <joseph@codesourcery.com>,
Richard Biener <richard.guenther@gmail.com>
Cc: <gcc@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])
Date: Wed, 07 Sep 2016 12:18:00 -0000 [thread overview]
Message-ID: <87h99s53ls.fsf@kepler.schwinge.homeip.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1608191101110.30687@digraph.polyomino.org.uk>
[-- Attachment #1: Type: text/plain, Size: 6601 bytes --]
Hi!
I trimmed the CC list -- I'm looking for advice about debugging a lto1
ICE.
On Fri, 19 Aug 2016 11:05:59 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 19 Aug 2016, Richard Biener wrote:
> > Can you quickly verify if LTO works with the new types? I don't see anything
> > that would prevent it but having new global trees and backends initializing them
> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
>
> Well, the execution tests are in gcc.dg/torture, which is run with various
> options including -flto (and I've checked the testsuite logs to confirm
> these tests are indeed run with such options). Is there something else
> you think should be tested?
As I noted in <https://gcc.gnu.org/PR77458>:
As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", nvptx
offloading is broken, ICEs in LTO stream-in. Probably some kind of data-type
mismatch that is not visible with Intel MIC offloading (using the same data
types) but explodes with nvptx. I'm having a look.
I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
backtrace of the ICE looks as follows:
#0 fancy_abort (file=file@entry=0x10d61d0 "[...]/source-gcc/gcc/vec.h", line=line@entry=727, function=function@entry=0x10d6e3a <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at [...]/source-gcc/gcc/diagnostic.c:1414
#1 0x000000000058c9ef in vec<tree_node*, va_heap, vl_embed>::operator[] (this=0x16919c0, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:727
#2 0x000000000058ca33 in vec<tree_node*, va_heap, vl_ptr>::operator[] (this=this@entry=0x1691998, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:1211
#3 0x0000000000c73e54 in streamer_tree_cache_get_tree (cache=0x1691990, ix=ix@entry=185) at [...]/source-gcc/gcc/tree-streamer.h:98
#4 0x0000000000c73eb9 in streamer_get_pickled_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930) at [...]/source-gcc/gcc/tree-streamer-in.c:1112
#5 0x00000000008f841b in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=LTO_tree_pickle_reference, hash=hash@entry=0) at [...]/source-gcc/gcc/lto-streamer-in.c:1404
#6 0x00000000008f8844 in lto_input_tree (ib=0x7fffffffceb0, data_in=0x1691930) at [...]/source-gcc/gcc/lto-streamer-in.c:1444
#7 0x0000000000c720d2 in lto_input_ts_list_tree_pointers (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861
#8 0x0000000000c7444e in streamer_read_tree_body (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:1077
#9 0x00000000008f6428 in lto_read_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/lto-streamer-in.c:1285
#10 0x00000000008f651b in lto_read_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1315
#11 0x00000000008f85db in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1427
#12 0x00000000008f8673 in lto_input_scc (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, len=len@entry=0x7fffffffceac, entry_len=entry_len@entry=0x7fffffffcea8) at [...]/source-gcc/gcc/lto-streamer-in.c:1339
#13 0x00000000005890f7 in lto_read_decls (decl_data=decl_data@entry=0x7ffff7fc0000, data=data@entry=0x169d570, resolutions=...) at [...]/source-gcc/gcc/lto/lto.c:1693
#14 0x00000000005898c8 in lto_file_finalize (file_data=file_data@entry=0x7ffff7fc0000, file=file@entry=0x15eedb0) at [...]/source-gcc/gcc/lto/lto.c:2037
#15 0x0000000000589928 in lto_create_files_from_ids (file=file@entry=0x15eedb0, file_data=file_data@entry=0x7ffff7fc0000, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2047
#16 0x0000000000589a7a in lto_file_read (file=0x15eedb0, resolution_file=resolution_file@entry=0x0, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2088
#17 0x0000000000589e84 in read_cgraph_and_symbols (nfiles=1, fnames=0x160e990) at [...]/source-gcc/gcc/lto/lto.c:2798
#18 0x000000000058a572 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:3299
#19 0x0000000000a48eff in compile_file () at [...]/source-gcc/gcc/toplev.c:466
#20 0x0000000000550943 in do_compile () at [...]/source-gcc/gcc/toplev.c:2010
#21 toplev::main (this=this@entry=0x7fffffffd180, argc=argc@entry=20, argv=0x15daf20, argv@entry=0x7fffffffd288) at [...]/source-gcc/gcc/toplev.c:2144
#22 0x0000000000552717 in main (argc=20, argv=0x7fffffffd288) at [...]/source-gcc/gcc/main.c:39
(Comparing to yesterday's r240004, the line number are slightly off, as
I've added some stuff to aid debugging.)
Looking at frame 14, lto_file_finalize, the ICE happens inside
lto_read_decls, after the mode table setup:
2025 #ifdef ACCEL_COMPILER
2026 lto_input_mode_table (file_data);
2027 #else
2028 file_data->mode_table = lto_mode_identity_table;
2029 #endif
2030 data = lto_get_section_data (file_data, LTO_section_decls, NULL, &len);
2031 if (data == NULL)
2032 {
2033 internal_error ("cannot read LTO decls from %s", file_data->file_name);
2034 return;
2035 }
2036 /* Frees resolutions */
2037 lto_read_decls (file_data, data, resolutions);
I have some confidence that it's not the offloading-specific
lto_write_mode_table/lto_input_mode_table mode table streaming; by manual
inspection it seems as if there's no change in the streamed information.
Looking at Joseph's gcc/tree.c:build_common_tree_nodes, I observe that
the x86_64 GNU/Linux target compiler does but the nvptx-offloading lto1
does not set up _Float128 and _Float64x types (expectedly, I'd day), but
I'm not sure if that's really the reason for the breakage.
From the backtrace I have difficulties to tell what exactly lto1 is
choking on -- are there any good strategies aside from stepping
before/after lto1s in GDB, and seeing where they diverge? For example,
can I pretty-print the LTO stream that the ICEing lto1 is reading in, and
can I try to tell from that what it's choking on?
Grüße
Thomas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
next prev parent reply other threads:[~2016-09-07 11:52 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 12:07 Implement C _FloatN, _FloatNx types Joseph Myers
2016-06-21 15:17 ` FX
2016-06-21 15:38 ` Joseph Myers
2016-06-21 15:21 ` Bill Schmidt
2016-06-21 15:43 ` Joseph Myers
2016-06-21 17:42 ` Implement C _FloatN, _FloatNx types [version 2] Joseph Myers
2016-06-21 20:53 ` Michael Meissner
2016-06-21 21:18 ` Joseph Myers
2016-06-22 20:43 ` Joseph Myers
2016-06-22 21:45 ` FX
2016-06-23 14:20 ` Implement C _FloatN, _FloatNx types [version 3] Joseph Myers
2016-06-27 17:31 ` Ping " Joseph Myers
2016-06-27 21:20 ` Bill Schmidt
2016-06-27 21:24 ` Joseph Myers
2016-06-27 21:38 ` Segher Boessenkool
2016-07-19 13:54 ` Implement C _FloatN, _FloatNx types [version 4] Joseph Myers
2016-07-22 21:59 ` Implement C _FloatN, _FloatNx types [version 5] Joseph Myers
2016-07-29 17:37 ` Ping " Joseph Myers
2016-07-29 22:09 ` Michael Meissner
2016-08-04 23:54 ` Michael Meissner
2016-08-05 0:12 ` Joseph Myers
2016-08-10 11:33 ` Ping^2 " Joseph Myers
2016-08-10 17:14 ` Paul Richard Thomas
2016-08-11 7:05 ` FX
2016-08-15 22:21 ` Ping^3 " Joseph Myers
2016-08-17 15:43 ` James Greenhalgh
2016-08-17 16:44 ` Joseph Myers
2016-08-17 20:17 ` Implement C _FloatN, _FloatNx types [version 6] Joseph Myers
[not found] ` <CAFiYyc3xqcqJ1rK2X0rC+wwpx3akHbULVG1G47PRmtk4wTk=7A@mail.gmail.com>
2016-08-19 11:06 ` Joseph Myers
2016-08-19 11:11 ` Richard Biener
2016-08-19 14:40 ` Joseph Myers
2016-08-19 15:52 ` David Malcolm
2016-08-19 16:51 ` Joseph Myers
2016-08-19 17:21 ` David Malcolm
2016-09-07 12:18 ` Thomas Schwinge [this message]
2016-09-07 12:28 ` Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]) Richard Biener
2016-09-08 11:53 ` Thomas Schwinge
2016-09-14 10:24 ` Richard Biener
2016-09-16 7:21 ` [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])) Thomas Schwinge
2016-09-16 9:02 ` Richard Biener
2016-09-16 14:00 ` Thomas Schwinge
2016-09-16 18:02 ` Joseph Myers
2016-09-19 8:40 ` Richard Biener
2016-09-19 11:04 ` Thomas Schwinge
2016-09-19 13:22 ` Joseph Myers
2016-09-19 8:53 ` Richard Biener
2016-09-19 11:57 ` Thomas Schwinge
2016-09-19 12:07 ` Richard Biener
2016-09-29 13:26 ` [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types Thomas Schwinge
2016-10-17 15:59 ` Thomas Schwinge
2016-10-19 10:58 ` Thomas Schwinge
2016-09-29 14:55 ` Explicitly list all tree codes in gcc/tree-streamer.c:record_common_node (was: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types) Thomas Schwinge
2016-09-30 8:10 ` Richard Biener
2016-10-17 15:57 ` Explicitly list all tree codes in gcc/tree-streamer.c:record_common_node Thomas Schwinge
2016-09-16 17:57 ` [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])) Joseph Myers
2016-08-19 15:28 ` Implement C _FloatN, _FloatNx types [version 6] Szabolcs Nagy
2016-08-19 16:24 ` Joseph Myers
2016-08-31 16:58 ` James Greenhalgh
2016-08-31 17:26 ` Joseph Myers
2016-09-01 10:52 ` Szabolcs Nagy
2016-09-01 15:40 ` Joseph Myers
2016-08-21 9:50 ` Andreas Schwab
2016-08-22 10:46 ` Joseph Myers
2016-08-22 8:09 ` [BUILDROBOT] x86_64: Segmentation fault during -fself-test (was: " Jan-Benedict Glaw
2016-08-22 11:23 ` Joseph Myers
2016-08-22 10:48 ` Matthew Wahab
2016-08-22 11:48 ` Joseph Myers
2016-08-22 17:52 ` Joseph Myers
2016-09-03 19:46 ` Andreas Schwab
2016-09-05 11:45 ` Joseph Myers
2016-09-06 9:02 ` Richard Biener
2016-09-06 11:18 ` Joseph Myers
2016-07-19 11:29 ` Implement C _FloatN, _FloatNx types [version 3] James Greenhalgh
2016-07-28 22:43 ` Joseph Myers
2016-08-09 15:26 ` James Greenhalgh
2016-08-09 20:44 ` Joseph Myers
2016-08-05 0:09 ` Implement C _FloatN, _FloatNx types Michael Meissner
2016-08-05 0:35 ` Joseph Myers
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=87h99s53ls.fsf@kepler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=richard.guenther@gmail.com \
/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).