[SLOF] [PATCH] Fix remaining compiler warnings in sloffs.c

[Thomas Huth]

On 08.08.2016 10:31, Segher Boessenkool wrote:
> On Mon, Aug 08, 2016 at 08:38:33AM +0200, Thomas Huth wrote:
>> On 08.08.2016 03:30, Segher Boessenkool wrote:
>>> On Fri, Aug 05, 2016 at 10:48:18AM +0200, Adrian Reber wrote:
>>>>> +static void print_header_date(void *dptr)
>>>>> +{
>>>>> +	uint8_t *date = dptr;
>>>>> +
>>>>> +	if (*(uint64_t *)dptr != 0) {
>>>
>>> This is the exact same problem though.  Should be something like
>>>
>>> 	if (date[0] || date[1] || date[2] || date[3]
>>> 	    || date[4] || date[5] || date[6] || date[7])
>>
>> I'm now type-punning dptr here, not date, so this time it's a void
>> pointer instead of a char array ... and I thought type-punning a void
>> pointer would be OK since they are considered to alias any other kind of
>> data? I might be wrong here, though, these aliasing problems always
>> cause a headache for me.
> 
> That is not how it works.  The pointer type does not matter; it is
> perfectly legal to cast a pointer.  What is not okay is accessing
> something with a type not compatible with its effective type (ignoring
> signedness), unless the access is character type.  "Effective type"
> usually is just the declared type of the datum.

Ouch, OK, I got it now. I'll send a new version of my patch...

>> In the end, we just might want to add -fno-strict-aliasing to the
>> HOSTCFLAGS, just like we already did it in make.rules for the normal
>> CFLAGS, and call it a day.
> 
> Or you could fix the problems.  SLOF used to work with -fstrict-aliasing,
> and it was a nice performance win.

That's a question for Nikunj who committed that change a couple of years
ago ...
(see http://git.qemu.org/?p=SLOF.git;a=commitdiff;h=7eca6a5e56f468)

 Thomas