public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Iain Sandoe <iain@sandoe.co.uk>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] JIT, testsuite, Darwin: Initial testsuite fixes.
Date: Wed, 18 Aug 2021 15:54:20 -0400	[thread overview]
Message-ID: <eff11c67912ee1eaac649988cdd881ff2f7e9653.camel@redhat.com> (raw)
In-Reply-To: <B7F72FD3-FFEE-4B13-B012-942C10ADC5E7@sandoe.co.uk>

On Wed, 2021-08-18 at 20:40 +0100, Iain Sandoe wrote:
> Hi,
> 
> * Note, the strategy in jit.exp has the assumption that
> $target==$host
>   the patches here adhere to that - there is far less testsuite
> library
>   support for host-side facilities (which we’d probably want to add
> if
>   it was desirable to operate the Jit in a cross-compiler
> environment).

Various people have expressed wanting to use libgccjit for ahead-of-
time cross-compilation, so that's a use-case we're going to want to
support at some point (e.g. the libgccjit-based rustc backend).

> 
> -------
> 
> The testsuite setup for jit is not compatible with Darwin since it
> assumes that all targets support --export-dynamic.
> 
>  - this is fixed by adding '-rdynamic' conditionally upon target
>    support for that (-rdynamic will be converted to the appropriate
>    linker option).
>   
> There is also an assumption that a suitable version of dejagnu.h
> is present in some default include search path that is usable from
> the testsuite.  This is not the case for Darwin (dejagnu.h is not
> installed, and would not, in general, be found in any default 
> include
> search path if installed via one of the main 'distros').  Also, the
> upstream dejagnu.h has a definition of 'wait()' that clashes with a
> libc routines and therefore causes fails in the testsuite.
> 
>  - This patch imports the header from dejagnu-1.6.2 and
>    * renames it to 'jit-dejagnu.h'
>    * patches it to avoid unused variable warnings and the clash
>      with the libc definition of wait ()
>    * In accordance with the advice in the expect man page, ensures
>      that the final output of the 'totals' print is stable.
> 
> tested on i686, x86_64-darwin, x86_64, powerpc64-linux,
> OK for master?

[...snip...]

> diff --git a/gcc/jit/docs/examples/tut04-toyvm/toyvm.c
> b/gcc/jit/docs/examples/tut04-toyvm/toyvm.c
> index e742f344068..8ea716e2d0a 100644
> --- a/gcc/jit/docs/examples/tut04-toyvm/toyvm.c
> +++ b/gcc/jit/docs/examples/tut04-toyvm/toyvm.c
> @@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include <stdlib.h>
>  #include <string.h>
>  
> -#include <dejagnu.h>
> +#include "jit-dejagnu.h"
>  
>  #include <libgccjit.h>
>  
> diff --git a/gcc/jit/docs/examples/tut04-toyvm/toyvm.cc
> b/gcc/jit/docs/examples/tut04-toyvm/toyvm.cc
> index 4b9c7651ee3..7e9550159ad 100644
> --- a/gcc/jit/docs/examples/tut04-toyvm/toyvm.cc
> +++ b/gcc/jit/docs/examples/tut04-toyvm/toyvm.cc
> @@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include <stdlib.h>
>  #include <string.h>
>  
> -#include <dejagnu.h>
> +#include "jit-dejagnu.h"
>  
>  #include <libgccjit++.h>
>  

There's a Makefile in gcc/jit/docs/examples/tut04-toyvm which can be
used to build these, so do the
  #include "jit-dejagnu.h"
will need to be adjusted to give a path that finds the new header?

That said, the Makefile seems to assume pkg-config, so it's not working
particularly well as-is, so maybe there's no need to fix this.

Other than that nit, looks good to me.

test-threads.c does some preprocessor hackery to make <dejagnu.h>
threadsafe which it would be nice to fix, but that feels like followup
work and not needed for this patch.

Thanks
Dave



  reply	other threads:[~2021-08-18 19:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 19:40 Iain Sandoe
2021-08-18 19:54 ` David Malcolm [this message]
2021-08-19  8:34   ` Iain Sandoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eff11c67912ee1eaac649988cdd881ff2f7e9653.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).