similar to: [RFC] Python 2 / Python 3 status

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

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

> De : 陳韋任 [chenwj at iis.sinica.edu.tw] > Date d'envoi : mardi 8 mai 2012 11:37 > À : Rinaldini Julien > Cc: LLVM Developers Mailing List > Objet : Re: [LLVMdev] RE : svn trunk comilation error > > Hi Rinaldini, > > You probably need to illustrate what your enviroment is, what revision you > checkout and how you build LLVM. I have no problem build LLVM svn here.

> De : 陳韋任 [chenwj at iis.sinica.edu.tw] > Date d'envoi : mardi 8 mai 2012 11:37 > À : Rinaldini Julien > Cc: LLVM Developers Mailing List > Objet : Re: [LLVMdev] RE : svn trunk comilation error > > Hi Rinaldini, > > You probably need to illustrate what your enviroment is, what revision you > checkout and how you build LLVM. I have no problem build LLVM svn here.

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

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. Change all #! lines to say

I'm trying to build llvm from svn. I ran ./configure with --enable-debug-runtime, then make -j4, before I got the following error: llvm[1]: Building llvm-config script. make[1]: Leaving directory `/home/vk/opt/llvm/tools/llvm-config' make[1]: Entering directory `/home/vk/opt/llvm/tools/llvm-config-2' llvm[1]: Constructing LLVMBuild project information. Traceback (most recent call

At the beginning of the year, I've landed a large set of patches to support both Python 2 and Python3 in most Python scripts. Looks like I missed some of them :-) At that time, backward portability with Python2 was still relevant, and I suspect it will still be the case for a few distributions that ship Python2 by default. That being said, Even RHEL8 uses Python3 by default, so at some point

IMO, having non-critical utility scripts require python 3 should be allowed now. But, not yet for any scripts which are critical to build or test the distributed components. If we need to spend some time to fix the test runner to allow properly skipping tests of python3-only components when python3 isn't available, that seems entirely worthwhile, since we only need to do that once. On Tue,

I define "critical" as: anything which is required to build or test any components which are part of a release. The intent being that we DO continue to support python 2 for building llvm, and for end-users of llvm, for now. However, developers of LLVM can be assumed to be able to install python3 if they want to be able to run these various optional, auxiliary, scripts. Having a unit

It sounds like you ran into a bug in the test infrastructure's code to determine if python3 is supported. Fixing that might be harder, but it only needs to be fixed once no matter how much more python3 development there will be. Right now, most of our scripts were originally written for python 2, so certainly it's easy for them to support python 2. But, it was a lot of work by various

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

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

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 actually modifying it. It took ~20 pass fixes to achieve that goal, as many passes were not respectful of that contract, but as of

> Out of curiosity, does change here include changes to names, and other semantically-irrelevant changes (e.g., changing the order of operands in a PHI)? The hashing function used to detect changes is currently very simple: it only accounts for instruction opcode and order. So some semantically-irrelevant changes are ignored (as well as some relevant changes), and some are not. Permuting two

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, I'd like to ask for some advise about adding a backend. I followed the steps at http://llvm.org/docs/WritingAnLLVMBackend.html (also adding the backend to the configure script, so it compiles (on Linux) with LLVM 3.1. However, llvm-build fails with: llvm[0]: Constructing LLVMBuild project information. Usage: llvm-build [options]

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via

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