Attachment added by trac user mounir.lamouri on 2010-02-21: build.log

trac user JoseJX wrote on 2010-02-22

I've looked into this a little, here's some more info:

On a G4 (ppc32) gcc-4.4.3, G5 (ppc32/ppc64 userland) gcc-4.4.3, and a G5 (ppc64 userland) gcc-4.3.4, all use the IBM Long Double format, which actually is a pair of 64 bit longs, basically as shown in this document http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/128bit_long_double_floating-point_datatype.htm

I'm sure there's a document that describes it for Linux as well, but it's the same format. As far as I know it was made default some time around gcc-4.1.

@cournape wrote on 2010-02-23

Ok, so that's one new long double format to take into account. I am afraid it requires rewriting most of the code which depends on long double, so it may take some time before I or someone else implements it.

Milestone changed to Unscheduled by @cournape on 2010-02-23

trac user JoseJX wrote on 2010-02-23

Well, you could force the size of the long double to always be 64 bits using -mlong-double-64, but I'm not sure if that's an acceptable solution.

@cournape wrote on 2010-07-20

Forcing the long double type to be as the double type is not good, as it breaks the ABI, and it means every C library function will be broken when called with our long double type

Someone who cares needs to fix things for IBM long doubles. It isn't IEEE, so strictly speaking we don't need to support it.

there is a patch for ppc64 little endian support in ubuntus numpy package, but I guess this issue is about big endian?

I don't know. PPC devices could be either big or little endian as the PPC could go both ways, I don't recall what Apple used. But this is about the special form that IBM used for long doubles. The detection may even have been fixed, but I'd need to check to code to find out.

Judging by the last comments on #7836 this should be fixed for little endian. Apple was, I believe big endian and I don't know what the status of that is from actual report, but I think is should be OK.

The ppc problems are being pursued elsewhere, so closing this.