Date: Mon, 23 Feb 1998 12:41:18 -0800 From: Mike Smith <mike@smith.net.au> To: Jon Loeliger <jdl@jdl.com> Cc: hackers@FreeBSD.ORG Subject: Re: My Compiler Confusion Message-ID: <199802232041.MAA12305@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 23 Feb 1998 10:19:26 CST." <199802231619.KAA01344@chrome.jdl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <some compiler file>. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802232041.MAA12305>