Lately NetBSD has gone over to use -Wall -Werror (a problem in itself,
when all warnings are not completely reliable).  However in one file,
nfs/nfs_socket.c, compiled with -O on a m68k architecture resulted in
an "uninitialized" warning that was *very* wrong.  I say *very*
because -Wuninitialized is known to be able to produce bogus warnings
when the logic is too hard for the dataflow mechanism of GCC to
follow.  However this case was a very simple one.  It boils down to:

typedef long long L;
typedef int S;

L
foo (S s)
{
  L l;

  l = (L)s * 2;
  return l;
}

This will trigger the warning on a m68k-unknown-netbsd config.  The
reason is that the setting of "l" will be done in a PARALLEL SET of
SUBREGs:

(insn 12 11 14 (parallel[ 
            (set (subreg:SI (reg/v:DI 29) 1)
                (mult:SI (reg/v:SI 28)
                    (reg:SI 30)))
            (set (subreg:SI (reg/v:DI 29) 0)
                (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg/v:SI 28))
                            (sign_extend:DI (reg:SI 30)))
                        (const_int 32))))
        ] ) 151 {mulsidi3+1} (insn_list 4 (insn_list 11 (nil)))
    (expr_list:REG_DEAD (reg/v:SI 28)
        (expr_list:REG_DEAD (reg:SI 30)
            (nil))))

The liveness calculating code ought to have marked reg 29 as dead
before this insn, but fails to do so because settings of subregs is
effectively a use of the destination too if the size of the subreg is
smaller than the reg.  In this case however the parallel set
effectively is a set of the *whole* reg, but mark_used_regs doesn't
check for that condition.

This ought not only to be a problem with the uninitialized warning,
register allocation will suffer as well I guess, no?

Do we have some function in gcc to see if a set of SUBREGs rtxs fully
specifies the REG they're derived from?

Niklas

PS. A nice proposal of making -Werror configurable per-warning-type
    was presented on a NetBSD list:  sth like -Werror -Wnoerror-uninitalized  
    could be devised to keep the uninitalized warning but not let it
    be a fatal error, while all others can.  Maybe this is something
    for GCC?

Niklas Hallqvist       Phone: +46-(0)31-40 75 00  Home: +46-(0)31-41 93 95
Applitron Datasystem   Fax:   +46-(0)31-83 39 50  Home: +46-(0)31-41 93 96
Molndalsvagen 95       Email: niklas@appli.se     GSM:  +46-(0)70-714 10 35
S-412 63  GOTEBORG     WWW:   Here
Sweden		       IRC:   niklas (#NetBSD)