I'm ok with this, but I did not test it.

I guess the nlrx64.S stuff can be fixed some other time.

Rebased it against latest changes and all tests still pass, except machine_mem/meminfo/math_fun. First two because they are made for unix port (never got to making them skip) and the last one because mingw prints -0 instead of plain 0 in some places but that's the only difference.

I dont have the knowledge myself for fixing the x64 assembly.

math_fun. First two because they are made for unix port (never got to making them skip) and the last one because mingw prints -0 instead of plain 0 in some places but that's the only difference.

Since yesterday, libc no longer prints floats, uPy itself does.

The Makefile doesn't yet have utils/printf.c

It's handled by py/formatfloat.c

Then I guess migw's asinh (and others) returns -0?

Bottom line is that I'd like to have a look first.

Ok with revision of ede1f54:

6 tests failed: repl_basic repl_cont repl_emacs_keys machine_mem math_fun import_file

--- math_fun.py.exp 2015-11-24 17:04:23.279753791 +0200
+++ math_fun.py.out 2015-11-24 17:04:23.279753791 +0200
@@ -68,7 +68,7 @@
 -1.0379
 -0.88137
 -0.48121
-0
+-0
 0.48121
 1.0379
 5.2983

With master:

10 tests failed: repl_basic repl_cont repl_emacs_keys machine_mem complex1 float1 math_fun string_format string_format_modulo import_file

--- float1.py.exp   2015-11-24 17:23:33.533898466 +0200
+++ float1.py.out   2015-11-24 17:23:33.533898466 +0200
@@ -15,8 +15,8 @@
 inf
 inf
 inf
-nan
-nan
+-nan
+-nan
 ValueError
 ValueError
 False

@stinos , you know how to handle it - pull in known good asinh and others, and skip libc/libm altogether ;-). So, you'd better say of you don't like that (but then you should be ready to move pendulum in the other direction yourself - like, I thought that it would be nice to have either own routine for float printing, or recurse to libc. But as you can see, I just removed printing-via-libc code, because maintaining that "would be nice" is a chore).

Merged, thanks.

Note that uPy has some difference with CPy wrt nan: if you do float("-nan") then uPy prints the - while CPy does not.

So, you'd better say of you don't like that

I was never planning to very actively support the mingw port: I have no real use for it myself (except that I can build same source tree locally with gcc without needing to ssh to a unix box) so I just try to make sure it keeps on building and running tests with most features working. Which it does apart from apparent corner case asinh and modf behaviour and I don't consider that problematic enough to work on it. On the other hand, on a lazy sunday afternoon I might do it anyway :]

Note
https://sourceforge.net/p/mingw-w64/bugs/515/
https://sourceforge.net/p/mingw-w64/bugs/516/

Thanks for submitting those!

I was never planning to very actively support the mingw port:

Ah, right, even if own implementations will be added for mingw, they won't affect msvc build. But then it will be just unneeded discrepancy which may lead to confusion. Anyone, I don't plan to make changes for that any time soon, but then suddenly I can start and make them, so wanted to make sure you're in loop.