Re: dubious use of O_subtract in gas/config/tc-ia64.c

["Jan Beulich" <JBeulich at novell dot com>]

>> Could anyone shed some light on the relevance of the two instances
of
>> checks for O_subtract within operand_match(), cases
IA64_OPND_IMMU64,
>> IA64_OPND_IMM14, and IA64_OPND_IMM22?
>
>This code is present in the first check in, so it was probably needed
>for the linux kernel port.
>
>I see in your example that you are subtracting two symbols in
different
>sections, which isn't something that we can easily compute.

Even with the recent pcrel patch applied I still see problems with
this: The checks there prohibit more complex expressions than just a
simple subtract, e.g. (with symbol1 and symbol2 in the same section)

-(symbol1 - symbol2)
(symbol1 - symbol2) >> 4
(symbol1 - .) + (. - symbol2)

Of course, these examples may not look very meaningful by themselves,
but I think you get the point. Beyond that, pseudo opcodes like data4
and data8 deal with them without problem. It would seem to me (without
having it tried, yet) that maybe the original issue you saw when
removing these checks could be gone with the pcrel patch applied.

This isn't the end of problems, though: The way insn operands are
handled in general cause more problems when it comes to forward
references; the question here is perhaps also of more general (not just
IA64) nature: Shouldn't an operand that is supported by
.byte/.word/.long/.quad (and for IA64 their dataN equivalents) and that
would be valid as an insn operand also be accepted by that insn?

Jan