I thought this conversation was worth saving. DannyB who did wonderful things with GCC's use of bugzilla has offered the same capability to LLVM. Thanks, Danny! <DannyB> sabre: BTW, if you need any of the bugzilla fun i have implemented for gcc, let me know [22:47] <sabre> Cool, what kinds of things do you have? [22:47] <DannyB> Besides the triplet stuff, i changed some of the workflow, added some email related features (incoming email handling, changed outgoing email format, made it not send out "useless" emails like keyword-only changes), etc [22:48] <DannyB> Incoming email handling and comment appending by email now handles attachments properly [22:48] <DannyB> all kinds of stuff [22:48] <sabre> Incoming email handling is the thing I would be most interested in [22:48] <sabre> It would be really nice to be able to respond to a bugzilla sent mail and have it appended to the bug [22:48] <DannyB> That's easy [22:48] <sabre> Is it built in? [22:48] <sabre> :) [22:49] <DannyB> define "builtin" [22:49] <sabre> I wouldn't be surprised if there was just a setting that needed to be enabled. :) [22:49] <DannyB> No, because you have to set up incoming email aliases [22:49] <DannyB> So that the mail gets passed off to the script [22:49] <sabre> Ok [22:50] <sabre> well easy is good. Are there dox for doing it, or do you have local hacks in the gcc bugz? [22:50] <DannyB> I also added support so that we know who made the change, and it gets spam-protected and placed in the from [22:50] <sabre> You've been busy! [22:50] <DannyB> So you see email from "dan at dberlin dot org" <gcc-bugzilla at gcc.gnu.org> [22:50] <DannyB> instead of "Bugzilla daemon" [22:50] <sabre> That is nice [22:51] <DannyB> I'll email you the incoming comment handling script. it's rather small, and easy to deal with. [22:51] <sabre> Hrm, yeah, how can I get some of this stuff from you? [22:51] <sabre> sounds great! [22:51] <DannyB> or you can check it out from the gcc CVS repo [22:51] <DannyB> it's in wwwdocs/bugzilla/contrib [22:51] <DannyB> bugzilla_email_append.pl and BugzillaEmailpl [22:51] <DannyB> s/pl/.pm/ [22:51] <sabre> brg and misha are the bugzilla guys [22:52] <sabre> I haven't done much at all with it, but we will definitely take a look [22:52] <DannyB> Happy to help in any way i can [22:52] <sabre> Yeah, just responding to the emails would make things so much faster [22:52] Action: sabre is worklist driven from his inbox [22:52] <DannyB> I'm responsible for having moved gcc from GNATS to bugzilla, and now for maintaining gcc bugzilla :) [22:52] <DannyB> I also have a nice email interface to bugzilla [22:52] <sabre> Yeah, I remember the transition [22:52] <DannyB> so you can get the results of bug queries by email [22:53] <sabre> Hrm, I don't mind using the "gui" for most things. It's just the conversations/feedback on bugs that drives me (more) nuts [22:53] <DannyB> okay, well, all you have to do is set the reply-to on the emails sent out to be the email address of the incoming handler. [22:54] <DannyB> and make sure people don't quote the entire damn email in a response :) [22:54] <sabre> heh [22:54] <sabre> That might be the difficult issue :) [22:54] <DannyB> (otherwise, it'll appear in the comment) [22:54] <sabre> understood [22:54] <DannyB> Well, there are various ways to take care of it from a script perspective [22:54] <DannyB> you could put BUGZILLA:> in front of every line, then ignore every response line with it [22:54] <DannyB> or something [22:54] <sabre> That could work [22:55] Action: sabre ponders [22:55] <sabre> brg: ping [22:55] <DannyB> there are a billion ways to do it [22:55] Action: brg returned Tue Jun 22 22:44:30 2004 -- (hmm) [22:55] <brg> hi what's up [22:55] <sabre> read the last dozen lines [22:55] <sabre> or so [22:56] <sabre> maybe 2 or 3 dozen [22:56] <brg> oh... bugmail? [22:56] <sabre> da [22:56] <DannyB> i hacked up bugzilla_email_append to be actually useful [22:56] <DannyB> as opposed to a useless piece of crap [22:57] <sabre> Do you know anything about the bugmail stuff in bugz brg? [22:57] <brg> i haven't looked into it much, other than to implement the llvmbugs list [22:57] <DannyB> what is the reply-to on llvmbugs? [22:58] <DannyB> for gcc-bugs, we have the reply-to go to the comment appending script, and make sure people don't cc the list again [22:58] <sabre> llvmbugs just gets mail when a bug is opened and resolved [22:58] <DannyB> oh [22:58] <sabre> But bugz sends out emails to people on the CC line for every change [22:58] <sabre> (of course) [22:58] <DannyB> what version of bugzilla are you guys using? [22:59] <sabre> llvmbugs is designed for people who want to keep track of stuff bug not get overwhelmed [22:59] <sabre> j/s [22:59] <brg> 2.16.something [22:59] <DannyB> ah [22:59] <DannyB> the script might not work with 2.16.* [22:59] <sabre> Here's the archives for llvmbugs: http://mail.cs.uiuc.edu/pipermail/llvmbugs/ [22:59] <DannyB> Well, without some changes [22:59] <brg> someday we ought to upgrade to 2.17, but it's been a pretty low priority task [22:59] <sabre> and bugz itself: http://llvm.cs.uiuc.edu/bugs/ [23:00] <DannyB> See, for example, rather than seeing [23:00] <DannyB> bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu [23:00] <DannyB> " [23:00] <DannyB> sabre at nondot.org changed: [23:00] <DannyB> " [23:00] <DannyB> you'll see "sabre at nondot dot org" bugzilla-daemon at cs.uiuc.edu [23:00] <DannyB> in the from [23:00] <sabre> that would be nice, but the report does say who it's from. It's annoying but works [23:00] <DannyB> this was actually a rather simple change [23:00] <sabre> I beleive it [23:00] <sabre> it could be cool [23:00] <sabre> because then the subject lines are more useful :) [23:00] <DannyB> well, whatevery you guys want [23:01] <sabre> what do you think brg? [23:01] <DannyB> i'm just offering the neurons i've used maintaining gcc bugzilla :) [23:01] <sabre> I think that setting the 'name' would be cool [23:01] <sabre> This is pretty useless, for example: http://mail.cs.uiuc.edu/pipermail/llvmbugs/2004-June/thread.html [23:01] <brg> i don't feel like i have the time to overhaul bugzilla at the moment [23:02] <sabre> But just replying to mails would be the killer feature [23:02] <sabre> Do you have some links to point me at dan? [23:02] <sabre> links being files? [23:02] <DannyB> in the gcc bugs mail, or in terms of source? [23:02] <sabre> the source [23:02] <DannyB> one sec [23:03] <sabre> btw, target triples aren't super useful to us, because we always build cross compilers [23:03] <DannyB> i figured as much :) [23:03] <sabre> a bug in the X86 target is just that [23:03] <DannyB> it's also somewhat invasive anyway [23:03] <sabre> you can hit it on sparcs [23:04] <sabre> (not because sparcs use the X86 target, but because they CAN) [23:04] Action: sabre shrugs [23:04] <DannyB> this is our bugzilla_email_append [23:04] <DannyB> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bugzilla/contrib/bugzilla_email_append.pl?rev=1.20&content-type=text/x-cvsweb-markup [23:04] <DannyB> it requires [23:04] <DannyB> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bugzilla/contrib/BugzillaEmail.pm?rev=1.7&content-type=text/x-cvsweb-markup [23:04] <DannyB> that [23:04] <DannyB> and that's it [23:05] <sabre> did you completely rewrite this thing? [23:05] <DannyB> I can't honestly remember anymore :) [23:05] <DannyB> I hate perl [23:05] Action: sabre agrees vigorously [23:06] <DannyB> me must go to bed [23:06] <sabre> So I really don't know much about bugzilla. [23:06] <sabre> What changes between versions? DB layout? [23:06] <DannyB> 2.16->2.17 is a db layout change [23:06] <sabre> ok, sounds good, we can chat about this tomorrow. [23:06] <sabre> ok [23:06] <DannyB> bugzilla is usually years between point releases unfortunately [23:06] <sabre> Will you be around tomorrow afternoon sometime? [23:06] <DannyB> yes [23:07] <DannyB> i'll be around all day tomorrow [23:07] <sabre> Ok, we should get _misha_ around [23:07] <DannyB> hacking loop transforms [23:07] <sabre> in on this [23:07] <DannyB> okeydokey [23:07] <sabre> cool, hopefully the LLVM ones :) [23:07] <sabre> sounds good, thanks for the ptrs [23:07] <DannyB> Hand me classic distance and direction vectors, and I'll hand you a loop transformer :) [23:08] <sabre> Hrm, yeah well we don't have dep analysis yet. [23:08] <sabre> It would be pretty easy to build it out of the SCEV + AA code [23:08] <DannyB> right [23:08] <sabre> If nothing else, we do have a robust AA infrastructure :) [23:08] <DannyB> which is why i'm working slow. I let sebastian implement the dependency analysis stuff in GCC [23:08] <DannyB> :) [23:08] <sabre> heh [23:08] <sabre> Which it seems like he has issues with [23:09] <DannyB> The closest i like to get to dependence analysis is to touch the result [23:09] <DannyB> s [23:09] <sabre> as an outsider observation [23:09] <DannyB> no, it works fine, actually [23:09] <DannyB> we've just been removing the experimental scalar evolutions recently [23:09] <sabre> k [23:09] <brg> i'll see if i can figure out what it would take to upgrade to a recent bugzilla [23:09] <DannyB> we'll add them back as we prove they are useful [23:09] <sabre> I saw intervals just disappear [23:09] <DannyB> brg: That isn't specifically necessary [23:09] <DannyB> Do you guys have intervals? [23:09] <sabre> no [23:09] <DannyB> Right. :) [23:09] <sabre> I didn't think they would make much of a difference at all [23:09] <DannyB> Right :) [23:10] <sabre> likewise with exp nodes [23:10] <DannyB> Hence, why we are removing them for now [23:10] <sabre> yah [23:10] <DannyB> exponential will be removed as well, if it's not gone [23:10] <sabre> I was much more interested in only implementing stuff that won't break programs :) [23:10] <DannyB> brg: I can make the script work with 2.16 [23:10] <sabre> Hence we're VERY conservative about integer wrap around and stuff [23:10] <brg> er, ok [23:11] <DannyB> brg: I'm pretty sure, anyway [23:11] <DannyB> brg: I don't believe the longdesc format changed [23:12] <sabre> Ok, well if you guys want to continue this tomorrow afternoon, we can drag misha in [23:12] <DannyB> okey [23:12] <sabre> Thanks Dan! [23:13] <brg> i think i'll at least update to 2.16.5 [23:13] <sabre> brg: that would be cool [23:15] <sabre> brg: did you just do something to bugzilla? [23:15] <sabre> It seems like it just got unwedged or something [23:15] <brg> yup, i upgraded it to 2.16.5, and fixed the sanity check error that i got [23:15] <sabre> already?? [23:15] <brg> i think it let loose with a bunch of old mail [23:15] <sabre> ya [23:15] <brg> yeah it's pretty easy to do the minor upgrades [23:16] <sabre> cool :) [23:16] <sabre> Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040623/0f169465/attachment.sig>
MetaSplit is an anlysis I just finished writing. It doesn't alter anything,
all it does is build a set of "program instructions". For some reason
even
though if I run it with any other combination of passes I've found, anytime
I run it with mem2reg I get a seg fault in dyn_cast! Here's output:
Starting program:
/mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load
../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc
Program received signal SIGSEGV, Segmentation fault.
0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
69 return isa_impl<To,FromTy>(Val);
(gdb) bt
#0 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#1 0x083b69f7 in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#2 0x083b693f in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:90
#3 0x083b6673 in isa<llvm::Instruction> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#4 0x083b6379 in isa<llvm::Instruction, const llvm::Value*>
(Val=@0xbf8000c0) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:114
#5 0x083b608f in llvm::CallInst::classof(llvm::Value const*) (V=0x894e850)
at /mounts/zion/disks/0/localhome/pmeredit/llvm/include/llvm/iOther.h:110
#6 0x08499213 in isa_impl<llvm::CallInst, llvm::Value> (Val=@0x894e850)
at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:52
#7 0x08499157 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#8 0x08498ea7 in isa<llvm::CallInst> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#9 0x08498b79 in isa<llvm::CallInst> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#10 0x4001d1f6 in isa<llvm::CallInst> (Val=@0xbf800170) at
/localhome/pmeredit/llvm/include/Support/Casting.h:90
#11 0x4001cfb3 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Use const,
llvm::Value*>::doit(llvm::Use const&) (Val=@0xbf800200)
at /localhome/pmeredit/llvm/include/Support/Casting.h:60
#12 0x4001ca1c in isa<llvm::CallInst> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:80
#13 0x4001c1ca in isa<llvm::CallInst, llvm::Use> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:114
#14 0x4001baaa in dyn_cast<llvm::CallInst, llvm::Use> (Val={Val =
0x894e850,
U = 0x8917e48, Prev = 0x895a240, Next = 0x894e880})
at /localhome/pmeredit/llvm/include/Support/Casting.h:223
#15 0x4001af72 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8917e48) at MetaSplit.cpp:79
#16 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x895ff40) at MetaSplit.cpp:88
#17 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#18 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#19 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#20 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#21 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#22 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#23 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#24 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#25 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#26 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#27 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#28 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#29 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
On Wed, 23 Jun 2004, Patrick Meredith wrote:> MetaSplit is an anlysis I just finished writing. It doesn't alter anything, > all it does is build a set of "program instructions". For some reason even > though if I run it with any other combination of passes I've found, anytime > I run it with mem2reg I get a seg fault in dyn_cast! Here's output: > > Starting program: > /mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load > ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bcThis is a crash in your pass. Try running: opt -mem2reg test3.s.bc -o tmp.bc opt -load ... -metasplit tmp.bc -o out.bc I suspect that it will still crash in only your pass (aka, the bug is yours :) Regardless I recommend trying out bugpoint for something like this. Try running: bugpoint -load ... -mem2reg -metasplit test3.s.bc and it will probably tell you what I just did, and give you a better testcase. :) -Chris> Program received signal SIGSEGV, Segmentation fault. > 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const, > llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850) > at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69 > 69 return isa_impl<To,FromTy>(Val); > (gdb) bt > #0 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const, > llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850) > at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69 > #1 0x083b69f7 in isa<llvm::Instruction> (Val=@0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80 > #2 0x083b693f in isa<llvm::Instruction> (Val=@0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:90 > #3 0x083b6673 in isa<llvm::Instruction> (Val=0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99 > #4 0x083b6379 in isa<llvm::Instruction, const llvm::Value*> > (Val=@0xbf8000c0) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:114 > #5 0x083b608f in llvm::CallInst::classof(llvm::Value const*) (V=0x894e850) > at /mounts/zion/disks/0/localhome/pmeredit/llvm/include/llvm/iOther.h:110 > #6 0x08499213 in isa_impl<llvm::CallInst, llvm::Value> (Val=@0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:52 > #7 0x08499157 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Value const, > llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850) > at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69 > #8 0x08498ea7 in isa<llvm::CallInst> (Val=@0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80 > #9 0x08498b79 in isa<llvm::CallInst> (Val=0x894e850) at > /mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99 > #10 0x4001d1f6 in isa<llvm::CallInst> (Val=@0xbf800170) at > /localhome/pmeredit/llvm/include/Support/Casting.h:90 > #11 0x4001cfb3 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Use const, > llvm::Value*>::doit(llvm::Use const&) (Val=@0xbf800200) > at /localhome/pmeredit/llvm/include/Support/Casting.h:60 > #12 0x4001ca1c in isa<llvm::CallInst> (Val=@0xbf800200) at > /localhome/pmeredit/llvm/include/Support/Casting.h:80 > #13 0x4001c1ca in isa<llvm::CallInst, llvm::Use> (Val=@0xbf800200) at > /localhome/pmeredit/llvm/include/Support/Casting.h:114 > #14 0x4001baaa in dyn_cast<llvm::CallInst, llvm::Use> (Val={Val = 0x894e850, > U = 0x8917e48, Prev = 0x895a240, Next = 0x894e880}) > at /localhome/pmeredit/llvm/include/Support/Casting.h:223 > #15 0x4001af72 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8917e48) at MetaSplit.cpp:79 > #16 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x895ff40) at MetaSplit.cpp:88 > #17 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #18 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #19 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #20 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #21 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #22 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #23 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #24 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #25 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #26 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #27 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > #28 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x89609a8) at MetaSplit.cpp:88 > #29 0x4001b049 in (anonymous > namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998, > V=0x8930610) at MetaSplit.cpp:88 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote:> MetaSplit is an anlysis I just finished writing. It doesn't alter > anything, all it does is build a set of "program instructions". For > some reason even though if I run it with any other combination of > passes I've found, anytime I run it with mem2reg I get a seg fault in > dyn_cast! Here's output:Since the crash is after your code is entered, the problem is probably not in mem2reg, but in your pass. To see if that's the case, you can do this: % opt -mem2reg < orig.bc > m2r.bc % opt -load=... -metasplit < m2r.bc > output.bc And see if it crashes in mem2reg or in your pass. To narrow your testcase down further, we recommend the use of bugpoint, the automatic test case reducer: http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html In this case, this should work: % bugpoint -load=... -mem2reg -metasplit orig.bc -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu