similar to: [LLVMdev] Status on llvm-g++ -> llc -> C backend

On Fri, 2 Jun 2006, Anton Korobeynikov wrote: > Hello, Chris. > You wrote Friday, June 2, 2006, 9:27:25 PM: > CL> I don't see that failure. We'll need more info to reproduce the issue. > Got fixed by adding the folowing line in ther early beginning of > LowerAllocations.cpp file: > > static IncludeFile CUFENP((void*)createUnifyFunctionExitNodesPass); I committed

Thanks Anton and Chris, it works. On a side note is there a way to have llc preserve function names upon output to C so that external CPP files that link this file in will be able to find the correct functions. And how about name mangling? I assume this is something not taken care of by llc or at least from llvm-g++ to bytecode. Ashwin On 6/2/06, Chris Lattner <sabre at nondot.org> wrote:

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > Hi, > > > > > > I partly built LLVM on Cygwin yesterday and it was fine

Aaron Gray wrote: > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:

On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > >

Aaron Gray wrote: > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > Hi, > > > > I partly built LLVM on Cygwin yesterday and it was fine as far as it > > went. But after doing a svn update today I am getting the following > > warning

Aaron Gray wrote: > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:

On Fri, Feb 27, 2009 at 7:14 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > >

Link to LowerAllocations ( http://llvm.org/doxygen/LowerAllocations_8cpp-source.html) is no longer working. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130518/9eb42d79/attachment.html>

Hi, I partly built LLVM on Cygwin yesterday and it was fine as far as it went. But after doing a svn update today I am getting the following warning on every compile :- llvm[3]: Compiling LowerAllocations.cpp for Debug build /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: -fPIC ignored for target (all code is position independent) This maybe happening on other targets too.

Hi, While attempting to build the LLVM code from CVS today using gcc 4.1, I encountered the following error. Any idea how to proceed with the build? llvm[2]: Linking Debug executable llvm-as /home/ll/programs/source/scm/cvs/llvm/Debug/lib/libLLVMAsmParser.a(llvmAsmParser.o): In function `__static_initialization_and_destruction_0':

On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > Hi, > > > > I partly built LLVM on Cygwin yesterday and it was fine as far as it > > went. But after doing a svn update today I am getting the following > > warning on every compile :- > > > > > > llvm[3]: Compiling LowerAllocations.cpp

I''ve read the docs. Honestly. But, I still can''t get my site working with the latest gem. I''m confused over when and how I need to specify content blocks, and how these relate to the stuff in config.yaml. The specific problem is with my analytics file include, I get errors like this: An error has occurred: Error while processing </analytics.en.html>: Error

Hi all In order to add visit tracking to my webgen site, i''ve written a google analytics plugin which, given a google analytics key, automatically includes tre required javascripts. Requirements : in your page template, put {googleAnalytics: key: your_google_key} just before your <body> tag. And that''s all. The code is the following :

Aaron Gray wrote: > Hi, > > I partly built LLVM on Cygwin yesterday and it was fine as far as it > went. But after doing a svn update today I am getting the following > warning on every compile :- > > > llvm[3]: Compiling LowerAllocations.cpp for Debug build > /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: > -fPIC ignored for

It seems to me that the man page is not complete. Personally, I had to read the code to understand. Propose to amend paragraph of included files on: -i GUEST-PATH=HOST-PATH, --include GUEST-PATH=HOST-PATH File (HOST-PATH) to copy into custom dir (GUEST-PATH). -I HOST-PATH, --includefile=HOST-PATH Copy all files listed in inputfile into the appropriate temporary sandbox directories. File

Chris Lattner wrote: > Can you explain what goes wrong without the stub? It's the only part that > I didn't apply. The X86 backend doesn't get registered since there are no references to symbols in X86TargetMachine the object file is never pulled in from the library I create, and thus the static intializer for the RegisterTarget is never called...

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

Now that we have a "-why" option to the GenLibDeps.pl utility (which is used by llvm-config to deduce library dependencies), a review of the output has led to a few dubious library dependencies. Here they are: All of the following dependencies are singletons (the dependent library depends on only a single symbol from the dependency library): libLLVMCodeGen.a: