similar to: [LLVMdev] linux mixed 32/64 systems

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] linux mixed 32/64 systems"

2009 Mar 10
0
[LLVMdev] linux mixed 32/64 systems
On 10/03/2009, at 1:25 PM, Nick Lewycky wrote: > Currently the build systems sets ARCH based on the result of 'uname - > m'. > On a mixed 32/64 system (one with a 64-bit kernel and a 32-bit > userspace) this will result in "x86_64" which is wrong. > > We'd like the ARCH variable to represent the userspace we're compiling > in/for, not what the
2004 Oct 21
3
1.0-test51
http://dovecot.org/test/ This release is built with autoconf 2.59 and libtool 1.9. We'll see how it works out :) The required changes were done by Matthias Andree. - The last fix for connection hanging made IDLE use 100% CPU - We don't use Maildir/.INBOX/ directory anymore, indexes are stored in Maildir-root - Don't crash with FETCH BODY[n.MIME] - Changed %p (protocol)
2012 May 03
2
Portablility patch for openssh 6.0p1 configure.ac
The following patch corrects a portablility issue when compiling openssh 6.0p1 on MirOS (aka. mirbsd). The issue is: sftp-server.c: In function `send_statvfs': sftp-server.c:510: error: request for member `val' in something not a structure or union sftp-server.c:510: error: request for member `val' in something not a structure or union The patch is: --- configure.ac.orig 2012-04-19
2015 Apr 08
10
Build-system cleanups
Hi everyone Following are a number of build-system cleanup patches. Some of them are prep-work for a possible upcoming automake/gnulib introduction. Best regards, Tiziano
2014 Jun 21
1
[PATCH 1/2] glamor: fix build without glamor.h
xorg-server can be built without glamor, which leads to: CC nouveau_xv.lo In file included from nouveau_xv.c:41:0: nouveau_glamor.h:12:20: fatal error: glamor.h: No such file or directory compilation terminated. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- configure.ac | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configure.ac
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
2011 Dec 02
2
[LLVMdev] deglobalizing TargetOptions
On 1 December 2011 17:15, Chris Lattner <clattner at apple.com> wrote: > > On Dec 1, 2011, at 5:09 PM, Nick Lewycky wrote: > >> I'm running LLVM under threadsanitizer >> (http://code.google.com/p/data-race-test/) to find and remove races in >> a larger program that uses LLVM as a library. One of the things that I >> found is that the TargetOptions are all
2008 Jun 26
2
[LLVMdev] Compile llvm-gcc-4.2 on sparc-sun-solaris2.10
On 20/06/2008, at 3:22 PM, Chris Lattner wrote: > > On Jun 16, 2008, at 2:12 PM, heguojin at ict.ac.cn wrote: > >> Has anyone succeded ? > > This sounds like the sparc backed doesn't have inline asm support, > which isn't a surprise. I'd suggest disabling bootstrapping. That was going to be my guess (PR1557 I think it is). If I get some spare cycles in the
2010 Feb 09
3
[LLVMdev] How to check for "SPARC code generation" in MachineBasicBlock.cpp?
On 09/02/2010, at 3:57 AM, Chris Lattner wrote: > On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: >> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is the responsibility of AnalyzeBranch and friends that you mention). > > Right. Implementing AnalyzeBranch will allow a bunch of block layout and branch optimizations to happen. > >> However I still
2012 Sep 10
10
[PATCH] mem_event: fix regression affecting CR3, CR4 memory events
This is a patch repairing a regression in code previously functional in 4.1.x. It appears that, during some refactoring work, calls to hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost. These functions were originally called in mov_to_cr() of vmx.c, but the commit http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the original code into generic functions up a level in
2014 Dec 09
1
[RFC PATCH v2] armv7: celt_pitch_xcorr: Introduce ARM neon intrinsics
Viswanath Puttagunta wrote: > + SUMM = vdupq_n_f32(0); It kills me that there's no intrinsic for VMOV.F32 d0, #0 (or at least I couldn't find one), so this takes two instructions instead of one. > + /* Consume 4 elements in x vector and 8 elements in y > + * vector. However, the 8'th element in y never really gets > + * touched in this loop. So, if len == 4,
2010 Mar 23
0
[LLVMdev] LLVM on Solaris/Intel?
On 21/03/2010, at 10:38 PM, Skip Montanaro wrote: >> I don't know anything about Solaris, but your paste doesn't actually >> contain any errors, just warnings (unless I'm reading "ld: warning: >> relocation error:" wrong). It might help to run make without -j until >> it fails, and then use `make VERBOSE=1` to print the exact commands >>
2008 Jun 13
2
[LLVMdev] Type conflicts with linkonce functions
Hi, Currently if the linker encounters a pair of linkonce function definitions with different types, it raises an error of the form: llvm-ld: error: Cannot link file 'item.o.bc': Function '_ZN18st_select_lex_unit12first_selectEv' defined as both ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)' and ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)'
2010 Feb 03
4
[LLVMdev] [patch] SPARCV9 subtarget support
Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on
2011 Dec 02
0
[LLVMdev] deglobalizing TargetOptions
On Dec 1, 2011, at 5:23 PM, Nick Lewycky wrote: >> Instead of adding a bunch of instance variables (+ getters/setters) into TargetMachine, why not make TargetOptions be a class, and have TM contain an instance of it? > > That works too, it makes little difference to me. One reason is that > most references to these globals are inside classes that derive from > TargetMachine so I
2014 Dec 07
2
[RFC PATCH v2] cover: armv7: celt_pitch_xcorr: Introduce ARM neon intrinsics
Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv1: - Rebased on top of commit aad281878: Fix celt_pitch_xcorr_c signature. which got rid of ugly code around CELT_PITCH_XCORR_IMPL passing of "arch" parameter. - Unified with --enable-intrinsics used by x86 - Modified algorithm to be more in-line with algorithm in celt_pitch_xcorr_arm.s Viswanath Puttagunta
2009 Sep 11
2
[PATCH] Add echo_daemon command
echo_daemon is a simple echo which can be used to test connectivity between the client and daemon. --- daemon/Makefile.am | 1 + daemon/echo_daemon.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++ daemon/m4/stddef_h.m4 | 45 +++++++++++++++++++++++++++++++++ po/POTFILES.in | 1 + src/MAX_PROC_NR | 2 +- src/generator.ml | 7 +++++ 6 files changed,
2010 Mar 21
3
[LLVMdev] LLVM on Solaris/Intel?
> I don't know anything about Solaris, but your paste doesn't actually > contain any errors, just warnings (unless I'm reading "ld: warning: > relocation error:" wrong). It might help to run make without -j until > it fails, and then use `make VERBOSE=1` to print the exact commands > it's running. Sorry. There was so much output I wasn't sure how much
2017 Jul 13
3
[PATCH supermin v2] ext2: Create symlinks properly (RHBZ#1470157).
The ext2 filesystem on disk format has two ways to store symlinks. For symlinks >= 60 bytes in length, they are stored as files (so-called "slow symlinks"). For shorter symlinks the symlink is stored in the inode ("fast symlinks"). Previously we only created slow symlinks even if they are shorter than 60 bytes. This didn't matter until recently, when a change went
2017 Jul 12
3
[PATCH supermin] ext2: Create symlinks properly (RHBZ#1470157).
The ext2 filesystem on disk format has two ways to store symlinks. For symlinks >= 60 bytes in length, they are stored as files (so-called "slow symlinks"). For shorter symlinks the symlink is stored in the inode ("fast symlinks"). Previously we only created slow symlinks even if there are shorter than 60 bytes. This didn't matter until recently, when a change went