This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: Mike Stump <mikestump at comcast dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 11 Sep 2019 22:47:47 +0200
- Subject: Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls
- References: <20190829151347.13536-1-jose.marchesi@oracle.com> <20190829151347.13536-5-jose.marchesi@oracle.com> <3CD73F6C-7900-48E5-95DA-345E5884AE00@comcast.net>
Hi Mike.
Thanks for the review.
On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi <jose.marchesi@oracle.com> 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.