From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31028 invoked by alias); 2 May 2019 11:12:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31013 invoked by uid 89); 2 May 2019 11:12:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-HELO:sk:mail-io, distant, H*r:807 X-HELO: mail-io1-f68.google.com Received: from mail-io1-f68.google.com (HELO mail-io1-f68.google.com) (209.85.166.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 May 2019 11:12:11 +0000 Received: by mail-io1-f68.google.com with SMTP id u12so1773526iop.0 for ; Thu, 02 May 2019 04:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wAm5xcPGm+XnI2tmn/zT1gni+1lhs76ZvR27+5tcKHc=; b=m1pIiuh1zEzaJ50kGpQW7KQeRjyN3n0QM/gG+ET3+POKshvhZAOz6F2aJiM87AqL4h oTHL1AYHtCiNVtnKEuv9VsIzKhrG9YSyBXe77bvpW525MRYKoSXpdhhZppzLEi0xD9d/ wED5lB4y7RdjoA3ULOwBt2Ft2nT37jRfvOrFAIIWC6CzIEn7Fzy15zmzDYBbjVX2PloN 2pTYlWsMawOundT9IkpJtH+V58576gIJcQaiO+MqK4N9HnoQe6D0Hd4fmWBuDy3FLONK 1b9sSitfbhDwvNdQlB386JZKijurkEQ2PlWl/V6BQBlnJv0IVVHkbLx6uwR7fE7jehn0 ps5w== Return-Path: Received: from ?IPv6:2620:10d:c0a3:1407:e9b5:58e4:53e1:807? ([2620:10d:c091:200::1:615e]) by smtp.googlemail.com with ESMTPSA id i72sm6911051itc.11.2019.05.02.04.12.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 May 2019 04:12:08 -0700 (PDT) Sender: Nathan Sidwell Subject: Re: ICE with precompiled headers (GCC 8.1) To: paul@mad-scientist.net, "gcc@gcc.gnu.org" References: <09c7773cd22879ca1f23b40103fc4d2c1c1293f7.camel@mad-scientist.net> <42b8330f0d75562fcab205c0ea5ea92b96654bae.camel@mad-scientist.net> From: Nathan Sidwell Message-ID: <710e1899-70f3-2316-4e6c-3863beb74c3c@acm.org> Date: Thu, 02 May 2019 11:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00012.txt.bz2 On 5/1/19 10:56 AM, Paul Smith wrote: > On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote: >>> Unfortunately my GCC is heavily optimized and stripped so backtraces >>> are useless. I will generate a debuggable GCC and see if I can get >>> more info on the ICE. >> >> I have created a GCC with debug enabled so I'll see what I find. > > I was able to reproduce this ICE quite readily with my debuggable GCC > 8.1.0. Here's the failure: > > : internal compiler error: Segmentation fault > 0x9cae61 crash_signal > /work/src/cc/gcc-8.1.0/gcc/toplev.c:325 > 0x1293778 apply_vpath > /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127 > 0x1293acc deps_add_dep(deps*, char const*) > /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258 > 0x1293fe3 deps_restore(deps*, _IO_FILE*, char const*) > /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432 > 0x129535b cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*) > /work/src/cc/gcc-8.1.0/libcpp/pch.c:884 > 0x596d59 c_common_read_pch(cpp_reader*, char const*, int, char const*) > /work/src/cc/gcc-8.1.0/gcc/c-family/c-pch.c:373 > 0x12872fe should_stack_file > /work/src/cc/gcc-8.1.0/libcpp/files.c:814 > 0x12874f1 _cpp_stack_file > /work/src/cc/gcc-8.1.0/libcpp/files.c:900 > 0x12876a7 _cpp_stack_include > /work/src/cc/gcc-8.1.0/libcpp/files.c:1049 > 0x1287b22 cpp_push_include(cpp_reader*, char const*) > /work/src/cc/gcc-8.1.0/libcpp/files.c:1484 > 0x5943ec push_command_line_include > /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1483 > 0x594615 c_finish_options > /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1452 > 0x5963a2 c_common_parse_file() > /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1126 > > Unsurprisingly the problem is that the "deps" data member in > cpp_reader* is null: > > #0 apply_vpath (d=d@entry=0x0, > t=t@entry=0x2174860 "/src/foo_pch.h") at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127 > #1 0x0000000001293acd in deps_add_dep (d=d@entry=0x0, > t=t@entry=0x2174860 "/src/foo_pch.h") at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258 > #2 0x0000000001293fe4 in deps_restore (deps=0x0, fd=fd@entry=0x2171750, > self=self@entry=0x2106810 "/src/obj/foo_pch.h.gch") > at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432 > #3 0x000000000129535c in cpp_read_state (r=r@entry=0x20f4d60, > name=name@entry=0x2106810 "/src/obj/foo_pch.h.gch", f=f@entry=0x2171750, data=0x210bce0) > at /work/src/cc/gcc-8.1.0/libcpp/pch.c:884 > > I have no idea whether the problem is that it should never be possible > for "deps" to be null, or whether the problem is that we're not > checking for that possibility when we should be. > > I'm building the current GCC 9.0.1 prerelease to see if I can reproduce > it there. > > Once again removing -fpch-deps solves the problem. I can only assume > that without that flag we never bother to walk the deps data member at > all. I've been playing with dep generation on the modules branch, and noticed there did appear to be something funky going on with its interaction with PCH. I didn't investigate, but have some patches that I'll be merging in the not too distant future. nathan -- Nathan Sidwell