search for: addrange

...ruction. In LiveIntervalAnalysis::addIntervalsForSpills, we have this: if (HasUse) { LiveRange LR(getLoadIndex(index), getUseIndex(index), nI.getNextValue(~0U, 0, VNInfoAllocator)); DOUT << " +" << LR; nI.addRange(LR); } Should this actually extend from the load index to the def index since value intervals are exclusive at end? Otherwise, the interval for the spill doesn't include the use of the reloaded register, which doesn't make sense to me. I think this probably went unnoticed bec...

..." > SETINFO input.frequency "49.9" > SETINFO input.voltage "224.1" > SETINFO input.voltage.fault "223.6" > SETINFO output.voltage "223.6" > SETINFO ups.beeper.status "enabled" > SETINFO ups.delay.shutdown "30" > + ADDRANGE ups.delay.shutdown 12 600 > + SETFLAGS ups.delay.shutdown RW > SETINFO ups.delay.start "180" > + ADDRANGE ups.delay.start 0 599940 > + SETFLAGS ups.delay.start RW > SETINFO ups.load "3" > SETINFO ups.productid "0003" > SETINFO ups.status "OL&q...

...ysis::addIntervalsForSpills, we have this: > > if (HasUse) { > LiveRange LR(getLoadIndex(index), getUseIndex(index), > nI.getNextValue(~0U, 0, VNInfoAllocator)); > DOUT << " +" << LR; > nI.addRange(LR); > } > > Should this actually extend from the load index to the def index since > value intervals are exclusive at end? Otherwise, the interval for > the spill > doesn't include the use of the reloaded register, which doesn't > make sense to > me....

...tructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange* llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*): Assertion `B->end <= Start && "Cannot overlap two LiveRanges with differing ValID's" " (did you def the same reg twice in a MachineInstr?)"' failed. has this following call stack: #3 in llvm::LiveInterval::addRange...

...led from LiveIntervalAnalysis.cpp, 360: for (unsigned i = 0, e = vi.Kills.size(); i != e; ++i) { MachineInstr *Kill = vi.Kills[i]; LiveRange LR(getInstructionIndex(Kill->getParent()->begin()), getUseIndex(getInstructionIndex(Kill))+1, ValNum); interval.addRange(LR); DEBUG(std::cerr << " +" << LR); When I add assert(mi2iMap_.count(Kill)); in that block, it fires. I have modified the LiveVariables class so that in the end of runOnFunction method, it prints all the instructions which are in Kill sets, but are not in the...

On Aug 13, 2012, at 8:34 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > Yes, this is what Arnold has suggested also, and from this point it looks > like it should work, but it will require parsing the bundle every time we > care to know whether this is a real use or a conditional def. This might > become awkward... but I guess I should provide a better

> If 3.9 shipped with these issues (assuming these are not false positive), it would be interesting to 1) know why the sanitizers didn’t catch it, and 2) add valgrind to the release qualification process (CC Hans). Yes, I'd be interested to see some corroboration. Note that the issue here is pretty specific: it only happens during optimized compile using Clang-3.9. This is all I did:

...DDCMD test.battery.start.deep 20.419722 send_to_all: ADDCMD test.battery.start.quick 20.419736 send_to_all: ADDCMD test.battery.stop 20.419752 send_to_all: SETINFO ups.delay.start "180" 20.419768 send_to_all: SETFLAGS ups.delay.start RW 20.419788 send_to_all: ADDRANGE ups.delay.start 0 599940 20.419805 send_to_all: SETINFO ups.delay.shutdown "30" 20.419820 send_to_all: SETFLAGS ups.delay.shutdown RW 20.419836 send_to_all: ADDRANGE ups.delay.shutdown 12 600 20.419852 No values for battery high/low voltages 20.419871 send_...

On Mar 5, 2015, at 2:34 AM, Jakub <jakub.scepka at gmail.com> wrote: > Come on, it started to be interesting! Do you have one of these UPSes? If so, here was Dan's email about a branch to test: > If you still can't get it to work with nutdrv_atcl_usb, another > approach could be worth considering. > > Since this UPS seems to be supported by UPSmart2000I, it could

...turn 1.023457 send_to_all: ADDCMD shutdown.stayoff 1.023478 send_to_all: ADDCMD shutdown.stop 1.023494 send_to_all: ADDCMD test.battery.start.quick 1.023511 send_to_all: SETINFO ups.delay.start "180" 1.023528 send_to_all: SETFLAGS ups.delay.start RW 1.023557 send_to_all: ADDRANGE ups.delay.start 60 599940 1.023575 send_to_all: SETINFO ups.delay.shutdown "30" 1.023591 send_to_all: SETFLAGS ups.delay.shutdown RW 1.023607 send_to_all: ADDRANGE ups.delay.shutdown 12 540 1.023624 No values for battery high/low voltages 1.023642 send_to_all: SETINFO bat...

...an assert in LiveInterval > update. On the surface it does not make much sense to me, so I wonder > if this is something you readily recognize, before I try to prop it > open... > > The assert is: > > lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange* > llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*): > Assertion `B->end <= Start && "Cannot overlap two LiveRanges with > differing ValID's" " (did you def the same reg twice in a > MachineInstr?)"' failed. > > has this following call stack: > >...

Thank you for the rapid response. I will try and investigate getting answers to some of your points but I'm a little new to Solaris so I'll need some time. Glancing at the configure output, it looks like it built against v0.1.7 of libusb (yes i think that is derived from the one you mention), checking for libusb version via pkg-config... 0.1.7 found checking for libusb cflags... checking