This is something very unoptimal (cast to float and cast back to int), and I thought that enclosing the whole expression into Std.int would prevent such castings (as stated in the documentation).
I did the same with hashlink converted to c code, it has the same result:
You might need to do a Std.int per division for hxcpp’s optimization to happen. total += Std.int(i/3) + i*Std.int(i/7);
Otherwise that’s not integer division but two float div which later are cast to int.
Note that there’s still room for optimisation at line 4, the comparison of r6 with 0 is useless, as r6 was set to 3 the line before. But I guess that the c compiler optimizer will catch it and remove it.
Using cpp.NativeMath.idiv seems to trigger the optimisation for hxcpp. Using Std.int seems like it should as the idiv function is just an inline function which wraps the division in Std.int.
Edit: Read the file wrong, the wrapping in Std.int only occurs when used on non cpp platforms, otherwise the extern functions is used.