Hi, I am the fml ML manager for the ML <debian-users <at> debian.or.jp>. --debian-users <at> debian.or.jp, Be Seeing You! ************************************************************ If you have any questions or problems, please contact debian-users-admin <at> debian.or.jp ************************************************************
"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 <bunk <at> stusta.de> Acked-by: Kyle McMartin <kyle <at> parisc-linux.org> --- 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(-) --- linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c.old 2005-10-30 01:58:43.000000000 +0200 +++ linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c 2005-10-30 01:59:11.000000000 +0200 <at> <at> -158,12 +158,12 <at> <at> #define stw(_s,_t,_o,_a,_e) def_store_insn(stw,"r",_s,_t,_o,_a,_e)(Continue reading)
This patch removes the usage of GCC_VERSION from arch/parisc/Makefile. There are no functional changes, it simply makes it a bit shorter (and removes the last instance of GCC_VERSION in the kernel). Signed-off-by: Adrian Bunk <bunk <at> stusta.de> Acked-by: Kyle McMartin <kyle <at> mcmartin.ca> --- This patch was already sent on: - 21 Nov 2006 - 19 Aug 2006 - 12 Jan 2006 --- linux-2.6.15-mm3-hppa/arch/parisc/Makefile.old 2006-01-12 03:11:45.000000000 +0100 +++ linux-2.6.15-mm3-hppa/arch/parisc/Makefile 2006-01-12 03:12:35.000000000 +0100 <at> <at> -35,12 +35,8 <at> <at> OBJCOPY_FLAGS =-O binary -R .note -R .comment -S -GCC_VERSION := $(call cc-version) -ifneq ($(shell if [ -z $(GCC_VERSION) ] ; then echo "bad"; fi ;),) -$(error Sorry, couldn't find ($(cc-version)).) -endif -ifneq ($(shell if [ $(GCC_VERSION) -lt 0303 ] ; then echo "bad"; fi ;),) -$(error Sorry, your compiler is too old ($(GCC_VERSION)). GCC v3.3 or above is required.) +ifneq ($(shell if [ $(call cc-version) -lt 0303 ] ; then echo "bad"; fi ;),) +$(error Sorry, your compiler is too old. GCC v3.3 or above is required.) endif(Continue reading)
Guy Martin wrote: > Hi James, > > This is working fine ! Thanks a lot ! > > I was able to mount a cd without any pb. > > Cheers, > Guy > > On Thu, 30 Nov 2006 13:13:46 -0500 > James Bottomley <James.Bottomley <at> SteelEye.com> wrote: > >> On Thu, 2006-11-30 at 12:17 -0500, James Bottomley wrote: >>> And here we get a phase mismatch in the command phase because the drive >>> transitions to data phase after six bytes and the driver still thinks it >>> has another four to send. >>> >>> I'd have the maintainer shot ... he clearly forgot to set up the command >>> length for auto request sense. >> Try this and see if it fixes the problem >> >> James > Sorry no yet a fix for my pb :_( scsi1: (3:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN scsi1: Bus Reset detected, executing command 15db93c0, slot 2ff48520, dsp 001c81e8[01e8] failing command because of reset, slot 2ff48520, cmnd 15db93c0 failing command because of reset, slot 2ff4864c, cmnd 2feb03c0(Continue reading)
On Fri, Dec 01, 2006 at 03:58:00PM +0000, Joel Soete wrote: > Sorry no yet a fix for my pb :_( It'd be useful to know if your problem was introduced at the same time. Can you try the same git revisions that Guy tried and let us know if that's the same commit that broke your machine?
On Fri, Dec 01, 2006 at 12:48:11PM +0100, Adrian Bunk wrote:
> "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.
> 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
On Fri, Dec 01, 2006 at 09:43:54AM -0700, Grant Grundler wrote: > On Fri, Dec 01, 2006 at 12:48:11PM +0100, Adrian Bunk wrote: > > "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. 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. > > If there are places that really need a forced inline, __always_inline > > would be the correct solution.(Continue reading)
On Fri, Dec 01, 2006 at 05:54:27PM +0100, Adrian Bunk wrote: > 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. > 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. ... > 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(Continue reading)
> 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 -- -- J. David Anglin dave.anglin <at> nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
RSS Feed10 | |
|---|---|
1 | |
11 | |
11 | |
62 | |
52 | |
56 | |
91 | |
133 | |
151 | |
52 | |
43 | |
225 | |
124 | |
138 | |
15 | |
28 | |
8 | |
15 | |
7 | |
32 | |
63 | |
24 | |
42 | |
229 | |
48 | |
10 | |
57 | |
16 | |
32 | |
42 | |
58 | |
3 | |
3 | |
28 | |
28 | |
2 |
