search for: init_al

Ok so I made a lot of changes and the controls sample works pretty good now. What I changed or added: - Got all my modifications meshed into wxRuby2. - Added constructors to wxIcon.h - Changed Xrc.i to XmlResource.i and changed wxXrc to wxXmlResource within the file. I also had to change Xrc to XmlResource in rakewx.rb. - For backwards compatability with wxRuby 0.6 I added the subclass methods

I've made quite a bit of progress getting bugpoint to work with our (non-gcc) tools. In fact I caught the alignment bug I recently posted about using it. But it's not there yet. In particular, I am seeing this scenario a lot (comments in brackets): *** Found miscompiling pass: -instcombine Emitted bitcode to 'bugpoint-passinput.bc' [ Good! This is progress! ] *** You can

The Intel C++ compiler has long had an internal facility to help our development teams track down the source of optimization related bugs by allowing a sort of binary search in which optimization passes and even individual optimizations are selectively disabled in response to front end command line options. As we've been doing development work on LLVM our developers have found that we miss

Hi Andy, > On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The Intel C++ compiler has long had an internal facility to help our development teams track down the source of optimization related bugs by allowing a sort of binary search in which optimization passes and even individual optimizations are selectively disabled in response

> On Mar 25, 2016, at 11:56 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Andy, > >> On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> The Intel C++ compiler has long had an internal facility to help our development teams track down the

Hi Mehdi, I started by trying to implement a single number approach, but it doesn't allow quite the approach I wanted in terms of isolating individual functions. Also, I think that there would be problems with that once parallel function optimization is enabled. I am open to revisiting that approach to see if the problems I had with it can be resolved. -Andy From: mehdi.amini at apple.com

> On Mar 25, 2016, at 12:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > > Hi Mehdi, > > I started by trying to implement a single number approach, but it doesn’t allow quite the approach I wanted in terms of isolating individual functions. Do you have an example where it matters? I wonder if there are enough real-world use case that justify the complexity?

> On Mar 25, 2016, at 12:10 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 25, 2016, at 11:56 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Andy, >> >>> On Mar 25, 2016, at 11:41 AM, Kaylor, Andrew via llvm-dev <llvm-dev at

Maybe someone on the list who knows about GHC internals (I don't) can chime in here, but GHC has (had?) a concept of "optimization fuel": http://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/ that is very similar to what Mehdi is suggesting. -- Sanjoy On Fri, Mar 25, 2016 at 12:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >

Andy, I'd love to see this feature. I wouldn't care too much wether the interface is a single number or two numbers, but if possible print the name of the function and the name of the pass that was just skipped so the developers knows where to start looking. - Matthias > On Mar 25, 2016, at 12:13 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi

> In the swift-world we use utils/bisect + a single number all the time + extra verifications. It works really well. Can you describe to me what you mean by that exactly? Are you using the single number in the LLVM back end or somewhere else? From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Michael Gottesman via llvm-dev Sent: Friday, March 25, 2016 12:35 PM To:

> On Mar 25, 2016, at 4:30 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Andy, > > I'd love to see this feature. I wouldn't care too much wether the interface is a single number or two numbers, but if possible print the name of the function and the name of the pass that was just skipped so the developers knows where to start looking. We do

And as we are on the topic of bisecting/diagnosing scripts I attached my personal script I used before. You give it two directories with assembly files (typically from a known good compiler and a "bad" compiler). The script will then go on and create permutations by picking all files from the "good" directory and combining them with a single file form the "bad"

I will describe the complete process for completeness thus hopefully forestalling all questions [tell me if I did not ; )]. There is not much to it TBH. ./utils/bisect is a dumb python script that allows for arbitrary bisecting via the exit status of a script it runs . The way you use it is you write a script (lets call it test.sh). Then you invoke: ./utils/bisect --start=N --end=M ./test.sh

Ok I cleaned it up and added some explaining comments. It's in llvm/utils/abtest now. - Mathias > On Mar 25, 2016, at 4:40 PM, Michael Gottesman <mgottesman at apple.com> wrote: > > >> On Mar 25, 2016, at 4:37 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: >> >> And as we are on the topic of bisecting/diagnosing

> On Mar 25, 2016, at 4:37 PM, Matthias Braun <matze at braunis.de> wrote: > > And as we are on the topic of bisecting/diagnosing scripts I attached my personal script I used before. > > You give it two directories with assembly files (typically from a known good compiler and a "bad" compiler). The script will then go on and create permutations by picking all files

I've worked on a compiler with a counter, but for individual optimisations, not just passes. It was incredibly useful! In the llvm world, it would let you bisect exactly which instcombine, dagcombine, or whatever causes an issue. I support the addition of a pass counter if it helps bisecting, but just wanted to point out that this can be as fine grained as the community is willing to accept.

I agree that the more fine grained this becomes the more useful it can be. I’ve updated my prototype to use a single number approach. I’m going to clean this up and post a review in the next day or two. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pete Cooper via llvm-dev Sent: Friday, March 25, 2016 10:22 PM To: Matthias Braun <matze at braunis.de> Cc:

Hi Greg, Thanks for your input! I’d love to see this evolve into something that would let us track problems to individual IR changes. My thinking is that starting with passes gives us something that will get us maybe 70% of the functionality in one easy step, then individual passes can be instrumented as anyone has time or need to get us the rest of the way there. Your max_opt option sounds

Hi everybody, I am new to rails. I get the following error when run the rake engine:migrate for the engine login_engine. ------------------------------------------------------------------------ gbalaji:~/projects/test/vendor/plugins/login_engine gopalbalaji$ rake engine_migrate ENGINE=log --trace (in /Users/gopalbalaji/Projects/test) ** Invoke engine_migrate (first_time) ** Invoke