From patchwork Mon Dec 21 16:24:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 559615 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 068C6140216 for ; Tue, 22 Dec 2015 03:25:09 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=l4nIYhRw; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=sxkutZXBSBToTYPu b6PUPG5e+7+v1Nx2CG8WR9QskC7uvG3SdJj+GIZke9L7VNWhFy1d/bOKkwplo25Q 2stPfMwTp3d+63BYbQEStQ7tbn55h+qOegPSoIFAdNRsRp5H2p2a9/JDLxA9HI5g tr6/mzlkCmpdOXK0Mk4ted0cpQg= 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:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=45Fuqq0tLoJqBuM2wAf0Nb SclQA=; b=l4nIYhRwu5bDEPxwYOGkpb8Av16NfH/WqraQ0ZPvqtxL+lap+1IOhQ q2BppgBoKDf58z9Af7KQaIPv7g7Xq2HugLT7gJCPkPdi8qEJ5vP8tzmgBU5Vg9MC qu4gEihyI8rqAp+pezjRwP3hGs11CjT99YI2psyHdFVh5oiVcFJ/s= Received: (qmail 44285 invoked by alias); 21 Dec 2015 16:25:02 -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 44118 invoked by uid 89); 21 Dec 2015 16:25:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL, BAYES_50, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=sk:ebotcaz, U*ebotcazou, ebotcazouadacorecom, ebotcazou@adacore.com X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 21 Dec 2015 16:25:01 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 808E32EE0030 for ; Mon, 21 Dec 2015 17:24:57 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFD_cIPVGRCR for ; Mon, 21 Dec 2015 17:24:57 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 5F4A92EE0028 for ; Mon, 21 Dec 2015 17:24:57 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [ARM] Fix ICE on Ada code with -mbig-endian -mhard-float Date: Mon, 21 Dec 2015 17:24:56 +0100 Message-ID: <3790654.AGgIZLrLrs@polaris> User-Agent: KMail/4.14.9 (Linux/3.16.7-29-desktop; KDE/4.14.9; x86_64; ; ) MIME-Version: 1.0 Hi, the attached Ada testcase triggers an ICE with -mbig-endian -mhard-float: eric@polaris:~/build/gcc/arm-linux-gnueabi> gcc/xgcc -Bgcc -S p.adb -I gcc/ada/rts -mbig-endian -mhard-float +===========================GNAT BUG DETECTED==============================+ | 6.0.0 20151220 (experimental) [trunk revision 231856] (arm-linux-gnueabi) GCC error:| | in emit_move_multi_word, at expr.c:3452 because the middle-end is trying to copy an OImode value from VFP registers and the back-end refuses it in big-endian mode: In big-endian mode, modes greater than word size (i.e. DFmode) are stored in VFP registers in little-endian order. We can't describe that accurately to GCC, so avoid taking subregs of such values. The only exception is going from a 128-bit to a 64-bit type. In that case the data layout happens to be consistent for big-endian, so we explicitly allow that case. */ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (TARGET_VFP && TARGET_BIG_END \ && !(GET_MODE_SIZE (FROM) == 16 && GET_MODE_SIZE (TO) == 8) \ && (GET_MODE_SIZE (FROM) > UNITS_PER_WORD \ || GET_MODE_SIZE (TO) > UNITS_PER_WORD) \ && reg_classes_intersect_p (VFP_REGS, (CLASS))) That's very likely not reproducible in the C family of languages because the code generates a RECORD_TYPE with OImode. The other thing to note is that this works for TImode because, in this case, the back-end returns a PARALLEL instead of a bare REG for the return value register. Hence the attached patch, which extends this treatment to all integer modes larger than TImode. Tested on arm-none-eabi, OK for the mainline? 2015-12-21 Eric Botcazou * config/arm/arm.c (aapcs_vfp_allocate_return_reg): Treat all integer modes larger than TImode as TImode if NEON is not enabled. Index: config/arm/arm.c =================================================================== --- config/arm/arm.c (revision 231856) +++ config/arm/arm.c (working copy) @@ -5846,7 +5846,10 @@ aapcs_vfp_allocate_return_reg (enum arm_ if (!use_vfp_abi (pcs_variant, false)) return NULL; - if (mode == BLKmode || (mode == TImode && !TARGET_NEON)) + if (mode == BLKmode + || (GET_MODE_CLASS (mode) == MODE_INT + && GET_MODE_SIZE (mode) >= GET_MODE_SIZE (TImode) + && !TARGET_NEON)) { int count; machine_mode ag_mode;