similar to: [LLVMdev] MSVC iterator debugging exception and RegReductionPriorityQueue V2.6

On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. > > When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn’t. > > Recently, we have started to see this error in

On May 26, 2010, at 3:26 PM, Evan Cheng wrote: > > On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > >> We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. >> >> When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will

I'm reposting this patch at the request of Evan. It fixes a problem with std::priority_queue and _GLIBCXX_DEBUG. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: schedule_dag.diff Type: text/x-diff Size: 7731 bytes Desc: not available URL:

Attached is a patch to fix a GLIBCXX_DEBUG error in ScheduleDAGRRList. The problem is that calls to CapturePred may reprioritize elements in the priority queue, violating streak weak ordering requirements. To fix this, I introduced a reference wrapper for containers to obtain access to the SUnitVec used by std::priority_queue. When CapturePred runs, it calls updateNode which does a

It's not building: usr/include/c++/4.0.0/bits/stl_queue.h: In member function 'void std::priority_queue<_Tp, _Sequence, _Compare>::push(const typename _Sequence::value_type&) [with _Tp = llvm::SUnit*, _Sequence = ll\ vm::container_reference_wrapper<std::vector<llvm::SUnit*, std::allocator<llvm::SUnit*> > >, _Compare = <unnamed>::td_ls_rr_sort]':

Hello, Still trying to write a custom scheduler, I stumbled accross a highly suspicious code in all schedulers. In both ScheduleDAGFast.cpp and ScheduleDAGRRList.cpp, one can find this piece of code: SUnit *CopyFromSU = CreateNewSUnit(NULL); and then in the same files: SUnit *CreateNewSUnit(SDNode *N) { [...] SUnit *NewNode = NewSUnit(N); And finally in ScheduleDAGSDNodes.cpp: SUnit

Hey Everyone, I'd like to begin a project to rework the scheduler to address some problems we've discovered on this end. The goal is to get a more configurable/flexible scheduler while simplifying maintenance by separating policy from implementation to get independent and interchangeable parts. This is going to be challenging because we are still stuck on LLVM 2.9. We will be upgrading

On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > I was studying the basic register allocator, and I am wondering why > "LessSpillWeightPriority" priority was used over the greater weight. Because the front of std::priority_queue is the largest element given the ordering.

I understand the mechanics. I don't know why a lesser weight is better than a greater weight. On Thu, Oct 28, 2010 at 7:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > >> I was studying the basic register allocator, and I am wondering why >> "LessSpillWeightPriority" priority was used over the

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

Bill Wendling wrote: > On Dec 30, 2008, at 4:51 PM, srs wrote: > > >> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >> mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in >> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >> >> As a work-around, I commented out the debug

Hello, is there any one who uses C++ STL classes when programming shared libs for R and has had any problems with STL? In the very simple example below I am constantly getting segfaults when trying to populate the queue. The segfault occurs at what looks like a random index in the loop when pushing another element to the queue. Reproduced on 4 machines. Object x is an Image as in EBImage,

Hi all, While testing my compiler on win32 in JIT mode, I ran into a couple of issues: 1. I linked the compiler with the lib files resulting from the cmake created VS.NET build. While everything built just fine, the ExecutionEngine::create call always returned NULL. The fix was to also link with JIT.obj (thanks aKor for pointing me in the right direction). I would have thought that linking

On Dec 31, 2008, at 5:57 AM, srs wrote: > Bill Wendling wrote: >> On Dec 30, 2008, at 4:51 PM, srs wrote: >> >> >>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>> mode. The problem is the evaluation of "&SUnits[0];" which >>> ASSERT's in >>> VC++'s vector[] implementation (when

Bill Wendling wrote: > On Dec 31, 2008, at 5:57 AM, srs wrote >> Bill Wendling wrote: >> >>> On Dec 30, 2008, at 4:51 PM, srs wrote: >>> >>> >>> >>>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>>> mode. The problem is the evaluation of "&SUnits[0];" which

Hi Dave, This looks great to me! My only concern is the potential compile time impact. Do you see any? Also, please update the license portion to match what Chris sent out a couple of days ago. I don't see any issue with bringing Boost code into llvm tree. However, does it make sense to move the license to the top of the file? Chris? Evan On Dec 17, 2007, at 10:17 AM, David Greene

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

Hi, At the moment the same test is being ran twice - same output so pointless! I believe this may not be what was intended. The change below runs the virtual register test the second time on the Predecessor SUnit. Robert diff --git a/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp b/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp index f5fe168..6e888da ---

On Apr 20, 2012, at 10:31 AM, dag at cray.com wrote: > I'd like to begin a project to rework the scheduler to address some > problems we've discovered on this end. The goal is to get a more > configurable/flexible scheduler while simplifying maintenance by > separating policy from implementation to get independent and > interchangeable parts. > > This is going to be

Hi all, I'm currently investigating a bug which is causing an assert to fail in lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp. See https://llvm.org/bugs/show_bug.cgi?id=28753 for repro information. To my knowledge, this problem only occurs with the SystemZ target. I'm trying to determine whether the issue is the result of an edge case in the scheduling code itself, or if it's a