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?
Johann
