From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126339 invoked by alias); 17 Jun 2015 15:37:09 -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 126235 invoked by uid 89); 17 Jun 2015 15:37:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f172.google.com Received: from mail-qc0-f172.google.com (HELO mail-qc0-f172.google.com) (209.85.216.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 17 Jun 2015 15:37:06 +0000 Received: by qcwx2 with SMTP id x2so14827570qcw.1 for ; Wed, 17 Jun 2015 08:37:04 -0700 (PDT) X-Received: by 10.140.216.18 with SMTP id m18mr9159812qhb.19.1434555424230; Wed, 17 Jun 2015 08:37:04 -0700 (PDT) Received: from ?IPv6:2601:19b:400:a983:a2a8:cdff:fe3e:b48? ([2601:19b:400:a983:a2a8:cdff:fe3e:b48]) by mx.google.com with ESMTPSA id a26sm2307819qka.0.2015.06.17.08.37.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 08:37:03 -0700 (PDT) Message-ID: <5581941E.70601@acm.org> Date: Wed, 17 Jun 2015 15:41:00 -0000 From: Nathan Sidwell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: James Greenhalgh CC: Andreas Schwab , Jason Merrill , GCC Patches Subject: Re: [C++/58583] ICE instantiating NSDMIs References: <557384CB.1020301@acm.org> <5575D517.1030708@redhat.com> <5576EE23.6030806@acm.org> <55805281.7040501@acm.org> <20150617085738.GA22950@arm.com> In-Reply-To: <20150617085738.GA22950@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg01210.txt.bz2 On 06/17/15 04:57, James Greenhalgh wrote: > I'm seeing the same issues on aarch64-none-elf and aarch64_be-none-elf > in one of my testing environments, but, interestingly, not on > aarch64-none-linux-gnu or in my other aarch64-none-elf testing > environment (!!). ugh. What is the behavior on the testcase with the patch reverted? Is it the same on both elf systems? (I'm expecting an ICE in one of the tsubst variants when it meets a DEFAULT_ARG) > I've pasted both log extracts below (after > stripping the file paths for each build environment, so you can see just > how similar the invocations are!). The PASSing environment does use a > slightly more modern toolchain for building the cross-toolchain (PASSing > environment uses 4.9.2, FAILing environment uses 4.8.1), so that could > be a source of the difference? ew. nathan