On Tue, 23 Sep 2008, Maurilio Longo wrote:
Hi Maurilio,
> I'm not able to get a stack dump :( (it's a long story, gdb is not up to date
> with the rest of the GCC tool chain I'm using)
> But I've found that the problem comes from rt_hvma.prg lines 191 and 192
> (commented as operators precedence).
> If I comment them the build goes on, If I uncomment just one of them (it does
> not matter which one) I get the SIGFPE.
> I'm still trying to find a way to have a back trace and/or a map file sice I
> have the cp:eip of the SIGFPE.
And this is an answer.
These two line have math epression:
1 + 2 * 3 / 4 - 2 ** 2 ^ 3
which is fully optimized by compiler at compile time.
But to calculate the result compiler have to call pow()
function and here we probably have GPF. AFAIR from your
older messages in OS2 math operation on wrong data
produces FPE. It's probably C compiler and/or OS version
dependent so David does not have this problem but you
you have just exploited stupid typo in POWER operator
optimization. In expropt2.c[367] we have unnecessary
redundant two line I had to copy by mistake from
expropt2.c[357]:
pSelf->value.asNum.val.d = pow( pLeft->value.asNum.val.d,
pRight->value.asNum.val.d );
I guess that if you remove it then all will work correctly.
Please confirm. I'll commit this fix ASAP.
One of the above value is nor double value by HB_LONG and is
passed to pow() without conversion so it may give wrong IEEE758
double value which causes SIGFPE. It's also possible that
If you are using HB_LONG_LONG_OFF and 32bits in this value
are undefined at all (random) and David doesn't so in this
test they are always 0 and whole number does not cause FPE
exception.
Many thanks for your tests and help.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
