search for: scooters

There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that appears to get tripped on targets that don't have subregisters defined: bool SubUsed = false; for (const unsigned *SubRegs = TRI->getSubRegisters(Reg); unsigned SubReg = *SubRegs; ++SubRegs) if (isUsed(SubReg)) { SubUsed = true; break; }

Ugh. Management lobotomy kicked in. Need to RTFC better. On Thu, Feb 25, 2010 at 6:18 PM, Scott Michel <scooter.phd at gmail.com> wrote: > There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that > appears to get tripped on targets that don't have subregisters defined: > > bool SubUsed = false; > for (const unsigned *SubRegs =

No, I wasn't having a management lobotomy moment. If the target's registers have no subregisters, SubUsed is false and the assert gets tripped. Ok, back to the original question: What was the original intent in this code (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? -scooter On Thu, Feb 25, 2010 at 7:00 PM, Scott Michel <scooter.phd at gmail.com> wrote: > Ugh.

Thanks. Indeed - but is it it possible to block IP addresses on a per mountpoint level? For example, my user with /mountpointA.ogg does not mind being hammered by connections from 93.184.216.34 [example.com] but my user with /mountpointB.ogg wants to block that IP address. Using iptables I've blocked connections, at a server level, from example.com for my User B but my User A doesn't

Yup, I've got one remaining bug that holding up the CellSPU release. It still has a bunch of warts, but so long as I can get it into shape such that llvm-gcc-4.2 compiles all the way through, then we collectively have something with which to work. I'm getting the following error from llc, the attachments have llc's debug and the .ll files, respectively. Can anyone shed some

Jerome: No, there are no plans to JIT to SPU. That's considerably more complicated -- you'd have to figure out when to JIT to the SPU and live with all of the constraints that the SPU imposes (data reformatting, r/w DMA, ensure your code lives in 256K unless you can manage to interface with the virtual I-cache work.) Basically, it's not trivial and it doesn't quite fit into the

Thank very much for this answer, so my last question will be: is it possible to use the LLVM JIT on a PS3 with Yellow Dog 6.2 distribution, instead of the LLVM interpreter, by using the PPE as it seems to be similar to 64-bit PowerPC processors? 2009/12/18 Scott Michel <scooter.phd at gmail.com> > Jerome: > > No, there are no plans to JIT to SPU. That's considerably more

Checking in ParserInternals.h would probably be a good thing about now... because if you take this update, it doesn't compile. -scooter On Thu, Jan 1, 2009 at 11:12 PM, Chris Lattner <clattner at apple.com> wrote: > I just checked in a new parser for .ll files, deleting the old bison > parser. This means that the last of the ".cvs" files are gone from the > tree,

This is a scheduler assertion. It means a value (virtual register) use is somehow scheduled before its definition. Please run llc in gdb. Call dumpSchedule() to print out the schedule. Also please let me know which node it is processing at the time of the assertion. Evan On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: > Yup, I've got one remaining bug

Evan: What you requested was in the debug output (sans offending Node), but here it is, outside of the attachment. The offending node is highlighted: SU(0): 0xa908760: ch = EntryToken SU(1): 0xa907600: i32,ch,flag = CopyFromReg 0xa9095d0, 0xa9070e0, 0xa9095d0:1 0xa906e30: ch,flag = CopyToReg 0xa908760, 0xa9070e0, 0xa9071f0 <<--<<--<<--<<--<< Node

I just checked in a new parser for .ll files, deleting the old bison parser. This means that the last of the ".cvs" files are gone from the tree, which will hopefully make the world a happier place for windows users in particular. I tested it thoroughly but expect minor fallout, if you notice any problems, please let me know.

Hi Several questions below: a) is it possible to block IP addresses on a per mountpoint level e.g. my user with /mountpointA.ogg does not mind being hammered by connections from 93.184.216.34 [example.com] but my user with /mountpointB.ogg wants to block that IP address. b) is it possible to geoblock ranges of IP addresses and whole countries on a per mountpoint basis? c) what options do

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

Hello, Thank you for your help. I tried to follow steps on your link but it didn't work. I used this one : https://weekly-geekly.github.io/articles/350236/index.html I finish all steps but when i try to launch icecast with : su icecast2 -s /bin/bash icecast -c /usr/local/etc/icecast.xml I get this error : /usr/local/etc/icecast.xml: line 1: syntax error near unexpected token `newline'

Scott, In case you missed it, I reimplemented your BuildVectorSDNode::isConstantSplat method following the suggestions from Chris. The revised version passes "make check" for llvm. Assuming that it also passes Evan's tests, I think it should also do what you need for CellSPU. On Feb 25, 2009, at 12:16 PM, Scott Michel wrote: > Evan: > > I work on reverting it,

Many thanks for this Philipp. On Mon, 13 Jan 2020 at 14:01, Philipp Schafft <phschafft at de.loewenfelsen.net> wrote: > I would recommend against that. It just adds another single point of > failure. Most software I know for that kind of analysis can in fact read > multiple files anyway. (e.g. some wants to import the data into it's own > database first, other just want to

Sorry, still not enough information. I am guessing it's asserting in getVR() called from EmitNode()? The node is CopyToReg and it's trying to find the virtual register of operand 2? From the schedule, I don't see the definition of the operand. Can you do DAG.viewGraph()? That should gives us a better idea. Evan On Oct 16, 2007, at 9:06 PM, Scott Michel wrote: > Evan: >

Who's your advisor? -scooter (aka "Dr. B. Scott Michel, UCLA CS 2004" :-) On Apr 12, 2007, at 4:39 PM, Fernando Magno Quintao Pereira wrote: > >>> And I have a quite fast algo that I believe is simpler than >>> [Budimlic02] >>> and I can share it with you :) >> >> Do you have a paper on this? I'd be interested in seeing it.

Hello Chip, I have no error in my file. I also test my previous XML file that was working and it say the same error : line 1: syntax error near unexpected token `newline' /usr/local/etc/icecast.xml: line 1: `<icecast>' BR, Ceelo On Fri, Mar 20, 2020 at 3:27 PM Chip <chiapas at aktivix.org> wrote: > Syntax error in your conf file. > > Check it from the command