Integer type breaks compilation of function

[numba]

Integer type breaks compilation of function

[ovillellas]

I described this same problem in a comment inside the "problems with castings". If you try to get the same ndot generated for float32 it will fail even if s is 0.0, because numba it is not able to downcast to single precision what it sees like a double literal :(.

[jriehl]

With the last commit, I'm able to get both the s = 0 and float32 versions of ndot to compile. Note that in the s = 0 case, the type of s is inferred to be an integer, so the input floating point values are being truncated, and the result is then cast to a floating point when being written to the output array.

The big problem with supporting the kind of type inference you want is loops. To keep things sane, I use the first observed type for values that have to be joined at branch targets (phi nodes in static single assignment lingo). Doing a more sophisticated static analysis might work. We'll have to look into it in more depth.

I'm not sure if I should close this issue and add an enhancement issue (since technically compilation is no longer broken), or re-purpose this issue for the enhancement. Opinions?

[stefanv]

It probably depends on whether you see behaviour different to that of default Python to be a bug or not?

[markflorisson]

This is fixed now with the SSA support, probably to the extent where Python compatibility remains feasible.