Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] 'Reference Out Of Range' error building llvm/clang with -O4"
2020 Aug 25
2
ORC JIT - Incorrect support for COFF files?
Hey Lang,
That is really cool :D Is the creation of that table a Windows thingy or is this the way the LLVM handles it?
Also… since it is COFF related – the never ending story of “finding my global constructors” first of all: Yes! I tried using the “initialize” function of LLVMJIT – however this only worked when I was loading a Module. When I added the object file (from the same source) the
2020 Aug 24
2
ORC JIT - Incorrect support for COFF files?
Hey Lang and Stefan,
Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work?
However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to
2017 Jan 25
2
LLVM 3.9.1 build race?
Hi Folks,
I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g.
Linking CXX static library ../libLLVMSupport.a
cd
2020 Aug 21
2
ORC JIT - Incorrect support for COFF files?
Hi Björn
I made a workaround for this specific issue a long time ago for the
Projucer C++ JIT Engine. It basically forwards the call to another stub
that provides enough space to encode a full 64-bit address. The patch is
based on LLVM 3.9, so I guess it won't work out-of-the-box on a recent
release, but it may give you enough hints to figure it out on your own:
2020 Apr 08
0
[RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> struct text_poke_loc {
> s32 rel_addr; /* addr := _stext + rel_addr */
> - s32 rel32;
> - u8 opcode;
> + union {
> + struct {
> + s32 rel32;
> + u8 opcode;
> + } emulated;
> + struct {
> + u8 len;
> + } native;
> + };
> const u8 text[POKE_MAX_OPCODE_SIZE];
> };
NAK, this
2009 Dec 05
4
paste adjacent elements matching string
Hi all,
I would like to combine elements of a vector:
vec <- c("astring", "b", "cstring", "d", "e")
> vec
[1] "astring" "b" "cstring" "d" "e"
such that for every element that contains "string" at the end, it is
combined with the next element, so that I get this:
2015 Nov 23
2
COFF::IMAGE_REL_AMD64_REL32 relocation overflow when compiling for x86_64
Some time ago I posted here regarding a relocation overflow on Windows
(among other things), but the issue disappeared and so the thread got left.
I've started this new thread because a) I didn't want to necro the old one
and b) it felt like its own.
I've now encountered the issue again and am noting down all the information
I can get about it whilst it's happening.
The issues is
2006 Aug 03
0
[LLVMdev] Building llvm under cygwin
Hello Anton
Thu, 3 Aug 2006 15:06:56 +0400 you wrote:
> here it is in the attachment :)
Ok. Could you also send LibDeps.txt file? It should be
in /obj/tools/llvm-config directory
--
With best regards, Anton Korobeynikov.
Faculty of Mathematics & Mechanics, Saint Petersburg State University.
2006 Aug 04
1
[LLVMdev] Building llvm under cygwin
Hello Anton
Fri, 4 Aug 2006 21:45:19 +0400 you wrote:
> Written by Mike Haertel and Paul Eggert.
> I've updated llvm and llvm-gcc4 ant trying to build it again after
> PR845 was resolved. According to Reid's letter this PR coud be the
> reason of my problem.
Anyway, "sort" call can cause large problems depending, where in your
PATH cygwin directory is (before
2008 Sep 06
2
[LLVMdev] "has different visibility" warnings
Recently I started getting these warnings - thousands of them - and I'm
not sure what I did to cause them or how to solve them:
ld: warning llvm::MemoryBuffer::getBufferStart() const has different
visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and
(2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o)
ld: warning
2004 Jul 03
1
[LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared
On Sat, 3 Jul 2004, Chris wrote:
>
>That should work fine. I'm not familiar at all with internix, but it
>appears to have a buggy header or something. From what I understand,
>internix is a posix layer for windows. Have you tried compiling under
>cygwin?
No, not yet.
>If you grab the latest CVS sources, they should work fine with
>cygwin, and will probably work
2008 Sep 06
0
[LLVMdev] "has different visibility" warnings
http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html
On 2008-09-05, at 22:46, Talin wrote:
> Recently I started getting these warnings - thousands of them - and
> I'm
> not sure what I did to cause them or how to solve them:
>
> ld: warning llvm::MemoryBuffer::getBufferStart() const has different
> visibility (1) in
2006 Aug 01
15
[LLVMdev] Building llvm under cygwin
>
> If you're building llvm-gcc4, you don't need the runtime libraries, so
> I'd just stick with the "tools-only" build and declare success. If
> you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :)
I switched to llvm-gcc4 but when I run make from obj folder i run into
folowing errors:
Can't find a library with no dependencies at
2006 Aug 03
0
[LLVMdev] Building llvm under cygwin
Hello Anton
Thu, 3 Aug 2006 12:38:54 +0400 you wrote:
> I've updated it yesterday and rebuilt - llvm built fine. But when
> building llvm-gcc4 (also updated yesterday from new /trunk
> directory) it fails with the same error.
You might easily get llvm-gcc4-mingw32 binaries from "prerelease"
directory. Since stdcall, fastcall & dllimport stuff is unsupported
right now,
2019 Jun 27
4
Re: [PATCH 9/9] Rust bindings: Complete bindings
Patch 9 is a kind of dumping ground of all kinds of stuff. It may be
better to spend some time with git rebase -i trying to work this into
more coherent patches.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live
2008 Jun 03
2
[LLVMdev] #include problem
Hi,
On Fedora 9 GCC 4.3,
LLVMCConfigurationEmitter.cpp needs #include <typeinfo>.
ValueTracking.cpp needs #include <cstring>.
Thanks.
--Zhongxing Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080603/38f917f4/attachment.html>
2008 Aug 21
3
[LLVMdev] Fix build on GCC 4.3
Index: include/llvm/ADT/APInt.h
===================================================================
--- include/llvm/ADT/APInt.h (revision 55101)
+++ include/llvm/ADT/APInt.h (working copy)
@@ -20,6 +20,7 @@
#include <cassert>
#include <iosfwd>
#include <string>
+#include <cstring>
namespace llvm {
class Serializer;
-------------- next part --------------
An
2009 Jan 21
2
[LLVMdev] RFA: Constant String c"\000"
The Constants.cpp file returns a ConstantAggregateZero object when you
pass it a c"\000" string. Here is the code:
Constant *ConstantArray::get(const ArrayType *Ty,
const std::vector<Constant*> &V) {
// If this is an all-zero array, return a ConstantAggregateZero
object
if (!V.empty()) {
Constant *C = V[0];
if (!C->isNullValue())
2013 Mar 21
2
[LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac
(forgot to CC llvmdev)
On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote:
> Hey Anna, Nick, Ted,
>
> We've the following problem with string literals under ASan on Mac.
> Some global string constants end up being put into the .cstring
> section, for which the following rules apply:
> - the strings can't contain zeroes in their
2014 Mar 26
7
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi,
Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash
with a backtrace like:
[ 3149s] --
[ 3149s] 0 libLLVMSupport.so 0x00003fff7ed0b864
llvm::sys::PrintStackTrace(_IO_FILE*) + 4294746876
[ 3149s] 1 libLLVMSupport.so 0x00003fff7ed0bb1c
[ 3149s] 2 libLLVMSupport.so 0x00003fff7ed0c520
[ 3149s] 3 linux-vdso64.so.1 0x00003fff7f7b0478 __kernel_sigtramp_rt64 + 0
[ 3149s] 4