From owner-freebsd-toolchain@freebsd.org Mon Feb 15 21:20:07 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 1E421AA9CDB for ; Mon, 15 Feb 2016 21:20:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C48A119DF for ; Mon, 15 Feb 2016 21:20:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24410 invoked from network); 15 Feb 2016 21:20:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 21:20:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 15 Feb 2016 16:20:14 -0500 (EST) Received: (qmail 3732 invoked from network); 15 Feb 2016 21:20:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Feb 2016 21:20:14 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AC8FB1C43A8; Mon, 15 Feb 2016 13:20:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc From: Mark Millard In-Reply-To: <20160215201800.GA20796@vlakno.cz> Date: Mon, 15 Feb 2016 13:20:04 -0800 Cc: Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20160215201800.GA20796@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) 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 21:20:07 -0000 On 2016-Feb-15, at 12:18 PM, Roman Divacky wrote: >=20 > On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote: >> On 2016-Feb-15, at 11:11 AM, Roman Divacky = wrote: >>>=20 >>> Mark, I believe you're right. What do you think about this patch? >>>=20 >>> Index: tools/clang/lib/CodeGen/TargetInfo.cpp >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852) >>> +++ tools/clang/lib/CodeGen/TargetInfo.cpp (working copy) >>> @@ -3599,6 +3599,8 @@ >>> { >>> CGF.EmitBlock(UsingOverflow); >>>=20 >>> + Builder.CreateStore(Builder.getInt8(11), NumRegsAddr); >>> + >>> // Everything in the overflow area is rounded up to a size of at = least 4. >>> CharUnits OverflowAreaAlign =3D CharUnits::fromQuantity(4); >>>=20 >>>=20 >>> Can you test it? >>=20 >> It may be later today before I can start the the test process. >>=20 >> While your change is not wrong as presented, it does seem to be based = on the ABI document's numbering with the range 3 <=3D gr <12, where 3 <=3D= gr < 11 cover r3-r10 use and gr=3D11 implies overflow stack area use. = (gr being the ABI documents name.) >>=20 >> 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 <=3D gpr < 9, where 0 <=3D gpr < 8 = cover r3-r10 use and gpr=3D8 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. >>=20 >> So assigning any value that appears to be positive and >=3D 8 should = work, such as: >>=20 >> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr); >=20 > Can you check what number gcc uses? We want to be interoperable with = gcc. >=20 > Anyway, thanks for testing! >=20 > Roman I'll do that check of gcc 4.2.1 code generation before starting the test = later today. But if the clang numbering is different in gcc 4.2.1 then far more than = just adding a > Builder.CreateStore(Builder.getInt8(?), NumRegsAddr) for some "?" would need to be involved in the changes in order to reach = compatibility. I'll note that for clang 3.8.0 the actual comparison instruction = generated is of the form > cmplwi r?,7 for some r?, such as r5 or r4, and the conditional branch generated is a = bgt instruction. =3D=3D=3D Mark Millard markmi at dsl-only.net