From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id BAD303858030; Tue, 25 Jan 2022 10:32:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAD303858030 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: Ce2M6xv8occ4cSD14PKH0gJ7x01e1aXaZIf6rVcmwuFR+jt2y4zdiJGqGi/J4amTI7k3EgwDey fKbvttdtUiTivlJFFzH1IxjK+72W6qblAerymIkUQBCHFplNugiVmrp/gHT8Vu8o+0StlNy/Wo pqNnXrlX96+k017I0qv4vo0eVmJAF/STwBTv4fc6cn6QQcUSEePDzbuvpdlhmmfMxEz35kiryK 8waIC76vgbmIzFvEb0RoIqqlqW2THpk9Jv46CuPZlXGLly+iIJm4AadGEQMTblhn24sRMVI/CV jLRFt0KXYgpvHwcRix5zVm+0 X-IronPort-AV: E=Sophos;i="5.88,314,1635235200"; d="scan'208";a="71144998" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 25 Jan 2022 02:32:24 -0800 IronPort-SDR: J8b+sdJWSlE8vr5Tbh/9mR8RnLhabcbjTiiDUcW03VawI+7dHViEva/HshBuRi+DKLdNbbjoPM ifgKbFMf1SNWsTwbNdMyU39MqMiAxoOaG8uHaF2A3oVzbF01vpVzcAOUPLqfnsK7D0ks4OxIwD 3Fzc1F3sfW+6z1rsLSAOKRa4Vri6mniM2TmFq4XNYtKFGOX5KfwuuBhAqHJiDiKCvE62x6AAQO C+LJbycW6I75DjRs6YigZJKW+/inv5iTon7RJY4f4ckCFILXMdLx9HdmyJkohgfmQV2u4wVRcY 31g= Message-ID: Date: Tue, 25 Jan 2022 11:32:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0). Content-Language: en-US To: Thomas Schwinge , Jakub Jelinek , Hafiz Abid Qadeer CC: , 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> From: Tobias Burnus In-Reply-To: <87r18wtbol.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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: Tue, 25 Jan 2022 10:32:30 -0000 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 --disable= -linux-futex" 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'.) (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 think 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.) Tobias 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+0x402c05) #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+0x402aee) #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_interce= ptors_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 ----------------- 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