Georg-Johann Lay writes:
> On 28.10.2016 17:58, Mike Stump wrote:
>> 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
>
> Yes, you are right. Label differences could be implemented. AFAIK there is
> currently no activity by the Binutils folks to add respective support, so it
> is
> somewhat pointless to add that support to avr-gcc...
>
> Bottom line is that label offsets are not supported by avr BE, and the
> intention of the patch is to reduce FAIL noise in testsuite results because
> of
> the missing support.
>
> If a dg-require is not appropriate, should I rather add dg-skip-if to every
> test case? I'd still prefer the dg-require solution because if the Binutils
> will ever support label differences, then the testsuite will automatically
> catch up with that.
>
>> 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
>
> Only if the code is not executed; there are several test cases that compute
> relative placements of labels like:
>
> x(){if(&&e-&&b<0)x();b:goto*&&b;e:;}
>
> If a test ever relies on the fact that &&e - &&b tells anything about the
> ordering of the labels, the code is about to crash.
>
>> 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
>
> The following code simple makes absolutely no sense in the presence of stubs:
> int
> test (int foo)
> {
> static void *dummy[] = { &&a, &&b };
> goto *((char *) &&b - 2 * (foo < 0));
> a:
> b:
> return 0;
> }
>
> It's only a compile test (the original PR66123 is about ICE), but the
> compiler
> cannot know that it's just a crazy test case that won't be executed...
>
> When you are offsetting from a stub you might end up *anywhere*, even in some
> data range.
>
>> 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?
>
> State of matters is that Binutils support is missing, and if I understand you
> correctly, dg-require is not appropriate to factor out availability of such
> features?
I'll take a stab at adding the missing binutils support for avr label diffs.
Regards
Senthil
