On Oct 27, 2016, at 3:16 AM, Georg-Johann Lay <a...@gjlay.de> wrote: > > Now imagine some arithmetic like &&LAB2 - &&LAB1. This might result in one > or two stub addresses, and difference between such addresses is a complete > different thing than the difference between the original labels: The result > might differ in absolute value and in sign, i.e. you can't even determine > whether LAB1 or LAB2 comes first in the generated code as the order of stubs > might differ from the order of respective labels.
So, I think this all doesn't matter any. Every address gs(LAB) fits in 16-bits by definition, and every gs(LAB1) - gs(LAB2) fits into 16 bits and thus is valid for all 16-bit one contexts. The fact the order between the stub and the actual code is different is irrelevant, it is a private implementation detail of the port, the point is the semantics are fixed and constant and useful. In deed that there is even a stub is a private implementation detail of the port. I think the `extra' helpful warning from avr_print_operand_address is wrong and should be removed. Think of the label as gs(LAB), not LAB, burn LAB from your mind. Once you do that, you see you can't talk about the order LAB1 > LAB2, the concept doesn't make any sense. The _only_ think you can talk about is gs(LAB1) > gs(LAB2). And because of that, it is always consistent and works just fine. Once that misguided complains from gcc and bisutils are fixed, are their any failing cases?
