From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 9DB3D3858006 for ; Tue, 17 Nov 2020 15:03:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9DB3D3858006 Received: by mail-wr1-x42f.google.com with SMTP id r17so23522585wrw.1 for ; Tue, 17 Nov 2020 07:03:28 -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=P9zyVZFt8AyT0Su/lpAymbkYREJzONnjEXhPgxKnL1s=; b=aCGFNBIizaBRK5whTF+YqdwCJF0SFF0JrHV03KBWucWOY3GoOuKKarRoLTbOgJQRrz fxv4Euq0bwdKnQyvKvlABQ2cmIu8ces5bnsxc04XxPJAw2vcPshsmrEkiGUmEo/7UUiQ fhsi/Z952uxFhkNaTeGa3FBkoYMfuOgdavhxjOq6DI9FMbRwnwgPvtdi4tLF6at1Slxp 5vA43sca4b8Kpd2V+GgUVmF9nRNteCBmGW4ta8eybAIAXP12juKuW3/XGWukYA3mwAzU a8LJuI7FZFKvfXxaHC43QNk06P5CZ5k5Qvz7YSPjwss3TFsfOSnIGwOneWDWowo+70iG uv3Q== X-Gm-Message-State: AOAM532ucEjo4Bb1ZaPto5szYgu4xPSM0iC+Dj47ItjCc3DWwe26CSsN LHd0XZ42r6qG1N8vP8c72AsndcHAqyp5Dfg4P97iecTn X-Google-Smtp-Source: ABdhPJydOOMUXMfh0ez1EfWxuTeUGU7CZwCsM+SjyHGU2p/U4bYHwSM65toObLkkDuSWL5aDipvAvBKSJEpBdoFYUDI= X-Received: by 2002:a5d:62c3:: with SMTP id o3mr25675666wrv.300.1605625407292; Tue, 17 Nov 2020 07:03:27 -0800 (PST) MIME-Version: 1.0 References: <87ft59e6a2.fsf@euler.schwinge.homeip.net> <87a6vhdzbn.fsf@euler.schwinge.homeip.net> In-Reply-To: <87a6vhdzbn.fsf@euler.schwinge.homeip.net> From: David Edelsohn Date: Tue, 17 Nov 2020 10:03:16 -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.2 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: Tue, 17 Nov 2020 15:03:31 -0000 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 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 > >> reports as: > >> > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read "c_loo= p_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 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 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=C3=BC=C3=9Fe > Thomas > > > >> Admittedly, using Tcl code inside DejaGnu directives is not most commo= n, > >> but it does make sense conceptually (at least to me), and reportedly d= oes > >> 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 offlo= ad 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 "GCC is not configured= to > >> support amdgcn-unknown-amdhsa as offload target"; this should one appe= ar > >> 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=C3=9Fe 201, 80634 M=C3=BCn= chen / Germany > Registergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thoma= s Heurung, Alexander Walter