Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
On Sep 11, 2019, at 1:47 PM, Jose E. Marchesi wrote: > > I am working on a new compilation mode for what I call xbpf, which is > basically eBPF plus extensions to eliminate the current restrictions to > C. The purpose of -mxbpf is mainly to test the compiler. Once the > support is in, I will revert this and similar other patches. Yeah, not a bad way to do it. I have a machine with limits on certain memories in hardware that trip up gcc's testsuite, and in my simulator, I have a special gcc testing mode that simply gives me a ton more memory (17 MB) that on real hardware, I don't have. This let's me easily test under simulation without worrying about the limits. I can also have my simulator select the small mode to reflect what hardware does, and everything else uses this. Best of both world.
Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
Hi Mike. Thanks for the review. On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch adds a new dg_require_effective_target procedure to the > testsuite infrastructure: indirect_calls. This new function tells > whether a target supports calls to non-constant call targets. Ok. I'll let people contemplate some comments... I'm torn between targets that can't support C and gooping up the test suite and approving. I'll error on the side of approving this, but, would like to hear from folks if I go to far. Since they are easy to identify, maintain and ignore... I went with approval. People can contemplate other ways to do this, like introduce a fake marker for when the feature is used and when running a program with such a marker, then mark it as unsupported. This way, no test need be marked, and all future test cases that use the feature, just flip to unsupported, no maintenance required. We do this sort of thing with programs that overflow the RAM, by using a stylized error message from ld, and noticing that in dejagnu, and then not expecting it to work. If you can find a way to tally stack space, and check it before running it, the other change to tightly track stack space then would not be as necessary. I think you might be able to do this on your target. Having the stack space marked is generally useful for other targets, as most won't have a nice way to sort out small stacks, so my general comment apply less to the stack size, but, things that can cause you less maintenance burden are likely good in any event. I am working on a new compilation mode for what I call xbpf, which is basically eBPF plus extensions to eliminate the current restrictions to C. The purpose of -mxbpf is mainly to test the compiler. Once the support is in, I will revert this and similar other patches. J.
Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch adds a new dg_require_effective_target procedure to the > testsuite infrastructure: indirect_calls. This new function tells > whether a target supports calls to non-constant call targets. Ok. I'll let people contemplate some comments... I'm torn between targets that can't support C and gooping up the test suite and approving. I'll error on the side of approving this, but, would like to hear from folks if I go to far. Since they are easy to identify, maintain and ignore... I went with approval. People can contemplate other ways to do this, like introduce a fake marker for when the feature is used and when running a program with such a marker, then mark it as unsupported. This way, no test need be marked, and all future test cases that use the feature, just flip to unsupported, no maintenance required. We do this sort of thing with programs that overflow the RAM, by using a stylized error message from ld, and noticing that in dejagnu, and then not expecting it to work. If you can find a way to tally stack space, and check it before running it, the other change to tightly track stack space then would not be as necessary. I think you might be able to do this on your target. Having the stack space marked is generally useful for other targets, as most won't have a nice way to sort out small stacks, so my general comment apply less to the stack size, but, things that can cause you less maintenance burden are likely good in any event.
Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
This patch adds a new dg_require_effective_target procedure to the testsuite infrastructure: indirect_calls. This new function tells whether a target supports calls to non-constant call targets. This patch also annotates the tests in the gcc.c-torture testuite that require support for indirect calls. As this implements a solution proposed by a global maintainer and I didn't get any further comments on it, I just installed it in its own commit in svn trunk. Salud!
[PATCH V6 04/11] testsuite: new require effective target indirect_calls
This patch adds a new dg_require_effective_target procedure to the testsuite infrastructure: indirect_calls. This new function tells whether a target supports calls to non-constant call targets. This patch also annotates the tests in the gcc.c-torture testuite that require support for indirect calls. gcc/ChangeLog: * doc/sourcebuild.texi (Effective-Target Keywords): Document indirect_calls. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_indirect_calls): New proc. * gcc.c-torture/compile/20010102-1.c: Annotate with dg-require-effective-target indirect_calls. * gcc.c-torture/compile/20010107-1.c: Likewise. * gcc.c-torture/compile/20011109-1.c: Likewise. * gcc.c-torture/compile/20011218-1.c: Likewise. * gcc.c-torture/compile/20011229-1.c: Likewise. * gcc.c-torture/compile/20020129-1.c: Likewise. * gcc.c-torture/compile/20020320-1.c: Likewise. * gcc.c-torture/compile/20020706-1.c: Likewise. * gcc.c-torture/compile/20020706-2.c: Likewise. * gcc.c-torture/compile/20021205-1.c: Likewise. * gcc.c-torture/compile/20030921-1.c: Likewise. * gcc.c-torture/compile/20031023-1.c: Likewise. * gcc.c-torture/compile/20031023-2.c: Likewise. * gcc.c-torture/compile/20031023-3.c: Likewise. * gcc.c-torture/compile/20031023-4.c: Likewise. * gcc.c-torture/compile/20040614-1.c: Likewise. * gcc.c-torture/compile/20040909-1.c: Likewise. * gcc.c-torture/compile/20050122-1.c: Likewise. * gcc.c-torture/compile/20050202-1.c: Likewise. * gcc.c-torture/compile/20060208-1.c: Likewise. * gcc.c-torture/compile/20081108-1.c: Likewise. * gcc.c-torture/compile/20150327.c: Likewise. * gcc.c-torture/compile/920428-2.c: Likewise. * gcc.c-torture/compile/920928-5.c: Likewise. * gcc.c-torture/compile/930117-1.c: Likewise. * gcc.c-torture/compile/930607-1.c: Likewise. * gcc.c-torture/compile/991213-2.c: Likewise. * gcc.c-torture/compile/callind.c: Likewise. * gcc.c-torture/compile/calls-void.c: Likewise. * gcc.c-torture/compile/calls.c: Likewise. * gcc.c-torture/compile/pr21840.c: Likewise. * gcc.c-torture/compile/pr32139.c: Likewise. * gcc.c-torture/compile/pr35607.c: Likewise. * gcc.c-torture/compile/pr37433-1.c: Likewise. * gcc.c-torture/compile/pr37433.c: Likewise. * gcc.c-torture/compile/pr39941.c: Likewise. * gcc.c-torture/compile/pr40080.c: Likewise. * gcc.c-torture/compile/pr43635.c: Likewise. * gcc.c-torture/compile/pr43791.c: Likewise. * gcc.c-torture/compile/pr43845.c: Likewise. * gcc.c-torture/compile/pr44043.c: Likewise. * gcc.c-torture/compile/pr51694.c: Likewise. * gcc.c-torture/compile/pr77754-2.c: Likewise. * gcc.c-torture/compile/pr77754-3.c: Likewise. * gcc.c-torture/compile/pr77754-4.c: Likewise. * gcc.c-torture/compile/pr89663-2.c: Likewise. * gcc.c-torture/compile/pta-1.c: Likewise. * gcc.c-torture/compile/stack-check-1.c: Likewise. * gcc.dg/Walloc-size-larger-than-18.c: Likewise. --- gcc/ChangeLog | 5 ++ gcc/doc/sourcebuild.texi | 4 ++ gcc/testsuite/ChangeLog| 55 ++ gcc/testsuite/gcc.c-torture/compile/20010102-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20010107-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20011109-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20011218-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20011229-1.c | 3 ++ gcc/testsuite/gcc.c-torture/compile/20020129-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20020320-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20020706-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20020706-2.c | 2 + gcc/testsuite/gcc.c-torture/compile/20021205-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20030921-1.c | 1 + gcc/testsuite/gcc.c-torture/compile/20031023-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20031023-2.c | 2 + gcc/testsuite/gcc.c-torture/compile/20031023-3.c | 2 + gcc/testsuite/gcc.c-torture/compile/20031023-4.c | 2 + gcc/testsuite/gcc.c-torture/compile/20040614-1.c | 1 + gcc/testsuite/gcc.c-torture/compile/20040909-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20050122-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20050202-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20060208-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20081108-1.c | 2 + gcc/testsuite/gcc.c-torture/compile/20150327.c | 2 + gcc/testsuite/gcc.c-torture/compile/920428-2.c | 2 + gcc/testsuite/gcc.c-torture/compile/920928-5.c | 3 ++ gcc/testsuite/gcc.c-torture/compile/930117-1.c | 2 +
