search for: eliben

...the old configure script. I've updated the PR - maybe the OP had the same problem. FWIW, Pete, the --enable-curses option to configure no longer exists. configure just ignores it. Chandler removed it in r188160. Eli > Thanks, > Pete > On Sep 6, 2013, at 9:09 PM, Eli Bendersky <eliben at gmail.com> wrote: > > Hello, > > I'm trying to build some code that relies on LLVM as a library > (out-of-source). It uses llvm-config for the compilation & linkage flags. > Some recent change breaks it, and with the newest trunk LLVM I get: > > /home/eliben/ll...

Hello, I'm trying to build some code that relies on LLVM as a library (out-of-source). It uses llvm-config for the compilation & linkage flags. Some recent change breaks it, and with the newest trunk LLVM I get: /home/eliben/llvm/build_llvm_svn_rw/Debug+Asserts/lib/libLLVMSupport.a(Process.o): In function `terminalHasColors': /home/eliben/llvm/llvm_svn_rw/lib/Support/Unix/Process.inc:256: undefined reference to `setupterm' /home/eliben/llvm/llvm_svn_rw/lib/Support/Unix/Process.inc:274: undefined reference to `t...

Hi Eli I don’t know a workaround which will keep support for coloured terminal output, but if you can live without it then passing these to configure should work. --enable-curses=no --enable-terminfo=no Thanks, Pete On Sep 6, 2013, at 9:09 PM, Eli Bendersky <eliben at gmail.com> wrote: > Hello, > > I'm trying to build some code that relies on LLVM as a library (out-of-source). It uses llvm-config for the compilation & linkage flags. Some recent change breaks it, and with the newest trunk LLVM I get: > > /home/eliben/llvm/build_llv...

...the source tree and not using RegisterPass causes opt to not recognize your command-line arguments. Do you know of any other projects that will demonstrate how to build passes out of tree, only creating an analysis group as well? Thanks Jeremy On Thu, Jun 12, 2014 at 4:20 PM, Eli Bendersky <eliben at google.com> wrote: > > > > On Thu, Jun 12, 2014 at 1:10 PM, Jeremy Salwen <jeremysalwen at gmail.com> > wrote: > >> Hello all, >> >> I'm trying to follow the guide >> http://llvm.org/docs/WritingAnLLVMPass.html to build an some passes and &...

...ugh tests (and enough of them) for this very important feature. Therefore, as an interim stage, I propose to adopt some external tool that parses DWARF and emits decoded textual dumps which makes tests easy to write. Concretely, I have a pure Python library named pyelftools (https://bitbucket.org/eliben/pyelftools) which provides comprehensive ELF and DWARF parsing capabilities and has a dumper that's fully compatible with the readelf command. Using pyelftools would allow us to immediately improve the quality of our tests, and as lib/DebugInfo matures llvm-dwarfdump can gradually replace the d...

On Wed, Aug 14, 2013 at 1:15 PM, Tim Northover <t.p.northover at gmail.com>wrote: > > If anyone is interested in this support, I'd appreciate it if you changed > > your setup to use Python3 for running the tests and let me know (or file > > bugs) for any issues you find. > Great work, Daniel. All LLVM tests pass for me on trunk when running with Python 3.4 alpha.

On Wed, Aug 14, 2013 at 1:46 PM, Eli Bendersky <eliben at google.com> wrote: > > Now get rid of pre-2.6 Python support ;-) Not only it helps clean-up code, > by 2-and-3 coexistence is much easier. > > It looks like Daniel was able to add py3k support fairly cleanly. I'm not sure how much of a difference removing pre-2.6 support w...

On Fri, Jul 29, 2016 at 10:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 July 2016 at 17:50, Eli Bendersky <eliben at google.com> wrote: > > While I think the 6-month mark is artificial (what's wrong about a vague > > "several months"? these are policies/guidelines, not legal contracts), > > I'm ok with that, too. > > Though, what do you think about the "2 month...

Ping? On Thu, Feb 28, 2013 at 12:59 PM, Eli Bendersky <eliben at google.com> wrote: > Hi, > > While doing various profiling runs of llc, it's easy to notice that > some wall-clock time is not accounted for by -time-passes (e.g. only 7 > out of 9.2 seconds for compiling gcc). Some of the "lost" time is in > reading the bitcod...

On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 4/17/2013 12:15 PM, Eric Christopher wrote: > > Give a compelling argument and I might :) > > The cost is the extra time spent verif...

...N trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at gmail.com>; eliben at gmail.com; llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org; Rafael Espíndola <rafael.espindola at gmail.com> Subject: Re: [cfe-dev] [llvm-dev] How to debug if LTO generate wrong code? On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com<mailto:st...

Whoops... Seems I forgot the asterisk (*) after the cast. Or something. Because I did insert the cast and it didn't work. But NOW it works. Thank you for spending some time on this - and also for presenting the solution. -- Mikael 2013/12/4 Eli Bendersky <eliben at google.com> > This code: > > declare i32 @printf(i8* nocapture readonly, ...) nounwind > > define i32 @bar(i8* %c, i32 %i) #0 { > entry: > %call = tail call i32 (i8*, ...)* @printf(i8* %c, i8* %c) > ret i32 %call > } > > Is accepted without complaints by...

> On Jun 24, 2015, at 10:19 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Wed, Jun 24, 2015 at 7:05 AM, Q Z <zhaoqian301 at gmail.com <mailto:zhaoqian301 at gmail.com>> wrote: > Hello，I want to compile a large project(for example,Apache httpd) to one .bc file. How can I do this? Can you give me some exampl...

...mware > > Tel: +86 021-61166522 > iNet: 821-6522 > > <>From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > Sent: Monday, May 30, 2016 2:13 PM > To: Shi, Steven <steven.shi at intel.com> > Cc: Umesh Kalappa <umesh.kalappa0 at gmail.com>; eliben at gmail.com; llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org; Rafael Espíndola <rafael.espindola at gmail.com> > Subject: Re: [cfe-dev] [llvm-dev] How to debug if LTO generate wrong code? > > > On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at...

> > This reflects the compiler's view of things correctly, but is problematic > for a debugger. The debugger should know that arg_arr refers to a 42-element > array and isn't just a pointer into a buffer of unspecified length. This is > something the user would expect. > > On the other hand, the debugger should also get the information that > arg_arr is actually a

On Jan 17, 2013, at 10:30 AM, Eli Bendersky <eliben at google.com> wrote: > On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> >>> On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at p...

On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 4/17/2013 12:15 PM, Eric Christopher wrote: > >> >> Give a compelling argument and I might :) >> > > The cost is the extra time spent verifying that the binaries are fresh. > In my experience it has never happened that I ran "make check" on a wrong >

Hi, While doing various profiling runs of llc, it's easy to notice that some wall-clock time is not accounted for by -time-passes (e.g. only 7 out of 9.2 seconds for compiling gcc). Some of the "lost" time is in reading the bitcode file (~ 1 sec). When reading textual IR, its parsing actually takes almost as much time as doing the actual -O0 compilation! I think it would be useful

On Fri, Jan 18, 2013 at 3:13 PM, Eli Bendersky <eliben at google.com> wrote: > >> > I'm fine with this as long as llvm-dwarfdump gets maintained. > >> > > >> > >> I agree, and as I said in the original email, in the long term I > >> believe llvm-dwarfdump is the correct solution. > >>...

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it...