similar to: [LLVMdev] [patch] fix gcc build failure on arm

What change did you need? deep 2009/3/17 Misha Brukman <brukman at gmail.com>: > On Thu, Mar 12, 2009 at 8:39 PM, Sandeep Patel <deeppatel1987 at gmail.com> > wrote: >> >> Attached is the patch I've been building arm-eabi with, which might >> help with linux-gnueabi. I disable multilib to get around several bugs >> with thumb. I build cross binutils

On Tue, Mar 17, 2009 at 4:17 PM, Sandeep Patel <deeppatel1987 at gmail.com>wrote: > What change did you need? Even with your change, it was still complaining about not having a definition of MACHO_DYNAMIC_NO_PIC_P somewhere, so I took the easy way out with inserting this in arm.h: /* Overridden by arm/darwin.h, whether it is included first or not. */ #ifndef TARGET_MACHO #define

Hello everyone, I'm currently constructing a graph from LLVM bitcode, and I have a question about accessing the names of the variables shown in the .ll assembly file, assuming it's possible... For example, with %2 = load i32* %x_addr, align 4 ; <i32> [#uses=1] I can retrieve the opcodeName() from the Instruction object, which is "load". I can also access the operand

On Mar 12, 2009, at 8:30 AMPDT, Misha Brukman wrote: > > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: > error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) > > This tells me there are some Darwin-specific bits in arm.md which > shouldn't be there (MachO is Mac OS X-specific). I'm using the > attached script

>> >> If any ARM/GCC experts know how to fix arm.md to not refer to >> Darwin-specific macros, that would be great, too. > > Probably the right general idea is to #define MACHO_DYNAMIC_NO_PIC_P > to be 0 for non-Darwin targets. Not sure where to put this so it > will work for both targets (the Darwin definition comes from config/ > darwin.h). I don't

On Mar 17, 2009, at 1:52 PMPDT, Misha Brukman wrote: > On Tue, Mar 17, 2009 at 4:17 PM, Sandeep Patel <deeppatel1987 at gmail.com > > wrote: > What change did you need? > > Even with your change, it was still complaining about not having a > definition of MACHO_DYNAMIC_NO_PIC_P somewhere, so I took the easy > way out with inserting this in arm.h: > > /*

Hi Dean, thank you for the response! I'm a newbie to LLVM, a student working on an LLVM project so I'm not quite sure of what you're suggesting, please excuse my naivety. To clarify there used to exist this http://llvm.org/releases/1.0/docs/CommandGuide/lli.html where you could type "lli -trace 'filename.bc' and you would get a dump of the dynamic excutiion trace. I

Can anyone shed some light on the origins of the comments... /* Mach-O doesn't support omitting the frame pointer for now. */ ...in gcc/config/i386/i386.c. FSF gcc trunk has enabled the omit-frame-pointer option as the default for both i386 and x86_64 recently. * config.gcc: Handle --enable-frame-pointer. * configure.ac: Add --enable-frame-pointer. * configure: Regenerated. *

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

Chris Lattner wrote: > > This looks like you're compiling llvm-gcc3, which is quite dead by now. > Please follow these instructions: > http://llvm.org/docs/CFEBuildInstrs.html > > Oups, sorry for that. Here is the error message with the latest svn version: gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic

As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in

OK, seems like there were unused TARGET_MACHO macros that would protect these errors from happening. I made some modifications that add #if TARGET_MACHO. Now the error is a linkage problem: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/xgcc: symbol lookup error: /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/libgcc_s.so.1: undefined symbol: __thenan_sf And even if I force the definition of

On Tue, 22 May 2007, Nicolas Geoffray wrote: > OK, seems like there were unused TARGET_MACHO macros that would protect > these errors from happening. I made some modifications that add #if > TARGET_MACHO. ok. If you send a patch in that adds these, I would be happy to apply it. > Now the error is a linkage problem: > > /home/varth/project/llvm-cvs/llvm-gcc4/obj/gcc/xgcc:

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

Hello, I have an Asus laptop, U36SD, with Optimus technology. The discrete gpu is an NVIDIA GeForce GT 520M with 1GB DDR3 VRAM Using Fedora 17; up to kernel 3.3.7-1 I was able to use bumblebee and bbswitch and then running optirun command (as I could do in F16). No more with kernel 3.4. Tried 3.4.0-1.fc17.x86_64, 3.4.2-4.fc17.x86_64 and 3.4.3-1.fc17.x86_64. I already opened a bug against F17:

James Stanier wrote: > Hello everyone, > > I'm currently constructing a graph from LLVM bitcode, and I have a question > about accessing the names of the variables shown in the .ll assembly file, > assuming it's possible... > > For example, with > > %2 = load i32* %x_addr, align 4 ; <i32> [#uses=1] > > I can retrieve the opcodeName() from the

The other repliers have been right that you probably want to use Value*s rather than string names in constructing your dependency graph, but I wanted to clear up a second possible point of confusion. When you see %2 in the assembly, that's an indication that the instruction's name is empty. That is, value->getName() == "". As far as I know, llvm-dis just generates numbers in

http://bugs.freedesktop.org/show_bug.cgi?id=27064 Summary: Nouveau fails to start X. This is a Nvidia G210m, the laptop is an asus UL50vt Product: xorg Version: 7.5 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Driver/nouveau

http://bugs.freedesktop.org/show_bug.cgi?id=26499 Summary: nouveau driver fails to load Product: xorg Version: 7.4 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: info at

Hi Chris, Chris Lattner wrote: > On Tue, 22 May 2007, Nicolas Geoffray wrote: > >> OK, seems like there were unused TARGET_MACHO macros that would protect >> these errors from happening. I made some modifications that add #if >> TARGET_MACHO. >> > > ok. If you send a patch in that adds these, I would be happy to apply it. > > I will when