sizetype, bitsizetype and DECL_FIELD_BITPOS

[Richard Kenner]

    I read the comment that size_binop is supposed to convert the result
    to sizetype.

Hmm... well, that *will* work in all current usages, except that we don't
always pass both inputs of the same type, but I'm concerned about such
a specification since it means that somebody accidentally calling it
to add two bitsizetype values will have an unexpected truncation.

    If size_binop required all inputs and the output to be the same type,
    it should just get the result type from one of the arguments, and be
    called tree_binop or something similarily type-independent.

Well, yes, I quite understand that.  And that's part of the reason why I'm
getting increasingly dubious about this whole idea of having both sizetype and
bitsizetype: it makes the use of size_binop *very* tricky.  Indeed, size_int
has the same problem. We have a bitsize_int now, but it seems that, for
some reason, its parameters are different (and nearly always called wrong,
since "0L" is totally bogus).  Perhaps we need a bitsize_binop and then
an explicit conversion, but I'd still like to be convinced that all this
complexity is actually buying us something that justifies it.