[macstl-dev] gcc 3.3 on YellowDogLinux
glen.low at pixelglow.com
Sun Apr 3 13:02:45 WST 2005
On 01/04/2005, at 9:40 PM, Michael LeBlanc wrote:
>>> Unfortunately it still traps at run-time.
>> Need to determine where the trap happens. Does YDL (1) turn Java
>> mode on or off, (2) have denormal handlers? (if either Java mode
>> is on OR you don't have denormal handlers, then the problem lies
>> somewhere else. What kind of trap, which line of code etc.)
> I have been trying test/benchmark and isolated the fault to the
> destructor of the "stdext" phase of each sub-benchmark. Without
> that, it runs to the end. Did I just comment out the Altivec test?
Interesting. How did you disable the destructor, since it would be
triggered anyway by implicitly called code? The destructor in the
stdext phase implicitly calls the stdext::valarray destructors, which
ends up calling free on the malloc'ed data. Off the top of my head,
it could be that malloc on YDL doesn't align on 16 bytes and free
looks at some info stored before the allocated block, hence the crash
On Mac OS X, malloc returns 16-byte aligned blocks and there doesn't
seem any other low-level way of getting aligned blocks (except
perhaps using VM functions). On OS 9 there used to be a vec_malloc
and Windows (and other MMX supporting OS) has _mm_alloc.
pixelglow software | simply brilliant stuff
More information about the macstl-dev