search for: guelton

On Fri, Nov 30, 2018 at 03:25:10PM +0100, Serge Guelton via llvm-dev wrote: > On Thu, Feb 01, 2018 at 04:47:03PM -0500, James Y Knight via llvm-dev wrote: > > That said, I do think it could make sense to prepare llvm for the world in > > which "python" is python3 on some systems. So, I'd propose the following: > > 1. C...

...evant changes are ignored (as well as some relevant changes), and some are not. Permuting two independant instructions is not ignored, while permuting the operands of a sub is ignored. On Wed, Jul 15, 2020 at 4:55 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 7/15/20 3:33 AM, Serge Guelton via llvm-dev wrote: > > Hi folks, > > some more information on this feature - as a reminder I started one month > ago to work on an expensive check that would verify that pass return status > is correctly reported by passes, i.e. no pass return « IR not modified » > while actu...

Hi folks, Python2 has reached end of support[0], and many core Python packages are dropping pthon 2 support[1]. This is a subject that raises periodically on this mlist, with a rather strong no in 2018 [-1] and a slow move in 2019 [-2, -3]. Even if Python is not a core build requirement, it's used during some configurations steps (e.g. in the cmake export_executable_symbols function), for

The next LLVM social in Paris will happen on January 30th, 2018. Everyone interested in LLVM, Clang, lldb, Polly, lld, ... is invited to join. Event details, including registration (free but mandatory) at http://www.meetup.com/LLVM-Clang-social For this meetup, Adrien Guinet, Serge Guelton and Juan Manuel Martinez will talk about the "Challenges when building an LLVM bitcode obfuscator", based on their 4 years experience building an industrial strength code obfuscator for C/C++ and Objective C. Looking forward to meet you ! -- Arnaud de Grandmaison, Duncan Sands, Sylvestre...

...t further regression on that topic. Thanks a lot to @foad, @jdoerfert, @fhahn, @calixte (and others I'm sorry to forgot) for their help during the reviews. On Fri, Jun 12, 2020 at 11:24 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Thu, Jun 11, 2020 at 8:42 AM Serge Guelton via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> Per the documentation[0], whenever an LLVM pass doesn't modify the IR >> it's run on, it >> should return `false`--it's okay to return `true` if no change happen, >>...

Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic), As a follow-up to that old thread about -D_FORTIFY_SOURCE=n http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE support is claimed to be only partial: https://pagure.io/fesco/issue/2020 I dig into the glibc headers in

Hi Folks, Although LLVM now relies on cmake for its build configuration, it still calls an external Python script, namely llvm-build, to manage component dependecies, activation or deactivation of target componenents and generating description for llvm-config. This system is documented in http://llvm.org/docs/CommandGuide/llvm-build.html and https://llvm.org/docs/LLVMBuild.html. Several

...l https://llvm.org/releases/10.0.0/projects/libcxx/docs/ReleaseNotes.html Special thanks to the release testers and packagers: Alexandre Ganea, Andrew Kelley, Anil Mahmud, Bernhard Rosenkraenzer, Brian Cain, Dimitry Andric, Martijn Otto, Michael Kruse, Michał Górny, Neil Nelson, Rainer Orth, Serge Guelton, Sylvestre Ledru, Tobias Hieta, and Yvan Roux. Without your work, this release would not be possible. For questions or comments about the release, please contact the community on the mailing lists. Onwards to LLVM 11! And take care. Thanks, Hans

...l https://llvm.org/releases/10.0.0/projects/libcxx/docs/ReleaseNotes.html Special thanks to the release testers and packagers: Alexandre Ganea, Andrew Kelley, Anil Mahmud, Bernhard Rosenkraenzer, Brian Cain, Dimitry Andric, Martijn Otto, Michael Kruse, Michał Górny, Neil Nelson, Rainer Orth, Serge Guelton, Sylvestre Ledru, Tobias Hieta, and Yvan Roux. Without your work, this release would not be possible. For questions or comments about the release, please contact the community on the mailing lists. Onwards to LLVM 11! And take care. Thanks, Hans

