similar to: ABI change in LLVM 7.0.x release

On 02/05/2019 08:07 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers > wrote: >> Hi, >> >> The release_70 branch is ready for the 7.1.0 release. I have updated the >> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >> which is the only bug we will be fixing in this release. >> >>

Hi, The release_70 branch is ready for the 7.1.0 release. I have updated the version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, which is the only bug we will be fixing in this release. Since this is an ABI breaking changing and also we are introducing a minor version for the first time, please take some time to test the branch and make sure everything works as expected.

On 02/05/2019 11:26 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >> On 02/05/2019 08:07 AM, Michał Górny wrote: >>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers >>> wrote: >>>> Hi, >>>> >>>> The release_70 branch is ready for the 7.1.0 release. I have updated the

On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > On 02/05/2019 11:26 AM, Michał Górny wrote: > > > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: > > > > On 02/05/2019 08:07 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via

On Wed, 2019-02-06 at 14:09 -0800, Tom Stellard wrote: > On 02/05/2019 10:41 PM, Michał Górny wrote: > > On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > > > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > > > On 02/05/2019 11:26 AM, Michał Górny wrote: > > > > > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

Hi, LLVM 7.1.0 is now available! Download it now, or read the release notes. This release is an update to LLVM 7.0.1 with a fix for llvm.org/PR39427. This bug caused some applications to crash to due to an ABI mismatch for clang built applications linking against a gcc built libLLVM.so or vice versa. I order to fix this bug, we had to introduce an ABI change to libLLVM.so, so unlike most stable

Hi Martin, On Fri, 3 Aug 2018 at 14:10, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > $ git branch --list > * master > martino By default "git branch" only lists local branches. "git branch -a" will list all of them, including (for me) "remotes/origin/release_70". If you just type "git checkout release_70" git will

On Fri, 3 Aug 2018 at 11:42, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > A few months ago I switched from using SVN for the LLVM project to using the GIT mono-repo, but I am still not particularly good at using GIT. How can I use the GIT command-line interface to select to the exact same set of sources used for the v7.0.0 branch, Do you mean the commit

Hi, I have some IR module from random generation (mostly ineffective instructions). It has a function with void return, and two function arguments where one is a reference. Therefore, I expect every instruction not altering the value at the 2nd arguments address should be ineffective. Here is the function definition (see below for full ll): define void @_Z27entityMainDataInputCallbackdRd(double

On Fri, Aug 3, 2018 at 3:38 PM, <paul.robinson at sony.com> wrote: > Hi Hans, > > I was just trying to push a release note about DWARF v5 support. I did: > git checkout release_70 # in the monorepo > git commit <update to llvm/docs/ReleaseNotes.rst> > git llvm push > but that fails. How do you want to do release notes? I'm not familiar with "git

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I want to restart this discussion. There seemed to be support for this, > but we got held up trying to decide on the appropriate set of tags to > use to classify issues. > > I propose that we move forward with this proposal and disable creation of > new bugs in

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the

Hi, I've cross-posted this to freedesktop@, as the xdg@ list is only used for actual specification development. On Mon, 22 Oct 2018 at 00:36, Jacob Lifshay <programmerjake at gmail.com> wrote: > Hi, we were thinking of asking if freedesktop would host Kazan (https://github.com/kazan-3d/kazan) for us, however some of our community members have objections with how freedesktop's

Hi Bekket, Thank you for your reply. Earlier I came across a paper called "Dynamic Look Ahead Compilation: Hide JIT compilation latencies", it devised some methods for JIT compilation of functions before the actual call takes place by using call graph analysis, branch probabilities to generate a list of functions with high likelihood of execution in near future. In my opinion it

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more

Hi, I'm trying to use llvm/clang to cross compile to sparcv9. The following works with a -march=sparc, but yields errors for sparcv9. Are there some other flags that need to be specified? Thanks, Tarun > clang -m64 -emit-llvm test.c -c -o test.bc > llc -march=sparcv9 test.bc -o hello.s ExpandIntegerResult #0: 0x8a6c478: i64 = GlobalAddress<[4 x i8]* @.str> 0 [ORD=1] [ID=0] Do

Hey everyone, So I have an LLVM pass that appears to run completely and work fine, and then it aborts at the very end. When exiting the final runOnFunction call, I get the following error / stack dump. I cannot figure out why this is happening for the life of me - does anyone have any ideas? I'm not trying to do any crazy deallocation or anything, it just seems like a normal pass to me.