Ticket #384 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

floor division on ctypedef-ed type results in non-compilable C code

Reported by: dagss Owned by: dagss
Priority: blocker Milestone: 0.12
Component: Code Generation Keywords:
Cc:

Description

This seems like a regression w. respect to 0.11.3.

Basically,

ctypedef Py_ssize_t index_t

def m_range_lm(index_t lmax):
    cdef index_t numcoefs = lmax // 2

results in

compiling (c) and running numpy_dagss ... numpy_dagss.c:296: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c: In function '__pyx_pf_11numpy_dagss_m_range_lm':
numpy_dagss.c:372: warning: implicit declaration of function '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c: At top level:
numpy_dagss.c:511: error: conflicting types for '__Pyx_div___pyx_t_11numpy_dagss_index_t'
numpy_dagss.c:372: error: previous implicit declaration of '__Pyx_div___pyx_t_11numpy_dagss_index_t' was here

Change History

Changed 5 years ago by dagss

  • owner changed from somebody to dagss
  • status changed from new to assigned

Changed 5 years ago by dagss

I'm deep into the issue behind this ticket, but a fix proves difficult for the case of

complex_arithmatic_utility_code

which can both depend on user-defined types and provide new ones. Luckily it cannot generate/get *any* type, so a code block order of

typedefs utility code emitting complex types utility code requiring use of complex type

should suffice. Would rather avoid making a full graph of code block dependencies, but can do that too. Will get back to it tomorrow or so.

Changed 5 years ago by dagss

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.