[U-Boot] warnings from gcc-4.4 build

[U-Boot] warnings from gcc-4.4 build

[Kumar Gala]

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

[U-Boot] warnings from gcc-4.4 build

[Detlev Zundel]

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

-- 
The  mathematician's patterns,  like the  painter's or  the poet's,  must be
beautiful;  the ideas, like the colours or the words, must fit together in a
harmonious way. Beauty is the first test: there is no permanent place in the
world for ugly mathematics.                       -- G. H. Hardy
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] warnings from gcc-4.4 build

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think it's a new feature. Don't tell anyone it was an accident. :-)
  -- Larry Wall on s/foo/bar/eieio in <10911@jpl-devvax.JPL.NASA.GOV>

[U-Boot] warnings from gcc-4.4 build

[Kumar Gala]

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

[U-Boot] warnings from gcc-4.4 build

[Scott Wood]

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

[U-Boot] warnings from gcc-4.4 build

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
'What shall we do?' said Twoflower.  'Panic?'  said  Rincewind  hope-
fully. He always held that panic was the best means of survival; back
in  the  olden days, his theory went, people faced with hungry sabre-
toothed tigers could be divided very simply in those who panicked and
those who stood there saying 'What a magnificent  brute!'  or  'Here,
pussy.'                      - Terry Pratchett, _The Light Fantastic_

[U-Boot] warnings from gcc-4.4 build

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090710/557bdd8d/attachment.pgp