similar to: Did anything weird happen to the git monorepo?

On Wed, Mar 06, 2019 at 07:26:42AM -0500, Pete Geenhuizen wrote: > > On 03/02/2019 05:41 AM, Phil Perry wrote: > > > >Hi Gerry, > > > >I've updated the nvidia 340xx legacy package set for el7.6, and > >released the packages to the elrepo testing repository. > > > >Please could you test them and let me know if they work as > >expected. To

On 06/03/2019 19:30, Pete Geenhuizen wrote: > > > On 03/06/2019 09:59 AM, Fred Smith wrote: >> >>> I tried to install this and ran into a conflict >>> >>> --> Processing Conflict: >>> nvidia-x11-drv-340xx-340.107-2.el7_6.elrepo.x86_64 conflicts ocl-icd >>> --> Finished Dependency Resolution >>> Error: nvidia-x11-drv-340xx

On 06/03/2019 21:53, Pete Geenhuizen wrote: > > > On 03/06/2019 04:21 PM, Phil Perry wrote: >> On 06/03/2019 19:30, Pete Geenhuizen wrote: >>> >>> That is all good and well, but my problem is that I now can't install >>> >>> vlc smplayer mplayer, or? ffmpeg-libs because they need >>> ocl-icd-2.2.12-1.el7.x86_64from epel.

On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote: > >> I've got this PseudoOp defined: >> >> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; >> def XSTGRELADDR :

On 27/02/2019 20:34, Phil Perry wrote: > On 27/02/2019 20:29, Jerry Geis wrote: >>> I'll see if I can find some time this weekend to fix the elrepo package >>> and get it reinstated into the repository. >> >>> Phil >> >> >> Hi Phil, Thanks for the reply. Your correct this is OLD hardware. >> Everything was working with 7.5 thought I

On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 1/13/2016 4:47 PM, Phil Tomson wrote: > >> >> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an >> LLVM Backend: Lowering to multiple instructions. (now I'm having my >> doubts as to whether this is the right approach) >> > >

Not sure who owns this bit of code, so sending this to the general list. It looks like there may be an unintentional fall through happening in the X86RegisterInfo::getCallPreservedMask function. http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html case CallingConv::Intel_OCL_BI

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC

Hi, building 'check-all' on any of my machines running OS X 10.10 usually fails because a few tests fail due to some processes being killed by the kernel (there's always "Killed: 9" somewhere in lit's error output). Everything's fine on 10.9. How do folks deal with this? Don't use 10.10 for building llvm? Is there some tweakable to tell the kernel "please

(resend to the list) And of course, just as I say that, my next ninja build shows the line only once. On reflection I am less sure that the lack of a [N/M] line means they are from the same invocation. Surely ninja could spawn two links, which then independently report "Creating library" after ninja emits the [N/M] lines. --paulr From: llvm-dev [mailto:llvm-dev-bounces at

Since there's no "[2663/3121] " line between the two messages, the two lines are from the same link.exe invocation. I don't know why link.exe thinks it needs to print this line twice, ninja doesn't have anything to do with it. On Mon, Nov 19, 2018 at 6:57 PM <paul.robinson at sony.com> wrote: > I'm more concerned about seeing the message come out twice, which

On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > > > On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: > > On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > >> Hi Nico, >> >> Sorry for the delay, I've been OOO. The llvm-cov bot should produce >> reports for llvm-undname starting today. >>

On Fri, Sep 4, 2015 at 12:46 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 10:27 AM, Nico Weber via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi, >> >> building 'check-all' on any of my machines running OS X 10.10 usually >> fails because a few tests fail due to some processes being killed by the

On Mon, Jun 10, 2019 at 2:11 PM <vsk at apple.com> wrote: > > > On Jun 6, 2019, at 9:56 AM, Nico Weber <thakis at chromium.org> wrote: > > On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > >> >> >> On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: >> >> On Mon, Jun 3, 2019 at 2:06 PM <vsk at

The monorepo prototype at https://github.com/llvm-project/llvm-project-20170507 is currently 9 hours behind. I forget who’s responsible for the script(s) updating the monorepo(s), and it would be great if we can inform them of the state of the monorepo. Cheers -- Dean

Hi folks, I recently started getting errors when I fetch from the github monorepo ( https://github.com/llvm-project/llvm-project-20170507). They look like this: $ git fetch error: cannot lock ref 'refs/tags/release_600': there is a non-empty directory '.git/refs/tags/release_600' blocking reference 'refs/tags/release_600' >From

What do you see as the pros and cons of making it a stable target? Does anyone else have any concerns about doing so? -Chris > On Feb 14, 2020, at 7:59 AM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +better dylanmckay address > > On Fri, Feb 14, 2020 at 10:58 AM Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> wrote:

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

Hello,my system info: virsh verison Compiled against library: libvirt 3.9.0 Using library: libvirt 3.9.0 Using API: QEMU 3.9.0 Running hypervisor: QEMU 2.10.90 And i want to pass through my gpu to my window 7 guest with <hostdev>, next line is comand i use: <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'>

On Tue, Sep 1, 2020 at 3:57 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Sep 1, 2020 at 12:42 PM Nico Weber <thakis at chromium.org> wrote: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org>