Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19

[Petr Pisar]

On 2013-01-04, Jakub Jelinek <jakub at redhat.com> wrote:
>
> getdata-0.7.3-3.fc18.src.rpm
> 	GCC is now more aggresive in turning loops that invoke undefined
> 	behavior into endless loops.  In test/get_uint32.c there is:
> 	uint32_t data_data[128];
> 	int fd, n, error, r = 0;
> 	...
> 	for (fd = 0; fd < 128; ++fd)
> 	  data_data[fd] = fd * (0x02000001);
> 	When fd is 64 or above, fd * 0x02000001 overflows, which is invalid
> 	in C/C++ for signed types (int here).  To fix use
> 	  data_data[fd] = fd * 0x02000001U;
> 	or
> 	  data_data[fd] = (uint32_t) fd * 0x02000001;
> 	etc. instead.
>
[...]
>
> yap-6.2.2-4.fc18.src.rpm
> 	similar to getdata bug:
> 	LAST_FLAG = 23
> 	...
> 	#define NUMBER_OF_YAP_FLAGS  LAST_FLAG
> 	...
> 	#define yap_flags Yap_heap_regs->yap_flags_field
> 	...
> 	Int  yap_flags_field[NUMBER_OF_YAP_FLAGS];
> 	...
> 	/* This must be done before initialising predicates */
> 	for (i = 0; i <= LAST_FLAG; i++) {
> 	  yap_flags[i] = 0;
> 	}
>
What's wrong with assigning 0 that fits into any intenger? C99 says:

  6.3.1.3 Signed and unsigned integers
  1 When a value with integer type is converted to another integer type
    other than _Bool, if the value can be represented by the new type,
    it is unchanged.

The pre-precessed code is:

  for (i = 0; i <= LAST_FLAG; i++) {
    ((all_heap_codes *)(0x10000000))->yap_flags_field[i] = 0;
  }

Type of yap_flags_field is int[].

Is it due to casting signed number to object pointer? But that's allowed:

  6.3.2.3 Pointers
  5 An integer may be converted to any pointer type. Except as previously
    specified, the result is implementation-defined, might not be correctly
    aligned, might not point to an entity of the referenced type, and might
    be a trap representation.

-- Petr