search for: xercesc

...hat doesn't obey the small restrictions that FPXX > enforces. Assuming, this is the cause –mfp32/-mfp64 should provide a > work around but I'd recommend updating the inline assembly since this > will make it easier to port to newer Mips processors. > > // Just tested with xercesc v3, got these warnings (sorry I said error message in last reply) > DOMNodeIDMap.s:134: Warning: float register should be even, was 1 > DOMNodeIDMap.s:134: Warning: float register should be even, was 1 > DOMNodeIDMap.s:136: Warning: float register should be even, was 1 > DOMNodeIDMap.s...

...; Furthermore, this raises another huge issue which is segregation of the LLVM header files. The practice for many open source projects today is to place all the header files in a directory that identifies the project. For example, when you include a Xerces header file, you do so with #include <xercesc/XYZ/File.h>. Similarly for ICU, we use #include <unicode/ucstring.h>. The same is true of many other packages, mine included. Unfortunately, it is not true of LLVM. Every #include in LLVm should look like: #include <llvm/Module/Header.h> As in #include <llvm/Support/support.h&gt...

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.