Broken ghc-7.0.3/vector combination?

[Dan Doel]

On Wed, Apr 20, 2011 at 3:01 PM, Daniel Fischer
<daniel.is.fischer at googlemail.com> wrote:
> I'm sure it's not criterion, because after I've found that NaNs were
> introduced to the resamples vectors during sorting (check the entire
> vectors for NaNs before and aftersorting, tracing the count; before: 0,
> afterwards often quite a number, sometimes close to 10%), the further tests
> didn't involve criterion anymore. criterion is simply the most obvious
> place to see the NaNs show up (with 5-10% NaNs among the resamples, it
> won't take too long to see one pop up).
>
> It could be a bug in statistics, but I'm pretty sure this one's not due to
> statistics either, since fiddling with vector-algorithms made the NaNs
> disappear - btw., Bryan, using the heap sort instead of introsort, I
> haven't found any NaNs in my tests, so temporarily switching the algorithm
> might cure the symptoms.

It's not a statistics bug. I'm reproducing it here using just vector-algorithms.

Fill a vector of size N with [N..1], and (intro) sort it, and you get
NaNs. But only with -O or above. Without optimization it doesn't
happen (and nothing seems to be reading/writing out of bounds, as I
compiled vector with UnsafeChecks earlier and it didn't complain).

Filling the vector with [1..N] also doesn't trigger the NaNs. [0,0..0]
and [0,0..1] trigger it.

I don't know what's going on yet. I have trouble believing it's a bug
in vector-algorithms code, though, as I don't think I've written any
RULEs (just INLINEs), and that's the one thing that comes to mind in
library code that could cause a difference between -O0 and -O. So I'd
tentatively suggest it's a vector, base or compiler bug.

The above testing is on 64-bit windows running a 32-bit copy of GHC,
for reference.

My ability to investigate this will be a bit limited for the near
future. If someone definitively tracks it down to bugs in my code,
though, let me know, and I'll try and push a new release up on
hackage.

-- Dan