parisc: "extern inline" -> "static inline" (fwd)

PATCH In review Adrian Bunk 3 participants 9 messages Dec 1, 2006 PA-RISC architecture

Share & tools

Adrian Bunk

author

2006-12-01 11:48 UTC #0 lore raw

PATCH 1/1 parisc: "extern inline" -> "static inline" (fwd)

"extern inline" generates a warning with -Wmissing-prototypes and I'm currently working on getting the kernel cleaned up for adding this to the CFLAGS since it will help us to avoid a nasty class of runtime errors.

If there are places that really need a forced inline, __always_inline would be the correct solution.

Signed-off-by Adrian Bunk <[email protected]>

Acked-by Kyle McMartin <[email protected]>

---

This patch was already sent on:
- 21 Nov 2006
- 19 Aug 2006

 arch/parisc/lib/memcpy.c       |    4 +--
 include/asm-parisc/io.h        |    2 -
 include/asm-parisc/pci.h       |    2 -
 include/asm-parisc/pgtable.h   |   40 ++++++++++++++++-----------------
 include/asm-parisc/prefetch.h  |    4 +--
 include/asm-parisc/semaphore.h |   10 ++++----
 include/asm-parisc/tlbflush.h  |    3 --
 7 files changed, 32 insertions(+), 33 deletions(-)

arch/parisc/lib/memcpy.c renamed from arch/parisc/lib/memcpy.c.old +2 -2

@@ -158,12 +158,12 @@
 #define stw(_s,_t,_o,_a,_e) 	def_store_insn(stw,"r",_s,_t,_o,_a,_e)
 
 #ifdef  CONFIG_PREFETCH
-extern inline void prefetch_src(const void *addr)
+static inline void prefetch_src(const void *addr)
 {
 	__asm__("ldw 0(" s_space ",%0), %%r0" : : "r" (addr));
 }
 
-extern inline void prefetch_dst(const void *addr)
+static inline void prefetch_dst(const void *addr)
 {
 	__asm__("ldd 0(" d_space ",%0), %%r0" : : "r" (addr));
 }

include/asm-parisc/pci.h renamed from include/asm-parisc/pci.h.old +1 -1

@@ -193,7 +193,7 @@
 extern void pcibios_register_hba(struct pci_hba_data *);
 extern void pcibios_set_master(struct pci_dev *);
 #else
-extern inline void pcibios_register_hba(struct pci_hba_data *x)
+static inline void pcibios_register_hba(struct pci_hba_data *x)
 {
 }
 #endif

include/asm-parisc/pgtable.h renamed from include/asm-parisc/pgtable.h.old +20 ~~-20~~

@@ -316,31 +316,31 @@
  * setup: the pgd is never bad, and a pmd always exists (as it's folded
  * into the pgd entry)
  */
-extern inline int pgd_none(pgd_t pgd)		{ return 0; }
-extern inline int pgd_bad(pgd_t pgd)		{ return 0; }
-extern inline int pgd_present(pgd_t pgd)	{ return 1; }
-extern inline void pgd_clear(pgd_t * pgdp)	{ }
+static inline int pgd_none(pgd_t pgd)		{ return 0; }
+static inline int pgd_bad(pgd_t pgd)		{ return 0; }
+static inline int pgd_present(pgd_t pgd)	{ return 1; }
+static inline void pgd_clear(pgd_t * pgdp)	{ }
 #endif
 
 /*
  * The following only work if pte_present() is true.
  * Undefined behaviour if not..
  */
-extern inline int pte_read(pte_t pte)		{ return pte_val(pte) & _PAGE_READ; }
-extern inline int pte_dirty(pte_t pte)		{ return pte_val(pte) & _PAGE_DIRTY; }
-extern inline int pte_young(pte_t pte)		{ return pte_val(pte) & _PAGE_ACCESSED; }
-extern inline int pte_write(pte_t pte)		{ return pte_val(pte) & _PAGE_WRITE; }
-extern inline int pte_file(pte_t pte)		{ return pte_val(pte) & _PAGE_FILE; }
-extern inline int pte_user(pte_t pte) 		{ return pte_val(pte) & _PAGE_USER; }
-
-extern inline pte_t pte_rdprotect(pte_t pte)	{ pte_val(pte) &= ~_PAGE_READ; return pte; }
-extern inline pte_t pte_mkclean(pte_t pte)	{ pte_val(pte) &= ~_PAGE_DIRTY; return pte; }
-extern inline pte_t pte_mkold(pte_t pte)	{ pte_val(pte) &= ~_PAGE_ACCESSED; return pte; }
-extern inline pte_t pte_wrprotect(pte_t pte)	{ pte_val(pte) &= ~_PAGE_WRITE; return pte; }
-extern inline pte_t pte_mkread(pte_t pte)	{ pte_val(pte) |= _PAGE_READ; return pte; }
-extern inline pte_t pte_mkdirty(pte_t pte)	{ pte_val(pte) |= _PAGE_DIRTY; return pte; }
-extern inline pte_t pte_mkyoung(pte_t pte)	{ pte_val(pte) |= _PAGE_ACCESSED; return pte; }
-extern inline pte_t pte_mkwrite(pte_t pte)	{ pte_val(pte) |= _PAGE_WRITE; return pte; }
+static inline int pte_read(pte_t pte)		{ return pte_val(pte) & _PAGE_READ; }
+static inline int pte_dirty(pte_t pte)		{ return pte_val(pte) & _PAGE_DIRTY; }
+static inline int pte_young(pte_t pte)		{ return pte_val(pte) & _PAGE_ACCESSED; }
+static inline int pte_write(pte_t pte)		{ return pte_val(pte) & _PAGE_WRITE; }
+static inline int pte_file(pte_t pte)		{ return pte_val(pte) & _PAGE_FILE; }
+static inline int pte_user(pte_t pte) 		{ return pte_val(pte) & _PAGE_USER; }
+
+static inline pte_t pte_rdprotect(pte_t pte)	{ pte_val(pte) &= ~_PAGE_READ; return pte; }
+static inline pte_t pte_mkclean(pte_t pte)	{ pte_val(pte) &= ~_PAGE_DIRTY; return pte; }
+static inline pte_t pte_mkold(pte_t pte)	{ pte_val(pte) &= ~_PAGE_ACCESSED; return pte; }
+static inline pte_t pte_wrprotect(pte_t pte)	{ pte_val(pte) &= ~_PAGE_WRITE; return pte; }
+static inline pte_t pte_mkread(pte_t pte)	{ pte_val(pte) |= _PAGE_READ; return pte; }
+static inline pte_t pte_mkdirty(pte_t pte)	{ pte_val(pte) |= _PAGE_DIRTY; return pte; }
+static inline pte_t pte_mkyoung(pte_t pte)	{ pte_val(pte) |= _PAGE_ACCESSED; return pte; }
+static inline pte_t pte_mkwrite(pte_t pte)	{ pte_val(pte) |= _PAGE_WRITE; return pte; }
 
 /*
  * Conversion functions: convert a page and protection to a page entry,

@@ -368,7 +368,7 @@
 #define mk_pte_phys(physpage, pgprot) \
 ({ pte_t __pte; pte_val(__pte) = physpage + pgprot_val(pgprot); __pte; })
 
-extern inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
+static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
 { pte_val(pte) = (pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot); return pte; }
 
 /* Permanent address of a page.  On parisc we don't have highmem. */

include/asm-parisc/semaphore.h renamed from include/asm-parisc/semaphore.h.old +5 -5

@@ -58,7 +58,7 @@
 #define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1)
 #define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0)
 
-extern inline void sema_init (struct semaphore *sem, int val)
+static inline void sema_init (struct semaphore *sem, int val)
 {
 	*sem = (struct semaphore)__SEMAPHORE_INITIALIZER((*sem),val);
 }

@@ -86,7 +86,7 @@
  * interrupts while we're messing with the semaphore.  Sorry.
  */
 
-extern __inline__ void down(struct semaphore * sem)
+static inline void down(struct semaphore * sem)
 {
 	might_sleep();
 	spin_lock_irq(&sem->sentry);

@@ -98,7 +98,7 @@
 	spin_unlock_irq(&sem->sentry);
 }
 
-extern __inline__ int down_interruptible(struct semaphore * sem)
+static inline int down_interruptible(struct semaphore * sem)
 {
 	int ret = 0;
 	might_sleep();

@@ -116,7 +116,7 @@
  * down_trylock returns 0 on success, 1 if we failed to get the lock.
  * May not sleep, but must preserve irq state
  */
-extern __inline__ int down_trylock(struct semaphore * sem)
+static inline int down_trylock(struct semaphore * sem)
 {
 	int flags, count;

@@ -132,7 +132,7 @@
  * Note! This is subtle. We jump to wake people up only if
  * the semaphore was negative (== somebody was waiting on it).
  */
-extern __inline__ void up(struct semaphore * sem)
+static inline void up(struct semaphore * sem)
 {
 	int flags;
 	spin_lock_irqsave(&sem->sentry, flags);

include/asm-parisc/tlbflush.h renamed from include/asm-parisc/tlbflush.h.old +1 -1

@@ -42,7 +42,7 @@
 #endif
 }
 
-extern __inline__ void flush_tlb_pgtables(struct mm_struct *mm, unsigned long start, unsigned long end)
+static inline void flush_tlb_pgtables(struct mm_struct *mm, unsigned long start, unsigned long end)
 {
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

include/asm-parisc/io.h renamed from include/asm-parisc/io.h.old +1 -1

@@ -128,7 +128,7 @@
 /* Most machines react poorly to I/O-space being cacheable... Instead let's
  * define ioremap() in terms of ioremap_nocache().
  */
-extern inline void __iomem * ioremap(unsigned long offset, unsigned long size)
+static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
 {
 	return __ioremap(offset, size, _PAGE_NO_CACHE);
 }

include/asm-parisc/prefetch.h renamed from include/asm-parisc/prefetch.h.old +2 -2

@@ -19,7 +19,7 @@
 #ifdef CONFIG_PREFETCH
 
 #define ARCH_HAS_PREFETCH
-extern inline void prefetch(const void *addr)
+static inline void prefetch(const void *addr)
 {
 	__asm__("ldw 0(%0), %%r0" : : "r" (addr));
 }

@@ -27,7 +27,7 @@
 /* LDD is a PA2.0 addition. */
 #ifdef CONFIG_PA20
 #define ARCH_HAS_PREFETCHW
-extern inline void prefetchw(const void *addr)
+static inline void prefetchw(const void *addr)
 {
 	__asm__("ldd 0(%0), %%r0" : : "r" (addr));
 }

Grant Grundler

2006-12-01 16:43 UTC #1 lore raw

Quoted 4 lines · Adrian Bunk

"extern inline" generates a warning with -Wmissing-prototypes and I'm currently working on getting the kernel cleaned up for adding this to the CFLAGS since it will help us to avoid a nasty class of runtime errors.

John David Anglin is the hppa/parisc gcc maintainer and has commented on inline variants last year:

    http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html

This makes me think -Wmissing-prototypes is reporting the wrong warning. ie there is a prototype but no function and no label.
Can you check with gcc folks to see if this is a gcc bug?

The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

Quoted 2 lines

If there are places that really need a forced inline, __always_inline would be the correct solution.

Yes, all the functions marked "extern inline" are expected to get essentially the same treatment as "always_inline".

thanks,
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Grant Grundler

2006-12-01 16:43 UTC #2 lore raw

In reply to Adrian Bunk

Quoted 4 lines · Adrian Bunk

"extern inline" generates a warning with -Wmissing-prototypes and I'm currently working on getting the kernel cleaned up for adding this to the CFLAGS since it will help us to avoid a nasty class of runtime errors.

John David Anglin is the hppa/parisc gcc maintainer and has commented on inline variants last year:

    http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html

This makes me think -Wmissing-prototypes is reporting the wrong warning. ie there is a prototype but no function and no label.
Can you check with gcc folks to see if this is a gcc bug?

The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

Quoted 2 lines

If there are places that really need a forced inline, __always_inline would be the correct solution.

Yes, all the functions marked "extern inline" are expected to get essentially the same treatment as "always_inline".

thanks,
grant

Adrian Bunk

author

2006-12-01 16:54 UTC #3 lore raw

Quoted 11 lines · Grant Grundler

Quoted 4 lines · Adrian Bunk
"extern inline" generates a warning with -Wmissing-prototypes and I'm currently working on getting the kernel cleaned up for adding this to the CFLAGS since it will help us to avoid a nasty class of runtime errors.
John David Anglin is the hppa/parisc gcc maintainer and has commented on inline variants last year:
    http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html

Quoted 7 lines

This makes me think -Wmissing-prototypes is reporting the wrong warning. ie there is a prototype but no function and no label.
Can you check with gcc folks to see if this is a gcc bug?
The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

If you read John David Anglin's email, you'll note that if you take the address you need this function provided somewhere.

Which of the functions my patch changes also have a global function provided within the kernel?

If none, "extern inline" didn't make any sense.

Quoted 5 lines

Quoted 2 lines
If there are places that really need a forced inline, __always_inline would be the correct solution.
Yes, all the functions marked "extern inline" are expected to get essentially the same treatment as "always_inline".

Currently, "inline" is defined to be always_inline, and __always_inline is for cases that produce non-compiling or non-working (opposed to only suboptimal) code.

Quoted 2 lines

thanks,
grant

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Grant Grundler

2006-12-01 17:36 UTC #4 lore raw

Quoted 2 lines · Adrian Bunk

If you read John David Anglin's email, you'll note that if you take the address you need this function provided somewhere.

Let me turn that around.
Which of the "extern inline" functions are we taking the address? The parisc kernel wouldn't (shouldn't) link if that were true.

Quoted 4 lines

Which of the functions my patch changes also have a global function provided within the kernel?
If none, "extern inline" didn't make any sense.

I expect none.

...

Quoted 3 lines

Currently, "inline" is defined to be always_inline, and __always_inline is for cases that produce non-compiling or non-working (opposed to only suboptimal) code.

Ok. Sounds like "extern inline" is the same as __always_inline.

Has gcc community confirmed "gcc -Wmissing-prototypes" behavior is really correct with respect to "extern inline"?

If so, I'm ok with changing "extern inline" to __always_inline.

thanks,
grant
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Grant Grundler

2006-12-01 17:36 UTC #5 lore raw

In reply to Adrian Bunk

Quoted 2 lines · Adrian Bunk

If you read John David Anglin's email, you'll note that if you take the address you need this function provided somewhere.

Let me turn that around.
Which of the "extern inline" functions are we taking the address? The parisc kernel wouldn't (shouldn't) link if that were true.

Quoted 4 lines

Which of the functions my patch changes also have a global function provided within the kernel?
If none, "extern inline" didn't make any sense.

I expect none.

...

Quoted 3 lines

Currently, "inline" is defined to be always_inline, and __always_inline is for cases that produce non-compiling or non-working (opposed to only suboptimal) code.

Ok. Sounds like "extern inline" is the same as __always_inline.

Has gcc community confirmed "gcc -Wmissing-prototypes" behavior is really correct with respect to "extern inline"?

If so, I'm ok with changing "extern inline" to __always_inline.

thanks,
grant

Adrian Bunk

author

2006-12-01 16:54 UTC #6 lore raw

In reply to Grant Grundler

Quoted 11 lines · Grant Grundler

Quoted 4 lines · Adrian Bunk
"extern inline" generates a warning with -Wmissing-prototypes and I'm currently working on getting the kernel cleaned up for adding this to the CFLAGS since it will help us to avoid a nasty class of runtime errors.
John David Anglin is the hppa/parisc gcc maintainer and has commented on inline variants last year:
    http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html

Quoted 7 lines

This makes me think -Wmissing-prototypes is reporting the wrong warning. ie there is a prototype but no function and no label.
Can you check with gcc folks to see if this is a gcc bug?
The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

If you read John David Anglin's email, you'll note that if you take the address you need this function provided somewhere.

Which of the functions my patch changes also have a global function provided within the kernel?

If none, "extern inline" didn't make any sense.

Quoted 5 lines

Quoted 2 lines
If there are places that really need a forced inline, __always_inline would be the correct solution.
Yes, all the functions marked "extern inline" are expected to get essentially the same treatment as "always_inline".

Currently, "inline" is defined to be always_inline, and __always_inline is for cases that produce non-compiling or non-working (opposed to only suboptimal) code.

Quoted 2 lines

thanks,
grant

cu
Adrian

Signature · 9 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

John David Anglin

2006-12-01 17:38 UTC #7 lore raw

Re: [parisc-linux] Re: [2.6 patch] parisc: "extern inline" -> "static

In reply to Grant Grundler

Quoted 3 lines

The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

The handling of "extern inline" is changing in GCC 4.3 to the C99 specified behavior. The attribute gnu_inline on an inline declaration results in the old GNU C89 inline behavior even in the ISO C99 mode.

The C99 behavior allows the function being inlined to be externally called. As a result, conflicts will occur if the function is defined in a header included by multiple objects. So, code that assumed the previous GNU treatment unfortunately needs to change.

The main difference between "static inline" and "extern inline" in the old GNU treatment was that with "extern inline" the function was never compiled on its own, even if its address was explicitly referenced. With "static inline", the function would be compiled on its own in some circumstances. So, this is mostly a code size issue.

More details are present in extend.texi in the GCC head. This has also been discussed on the gcc list a few times.

Dave

Signature · 6 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

John David Anglin

2006-12-01 17:39 UTC #8 lore raw

Re: [parisc-linux] Re: [2.6 patch] parisc: "extern inline" -> "static

In reply to Grant Grundler

Quoted 3 lines

The parisc point intentionally switched to "extern inline" at one point and unless what jda wrote is now incorrect, I'm not inclined to change it.

More details are present in extend.texi in the GCC head. This has also been discussed on the gcc list a few times.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)