From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83069 invoked by alias); 7 Sep 2016 12:23:32 -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 83035 invoked by uid 89); 7 Sep 2016 12:23:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=Gr, ordering, HCc:U*gcc, Gr=c3=bc=c3?= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Sep 2016 12:23:21 +0000 Received: by mail-wm0-f48.google.com with SMTP id 1so29074582wmz.1; Wed, 07 Sep 2016 05:23:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W2XE7lPqXTttYCIVGL2YhL366LYf9tVK8WPVppG18WY=; b=Hn1G073rIScev+mK+PegB04JKBgRBOugwII8epi3hrFTKg7Tu15fR9q9dqAFWK/tdR 2wD38QKj7mEFMlqB7epkFKGzjj8kWHfjAyqfUHlaVyvRuDn1RoHbZYXrBD4G2dzvzo+7 UAuevZQYSzP4LXEntmQqiSVAaHmxF0sqgI6tZ4EA7MnvMcf1pucBy2m07P0CK67kxBCf jhwWOqdKBbeQ5I3xqa/Hnfw9J4pnmU5019fbhH0A9LqRnX4Pr6KHLSuCIfsIVm/VC31p kQF10ekKQGSRZA6Q1aqENqpYSlRPm3+iHpG71Bn0eavIoy0MRYPxcshfg+ItwYuPeijG wJ1g== X-Gm-Message-State: AE9vXwOdaGQkgUz4OtwKPby0b0hagwmPlzqC651n+3jEyYZJkrZeBWKZ94FXQr4ERVM5f493HMidJPs74jlFEA== X-Received: by 10.194.73.99 with SMTP id k3mr12342524wjv.63.1473250999447; Wed, 07 Sep 2016 05:23:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Wed, 7 Sep 2016 05:23:18 -0700 (PDT) In-Reply-To: <87h99s53ls.fsf@kepler.schwinge.homeip.net> References: <20160817154244.GA39270@arm.com> <87h99s53ls.fsf@kepler.schwinge.homeip.net> From: Richard Biener Date: Wed, 07 Sep 2016 12:28:00 -0000 Message-ID: Subject: Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]) To: Thomas Schwinge Cc: Joseph Myers , GCC Development , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00380.txt.bz2 On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge w= rote: > 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 wrote: >> On Fri, 19 Aug 2016, Richard Biener wrote: >> > Can you quickly verify if LTO works with the new types? I don't see a= nything >> > that would prevent it but having new global trees and backends initial= izing 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 vario= us >> 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 : > > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types= ", nvptx > offloading is broken, ICEs in LTO stream-in. Probably some kind of d= ata-type > mismatch that is not visible with Intel MIC offloading (using the sam= e 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=3Dfile@entry=3D0x10d61d0 "[...]/source-gcc/gcc/= vec.h", line=3Dline@entry=3D727, function=3Dfunction@entry=3D0x10d6e3a <_ZZ= N3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at [.= ..]/source-gcc/gcc/diagnostic.c:1414 > #1 0x000000000058c9ef in vec::operato= r[] (this=3D0x16919c0, ix=3Dix@entry=3D185) at [...]/source-gcc/gcc/vec.h:7= 27 > #2 0x000000000058ca33 in vec::operator[= ] (this=3Dthis@entry=3D0x1691998, ix=3Dix@entry=3D185) at [...]/source-gcc/= gcc/vec.h:1211 so it wants tree 185 which is (given the low number) likely one streamed by preload_common_nodes. This is carefully crafted to _not_ diverge by frontend (!) it wasn't even designed to cope with global trees being present or not dependent on target (well, because the target is always the same! mind you!) Now -- in theory it should deal with NULLs just fine (resulting in error_mark_node), but it can diverge when there are additional compount types (like vectors, complex or array or record types) whose element types are not in the set of global trees. The complex _FloatN types would be such a case given they appear before the= ir components. That mixes up the ordering at least. So I suggest to add a print_tree to where it does the streamer_tree_cache_a= ppend and compare cc1 and lto1 outcome. The ICE above means the lto1 has fewer preloaded nodes I guess. Richard. > #3 0x0000000000c73e54 in streamer_tree_cache_get_tree (cache=3D0x169= 1990, ix=3Dix@entry=3D185) at [...]/source-gcc/gcc/tree-streamer.h:98 > #4 0x0000000000c73eb9 in streamer_get_pickled_tree (ib=3Dib@entry=3D= 0x7fffffffceb0, data_in=3Ddata_in@entry=3D0x1691930) at [...]/source-gcc/gc= c/tree-streamer-in.c:1112 > #5 0x00000000008f841b in lto_input_tree_1 (ib=3Dib@entry=3D0x7ffffff= fceb0, data_in=3Ddata_in@entry=3D0x1691930, tag=3Dtag@entry=3DLTO_tree_pick= le_reference, hash=3Dhash@entry=3D0) at [...]/source-gcc/gcc/lto-streamer-i= n.c:1404 > #6 0x00000000008f8844 in lto_input_tree (ib=3D0x7fffffffceb0, data_i= n=3D0x1691930) at [...]/source-gcc/gcc/lto-streamer-in.c:1444 > #7 0x0000000000c720d2 in lto_input_ts_list_tree_pointers (ib=3Dib@en= try=3D0x7fffffffceb0, data_in=3Ddata_in@entry=3D0x1691930, expr=3Dexpr@entr= y=3D0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861 > #8 0x0000000000c7444e in streamer_read_tree_body (ib=3Dib@entry=3D0x= 7fffffffceb0, data_in=3Ddata_in@entry=3D0x1691930, expr=3Dexpr@entry=3D0x7f= fff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:1077 > #9 0x00000000008f6428 in lto_read_tree_1 (ib=3Dib@entry=3D0x7fffffff= ceb0, data_in=3Ddata_in@entry=3D0x1691930, expr=3Dexpr@entry=3D0x7ffff69937= 80) at [...]/source-gcc/gcc/lto-streamer-in.c:1285 > #10 0x00000000008f651b in lto_read_tree (ib=3Dib@entry=3D0x7fffffffce= b0, data_in=3Ddata_in@entry=3D0x1691930, tag=3Dtag@entry=3D4, hash=3Dhash@e= ntry=3D4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1315 > #11 0x00000000008f85db in lto_input_tree_1 (ib=3Dib@entry=3D0x7ffffff= fceb0, data_in=3Ddata_in@entry=3D0x1691930, tag=3Dtag@entry=3D4, hash=3Dhas= h@entry=3D4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1427 > #12 0x00000000008f8673 in lto_input_scc (ib=3Dib@entry=3D0x7fffffffce= b0, data_in=3Ddata_in@entry=3D0x1691930, len=3Dlen@entry=3D0x7fffffffceac, = entry_len=3Dentry_len@entry=3D0x7fffffffcea8) at [...]/source-gcc/gcc/lto-s= treamer-in.c:1339 > #13 0x00000000005890f7 in lto_read_decls (decl_data=3Ddecl_data@entry= =3D0x7ffff7fc0000, data=3Ddata@entry=3D0x169d570, resolutions=3D...) at [..= .]/source-gcc/gcc/lto/lto.c:1693 > #14 0x00000000005898c8 in lto_file_finalize (file_data=3Dfile_data@en= try=3D0x7ffff7fc0000, file=3Dfile@entry=3D0x15eedb0) at [...]/source-gcc/gc= c/lto/lto.c:2037 > #15 0x0000000000589928 in lto_create_files_from_ids (file=3Dfile@entr= y=3D0x15eedb0, file_data=3Dfile_data@entry=3D0x7ffff7fc0000, count=3Dcount@= entry=3D0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2047 > #16 0x0000000000589a7a in lto_file_read (file=3D0x15eedb0, resolution= _file=3Dresolution_file@entry=3D0x0, count=3Dcount@entry=3D0x7fffffffd054) = at [...]/source-gcc/gcc/lto/lto.c:2088 > #17 0x0000000000589e84 in read_cgraph_and_symbols (nfiles=3D1, fnames= =3D0x160e990) 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/top= lev.c:466 > #20 0x0000000000550943 in do_compile () at [...]/source-gcc/gcc/tople= v.c:2010 > #21 toplev::main (this=3Dthis@entry=3D0x7fffffffd180, argc=3Dargc@ent= ry=3D20, argv=3D0x15daf20, argv@entry=3D0x7fffffffd288) at [...]/source-gcc= /gcc/toplev.c:2144 > #22 0x0000000000552717 in main (argc=3D20, argv=3D0x7fffffffd288) 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 =3D lto_mode_identity_table; > 2029 #endif > 2030 data =3D lto_get_section_data (file_data, LTO_section_decls= , NULL, &len); > 2031 if (data =3D=3D NULL) > 2032 { > 2033 internal_error ("cannot read LTO decls from %s", file_d= ata->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=C3=BC=C3=9Fe > Thomas