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 the DAG.
Call Stack:
SelectionDAGISel::runOnMachineFunction:339
SelectionDAGISel::SelectAllBasicBlocks:401
SelectionDAGISel::CodeGenAndEmitDAG:603
ScheduleDAGSDNodes::Run:36
ScheduleDAG::Run:61
ScheduleDAGRRList::Schedule::185
ScheduleDAGRRList::ListScheduleBottomUp:736
RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 ← exception here
I haven’t reported this as a bug because first I want to find out that in LLVM’s usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change?
Has this been fixed in 2.7?
Thanks
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 the DAG.
Call Stack:
SelectionDAGISel::runOnMachineFunction:339
SelectionDAGISel::SelectAllBasicBlocks:401
SelectionDAGISel::CodeGenAndEmitDAG:603
ScheduleDAGSDNodes::Run:36
ScheduleDAG::Run:61
ScheduleDAGRRList::Schedule::185
ScheduleDAGRRList::ListScheduleBottomUp:736
RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 ← exception here
I haven’t reported this as a bug because first I want to find out that in LLVM’s usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change?
I believe that’s precisely the problem.
Has this been fixed in 2.7?
No.
Evan
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 the DAG.
Call Stack:
SelectionDAGISel::runOnMachineFunction:339
SelectionDAGISel::SelectAllBasicBlocks:401
SelectionDAGISel::CodeGenAndEmitDAG:603
ScheduleDAGSDNodes::Run:36
ScheduleDAG::Run:61
ScheduleDAGRRList::Schedule::185
ScheduleDAGRRList::ListScheduleBottomUp:736
RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 ← exception here
I haven’t reported this as a bug because first I want to find out that in LLVM’s usage of the std::priority_queue, could the relative priorities get changed after they are inserted in the queue thus causing the order to change?
I believe that’s precisely the problem.
Has this been fixed in 2.7?
No.
I should mention Dan has fixed this as of r104718.
Evan
Huge thanks for a quick response and patch.