[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC 4.1 now the default GCC version for etch

Andreas Metzler <ametzler@downhill.at.eu.org> writes:

> 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
>>    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.
> [...]
> Hello,
> 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,
> or
> 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.


Reply to: