On Fri, 8 Jan 2010, Andrew Whitworth wrote:
> I've been trying to do some testing on some "exotic" platforms
> recently, and one issue I am running into consistently is the negative
> zero problem. Several platform/compiler combinations I have tried do
> not seem to have proper negative zero support, which causes parrot to
> fail several tests (several similar tests spread across several test
> files, which I find particularly annoying).
First and most importantly, are the tests actually testing desired
behavior? Last time I looked (quite some time ago) the actual desired
behavior for parrot wasn't specified.
The remainder of this message assumes that the tests are actually correct.
(A dangerous assumption, I know!)
> So the question I have is this: How do we go about fixing this problem
> for platforms where the math libraries don't handle negative zero the
> way we want? Do we add in runtime checks to all our arithmetic ops to
> ensure that we get negative zero values when we should? Runtime checks
> could be expensive for math-heavy programs. We could use preprocessor
> #ifdef sections to only insert these checks on platforms where it's
> known to be an issue, but we would need support from Configure.pl to
> detect this and define the macros properly. Is there another solution
> somewhere that I am not thinking about?
Some of the issues are discussed in TT #313 and in the many old RTs
referenced there. There is a config variable, but I do not know if
it is actually testing for the behavior that parrot actually wants.
In any case, the config variable should not be used to skip tests, but,
instead, should be used to incorporate appropriate code to ensure that
parrot operates as specified.
I can actually think of two separate possible issues. One is that a math
library may simply not correctly handle -0.0 and may inadvertantly lose
the sign. I don't think we can fix that easily, unless there's some
setting akin to the 'LIB_VERSION' stuff that works on some of the BSDs.
A second is that the value may be correctly represented internally, but
the sprintf() library function might not correctly render it. I thought
the patches in TT #313 were supposed to address the second problem (though
I also had thought they could have been more naturally handled in
src/spf_render.c instead).
Anyway, are you able to tell whether the problem is one of internal
representation or simply one of rendering?
--
Andy Dougherty [email protected]
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
