similar to: [LLVMdev] Merge-Cha-Cha

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

On Tue, Sep 2, 2008 at 8:21 PM, John Regehr <regehr at cs.utah.edu> wrote: > I'm getting the error below on Ubuntu Hardy on ia32 on r55688. > ... > ../../gcc/postreload-gcse.c:1123: error: > flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this > function) This is a Darwin-specific flag. I added a conditional to check for "CONFIG_DARWIN_H"

See below. This is on Ubuntu Hardy on ia32. Thanks, 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 -I../../gcc/.

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

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

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

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

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: > > /*

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

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

> > Now the problem is obvious.  A two dimensional array access is being > performed by a single instruction.  The arithmetic needed to address > the element is implicit, and therefore inaccessible to optimizations.  > The redundant calculations can not be eliminated, nor can strength > reduction be performed.  getelementptr needs to be broken down into > its constituent

I'm new to the LLVM, so please forgive what might be a silly question. I'd like to use the opt bytecode-to-bytecode optimizer, but when I try running it to do, for example, dead code elimination (-dce) or global common subexpression elimination (-gcse), nothing much seems to happen: opt -gcse -dce -o bar-opt.bc bar.bc llvm2cpp -o bar-opt.cpp bar-opt.bc

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >>> You could do that, but SCCPSolver isn't really useful to mainline LLVM >>> for anything other than SCCP and IPSCCP, so we don't need it in a public >>> header. Out of curiosity, what are you looking to use the latice values >>> for? Why not just run SCCP and then look at the

I figured getelementptr exists as it does to facilitate data flow analysis, but it does need to be broken down before instruction selection. It's not just the missed optimization opportunities. It also introduces a huge amount of complexity into instruction selection as they deal with its complexity. It would also take care of many of the FIXMEs in LoopStrengthReduce. Vikram Adve

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 Wed, 10 May 2006, Nick Lewycky wrote: >> Then just run the SCCP pass, and check to see if any operands satisfy >> the predicate "isa<UndefValue>(V)". LLVM explicitly represents >> undefined values. > > I have a case where it doesn't, but perhaps the SCCP pass isn't to blame: > > extern void write_char(int); > > const char foo[4] =

Hello, I have some code which I was hoping the LLVM optimization passes would get rid of for me, but no such luck -- all the code does is store four float 0.f to memory, load four other floats from memory, load back the first four floats, multiply them together (here we should have always get 0) and finally store them back to memory. Any ideas why this isn't picked up by the constant

On Wed, 21 May 2008, Nicolas Capens wrote: > Thanks for the detailed explanations. I have a few remaining questions: > > Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg > and therefore generally preferable? Right. > What would be the code quality implications of using "-dce -simplifycfg" > instead of -adce? As far as I understand the