Re: Appeasing gcc48 for mvme68k

In article <[email protected]>,
John D. Baker <[email protected]> wrote:
>A couple of unused variable fixes relevant to mvmeXXX(X) were committed
>recently.  A couple more are needed for mvme68k:
>
>
>+Index: sys/arch/mvme68k/stand/bootst/dev_tape.c
>+===================================================================
>+RCS file: /cvsroot/src/sys/arch/mvme68k/stand/bootst/dev_tape.c,v
>+retrieving revision 1.12
>+diff -u -b -r1.12 dev_tape.c
>+--- sys/arch/mvme68k/stand/bootst/dev_tape.c	17 Jul 2011 20:54:44 -0000	1.12
>++++ sys/arch/mvme68k/stand/bootst/dev_tape.c	13 Mar 2014 23:16:37 -0000
>+@@ -114,7 +114,7 @@
>+ int
>+ tape_close(struct open_file *f)
>+ {
>+-	struct mvmeprom_dskio *ti;
>++	struct mvmeprom_dskio *ti __unused;
>+ 
>+ 	ti = f->f_devdata;
>+ 	f->f_devdata = NULL;
>
>I didn't analyse it further, but unless the assignment above is a
>register access, "ti" could be eliminated entirely.

I think looks like this can be removed, but verify.

>The variable "shstrsz" appears in a DEALLOC() macro later in the function
>so I don't know why gcc48 complains--unless the macro collapses the
>corresponding parameter (or entirely) for certain architectures or
>applications.

perhaps __USE(shstrsz) in DEALLOC()?

christos