This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]