From patchwork Mon Jun 4 08:48:33 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Richard Earnshaw (lists)" X-Patchwork-Id: 924885 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-478995-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="AJBs18Is"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40zpWP2ZKXz9ryk for ; Mon, 4 Jun 2018 18:48:48 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=IYMgsgq06Gb3I0BZs1EtJY+FlYZH5RO+ScZD9tIK+EqN4SFkQQ s/oUzKAUPZ8KmvVnJVh6To/Mz6GreFq+SrpGYmO0uyDfC6PPIyBLp+XcxWHlG8NK 1XUbfteW4f2OtEwzloWUCot2Bwk4zSH0NMEeyOLFHIpWMp+yXrkpXuvT8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=g5EhBzQDGdI6Ft1J2kktm5snLlk=; b=AJBs18IskhNlg7MLmab6 8MS4CBkyiaVTrjiWx5nF6BXebwfj5fDi2IU+Sud3g3wtG17ZM1RnXE+y4wl9UZ8M kndJyImicj0/XtPBucDm/pKEaVLvh5NT1AfiHLxbtPoSQRR/b6CO/oDGyM94VOyB fK7S8V9l7+yK7MzOUWqttSQ= Received: (qmail 52615 invoked by alias); 4 Jun 2018 08:48:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 52586 invoked by uid 89); 4 Jun 2018 08:48:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=Architecture X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jun 2018 08:48:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5248E1529; Mon, 4 Jun 2018 01:48:35 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C69E33F25D; Mon, 4 Jun 2018 01:48:34 -0700 (PDT) To: gcc-patches From: "Richard Earnshaw (lists)" Subject: [arm] PR target/86003 build failures with --with-cpu=xscale Openpgp: preference=signencrypt Message-ID: <6c5695c2-8265-f16d-9653-602ce263288e@arm.com> Date: Mon, 4 Jun 2018 09:48:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 The XScale cpu configuration in GCC has always been somewhat non-conforming. Although XScale isn't an architecture (it's simply an implementation of ARMv5te), we do by tradition emit a specific pre-define for it. We achieve this effect by adding an additional feature bit to the xscale CPU definition that isn't part of the base architecture. When I restructured the options last year I overlooked this oddity and the result, of course, is that this configuration now fails to build as intended. What happens is that the driver (correctly) constructs an architecture for the xscale cpu name (as armv5te) and passes it in addition to the CPU name. The backend code, on finding both a cpu and an architecture specifies attempts to correlate the two and finds a difference due to the additional feature bit and reports an inconsistency (fatally if -werror is specified). I think the best fix to this is to treat the xscale feature bit using the same mechanism that we use for other 'quirks' in CPU implementations and simply filter it out before comparing the capabilities. It has the additional benefit that it's also the simplest fix. PR target/86003 * config/arm/arm-cpus.in (ALL_QUIRKS): Add xscale feature to the list of bits to ignore when comparing architectures. Committed to trunk and gcc-8 branch diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in index 96972a0..545321b 100644 --- a/gcc/config/arm/arm-cpus.in +++ b/gcc/config/arm/arm-cpus.in @@ -268,7 +268,9 @@ define fgroup DOTPROD NEON dotprod # List of all quirk bits to strip out when comparing CPU features with # architectures. -define fgroup ALL_QUIRKS quirk_no_volatile_ce quirk_armv6kz quirk_cm3_ldrd +# xscale isn't really a 'quirk', but it isn't an architecture either and we +# need to ignore it for matching purposes. +define fgroup ALL_QUIRKS quirk_no_volatile_ce quirk_armv6kz quirk_cm3_ldrd xscale # Architecture entries # format: