Re: [patch,testsuite] Support dg-require-effective-target label_offsets.

[Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>]

Georg-Johann Lay writes:

> On 28.10.2016 17:58, Mike Stump wrote:
>> On Oct 27, 2016, at 3:16 AM, Georg-Johann Lay <avr@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