From patchwork Wed Jul 2 10:05:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 366314 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 B231A14009E for ; Wed, 2 Jul 2014 20:05:50 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=PDFTi1CEilOK5QZyalgHxIuIQrxHyjOIbIzpe0IzM1Whs81yKX fFobHOo2RUg2hTpiRo2LXjf7hQJxEGWTQpljAd9kzjCuIAWJhmhWW9ry2T1myc1I U7iaycdWsfigh7+8E8lhlyqvOD/sczyXe19Om+YEzdzy5gxrQ71rvKHyw= 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:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=XsKlfbicYkFmKt6QJZy5LxNtfLw=; b=eLOGJxgMKhPicgS7+EOq 9W++DoklbnBADAYQbCboSrPnWbA+PW8sr3PycwDsKM1EABoPJKDDqaoNyGhbuCi6 TDimsZxg8gksbvwwTXrVF6h7kbQFpvEGKYvpWnNqyqx9Mk2F7l5hOmp99ht098Eu zy9uUlylW0A0NR8YKilxLLM= Received: (qmail 30903 invoked by alias); 2 Jul 2014 10:05: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 30884 invoked by uid 89); 2 Jul 2014 10:05:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Jul 2014 10:05:34 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1X2HPu-0006zM-DX from Maciej_Rozycki@mentor.com ; Wed, 02 Jul 2014 03:05:30 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jul 2014 03:05:30 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 2 Jul 2014 11:05:28 +0100 Date: Wed, 2 Jul 2014 11:05:23 +0100 From: "Maciej W. Rozycki" To: CC: Anton Blanchard Subject: [PATCH] Power/GCC: Subword atomic operation endianness check bug fix Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Hi, This change: ------------------------------------------------------------------------ r199935 | amodra | 2013-06-11 07:17:50 +0100 (Tue, 11 Jun 2013) | 4 lines * config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Calculate correct shift value in little-endian mode. ------------------------------------------------------------------------ fixed subword atomic operations on little-endian Power targets, but while the effect of the change happens to be correct, the way it is achieved is not. This code operates on SImode values, however refers to WORDS_BIG_ENDIAN to check the endianness. This is not right, quoting our internal manual: "[...] The memory order of bytes is defined by two target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': * `WORDS_BIG_ENDIAN', if set to 1, says that byte number zero is part of the most significant word; otherwise, it is part of the least significant word. * `BYTES_BIG_ENDIAN', if set to 1, says that byte number zero is the most significant byte within a word; otherwise, it is the least significant byte within a word." so WORDS_BIG_ENDIAN should only ever be referred when operating on multi-word values, not single-word ones such as SImode ones are. As it happens both macros have the same value for the Power target, so the result of the check works out the same, but nevertheless it's not correct and can be misleading to the casual reader. The fix below has been regression tested with the powerpc-eabi target and the following multilibs: -mcpu=603e -mcpu=603e -msoft-float -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe -msoft-float -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe -mlittle -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe -msoft-float -mcpu=7400 -maltivec -mabi=altivec as well as the powerpc-linux-gnu target and the following multilibs: -mcpu=603e -mcpu=603e -msoft-float -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe -mcpu=7400 -maltivec -mabi=altivec -mcpu=e5500 -m64 OK to apply? 2014-07-02 Maciej W. Rozycki gcc/ * config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Use BYTES_BIG_ENDIAN rather than WORDS_BIG_ENDIAN to check for byte endianness. Maciej gcc-ppc-atomic-le.diff Index: gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c =================================================================== --- gcc-fsf-trunk-quilt.orig/gcc/config/rs6000/rs6000.c 2014-06-10 21:46:36.628975329 +0100 +++ gcc-fsf-trunk-quilt/gcc/config/rs6000/rs6000.c 2014-06-11 16:35:08.917560846 +0100 @@ -19891,7 +19891,7 @@ rs6000_adjust_atomic_subword (rtx orig_m shift = gen_reg_rtx (SImode); addr = gen_lowpart (SImode, addr); emit_insn (gen_rlwinm (shift, addr, GEN_INT (3), GEN_INT (shift_mask))); - if (WORDS_BIG_ENDIAN) + if (BYTES_BIG_ENDIAN) shift = expand_simple_binop (SImode, XOR, shift, GEN_INT (shift_mask), shift, 1, OPTAB_LIB_WIDEN); *pshift = shift;