[macstl-dev] gcc 3.3 on YellowDogLinux

Glen Low glen.low at pixelglow.com
Sun Apr 3 13:02:45 WST 2005

  • Previous message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Next message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


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  
during free.

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.

Cheers,
Glen Low


pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen





  • Previous message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Next message: [macstl-dev] gcc 3.3 on YellowDogLinux
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the macstl-dev mailing list