From: George Spelvin <lkml@sdf.org>
To: akpm@linux-foundation.org, lkml@sdf.org, lkp@intel.com,
sfr@canb.auug.org.au
Cc: andriy.shevchenko@linux.intel.com, daniel.wagner@siemens.com,
dchinner@redhat.com, don.mullis@gmail.com, geert@linux-m68k.org,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@rasmusvillemoes.dk, st5pub@yandex.ru
Subject: Re: [RESEND PATCH v2 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS
Date: Fri, 29 Mar 2019 04:10:12 GMT [thread overview]
Message-ID: <201903290410.x2T4ACjG014546@sdf.org> (raw)
In-Reply-To: <20190328150851.5d261d1a72e2ca86a1c141c0@linux-foundation.org>
Than you all for the build warning report.
The warning produced by gcc versions 4.9, 7.3, 8.1, whatever version
Stephen Rothwell is running, is:
lib/list_sort.c:17:36: warning: __pure__ attribute ignored [-Wattributes]
The relevant code is:
10: /*
11: * By declaring the compare function with the __pure attribute, we give
12: * the compiler more opportunity to optimize. Ideally, we'd use this in
13: * the prototype of list_sort(), but that would involve a lot of churn
14: * at all call sites, so just cast the function pointer passed in.
15: */
16: typedef int __pure __attribute__((nonnull(2,3))) (*cmp_func)(void *,
17: struct list_head const *, struct list_head const *);
As the comment says, the purpose of the __pure attribute is to tell
the compiler that, after a call via a function pointer of this
type, memory is not clobbered and it is not necessary to reload
any cached list pointers.
This is, of course, purely optional and may be deleted harmlessly.
I just checked, and that makes no difference at all to gcc-8 code
generation, so there's no point messing with #ifdef.
There are only two questions: how to update the comment, and how
to submit the fix. I'm thinking of
/*
* A more accurate type for comparison functions. Ideally, we'd use
* this in the prototype of list_sort(), but that would involve a lot of
* churn at all call sites, so just cast the function pointer passed in.
*
* This could also include __pure to give the compiler more opportunity
* to optimize, but that elicits an "attribute ignored" warning on
* GCC <= 8.1, and doesn't change GCC 8.3's code generation at all,
* so it's omitted.
*/
How to submit the fix: Andrew, do you prefer a replacement patch
or a small fix patch? I'll assume the latter and send it in a few
minutes.
next prev parent reply other threads:[~2019-03-29 4:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-16 2:43 [PATCH v2 0/5] lib/sort & lib/list_sort: faster and smaller George Spelvin
2019-02-21 6:30 ` [PATCH v2 1/5] lib/sort: Make swap functions more generic George Spelvin
2019-02-21 8:21 ` [PATCH v2 2/5] lib/sort: Use more efficient bottom-up heapsort variant George Spelvin
2019-02-21 8:21 ` [PATCH v2 3/5] lib/sort: Avoid indirect calls to built-in swap George Spelvin
2019-03-05 3:06 ` [PATCH v2 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS George Spelvin
2019-03-05 5:58 ` [PATCH v2 5/5] lib/list_sort: Optimize number of calls to comparison function George Spelvin
2019-03-19 8:15 ` [RESEND PATCH v2 0/5] lib/sort & lib/list_sort: faster and smaller George Spelvin
2019-03-19 8:15 ` [RESEND PATCH v2 1/5] lib/sort: Make swap functions more generic George Spelvin
2019-03-19 8:15 ` [RESEND PATCH v2 2/5] lib/sort: Use more efficient bottom-up heapsort variant George Spelvin
2019-03-19 8:15 ` [RESEND PATCH v2 3/5] lib/sort: Avoid indirect calls to built-in swap George Spelvin
2019-03-19 8:16 ` [RESEND PATCH v2 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS George Spelvin
2019-03-28 22:08 ` Andrew Morton
2019-03-29 4:10 ` George Spelvin [this message]
2019-03-29 4:31 ` [PATCH 6/5] lib/list_sort: Fix GCC warning George Spelvin
2019-03-19 8:16 ` [RESEND PATCH v2 5/5] lib/list_sort: Optimize number of calls to comparison function George Spelvin
2019-03-19 10:56 ` [RESEND PATCH v2 0/5] lib/sort & lib/list_sort: faster and smaller Rasmus Villemoes
2019-03-19 14:01 ` Andy Shevchenko
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=201903290410.x2T4ACjG014546@sdf.org \
--to=lkml@sdf.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=daniel.wagner@siemens.com \
--cc=dchinner@redhat.com \
--cc=don.mullis@gmail.com \
--cc=geert@linux-m68k.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lkp@intel.com \
--cc=sfr@canb.auug.org.au \
--cc=st5pub@yandex.ru \
/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
Powered by JetHome