OpenACC 'kernels' testsuite failures

David Edelsohn dje.gcc@gmail.com
Tue Nov 17 15:03:16 GMT 2020


Hi, Thomas

The standard version of Tcl installed on AIX currently is Tcl 8.4.
I'll see if I can have a newer version on the side.

The patch resolves the "no such variable" error message.  (Great!
Thanks!)  I now see:

during GIMPLE pass: omplower

as an Excess error.  Any idea where that comes from and why it doesn't
appear on other targets?  Does that need to be captured and ignored?

Thanks, David

On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge
<thomas@codesourcery.com> wrote:
>
> Hi David!
>
> While you were writing your email, I've also been busy:
>
> On 2020-11-16T11:32:46-0500, David Edelsohn <dje.gcc@gmail.com> wrote:
> > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
> >> On 2020-11-15T15:47:15-0500, David Edelsohn <dje.gcc@gmail.com> wrote:
> >> > I am seeing a number of new failures on AIX related to the OpenACC
> >> > kernels patches.
> >> >
> >> > c-c++-common/goacc/kernels-decompose-1.c
> >> > c-c++-common/goacc/kernels-decompose-2.c
> >> > gfortran.dg/goacc/kernels-decompose-1.f95
> >> > gfortran.dg/goacc/kernels-decompose-2.f95
> >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c
> >> > libgomp.oacc-fortran/pr94358-1.f90
> >>
> >> I suppose what you're asking about is what appears in
> >> <gcc-testresults@gcc.gnu.org> reports as:
> >>
> >>     ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] "
> >>     UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] "
> >>
> >> Etc.
>
> In the mean time, I did remember that weeks ago, I had noticed this
> following "detail": on <https://www.tcl.tk/man/tcl8.5/TclCmd/incr.htm> we
> read that "Starting with the Tcl 8.5 release, the variable 'varName'
> passed to 'incr' may be unset, and in that case, it will be set to
> [...]".  Tcl 8.5 has been released in 2007.
>
> Per 'gcc/doc/install.texi' we require:
>
>     @item DejaGnu 1.4.4
>     @itemx Expect
>     @itemx Tcl
>
>     Necessary to run the GCC testsuite; [...]
>
> DejaGnu has been released in 2004 (so cannot have required Tcl 8.5
> released in 2007).
>
> >> However, per the reports posted there, these really only (!) appear to
> >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" testing,
> >> strange.  Which versions of DejaGnu and Tcl are used?
> >
> > For my internal tester DejaGNU reports the following:
> >
> > Expect version is 5.42.1
> > Tcl version is 8.4
> > Framework version is 1.5.3
>
> There we go: you're on Tcl 8.4.  ;-D
>
> >> On <https://cfarm.tetaneutral.net/machines/list/> I see there are AIX
> >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the issue
> >> there.
>
> On these, we've got:
>
>     tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --version
>     WARNING: Couldn't find the global config file.
>     Expect version is       5.45.4
>     Tcl version is          8.6
>     Framework version is    1.4.4
>
>     tschwinge@gcc119:[/home/tschwinge]/opt/freeware/bin/runtest --version
>     WARNING: Couldn't find the global config file.
>     Expect version is       5.44.1.15
>     Tcl version is          8.5
>     Framework version is    1.5.3
>
> ..., so can't (easily) be used to reproduce the issue.  (... but it
> wouldn't be specific to AIX, anyway.)
>
> Before I spend time on building/verifying with Tcl 8.4: are you able to
> give the attached patch "[testsuite] Avoid Tcl 8.5-specific behavior" a
> try?
>
>
> Grüße
>  Thomas
>
>
> >> Admittedly, using Tcl code inside DejaGnu directives is not most common,
> >> but it does make sense conceptually (at least to me), and reportedly does
> >> work with a large number of DejaGnu/Tcl versions combinations.
> >>
> >> > Looking at the testsuite logs I see:
> >> >
> >> > fatal error: GCC is not configured to support amdgcn-amdhsa as offload target
> >>
> >> That one's not actually related to the new OpenACC 'kernels' testcases:
> >> it's just the testsuite harness checking whether GCN offloading is
> >> configured.  (See <https://gcc.gnu.org/PR88920> "GCC is not configured to
> >> support amdgcn-unknown-amdhsa as offload target"; this should one appear
> >> once per testsuite.)
> >>
> >> > I don't know why this is different from the other OpenACC tests.
> >>
> >> It's not.  At least not intentionally.
> >
> > I don't see any obvious difference in the style of the additional
> > options for the kernels testcases versus others, although it
> > specifically is using an option for that test.  I only see the "GCC is
> > not configured ... amdhsa" for those tests.
> >
> >>
> >> > How
> >> > should these tests be skipped or adjusted to not fail on other
> >> > systems?
> >>
> >> They are expected to work fine on all systems; they're not specific to
> >> actual code offloading.  So if something FAILs, we shall resolve it.
> >
> > Thanks, David
>
>
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter


More information about the Gcc-patches mailing list