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
next prev parent 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