Re: GCC 4.1 now the default GCC version for etch
Scripsit Andreas Metzler <ametzler@downhill.at.eu.org>
> On 2006-06-07 Matthias Klose <doko@cs.tu-berlin.de> wrote:
>> We did pick two compiler warnings and scanned the build logs of one
>> archive rebuild on alpha (64bit), where wrong code may be generated.
>> - cast from pointer to integer of different size
>> cast to pointer from integer of different size
> i.e. if a package is currently in the archive, suffers from this
> issues and the binary packages *currently* in the archive have been
> built with gcc-4.0, should I
> b) simply continue, as the package won't be broken more with gcc-4.1
> than it was with gcc-4.0?
If the code is really nont 64bit-clean (i.e. it tries to store a
pointer in a 32-bit integer and expects to be able to cast it back and
still locate the data the original pointer pointed to), I cannot see
how gcc-4.0 would have been able to create working code either.
As I read Matthias' posting, these warnings were ones that were found
as a kind of bonus outcome from the compile-everything-with-gcc4.1
experiment.
Another related bug type that I found lurking in my packages when I
investigated the warnings in this list, is trying to format a size_t
value with a %u or %d format string, which will break if size_t is 64
bits (unless the actual number is small and it is the last argument
and the endianness of the architecture happens to match its stack
growth direction). This too produces a warning on all relevant gcc
versions, but only when compiling to a 64-bit target.
Somebody<tm> ought to create a tool that could easily compare the
buildd logs for a package on different architectures and flag warnings
that appear only for some but not arches, indicating a possible
portability bug.
--
Henning Makholm "What the hedgehog sang is not evidence."
Reply to: