From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119328 invoked by alias); 28 Nov 2017 18:06:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 119266 invoked by uid 89); 28 Nov 2017 18:06:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=designers, tale, wish X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Nov 2017 18:06:46 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D823E6014F; Tue, 28 Nov 2017 18:06:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-12.rdu2.redhat.com [10.10.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTP id B94415D972; Tue, 28 Nov 2017 18:06:43 +0000 (UTC) Subject: PUSH_ROUNDING To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <871sltvm7r.fsf@linaro.org> <87r2ttepfk.fsf@linaro.org> <87wp2awaex.fsf@linaro.org> From: Jeff Law Message-ID: <628c2ffc-a628-4d81-eca1-9b6fac9a2a77@redhat.com> Date: Tue, 28 Nov 2017 18:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87wp2awaex.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02451.txt.bz2 On 11/28/2017 11:00 AM, Richard Sandiford wrote: > Jeff Law writes: >> >> I so wish PUSH_ROUNDING wasn't needed and that folks could at least keep >> their processors consistent (I'm looking at the coldfire designers :(. >> For a tale of woe, see BZ68467. > > Ouch. Is this also fallout from having different code for libcalls > and normal calls? That always seemed like an accident waiting to > happen, but I don't remember seeing cases where it caused actual ABI > breakage before. Yup. Essentially the caller uses a libcall interface where promotions are not occurring, but there's no way to describe that at the source level to the implementation of the libcall and the implementation thus expects the usual argument promotions. At least that's how it looked when I started poking a bit. At that point, I had to stop as I couldn't justify the time to dig further for an m68k issue... > > Thanks as ever for the reviews :-) You're welcome. Still lots to do, but at least some progress whittling it down. jeff