On 8/19/19 8:23 AM, Jose E. Marchesi wrote:
>
> [...]
> > * gcc.dg/Wframe-larger-than-2.c: Likewise.
> > * gcc.dg/Wframe-larger-than.c: Likewise.
> > * gcc.dg/Wrestrict-11.c: Likewise.
> So I think we probably want an effective target check for indirect calls
> rather than checking explicitly for ebpf in all these files.
>
> Ok, will introduce it.
>
> It also seems like rather than checking for ebpf on files with large
> stacks, we should be using the generic mechanisms to defined the allowed
> size of the stack (mentioned in prior review) & mark test which use too
> much space. This would almost certainly help other embedded targets as
> well.
>
> I first thought about doing that, but hesitated when I realized it would
> require to alter existing tests in no trivial ways: will the test still
> effectively test whatever it is supposed to test, after the size of an
> array is changed, for example?
I think you just add something like
/* dg-require-stack-size "<size>" */
Assuming that's right you don't have to worry about changing the test
itself and potentially changing its meaning.
I wouldn't necessarily try to figure the exact size needed by each test.
A reasonable guesstimation ought to be sufficient.
>
> Not sure the best way to deal with too many arguments. I suspect we
> want an efffective target check for that. Keeping this up-to-date will
> be painful as people write more tests.
>
> Yeah, that won't be fun :(
>
> /* Copyright (C) 2000, 2003 Free Software Foundation */
> > __complex__ long long f ()
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
> > b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
> > index be0bdcf7631..9f6bd0af2e5 100644
> > --- a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
> > +++ b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
> > @@ -3,6 +3,7 @@
> > /* { dg-skip-if "too much code for pdp11" { "pdp11-*-*" } } */
> > /* { dg-xfail-if "PR36698" { spu-*-* } { "-O0" } { "" } } */
> > /* { dg-skip-if "" { m32c-*-* } } */
> > +/* { dg-skip-if "jumps too far for eBPF" { bpf-*-* } } */
> > /* { dg-timeout-factor 4.0 } */
> Jumps too far is probably an indication you need to fix something in
> your port. Though I guess its OK if you're never going to support far
> away targets.
>
> The reasons for this are that eBPF doesn't have indirect jump
> instructions, and the direct jump instruction's displacement is a signed
> PC-relative 16-bit offset, in 64-bit word units.
>
> So, unless the compiler gets able to generate a "chain" of direct jumps
> to reach the destination (that would be a fun hack :D) the range for
> branches is severely limited.
OK. Perhaps another effective target check. Or leave this one with
the epf check.
jeff
