|
Message
From: Balint Cristian<cristian.balint@o...>
Date: Mon Feb 21 09:15:22 CET 2005
Subject: [openrisc] x86_64 linux [more&more]
Hi Matiaz !
> this is an interesting diff between i386 and x86-64 generated assembly...
> the 268435456 just happens to be 0x10000000, so it's the upper part of
No, it takes the whole 64 bit part, not just the upper or lower.
> 1152921504606846976. My really wild guess would be that some code assumes
> target register size = host register size...
Yes, something like. Would be nice to know where, and to constrain this to 32 bit lower part,
and ignore in rest. Who write these piece of code in /or32 ?
Matjaz, what was this diff you send lower:
> - l.movhi r3,hi(.LC1) # move immediate (high)
> - l.ori r3,r3,lo(.LC1) # move immediate (low)
> +.L318:
> + l.or r13, r0, r0
> + l.movhi r14, hi(1152921504606846976)
^^^^^^^^^^^^^^^^^^^ this is whole 64 bit,
If have idea how to force lower 32 bit will be a solution at last.
Unfortunatley in gdb the hardware watchpoint to trace modif of some location not work
so i dont know where is exactly the code piece.
I work with sparc32/sparc64 arm and hppa on 3.4.3 compiler so i guess the compiler is ok something
is missdeclared in gcc/config/or32 part.
I diffed 3.4.2-ork1 vs 3.4.2-vannila and applied to latest 3.4.3 gcc, the same symptoms appear.
I will retake my analisys and study a little bit whats happening in the or32 folder, specialy in or32.h
If anyone still have some more idea, please help out.
> + l.ori r14, r14, lo(1152921504606846976)
> best regards,
> p.
thank you,
~cristian
--
Cristian Balint
Romania Data Systems SA - filiala Oradea
Departamentul Tehnic
➧ str. Independentei nr. 24, Oradea
tel. + 40-259-447.252
fax. + 40-259-467.440
➧ email: cristian.balint@o...
suport@r...
➧ http://www.rdsnet.ro
|
 |
Browse
