From patchwork Fri Jun 8 00:15:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 163696 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]) by ozlabs.org (Postfix) with SMTP id 143EBB6FA3 for ; Fri, 8 Jun 2012 10:15:49 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1339719350; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:Received:Date:Message-Id:From:To:CC: Subject:MIME-Version:Content-Type:Content-Transfer-Encoding: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=0QVDlaaNJYknTP+fUnu2 ClM+Oh0=; b=QXrDr06CxqhXS+TN4OK09qJi285Q/q51Kkxe2Rie+39hABKMsGkD 0kWnjlrscght6XF45cEg0nyPfeWg8AnuRCZQoBZ60fnAc9guo35m1p3MxG6YRBN+ R1IKPRWI16PjhO01OvfU1kvtOywC9HUjN/HETVm9sa+hcqmU0oQ5FHg= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:Received:Date:Message-Id:From:To:CC:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=TF7dRfUBBkP/ckzIK+SnvhWePbCCPrtpyPbOEAIaT16sNvW2by0WDQzppyh+7j jqeScp9qDZ1dgZETYWmWtaEfnScd6A86cHetNyjAuDsMvltCcfREa0lqVkublncN R71rQJd4yIbJY4FYfni0lLeANNgBvWCGkcMGDfIn0u/iE=; Received: (qmail 21100 invoked by alias); 8 Jun 2012 00:15:43 -0000 Received: (qmail 21086 invoked by uid 22791); 8 Jun 2012 00:15:38 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_HOSTKARMA_NO, TW_CP, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ra.se.axis.com (HELO ra.se.axis.com) (195.60.68.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jun 2012 00:15:25 +0000 Received: from localhost (localhost [127.0.0.1]) by ra.se.axis.com (Postfix) with ESMTP id 993EB11F65; Fri, 8 Jun 2012 02:15:23 +0200 (CEST) Received: from ra.se.axis.com ([127.0.0.1]) by localhost (ra.se.axis.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hz9L7sGjtX7R; Fri, 8 Jun 2012 02:15:22 +0200 (CEST) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by ra.se.axis.com (Postfix) with ESMTP id 7956A11F61; Fri, 8 Jun 2012 02:15:22 +0200 (CEST) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by thoth.se.axis.com (Postfix) with ESMTP id 60CA93414C; Fri, 8 Jun 2012 02:15:22 +0200 (CEST) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id q580FMmt014119; Fri, 8 Jun 2012 02:15:22 +0200 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id q580FL8H014115; Fri, 8 Jun 2012 02:15:21 +0200 Date: Fri, 8 Jun 2012 02:15:21 +0200 Message-Id: <201206080015.q580FL8H014115@ignucius.se.axis.com> From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org CC: richard.earnshaw@arm.com Subject: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses MIME-Version: 1.0 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 (CC to ARM maintainer approving the original patch.) I'm listing this under "caveats" rather than "improvements" and before the current top ARM-related caveat (as this one is more important :) because I don't see performance figures in the context of the original patch (r178852) backing up this as an improvement, and it caused sort-of a wild goose hunt for applications causing unaligned accesses, until it was found to be deliberately emitted by gcc-4.7 when configured for arm-unknown-linux-gnueabi and passing "-marmv6". Hence caveat. Nomenclature taken from that patch; if prefer a different spelling of the ARM variants, please tell how. The "some source codes" was in the analyzed case a strcpy of a five-byte string (busybox/libbb/procps.c:365 'strcpy(filename_tail, "stat");' of some unknown busybox-version). An OS configured with unaligned accesses turned off (IIUC the default for Linux/ARM), has the nice property that you easily spot a certain class of bad codes. Ok to commit? Alternatively and IMHO preferably, there's reason enough to revert the (new) default, including the gcc-4.7 branch. brgds, H-P Index: changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.113 diff -p -u -r1.113 changes.html --- changes.html 5 Jun 2012 11:03:53 -0000 1.113 +++ changes.html 8 Jun 2012 00:01:09 -0000 @@ -43,6 +43,16 @@ +
  • On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, + ARMv7-R, or ARMv7-M, the default of the new option + -munaligned-accesses is on, which for some source + codes generates code that accesses memory on unaligned adresses. + This will require the OS of those systems to enable such accesses + (controlled by CP15 register c1, refer to ARM documentation). + Alternatively or for compatibility with OS versions that do not + enable unaligned accesses, all codes has to be compiled with + -mno-unaligned-accesses.
    • +
  • Support on ARM for the legacy floating-point accelerator (FPA) and the mixed-endian floating-point format that it used has been obsoleted. The ports that still use this format have been obsoleted as well.