From owner-svn-src-head@FreeBSD.ORG Fri Jul 2 22:16:40 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACCDA1065670; Fri, 2 Jul 2010 22:16:40 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6812D8FC08; Fri, 2 Jul 2010 22:16:40 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id o62MGdiU031428; Fri, 2 Jul 2010 18:16:39 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id o62MGcWD031427; Fri, 2 Jul 2010 18:16:38 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 2 Jul 2010 18:16:38 -0400 From: David Schultz To: Marcel Moolenaar Message-ID: <20100702221638.GA31280@zim.MIT.EDU> Mail-Followup-To: Marcel Moolenaar , Bruce Evans , Marcel Moolenaar , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201006300140.o5U1eQVG097566@svn.freebsd.org> <20100630184517.B51465@delplex.bde.org> <79DD181D-3885-45F5-9E9D-753553D19891@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79DD181D-3885-45F5-9E9D-753553D19891@mac.com> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, Marcel Moolenaar , src-committers@FreeBSD.ORG, Bruce Evans Subject: Re: svn commit: r209604 - head/lib/libc/gmon X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:16:40 -0000 On Wed, Jun 30, 2010, Marcel Moolenaar wrote: > >> s_scale = ((float)p->kcountsize / o ) * SCALE_1_TO_1; > > > > I can't see any bugs in this expression. p->kcountsize is < o, and the > > scale factor is only 65536, so there should be no problems with overflow. > > This leaves GCC a the problem. What does the generated assembly look like, and what are the inputs that screw up? PowerPC doesn't have an instruction to convert integer types to floats, so that's done in software. The hardest/most esoteric is the conversion from a 64-bit int to a float (as above with kcountsize), so it wouldn't be surprising if that's buggy.