search for: target_macho

...m>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 TARGET_MACHO 0 +#define MACHO_DYNAMIC_NO_PIC_P 0 #endif Anyone have any objections to this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090317/b567afb0/attachment.html>

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

...> > 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 TARGET_MACHO 0 > +#define MACHO_DYNAMIC_NO_PIC_P 0 > #endif Looks fine to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090317/92a4acaa/attachment.html>

...al 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 think so. Darwin-specific pieces of code should be guarded, as usual, with TARGET_MACHO define. --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/e56f1cd6/attachment.html>

...for both i386 and x86_64 recently. * config.gcc: Handle --enable-frame-pointer. * configure.ac: Add --enable-frame-pointer. * configure: Regenerated. * config/i386/i386.c (USE_IX86_FRAME_POINTER): Default to 0. (override_options): Enable -fomit-frame-pointer for 32bit code if compiling for TARGET_MACHO and not optimizing for size unless configured with --enable-frame-pointer. Enable -fasynchronous-unwind-tables unless configured with --enable-frame-pointer. Enable -maccumulate-outgoing-args by default unless configured with --enable-frame-pointer. After testing on x86_64-appled-darwin10 an...

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

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:...

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:...

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

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 I'll figure out why it sometimes doesn't...

The attached patch implements iasm_memory_clobber so that cc1 links correctly on arm targets. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc.patch Type: application/octet-stream Size: 570 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061003/947791cb/attachment.obj>