Displaying 5 results from an estimated 5 matches for "llvm_cv_llvmgcc_saniti".
Did you mean:
llvm_cv_llvmgcc_sanity
2010 Nov 12
0
[LLVMdev] LLVM test-suite support for dragonegg / Fortran
Hi Tobias,
> I committed an extended version of that patch to llvm core and the test suite.
> Can you have a look, if it works for you.
if I configure like this then the configure script thinks llvm-gcc is not
dragonegg:
configure --with-llvmgcc="gcc-4.5 -fplugin=path/dragonegg.so"
--with-llvmgxx="g++-4.5 -fplugin=path/dragonegg.so"
There are several reasons for
2010 Nov 10
2
[LLVMdev] LLVM test-suite support for dragonegg / Fortran
On 11/08/2010 03:18 PM, Duncan Sands wrote:
> Hi Tobias,
>
>> I am very interested in using dragonegg as a fortran frontend for the
>> LLVM test
>> suite, as a start to improve fortran support.
>>
>> I believe this should be easy, but when I looked into this I had the
>> impression
>> the nightly tester in the llvm test-suite does not even support
2009 Aug 18
0
[LLVMdev] Build issues on Solaris
Hello, Nathan
> or if it should be a configure test, which might be safer. Are there
> any x86 platforms (other than apple) that don't need PLT-indirect calls?
Yes, mingw. However just tweaking the define is not enough - we're not
loading address of GOT into ebx before the call (on 32 bit ABIs) thus
the call will be to nowhere.
--
With best regards, Anton Korobeynikov
Faculty of
2009 Aug 25
2
[LLVMdev] Build issues on Solaris
On 19/08/2009, at 4:00 AM, Anton Korobeynikov wrote:
> Hello, Nathan
>
>> or if it should be a configure test, which might be safer. Are there
>> any x86 platforms (other than apple) that don't need PLT-indirect
>> calls?
> Yes, mingw. However just tweaking the define is not enough - we're not
Ok, so configure might be the way to go then, maybe something
2009 Aug 11
6
[LLVMdev] Build issues on Solaris
Hi all,
I've encountered a couple of minor build issues on Solaris that
have crept in since 2.5, fixes below:
1. In lib/Target/X86/X86JITInfo.cpp, there is:
// Check if building with -fPIC
#if defined(__PIC__) && __PIC__ && defined(__linux__)
#define ASMCALLSUFFIX "@PLT"
#else
#define ASMCALLSUFFIX
#endif
Which causes a link failure due to the non-PLT