[Cython] Bug in Cython producing incorrect C code

[mark florisson]

On 26 January 2012 06:39, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2012/1/25 Stefan Behnel <stefan_ml at behnel.de>:
>> mark florisson, 24.01.2012 14:53:
>>> On 24 January 2012 11:37, Konrad Hinsen wrote:
>>>> Compiling the attached Cython file produced the attached C file which
>>>> has errors in lines 532-534:
>>>>
>>>>  __pyx_v_self->xx = None;
>>>>  __pyx_v_self->yy = None;
>>>>  __pyx_v_self->zz = None;
>>>>
>>>> There is no C symbol "None", so this doesn't compile.
>>>>
>>>> I first noticed the bug in Cython 0.15, but it's still in the latest
>>>> revision from Github.
>>>
>>> Hm, it seems the problem is that the call to the builtin float results
>>> in SimpleCallNode being replaced with PythonCApiNode, which then
>>> generates the result code, but the list of coerced nodes are
>>> CloneNodes of the original rhs, and CloneNode does not generate the
>>> result code of the original rhs (i.e. allocate and assign to a temp),
>>> which results in a None result.
>>
>> Back to the old idea of separating the type analysis into 1) a basic
>> typing, inference and entry creation step and 2) a proper type analysis,
>> coercion, etc. step.
>>
>
> Yeah! I think the issue must be fixed before release. We can start
> moving slowly in this direction and split
> CascadedAssignmentNode.analyse_types into parts:
>  - normal analyse_types()/expressions()
>  - create clone nodes at some late stage

At what stage would the stage 2) proper type analysis take place?
Basically nodes may be replaced at any point, and I'm not sure you
want to wait until just before code generation to do the coercions
(e.g.  GILCheck won't catch coercions to object, although assignment
nodes seem to check manually).

I think this problem can trivially be solved by creating a ProxyNode
that should never be replaced by any transform, but it's argument may
be replaced. So you wrap self.rhs in a ProxyNode and use that to
create your CloneNodes.

>> The type driven optimisations would then run in between the two. That would
>> simplify the optimisations (which would no longer have to unpack wrapped
>> nodes) and improve the type analysis because it could work with the
>> optimised types, e.g. return types of optimised builtin functions.
>>
>> I'm not entirely sure where the type inference should run. It may make more
>> sense to move it after the tree optimisations to make use of optimised
>> function calls.
>>
>> While we're at it, we should also replace the current type inference
>> mechanism with a control flow based one.
>>
>> Sounds like a good topic for a Cython hacking workshop.
>>
>
> Nice. Any news on that?
>
>
> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel