[U-Boot] warnings from gcc-4.4 build
When building the MPC8572DS_config w/gcc-4.4 I get:
sys_eeprom.c: In function ‘do_mac’: sys_eeprom.c:323: warning: dereferencing type-punned pointer will break strict-aliasing rules sys_eeprom.c: In function ‘mac_read_from_eeprom’: sys_eeprom.c:395: warning: dereferencing type-punned pointer will break strict-aliasing rules ahci.c: In function ‘ata_scsiop_read_capacity10’: ahci.c:616: warning: dereferencing type-punned pointer will break strict-aliasing rules biosemu.c: In function ‘BE_setVGA’: biosemu.c:147: warning: dereferencing type-punned pointer will break strict-aliasing rules tsec.c: In function ‘tsec_init’: tsec.c:200: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘malloc_bin_reloc’: dlmalloc.c:1502: warning: dereferencing pointer ‘p’ does break strict- aliasing rules dlmalloc.c:1502: warning: dereferencing pointer ‘p’ does break strict- aliasing rules dlmalloc.c:1499: note: initialized from here dlmalloc.c:1502: note: initialized from here dlmalloc.c: In function ‘free’: dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: note: initialized from here dlmalloc.c: In function ‘malloc’: dlmalloc.c:2219: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2219: note: initialized from here dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: note: initialized from here dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: note: initialized from here dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: note: initialized from here xyzModem.c: In function ‘xyzModem_stream_open’: xyzModem.c:564: warning: ‘dummy’ is used uninitialized in this function xyzModem.c:547: note: ‘dummy’ was declared here
Should would be turning on -fno-strict-aliasing. The linux kernel has been doing this for some time.
- k
Hi Kumar,
When building the MPC8572DS_config w/gcc-4.4 I get:
sys_eeprom.c: In function ‘do_mac’: sys_eeprom.c:323: warning: dereferencing type-punned pointer will break strict-aliasing rules sys_eeprom.c: In function ‘mac_read_from_eeprom’: sys_eeprom.c:395: warning: dereferencing type-punned pointer will break strict-aliasing rules ahci.c: In function ‘ata_scsiop_read_capacity10’: ahci.c:616: warning: dereferencing type-punned pointer will break strict-aliasing rules biosemu.c: In function ‘BE_setVGA’: biosemu.c:147: warning: dereferencing type-punned pointer will break strict-aliasing rules tsec.c: In function ‘tsec_init’: tsec.c:200: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function ‘malloc_bin_reloc’: dlmalloc.c:1502: warning: dereferencing pointer ‘p’ does break strict- aliasing rules dlmalloc.c:1502: warning: dereferencing pointer ‘p’ does break strict- aliasing rules dlmalloc.c:1499: note: initialized from here dlmalloc.c:1502: note: initialized from here dlmalloc.c: In function ‘free’: dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2474: note: initialized from here dlmalloc.c: In function ‘malloc’: dlmalloc.c:2219: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2219: note: initialized from here dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2228: note: initialized from here dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2235: note: initialized from here dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules dlmalloc.c:2292: note: initialized from here
You already fixed quite a few problems in dlmalloc:
commit 57c219ad5d34dd9d49991777a62e3899595f2ec7 Author: Kumar Gala galak@kernel.crashing.org Date: Wed Jul 30 08:01:15 2008 -0500
Fix compile warnings in dlmalloc
The origional code was using on odd reference to get to the first real element in av_[]. The first two elements of the array are not used for actual bins, but for house keeping. If we are more explicit about how use the first few elements we can get rid of the warnings:
dlmalloc.c: In function 'malloc_extend_top': dlmalloc.c:1971: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:1999: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2029: warning: dereferencing type-punned pointer will break strict-aliasing rules ...
The logic of how this code came to be is: bin_at(0) = (char*)&(av_[2]) - 2*SIZE_SZ
SIZE_SZ is the size of pointer, and av_ is arry of pointers so: bin_at(0) = &(av_[0])
Going from there to bin_at(0)->fd or bin_at(0)->size should be straight forward.
Signed-off-by: Kumar Gala galak@kernel.crashing.org
xyzModem.c: In function ‘xyzModem_stream_open’: xyzModem.c:564: warning: ‘dummy’ is used uninitialized in this function xyzModem.c:547: note: ‘dummy’ was declared here
Should would be turning on -fno-strict-aliasing. The linux kernel has been doing this for some time.
Last time around, i.e. moving to gcc 4.x (as proven by the commit above), we were able to fix the problems. Did anything significantly change in the arguments?
Cheers Detlev
Dear Kumar Gala,
In message 9B5E5AE1-2907-49C2-870F-2D7B2F2DE598@kernel.crashing.org you wrote:
When building the MPC8572DS_config w/gcc-4.4 I get:
sys_eeprom.c: In function do_mac: sys_eeprom.c:323: warning: dereferencing type-punned pointer will > break strict-aliasing rules
...
Should would be turning on -fno-strict-aliasing. The linux kernel has > been doing this for some time.
Should we not rather fix the code that causes these warnings? Usually the required changes are just minimal (which does not mean that it is a trivial task).
Best regards,
Wolfgang Denk
On Jul 4, 2009, at 6:33 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 9B5E5AE1-2907-49C2-870F-2D7B2F2DE598@kernel.crashing.org you wrote:
When building the MPC8572DS_config w/gcc-4.4 I get:
sys_eeprom.c: In function ‘do_mac’: sys_eeprom.c:323: warning: dereferencing type-punned pointer will > break strict-aliasing rules
...
Should would be turning on -fno-strict-aliasing. The linux kernel has > been doing this for some time.
Should we not rather fix the code that causes these warnings? Usually the required changes are just minimal (which does not mean that it is a trivial task).
For some cases its trivial, for others I'm not sure if its worth it (like ahci.c):
static int ata_scsiop_read_capacity10(ccb *pccb) { u8 buf[8];
memset(buf, 0, 8);
*(u32 *) buf = le32_to_cpu(ataid[pccb->target]->lba_capacity);
buf[6] = 512 >> 8; buf[7] = 512 & 0xff;
memcpy(pccb->pdata, buf, 8);
return 0; }
how do we fix this (the *u32 *)buf ... line is the one causing warnings ?
For dlmalloc I think we might want to look at updating to a newer version of the code.
- k
On Mon, Jul 06, 2009 at 10:10:20AM -0500, Kumar Gala wrote:
static int ata_scsiop_read_capacity10(ccb *pccb) { u8 buf[8];
memset(buf, 0, 8); *(u32 *) buf = le32_to_cpu(ataid[pccb->target]->lba_capacity); buf[6] = 512 >> 8; buf[7] = 512 & 0xff; memcpy(pccb->pdata, buf, 8); return 0;}
how do we fix this (the *u32 *)buf ... line is the one causing warnings ?
Use a union.
For dlmalloc I think we might want to look at updating to a newer version of the code.
Agreed in general, though I'm nervous about enabling strict aliasing on any malloc implementation (except possibly one that makes sure to operate on char pointers, at least to a degree required to create optimization barriers). Its whole purpose in life is to reinterpret portions of memory -- consider some hyperoptimizing compiler that does inter-procedural analysis and ends up moving accesses across the free() boundary because it couldn't find any intervening access through a pointer to the same type (or char).
-Scott
Dear Scott Wood,
In message 20090706175233.GA5964@b07421-ec1.am.freescale.net you wrote:
On Mon, Jul 06, 2009 at 10:10:20AM -0500, Kumar Gala wrote:
static int ata_scsiop_read_capacity10(ccb *pccb) { u8 buf[8];
memset(buf, 0, 8); *(u32 *) buf = le32_to_cpu(ataid[pccb->target]->lba_capacity); buf[6] = 512 >> 8; buf[7] = 512 & 0xff; memcpy(pccb->pdata, buf, 8); return 0;}
how do we fix this (the *u32 *)buf ... line is the one causing warnings ?
Use a union.
Or simply a temporary variable to perform the conversion in two separate steps.
Best regards,
Wolfgang Denk
On Friday 10 July 2009 19:05:28 Wolfgang Denk wrote:
Scott Wood wrote:
On Mon, Jul 06, 2009 at 10:10:20AM -0500, Kumar Gala wrote:
static int ata_scsiop_read_capacity10(ccb *pccb) { u8 buf[8];
memset(buf, 0, 8); *(u32 *) buf = le32_to_cpu(ataid[pccb->target]->lba_capacity); buf[6] = 512 >> 8; buf[7] = 512 & 0xff; memcpy(pccb->pdata, buf, 8); return 0;}
how do we fix this (the *u32 *)buf ... line is the one causing warnings ?
Use a union.
Or simply a temporary variable to perform the conversion in two separate steps.
a union is generally what people are moving to to avoid aliasing issues, but that's only when rewriting the code isnt trivial to do. in this case, it should be as you say and it would be simpler. and the buf[] could be tossed completely as well as the largely useless memset().
probably something like: u32 cap = le32_to_cpu(ataid[pccb->target]->lba_capacity); memcpy(pccb->pdata, &cap, sizeof(cap)); pccb->pdata[4] = pccb->pdata[5] = '\0'; pccb->pdata[6] = 512 >> 8; pccb->pdata[7] = 512 & 0xff; -mike
participants (5)
-
Detlev Zundel -
Kumar Gala -
Mike Frysinger -
Scott Wood -
Wolfgang Denk