From patchwork Wed Sep 2 16:28:10 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 52990 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-lb0-f198.google.com (mail-lb0-f198.google.com [209.85.217.198]) by patches.linaro.org (Postfix) with ESMTPS id 7469E23002 for ; Wed, 2 Sep 2015 16:29:50 +0000 (UTC) Received: by lbbti1 with SMTP id ti1sf5748530lbb.3 for ; Wed, 02 Sep 2015 09:29:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:from:to:subject:date:message-id :precedence:list-id:list-unsubscribe:list-archive:list-post :list-help:list-subscribe:cc:mime-version:content-type :content-transfer-encoding:sender:errors-to:x-original-sender :x-original-authentication-results:mailing-list; bh=mUz9r9XO3UGN0NlF3poU979moIxaVp3uKaxvC+iBoq4=; b=S7SJSdPQ3chzlNtseD8WhHMBTwWMQc36K8qHO4bVjok/oMRyiidEMuW5ryvsGUxOeN OtgAmzvv2+eKRYwyLu2jqJXwZi3xWwKbfv3+6Boqma/mRexG5z0sg6bI8hlTy1VLNmaF uKAf5AKVigwY9rviEvDBNrG38gyPMRD2aTw+2g5kFSw4MCM5sTbFAzCCAxxdLxt6O7bO dcSJHYNuOyIiEKQ7NilXrvu5IG5twFik5hCdwNw2xyzOnLd5SGYjWG6+RK/xt0dnLA/+ LGQajWqzMBJRBFYmxI0ZwXWkSXfbNXVxYxspNtMfJ+Xh5mB82H0oxLolvkA0KvTu6fqU Dn/g== X-Gm-Message-State: ALoCoQnOljwCvY1yZ1mz9yseo5QtPS9LMvM0OPAZou1GqUYy6t0+OUpRK1NsBgszbES6PDScdQVX X-Received: by 10.112.78.101 with SMTP id a5mr9399233lbx.9.1441211389422; Wed, 02 Sep 2015 09:29:49 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.153.7.102 with SMTP id db6ls123134lad.70.gmail; Wed, 02 Sep 2015 09:29:49 -0700 (PDT) X-Received: by 10.112.234.165 with SMTP id uf5mr15992936lbc.91.1441211389143; Wed, 02 Sep 2015 09:29:49 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com. [209.85.215.50]) by mx.google.com with ESMTPS id tn10si20151264lbb.38.2015.09.02.09.29.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2015 09:29:48 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.50 as permitted sender) client-ip=209.85.215.50; Received: by laeb10 with SMTP id b10so11123126lae.1 for ; Wed, 02 Sep 2015 09:29:48 -0700 (PDT) X-Received: by 10.112.166.2 with SMTP id zc2mr16040539lbb.29.1441211388715; Wed, 02 Sep 2015 09:29:48 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.164.42 with SMTP id yn10csp691159lbb; Wed, 2 Sep 2015 09:29:47 -0700 (PDT) X-Received: by 10.66.62.229 with SMTP id b5mr55941251pas.81.1441211387611; Wed, 02 Sep 2015 09:29:47 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id fn4si36329957pab.34.2015.09.02.09.29.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2015 09:29:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZXAts-0005t8-TX; Wed, 02 Sep 2015 16:28:40 +0000 Received: from mail-wi0-f182.google.com ([209.85.212.182]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZXAtp-0005jK-7k for linux-arm-kernel@lists.infradead.org; Wed, 02 Sep 2015 16:28:38 +0000 Received: by wiclp12 with SMTP id lp12so25051104wic.1 for ; Wed, 02 Sep 2015 09:28:15 -0700 (PDT) X-Received: by 10.180.81.227 with SMTP id d3mr5209176wiy.38.1441211295374; Wed, 02 Sep 2015 09:28:15 -0700 (PDT) Received: from localhost.localdomain (cag06-7-83-153-85-71.fbx.proxad.net. [83.153.85.71]) by smtp.gmail.com with ESMTPSA id m4sm33143136wjb.37.2015.09.02.09.28.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Sep 2015 09:28:14 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk, dave.martin@arm.com Subject: [PATCH] ARM: disable GCC SRA optimization Date: Wed, 2 Sep 2015 18:28:10 +0200 Message-Id: <1441211290-11449-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 1.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150902_092837_433497_AEF3089D X-CRM114-Status: GOOD ( 15.90 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.182 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.212.182 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Cc: Ard Biesheuvel , will.deacon@arm.com, leif.lindholm@linaro.org, nico@linaro.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: ard.biesheuvel@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.50 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 While working on the 32-bit ARM port of UEFI, I noticed a strange corruption in the kernel log. The following snprintf() statement (in drivers/firmware/efi/efi.c:efi_md_typeattr_format()) snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]", was producing the following output in the log: | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | |WB|WT|WC|UC]* | | | | | |WB|WT|WC|UC] |RUN| | | | | | | |UC] |RUN| | | | | | | |UC] As it turns out, this is caused by incorrect code being emitted for the string() function in lib/vsprintf.c. The following code if (!(spec.flags & LEFT)) { while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } } for (i = 0; i < len; ++i) { if (buf < end) *buf = *s; ++buf; ++s; } while (len < spec.field_width--) { if (buf < end) *buf = ' '; ++buf; } when called with len == 0, triggers an issue in the GCC SRA optimization pass (Scalar Replacement of Aggregates), which handles promotion of signed struct members incorrectly. This is a known but as yet unresolved issue. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular case, it is causing the second while loop to be executed erroneously a single time, causing the additional space characters to be printed. So disable the optimization by passing -fno-ipa-sra. Signed-off-by: Ard Biesheuvel Acked-by: Nicolas Pitre --- Needs to go to stable perhaps? The emitted asm is at the end of this patch. arch/arm/Makefile | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 7451b447cc2d..2c2b28ee4811 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -54,6 +54,14 @@ AS += -EL LD += -EL endif +# +# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and +# later may result in code being generated that handles signed short and signed +# char struct members incorrectly. So disable it. +# (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932) +# +KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra) + # This selects which instruction set is used. # Note that GCC does not numerically define an architecture version # macro, but instead defines a whole series of macros which makes