similar to: [LLVMdev] llvm-mc build fails

John Myers <atomicdog.jwm at gmail.com> writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a

The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this really true? On X86 stack grows down, so

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >

I have got the latest CVS release of LLVM. And built the Win32 MS VC++ 2003 port with modifications for MS VC++ 2005. Do bear in mind the Visual Studio ports are by no means complete, and are on going. Microsoft Visual Studio 2005 Beta (codename Whidbey) can be got from Microsoft Beta program nearly for free; the cost of postage from :-

I missed two files from the LLVM source code proper. These need reviewing and commiting. They are trivial changes that should not influence any other builds. Basically these functions are missing a return statement which Visual Studio 2005 Beta flags as an error rather than as a warning. I have put in dummy constructors in return statements to allow CodeGen and Target libraries to build. The

Chris Lattner wrote: > On Mon, 7 Jun 2004, Vladimir Prus wrote: > > The TargetFrameInfo, amoung other things, specifies "local area offset" > > -- which, as comment say, is: > > > > the offset of the local area from the stack pointer on entrance to a > > function. > > > > The question is -- what's local area? Is this the first stack

With reference to the previous query, I think, i miscalculated the offset, just recalculating. 1. without instruction combining coupling member variable, is at:   %struct._FRAME_DATA* %2, i32 0, i32 5   where "%2" is defined as:   %arrayidx3 = getelementptr inbounds i16* %Data, i32 1024, !dbg !446   %2 = bitcast i16* %arrayidx3 to %struct._FRAME_DATA*, !dbg !446 i.e. at 5 offset in

I think, finally, I want to conclude on this.   The problem I see is that if I comment the case for "simplificaiton of bitcast to gep of original struct in instruction combining", wherein there is a case for if the offset by which GEP moves the pointer is non-zero.   If I disable this code, then structure elements size, I get is

Török Edwin wrote: > [snip] > > I applied the attached patch to make it compile on my box (Debian > x86_64), only to find out that x86_64 is not supported :( > This architecture is not supported by the pool allocator! > Aborted > Thanks for the patch. What options do I give to the patch command to apply it to the source code? Although there's no documentation about

The TargetFrameInfo, amoung other things, specifies "local area offset" -- which, as comment say, is: the offset of the local area from the stack pointer on entrance to a function. The question is -- what's local area? Is this the first stack location which can be used by function for allocating its own variables? - Volodya

On Mon, 7 Jun 2004, Vladimir Prus wrote: > > The TargetFrameInfo, amoung other things, specifies "local area offset" -- > which, as comment say, is: > > the offset of the local area from the stack pointer on entrance to a > function. > > The question is -- what's local area? Is this the first stack location which > can be used by function for

Hi Pankaj, are you testing this on valid bitcode? The bitcode you sent me did not pass the verifier, i.e. was not valid. Optimizers can be expected to do strange and wrong things if passed invalid bitcode. That is not a bug in LLVM: it is user error if a user doesn't use valid bitcode. Ciao, Duncan. > I think, finally, I want to conclude on this. > The problem I see is that if I

On 2009-08-31 08:50, Tanya Lattner wrote: > LLVMers, > > 2.6 pre-release1 is ready to be tested by the community. > http://llvm.org/prereleases/2.6/ > Hi Tanya, Here are the results for x86_64 Linux (Debian unstable): > You will notice that we have quite a few pre-compiled binaries (of > both clang and llvm-gcc). We have identified several bugs that will be > fixed in

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

Duncan Sands skrev: > Hi Xerxes, > > >> 4. softfloat related errors >> http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ >> example: >> >> root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >>

Hi All,   Further exploring the problem I could find that, there is a address offset calculation problem, with the GEP bitcast handling code in instruction combining. Below is table which shows address offset calculation for the struct elements (described earlier).   Type Variable Actual Size(in bytes) pass fail llvm2.9 Address(pass) Size-pass (in bytes) Address (fail) Size -fail (in bytes) with

Hey all, I need to use C bindings in a pass that I am authoring (specifically, I want to use the OCaml bindings that are tied to the C bindings to author the pass). However, this requires that I link in LLVMCore to provide said bindings to my library. From what I've read, there is a known issue with linking LLVMCore into a module that is fed to opt. Namely, you get the following assertion:

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to