Hello,
I'm using clang on x86 cross build for mips, here is my main configure
parameters
llvm/configure \
--prefix=/usr \
--target=mipsel-unknown-linux-gnu \
--enable-targets=mips \
--enable-optimized \
--enable-shared \
--disable-assertions
I want to build code for *mips3* with *o32* abi, but fails:
mipsel-unknown-linux-gnu-clang++ test.cpp -mips3
/tmp/test-a51985.s: Assembler messages:
/tmp/test-a51985.s:11: Warning: `fp=64' used with a 32-bit ABI
/usr/local/bin/mipsel-unknown-linux-gnu-ld: Warning: a.out uses
-mdouble-float (set by
/opt/toolchain_clang/host/usr/mipsel-unknown-linux-gnu/sysroot/usr/lib/../lib/crt1.o),
/tmp/test-d48db1.o uses -mgp32 -mfp64
How can I change the *fp=64* to *fp=32*? Have tried pass -mfp32 to
mipsel-unknown-linux-gnu-clang++ but with no luck.
Though this is a warning, but it fails to compile Qt.
Yes I known it works if uses *-mips64* etc, but I need mips3.
Please let me know if I'm post to the wrong place, I'm new here.
Thank you.
--
*Regards*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150611/0fcd6366/attachment.html>
Hi, I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken at the moment, it's one of the very long-standing issues I'm working towards. The main problem is that a lot of the internals of the Mips LLVM backend derive their behaviour from the target CPU rather than the target ABI. In theory, the combination of mips3 and O32 is valid and should generate code pretty much the same way as mips2 and O32 does. In the current implementation, the fact that mips3 has 64-bit GPR's tells a lot of the code generator to use 64-bit instructions and selects other behaviour that is correct for the N32/N64 ABI's but not for O32. For this (and many other) reasons, there's an assertion that O32 is not used on a 64-bit CPU. Any patches that make progress on this will be warmly welcomed. In the meantime, the best I can suggest is to target mips2 and O32. That combination will work and will do the same thing (aside from the precise ELF header flags) as mips3 and O32 would.> How can I change the fp=64 to fp=32? Have tried pass -mfp32 to mipsel-unknown-linux-gnu-clang++ but with no luck.In the current implementation, this is not possible. This also raises a point I haven't considered yet. The Mips3 architecture mandates that the FPU implementation is 64-bit, but if you're generating O32 code should we treat it as being a 32-bit FPU? I suspect we should since it matches the treatment of GPR's.> Yes I known it works if uses -mips64 etc, but I need mips3.I'd be surprised if mips64 and O32 works. It's subject to the same problems as mips3 and O32. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Weitian Leung Sent: 11 June 2015 04:43 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] How to pick default floating point ABI? Hello, I'm using clang on x86 cross build for mips, here is my main configure parameters llvm/configure \ --prefix=/usr \ --target=mipsel-unknown-linux-gnu \ --enable-targets=mips \ --enable-optimized \ --enable-shared \ --disable-assertions I want to build code for mips3 with o32 abi, but fails: mipsel-unknown-linux-gnu-clang++ test.cpp -mips3 /tmp/test-a51985.s: Assembler messages: /tmp/test-a51985.s:11: Warning: `fp=64' used with a 32-bit ABI /usr/local/bin/mipsel-unknown-linux-gnu-ld: Warning: a.out uses -mdouble-float (set by /opt/toolchain_clang/host/usr/mipsel-unknown-linux-gnu/sysroot/usr/lib/../lib/crt1.o), /tmp/test-d48db1.o uses -mgp32 -mfp64 How can I change the fp=64 to fp=32? Have tried pass -mfp32 to mipsel-unknown-linux-gnu-clang++ but with no luck. Though this is a warning, but it fails to compile Qt. Yes I known it works if uses -mips64 etc, but I need mips3. Please let me know if I'm post to the wrong place, I'm new here. Thank you. -- Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150612/fc00e2df/attachment.html>
On 06/12/2015 07:12 PM, Daniel Sanders wrote:> > Hi, > > I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken > at the moment, it's one of the very long-standing issues I'm working > towards. The main problem is that a lot of the internals of the Mips > LLVM backend derive their behaviour from the target CPU rather than > the target ABI. In theory, the combination of mips3 and O32 is valid > and should generate code pretty much the same way as mips2 and O32 > does. In the current implementation, the fact that mips3 has 64-bit > GPR's tells a lot of the code generator to use 64-bit instructions and > selects other behaviour that is correct for the N32/N64 ABI's but not > for O32. For this (and many other) reasons, there's an assertion that > O32 is not used on a 64-bit CPU. > > Any patches that make progress on this will be warmly welcomed. In the > meantime, the best I can suggest is to target mips2 and O32. That > combination will work and will do the same thing (aside from the > precise ELF header flags) as mips3 and O32 would. > > > How can I change the *fp=64* to *fp=32*? Have tried pass -mfp32 to > mipsel-unknown-linux-gnu-clang++ but with no luck. > > In the current implementation, this is not possible. > > This also raises a point I haven't considered yet. The Mips3 > architecture mandates that the FPU implementation is 64-bit, but if > you're generating O32 code should we treat it as being a 32-bit FPU? I > suspect we should since it matches the treatment of GPR's. > > > Yes I known it works if uses *-mips64* etc, but I need mips3. > > I'd be surprised if mips64 and O32 works. It's subject to the same > problems as mips3 and O32. > >Hi,> the best I can suggest is to target mips2 and O32It's not work for all, still get Assembler messages error on some source files> Warning: float register should be even, was 7> I'd be surprised if mips64 and O32 works.I mean compile the code only, since running the application with buggy GUI. :-( -- /Regards/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/bb1144d7/attachment.html>