search for: lp64

...(rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64 bug... -- Christian "naddy" Weisgerber naddy@mips.inka.de

Did you really experience problems with the code? Since I only care about the last bits (because of the & "(size-1)"), I thought it should work even if sizeof(int) != sizeof(void*). If it doesn't work with int, I suspect the solution with the long could also fail on some archs. Jean-Marc Le mer 11/06/2003 à 11:56, Christian Weisgerber a écrit : > Casting a pointer to

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Casting a pointer to an int is a bad idea on 64-bit platforms. --- libspeex/stack_alloc.h.orig Wed Jun 11 17:10:53 2003 +++ libspeex/stack_alloc.h Wed Jun 11 17:11:12 2003 @@ -48,7 +48,7 @@ #else /*Aligns the stack to a 'size' boundary */ -#define ALIGN(stack, size) ((stack) += ((size) - (int)(stack)) & ((size) - 1)) +#define ALIGN(stack, size) ((stack) += ((size) - (long)(stack))

...s that removing “nsw” from an operation is simpler and cleaner than adding “freeze” to it, and in software engineering we are always striving for the simplest and cleanest solution. IIUC option three does not inhibit Dan's original goal of promoting 32-bit induction variables to 64-bit on an LP64 target. And I don’t agree with Dan's description of this being “suboptimal” for any other reason, the lost information does not seem to be useable AFAICT, but if you disagree then simply insert an “llvm.assume" in the spot where the operation is being hoisted from. So I propose that we...

We have: ---------------------------------------------------------------------- typedef unsigned long uint4; ---------------------------------------------------------------------- which on an LP64 system is a lie. If uint4 is used on disk (and it's used in the btree implementation) then it would make the databases unportable, which probably isn't a good idea (unless we already have endianness issues, although even there, an ILP32 and an LP64 process on the same machine should really...

...tptr' type could be > a useful feature, with the advantage of it being a language-independent > construct. I think this would capture what you're really going for, and > have very simple and well-defined meaning. Yes, maybe ... what exactly is the definition of this type? On LP64 systems the width of ints and pointers are different. > If other front-end people > think that this would be a useful abstraction for providing portable > code, and can give examples where it would be used, that would provide a > lot of cre...

All, These discussions seem to be based on the premise that there is a need for the compiler to exploit undefined behavior for performance optimization reasons. So far the only beneficial optimization I am aware of that relies on some form of “undefined” is Dan Gohman’s original project for LP64 targets of promoting i32 induction variables to i64 and hoisting sign-extension out of the loop. But “undef” / “poison” never appears in either the original or the transformed IR for these types of loops, instead properties of “+nsw” are used to justify the transformation. The transformation does...

.../058450.html What’s currently in trunk: * Triplet x86_64-*-linux-gnux32 (command line support, EnvironmentType enum to differentiate x32 from x86_64 by getTriple().getEnvironment() == llvm::Triple::GNUX32) https://github.com/llvm-mirror/llvm/commit/9dd2a3b1f2c253e20262535bb89b1ab6cc680ece * ILP32/LP64 differentiation for TargetMachine https://github.com/llvm-mirror/llvm/commit/a5597f0eaf1f93c6d0bc641a0cc54ecffb33955a * LEA tuning: https://github.com/llvm-mirror/llvm/commit/693c37aa86506be657dfaf8835845b0998531c3c * Bunch of tests (grep for gnux32): test/CodeGen/X86/imul64-lea.ll test/CodeGen/X86...

...n mmsystem.h. include: Remove 'l' modifier from numeric constants in dinput.h. include: Remove 'l' modifier from numeric constants in digitalv.h. include: Drop the 'l' modifier from some numeric constants in winnt.h. include: Add a macro to paper over LP64/LLP64 differences for numeric constants. include: Make "long" numeric constants LP64/LLP64 proof (d3d9caps.h). include: Make "long" numeric constants LP64/LLP64 proof (d3d9*.h). include: Make "long" numeric constants LP64/LLP64 proof (d3d*.h). i...

On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote: > > int a = INT_MAX, b = 1; > long c = (long)(a + b); > > What is the value of c, on an LP64 target? > > If a and b are promoted to 64-bit, c is 0x0000000080000000. > > In a world where signed add overflow returns undef, c could be any of >  0x0000000000000000 >  ... >  0xffffffffffffffff > however it can't ever be 0x0000000080000000, because there's no 32-b...

...not valid under >> the simple and obvious answer. Are you proposing to do it anyway? > > Please define "valid". We discussed this a very very long time ago, and I don't recall the details. int a = INT_MAX, b = 1; long c = (long)(a + b); What is the value of c, on an LP64 target? By standard C rules, the add overflow invokes immediate undefined behavior of course. If a and b are promoted to 64-bit, c is 0x0000000080000000. In a world where signed add overflow returns undef, c could be any of 0x0000000000000000 0x0000000000000001 0x0000000000000002 ... 0...

Hi, all I found in some cases the int variable get promoted to i64, although I think it should i32. I use the online demo (http://llvm.org/demo). And below is the test case. ------------- test case ------------- int test(int x[], int y[], int n) { int i = 0; int sum = 0; for ( ; i < n; i++) { sum += x[i] * y[i]; } return sum; } ------------------------------------- No

Hello all, I get unresolved external symbol __muloti4 when attempting to compile GNU m4 for Windows commandline. See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22 Looking into this, I see that some parts of compiler-rt are disabled for Windows due to the __LP64__ define. The code seem not portable as is to the MS compiler, but according to my tests the code compiles and links OK with clang: I have not tested functionality though. Regarding the __LP64__ define, it's wrong to define it for Windows. SUA/Interix have LP64 long type model, while Cygwin, mi...

On Dec 30, 2015, at 3:09 AM, Thomas Zander <thomas.e.zander at googlemail.com> wrote: > On 29 December 2015 at 21:50, lvqcl <lvqcl.mail at gmail.com> wrote: >> So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) >> as 4 for 32-bit and as 8 for 64-bit targets? > > Your tests so far imply this is a sensible default. > I'd say go ahead. We

...9da3d28..4848fbd 100644 --- a/src/lib/test-murmurhash3.c +++ b/src/lib/test-murmurhash3.c @@ -7,7 +7,19 @@ struct murmur3_test_vectors { const char *input; size_t len; uint32_t seed; - uint32_t result[4]; /* fits all results */ + + /* murmurhash3_128() produces a different output on ILP32 and LP64 + systems (by design). Therefore, 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 a...

...rapv/-ftrapv on the compiler command line, which impede the compiler's usual exploitation of signed wrap UB in C. Last I heard, those options lead to substantial performance regressions. > In my other emails I point out that Dan achieved the goal of hoisting sign-extension out of loops for LP64 targets by exploiting “+nsw”, and that this appears to be the only example of a performance benefit. I am not suggesting we remove this optimization, and my emails point out that keeping this opt does not require that the compiler model “undefined behavior”. Heres what gcc says about those opti...

At 4:37 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 13:21, tom erbe wrote: >> At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >> > > 0.2 doesn't segfault, but it seems to overrun the server (if that >> >> makes any sense), it plays a 3 minute file in seconds. >> > >> >I'd like to know more about this. Are you

...gt; return *p; > } > > The X86 machine code would do something like > > add %eax, 4 > > for `++p', but for x86_64 it would be > > add %rax, 8 > > But you can't know that without looking at the original C code. This is a bad example. A compiler compiling LP64 code would generate the above code on x86_64 for the given C code. An ILP32 compiler for x86_64 would generate something more akin to the 32-bit x86_32 code given above. It should be possible to statically convert such a simple program from one instruction set to another (provided that they...

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: