All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Winkler, Tomas" <tomas.winkler@intel.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Peter Huewe <peterhuewe@gmx.de>,
	Marcel Selhorst <tpmdd@selhorst.net>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	"tpmdd-devel@lists.sourceforge.net" 
	<tpmdd-devel@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tpm/tpm_crb: mark PM functions as __maybe_unused
Date: Tue, 21 Mar 2017 08:37:13 +0100	[thread overview]
Message-ID: <CAK8P3a1_0w7xOGXAczbYDE402GsnsbyRftsK3R0nuhCYiWT59g@mail.gmail.com> (raw)
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B543B0650@hasmsx108.ger.corp.intel.com>

On Tue, Mar 21, 2017 at 12:35 AM, Winkler, Tomas
<tomas.winkler@intel.com> wrote:
>
>>
>> On Mon, Mar 20, 2017 at 11:01:36PM +0000, Winkler, Tomas wrote:
>>
>> > I believe that in this case the #ifdefs can be done correctly quite
>> > easily, but now I'm not against your solution as well, just maybe put
>> > some of this info to the commit message.
>>
>> I perfer fewer ifdefs, it makes it more maintainable..
>
> Sure,
>>
>> The compiler will remove unused static functions.
>
> I'm not sure if this goes away w/o --gc-sections, but it might.
> Will check, didn't looked at that for a while.

gcc-4.1 had a bug where code it failed to eliminate a dead function
if it was referenced through a function pointer in another unused
static function, but it would work correctly in this case (obviously
unused code) and compiler that people actually use don't have
this problem. Note that the kernel depends on dead code elimination
to work correctly in a lot of places, it wouldn't build at all if that
was broken.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: "Winkler, Tomas" <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [PATCH] tpm/tpm_crb: mark PM functions as __maybe_unused
Date: Tue, 21 Mar 2017 08:37:13 +0100	[thread overview]
Message-ID: <CAK8P3a1_0w7xOGXAczbYDE402GsnsbyRftsK3R0nuhCYiWT59g@mail.gmail.com> (raw)
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B543B0650-Jy8z56yoSI8MvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>

On Tue, Mar 21, 2017 at 12:35 AM, Winkler, Tomas
<tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
>>
>> On Mon, Mar 20, 2017 at 11:01:36PM +0000, Winkler, Tomas wrote:
>>
>> > I believe that in this case the #ifdefs can be done correctly quite
>> > easily, but now I'm not against your solution as well, just maybe put
>> > some of this info to the commit message.
>>
>> I perfer fewer ifdefs, it makes it more maintainable..
>
> Sure,
>>
>> The compiler will remove unused static functions.
>
> I'm not sure if this goes away w/o --gc-sections, but it might.
> Will check, didn't looked at that for a while.

gcc-4.1 had a bug where code it failed to eliminate a dead function
if it was referenced through a function pointer in another unused
static function, but it would work correctly in this case (obviously
unused code) and compiler that people actually use don't have
this problem. Note that the kernel depends on dead code elimination
to work correctly in a lot of places, it wouldn't build at all if that
was broken.

      Arnd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  reply	other threads:[~2017-03-21  7:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20  9:17 [PATCH] tpm/tpm_crb: mark PM functions as __maybe_unused Arnd Bergmann
2017-03-20 12:11 ` Winkler, Tomas
2017-03-20 12:11   ` Winkler, Tomas
2017-03-20 12:27   ` Arnd Bergmann
2017-03-20 12:27     ` Arnd Bergmann
2017-03-20 23:01     ` Winkler, Tomas
2017-03-20 23:01       ` Winkler, Tomas
2017-03-20 23:04       ` Jason Gunthorpe
2017-03-20 23:04         ` Jason Gunthorpe
2017-03-20 23:35         ` Winkler, Tomas
2017-03-20 23:35           ` Winkler, Tomas
2017-03-21  7:37           ` Arnd Bergmann [this message]
2017-03-21  7:37             ` Arnd Bergmann
2017-03-22 10:21 ` Jarkko Sakkinen
2017-03-22 10:21   ` Jarkko Sakkinen

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=CAK8P3a1_0w7xOGXAczbYDE402GsnsbyRftsK3R0nuhCYiWT59g@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=jsnitsel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tomas.winkler@intel.com \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tpmdd@selhorst.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.