> There is something wrong around lib/strftime.c:946
>           if (negative_number)
>             u_number_value = - u_number_value;
>
> u_number_value being unsigned, this is wrong.

I don't see anything wrong there.  The value of
-X is well-defined if X is unsigned int; it's
equivalent to ~X + 1.  Can you supply a test case
illustrating the actual bug?


When my compiler issues a warning like :

unsigned.c
unsigned.c(3) : warning C4146: unary minus operator applied to unsigned type, result still unsigned

I tend to care about it. If it is on purpose, then I'm ok with it albeit I would have prefered something less error prone
(I mean human interpretation error :-) )
 
> In src/dispnew.c:6402, height and width should probably be unsigned. The
> checking by
> INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> constant overflow
> because it tries to compute (INTMIN - 2) which obviously is out of range.
> The value is not used in this case, but the compiler may emit the warning
> anyway.

We don't need to modify the mainline Emacs code in order to
pacify third-party compilers that issue incorrect warnings.
We can safely ignore these warnings and leave the code alone.

My past experience with stuff like pdftex (many years !)
is that compiling with a completely different 
compiler may reveal useful to find errors in already tested source code.
The cleaner, the safer.

I don't know to which extent the FSF wants to support compilation of emacs
x64 (but that applies to x86 too) with the MS tools (even if they are freely available).
I did it because I'm using it this way, but that should be doable with MINGW x64 (or so I guess).
With the MS tools, emacs does not compile out of the box. There are errors. 
There are also lots of warnings and when something does not work, I try to remove warnings first. 
All in all,  at least for the record, it may help people who would need an emacs/x64/windows this way.

Best regards,

Fabrice