similar to: Is llvm.org down?

There seems to be an issue with DNS: > nslookup llvm.org ;; Got SERVFAIL reply from 192.168.178.1, trying next server Server: 192.168.178.1 Address: 192.168.178.1#53 ** server can't find llvm.org: NXDOMAIN -- AlexDenisov Software Engineer, https://lowlevelbits.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16)

Hi, My target has a special configuration register that many instructions read implicitly, configuring for example if an add instruction should saturate at over/underflow or not. Now, I have a problem where the MachineCSE removes a setting of this configuration register in a basic block, because MachineCSE::isPhysDefTriviallyDead can't find any uses of it in the basic block where

Hi, everyone, I'm currently the code owner for the PowerPC target. I worked on the PowerPC target for many years, and that was a lot of fun, but I've not been directly involved in development for PowerPC for some time. I would like to nominate Nemanja Ivanovic for the role of PowerPC target code owner. Insofar as a code owner is responsible for making sure that patches are reviewed,

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.

I'm not sure exactly what you're after. I was under the impression that you want to know which register is live at a specific point (an instruction). If that's the case, how do one of the two suggested solutions not suffice? If a register is live-in to a block and not killed before your instruction or it has a def and no kill within the block, it is live. Otherwise it is dead and

On 03/30/2016 11:51 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >> >> Hi, >> >> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>> >>>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>>> <mailto:mikael.holmen at

Thanks for the reduced test case, I’ll try to take a look by the end of the week. > On Feb 20, 2019, at 6:53 PM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Finally managed to reduce this to something manageable: https://godbolt.org/z/Hw529k <https://godbolt.org/z/Hw529k> > > On line 40 of the output, we have a load-immediate to put zero into R3. Then we

> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > Hi, > > On 03/30/2016 11:38 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>> <mailto:mikael.holmen at ericsson.com>> wrote: >>> >>> i16 (divm16_pseudo …) >>>

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at

This is likely due to a race condition (%T is a shared parent directory). I'll put up a patch to fix it. On Thu, Sep 3, 2020 at 10:00 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is the machine running any jobs in parallel? Would it be worth trying running lit in the loop, rather than the script? (perhaps lit's doing something interesting) or maybe the

On 07/15/2019 04:01 AM, Mikael Holmén via llvm-dev wrote: > Hi, > > Same thing for me, as I described here: > > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190708/279184.html > > I think the problem is that the patch assumes that if sys/inotify.h > exists, then IN_EXCL_UNLINK is defined in it. > > But I think that there are old versions of inotify.h

I do have a reproducer, but it's not for the faint of heart :) This is from a large and messy C file (Perlbench's regexec.c), reduced by bugpoint down to 1050 lines of IR. Perhaps I can paste it on pastebin. Just for fun, I added some debug dumps for machine instructions that spill registers (i.e. return non-zero from MachineInstr::getFoldedSpillSize()) that are fed by load-immediates and

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

Well, I am at my wit's end. I have copied over the script and directories for this test case and run it a few million times. First I was running one at a time, then I switched to kicking off 1000 at a time. All the while, the bots continued to run on the same machine. The script never failed even once. I am not sure if this has something to do with Python as part of llvm-lit or what is going

I think that was maybe the discussion on https://reviews.llvm.org/D78245 On Thu, Sep 3, 2020 at 6:22 PM Robinson, Paul <paul.robinson at sony.com> wrote: > I have a vague memory that libcxx wanted it for something, and claimed it > would be hard to work around not having it. > > Anyone else remember that? I can’t dredge up the details, sorry… > > In any event, a separate

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t

Hi, A few days ago I stumbled upon a problem where SpeculativeExecution changed the order of a load and a store to the same address. I wrote https://bugs.llvm.org//show_bug.cgi?id=32964 about it but no response there so far. In the input we have store i8 0, i8* @i %.pre = load i8, i8* @i and then in the output the load is moved so it's before the store which clearly makes it

Hi, I'm trying to run the benchmark suite: http://llvm.org/docs/TestingGuide.html#test-suite-quickstart I'm doing it the lnt way, as described at: http://llvm.org/docs/lnt/quickstart.html I don't know what to expect but the results seems to be quite noisy and unstable. E.g I've done two runs on two different commits that only differ by a space in CODE_OWNERS.txt on my 12