From owner-freebsd-toolchain@freebsd.org Mon Feb 15 20:20:24 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 216B5AAAD9D; Mon, 15 Feb 2016 20:20:24 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id DD95D101F; Mon, 15 Feb 2016 20:20:23 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id E45BD1E22EB6; Mon, 15 Feb 2016 21:18:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1455567480; bh=rapkILx3f5M4TmZ0s1vKsEqiopfGhNnZCBTHv/VIU+Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ByqJ/JcWoIRDCN2Rrft9gMprKYKaUjAkFpJbhF7P2bOT93b4+mGibd3+7tlt7k41g 6NV8Tm2TjNX6jjMXIsAlo+DJOYbB3KeH9Ans81vAkm6/1uriGgUzZTtedETHjhZLWl FJqe79MMITVYltGMTDE9moatc1YLTt8WWwhNJO58= Date: Mon, 15 Feb 2016 21:18:00 +0100 From: Roman Divacky To: Mark Millard Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc Message-ID: <20160215201800.GA20796@vlakno.cz> References: <20160214192903.GA96697@vlakno.cz> <70B405C4-E1AC-4F35-9786-051FDA2F8BE7@dsl-only.net> <20160215191100.GA17387@vlakno.cz> <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 20:20:24 -0000 On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: > On 2016-Feb-15, at 11:11 AM, Roman Divacky wrote: > > > > Mark, I believe you're right. What do you think about this patch? > > > > Index: tools/clang/lib/CodeGen/TargetInfo.cpp > > =================================================================== > > --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) > > +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) > > @@ -3599,6 +3599,8 @@ > > { > > CGF.EmitBlock(UsingOverflow); > > > > + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); > > + > > // Everything in the overflow area is rounded up to a size of at least 4. > > CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4); > > > > > > Can you test it? > > It may be later today before I can start the the test process. > > While your change is not wrong as presented, it does seem to be based on the ABI document's numbering with the range 3 <= gr <12, where 3 <= gr < 11 cover r3-r10 use and gr=11 implies overflow stack area use. (gr being the ABI documents name.) > > The clang code generation that I saw while analyzing the problem and the clang source that you had me look at did not use that numbering. Instead it seems to be based on 0 <= gpr < 9, where 0 <= gpr < 8 cover r3-r10 use and gpr=8 implies overflow stack area use. (gpr being what gdb showed me as I remember.) In other words: clang counts the number of "parameter registers" already in use as it goes along instead of tracking register numbers that have been used. > > So assigning any value that appears to be positive and >= 8 should work, such as: > > Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); Can you check what number gcc uses? We want to be interoperable with gcc. Anyway, thanks for testing! Roman