I'd like to suggest a higher bar than just pre-commit passing for any such commits going forward. The reason we disabled these in the first place is that there was at least some evidence they are buggy.
I'd suggest a minimal bar of running the core tests on at least ia32 and seeing a 100% pass. Ideally, a test should be run on core on both ia32 and a ppc platform. This will be required for the riskier optimizations. This will slow down re-enabling optimizations, but the alternative is to slow down all other forward development because we lose a whole iteration of test results to something that could have been caught before it was committed and thus make it harder to detect regressions introduced due to other (non-opt re-enablement) commits.
--dave
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
