[Cython] Compilation failes if a class member is named "INFINITY"
Hello,
if I try to compile the following minimal example:
cdef class Test:
cdef readonly int INFINITY
cython does not complain but gcc refuses with an error message:
In file included from /usr/include/math.h:38:0,
from /usr/include/python2.7/pyport.h:325,
from /usr/include/python2.7/Python.h:58,
from testinf.c:16:
testinf.c:433:7: error: field '__builtin_inff' declared as a function
int INFINITY;
^
testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__':
testinf.c:569:50: error: expected identifier before '(' token
__pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if
(unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10;
__pyx_clineno = __LINE__; goto __pyx_L1_error;}
^
Apparently the name "INFINITY" is handled wrongly; any other variable
name seems to be fine.
Regards,
Michael
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compilation failes if a class member is named "INFINITY"
Am 31.01.2015 um 19:48 schrieb Matthew Brett:
> Hi,
>
> On Fri, Jan 30, 2015 at 1:49 AM, Michael wrote:
>> Hello,
>>
>> if I try to compile the following minimal example:
>>
>> cdef class Test:
>>
>> cdef readonly int INFINITY
>>
>> cython does not complain but gcc refuses with an error message:
>> In file included from /usr/include/math.h:38:0,
>> from /usr/include/python2.7/pyport.h:325,
>> from /usr/include/python2.7/Python.h:58,
>> from testinf.c:16:
>> testinf.c:433:7: error: field '__builtin_inff' declared as a function
>>int INFINITY;
>>^
>> testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__':
>> testinf.c:569:50: error: expected identifier before '(' token
>>__pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if
>> (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10;
>> __pyx_clineno = __LINE__; goto __pyx_L1_error;}
>> ^
>> Apparently the name "INFINITY" is handled wrongly; any other variable
>> name seems to be fine.
>
> Maybe you hit the INFINITY gcc macro?
>
> http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
Yes, that's probably the explanation. So should Cython do anything about
the problem, i.e. raise an exception if struct members are named like a
macro?
I don't know about the Cython internals, but I wonder why the name not
altered in the c file:
struct __pyx_obj_7testinf_Test {
PyObject_HEAD
int INFINITY;
};
I would have expected something like "int __pyx_member_INFINITY"?
Michael
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compilation failes if a class member is named "INFINITY"
Am 05.02.2015 um 10:44 schrieb Stefan Behnel:
> Michael schrieb am 05.02.2015 um 09:52:
>> Am 31.01.2015 um 19:48 schrieb Matthew Brett:
>>> On Fri, Jan 30, 2015 at 1:49 AM, Michael wrote:
>>>> if I try to compile the following minimal example:
>>>>
>>>> cdef class Test:
>>>>
>>>> cdef readonly int INFINITY
>>>>
>>>> cython does not complain but gcc refuses with an error message:
>>>> In file included from /usr/include/math.h:38:0,
>>>> from /usr/include/python2.7/pyport.h:325,
>>>> from /usr/include/python2.7/Python.h:58,
>>>> from testinf.c:16:
>>>> testinf.c:433:7: error: field '__builtin_inff' declared as a function
>>>>int INFINITY;
>>>>^
>>>> testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__':
>>>> testinf.c:569:50: error: expected identifier before '(' token
>>>>__pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if
>>>> (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10;
>>>> __pyx_clineno = __LINE__; goto __pyx_L1_error;}
>>>> ^
>>>> Apparently the name "INFINITY" is handled wrongly; any other variable
>>>> name seems to be fine.
>>>
>>> Maybe you hit the INFINITY gcc macro?
>>>
>>> http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
>>
>> Yes, that's probably the explanation. So should Cython do anything about
>> the problem, i.e. raise an exception if struct members are named like a
>> macro?
>
> Cython cannot know about everything that the C compiler (or its
> preprocessor) will eventually see in its flat namespace. So, no, Cython
> can't generally solve this problem for you.
>
>
>> I don't know about the Cython internals, but I wonder why the name not
>> altered in the c file:
>> struct __pyx_obj_7testinf_Test {
>> PyObject_HEAD
>> int INFINITY;
>> };
>> I would have expected something like "int __pyx_member_INFINITY"?
>
> Python extension types are just structs at the C level, and struct member
> names cannot be mangled. Plus, when types are external or public (or even
> just redeclared somewhere else by someone else), foreign code may depend on
> struct fields of extension types as well. Builtin types are an example.
>
Ok, that makes sense. I'll just choose a different name then. :-)
Michael
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compilation failes if a class member is named "INFINITY"
Am 05.02.2015 um 12:30 schrieb Greg Ewing: > Stefan Behnel wrote: >> Python extension types are just structs at the C level, and struct member >> names cannot be mangled. > > Well, in principle it *could* mangle the names in > structs that aren't declared "cdef extern". I didn't > do that in Pyrex because it didn't seem necessary; > I hadn't anticipated problems like collision with > macros. > > It's probably too late to change it now, since it > would break existing code that interoperates with > foreign code. > To me, that sounds like a too complicated solution for a marginal problem. It's a bit odd that you can't use special names like INFINITY for cdef class members, but on the other hand, I think that's a reasonable restriction since you are generating C code, and in C you can't name a struct member INFINITY either (at least with gcc). ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
AC�LIO JO�O CARLOS MOREIRA DE CARVALHO AMORIM NETO
GOULART JUCIMARA VICENTE DOS SANTOS, DAMIANA PEREIRA DE OLIVERIA, ANA ANGELICA PEREIRA ALVES, PAULO DE SIQUEIRA SILVA. PAULO DE SIQUEIRA SILVA. AMAURI CLIFE, ELEUTÃRIO LEAL, LEAL CORLETTO, CLIFE ACÃLIO LEAL. ELEUTÃRIO GOULART, VICTOR DI MELLO, JAVERT MONTEIRO, NELSON DANTAS, DANIEL DE OLIVEIRA, RICARDO CORTE REAL, FLÃVIO SILVINO, LUIS GUSTAVO, BABU SANTANA, SERAFIM GONZALEZ, HARILDO DEDA, MARCOS FROTA, CARLOS VERGUEIRO, PAULO GIARDINI, ELIEZER MOTTA, JULIANO CAZARRÃ, ANDERSON LAU ANTUNES, ACILINO. AFONSO CLÃUDIO, INDAIABIRA, FERNANDO PEDROZA IGARATINGA. AMAURI ANTUNES, ACILINO. AFONSO CLÃUDIO, INDAIABIRA, FERNANDO PEDROZA JOÃO CARLOS MOREIRA DE CARVALHO OURO VERDE DE MINAS PAULO DE SIQUEIRA SILVA BALDOMERO GOULART, CLIFE LEAL. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] cython --cplus --embed generates invalid code
Hi, on my system, --embed does not work with --cplus. How to reproduce: Any valid pyx file works: $ rm -f test.pyx; touch test.pyx $ cython --embed --cplus test.pyx $ g++ -c test.cpp -I/usr/include/python3.4m test.cpp: In function ‘wchar_t* __Pyx_char2wchar(char*)’: test.cpp:945:41: error: invalid conversion from ‘void*’ to ‘wchar_t*’ [-fpermissive] res = malloc(argsize*sizeof(wchar_t)); $ clang++ -c test.cpp -I/usr/include/python3.4m test.cpp:945:9: error: assigning to 'wchar_t *' from incompatible type 'void *' res = malloc(argsize*sizeof(wchar_t)); The issue can easily be fixed by manually casting the malloc result to (wchar_t *). In C it is not recommended to cast the malloc result, while in C++ it is required (and malloc is discouraged). System info: $ cython --version Cython version 0.21.1 $ g++ --version g++ (Debian 4.9.2-2) 4.9.2 $ python3 --version Python 3.4.2 $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux unstable (sid) Release:unstable Codename: sid ~ Michael signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython produces invalid C code
Hi everybody, Cython 0.21.1, from Debian Sid, and Cython 0.22, from Gentoo, produce invalid C Code for the following .pyx file: $ cat test.pyx cimport cpython cdef extern from "test.h": cdef void foo(int i = 0) def bar(self): foo(0) $ cat test.h void foo(int i); $ cython test.pyx $ gcc -c test.c -I/usr/include/python3.4m test.c: In function ‘__pyx_pf_4test_bar’: test.c:659:35: error: storage size of ‘__pyx_t_1’ isn’t known struct __pyx_opt_args_4test_foo __pyx_t_1; $ clang test.c -I/usr/include/python3.4m test.c:659:35: error: variable has incomplete type 'struct __pyx_opt_args_4test_foo' struct __pyx_opt_args_4test_foo __pyx_t_1; test.c:659:10: note: forward declaration of 'struct __pyx_opt_args_4test_foo' struct __pyx_opt_args_4test_foo __pyx_t_1; Note that this is a minimal example; removing anything from test.pyx fixes the issue (the 'cimport' statement, the default value for int i, and the call to foo). The issue also occurs with --cplus. Happy debugging, mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython produces invalid C code
Hi, On 23/04/15 06:25, Robert Bradshaw wrote: > I've made this an explicit error. thanks; I hope this will save future users some WTFs. ~mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Misleading error message when assigning function pointers with differing except* declarations
Hi, consider the following example: $ cat demo.pyx cdef void (*foo)() cdef void bar() except*: pass foo = bar $ cython demo.pyx Error compiling Cython file: ... cdef void (*foo)() cdef void bar() except*: pass foo = bar ^ demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)' this is all expected behavior, but the error message is entirely misleading; it should be something like demo.pyx:6:9: Function pointers have incompatible 'except *' declarations. Note that the same error message also occurs when the pointer is declared except*, and the function isn't. ~ mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython generates invalid C code for some generator expressions in cdef functions
Take the following example: $ cat t2.pyx cdef void read_callback(): foo = b"asdf" bar = (c for c in foo) $ cython t2.pyx $ gcc -I/usr/include/python3.4m t2.c t2.c: In function ‘__pyx_f_2t2_read_callback’: t2.c:778:12: error: ‘None’ undeclared (first use in this function) return None; ^ t2.c:778:12: note: each undeclared identifier is reported only once for each function it appears in t2.c:778:5: warning: ‘return’ with a value, in function returning void return None; ^ Note that the error does not occur for bar = (c for c in b"asdf") or bar = [c for c in b"asdf"] ~ mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Feature request: Expose methods to fake stack traces
Hi everybody, my C++ exceptions contain some stack trace information (starting with __FILE__ and __LINE__), and I'd like to preserve that information in my custom 'except+' translator. Cython seems to have some internal methods to fake Python stack trace objects, but research (and an unanswered question on the Users list [https://groups.google.com/forum/#!topic/cython-users/9coFCVwigpE]) seems to imply that this functionality is not currently exposed. I'd like to see that internal functionality exposed for usage from .pyx files. ~ mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython produces invalid code for operator()
Hi guys,
have a look at this:
$ cat bar.pyx
cdef extern from "foo.h":
cdef cppclass Foo:
int operator() (int arg)
int do_call (int arg)
cdef int bar(int arg):
cdef Foo foo
foo.do_call(arg)
return foo(arg)
$ cython3 --cplus bar.pyx
$ cat bar.cpp
(...)
static int __pyx_f_3bar_bar(int __pyx_v_arg) {
Foo __pyx_v_foo;
int __pyx_r;
__Pyx_RefNannyDeclarations
__Pyx_RefNannySetupContext("bar", 0);
/* "bar.pyx":9
* cdef int bar(int arg):
* cdef Foo foo
* foo.do_call(arg) # <<
* return foo(arg)
*/
__pyx_v_foo.do_call(__pyx_v_arg);
/* "bar.pyx":10
* cdef Foo foo
* foo.do_call(arg)
* return foo(arg) # <<
*/
__pyx_r = operator()(__pyx_v_arg);
goto __pyx_L0;
/* "bar.pyx":7
*
*
* cdef int bar(int arg): # <<
* cdef Foo foo
* foo.do_call(arg)
*/
/* function exit code */
__pyx_L0:;
__Pyx_RefNannyFinishContext();
return __pyx_r;
}
(...)
Note how the function invocation for "do_call" is generated correctly,
but the invocation of operator() is nonsensical.
The correct line would be this:
__pyx_r = __pyx_v_foo(__pyx_v_arg);
Happy debugging :D
~ mic_e
signature.asc
Description: OpenPGP digital signature
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Compiler crash in AnalyseExpressionsTransform
Hi, another bug report: mic@mic /tmp $ cat t11.pyx cdef cppclass foo: pass def test(): foo() mic@mic /tmp $ cython --cplus t11.pyx Error compiling Cython file: ... cdef cppclass foo: pass def test(): foo() ^ t11.pyx:5:7: Compiler crash in AnalyseExpressionsTransform ModuleNode.body = StatListNode(t11.pyx:1:0) StatListNode.stats[1] = DefNode(t11.pyx:4:0, modifiers = [...]/0, name = u'test', py_wrapper_required = True, reqd_kw_flags_cname = '0', used = True) File 'Nodes.py', line 421, in analyse_expressions: StatListNode(t11.pyx:5:7) File 'Nodes.py', line 4652, in analyse_expressions: ExprStatNode(t11.pyx:5:7) File 'ExprNodes.py', line 434, in analyse_expressions: SimpleCallNode(t11.pyx:5:7, use_managed_ref = True) File 'ExprNodes.py', line 4495, in analyse_types: SimpleCallNode(t11.pyx:5:7, use_managed_ref = True) File 'ExprNodes.py', line 4429, in analyse_as_type_constructor: SimpleCallNode(t11.pyx:5:7, use_managed_ref = True) Compiler crash traceback from this point on: File "/usr/lib/python2.7/dist-packages/Cython/Compiler/ExprNodes.py", line 4429, in analyse_as_type_constructor self.function = RawCNameExprNode(self.function.pos, constructor.type) AttributeError: 'NoneType' object has no attribute 'type' The code is obviously nonsensical, but Cython should produce a proper error message instead of crashing. signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Can't call functions with multi-token template arguments such as 'char *'
Hi, it seems to be impossible to use anything but a single word as a template type for functions. Classes don't suffer from this issue, as seen below. As a workaround, complex types can be ctypedef-d to a single word (also seen below). $ cat t10.pyx cdef extern from "nope.h": cdef cppclass bar[T]: void func(T arg) void foo[T](T arg) ctypedef char * charptr def test(): # works cdef bar[char *] barobj barobj.func(NULL) # works foo[int](5) # works foo[charptr](NULL) # fails foo[char *](NULL) $ cython --cplus t10.pyx Error compiling Cython file: ... # works foo[charptr](NULL) # fails foo[char *](NULL) ^ t10.pyx:27:14: Expected an identifier or literal Happy debugging, ~ mic_e signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Feature request: Flag to enable warnings when 'extern' functions are not declared 'except +'
Hi everybody, as you surely have guessed from the amount of Bug reports I have recently submitted to this mailing list, I'm currently working on a rather large Cython project. More precisely: I'm using Cython as the glue layer between the Python and C++ components of openage; an overview and source code may be found here: https://github.com/mic-e/openage/blob/pyinterface/doc/implementation/pyinterface.md https://github.com/mic-e/openage/tree/pyinterface/cpp/pyinterface https://github.com/mic-e/openage/tree/pyinterface/openage/cppinterface In openage, almost all C++ functions that are exposed to Cython SHOULD be declared as 'except +'. Forgetting to do so can cause hard-to-debug issues, including useless Exception messages, corruption of CPython and right-out program termination, if those methods should throw a C++ exception. As a solution, I'd like to see Cython warnings if an extern cimport has no 'except' declaration. To intentionally omit the "except +", I suggest a new except declaration, "except -", or, even better, the C++11 keyword "noexcept" (since precisely those methods that are declared 'noexcept' should be cimported without 'except+'). Of course, those warnings (or errors?) should be disabled by default, and enabled by a special command-line flag. Any thoughts on this? ~ mic_e ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Feature Request: Variadic Templates
Hi,
I'd like to see support for variadic template arguments, such as this:
test.h:
template
RetT foo(VARARGS ...);
test.pyx:
cdef extern from "test.h":
cdef RetT foo[RetT, ... VARARGS](... VARARGS)
def test():
cdef int i = foo[int, float, int](1, 2.5, 3)
This would allow Cython's libcpp to easily support many of C++11's new
types, including std::tuple and std::function.
Support for the latter in particular would prove quite useful in passing
around function pointers between Cython and C++.
I have tried to implement this feature myself, but I'm entirely
unfamiliar with Cython's codebase, and all my attempts ended in
unsatisfactorily hacky, unstable code.
I believe that any experienced Cython developer on this list would be
able to properly implement this in a matter of a few hours, as it seems
like a rather minor feature.
The current workaround for the non-existance of this feature involves
typedefs for every possible number of arguments, like this:
template
struct S {};
using S0 = S<>;
template
using S1 = S;
template
using S2 = S;
template
using S3 = S;
then exporting all of S0, S1, ... individually in the .pxd file.
This is inconvenient, but acceptable.
Now assume that S has a member function f,
template
void f(Ts..., Us ...);
due to the nature of C++, the same trick as above does not work, and the
user will be forced to clutter the C++ code with a function body for
every possible len(Us). Even worse, the .pxd file will now contain a
quadratic number of wrappers (one for every possible combination of
len(Ts), len(Us)), all of them extremely prone to mistakes.
Thanks for reading,
~ Michael
signature.asc
Description: OpenPGP digital signature
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Multidimensional indexing of C++ objects
Drawback 1) could be solved by declaring the operator as cdef inline operator []() instead of cdef inline __getitem__() signature.asc Description: OpenPGP digital signature ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP 4.5 array reductions
Hi,
You could solve this by specializing the code according to the version of the
OpenMP specification supported:
#if _OPENMP >= 201511
// OpenMP 4.5 and newer
#else
// features up to OpenMP 3.1
#endif
It’s more work in the compiler, but the auto-generated code does not have to be
pretty. ☺
Kind regards,
-michael
From: cython-devel
[mailto:cython-devel-bounces+michael.klemm=intel@python.org] On Behalf Of
Nathan Goldbaum
Sent: Friday, August 31, 2018 4:51 PM
To: Core developer mailing list of the Cython compiler
Subject: [Cython] OpenMP 4.5 array reductions
Hi all,
I'm curious if there would be any interest in adding support for OpenMP 4.5
array reduction in the cython compiler or alternatively detecting these cases
and raising a cython compiler error.
Currently cython is generating code that will compile but might lead to race
conditions. See:
https://github.com/cython/cython/issues/2316
https://github.com/cython/cython/issues/1504
The trouble with fixing this in the cython compiler is that adding the
appropriate OpenMP pragmas might generate code that will no longer compile on
compilers that don't support OpenMP 4.5. However perhaps that's a better
alternative than the status quo, which is generating code that might produce
random results.
I'd very much appreciate any feedback or advice here as this is currently
blocking our ability to easily add OpenMP to our cython code in places where
we'd like threads to do parallel reductions on large arrays. I would also not
be surprised if there is code in the wild that is racy and silently producing
incorrect results.
-Nathan
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
