Mailman 3 August 2011 - cython-devel

Re: [Cython] GCC 4.6 unused-but-set-variable warnings
by Stefan Behnel Aug. 4, 2011

Aug. 4, 2011

[moving this here from cython-users] Nikolaus Rath, 13.06.2011 16:59: > Stefan Behnel writes: >> Nikolaus Rath, 13.06.2011 01:18: >>> Stefan Behnel writes: >>>> Nikolaus Rath, 03.06.2011 23:24: >>>>> Cython 0.14 generated code triggers lots of unused-but-set-variable >>>>> warnings (which are new in GCC 4.6). >>>> >>>> Hmm, that's annoying. We actually generate a lot of useless "dangling >>>> reset to 0" statements for safety (and also as a bit of a "now unused" >>>> hint to the C compiler). >>>> >>>> We could get rid of most of them based on control flow analysis, but I >>>> actually like having them there, just in case we accidentally generate >>>> broken code at some point. A NULL pointer is a lot safer than an >>>> arbitrarily dangling address, especially when it comes to CPython heap >>>> allocated memory (which doesn't necessarily get freed, so you may not >>>> get a quick segfault but a read from dead memory). >>> >>> I don't quite understand. The way to get rid of the warnings is to >>> remove the unnecessary variables. How can this result in a dangling >>> address? You'll get a syntax error from gcc about using an undeclared >>> variable. >> >> Ah, sorry. I misunderstood the meaning of the warning message as >> pointing at unnecessary assignments in general. Could you post a C >> code snippet (and the corresponding Cython code) that triggers this? I >> don't have gcc 4.6 available for testing. > > Sure. It's apparently triggered by unused function arguments: > > $ cat test.pyx > class Operations(object): > def handle_exc(self, fn, exc): > pass > > $ cython test.pyx > > $ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c test.c -o test.o -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -Werror -Wall -Wextra -Wconversion -Wno-unused-parameter -Wno-sign-conversion -fno-strict-aliasing test.c: > test.c:454:13: warning: variable ‘__pyx_v_exc’ set but not used [-Wunused-but-set-variable] > test.c:453:13: warning: variable ‘__pyx_v_fn’ set but not used [-Wunused-but-set-variable] > test.c:452:13: warning: variable ‘__pyx_v_self’ set but not used [-Wunused-but-set-variable] http://trac.cython.org/cython_trac/ticket/704 I think this is something that the control flow analysis could deal with. Basically, every parameter that turns out to be unused in the function (and this most likely only happens with parameters) could be ignored, unless it requires a type conversion with potential side effects. In that (unlikely) case, we could still drop the final assignment to the variable itself. Stefan

2 15

Cython 0.15rc2 and parallelization issue
by Francesc Alted Aug. 3, 2011

Aug. 3, 2011

Hi, I'm trying to take advantage of the exciting new parallelizing capabilities recently introduced in forthcoming 0.15 version, but I'm having a small difficulty. When I try to compile a small demo routing (attached), I'm getting this error: $ cython -a mandel.pyx Error compiling Cython file: ------------------------------------------------------------ ... for pix in prange(num_pixels, nogil=True, schedule="dynamic"): x = pix % width y = pix // width cr = begin_r + (x * span_r / (width + 1.0)) ci = begin_i + (y * span_i / (height + 1.0)) n = MandelbrotCalculate(cr, ci, maxiter) ^ ------------------------------------------------------------ mandel.pyx:50:31: Calling gil-requiring function not allowed without gil While trying to figure out why MandelbrotCalculate does require GIL, I replaced the "for prange", by a trivial "for range", and the annotated HTML source reveals that the only line in (light) yellow in this function is return n which is translated as: /* "mandel.pyx":22 * ti = 2*zr*zi + ci * zr, zi = tr, ti * return n # <<<<<<<<<<<<<< * * @cython.boundscheck(False) */ __pyx_r = __pyx_v_n; goto __pyx_L0; __pyx_r = 0; __pyx_L0:; __Pyx_RefNannyFinishContext(); return __pyx_r; } My guess is that this __Pyx_RefNannyFinishContext() call is preventing to call the routing from the parallel loop. Is that a bug, a limitation of current implementation or it is just that I'm missing something? Thanks, -- Francesc Alted

3 5

Cython 0.15 release candidate
by Robert Bradshaw Aug. 2, 2011

Aug. 2, 2011

Cython has seen an enormous amount of development since 0.14.1. If you are not already using the latest version from the development repository, we encourage you to try out the release candidate: http://cython.org/release/Cython-0.15rc0.tar.gz - Robert

8 12

OpenMP problem
by Vitja Makarov Aug. 1, 2011

Aug. 1, 2011

I've tried openmp support with simple example: from cython.parallel cimport prange def mul(values): ret = 1 for i in prange(values): ret *= i return ret And cython crashes: ((b04e040...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ make mul.so /usr//bin/python ../cython.py --gdb -v mul.pyx -o mul.c Compiling /home/vitja/work/cython-vitek/zzz/mul.pyx Error compiling Cython file: ------------------------------------------------------------ ... from cython.parallel cimport prange def mul(values): ret = 1 for i in prange(values): ^ ------------------------------------------------------------ mul.pyx:5:26: stop argument must be numeric or a pointer (perhaps if a numeric literal is too big, use 1000LL) Error compiling Cython file: ------------------------------------------------------------ ... from cython.parallel cimport prange def mul(values): ret = 1 for i in prange(values): ^ ------------------------------------------------------------ mul.pyx:5:19: Compiler crash in AnalyseExpressionsTransform ModuleNode.body = StatListNode(mul.pyx:1:0) StatListNode.stats[0] = DefNode(mul.pyx:3:0, modifiers = [...]/0, name = u'mul', num_required_args = 1, reqd_kw_flags_cname = '0', used = True) File 'Nodes.py', line 337, in analyse_expressions: StatListNode(mul.pyx:4:4, is_terminator = True) File 'Nodes.py', line 6553, in analyse_expressions: ParallelRangeNode(mul.pyx:5:19, assigned_nodes = [...]/1, is_parallel = True, is_prange = True, valid_keyword_arguments = [...]/3) Compiler crash traceback from this point on: File "/home/vitja/work/cython-vitek/Cython/Compiler/Nodes.py", line 6553, in analyse_expressions self.index_type, node.type) File "/home/vitja/work/cython-vitek/Cython/Compiler/PyrexTypes.py", line 2624, in widest_numeric_type elif type1.rank < type2.rank: AttributeError: 'PyObjectType' object has no attribute 'rank' make: *** [mul.c] Ошибка 1 rm mul.c ((b04e040...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ -- vitja.

5 7