similar to: domain truncated

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,

U P O Z O R E N J E - D E T E K T O V A N V I R U S V I R U S A L E R T Nas antivirus softver pronasao je | Our viruschecker found the infected: I-Worm.Klez.h virus(e) u poruci koju ste poslali | virus(es) in your email na sledece adrese: | to the following recipient(s): tomicb@eunet.yu Molimo vas

https://bugs.freedesktop.org/show_bug.cgi?id=104728 Bug ID: 104728 Summary: [possible regression] VMD crashes on startup on GT 640 / GK107 / NVE7 Product: Mesa Version: 17.2 Hardware: All OS: All Status: NEW Severity: major Priority: medium Component:

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.

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

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

+ 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

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to

Looks like I can't access git, documentation, bugs... I'm not sure if this email will actually go through. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/e63b709a/attachment.html>

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

Aside from the fact that you're checking for i64 specifically instead of generally checking for illegal types, how much of this is really PPC specific? Would this be a reasonable enhancement to the SDAG logic in general? -Hal On 1/4/19 8:03 AM, Nemanja Ivanovic wrote: The changes seem fine to me. I don't think this is excessively intrusive and it accomplishes what is needed by targets

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

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

i removed printf from loop. Now getting no error. but the IR doesnot contain vectorized code. IR Output is as follows: ; ModuleID = 'sum-vec.ll' source_filename = "sum-vec.c" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: norecurse nounwind readnone uwtable define i32 @main(i32, i8**

Hi Brian, +1 on what Nemanja said: specifying large register classes is the key. More details here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html <http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html> Cheers, -Quentin > On Sep 9, 2020, at 11:13 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On PowerPC, we

I'm running CVS HEAD. The last time I updated was January 7th, at which time everything was fine. Having updated again today, January 17th, I'm having problems with IAX2. I use the "bindaddr" directive for both SIP and IAX2, and while SIP respects it, IAX2 doesn't. It listens on every interface, and uses every one of them for outgoing source addresses. This breaks IAX2

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

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

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