From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id E02763857C66 for ; Sat, 21 Nov 2020 15:50:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E02763857C66 Received: by mail-wm1-x32e.google.com with SMTP id c9so13805006wml.5 for ; Sat, 21 Nov 2020 07:50:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iS57ZJIGNp0JHPobWrAfARXm/p+wkKEPtuvvuhk2KIs=; b=IFdsdinzk0y4sshDjTWoPDQKEPhSahugV3PAi13EvP2iLJ4lA9tkAGT6+85VtOgSls uwGEDPkmNGuUePV1jtGT1zWpi44L1hnZt9HANn/h4vAwcpocd/+jV2Mvuka+OncI1ej7 dKswJUgbPiwkoXwgHZpfX97Hp+6KNDGbKIfyD0VYWInMf51N+e9R31sIXqCrafyrAosx GL49w8TDqAw2OWvpT6pRjjQDpi0Gk//M2mLzAk1Tiyli/v37QlNmc9szq1/h7Q3O8z6N 0qnN8rtw92RynE3VXWKIgwTEZO5I91g7soUF8VM39kzv0PMpgqevjTkwCytJsXNo/7fF 7wZA== X-Gm-Message-State: AOAM533IDt/c9AqUAucSgTz7gnUgCyhXn/0Uu7wioTTxP7kFXuWbJ2/p vqwE+gfrATGC63HaMRWf4a9VYVni7+40eQ3p1wZE5P2/ X-Google-Smtp-Source: ABdhPJwVAAyCU+lURDj1Vqp9FDNunAYfHNGrQng+gSCHOnAgcXT1W3hN8KReDV/89X+uCiFt/Fq/eo6PGaVIz5O2zeA= X-Received: by 2002:a1c:e3c1:: with SMTP id a184mr15245078wmh.88.1605973822858; Sat, 21 Nov 2020 07:50:22 -0800 (PST) MIME-Version: 1.0 References: <87ft59e6a2.fsf@euler.schwinge.homeip.net> <87a6vhdzbn.fsf@euler.schwinge.homeip.net> In-Reply-To: From: David Edelsohn Date: Sat, 21 Nov 2020 10:50:10 -0500 Message-ID: Subject: Re: OpenACC 'kernels' testsuite failures To: Thomas Schwinge Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, KAM_TK, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_DBL_SPAM autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 15:50:25 -0000 Hi, Thomas I see "during GIMPLE pass: omplower" message for kernels-decompose-ice-2.c. kernels-decompose-ice-1.c explicitly prunes that output, but kernels-decompose-ice-2.c does not. Is there a reason that the second testcase does not prune that output or can we add it? Thanks, David On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn wrote: > > Hi, Thomas > > The patch resolves the "no such variable" error message, but I see > > "during GIMPLE pass: omplower" > > excess error message. > > I installed Tcl 8.6 with Expect 5.45. This removes the "no such > variable" error messages for C and C++ test cases, but they still > occur for Fortran. > > I guess that the patch is necessary because there seems to be > something else still behaving differently on AIX. > > Any insights? > > Thanks, David > > On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn wrote= : > > > > 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 > > wrote: > > > > > > Hi David! > > > > > > While you were writing your email, I've also been busy: > > > > > > On 2020-11-16T11:32:46-0500, David Edelsohn wrote= : > > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge wrote: > > > >> On 2020-11-15T15:47:15-0500, David Edelsohn wr= ote: > > > >> > I am seeing a number of new failures on AIX related to the OpenA= CC > > > >> > 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 > > > >> 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 re= ad "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 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 (!) appea= r to > > > >> fail for your "Native configuration is powerpc-ibm-aix7.2.3.0" tes= ting, > > > >> 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 I see there are = AIX > > > >> systems gcc111, gcc119 -- maybe I'll have luck reproducing the iss= ue > > > >> there. > > > > > > On these, we've got: > > > > > > tschwinge@gcc111:[/home/tschwinge]/opt/freeware/bin/runtest --ver= sion > > > 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 --ver= sion > > > 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=C3=BC=C3=9Fe > > > Thomas > > > > > > > > > >> Admittedly, using Tcl code inside DejaGnu directives is not most c= ommon, > > > >> but it does make sense conceptually (at least to me), and reported= ly 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 o= ffload target > > > >> > > > >> That one's not actually related to the new OpenACC 'kernels' testc= ases: > > > >> it's just the testsuite harness checking whether GCN offloading is > > > >> configured. (See "GCC is not config= ured 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 specifi= c to > > > >> actual code offloading. So if something FAILs, we shall resolve i= t. > > > > > > > > Thanks, David > > > > > > > > > ----------------- > > > Mentor Graphics (Deutschland) GmbH, Arnulfstra=C3=9Fe 201, 80634 M=C3= =BCnchen / Germany > > > Registergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: T= homas Heurung, Alexander Walter