similar to: rsync overall progress patch

After the extended discussion I think it's in a pretty good shape now: https://reviews.llvm.org/D61550 Any further comments? > On 4. May 2019, at 11:32, Alex Denisov <1101.debian at gmail.com> wrote: > > The final draft is now published and awaiting your comments or approval :) > > https://reviews.llvm.org/D61550 > >> On 15. Apr 2019, at 16:01, Alex Denisov

Hi folks, I want to update the Release Notes for the release/9.x, but seems like 'git llvm push' only supports commits to the master/trunk. What's the current process for such patches? Thanks, Alex. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL:

> I looking for a solution to display overall rsync progress on an LCD display as a bargraph. > I have found 2 parameters: > > --progress > This option tells rsync to print information showing the > progress of the transfer. This gives a bored user something to > watch. Implies --verbose if it wasn't already specified. >

> It's not the job of the Orc engine. I could argue about this, but I won’t :) > Just don't use atexit. The problem is that I run third-party programs. I cannot control them. > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >> JIT

Hello, I looking for a solution to display overall rsync progress on an LCD display as a bargraph. I have found 2 parameters: --progress This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. Implies --verbose if it wasn't already specified.

Hi folks, At EuroLLVM we had a round table for organizers of LLVM Socials around the globe. After the discussion we decided to get some sort of guidelines for those who want to organize the meetup in their city, but have any questions and don't know where to start. Currently, I am creating the very first draft. Once it's in a good shape I will send it to the phabricator. I am looking

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote: >

Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute the constructors straight away, rather than naming them and looking them up

Appreciations for the initiative! There are some people in the Berlin C++ user group [1] who may be interested. Also there was an active compiler meetup group [3] a few years ago. As far as I know these guys mostly joined the Strange Group Berlin [2], but may still be interested in a more compiler-focused meetup. For the people cc'd: please let us know who'd like to participate in a LLVM

Hi folks, I’m trying to port some code built on top of LLVM/Clang to Windows, however I just discovered that the precompiled versions from releases.llvm.org are missing all the libLLVM* and libclang* dlls. Also, some tools (e.g. opt) are missing on Windows as well. I’m curious whether it’s a technical limitation (i.e. certain things don’t work on Windows), or something else? For the others out

Hello everyone, My name is Alex, I'm hobbyist compiler hacker who lives in Berlin, Germany now. I'm thinking about organising "LLVM Social" meetups in Berlin, however I don't really know how many people are here, and how many of them are interested in getting in touch. If you want to participate or have any questions - feel free to answer to this thread, or to send me a

Hello everyone, I observe a weird behavior switching from clang-4 to clang-5 (and any higher version). I compile an executable that depends on LLVM. Everything works fine with clang-4, but when I run the executable compiled with clang-5 I see the following error: : CommandLine Error: Option 'rewrite-map-file' registered more than once! LLVM ERROR: inconsistency in registered CommandLine

On 31 May 2018 at 08:41, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I understand the linking problem. What I do not understand is how to debug the difference between two versions of compilers. > This what I do (briefly): > > clang++-4 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib > > clang++-5 foobar.cpp -lLLVM -l/opt/llvm-3.9/lib If you add -v then Clang will

> On Nov 15, 2019, at 1:52 AM, Alex Denisov <1101.debian at gmail.com> wrote: > >> I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. > > IIRC, the -p option of 'patch' is exactly for doing this. Would that simplify your use-case? > Yes, for a single patch that would work. If there is a way to do

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

Hi Geoff, hi Alex If you implement the GDB JIT Interface in your Orc JIT, this is in general possible (at least from the JIT's point of view) with both debuggers, GDB and LLDB. Please have a look at the example here: https://github.com/weliveindetail/JitFromScratch/tree/jit-debug/gdb-interface You will probably need to adjust the code depending on the LLVM version you are using. As described

Hi everyone, I’m working with the LLVM C API now. I see that several functions are deprecated, however the only notion is in comments around the function. Is there any specific reason why __attribute__((deprecated)) is omitted? Will it make sense to send a patch with such additions? -- AlexDenisov Software Engineer, http://lowlevelbits.org -------------- next part -------------- A non-text

Hello everybody, I am trying to do some static analysis, e.g. find which other functions accessible from a function. Current naive implementation goes over each instruction and whether it is a call site or not. It works great so far, but there are some cases where it doesn’t work. For example: declare no_source(function: f) // uses f internally define foo() { ... } define bar() { ... }

Hi there, I’m curious is there any (official or not) communication channel for upcoming EuroLLVM? If there is none besides mailing lists and IRC, shall we then setup something like Slack? -- AlexDenisov Software Engineer, https://lowlevelbits.org