Karl Rupp <r...@iue.tuwien.ac.at> writes: > Yes, you can. Since the scheduler will sooner or later be directly > interfaced from C, it needs to do quite careful error-checking anyway.
Right, I shall do that. > There is no general 'rule' on when to use one over the other and depends > on the particular project. I tend to use assertions to indicate logic > errors, but there are other projects which don't use any assertions at > all. For very small, performance-critical functions like value access > via operator(), assert() is preferable over exceptions, because it does > not incur any runtime penalty in optimized mode (there's always some > conditional required for an exception, while an assert() is totally > removed by the preprocessor). I don't think there is any such > performance-critical path in the scheduler, so feel free to > use/introduce a suitable exception type. Thanks for this; I hadn't thought about the performance implications of exception handling -- and, of course, assert is much more transparent in that regard. Having fixed up a layout consistency check, I seem to have hit a real scheduler bug. I'm currently reading the code myself with a view to a fix, but since you wrote it, I suspect you'd be quicker. I've written a C++ program that produces a seg-fault: http://paste.ubuntu.com/6030580/ The backtrace is: (gdb) run Starting program: /home/toby/src/viennacl/pyviennacl-dev/build/bin/bugfix warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff5d40700 (LWP 23647)] [New Thread 0x7ffff483b700 (LWP 23648)] [New Thread 0x7ffff403a700 (LWP 23649)] [New Thread 0x7ffff3839700 (LWP 23650)] [New Thread 0x7ffff3038700 (LWP 23651)] [New Thread 0x7ffff2837700 (LWP 23652)] Node 0: LHS: DOUBLE_TYPE, DENSE_ROW_MATRIX_TYPE (0x7fffffffe220), OP: OPERATION_BINARY_INPLACE_ADD_TYPE, RHS: COMPOSITE_OPERATION_FAMILY(1) Node 1: LHS: DOUBLE_TYPE, HOST_SCALAR_TYPE (2.718), OP: OPERATION_BINARY_MULT_TYPE, RHS: DOUBLE_TYPE, DENSE_ROW_MATRIX_TYPE (0x7fffffffe220) Program received signal SIGSEGV, Segmentation fault. 0x0000000000574ac8 in viennacl::scheduler::detail::execute_composite (s=..., root_node=...) at /home/toby/src/viennacl/pyviennacl-dev/viennacl/scheduler/execute.hpp:47 47 if (leaf.op.type == OPERATION_BINARY_ADD_TYPE || leaf.op.type == OPERATION_BINARY_SUB_TYPE) // x = (y) +- (z) where y and z are either data objects or expressions (gdb) bt #0 0x0000000000574ac8 in viennacl::scheduler::detail::execute_composite (s=..., root_node=...) at /home/toby/src/viennacl/pyviennacl-dev/viennacl/scheduler/execute.hpp:47 #1 0x0000000000574bca in viennacl::scheduler::detail::execute_composite (s=..., root_node=...) at /home/toby/src/viennacl/pyviennacl-dev/viennacl/scheduler/execute.hpp:74 #2 0x0000000000575712 in viennacl::scheduler::detail::execute_impl (s=..., root_node=...) at /home/toby/src/viennacl/pyviennacl-dev/viennacl/scheduler/execute.hpp:223 #3 0x000000000057584b in viennacl::scheduler::execute (s=...) at /home/toby/src/viennacl/pyviennacl-dev/viennacl/scheduler/execute.hpp:240 #4 0x0000000000546f93 in main () at /home/toby/src/viennacl/pyviennacl-dev/examples/pyviennacl/bugfix.cpp:312 Best, Toby ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
