[U-Boot] [PATCH 0/9] Fix a few warnings that bug me
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Simon Glass (9): usb: Fix strict-aliasing warning in host/ohci-hcd.c Fix strict-aliasing warning in dlmalloc mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c ppc4xx: Fix strict-aliasing warnings in usb_ohci.c sandbox: sort header files in os.c sandbox: Add required header to os.c Remove CONFIG_SYS_EXTBDINFO from snapper9260.h m68k: Change memsz to a signed char to avoid warning ppc: Change memsz variable to signed char
arch/m68k/lib/board.c | 2 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c | 7 +-- arch/sandbox/cpu/os.c | 11 +++-- common/dlmalloc.c | 8 ++-- drivers/usb/host/ohci-hcd.c | 26 ++++++------ include/configs/snapper9260.h | 1 - 8 files changed, 122 insertions(+), 93 deletions(-)
This fixes these warnings seen with my gcc 4.6 compiler.
ohci-hcd.c: In function 'submit_control_msg': ohci-hcd.c:1307: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules cc1: note: initialized from here ohci-hcd.c:1310: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules cc1: note: initialized from here ohci-hcd.c:1313: warning: dereferencing pointer 'pretmp.729' does break strict-aliasing rules
Signed-off-by: Simon Glass sjg@chromium.org --- drivers/usb/host/ohci-hcd.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index cf906b4..2cbb326 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1261,20 +1261,18 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe, int leni = transfer_len; int len = 0; int stat = 0; - __u32 datab[4]; + u8 *dataptr = NULL; union { - void *ptr; - __u8 *u8; - __u16 *u16; - __u32 *u32; + /* data will be in here when dataptr stays as NULL */ + __u8 u8[16]; + __u16 u16[8]; + __u32 u32[3]; } databuf; __u16 bmRType_bReq; __u16 wValue; __u16 wIndex; __u16 wLength;
- databuf.u32 = (__u32 *)datab; - #ifdef DEBUG pkt_print(NULL, dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); @@ -1381,14 +1379,14 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len, min_t(unsigned int, sizeof(root_hub_dev_des), wLength)); - databuf.ptr = root_hub_dev_des; OK(len); + dataptr = root_hub_dev_des; OK(len); case (0x02): /* configuration descriptor */ len = min_t(unsigned int, leni, min_t(unsigned int, sizeof(root_hub_config_des), wLength)); - databuf.ptr = root_hub_config_des; OK(len); + dataptr = root_hub_config_des; OK(len); case (0x03): /* string descriptors */ if (wValue == 0x0300) { len = min_t(unsigned int, @@ -1396,7 +1394,7 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len, min_t(unsigned int, sizeof(root_hub_str_index0), wLength)); - databuf.ptr = root_hub_str_index0; + dataptr = root_hub_str_index0; OK(len); } if (wValue == 0x0301) { @@ -1405,7 +1403,7 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len, min_t(unsigned int, sizeof(root_hub_str_index1), wLength)); - databuf.ptr = root_hub_str_index1; + dataptr = root_hub_str_index1; OK(len); } default: @@ -1469,8 +1467,10 @@ pkt_print(NULL, dev, pipe, buffer, transfer_len, #endif
len = min_t(int, len, leni); - if (data != databuf.ptr) - memcpy(data, databuf.ptr, len); + if (dataptr) + memcpy(data, dataptr, len); + else + memcpy(data, &databuf, len); dev->act_len = len; dev->status = stat;
On Thursday 05 January 2012 22:54:49 Simon Glass wrote:
len = min_t(int, len, leni);
- if (data != databuf.ptr)
memcpy(data, databuf.ptr, len);
- if (dataptr)
memcpy(data, dataptr, len);- else
memcpy(data, &databuf, len);
this doesn't seem to be equivalent ? -mike
Hi Mike,
On Sun, Jan 8, 2012 at 1:32 AM, Mike Frysinger vapier@gentoo.org wrote:
On Thursday 05 January 2012 22:54:49 Simon Glass wrote:
len = min_t(int, len, leni);
- if (data != databuf.ptr)
- memcpy(data, databuf.ptr, len);
- if (dataptr)
- memcpy(data, dataptr, len);
- else
- memcpy(data, &databuf, len);
this doesn't seem to be equivalent ? -mike
I believe it is if you look at the entire change, but I might have missed something. dataptr is used only when we want to pull in the USB descriptor info. Otherwise we use our local databuf union.
Regards, Simon
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
Signed-off-by: Simon Glass sjg@chromium.org --- common/dlmalloc.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index c645d73..0a719b4 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = { #ifdef CONFIG_NEEDS_MANUAL_RELOC void malloc_bin_reloc (void) { - unsigned long *p = (unsigned long *)(&av_[2]); + mbinptr *p = &av_[2]; int i; - for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) { - *p++ += gd->reloc_off; - } + + for (i = 2; i < ARRAY_SIZE(av_); ++i) + *p = (mbinptr)((ulong)*p + gd->reloc_off); } #endif
Dear Simon Glass,
In message 1325822097-15227-3-git-send-email-sjg@chromium.org you wrote:
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
Which exact version is this?
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
Can you please tell me at least one board configuration that throws this error (preferrably ppc, arm or mips) ?
Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c" patches?
I wonder why I don't see any such warnings. Which exact commit ID are you building?
Thanks.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, Jan 5, 2012 at 10:48 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1325822097-15227-3-git-send-email-sjg@chromium.org you wrote:
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
Which exact version is this?
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
Can you please tell me at least one board configuration that throws this error (preferrably ppc, arm or mips) ?
I can't see one with those architectures. It does happen for others though:
$ (for b in $(cd ~/cosarm/buildall/logs.master.9a42098 && grep -l 1493 *ERR |sed 's/.ERR//'); do grep $b boards.cfg; done ) |awk '{print $2, $1}' avr32 atngw100 avr32 atstk1002 avr32 atstk1003 avr32 atstk1004 avr32 atstk1006 mips dbau1000 mips dbau1100 mips dbau1500 mips dbau1550 mips dbau1550_el avr32 favr-32-ezkit avr32 grasshopper mips gth2 avr32 hammerhead mips incaip mips incaip_100MHz mips incaip_133MHz mips incaip_150MHz m68k M54451EVB m68k M54451EVB_stmicro m68k M54451EVB_stmicro m68k M54455EVB_a66 m68k M54455EVB m68k M54455EVB_a66 m68k M54455EVB_i66 m68k M54455EVB_intel m68k M54455EVB_stm33 m68k M54455EVB_i66 m68k M54455EVB_intel m68k M54455EVB_stm33 m68k M5475AFE m68k M5475BFE m68k M5475CFE m68k M5475DFE m68k M5475EFE m68k M5475FFE m68k M5475GFE m68k M5485AFE m68k M5485BFE m68k M5485CFE m68k M5485DFE m68k M5485EFE m68k M5485FFE m68k M5485GFE m68k M5485HFE avr32 mimc200 mips qemu_mips mips vct_platinumavc mips vct_platinumavc_onenand mips vct_platinumavc_onenand_small mips vct_platinumavc_small mips vct_platinumavc_onenand mips vct_platinumavc_onenand_small mips vct_platinumavc_onenand_small mips vct_platinumavc_small mips vct_platinum mips vct_platinumavc mips vct_platinumavc_onenand mips vct_platinumavc_onenand_small mips vct_platinumavc_small mips vct_platinum_onenand mips vct_platinum_onenand_small mips vct_platinum_small mips vct_platinum_onenand mips vct_platinum_onenand_small mips vct_platinum_onenand_small mips vct_platinum_small mips vct_premium mips vct_premium_onenand mips vct_premium_onenand_small mips vct_premium_small mips vct_premium_onenand mips vct_premium_onenand_small mips vct_premium_onenand_small mips vct_premium_small
Using built-in specs. Target: mips-linux Configured with: /home/tony/buildall/src/gcc/configure --target=mips-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/mips-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
Using built-in specs. Target: m68k-linux Configured with: /home/tony/buildall/src/gcc/configure --target=m68k-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/m68k-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
Using built-in specs. Target: powerpc-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
From here:
http://dev.gentoo.org/~vapier/u-boot/
Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c" patches?
powerpc BC3450 powerpc cm5200 powerpc EVAL5200 powerpc galaxy5200 powerpc galaxy5200_LOWBOOT powerpc galaxy5200_LOWBOOT powerpc inka4x0 powerpc mcc200_COM12 powerpc mcc200_COM12_highboot powerpc mcc200_COM12_highboot_SDRAM powerpc mcc200_COM12_SDRAM powerpc mcc200_COM12_highboot powerpc mcc200_COM12_highboot_SDRAM powerpc mcc200_COM12_highboot_SDRAM powerpc mcc200_COM12_SDRAM powerpc mcc200 powerpc mcc200_COM12 powerpc mcc200_COM12_highboot powerpc mcc200_COM12_highboot_SDRAM powerpc mcc200_COM12_SDRAM powerpc mcc200_highboot powerpc mcc200_highboot_SDRAM powerpc mcc200_SDRAM powerpc prs200 powerpc prs200_DDR powerpc prs200_highboot powerpc prs200_highboot_DDR powerpc mcc200_highboot powerpc mcc200_highboot_SDRAM powerpc mcc200_highboot_SDRAM powerpc mcc200_SDRAM powerpc PM520_DDR powerpc PM520 powerpc PM520_DDR powerpc PM520_ROMBOOT powerpc PM520_ROMBOOT_DDR powerpc PM520_ROMBOOT_DDR powerpc PM520_ROMBOOT powerpc PM520_ROMBOOT_DDR powerpc prs200_DDR powerpc prs200 powerpc prs200_DDR powerpc prs200_highboot powerpc prs200_highboot_DDR powerpc prs200_highboot_DDR powerpc prs200_highboot powerpc prs200_highboot_DDR powerpc TB5200_B powerpc TB5200 powerpc TB5200_B powerpc Total5200 powerpc Total5200_lowboot powerpc Total5200_Rev2 powerpc Total5200_Rev2_lowboot powerpc Total5200_lowboot powerpc Total5200_Rev2 powerpc Total5200_Rev2_lowboot powerpc Total5200_Rev2_lowboot powerpc v38b
and
powerpc acadia powerpc acadia_nand powerpc acadia_nand powerpc bamboo powerpc bamboo_nand powerpc bamboo_nand powerpc korat powerpc korat_perm powerpc korat_perm powerpc pcs440ep
I wonder why I don't see any such warnings. Which exact commit ID are you building?
I was building with this :
commit 9a420986cccc9bd2c37affd931d627b3c3e72952 Author: Rob Herring rob.herring@calxeda.com Date: Thu Dec 15 11:15:50 2011 +0000
ARM: highbank: enable networking and pxe
(so before all the common.h problems).
Regards, Simon
Thanks.
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@denx.de Make it right before you make it faster.
Dear Simon,
In message CAPnjgZ1OxJJsSEodSM-fqTN791mW-UezqWjFLQBAS-4RbFHJkQ@mail.gmail.com you wrote:
Can you please tell me at least one board configuration that throws this error (preferrably ppc, arm or mips) ?
I can't see one with those architectures. It does happen for others though:
...
Strange. Both MIPS and PPC build without a single warning for me.
I cannot test avr32 or m68k here.
Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c" patches?
None here.
I am tempted to blame your tool chain for the problems.
Is anybody else seing these warnings? With which tool chain versions?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Fri, Jan 6, 2012 at 3:37 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1OxJJsSEodSM-fqTN791mW-UezqWjFLQBAS-4RbFHJkQ@mail.gmail.com you wrote:
Can you please tell me at least one board configuration that throws this error (preferrably ppc, arm or mips) ?
I can't see one with those architectures. It does happen for others though:
...
Strange. Both MIPS and PPC build without a single warning for me.
I cannot test avr32 or m68k here.
Also, at least one for the "mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c" and "ppc4xx: Fix strict-aliasing warnings in usb_ohci.c" patches?
None here.
I am tempted to blame your tool chain for the problems.
Could be - well you can download it for yourself if you want to try it.
http://dev.gentoo.org/~vapier/u-boot/
The warnings seems mostly reasonable (i.e. correct) to me, except for the new USB alias one AFTER Marek's fix. That one I don't quite understand.
Is anybody else seing these warnings? With which tool chain versions?
Will wait to hear from people.
Regards, Simon
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@denx.de If you fail to plan, plan to fail.
On Friday 06 January 2012 15:39:08 Simon Glass wrote:
On Thu, Jan 5, 2012 at 10:48 PM, Wolfgang Denk wrote:
Simon Glass wrote:
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
Which exact version is this?
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
Can you please tell me at least one board configuration that throws this error (preferrably ppc, arm or mips) ?
I can't see one with those architectures. It does happen for others though:
yes, there have been reports and patches posted in the past iirc. first by Kumar i think. -mike
Dear Simon Glass,
On 06.01.2012 04:54, Simon Glass wrote:
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
This is really annoying, but ...
Signed-off-by: Simon Glass sjg@chromium.org
common/dlmalloc.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index c645d73..0a719b4 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = { #ifdef CONFIG_NEEDS_MANUAL_RELOC void malloc_bin_reloc (void) {
- unsigned long *p = (unsigned long *)(&av_[2]);
- mbinptr *p = &av_[2]; int i;
- for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) {
*p++ += gd->reloc_off;- }
- for (i = 2; i < ARRAY_SIZE(av_); ++i)
*p = (mbinptr)((ulong)*p + gd->reloc_off);
your patch breaks avr32 boards at runtime:
---8<--- U-Boot 2012.07-00134-g6073aab (Aug 13 2012 - 17:16:34)
U-Boot code: 00000000 -> 00013588 data: 0001ab70 -> 00050448 VMR table @ 0x107ca4bc DMA: Using memory from 0x1076b000 to 0x1076f000 Flash: 8 MiB at address 0x00000000 DRAM Configuration: Bank #0: 10000000 8 MiB
*** Unhandled exception 24 at PC=0x107b442e [0000542e] MMU exception at address 0x7af1ade4 pc: 107b442e lr: 0001b1c8 sp: 1076aecc r12: 00000001 r11: 00000000 r10: 00000079 r9: 107c9de8 r8: 107c9de0 r7: 00010000 r6: 107ca9ac r5: 1076af90 r4: 0000007e r3: 7af1ade0 r2: 107cb8f0 r1: 00000000 r0: 107cb908 Flags: qvnzc Mode bits: hrje....g CPU Mode: Supervisor --->8---
A working solution is http://patchwork.ozlabs.org/patch/176885/
Would be great to remove this aliasing warning in 2012.10
Best regards
Andreas Bießmann
Dear Simon Glas,
On 13.08.2012 17:25, Andreas Bießmann wrote:
Dear Simon Glass,
On 06.01.2012 04:54, Simon Glass wrote:
This fixes the following warnings in dlmalloc seen with my gcc 4.6.
dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here
This is really annoying, but ...
Signed-off-by: Simon Glass sjg@chromium.org
common/dlmalloc.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c index c645d73..0a719b4 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -1487,11 +1487,11 @@ static mbinptr av_[NAV * 2 + 2] = { #ifdef CONFIG_NEEDS_MANUAL_RELOC void malloc_bin_reloc (void) {
- unsigned long *p = (unsigned long *)(&av_[2]);
- mbinptr *p = &av_[2]; int i;
- for (i=2; i<(sizeof(av_)/sizeof(mbinptr)); ++i) {
*p++ += gd->reloc_off;- }
- for (i = 2; i < ARRAY_SIZE(av_); ++i)
*p = (mbinptr)((ulong)*p + gd->reloc_off);
------------------^
Ouch ... isn't there something missing? Who increments the pointer? ;)
your patch breaks avr32 boards at runtime:
Will send a new version which supersedes this one and http://patchwork.ozlabs.org/patch/176885/
Best regards
Andreas Bießmann
This fixes warnings seen with my gcc 4.6.
usb_ohci.c: In function 'submit_control_msg': usb_ohci.c:1041: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1041: note: initialized from here usb_ohci.c:1043: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1043: note: initialized from here usb_ohci.c:1045: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules
Signed-off-by: Simon Glass sjg@chromium.org --- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 +++++++++++++++++++++-------------- 1 files changed, 47 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/cpu/mpc5xxx/usb_ohci.c b/arch/powerpc/cpu/mpc5xxx/usb_ohci.c index d250c19..d78badc 100644 --- a/arch/powerpc/cpu/mpc5xxx/usb_ohci.c +++ b/arch/powerpc/cpu/mpc5xxx/usb_ohci.c @@ -1005,12 +1005,19 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe, int len = 0; int stat = 0; __u32 datab[4]; - __u8 *data_buf = (__u8 *)datab; + union { + void *ptr; + __u8 *u8; + __u16 *u16; + __u32 *u32; + } databuf; __u16 bmRType_bReq; __u16 wValue; __u16 wIndex; __u16 wLength;
+ databuf.u32 = (__u32 *)datab; + #ifdef DEBUG urb_priv.actual_length = 0; pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); @@ -1038,17 +1045,21 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); */
case RH_GET_STATUS: - *(__u16 *) data_buf = m16_swap (1); OK (2); + databuf.u16[0] = m16_swap(1); + OK(2); case RH_GET_STATUS | RH_INTERFACE: - *(__u16 *) data_buf = m16_swap (0); OK (2); + databuf.u16[0] = m16_swap(0); + OK(2); case RH_GET_STATUS | RH_ENDPOINT: - *(__u16 *) data_buf = m16_swap (0); OK (2); + databuf.u16[0] = m16_swap(0); + OK(2); case RH_GET_STATUS | RH_CLASS: - *(__u32 *) data_buf = m32_swap ( - RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE)); - OK (4); + databuf.u32[0] = m32_swap( + RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE)); + OK(4); case RH_GET_STATUS | RH_OTHER | RH_CLASS: - *(__u32 *) data_buf = m32_swap (RD_RH_PORTSTAT); OK (4); + databuf.u32[0] = m32_swap(RD_RH_PORTSTAT); + OK(4);
case RH_CLEAR_FEATURE | RH_ENDPOINT: switch (wValue) { @@ -1113,14 +1124,14 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_dev_des), wLength)); - data_buf = root_hub_dev_des; OK(len); + databuf.ptr = root_hub_dev_des; OK(len); case (0x02): /* configuration descriptor */ len = min_t(unsigned int, leni, min_t(unsigned int, sizeof (root_hub_config_des), wLength)); - data_buf = root_hub_config_des; OK(len); + databuf.ptr = root_hub_config_des; OK(len); case (0x03): /* string descriptors */ if(wValue==0x0300) { len = min_t(unsigned int, @@ -1128,7 +1139,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_str_index0), wLength)); - data_buf = root_hub_str_index0; + databuf.ptr = root_hub_str_index0; OK(len); } if(wValue==0x0301) { @@ -1137,7 +1148,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_str_index1), wLength)); - data_buf = root_hub_str_index1; + databuf.ptr = root_hub_str_index1; OK(len); } default: @@ -1149,38 +1160,42 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); { __u32 temp = roothub_a (&gohci);
- data_buf [0] = 9; /* min length; */ - data_buf [1] = 0x29; - data_buf [2] = temp & RH_A_NDP; - data_buf [3] = 0; + databuf.u8[0] = 9; /* min length; */ + databuf.u8[1] = 0x29; + databuf.u8[2] = temp & RH_A_NDP; + databuf.u8[3] = 0; if (temp & RH_A_PSM) /* per-port power switching? */ - data_buf [3] |= 0x1; + databuf.u8[3] |= 0x1; if (temp & RH_A_NOCP) /* no overcurrent reporting? */ - data_buf [3] |= 0x10; + databuf.u8[3] |= 0x10; else if (temp & RH_A_OCPM) /* per-port overcurrent reporting? */ - data_buf [3] |= 0x8; + databuf.u8[3] |= 0x8;
/* corresponds to data_buf[4-7] */ - datab [1] = 0; - data_buf [5] = (temp & RH_A_POTPGT) >> 24; + databuf.u32[1] = 0; + databuf.u8[5] = (temp & RH_A_POTPGT) >> 24; temp = roothub_b (&gohci); - data_buf [7] = temp & RH_B_DR; - if (data_buf [2] < 7) { - data_buf [8] = 0xff; + databuf.u8[7] = temp & RH_B_DR; + if (databuf.u8[2] < 7) { + databuf.u8[8] = 0xff; } else { - data_buf [0] += 2; - data_buf [8] = (temp & RH_B_DR) >> 8; - data_buf [10] = data_buf [9] = 0xff; + databuf.u8[0] += 2; + databuf.u8[8] = (temp & RH_B_DR) >> 8; + databuf.u8[10] = databuf.u8[9] = 0xff; }
len = min_t(unsigned int, leni, - min_t(unsigned int, data_buf [0], wLength)); + min_t(unsigned int, databuf.u8[0], wLength)); OK (len); }
- case RH_GET_CONFIGURATION: *(__u8 *) data_buf = 0x01; OK (1); + case RH_GET_CONFIGURATION: + databuf.u8[0] = 0x01; + OK(1);
- case RH_SET_CONFIGURATION: WR_RH_STAT (0x10000); OK (0); + case RH_SET_CONFIGURATION: + WR_RH_STAT(0x10000); + OK(0);
default: dbg ("unsupported root hub command"); @@ -1192,8 +1207,8 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); #endif
len = min_t(int, len, leni); - if (data != data_buf) - memcpy (data, data_buf, len); + if (data != databuf.ptr) + memcpy(data, databuf.ptr, len); dev->act_len = len; dev->status = stat;
This fixes warnings seen with my gcc 4.6.
usb_ohci.c: In function 'submit_control_msg': usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1046: note: initialized from here usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1048: note: initialized from here usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules
Signed-off-by: Simon Glass sjg@chromium.org --- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 +++++++++++++++++++++--------------- 1 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/usb_ohci.c b/arch/powerpc/cpu/ppc4xx/usb_ohci.c index 4fb7031..57fa24f 100644 --- a/arch/powerpc/cpu/ppc4xx/usb_ohci.c +++ b/arch/powerpc/cpu/ppc4xx/usb_ohci.c @@ -1010,12 +1010,19 @@ static int ohci_submit_rh_msg(struct usb_device *dev, unsigned long pipe, int len = 0; int stat = 0; __u32 datab[4]; - __u8 *data_buf = (__u8 *)datab; + union { + void *ptr; + __u8 *u8; + __u16 *u16; + __u32 *u32; + } databuf; __u16 bmRType_bReq; __u16 wValue; __u16 wIndex; __u16 wLength;
+ databuf.u32 = (__u32 *)datab; + #ifdef DEBUG urb_priv.actual_length = 0; pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); @@ -1043,17 +1050,21 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); */
case RH_GET_STATUS: - *(__u16 *) data_buf = m16_swap (1); OK (2); + databuf.u16[0] = m16_swap(1); + OK(2); case RH_GET_STATUS | RH_INTERFACE: - *(__u16 *) data_buf = m16_swap (0); OK (2); + databuf.u16[0] = m16_swap(0); + OK(2); case RH_GET_STATUS | RH_ENDPOINT: - *(__u16 *) data_buf = m16_swap (0); OK (2); + databuf.u16[0] = m16_swap(0); + OK(2); case RH_GET_STATUS | RH_CLASS: - *(__u32 *) data_buf = m32_swap ( - RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE)); - OK (4); + databuf.u32[0] = m32_swap( + RD_RH_STAT & ~(RH_HS_CRWE | RH_HS_DRWE)); + OK(4); case RH_GET_STATUS | RH_OTHER | RH_CLASS: - *(__u32 *) data_buf = m32_swap (RD_RH_PORTSTAT); OK (4); + databuf.u32[0] = m32_swap(RD_RH_PORTSTAT); + OK(4);
case RH_CLEAR_FEATURE | RH_ENDPOINT: switch (wValue) { @@ -1118,14 +1129,14 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_dev_des), wLength)); - data_buf = root_hub_dev_des; OK(len); + databuf.ptr = root_hub_dev_des; OK(len); case (0x02): /* configuration descriptor */ len = min_t(unsigned int, leni, min_t(unsigned int, sizeof (root_hub_config_des), wLength)); - data_buf = root_hub_config_des; OK(len); + databuf.ptr = root_hub_config_des; OK(len); case (0x03): /* string descriptors */ if(wValue==0x0300) { len = min_t(unsigned int, @@ -1133,7 +1144,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_str_index0), wLength)); - data_buf = root_hub_str_index0; + databuf.ptr = root_hub_str_index0; OK(len); } if(wValue==0x0301) { @@ -1142,7 +1153,7 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); min_t(unsigned int, sizeof (root_hub_str_index1), wLength)); - data_buf = root_hub_str_index1; + databuf.ptr = root_hub_str_index1; OK(len); } default: @@ -1154,38 +1165,42 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); { __u32 temp = roothub_a (&gohci);
- data_buf [0] = 9; /* min length; */ - data_buf [1] = 0x29; - data_buf [2] = temp & RH_A_NDP; - data_buf [3] = 0; + databuf.u8[0] = 9; /* min length; */ + databuf.u8[1] = 0x29; + databuf.u8[2] = temp & RH_A_NDP; + databuf.u8[3] = 0; if (temp & RH_A_PSM) /* per-port power switching? */ - data_buf [3] |= 0x1; + databuf.u8[3] |= 0x1; if (temp & RH_A_NOCP) /* no overcurrent reporting? */ - data_buf [3] |= 0x10; + databuf.u8[3] |= 0x10; else if (temp & RH_A_OCPM) /* per-port overcurrent reporting? */ - data_buf [3] |= 0x8; + databuf.u8[3] |= 0x8;
/* corresponds to data_buf[4-7] */ - datab [1] = 0; - data_buf [5] = (temp & RH_A_POTPGT) >> 24; + databuf.u32[1] = 0; + databuf.u8[5] = (temp & RH_A_POTPGT) >> 24; temp = roothub_b (&gohci); - data_buf [7] = temp & RH_B_DR; - if (data_buf [2] < 7) { - data_buf [8] = 0xff; + databuf.u8[7] = temp & RH_B_DR; + if (databuf.u8[2] < 7) { + databuf.u8[8] = 0xff; } else { - data_buf [0] += 2; - data_buf [8] = (temp & RH_B_DR) >> 8; - data_buf [10] = data_buf [9] = 0xff; + databuf.u8[0] += 2; + databuf.u8[8] = (temp & RH_B_DR) >> 8; + databuf.u8[10] = databuf.u8[9] = 0xff; }
len = min_t(unsigned int, leni, - min_t(unsigned int, data_buf [0], wLength)); - OK (len); + min_t(unsigned int, databuf.u8[0], wLength)); + OK(len); }
- case RH_GET_CONFIGURATION: *(__u8 *) data_buf = 0x01; OK (1); + case RH_GET_CONFIGURATION: + databuf.u8[0] = 0x01; + OK(1);
- case RH_SET_CONFIGURATION: WR_RH_STAT (0x10000); OK (0); + case RH_SET_CONFIGURATION: + WR_RH_STAT(0x10000); + OK(0);
default: dbg ("unsupported root hub command"); @@ -1197,8 +1212,8 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe)); #endif
len = min_t(int, len, leni); - if (data != data_buf) - memcpy (data, data_buf, len); + if (data != databuf.ptr) + memcpy(data, databuf.ptr, len); dev->act_len = len; dev->status = stat;
Dear Simon Glass,
This fixes warnings seen with my gcc 4.6.
usb_ohci.c: In function 'submit_control_msg': usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1046: note: initialized from here usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1048: note: initialized from here usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules
[...]
Are we still seeing these?
Best regards, Marek Vasut
Hi Marek,
On Mon, Oct 15, 2012 at 11:28 PM, Marek Vasut marex@denx.de wrote:
Dear Simon Glass,
This fixes warnings seen with my gcc 4.6.
usb_ohci.c: In function 'submit_control_msg': usb_ohci.c:1046: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1046: note: initialized from here usb_ohci.c:1048: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules usb_ohci.c:1048: note: initialized from here usb_ohci.c:1050: warning: dereferencing pointer 'data_buf.70' does break strict-aliasing rules
[...]
Are we still seeing these?
I see them with my compiler, but I might be in a minority of one here. I am working on getting a new powerpc tool chain.
Regards, Simon
Best regards, Marek Vasut
Tidy this up as the list is long and likely to get longer.
Signed-off-by: Simon Glass sjg@chromium.org --- arch/sandbox/cpu/os.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index 6d55b5c..700c1a7 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -19,16 +19,16 @@ * MA 02111-1307 USA */
+#include <errno.h> #include <fcntl.h> +#include <linux/types.h> #include <stdlib.h> #include <termios.h> -#include <unistd.h> #include <time.h> -#include <errno.h> -#include <sys/types.h> -#include <sys/stat.h> +#include <unistd.h> #include <sys/mman.h> -#include <linux/types.h> +#include <sys/stat.h> +#include <sys/types.h>
#include <os.h>
On Thursday 05 January 2012 22:54:53 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c
+#include <errno.h> #include <fcntl.h> +#include <linux/types.h> #include <stdlib.h> #include <termios.h> -#include <unistd.h> #include <time.h> -#include <errno.h> -#include <sys/types.h> -#include <sys/stat.h> +#include <unistd.h> #include <sys/mman.h> -#include <linux/types.h> +#include <sys/stat.h> +#include <sys/types.h>
the order should generally be: - stuff in include/ - stuff in sys/ - stuff in linux/ - stuff in asm/ each sub-region can be sorted, but i don't think we should go against the subdir rule -mike
Hi Mike,
On Sun, Jan 8, 2012 at 12:49 AM, Mike Frysinger vapier@gentoo.org wrote:
On Thursday 05 January 2012 22:54:53 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c
+#include <errno.h> #include <fcntl.h> +#include <linux/types.h> #include <stdlib.h> #include <termios.h> -#include <unistd.h> #include <time.h> -#include <errno.h> -#include <sys/types.h> -#include <sys/stat.h> +#include <unistd.h> #include <sys/mman.h> -#include <linux/types.h> +#include <sys/stat.h> +#include <sys/types.h>
the order should generally be: - stuff in include/ - stuff in sys/ - stuff in linux/ - stuff in asm/ each sub-region can be sorted, but i don't think we should go against the subdir rule
OK done, thanks.
Regards, Simon
-mike
We should include sys/time.h header to avoid warnings.
Signed-off-by: Simon Glass sjg@chromium.org --- arch/sandbox/cpu/os.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index 700c1a7..ebd0ff1 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -28,6 +28,7 @@ #include <unistd.h> #include <sys/mman.h> #include <sys/stat.h> +#include <sys/time.h> #include <sys/types.h>
#include <os.h>
On Thursday 05 January 2012 22:54:54 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c
#include <unistd.h> #include <sys/mman.h> #include <sys/stat.h> +#include <sys/time.h> #include <sys/types.h>
#include <os.h>
guess this will need a rebase once 5/9 is rewritten -mike
Hi Mike,
On Sun, Jan 8, 2012 at 12:49 AM, Mike Frysinger vapier@gentoo.org wrote:
On Thursday 05 January 2012 22:54:54 Simon Glass wrote:
--- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c
#include <unistd.h> #include <sys/mman.h> #include <sys/stat.h> +#include <sys/time.h> #include <sys/types.h>
#include <os.h>
guess this will need a rebase once 5/9 is rewritten
Yes that right, will resubmit.
Regards, Simon
-mike
This feature is not available on ARM, so it is an error to define it.
Signed-off-by: Simon Glass sjg@chromium.org --- include/configs/snapper9260.h | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h index cb3c674..cee65d1 100644 --- a/include/configs/snapper9260.h +++ b/include/configs/snapper9260.h @@ -157,7 +157,6 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_LONGHELP -#define CONFIG_SYS_EXTBDINFO #define CONFIG_CMDLINE_EDITING #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_HUSH_PARSER
On 06/01/2012 04:54, Simon Glass wrote:
This feature is not available on ARM, so it is an error to define it.
Signed-off-by: Simon Glass sjg@chromium.org
include/configs/snapper9260.h | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h index cb3c674..cee65d1 100644 --- a/include/configs/snapper9260.h +++ b/include/configs/snapper9260.h @@ -157,7 +157,6 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_LONGHELP -#define CONFIG_SYS_EXTBDINFO #define CONFIG_CMDLINE_EDITING #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_HUSH_PARSER
Acked-by: Stefano Babic sbabic@denx.de
Best regards, Stefano Babic
On Thu, 5 Jan 2012 19:54:55 -0800 Simon Glass sjg@chromium.org wrote:
This feature is not available on ARM, so it is an error to define it.
Signed-off-by: Simon Glass sjg@chromium.org
include/configs/snapper9260.h | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
Applied to u-boot-staging/agust@denx.de, thanks!
Anatolij
There doesn't seem to be any reason for using uchar here, so change it to char. This fixes a warning:
pointer targets in passing argument 1 of 'sprintf' differ in signedness
Signed-off-by: Simon Glass sjg@chromium.org --- arch/m68k/lib/board.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/lib/board.c b/arch/m68k/lib/board.c index 259b71c..1526967 100644 --- a/arch/m68k/lib/board.c +++ b/arch/m68k/lib/board.c @@ -639,7 +639,7 @@ void board_init_r (gd_t *id, ulong dest_addr) */ { ulong pram = 0; - uchar memsz[32]; + char memsz[32];
#ifdef CONFIG_PRAM pram = getenv_ulong("pram", 10, CONFIG_PRAM);
Acked-by: Mike Frysinger vapier@gentoo.org -mike
On 06/01/2012 04:54, Simon Glass wrote:
There doesn't seem to be any reason for using uchar here, so change it to char. This fixes a warning:
pointer targets in passing argument 1 of 'sprintf' differ in signedness
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot-staging, sbabic@denx.de branch, thanks.
Best regards, Stefano Babic
This seems to be unsigned char for no good reason. Tidy this up and remove the casts.
Signed-off-by: Simon Glass sjg@chromium.org --- arch/powerpc/lib/board.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c index ff5888e..3f9af1d 100644 --- a/arch/powerpc/lib/board.c +++ b/arch/powerpc/lib/board.c @@ -1021,7 +1021,7 @@ void board_init_r(gd_t *id, ulong dest_addr) */ { ulong pram = 0; - uchar memsz[32]; + char memsz[32];
#ifdef CONFIG_PRAM pram = getenv_ulong("pram", 10, CONFIG_PRAM); @@ -1032,9 +1032,8 @@ void board_init_r(gd_t *id, ulong dest_addr) pram += (LOGBUFF_LEN + LOGBUFF_OVERHEAD) / 1024; #endif #endif - sprintf((char *) memsz, "%ldk", - (bd->bi_memsize / 1024) - pram); - setenv("mem", (char *) memsz); + sprintf(memsz, "%ldk", (bd->bi_memsize / 1024) - pram); + setenv("mem", memsz); } #endif
Acked-by: Mike Frysinger vapier@gentoo.org -mike
On 06/01/2012 04:54, Simon Glass wrote:
This seems to be unsigned char for no good reason. Tidy this up and remove the casts.
Signed-off-by: Simon Glass sjg@chromium.org
Applied to u-boot-staging, sbabic@denx.de branch, thanks.
Best regards, Stefano Babic
Dear Simon Glass,
In message 1325822097-15227-1-git-send-email-sjg@chromium.org you wrote:
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Can you please let me know which tool chain is throwing these errors? I built "master" yesterday, and before adding the commit that introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with ELDK 5.2 (gcc 4.6.3).
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, Jan 5, 2012 at 10:20 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1325822097-15227-1-git-send-email-sjg@chromium.org you wrote:
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Can you please let me know which tool chain is throwing these errors? I built "master" yesterday, and before adding the commit that introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with ELDK 5.2 (gcc 4.6.3).
I just check that - actually my PowerPC one is v4.4.4:
Using built-in specs. Target: powerpc-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
I got this from Mike F (from the Gentoo site).
Regards, Simon
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@denx.de Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon
Hi Wolfgang / Stefano,
On Thu, Jan 5, 2012 at 10:28 PM, Simon Glass sjg@chromium.org wrote:
Hi Wolfgang,
On Thu, Jan 5, 2012 at 10:20 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1325822097-15227-1-git-send-email-sjg@chromium.org you wrote:
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Can you please let me know which tool chain is throwing these errors? I built "master" yesterday, and before adding the commit that introduced the ``"_LINUX_CONFIG_H" redefined'' issue the PPC tree was built clean - with ELDK 4.2 (gcc 4.2.2), ELDK 5.1 (gcc 4.6.1) and with ELDK 5.2 (gcc 4.6.3).
I just check that - actually my PowerPC one is v4.4.4:
Using built-in specs. Target: powerpc-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
I got this from Mike F (from the Gentoo site).
What should we do about this series? I still see these warnings with the toolchains I use [1]. Does anyone else?
Regards, Simon
[1] http://dev.gentoo.org/~vapier/u-boot/
Regards, Simon
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@denx.de Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon
On 20/02/2012 19:49, Simon Glass wrote:
Hi Wolfgang / Stefano,
Hi Simon,
I just check that - actually my PowerPC one is v4.4.4:
Using built-in specs. Target: powerpc-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/cross/gcc-4.4.4-nolibc/powerpc-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys --with-gmp=/home/tony/buildall/src/sys Thread model: single gcc version 4.4.4 (GCC)
I got this from Mike F (from the Gentoo site).
What should we do about this series? I still see these warnings with the toolchains I use [1]. Does anyone else?
I read the whole thread, and it seems that it is not clear if the warnings are real or must be related to the used toolchain.
I will try myself with mips, as this is one of the architectures reporting warnings.
However, current toolchains based on more restrictive compilers (I mean, GCC >= 4.6) seem to be happy with the code. At least a couple of patches reassembles code that seems correct...
IMHO if the code cannot be built with an older toolchain we can try to fix, and also we must drop warnings with newer and current toolchains (a lot of patches fixed gcc 4.6 warnings). I am aware that we cannot support every toolchain, even if we try to do it. And maybe (only my opinion) it is acceptable to have some warnings with older toolchains.
So tendentially my vote is not to take these patches, but Wolfgang has the last word on them.
Stefano
On 21/02/2012 11:20, Stefano Babic wrote:
I will try myself with mips, as this is one of the architectures reporting warnings.
Just to report this: a "MAKEALL mips" reports no warning with a ggc 4.6 compiler : gcc version 4.6.1 20110627 (prerelease) (GCC)
It seems to me that the warnings are more related to the selected toolchain.
Stefano
On 21/02/2012 18:06, Mike Frysinger wrote:
On Tuesday 21 February 2012 05:20:47 Stefano Babic wrote:
I will try myself with mips, as this is one of the architectures reporting warnings.
i don't think Simon did say that mips was throwing these warnings, so testing that arch and looking for these warnings won't help
In the thread I read that Simon got warnings with both mips and powerpc, as well as with avr32 and m68k. But mips and powerpc are free of warnings when I build with gcc 4.6.
Stefano
Hi Stefano,
On Tue, Feb 21, 2012 at 9:15 AM, Stefano Babic sbabic@denx.de wrote:
On 21/02/2012 18:06, Mike Frysinger wrote:
On Tuesday 21 February 2012 05:20:47 Stefano Babic wrote:
I will try myself with mips, as this is one of the architectures reporting warnings.
i don't think Simon did say that mips was throwing these warnings, so testing that arch and looking for these warnings won't help
Part of the problem is that I mislabeled the commits, claiming that I was using a 4.6 compiler when in fact mostly it was 4.4.4.
In the thread I read that Simon got warnings with both mips and powerpc, as well as with avr32 and m68k. But mips and powerpc are free of warnings when I build with gcc 4.6.
Yes but not just those. There are detailed notes with each patch, but here is a summary. I think 6 out of 9 patches should be applied regardless of toolchain.
68k only: arch/m68k/lib/board.c | 2 +- - I believe this fix is sensible for the reasons described in the patch, regardless of what the toolchain does.
PPC only: arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-------------- - These two seem not to happen with a later toolchain. Please skip these if you like.
arch/powerpc/lib/board.c | 7 +-- - Similar to the68k patch, again I think it makes sense to apply this. The variable is unsigned char for no good reason.
Sandbox: arch/sandbox/cpu/os.c | 11 +++-- - This should be applied as it is not toolchain dependent (Mike may have picked it up already)
common/dlmalloc.c | 8 ++-- - These happen with MIPS, AVR, 68k for me (with Mike's toolchains). Does not happen on 4.6 ARM.
ARM and PPC: drivers/usb/host/ohci-hcd.c | 26 ++++++------ - These happen with my 4.4.4 compiler, apparently not on 4.6. Drop them if you like.
ARM: include/configs/snapper9260.h | 1 - - This fixes a real problem regardless of toolchain.
Regards, Simon
Stefano
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Tuesday 21 February 2012 13:40:36 Simon Glass wrote:
68k only: arch/m68k/lib/board.c | 2 +-
- I believe this fix is sensible for the reasons described in the
patch, regardless of what the toolchain does.
arch/powerpc/lib/board.c | 7 +--
- Similar to the68k patch, again I think it makes sense to apply this.
The variable is unsigned char for no good reason.
i agree
Sandbox: arch/sandbox/cpu/os.c | 11 +++--
- This should be applied as it is not toolchain dependent (Mike may
have picked it up already)
i have
common/dlmalloc.c | 8 ++--
- These happen with MIPS, AVR, 68k for me (with Mike's toolchains).
what boards ? i tried a bunch of m68k ones and aren't seeing it ... -mike
On 21/02/2012 19:40, Simon Glass wrote:
Yes but not just those. There are detailed notes with each patch, but here is a summary. I think 6 out of 9 patches should be applied regardless of toolchain.
68k only: arch/m68k/lib/board.c | 2 +-
- I believe this fix is sensible for the reasons described in the
patch, regardless of what the toolchain does.
Agree - I will send my ACK and merge it into my u-boot-staging
arch/powerpc/lib/board.c | 7 +--
- Similar to the68k patch, again I think it makes sense to apply this.
The variable is unsigned char for no good reason.
Agree, there is no reason. I will merge also this one into u-boot-staging.
Sandbox: arch/sandbox/cpu/os.c | 11 +++--
- This should be applied as it is not toolchain dependent (Mike may
have picked it up already)
Ok, the patch has already found its way to mainline
ARM and PPC: drivers/usb/host/ohci-hcd.c | 26 ++++++------
- These happen with my 4.4.4 compiler, apparently not on 4.6. Drop
them if you like.
ARM: include/configs/snapper9260.h | 1 -
- This fixes a real problem regardless of toolchain.
Right. I will send my ACK with CC to Albert. He can pick-up it directly into u-boot-arm.
Best regards, Stefano
Dear Simon Glass,
In message CAPnjgZ0Mb=LJBE3JSs0zOqivHY5pRfYNGpS3vnfs6O=SQXu9vQ@mail.gmail.com you wrote:
Yes but not just those. There are detailed notes with each patch, but here is a summary. I think 6 out of 9 patches should be applied regardless of toolchain.
Then please re-test these and re-submit them, clearly indicating which errors / warnings these are supposed to fix.
PPC only: arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-----------=
arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-----------=
- These two seem not to happen with a later toolchain. Please skip
these if you like.
They also seem not to happen with older tool chains (like GCC 4.2.2).
common/dlmalloc.c | 8 ++--
- These happen with MIPS, AVR, 68k for me (with Mike's toolchains).
Does not happen on 4.6 ARM.
Not seen with GCC 4.2.2 nor with GCC 4.6.
ARM and PPC: drivers/usb/host/ohci-hcd.c | 26 ++++++------
- These happen with my 4.4.4 compiler, apparently not on 4.6. Drop
them if you like.
Not seen with GCC 4.2.2 nor with GCC 4.6.
Best regards,
Wolfgang Denk
Dear Simon Glass,
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Simon Glass (9): usb: Fix strict-aliasing warning in host/ohci-hcd.c Fix strict-aliasing warning in dlmalloc mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c ppc4xx: Fix strict-aliasing warnings in usb_ohci.c sandbox: sort header files in os.c sandbox: Add required header to os.c Remove CONFIG_SYS_EXTBDINFO from snapper9260.h m68k: Change memsz to a signed char to avoid warning ppc: Change memsz variable to signed char
arch/m68k/lib/board.c | 2 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c | 7 +-- arch/sandbox/cpu/os.c | 11 +++-- common/dlmalloc.c | 8 ++-- drivers/usb/host/ohci-hcd.c | 26 ++++++------ include/configs/snapper9260.h | 1 - 8 files changed, 122 insertions(+), 93 deletions(-)
Can you please split out the USB part and send it to me (I became new usb maint.) please?
Thanks in advance!
Best regards, Marek Vasut
Hi Marek,
On Mon, Mar 5, 2012 at 10:22 AM, Marek Vasut marex@denx.de wrote:
Dear Simon Glass,
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Simon Glass (9): usb: Fix strict-aliasing warning in host/ohci-hcd.c Fix strict-aliasing warning in dlmalloc mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c ppc4xx: Fix strict-aliasing warnings in usb_ohci.c sandbox: sort header files in os.c sandbox: Add required header to os.c Remove CONFIG_SYS_EXTBDINFO from snapper9260.h m68k: Change memsz to a signed char to avoid warning ppc: Change memsz variable to signed char
arch/m68k/lib/board.c | 2 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c | 7 +-- arch/sandbox/cpu/os.c | 11 +++-- common/dlmalloc.c | 8 ++-- drivers/usb/host/ohci-hcd.c | 26 ++++++------ include/configs/snapper9260.h | 1 - 8 files changed, 122 insertions(+), 93 deletions(-)
Can you please split out the USB part and send it to me (I became new usb maint.) please?
Thanks in advance!
Of course - I think you want to look at this one:
http://patchwork.ozlabs.org/patch/134600/
The two PowerPC ones apparently only happen with the 4.4 toolchain, so I think we are going to drop those and I am going to upgrade my toolchain instead :-)
Regards, Simon
Best regards, Marek Vasut
Hi Simon,
<snip>
arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++--------------
arch/powerpc/cpu/ppc4xx/usb_ohci.c |
81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c
<snip>
The two PowerPC ones apparently only happen with the 4.4 toolchain, so I think we are going to drop those and I am going to upgrade my toolchain instead :-)
This has just grabbed my attention with the comment regarding the 4.4 toolchain as I know that MontaVista ship a version of the 4.4.0 toolchain for PowerPC with one of their embedded Linux products. Is there a generic issue with 4.4.x versions or just a rogue board or two?
Regards,
Andy.
Dear Simon Glass,
Hi Marek,
On Mon, Mar 5, 2012 at 10:22 AM, Marek Vasut marex@denx.de wrote:
Dear Simon Glass,
This series fixes some warnings which seem to still be left over from all the warning-squashing efforts for 2011.12. If patches exist for some of these already then please ignore.
The alias problem in USB is a bit odd, since I thought it was already fixed. But perhaps it has come back.
Simon Glass (9): usb: Fix strict-aliasing warning in host/ohci-hcd.c Fix strict-aliasing warning in dlmalloc mpc5xxx: Fix strict-aliasing warnings in usb_ohci.c ppc4xx: Fix strict-aliasing warnings in usb_ohci.c sandbox: sort header files in os.c sandbox: Add required header to os.c Remove CONFIG_SYS_EXTBDINFO from snapper9260.h m68k: Change memsz to a signed char to avoid warning ppc: Change memsz variable to signed char
arch/m68k/lib/board.c | 2 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 79 ++++++++++++++++++++-------------- arch/powerpc/cpu/ppc4xx/usb_ohci.c | 81 ++++++++++++++++++++-------------- arch/powerpc/lib/board.c
| 7 +--
arch/sandbox/cpu/os.c | 11 +++-- common/dlmalloc.c | 8 ++-- drivers/usb/host/ohci-hcd.c | 26 ++++++------ include/configs/snapper9260.h | 1 - 8 files changed, 122 insertions(+), 93 deletions(-)
Can you please split out the USB part and send it to me (I became new usb maint.) please?
Thanks in advance!
Of course - I think you want to look at this one:
http://patchwork.ozlabs.org/patch/134600/
The two PowerPC ones apparently only happen with the 4.4 toolchain, so I think we are going to drop those and I am going to upgrade my toolchain instead :-)
Can you actually paste the MAKEALL output for those boards where you observe the issue please?
I took a look at that patch and I'm not yet completely convinced by the memcpy business there. Also, I don't want to pick patches from the middle of a patchset, so can you please resend what you consider eligible?
Thanks!
Best regards, Marek Vasut
participants (8)
-
Anatolij Gustschin -
Andreas Bießmann -
Andy Pont -
Marek Vasut -
Mike Frysinger -
Simon Glass -
Stefano Babic -
Wolfgang Denk