From patchwork Tue Aug 15 20:56:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 801765 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=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-83191-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="sUIXjO8I"; 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 3xX4ZY6MxLz9sRW for ; Wed, 16 Aug 2017 06:58:29 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; q=dns; s=default; b=MFAnh3R o72rZeYeFE7mPukI1ly7ywdjOK/6KozE29BqHzoIE8pBopA7zpe0Zhgx53/K6W3W 02/iPwqZnrEz1h6BLIgJzeb72IPidySMWyau1qqkSLZTo3t13Cd918cSRhIri4mw PO5Af8RoZaNKJ7iWRaQ0KqUVwc/SNCq55490= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; s=default; bh=pl4enYF6F4/0G JNoP14AY2pmHYk=; b=sUIXjO8Iy2KrZ3mW6H+jsaNPqAIXlZAcE/lx4w5ENfnV+ aA2PBttkP9Ty50rFpZFjiHiOWdDotKF20FHoE3rUidjRf6vOrudSHE81+Jr3B6vm FkRwkVrWKq07LfjCFCDWFff0+aqUZwbf5z//KW1gDRiRbLoMZZs/XT16WfZEKU= Received: (qmail 91051 invoked by alias); 15 Aug 2017 20:56:37 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 77228 invoked by uid 89); 15 Aug 2017 20:56:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f47.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PtyR3UbP459TvyXFfnRptGYGPcqhIbXlc/4wB3ACJ8M=; b=Gben/2/XVD1a8j5y83BwVzl8EmNswMBm7zmq3BvYVAFX0YqvT68yaO4AB3XUJriR24 uxWXOK65g7gEFVw49Y0VAn9UjIeAsxcu1uwF+pagwxvHaIvA3+umQAlP2Vgf1wfxNhfh EsPyr2BAFX9ZKA0WRPiX/vErz4mwfBi/vmukt30hP5st/S2nYxDd+1ojwdBxdpH50xKZ uaKTT99EudJ3YVfyPdNrue61JH+gPdwT6JyaH3X1FERYAxXKp33I1dbrueum56CB7niB kjrgsWjNJHzFksBm8IQcH4RsQWfBbRS9hgP2oZkTYRQ5Uw+gSqF9N5e9EgvLqRM7w9aG AdTw== X-Gm-Message-State: AHYfb5giBAReltwi5ZLBL2YBfhLYOaS34+gwbCVswiNbp9uq+pBqFWuf s3DuTkumFOG+D6NpoFTfsm5lmiq7sw== X-Received: by 10.202.227.5 with SMTP id a5mr31439023oih.240.1502830576296; Tue, 15 Aug 2017 13:56:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: "H.J. Lu" Date: Tue, 15 Aug 2017 13:56:15 -0700 Message-ID: Subject: Fwd: [PATCH] x86-64: Align L(SP_RANGE)/L(SP_INF_0) to 8 bytes [BZ #21955] To: GNU C Library On Tue, Aug 15, 2017 at 1:28 PM, Joseph Myers wrote: > On Tue, 15 Aug 2017, H.J. Lu wrote: > >> On Tue, Aug 15, 2017 at 1:02 PM, Joseph Myers wrote: >> > On Tue, 15 Aug 2017, H.J. Lu wrote: >> > >> >> > [BZ #21955] >> >> > * sysdeps/x86_64/fpu/e_expf.S (L(SP_INF_0)): Place it in >> >> > .rodata.cst4 section. >> >> >> >> L(SP_RANGE) has the same issue. This updated patch fixes both. >> > >> > It's a lot more than just expf. There are various other x86_64 and x86 >> > libm files that could use .rodata.cstN but don't. (Obviously this only >> > works for invididual objects where the code doesn't use offsets from one >> > object to another, not when an array of two or more objects is being used >> > unless you choose the section appropriately to preserve the array as >> > such.) >> >> Aren't .rodata.cstN optimization? In case of e_expf.S, it is a correctness >> issue. > > They are generally optimization. > > Could you explain this correctness issue in more detail? SP_INF_0 appears > to be an array of two 4-byte values. Because it's used as an array, the > two values need to stay adjacent. That is, I'd expect it to need, for > correctness, to be in .rodata.cst8, as it is at present, and *not* > .rodata.cst4 (if in .rodata.cst4, it might get split up as those values > get unified with other values in that section). > After a closer look, the bug is .section .rodata.cst8,"aM",@progbits,8 ... .p2align 2 <<<<<< 4 byte aligned. Here is the new patch. OK for master? From 39245565fc0523eece29721c4590639ccebb6145 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Tue, 15 Aug 2017 10:34:22 -0700 Subject: [PATCH] x86-64: Align L(SP_RANGE)/L(SP_INF_0) to 8 bytes [BZ #21955] sysdeps/x86_64/fpu/e_expf.S has lea L(SP_RANGE)(%rip), %rdx /* load over/underflow bound */ cmpl (%rdx,%rax,4), %ecx /* |x|this bound, then result overflows */ .long 0x42cff1b4 /* if xthis bound, then result overflows */ .long 0x42cff1b4 /* if x