On Fri, 21 May 2010, Khem Raj wrote:
On Fri, May 21, 2010 at 6:40 AM, Vitus Jensen <[email protected]> wrote:
On Fri, 21 May 2010, Vitus Jensen wrote:
On Fri, 21 May 2010, Vitus Jensen wrote:
On Wed, 19 May 2010, Koen Kooi wrote:
On 19-05-10 17:46, Vitus Jensen wrote:
On Wed, 19 May 2010, Vitus Jensen wrote:
On Wed, 19 May 2010, Gary Thomas wrote:
On 05/19/2010 03:38 AM, Vitus Jensen wrote:
...
So currently .dev should be unbuildable for ppc users? Without
selecting a non-default compiler that is.
I thought I pinned powerpc at 4.1.1, but it turns out that it was
only
for ppc405:
ANGSTROM_GCC_VERSION_ppc405 ?= "4.1.1"
Feel free to send patches to add that for other ppc platforms.
I'd loved to but it should be a usable version for ppc603e. We have
used
ELDK gcc 3.3.3 in the past so that version would be a known good one.
[stable/2009]
4.2.4 wrong result
4.1.1 wrong result (see first posting)
3.3.3 doesn't compile, obstack macro problem
3.3.4 doesn't compile, signal.h stack_t problem
[org.openembedded.dev]
4.3.3 doesn't compile
4.1.1 doesn't compile
4.2.4 doesn't compile, libstdc++ problem
All compilations in the .dev branch used MACHINE=n1200, in stable I used
our bluepro. Always a clean build of meta-toolchain. I know that there
are currently problems in .dev so I will wait/monitor the list and try
to get 3.3.3 and something newer than 4.3.3. to compile.
Faster than thought: 4.4.4 compiles for n1200 (ppc603e) on .dev and
produces correct output. (double)(long long)10 equals 10.0.
Only at -O2 and -O3, at those levels the internal function __floatdidf isn't
called (previously it was only -O3).
I dont think thats the case. It always generates the call to __floatdidf
Well, it generates the call to __floatdidf from inside cast() but that
function is never called from main but replaced with the precomputed
result. See attached assembler output, there is no call to _Z4castx.
At -O1 and below it is called and
still produces incorrect results :-( Oh well, I give up for now.
All I have to test is qemu running OE/ppc603e. So i tried this test on
qemu/uclibc and it seems to work for me at O1/O2/O3 using gcc 4.4.4 and
minimal-uclibc distro. I would also try with eglibc but I need to build
it.
Hmm, I'm using angstrom with glibc. And I'm testing on the real device
and saw that -mhard-float is implied by mcpu=603e. Using the FPU would
certainly explain differences between qemu and the real thing. But
__floatdidf is hard to understand, all macro. Is it really using the FPU?
Vitus
PS, to crosscheck: is there a HOWTO for qemu and oe/ppc? And qemu_0.12.4
doesn't build here.
--
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers
.file "cast.cpp"
.gnu_attribute 4, 1
.gnu_attribute 8, 1
.gnu_attribute 12, 2
.globl __floatdidf
.section ".text"
.align 2
.globl _Z4castx
.type _Z4castx, @function
_Z4castx:
.LFB12:
mflr 0
.LCFI0:
stwu 1,-16(1)
.LCFI1:
stw 0,20(1)
.LCFI2:
bl __floatdidf
lwz 0,20(1)
addi 1,1,16
mtlr 0
blr
.LFE12:
.size _Z4castx, .-_Z4castx
.align 2
.globl main
.type main, @function
main:
.LFB13:
mflr 0
.LCFI3:
lis 9,....@ha
stwu 1,-16(1)
.LCFI4:
lis 3,....@ha
lfs 1,....@l(9)
la 3,....@l(3)
li 5,0
li 6,10
stw 0,20(1)
.LCFI5:
creqv 6,6,6
bl printf
lwz 0,20(1)
li 3,0
addi 1,1,16
mtlr 0
blr
.LFE13:
.size main, .-main
.section .rodata.cst4,"aM",@progbits,4
.align 2
.LC2:
.4byte 1092616192
.section .rodata.str1.4,"aMS",@progbits,1
.align 2
.LC0:
.string "%lld == %f\n"
.section .eh_frame,"a",@progbits
.Lframe1:
.4byte .LECIE1-.LSCIE1
.LSCIE1:
.4byte 0x0
.byte 0x1
.globl __gxx_personality_v0
.string "zP"
.uleb128 0x1
.sleb128 -4
.byte 0x41
.uleb128 0x5
.byte 0x0
.4byte __gxx_personality_v0
.byte 0xc
.uleb128 0x1
.uleb128 0x0
.align 2
.LECIE1:
.LSFDE3:
.4byte .LEFDE3-.LASFDE3
.LASFDE3:
.4byte .LASFDE3-.Lframe1
.4byte .LFB13
.4byte .LFE13-.LFB13
.uleb128 0x0
.byte 0x4
.4byte .LCFI4-.LFB13
.byte 0xe
.uleb128 0x10
.byte 0x4
.4byte .LCFI5-.LCFI4
.byte 0x5
.uleb128 0x41
.uleb128 0xffffffffffffffff
.align 2
.LEFDE3:
.ident "GCC: (GNU) 4.4.4"
.section .note.GNU-stack,"",@progbits
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
