Forte 6u1 C compiler bug? Worse in 6u2?

Question

I have a rather large program containing a function which misbehaves intermittently with -xO3 optimization. The failure occurs on perhaps one run in ten.
A pointer variable local to the function appears to be corrupted by a call to another function. (It's ok before, and bad after the call.) The corrupted pointer value then usually causes a BUS error, rarely a SEGV (depending on its divisibility by 8, I assume).
Adding printf() calls showed the corrupt value (lately, 0x800000002 has been popular) using 6u1. After updating to 6u2, the intermittent corruption remains, but now the printf() itself fails, as it apparently tries to dereference the pointer (for some mysterious reason) instead of just displaying it. Dbx (6u2) says:
Read from unallocated (rua):
Attempting to read 1 byte at address 0x800000002
stopped in _doprnt at 0x7fef5189d54
0x000007fef5189d54: doprnt+0x0160:     ba,a    doprnt-0xda41c
(/opt/forte6u2/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
=>[1] _doprnt(0x100327630, 0xffffffff7fffefc0, 0x100327630, 0xff291400, 0x0, 0x0), at 0x7fef5189d54
[2] _fprintf(0x0, 0x800000002, 0x7fef52be228, 0x0, 0xffffffffffffffff, 0x100327db0), at 0x7fef518d088
[3] <my_stuff ...>
The (newly) offending statement looks like this:
fprintf( pfCFile, " a = %016lx.\n", assign);
where "assign" is the pointer to a structure of some sort.
Does anyone have any helpful hints or will I need to spend the $1599 to create an incident?

Answer 1

-xO2 is enough to cause the failure.
Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
My guess is over-eager register reuse, but I'm open to alternative theories.