Displaying 3 results from an estimated 3 matches for "8589934591".
Did you mean:
8589934592
2017 Dec 03
2
5.0.1-rc2 has been tagged
...The bug is fixed by
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 315889
> 91177308-0d34-0410-b5e6-96231b3b80d8
> in llvm 6.0.
>
> This patch is largely the same as the fix in llvm 6.0 except
> one minor adjustment ("; CHECK: r{{[0-9]+}} = 8589934591 ll" in
> the original commit
> to "; CHECK: r{{[0-9]+}} = 8589934591ll" in this patch) for the test case.
>
> Reported-by: John Fastabend <john.fastabend at gmail.com>
> Reported-by: Jakub Kicinski <jakub.kicinski at netronome.com>
> Sig...
2017 Nov 30
9
5.0.1-rc2 has been tagged
Hi,
I've tagged the 5.0.1-rc2 release, go ahead and start testing and report
your results.
-Tom
2004 Dec 16
0
[LLVMdev] Re: LLVM & Large memory 64-bit systems
...lementation ; Functions:
sbyte* %p(ulong %n) {
entry:
%tmp.3 = getelementptr %struct.Foo* %foo, long 0, uint 0, ulong %n
ret sbyte* %tmp.3
}
int %y() {
entry:
ret int cast (bool setlt (long sub (long cast (sbyte* getelementptr (%struct.Foo* %foo, long 0, uint 0, ulong 8589934591) to long), long cast (%struct.Foo* %foo to long)), long 8589934593) to int)
}
... The type of "foo" is clearly wrong and going to be miscompiled, but
'y' is correctly compiled (even if it should be constant folded).
>> %X = malloc int, ulong <something big>
>&...