From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64121 invoked by alias); 4 Feb 2016 22:04:40 -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 64110 invoked by uid 89); 4 Feb 2016 22:04:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=ebotcazouadacorecom, ebotcazou@adacore.com, richard.guenther@gmail.com, richardguenthergmailcom X-HELO: mail-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 22:04:38 +0000 Received: by mail-wm0-f54.google.com with SMTP id p63so2336725wmp.1 for ; Thu, 04 Feb 2016 14:04:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=yRCqSvV/cNdCzLN5e4mlXnpGnOdWz28f6ZS/8YT8dgM=; b=gXc9zGA9xebbx4xcLmhV0E4o1xwmKhkEFuUDOgkGYRz2qNKUkawQH/rpPI/IAOXH7Z oa+z7qmkC8v638KwnFjvqaR6V2hJgLTshJrUqO3NMhB0TWIXivsO/F4Jks9dDwCspF3P qpY9kscDVqPSOYmS2rHl02NXJeWoqYr52UozJKs4XOD/Wr+pABlKrdpJEgyrsV7tTgXU LQUm5MYfI6HwPpCuQizvJ3+K4aTANAnrDZfL5DVxne0/BQV/dvvCpcCPgBs+SCWsFJ7C WrBmQVm1RbnO5ucfM5YmEGsS6KV8WfwMg5NZyuhvAjz19kHdNUBqUteJv6Gm8BEbF1Mz p0FA== X-Gm-Message-State: AG10YOQYTToAPS/HYrO3R69jwSmCGhLxOgnMQ/6dWNUJphBt/CrJf/JrOafR0bC2FKhx5w== X-Received: by 10.194.103.2 with SMTP id fs2mr12294562wjb.36.1454623475667; Thu, 04 Feb 2016 14:04:35 -0800 (PST) Received: from android-4c5a376a18c0e957.fritz.box (p5B0E5281.dip0.t-ipconnect.de. [91.14.82.129]) by smtp.gmail.com with ESMTPSA id q75sm28220508wmd.6.2016.02.04.14.04.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 14:04:35 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <8737t8fcex.fsf@googlemail.com> References: <1454538638.3232.125.camel@ubuntu-sellcey> <1E4CE37C-986B-4DEB-A936-BA9A6C117A0B@comcast.net> <2455176.3K2QFyxiOu@polaris> <8737t8fcex.fsf@googlemail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs From: Richard Biener Date: Thu, 04 Feb 2016 22:04:00 -0000 To: Richard Sandiford CC: Eric Botcazou ,Mike Stump ,GCC Patches ,sellcey@imgtec.com,"Moore, Catherine" ,"Maciej W. Rozycki" ,Matthew Fortune Message-ID: <1615E2C0-6204-4F36-B639-CAA8DE6D9073@gmail.com> X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00369.txt.bz2 On February 4, 2016 9:28:22 PM GMT+01:00, Richard Sandiford wrote: >Richard Biener writes: >> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou > wrote: >>>> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, >rx, sparc, >>>> tilegx, tilepro or xtensa. >>>> :-( That’s one of the problems by having each port copy and paste >swaths of >>>> :code from other ports to express the same thing instead of ports >sharing >>>> :just one copy of code. My port is also broken in the same way >>>> :(currently). >>> >>> Yes, fixing a compiler bug by changing the ABI is a no-no, and the >argument of >>> the compatibility with LLVM has IMO little merit since it's a GCC >extension. >> >> True, but the compiler bug is in the backends - it just now gets >> exposed more easily >> (read: w/o user intervention). > >I'm still not convinced it's a backend/target bug though. It seems >like a similar situation to floats being promoted to doubles and >chars to ints when passed to unprototyped functions or varargs. >In those situations it's up to the hook to decide what type the >value actually gets passed as. Passing an overaligned int as a >plain int is pretty similar and isn't something that each target >should need to check individually. I agree here. BUT we are still effectively changing the ABI of each affected target then without actually knowing we do. I'd happily do such change in the middle-end if we identified all affected targets and verified the changes impact. That's a lot of work and thus having active targets follow the "arm way" of fixing the issue in the target is very reasonable in my opinion and the only thing I'd accept at this stage. Richard. >Thanks, >Richard