From owner-freebsd-hackers Mon Feb 23 12:42:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09491 for freebsd-hackers-outgoing; Mon, 23 Feb 1998 12:42:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09486 for ; Mon, 23 Feb 1998 12:42:41 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA12305; Mon, 23 Feb 1998 12:41:19 -0800 (PST) Message-Id: <199802232041.MAA12305@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jon Loeliger cc: hackers@FreeBSD.ORG Subject: Re: My Compiler Confusion In-reply-to: Your message of "Mon, 23 Feb 1998 10:19:26 CST." <199802231619.KAA01344@chrome.jdl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Feb 1998 12:41:18 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I confess, I need some help in figuring out just what is > really going on during the compilation of a trivial routine. > I suspect that I have an odd floating point mode set on > my FreeBSD box, but I'm not sure. You're close, I think. > Under FreeBSD now, gcc gives: > - Warning: > bug1.c:7: warning: overflow in implicit constant conversion Correct warning. > - Bad code: > > _main: > pushl %ebp > movl %esp,%ebp > call ___main > movl $0,_k Correct code, according to the standard. > Now here's the cool one. Under FreeBSD, the Black Box Compiler: > - Warning: > "bug1.c", line 7: warning: floating-point value does not fit in > required integral type > > Signal: SIGFPE in . line 7 The BB compiler is apparently trying to use the default behaviour of whatever it was bootstrapped with on the given platform to produce the "platform normal" translation of a floating value to an integer. Or something similar, at any rate I would expect that the BB compiler is not masking the FP exceptions that relate to loss of prceision. You should examine the source of the BB compiler and the fpsetmask(2) manpage, and make such adjustments are are required. > The code that the compiler is executing when this woofing happens > looks, in part, like this: > > typedef struct { > int tc_type; > union { /* Whole buncha irrelevant fields in here too. */ > struct { > int v0, v1, v2, v3; > } ival; > float fval; > } vals; > } TC; > > BOOL > is_full_number(TC tc, int *i) > { > int k; > float s; > > switch (tc.type) { > > case TC_R4: > k = tc.vals.fval; > s = k; > if (s == tc.vals.fval) { > *i = k; > return TRUE; > } > return FALSE; > > OK, clearly, the intent here is to somehow determine if the float > and integer representation of a number in TC look the same after > being converted from float, to integer, and back to a float. > We lose it on that k = tc.vals.fval statement, as that is where > the implicit cast to integer happens. Like I said. 8) > > The questions now... > > Why is the Floating point exception happening only on my FreebSD system? > Is there some FP mode somewhere that I don't know about or don't > know how to set for the system or a specific process? And which I > might then set to a specific mode near the bbc's startup under FreeBSD? See above inre: fpsetmask. > What are they(*) _really_ trying to do with that cast-cast-compare code? > ((*) I am not the original author of this Work of Art...) See above inre: platform-normal behaviour. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message