similar to: [LLVMdev] Why is BasicBlock's copy constructor private?

On 25 March 2010 20:04, Trevor Harmon <trevor.w.harmon at nasa.gov> wrote: > > So why exactly is BasicBlock's copy constructor private? The ominous > "Do not implement" warning leads me to think there is some sort of > design issue that is preventing a copy constructor here. Is there any > possibility of working around it? > I think the problem is that LLVM

On Mar 25, 2010, at 5:23 PM, me22 wrote: > Given that LLVM is already managing the memory and presumably will do > so for the life of your graph processing, could you just use a > boost::directed_graph<llvm::BasicBlock*> instead? Yeah, that was one of the first things I tried: for (Function::iterator i = function.begin(), e = function.end(); i != e; ++i) { BasicBlock

On 03/26/10 01:04, Trevor Harmon wrote: > Hi, > > LLVM provides basic graph traversal for its CFGs, but I need > additional operations, such as iterating over the edges. I thought I > would solve this problem using the Boost graph library. It should be > relatively simple to walk an LLVM CFG and add the BasicBlock objects > to a Boost graph declared as: Hi Trevor, I am not

Ryan, [ Please continue the discussion on mailing for the benefit of everyone. ] On Nov 10, 2011, at 10:31 AM, Ryan Taylor wrote: > I need to iterate bottom up on the nodes, but within that I want to break up BBs within a loop. I could just create a loop pass as another opt and call that, I just thought it'd be easier to get the loop info inside the opt I'm already doing. It is

Basically I have two separate passes (first is a loop pass) which are two different files and two different opts but I need to keep the data consistent (ie, I want the changes to show up the resulting .bc output file from the first (loop) pass so the second pass can use these new names. Currently, when I print out "BB->getName().str()" after the code below, I get the correct renaming

Nick, Thanks for this info, though this didn't help my problem at all. On Wed, Nov 16, 2011 at 7:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Never create a Twine as a local variable. > > V->setName(Twine("new_name")); > > should work fine, however. Note that Twine itself has an implicit > constructor from const char *, so this code: > >

LLVMers, So, I'm trying to write a pass that changes the names of the basic blocks through the use of Value, so: Value *V = *BasicBlockPtr; const Twine Tname("new_name"); V->setName(Tname); But when I run the opt and look at the IR output nothing is changed? Not sure what I'm doing wrong. Thanks. -------------- next part -------------- An HTML attachment was

Never create a Twine as a local variable. V->setName(Twine("new_name")); should work fine, however. Note that Twine itself has an implicit constructor from const char *, so this code: V->setName("new_name"); should also work fine. Nick Ryan Taylor wrote: > Basically I have two separate passes (first is a loop pass) which are > two different files and

So is this simply not possible? On Thu, Nov 17, 2011 at 10:31 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Nick, > > Thanks for this info, though this didn't help my problem at all. > > > On Wed, Nov 16, 2011 at 7:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Never create a Twine as a local variable. >> >>

Hello, Yesterday I posted about how to email from a worker. I decided to be a bit piggy and just inhale all of rails. Sorted. I am noticing some rather ominous behavior though. The setup: My worker takes an uploaded image as a param and passes it (via system call) to a C++ image processing engine. Take a look at these memory consumption figures for successive runs uploading the identical image

I''m currently running snv_76 on my laptop to run a windows XP hvm domU. Everything has been working great until recently when I started getting the following messages during boot (from dmesg): Dec 11 16:31:19 pdlaptop xenstored: [ID 702911 daemon.error] Checking store ... Dec 11 16:31:19 pdlaptop xenstored: [ID 702911 daemon.error] Checking store complete. Dec 11 16:31:19 pdlaptop

Hey I''m getting a Ajax.InPlaceEditor is not a constructor error on some of my pages. I''ve included the following .js''s: :defaults scriptaculous Any ideas? Thanks guys! Gustav gustav@rails.co.za -- Posted via http://www.ruby-forum.com/.

Bugs item #6825, was opened at 2006-11-22 18:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=6825&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Kevin Smith (qualitycode) Summary: Missing typedef for Wx::FindReplaceData constructor Initial Comment:

I tried out the sugar. The following code crashes: require ''rubygems'' require ''wx'' require ''wx_sugar/all'' frame = Wx::Frame.new(nil, :title => "Text") panel = Wx::Panel.new(frame) With the following error. 0.1.13/lib/wx_sugar/keyword_constructors.rb:244: [BUG] Bus Error Any ideas? Micah Martin 8th Light, Inc. 8thlight.com

Patches item #20447, was opened at 30/05/2008 12:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=20447&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Hurni (phi) Assigned to: Nobody (None) Summary: Add keyword constructor to new class Wx::ToolBarTool Initial Comment: Wx::ToolBar API changed

Hi Rails, I am having trouble setting up an autocomplete text field. Using rails 1.0.0 and just trying to copy the simple scriptaculous demo (http://demo.script.aculo.us/ajax/autocompleter) fails. My view and controller are set up the same way. In firefox 1.0.4 (and safari, don''t remember the version) I get the Ajax.Autocompleter error in the javascript console when loading the

I have a model; I do photo = Photo.new(parameters) parameters contains: {"picture"=>#<File:C:/DOCUME~1/BART~1/LOCALS~1/Temp/CGI3180.1>} so i expect that the def picture=(filename) method is called in this constructor.. this is not the case. Does anyone know why? params[:photo].each_pair do |id, parameters| photo = Photo.new(parameters) end class Photo

I remember reading in a previous thread by Chris that all instructions will have the "instruction to insert before" as an argument to their constructors. In the code I have, this hasn't been done for the AllocaInst. I did a recent "cvsupdate", but the code still hadn't changed. Has this code already been updated ? If not, I request that it be updated as soon as

> AllocaInst. I did a recent "cvsupdate", but the code still hadn't > changed. Has this code already been updated ? If not, I request that it > be updated as soon as possible, as it simplifies our implementation of > MP1 (we need to insert the alloca's at the beginning of the function). The plan is to update the CSIL CVS tree soon. When that happens you should get

On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > What guarantees does LLVM try to provide regarding source code compatibility? None. > Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17