[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17265E10@AcuExch.aculab.com>
Date: Wed, 25 Jun 2014 16:04:43 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Uwe Kleine-König'
<u.kleine-koenig@...gutronix.de>
CC: 'Guenter Roeck' <linux@...ck-us.net>,
Russell King <linux@....linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Dietmar Eggemann" <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>,
"Paul Mackerras" <paulus@...ba.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Ingo Molnar <mingo@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v2] sched: Fix compiler warnings
From: Uwe Kleine-König
> Hello,
>
> On Wed, Jun 25, 2014 at 03:40:28PM +0000, David Laight wrote:
> > From: Guenter Roeck
> > > Actually turns out one can use __attribute_const__, and it is
> > >
> > > static inline int __attribute_const__ cpu_corepower_flags(void)
> > >
> > > which turns out to be widely used.
> > >
> > > I'll change that and resubmit after testing.
> >
> > You don't need to tell the compiler that for an inline function.
> I didn't check for the functions in question here, but in general your
> statement is wrong.
>
> For example:
>
> static inline unsigned int __attribute_const__ read_cpuid_id(void)
> {
> return readl(BASEADDR_V7M_SCB + V7M_SCB_CPUID);
> }
>
> from arch/arm/include/asm/cputype.h. The V7M_SCB_CPUID register never
> changes, but there is no way gcc can deduce that.
Hmm... it all rather depends on the order of the optimisations and
inlining.
I've tried to use 'restrict' on the parameters to an inline function
in an attempt to get 'noalias' - but the reverse inference never
seems to be applied.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists