Re: GCC 4.1 now the default GCC version for etch
Andreas Metzler <email@example.com> writes:
> On 2006-06-07 Matthias Klose <firstname.lastname@example.org> 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
>> These warnings may point to code which is not 64bit clean. They are
>> most likely not seen on 32bit architectures. See the amd64, alpha
>> and ia64 build logs for these architecture specific warnings.
> as this was sent in conjunction with gcc 4.1, I wonder whether gcc 4.1
> is more strict in this matter, too.
This has always been a bug and great cause for segfaults. They just
have automated looking for the compiler warnings for the problem now
instead of users looking at segfaults.
> 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
> a) refrain from making a upload before the
> issue is fixed as the packages will break horribly with gcc-4.1,
> b) simply continue, as the package won't be broken more with gcc-4.1
> than it was with gcc-4.0?
> thanks, cu andreas
The brokenness does not change, the generated code does not
change. The bug remains if it actualy is a bug. Sometimes you have
code that pases an int (and other things at different places) along as
void* and deeper down casts it back to int. This will generate the
warning, is bad C (implementation defined behaviour), but with gcc it
will work perfectly. The extra 32 high-bits you gain you loose
again. No harm done _in_this_case.
But other sources pass a pointer as int and there you loose 32
valuable bits and get a segfault when the int is used as pointer
again. The warnings ware the same.