From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 559BA3858D20; Fri, 4 Feb 2022 09:46:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 559BA3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 1P6kzPAQQbN4/SARb3R3jTxqfHBU38TgzQvaYxeeOV/cPe3aytZVfDtgNmzU82pHUdJ1xFeOz4 oHuKHGjAP0KUY8v36PZRwZmoitmNOMiDxEVp5XFqsVeRWd63hJwjG30OcQw/+ADyKqtmn5emBc IZYsvjgmmE6SASmuRX8sPSysJDM5Mt/UlRgU4kA8M7bhf14IgorFrXS5aZT/Ox+rJETPlaSloH HKfCDysiHL/AZsBdUzp+uXonH1iftkQglPUYD9vPagG51GJhbCHAWQEojU0+MQ4lLjRWp3Rxlp Esgg+TKmC7r8TH2mBUDxvYet X-IronPort-AV: E=Sophos;i="5.88,342,1635235200"; d="scan'208";a="71603952" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 04 Feb 2022 01:46:56 -0800 IronPort-SDR: 2QxiptIYS3W45Yzf4tBsa43HmmB/OrLRHqw3MZbZTzhwIg6UVFmr+3WOj0qJwLg4Sae0+IX1hS fmNfsAL3kn3lQ/M/c6BDB1B3EtH4Ae5ZxjnYgvYetG7nHn/O8oNFwfTc5uXWjpuqiUqWUJyCAX 3YWLvhJyOiLyR8Aryo8ZHuaWri7gpQR027gOeA7Qqo0wAdoo/ZGY4uWGeuUj9SdQ6wmTuexWUA uvkoOsbgapkfKBWHYJHmzNr8k67Nep5VfRxT/EB8J40DU7tf+2Gv3pBaQ8cZjFqeCws6S6m+RM vr8= From: Thomas Schwinge To: Hafiz Abid Qadeer , Tobias Burnus , Jakub Jelinek CC: , Subject: Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0). In-Reply-To: <343f7669-0e6a-11eb-3580-e351711f02b9@mentor.com> References: <20211022130502.2211568-1-abidh@codesourcery.com> <20211102162714.GF304296@tucnak> <20211220200650.GN2646553@tucnak> <8735lh6mcx.fsf@euler.schwinge.homeip.net> <48d8c123-fa4f-d4a3-17de-b082de32f0bf@codesourcery.com> <87r18wtbol.fsf@euler.schwinge.homeip.net> <343f7669-0e6a-11eb-3580-e351711f02b9@mentor.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Fri, 4 Feb 2022 10:46:49 +0100 Message-ID: <87k0ebrmk6.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 09:47:03 -0000 Hi! On 2022-01-31T19:13:09+0000, Hafiz Abid Qadeer wro= te: > On 25/01/2022 10:32, Tobias Burnus wrote: >> On 25.01.22 10:19, Thomas Schwinge wrote: >>>> I am trying to figure out if the problem you observed >>>> is a general one or just specific to fortran testcase. >>> So, unless the '-fsanitize=3Dthread' issues are bogus -- unlikely ;-) -= - it >>> seems a latent issue generally, now fatal with >>> 'libgomp.fortran/allocate-1.f90'. >> >> There is one known issue with libgomp and TSAN (-fsanitize=3Dthread) >> that I tend to forget about :-( >> >> That's according to Jakub, who wrote a while ago: >> >> "TSAN doesn't understand what libgomp is doing, unless built with --disa= ble-linux-futex" Uh. Anything that can reasonably be done to address this? At least, to make this obvious to the user of '-fsanitize=3Dthread'? >> However, I now tried to disable futex and still get the following. >> (First result for libgomp.c-c++-common/allocate-1.c). >> >> On the other hand, I have the feeling that the configure option is >> a no op for libgomp. This can also be seen in the configure.ac script, >> which only for libstdc++ uses the result and the others have a no-op >> call to 'true' (alias ':'): >> >> libgomp/configure.ac:GCC_LINUX_FUTEX(:) >> libitm/configure.ac:GCC_LINUX_FUTEX(:) >> libstdc++-v3/configure.ac:GCC_LINUX_FUTEX([AC_DEFINE(HAVE_LINUX_FUTEX, 1= , [Define if futex syscall >> is available.])]) >> >> (The check is not completely pointless as some checks are still done; >> e.g. 'SYS_gettid and SYS_futex required'.) Uh. That (make '--disable-linux-futex' work) should be fixed, I suppose? >> (TSAN did find issues in libgomp in the past, however. But those >> habe been fixed.) >> >> >> Thus, there might or might not be an issue when TSAN reports one. >> >> * * * >> >> Glancing at the Fortran testcase, I noted the following, >> which probably does not cause the problems. But still, >> I want to mention it: >> >> !$omp parallel private (y, v) firstprivate (x) allocate (x, y, v) >> if (x /=3D 42) then >> stop 1 >> end if >> >> v(1) =3D 7 >> if ( (and(fl, 2) /=3D 0) .and. & >> ((is_64bit_aligned(x) =3D=3D 0) .or. & >> (is_64bit_aligned(y) =3D=3D 0) .or. & >> (is_64bit_aligned(v(1)) =3D=3D 0))) then >> stop 2 >> end if >> >> If one compares this with the C/C++ testcase, I note that there >> is a barrier before the alignment check in C/C++ but not in >> Fortran. Additionally, 'v(1) =3D 7' is set twice and the >> alignment check happens earlier than in C/C++. Not that that >> should really matter, but I just saw it. >> >> >> In C/C++: >> int v[x], w[x]; >> ... >> v[0] =3D 7; >> v[41] =3D 8; >> >> In Fortran: >> integer, dimension(x) :: v >> ... >> v(1) =3D 7 >> v(41) =3D 8 >> >> where 'x =3D=3D 42'. The Fortran version is not really wrong, but I thin= k >> the idea is to set the first and last array element - and that's here >> v(42) and not v(41). >> >> BTW: Fortran permits to specify a different lower bound. When converting >> C/C++ testcases, it can be useful to use the same lower bound also in >> Fortran: integer :: v(0:x-1) (or: 'integer, dimension(0:x-1) :: v') >> uses then 0 ... 41 for the indices instead of 1 ... 42. >> >> But one has to be careful as Fortran uses the upper bound and C uses the >> number of elements. (Same with OpenMP array sections in Fortran vs. C.) Abid, are you going to address these? I think it does make sense if the C/C++ and Fortran test cases match as much as feasible. >> PS: The promised data-race warning: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> WARNING: ThreadSanitizer: data race (pid=3D4135381) >> Read of size 8 at 0x7ffc0888bdc0 by thread T10: >> #0 foo._omp_fn.2 libgomp.c-c++-common/allocate-1.c:47 (a.out+0x402c0= 5) >> #1 gomp_thread_start ../../../repos/gcc/libgomp/team.c:129 (libgomp.= so.1+0x1e5ed) >> >> Previous write of size 8 at 0x7ffc0888bdc0 by main thread: >> #0 foo._omp_fn.1 libgomp.c-c++-common/allocate-1.c:47 (a.out+0x402ae= e) >> #1 GOMP_teams_reg ../../../repos/gcc/libgomp/teams.c:51 (libgomp.so.= 1+0x3638c) >> #2 main libgomp.c-c++-common/allocate-1.c:366 (a.out+0x40273e) >> >> Location is stack of main thread. >> >> Location is global '' at 0x000000000000 ([stack]+0x1ddc0) >> >> Thread T10 (tid=3D4135398, running) created by main thread at: >> #0 pthread_create ../../../../repos/gcc/libsanitizer/tsan/tsan_inter= ceptors_posix.cpp:1001 >> (libtsan.so.2+0x62c76) >> #1 gomp_team_start ../../../repos/gcc/libgomp/team.c:858 (libgomp.so= .1+0x1ec18) >> #2 main libgomp.c-c++-common/allocate-1.c:366 (a.out+0x40273e) >> >> SUMMARY: ThreadSanitizer: data race libgomp.c-c++-common/allocate-1.c:47= in foo._omp_fn.2 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > Problem was with the pool_size trait. It has limited size which this test= case exceeded. I have > removed it now which seems to fix the problem. Ok to commit the attached = patch? First, I do confirm that this (testing together with Tobias' patch "which silences the three kind of warnings and fixes the interface issue" plus my suggestion that the "early 'stop' [...] be backed out") does resolve the execution FAILs, thanks. However: really (a) remove 'omp_alloctrait (omp_atk_pool_size, 8192)' altogether, or instead: (b) increase its size (if that can be computed) -- and/or (c) limit the number of OpenMP threads executing in parallel? Due to unfamiliarity with all that, I don't know what's best here. Gr=C3=BC=C3=9Fe Thomas > From 98b5493bd94520dd78b3963d3a4e67cba6bfb6aa Mon Sep 17 00:00:00 2001 > From: Hafiz Abid Qadeer > Date: Mon, 31 Jan 2022 19:02:14 +0000 > Subject: [PATCH] [libgomp] Fix testcase to remove out of memory error. > > Thomas reported in > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589039.html > that this testcase is randomly failing. The problem was fixed pool > size which was exhausted when there were a lot of threads. Fixed it > by removing pool_size trait which causes default pool size to be used > which should be big enough. > > libgomp/ChangeLog: > > * testsuite/libgomp.fortran/allocate-1.f90: Remove pool_size trait. > --- > libgomp/testsuite/libgomp.fortran/allocate-1.f90 | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/libgomp/testsuite/libgomp.fortran/allocate-1.f90 b/libgomp/t= estsuite/libgomp.fortran/allocate-1.f90 > index 35d1750b878..04bf2307462 100644 > --- a/libgomp/testsuite/libgomp.fortran/allocate-1.f90 > +++ b/libgomp/testsuite/libgomp.fortran/allocate-1.f90 > @@ -313,13 +313,12 @@ program main > integer, dimension(4) :: p > integer, dimension(4) :: q > > - type (omp_alloctrait) :: traits(3) > + type (omp_alloctrait) :: traits(2) > integer (omp_allocator_handle_kind) :: a > > traits =3D [omp_alloctrait (omp_atk_alignment, 64), & > - omp_alloctrait (omp_atk_fallback, omp_atv_null_fb), & > - omp_alloctrait (omp_atk_pool_size, 8192)] > - a =3D omp_init_allocator (omp_default_mem_space, 3, traits) > + omp_alloctrait (omp_atk_fallback, omp_atv_null_fb)] > + a =3D omp_init_allocator (omp_default_mem_space, 2, traits) > if (a =3D=3D omp_null_allocator) stop 1 > > call omp_set_default_allocator (omp_default_mem_alloc); > -- > 2.25.1 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955