public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit
Date: Thu, 8 Nov 2012 02:30:52 +0100	[thread overview]
Message-ID: <201211080230.52319.marex@denx.de> (raw)
In-Reply-To: <509A8779.7040501@monstr.eu>

Dear Michal Simek,

> On 10/05/2012 06:48 PM, Marek Vasut wrote:
> > Dear Michal Simek,
> > 
> >> ext2_find_next_zero_bit must be also static if __swab32 is also static.
> >> 
> >> Warning:
> >> include/asm/bitops.h:369:22: warning: '__fswab32' is static but
> >> used in inline function 'ext2_find_next_zero_bit'
> >> which is not static [enabled by default]
> >> 
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> ---
> >> 
> >>   arch/microblaze/include/asm/bitops.h |    3 ++-
> >>   1 files changed, 2 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/arch/microblaze/include/asm/bitops.h
> >> b/arch/microblaze/include/asm/bitops.h index e8c835f..eafa2b5 100644
> >> --- a/arch/microblaze/include/asm/bitops.h
> >> +++ b/arch/microblaze/include/asm/bitops.h
> >> @@ -319,7 +319,8 @@ extern __inline__ int ext2_test_bit(int nr, const
> >> volatile void * addr) #define ext2_find_first_zero_bit(addr, size) \
> >> 
> >>   	ext2_find_next_zero_bit((addr), (size), 0)
> >> 
> >> -extern __inline__ unsigned long ext2_find_next_zero_bit(void *addr,
> >> unsigned long size, unsigned long offset) +static inline unsigned long
> >> ext2_find_next_zero_bit(void *addr,
> >> +				unsigned long size, unsigned long offset)
> >> 
> >>   {
> >>   
> >>   	unsigned long *p = ((unsigned long *) addr) + (offset >> 5);
> >>   	unsigned long result = offset & ~31UL;
> > 
> > I'd rather see it done the other way -- drop the inline and let compiler
> > decide. What are the size penalties ?
> 
> With inline
>     text	   data	    bss	    dec	    hex	filename
>   361914	  14698	 232344	 608956	  94abc	./u-boot
> 
> without inline
>     text	   data	    bss	    dec	    hex	filename
>   361922	  14698	 232368	 608988	  94adc	./u-boot
> 
> But the problem is that I can see a lot of warnings that this function is
> unused. u-boot/include/asm/bitops.h:322:22: warning:
> 'ext2_find_next_zero_bit' defined but not used [-Wunused-function]
> 
> FYI: I have just grepped source tree and I see that the same solution is
> used by blackfin/mips and powerpc.
> 
> $ grep -rn "ext2_find_next_zero_bit" arch/ | grep static
> arch/microblaze/include/asm/bitops.h:322:static inline unsigned long
> ext2_find_next_zero_bit(void *addr,
> arch/blackfin/include/asm/bitops.h:324:static __inline__ unsigned long
> ext2_find_next_zero_bit(void *addr,
> arch/mips/include/asm/bitops.h:830:static __inline__ unsigned long
> ext2_find_next_zero_bit(void *addr, unsigned long size, unsigned long
> offset) arch/powerpc/include/asm/bitops.h:344:static __inline__ unsigned
> long ext2_find_next_zero_bit(void *addr,

DAMN :-( Maybe we should focus on --gc-sections for whole u-boot. Anyway, I'd 
say apply this and then start working on the --gc-sections.

Best regards,
Marek Vasut

  reply	other threads:[~2012-11-08  1:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 12:58 [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit Michal Simek
2012-10-05 12:58 ` [U-Boot] [PATCH 2/4] microblaze: Fix byteorder for microblaze Michal Simek
2012-10-05 16:48   ` Marek Vasut
2012-10-11 22:31   ` Stephan Linz
2012-10-05 12:58 ` [U-Boot] [PATCH 3/4] microblaze: Flush caches before enabling them Michal Simek
2012-10-05 16:50   ` Marek Vasut
2012-10-05 12:58 ` [U-Boot] [PATCH 4/4] microblaze: Fix compilation failure because of missing libdts Michal Simek
2012-10-05 16:51   ` Marek Vasut
2012-10-05 16:48 ` [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit Marek Vasut
2012-11-07 16:08   ` Michal Simek
2012-11-08  1:30     ` Marek Vasut [this message]
2012-11-08  7:57       ` Michal Simek
2012-10-11 22:31 ` Stephan Linz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201211080230.52319.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox