Problem with PowerPC Altivec engine

I'm getting occasional bad outputs on my Mac iBook when minting 29 bit
coins with a long resource name.  This is for my rpow.net project which
uses a fixed resource name of 71672bc400000017-000003c2-0001.rpow.net.

Here is a sample GOOD output:

./hashcash -m -b 29 -r 71672bc400000017-000003c2-0001.rpow.net
hashcash token: 1:29:050131:71672bc400000017-000003c2-0001.rpow.net::TP+l7rpzbtJoqygB:000000000000000000000HJZop

Here is a sample BAD output:

./hashcash -m -b 29 -r 71672bc400000017-000003c2-0001.rpow.net
hashcash token: 1:29:050131:71672bc400000017-000zFsHIgwYn9MnogZF:0000000000000000000000000000000000000000007/FQn

You will notice that it's not well formed, there are only 4 colons rather
than 6.

It fails about one time in 5 or so.

This test was done compiling with no optimization, because I thought
the Mac's optimizer might be having problems.  The Mac gcc compiler
actually gets an internal compiler error when compiling with -O3 on
fastmint_altivec_standard_2.c, so I compile that one manually without
optimization.  That one is in fact the core that is used on my Mac,
but I have tried some tests forcing the use of other cores, and it
appears that all of the Altivec-based cores show the same problem of
occasional failures.

I have not seen it fail when generating stamps of less than 29 bits.
I haven't tried for larger sizes.  I'm also not sure if the long resource
string makes a difference, but I note that the stamp format is somewhat
different for short resource strings, so maybe it does.

Another odd thing is that sometimes in the past with flaky cores, I
would see an error like "requested 29, reported 30, actual value 0".
This made me think that something in the code was testing the value
returned from the libfastmint.  But in this case no such error occurs
even though the string is totally bogus.  I don't know whether the error
testing is not always done, or whether this indicates that the corruption
occurs after a test said it was valid.

Hal Finney