search for: _lp64

...++ compiler apparently has a #pragma which can be used to do it and gcc 4.3 seems to be happy with the hack described but as Duncan says trying to force this behavior in a union is probably less than desirable in the long term. Another ugly hack that I tried: union { uintptr_t V; #ifdef _LP64 SimpleValueType SimpleTyU[2]; # define SimpleTy SimpleTyU[1] #else SimpleValueType SimpleTyU[1]; # define SimpleTy SimpleTyU[0] #endif const Type *LLVMTy; }; This works on my big endian 64-bit system but I've not seen what damage it may do on other platform types. On 4/...

I have found that pid provider can not create memcpy:return probe for 64bit process on snv_110. For example, the pid is 10603, I will have following output for dtrace command: #dtrace -n pid10603:libc.so.1:memcpy:return dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: probe description pid10603:libc.so.1:memcpy:return does not match any probes This just

...erefore, we must use different expected + results based on what system we're on. We define both all the + time, but use the below pre-processor magic to select which + version we'll use. */ + uint8_t result_ilp32[MURMURHASH3_128_RESULTBYTES]; /* fits all results */ + uint8_t result_lp64[MURMURHASH3_128_RESULTBYTES]; /* fits all results */ +#ifdef _LP64 +#define result result_lp64 +#else +#define result result_ilp32 +#endif }; static void test_murmurhash3_algorithm(const char *name, @@ -29,24 +41,49 @@ static void test_murmurhash3_algorithm(const char *name, static void test...

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

I can't make R on a Solaris 9 box. Does anyone have any suggestions? Thanks in advance. <3>-> make `Makedeps' is up to date. `libbz2.a' is up to date. `Makedeps' is up to date. `libpcre.a' is up to date. `Makedeps' is up to date. `libz.a' is up to date. ../../../src/include/libintl.h is unchanged ../../../include/libintl.h is unchanged `localecharset.h'

Hi Aki, On 15:55 Mon 26 Mar , Aki Tuomi wrote: > On 26.03.2018 15:49, Apollon Oikonomopoulos wrote: > > Hi, > > > > The dovecot 2.3.0.1 Debian package currently fails to build on all > > big-endian architectures[1], due to murmurhash3 tests failing. The > > relevant output from e.g. s390x is: > > > > test-murmurhash3.c:22: Assert(#8) failed:

Hi Neale, > The comment in the above fix indicates that in this 64-bit system the enum > needs to be 64-bits is correct, but the fix doesn't seem to do it. the basic problem seems to be that your system compiler is miscompiling LLVM. Mucking around with the details of the union in the hope of tricking the compiler into not miscompiling is one approach, but as you saw each broken

Hello, > +static const uintptr_t minus_one = -1; -1 here is of signed int type. What if you will use -1ULL ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...haviour or not, but given the number of compilers it breaks it clearly needs to be changed. I'm not sure the enum needs to be an enum, how about turning it into a uintptr_t instead? Ciao, Duncan. > Another ugly hack that I tried: > > union { > uintptr_t V; > #ifdef _LP64 > SimpleValueType SimpleTyU[2]; > # define SimpleTy SimpleTyU[1] > #else > SimpleValueType SimpleTyU[1]; > # define SimpleTy SimpleTyU[0] > #endif > const Type *LLVMTy; > }; > > This works on my big endian 64-bit system but I've not seen what...

Fix more comment typos. On Solaris, #include <sys/isa_defs.h> to be sure _LP64 is defined in 64-bit builds. Fix some comment typos. CVS tag: xproto-7_0_5 6f287a54712dae74b62f1ec6b6e207ad xproto-7.0.5.tar.gz f47d90bd44e3809e0bdf8da87d27caa25b7f3f8d xproto-7.0.5.tar.gz 7ebf5b845817a867f2e4bdcabc33a257 xproto-7.0.5.tar.bz2 c4757c2051f5774fe35b0a6c7aa455ae684d6781 xproto-7...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 configure:17280: result: no configure:17300: checking for mblen configure:17356: gcc -o conftest -O3 -m64 -mtune=native -pipe -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset

...{ return readdir64(dirp); } The problem is that the "readdir64" result is type "dirent", not the samba- expected "dirent64". This is happening in the Solaris "dirent.h", where: . . . /* large file compilation environment setup */ #if !defined(_LP64) && _FILE_OFFSET_BITS == 64 #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname readdir readdir64 #else #define readdir readdir64 #endif #endif /* _FILE_OFFSET_BITS == 64 */ . . . causes: extern struct dirent *readdir(DIR *); to become: extern stru...

...013-08-18 12:08:11.086175660 +0000 @@ -2384,6 +2384,14 @@ Builder.defineMacro("__amd64"); Builder.defineMacro("__x86_64"); Builder.defineMacro("__x86_64__"); + if (PointerWidth == 64 && getLongWidth() == 64) { + Builder.defineMacro("_LP64"); + Builder.defineMacro("__LP64__"); + } else if (PointerWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else {...

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

...013-08-18 12:08:11.086175660 +0000 @@ -2384,6 +2384,14 @@ Builder.defineMacro("__amd64"); Builder.defineMacro("__x86_64"); Builder.defineMacro("__x86_64__"); + if (PointerWidth == 64 && getLongWidth() == 64) { + Builder.defineMacro("_LP64"); + Builder.defineMacro("__LP64__"); + } else if (PointerWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else {...

...> UINT32_MAX || - ds64.f_ffree > UINT32_MAX || ds64.f_favail > UINT32_MAX) + ds64.f_bavail > UINT32_MAX) + rescale_frsize(&ds64); + + if (ds64.f_blocks > UINT32_MAX || ds64.f_bfree > UINT32_MAX || + ds64.f_bavail > UINT32_MAX) return (EOVERFLOW); + #ifdef _LP64 /* * On the 64-bit kernel, even these fields grow to 64-bit

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Hi, so here it is, LZ4 compression method inside btrfs. The patchset is based on top of current Chris'' for-linus + Andi''s snappy implementation + the fixes from Li Zefan. Passes xfstests and stresstests. I haven''t measured performance on wide range of hardware or workloads, rather wanted to publish the patches before I get distracted again. I''d like to ask

...LZ4_uncompress_unknownOutputSize(s_start + 4, d_start, bufsiz, + d_len) < 0); +} + +/* + * CPU Feature Detection + */ + +/* 32 or 64 bits ? */ +#if (defined(__x86_64__) || defined(__x86_64) || defined(__amd64__) || \ + defined(__amd64) || defined(__ppc64__) || defined(_WIN64) || \ + defined(__LP64__) || defined(_LP64)) +#define LZ4_ARCH64 1 +#else +#define LZ4_ARCH64 0 +#endif + +/* + * Little Endian or Big Endian? + * Note: overwrite the below #define if you know your architecture endianess. + */ +#if (defined(__BIG_ENDIAN__) || defined(__BIG_ENDIAN) || \ + defined(_BIG_ENDIAN) || defined(_...

This is an automatic message generated by the builder on builder-debian for febootstrap. Log files from the build follow below. Linux builder-debian.home.annexia.org 2.6.36-trunk-amd64 #1 SMP Wed Oct 27 14:28:29 UTC 2010 x86_64 GNU/Linux Tue Jun 7 20:00:01 BST 2011 ----- + git pull --rebase git://git.annexia.org/git/febootstrap.git master >From git://git.annexia.org/git/febootstrap *