We really should have GCC always return true for finite() I guess, since 
that's what the function does anyway, and then gcc could optimize correctly.

But it seems we need someone with knowledge of gcc to fix a number of 
issues that we have at the moment...
If just gcc would work right for us, then I think we should actually 
have a fairly good base at the moment for the VAX.

	Johnny

Anders Magnusson skrev:
> Heh, you found the bug!
> 
> If you add -fno-builtin when compiling that file then finite won't be 
> optimized
> away and it (probably) works, I have no machine to test on right now.
> 
> Someone with knowledge of gcc maybe can make gcc DTRT (or, at least, remove
> the finite() builtin)?
> 
> -- Ragge
> 
> Johnny Billquist wrote:
> 
>> I looked at the problems with top and family today, and located the 
>> problem.
>> In a way it's confusing that it exists, but I have an easy solution to 
>> it, anyway.
>>
>> The problem comes from the log() function in libm, and the code starts 
>> like this:
>>
>> ---
>>         if (x <= 0) {
>>                 if (_IEEE && x == zero) /* log(0) = -Inf */
>>                         return (-one/zero);
>>                 else if (_IEEE)         /* log(neg) = NaN */
>>                         return (zero/zero);
>>                 else if (x == zero)     /* NOT REACHED IF _IEEE */
>>                         return (infnan(-ERANGE));
>>                 else
>>                         return (infnan(EDOM));
>>         } else if (!finite(x)) {
>>                 if (_IEEE)              /* x = NaN, Inf */
>>                         return (x+x);
>>                 else
>>                         return (infnan(ERANGE));
>>         }
>> ---
>>
>> The interesting thing is, if you look at the produced code, it looks 
>> like this:
>>
>> ---
>> 00000228 <log>:
>>  228:   00 00           Entry mask 0x0000 = < >
>>  22a:   c2 04 5e        subl2 $0x4,sp
>>  22d:   70 ac 04 50     movd 0x4(ap),r0
>>  231:   73 50           tstd r0
>>  233:   15 0d           bleq 242 <log+0x1a>
>>  235:   dd 22           pushl $0x22
>>  237:   fb 01 ef c2     calls $0x1,0 <__log__D>
>>  23b:   fd ff ff
>>  23e:   6e 50 50        cvtld r0,r0
>>  241:   04              ret
>>  242:   73 50           tstd r0
>>  244:   13 0d           beql 253 <log+0x2b>
>>  246:   dd 21           pushl $0x21
>>  248:   fb 01 ef b1     calls $0x1,0 <__log__D>
>>  24c:   fd ff ff
>>  24f:   6e 50 50        cvtld r0,r0
>>  252:   04              ret
>>  253:   d2 21 7e        mcoml $0x21,-(sp)
>>  256:   fb 01 ef a3     calls $0x1,0 <__log__D>
>>  25a:   fd ff ff
>>  25d:   6e 50 50        cvtld r0,r0
>>  260:   04              ret
>> ---
>>
>> (all the three "calls $0x1,0" are really calls to infnan.)
>>
>> Which is rather interesting. Looking at the produced code, it appears 
>> that the test:
>>   if (!finite(x)) {
>> gets optimized away, and is assumed to always be true, so that branch 
>> is always taken. In effect, the log() function always returns infnan() 
>> right away. And infnan() on the vax is designed to always give an 
>> illegal instruction trap.
>>
>> Now, I haven't really understood how on earth gcc can think that 
>> finite() itself would always be false, but therein lies the problem. 
>> I've searched the whole source tree for macro definitions of finite 
>> without finding any. Anyway, adding the following line before the 
>> log() function in n_log.c fixes everything:
>>
>> #define finite(x) 1
>>
>> And, based on the code in n_support.c, finite() should always return 
>> true on a VAX.
>>
>> There are finite() calls in other pieces of code in noieee_src as 
>> well, but nothing else seems to be used by any code I've stumbled on 
>> so far, but this fix is applicable to all of those files.
>>
>> So this leaves us with one question:
>>
>> Why does gcc optimize away the call to finite()? Is there a built-in 
>> macro in gcc for this on the vax perhaps???
>>
>> After this fix, what's left is that gcc crash if you turn on any 
>> optimizations on the VAX. Someone who knows gcc needs to help out with 
>> this one. And we'd probably want the PIC ability back in gcc for VAX 
>> again, so that we can have shared libraries.
>>
>> Anyone feel like helping out? :-)
>>
>>     Johnny
>>
>