From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23997 invoked by alias); 22 Aug 2011 18:04:14 -0000 Received: (qmail 23982 invoked by uid 22791); 22 Aug 2011 18:04:12 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Aug 2011 18:03:46 +0000 Received: (qmail 29457 invoked from network); 22 Aug 2011 18:03:45 -0000 Received: from unknown (HELO ?84.152.157.65?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Aug 2011 18:03:45 -0000 Message-ID: <4E5299AA.2010408@codesourcery.com> Date: Mon, 22 Aug 2011 18:04:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110801 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: Andrew Pinski CC: GCC Mailing List , Richard Henderson Subject: Re: Fwd: C6X fails to build in FSF mainline References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030308090700070606080607" 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 X-SW-Source: 2011-08/txt/msg00387.txt.bz2 This is a multi-part message in MIME format. --------------030308090700070606080607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-length: 876 On 08/18/11 03:45, Andrew Pinski wrote: > Forwarding this to the gcc list. Also Adding RTH to the CC since he > helped Bernd to get the dwarf2 parts working correctly. > You probably know this already. The c6x-elf target fails to build > libgcc with the current FSF mainline sources: > > gcc/libgcc2.c: In function ‘__gnu_mulsc3’: > gcc/libgcc2.c:1928:1: internal compiler error: in scan_trace, at > dwarf2cfi.c:2433 > Please submit a full bug report, Thanks Richard for fixing this (I've been on vacation). There are some testsuite failures at -O3 in another part of dwarf2cfi, which are caused by computed_jump_p returning 0 for the indirect_jump_shadow pattern. There isn't really a sensible way to represent this pattern in RTL, but we can take advantage of the fact that computed_jump_p returns true for constants. I committed the following patch. Bernd --------------030308090700070606080607 Content-Type: text/plain; name="compjmp.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="compjmp.diff" Content-length: 1420 SW5kZXg6IGdjYy9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gZ2NjL0NoYW5nZUxvZwkocmV2aXNpb24gMTc3OTY3KQorKysgZ2NjL0No YW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDggQEAKKzIwMTEt MDgtMjIgIEJlcm5kIFNjaG1pZHQgIDxiZXJuZHNAY29kZXNvdXJjZXJ5LmNv bT4KKworCSogY29uZmlnL2M2eC9jNngubWQgKGluZGlyZWN0X2p1bXBfc2hh ZG93KTogVHdlYWsgcmVwcmVzZW50YXRpb24KKwl0byBtYWtlIGNvbXB1dGVk X2p1bXBfcCByZXR1cm4gdHJ1ZS4KKwogMjAxMS0wOC0yMiAgUmFpbmVyIE9y dGggIDxyb0BDZUJpVGVjLlVuaS1CaWVsZWZlbGQuREU+CiAKIAkqIGNvbmZp Z3VyZS5hYyAoR0NDX1BJQ0ZMQUdfRk9SX1RBUkdFVCk6IENhbGwgaXQuCklu ZGV4OiBnY2MvY29uZmlnL2M2eC9jNngubWQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gZ2NjL2NvbmZpZy9jNngvYzZ4Lm1kCShyZXZpc2lvbiAxNzc5 NTIpCisrKyBnY2MvY29uZmlnL2M2eC9jNngubWQJKHdvcmtpbmcgY29weSkK QEAgLTE0MjcsOCArMTQyNywxMCBAQCAoZGVmaW5lX2luc24gInJlYWxfcmV0 IgogICAgKHNldF9hdHRyICJjcm9zcyIgInksbiIpCiAgICAoc2V0X2F0dHIg ImRlc3RfcmVnZmlsZSIgImIiKV0pCiAKKzs7IGNvbXB1dGVkX2p1bXBfcCBy ZXR1cm5zIHRydWUgaWYgaXQgZmluZHMgYSBjb25zdGFudDsgc28gdXNlIG9u ZSBpbiB0aGUKKzs7IHVuc3BlYy4KIChkZWZpbmVfaW5zbiAiaW5kaXJlY3Rf anVtcF9zaGFkb3ciCi0gIFsoc2V0IChwYykgKHVuc3BlYyBbKHBjKV0gVU5T UEVDX0pVTVBfU0hBRE9XKSldCisgIFsoc2V0IChwYykgKHVuc3BlYyBbKGNv bnN0X2ludCAxKV0gVU5TUEVDX0pVTVBfU0hBRE9XKSldCiAgICIiCiAgICI7 OyBpbmRpcmVjdCBqdW1wIG9jY3VycyIKICAgWyhzZXRfYXR0ciAidHlwZSIg InNoYWRvdyIpXSkK --------------030308090700070606080607--