linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	 Nathan Chancellor <nathan@kernel.org>,
	kernel test robot <lkp@intel.com>,
	 Hugh Dickins <hughd@google.com>,
	kbuild-all@lists.01.org,
	 clang-built-linux <clang-built-linux@googlegroups.com>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	 Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [linux-next:master 9529/10007] mm/hugetlb.c:1591:9: warning: no previous prototype for function 'hugetlb_basepage_index'
Date: Tue, 15 Jun 2021 16:37:09 -0700 (PDT)	[thread overview]
Message-ID: <dd3fa26c-4da7-8611-fe6-92b2a7c83392@google.com> (raw)
In-Reply-To: <YMj5I2vEGaw6X3Ob@casper.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Tue, 15 Jun 2021, Matthew Wilcox wrote:
> On Tue, Jun 15, 2021 at 11:50:40AM -0700, Nick Desaulniers wrote:
> > On Tue, Jun 15, 2021 at 11:32 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > > On Tue, Jun 15, 2021 at 05:03:40PM +0100, Matthew Wilcox wrote:
> > > > On Tue, Jun 15, 2021 at 11:58:36PM +0800, kernel test robot wrote:
> > > > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
> > > > >
> > > > > If you fix the issue, kindly add following tag as appropriate
> > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > >
> > > > > All warnings (new ones prefixed by >>):
> > > > >
> > > > > >> mm/hugetlb.c:1591:9: warning: no previous prototype for function 'hugetlb_basepage_index' [-Wmissing-prototypes]
> > > > >    pgoff_t hugetlb_basepage_index(struct page *page)
> > > >
> > > > So clang requires the prototype to still be in scope, while gcc doesn't.
> > > > Does one of our clangers want to file a bug about that?
> > >
> > > I see the exact same warning with GCC 11.1.0:
> > >
> > > $ curl -LSs https://lore.kernel.org/linux-mm/202106152328.Mh5S48hE-lkp@intel.com/2-a.bin | gzip -d > .config
> > >
> > > $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- W=1 olddefconfig mm/hugetlb.c
> > > mm/hugetlb.c:1591:9: warning: no previous prototype for 'hugetlb_basepage_index' [-Wmissing-prototypes]
> > >  1591 | pgoff_t hugetlb_basepage_index(struct page *page)
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > 
> > Since this is a commonly recurring warning for W=1 builds, then this
> > function either should be declared as having static linkage if its
> > uses are local to the same file, or a prototype should be declared in
> > a header so that callers and callee agree on function signature.
> 
> Oh, you haven't understood the problem.
> 
> static inline int bar(void)
> {
>         int foo(void);
> 
>         return foo();
> }
> 
> int foo(void) { return 1; }
> 
> The prototype isn't _missing_.  It's just no longer in scope.
> 
> Since gcc and clang behave the same way here, we should adjust the source
> to make foo visible outside bar.  But this is a case where both compilers
> are wrong.

I guess I'd better start W=1-ing - not my habit before, sorry.

I can't tell what's right or wrong for the compiler, but it sure is
odd that if I add a bogus ", int flags" to hugetlb_basepage_index()
in mm/hugetlb.c, then building with gcc (10) and W=1 says

  CC      mm/hugetlb.o
mm/hugetlb.c:1591:9: warning: no previous prototype for ‘hugetlb_basepage_index’ [-Wmissing-prototypes]
 1591 | pgoff_t hugetlb_basepage_index(struct page *page, int flags)
      |         ^~~~~~~~~~~~~~~~~~~~~~
mm/hugetlb.c:1591:9: error: conflicting types for ‘hugetlb_basepage_index’
In file included from mm/hugetlb.c:14:
./include/linux/pagemap.h:543:18: note: previous declaration of ‘hugetlb_basepage_index’ was here
  543 |   extern pgoff_t hugetlb_basepage_index(struct page *page);
      |                  ^~~~~~~~~~~~~~~~~~~~~~

So, it manages to conflict with no previous prototype!
(I didn't try clang with W=1, presumably similar.)

Both gcc and clang with W=0 do issue the conflicting types error,
as I hoped and assumed that they would when I put in the prototype.

Oh well, thanks for moving it Matthew: whatever the rights and wrongs,
neither of us want to be generating unnecessary noise.

Hugh

      reply	other threads:[~2021-06-15 23:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 15:58 kernel test robot
2021-06-15 16:03 ` Matthew Wilcox
2021-06-15 18:32   ` Nathan Chancellor
2021-06-15 18:50     ` Nick Desaulniers
2021-06-15 19:01       ` Matthew Wilcox
2021-06-15 23:37         ` Hugh Dickins [this message]

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=dd3fa26c-4da7-8611-fe6-92b2a7c83392@google.com \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=willy@infradead.org \
    /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