On Wed, 28 Sept 2022 at 14:50, Thomas Schwinge <tho...@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc <gcc@gcc.gnu.org> wrote:
> > On 2/4/22 08:21, Thomas Schwinge wrote:
> >> On 2022-02-03T13:35:55+0000, "vries at gcc dot gnu.org via Gcc-bugs"
> >> <gcc-b...@gcc.gnu.org> wrote:
> >>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x {
> >>> GOMP_NVPTX_JIT=-O0, <default> }.
> >>
> >> Do you use separate (nvptx-none offload target only?) builds for
> >> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
> >> multilib configuration?
> >
> > Neither, I'm using --target_board=unix/foffload= for that.
>
> OK, so that's for libgomp nvptx offloading testing.
>
> What about nvptx target testing:
> 'gcc/testsuite/gcc.target/nvptx/nvptx.exp'.
>
> We have a DejaGnu board file, say 'BOARD', invoking the nvptx-tools
> 'nvptx-none-run' launcher
> (<https://github.com/MentorEmbedded/nvptx-tools/>):
>
> $ make check RUNTESTFLAGS='--target_board=BOARD'
>
> That generally works as expected.
>
> But now suppose that 'BOARD' needs '-mptx=3.1', because old CUDA, for
> example. Running the obvious '--target_board=BOARD/-mptx=3.1' FAILs in a
> number of 'gcc.target/nvptx/nvptx.exp' test cases, for example:
>
> FAIL: gcc.target/nvptx/alias-1.c (test for excess errors)
> Excess errors:
> [...]/gcc.target/nvptx/alias-1.c:13:6: error: alias definitions not
> supported in this configuration
>
> That's because we then invoke GCC as follows:
>
> [GCC] [...]/gcc.target/nvptx/alias-1.c [...] -malias -mptx=6.3 [...]
> -mptx=3.1 -o ./alias-1.exe
>
> Here, '-malias -mptx=6.3' are due to 'dg-add-options ptx_alias' in the
> test case, but our '-mptx=3.1' overrides that, thus FAIL. I think these
> would work if the '-mptx=3.1' came first?
Which version of Dejagnu are you using? There was a fix in 6.1 or 6.2
to change the order that the RUNTESTFLAGS and dg-options get added to
the command line.
It's a pain to make the testsuite work consistently for both old and
new versions. I would be very happy if we just said you need a modern
version of Dejagnu, and relied on the semantics in the newer versions.