Hi folks, Per the documentation[0], whenever an LLVM pass doesn't modify the IR it's run on, it should return `false`--it's okay to return `true` if no change happen, just less optimal. In the New PM area, this is generally translated into a `PreservedAnalyses::all()`. https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that computes a hash of the IR before and after the

...ma at quicinc.com> wrote: > Are you sure you've diagnosed the issue correctly? __builtin___memcpy_chk > works correctly, as far as I know. > > -Eli > > > -----Original Message----- > > From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Serge > Guelton via > > cfe-dev > > Sent: Tuesday, December 3, 2019 2:07 AM > > To: cfe-dev at lists.llvm.org > > Cc: llvm-dev at lists.llvm.org > > Subject: [EXT] [cfe-dev] clang and -D_FORTIFY_SOURCE=1 > > > > Hi folks (CCing llvm-dev, but that's probably more of a c...

Hi folks, today, I wanted to concatenate two .ll, and naively typed: $ llvm-cat -help This is the not-so-helpful output I had: OVERVIEW: Module concatenation USAGE: llvm-cat [options] <input files> OPTIONS: General options: -aarch64-neon-syntax - Choose style of NEON code to emit from AArch64 backend: =generic

On 2020-01-29, Reid Kleckner via llvm-dev wrote: >On Wed, Jan 29, 2020 at 2:27 AM Serge Guelton via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> My personal take on this would be to start moving forward. Still >> supporting both >> version this year, but obsoleting Python 2.7 and requiring, say Python 3.6, >> starting January 2021 looks like a good c...

On Mon, Oct 03, 2016 at 09:04:15AM +0200, Joerg Sonnenberger via llvm-dev wrote: > On Sun, Oct 02, 2016 at 11:09:08PM +0000, Zachary Turner via llvm-dev wrote: > > The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have LLVM > > 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8. > > Open BSD has a very old GCC, but distrowatch claims that

On Mon, Mar 02, 2015 at 12:12:34AM -0500, John Criswell wrote: > On 3/2/15 12:07 AM, Haopeng Liu wrote: > >Got it, thanks. But in my pass, I use function name to locate. Can I > >disable mangling in clang? > > No, but you can probably fine a library that can either mangle the original > name or demangle the name you're seeing in the LLVM bitcode. > > As an FYI,

Hi llvm-dev, Every now and then, when building a direct ``CallInst`` either from IRBuilder or through ``Create*``, I have a latent bug because the calling convention (CC) expected by the function is not set on the call, and I need to manually call ``setCallingConv``. Now, from LangRef#calling-conventions, The calling convention of any pair of dynamic caller/callee must match, or the

On 10 Sep 2015, at 10:09, serge guelton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 10, 2015 at 04:20:01PM +0800, Dipanjan Das via llvm-dev wrote: >> Hello, >> >> I can see the occurrences of several LLVM intrinsic functions in the LLVM >> IR generated by llvm-dis disassembler. I...

> I agree. If a pass modifies the IR in any way, even temporarily, it was changed (at some point). I'd like to +1, but when doing the migration of the code base to enable the associated expensive check, I found situations where (B) was used. On Sat, Jul 18, 2020 at 5:20 AM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 7/17/20 2:57 PM, Roman

Hi all, I'm a beginner in LLVM. Currently, I want to implement a pass that generates a jump table. The entry in that table is a jump to some place (may be an instruction) in a basic block. I'm reading the JumpTable code in llvm 3.5, there is a table which contains jump entries to functions. In AsmPrinter::doFinalization function from file lib/CodeGen/AsmPrinter/AsmPrinter.cpp, it gets a

Hi Folks, Now that LLVM 11.0.0 has been released, it's time to prepare for the final step envisionned in the previous RFC named *[RFC] Python 2 / Python 3 status* [0], ie. requiring Python3.6 for LLVM 12.0.0, to be released in 2021. At least Fedora already only ships Python3 and we didn't have much bugs reported wrt. Python compatibility for the LLVM toolchain. Indeed, all Python scripts