homepage

It would seem that enabling GCC's type conversion/truncation warnings would be a good thing for Python builds.
This would bring GCC builds in line with MSVC builds and reduce the burden on the Windows developers in fixing them. Also, it would bring attention to those issues by the developer who writes code and would hopefully understand the truncation issues at hand.
The CFLAGS required for this are '-Wconversion -Wno-sign-conversion'.
I unfortunately do not know the autoconf foo needed to implement this suggestion, however. Perhaps it should only be enabled for debug builds as well to eliminate excess noise for other builds. Or at least enabled on some of the buildbots.

How many extra warnings do you get by adding these flags (e.g., just by doing 'export CFLAGS= ...' before building)? It might be useful to see a sampling of those warnings.
The addition of these flags should be conditional on gcc's version being >= 4.3: gcc 4.2 apparently has a different meaning for -Wconversion (to do with implicit conversions when passing function arguments), and generates crazy numbers of warnings on my OS X 10.6 machine (which comes with gcc 4.2).
Why '-Wno-sign-conversion'? Is fixing all the places that have implicit sign conversions a reasonable goal, or are there just too many of those?

I'm getting more than thousand warnings:
$ CFLAGS="-Wconversion -Wno-sign-conversion" ./configure
$ LC_ALL=C make -s -j8 2>&1 | tee log
$ grep Wconversion log | wc -l
1163
platform: Ubuntu 12.04 x86_64
gcc: 4.6.3

> I'm getting more than thousand warnings:
>
> $ CFLAGS="-Wconversion -Wno-sign-conversion" ./configure
> $ LC_ALL=C make -s -j8 2>&1 | tee log
> $ grep Wconversion log | wc -l
> 1163
My Win64 buildbot currentlyhas 544 conversion warnings, but it seems
something has recently changed with OpenSSL thus causing over 2100
total warnings.

Issue 23545 has a patch with some comments from me about adding other warnings via "autoconf foo", so you could copy from that if you want.
The few warnings that I glanced at do not look troublesome. But maybe it is worth working around them to see other warnings; I dunno. Adding explicit casts can sometimes hide other bugs. Anyway, here is a random selection of some warnings:
Modules/sha256module.c:198:44: warning: conversion to ‘SHA_INT32 {aka unsigned int}’ from ‘long unsigned int’ may alter its value [-Wconversion]
 RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],48,0x19a4c116);
 ^
Modules/sha256module.c:145:11: note: in definition of macro ‘RND’
 t0 = h + Sigma1(e) + Ch(e, f, g) + ki + W[i]; \
 ^
Modules/resource.c:19:60: warning: conversion to ‘double’ from ‘__suseconds_t {aka long int}’ may alter its value [-Wconversion]
 #define doubletime(TV) ((double)(TV).tv_sec + (TV).tv_usec * 0.000001)
 ^
./Include/tupleobject.h:62:75: note: in definition of macro ‘PyTuple_SET_ITEM’
 #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] = v)
 ^
Modules/resource.c:82:5: note: in expansion of macro ‘PyStructSequence_SET_ITEM’
 PyStructSequence_SET_ITEM(result, 0,
 ^~~~~~~~~~~~~~~~~~~~~~~~~
Modules/resource.c:83:40: note: in expansion of macro ‘doubletime’
 PyFloat_FromDouble(doubletime(ru.ru_utime)));
 ^~~~~~~~~~
Modules/cjkcodecs/cjkcodecs.h:155:27: warning: conversion to ‘unsigned char’ from ‘int’ may alter its value [-Wconversion]
 do { ((*outbuf)[1]) = (c); } while (0)
 ^
Modules/cjkcodecs/_codecs_kr.c:58:13: note: in expansion of macro ‘OUTBYTE2’
 OUTBYTE2((code & 0xFF) | 0x80);
 ^~~~~~~~
Modules/_ctypes/cfield.c:439:15: warning: conversion to ‘short int’ from ‘int’ may alter its value [-Wconversion]
 v >>= (sizeof(v)*8 - NUM_BITS(size)); \
 ^
Modules/_ctypes/cfield.c:594:5: note: in expansion of macro ‘GET_BITFIELD’
 GET_BITFIELD(val, size);
 ^~~~~~~~~~~~