Mikhail Loenko wrote:
2007/6/27, Vladimir Ivanov <[EMAIL PROTECTED]>:
On 6/27/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 6/27/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > Alexei Zakharov wrote:
> > > The reason of these failures lies in fdlibm indeed. Yes, it was
> > > tweaked to use "-O0" but there was a typo in this tweak and it does
> > > not affect the compilation. As a result fdlibm was compiled with
"-O1"
> > > as all other natives. I has created HARMONY-4287 and attached a
patch
> > > for this issue. The patch itself is trivial:
> > <snip>
> > >
> > > So I suggest to commit it and include into our M2 build. Waiting
for
> > > other committer's vote...
> >
> > A dumb question but does it fix the problem?
>
> I've run classlib tests with the patch applied and these failures
disappeared.
>
> > It's been like that since
> > r483045 (i.e. before M1). I'm surprised we didn't find it when
testing
> > that.
>
> I'm afraid but it looks like in M1 we relied on CC status - I created
> snapshots when all CCs were up (this includes classlib tests). And CC
> runs classlib tests on debug build so they passed.
>
> BTW, this is a good example for obtaining all milestone's results with
> the snapshot build.
Actually, this is a good example to show that we should test both:
release and debug builds while results can be different :)
I think we should create a mode which reveals most of the bugs.
E.g. something optimizing but with asserts. And use this mode for CC and
probably build snapshots in that mode.
To enable assertions in release in native code it is enough to disable
defining NDEBUG when building release.
--
Gregory
