Re: Appeasing gcc48 for mvme68k

[christos%astron.com@localhost (Christos Zoulas)]

In article <Pine.NEB.4.64.1403261153040.6293%david.technoskunk.fur@localhost>,
John D. Baker <jdbaker%mylinuxisp.com@localhost> 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