search for: d30107

Hello, I was curious if there was any advice on how to get a code-review restarted/completed. The two I've submitted recently (D30107<https://reviews.llvm.org/D30107> D29923<https://reviews.llvm.org/D29923>) have gotten a bit of review but both then seem to stall. Any hints? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachment...

Thanks. I have gone that route and there was no response. What constitutes 'particularly urgent'? In regards to D30107<https://reviews.llvm.org/D30107> it some fairly obvious defect(s) and there are a few bugs open in your database about the issue, but it seems an area that doesn't get much interest (related to DynamicLibrary class). Thanks again. ________________________________ From: Robinson, Pau...

..._________________________ From: Robinson, Paul <paul.robinson at sony.com> Sent: Wednesday, March 8, 2017 2:05 AM To: Frederich Munch Cc: llvm-dev at lists.llvm.org Subject: RE: Restarting a stalled patch > Thanks. I have gone that route and there was no response. Well, I see you pinged D30107 and there were some comments yesterday. I don't see a ping on D29923 until today. Even with a ping, it can take a while. Not to discourage you, but I have known patches to sit for months waiting for review. > What constitutes 'particularly urgent'? I'd say, something that is...

I ran into a similar problem a while ago; see https://reviews.llvm.org/D30107 and https://reviews.llvm.org/D33515 .  You get the unusual stack trace because it's trying to call a destructor in shared library which was already unloaded. I thought we had fixed that, but maybe not?  Looking again, it looks like the patch got reverted and I didn't notice. -Eli On 5...

...thing with a similar setup. I believe it should now work properly, but would like to make sure that it'll pass before possibly adding a third commit/revert cycle. If the history isn't an issue, let me know an I'll just keep trying. The differential is here: https://reviews.llvm.org/D30107. FWIW, the errors have been from inconstancies with the ming available here: Slightly different header version causing a missing function. Mounted to a case insensitive volume. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

It's working with trunk though. Do you think the patch will end up in 6.0.1? Thanks. Simone On Tue, May 15, 2018 at 11:18 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > I ran into a similar problem a while ago; see https://reviews.llvm.org/ > D30107 and https://reviews.llvm.org/D33515 . You get the unusual stack > trace because it's trying to call a destructor in shared library which was > already unloaded. > > I thought we had fixed that, but maybe not? Looking again, it looks like > the patch got reverted and I didn'...

This is the correct path to the pass: https://github.com/PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/InstrumentParallel.cpp On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com> wrote: > Hi all, > > I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation > fault. > I was able to obtain only the info below from GDB. > >

Hi all, I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation fault. I was able to obtain only the info below from GDB. I tried to debug with some printf and the runOnFunction runs correctly. Any idea/suggestion about what is going on? The source code of the pass is here: https://github.com/PRUNERS/sword/blob/master/lib/Sword.cpp Any help is much appreciated, Thanks!