From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id E8FA23858D33; Sat, 11 May 2024 20:13:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E8FA23858D33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E8FA23858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.15.18 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715458383; cv=none; b=NmikTYA/siOaaSOhOqj/99lBP6Jn+A2au4PPK4KjleeHEaqYYQOK8XU1S7nm2CISOAuvHl9MU4zdBxfKafioLy8L/1XrakNidocLuyFWQalj+Ge6WfRIC3bX6am5mUMwTzWQYh+9rkQ7xDr9VW40sbZumdIozSRB4FfjNDF4mQQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715458383; c=relaxed/simple; bh=m2dKD9KjrcBp6eQXUMcEXRWBtMvOLjbI5Bv9cwkIspM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PcIFTuhsdaXs2eDfINeRrizDW7DyVkrWJfzUwP2+UD37nqt0S4fZP339FuYl1sm9hVL0L/qMuna8BcmbLkSeSUP5snX/C2R8B9lpeB9C8iyNQEvB8/Xrzpo7BEmkEPSt+SNBVJlwRLbzz640mH0Y2HjcgH6PTsxN7/faCC0Obr0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1715458379; x=1716063179; i=anlauf@gmx.de; bh=bWsazelgSd3zQ8RSy7LJL5IiZb72qIy1/lREDFtoqfk=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=V9E+Ep6Xrhnm6O6CyrtvJOFWmjlbqi//H7roNIAQa8bGtafR10um4bxFnsREmuKh YNdAP/1pVtMqtRXF9mUSbD9fUnVrW3R7CbyCtM7VC42ByazXNFWKOzwU8T9HcxkKB IzpjD4QzwBrG92Q/iZ3+rNMrY+Q9NmvenVenAse823BSUFCLcErwacKeVNgiKDXTL uR56FEL2tzmcOC+fi9urf0iBv7gnF70K0TaYSATSV6HmjzDjZx3d7XR9ATQcsu+6H dE7tsMUOGH4yquAslkpxv8SLQjTcPGXb57MW2k/BKuZJb8MyuuZ9M3upy7URH1uLo fKIsRIfbx/WXUzP9BQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.251.6.124]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MiJZE-1sYt7U3Kp4-00fOl4; Sat, 11 May 2024 22:12:58 +0200 Message-ID: <36d2a746-3dce-450d-93e5-7aa48915a80b@gmx.de> Date: Sat, 11 May 2024 22:12:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: Content-Language: en-US From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:MvXmI0+/IXQU4RI/sDpL8Ou8amXgbKlUGUFhunejJ36GJHRWyi7 XOBrqcU6gofnzpQpAoddlZC1RKvv1xILh03qvAqXo7UcpyUdHKg3YOssXi6NMeMbuHBWgHM tBUJzgvm4oPaXBEcN9CxAnPS3MWz96zGv77exY2u95W7Tp38LGbCMaz06PVHar8yOmtLy1K VkYDrNWGXnG0GQlV0Qwuw== UI-OutboundReport: notjunk:1;M01:P0:t+qzadGQsmo=;LiyMtF3M/McYecT+5QHtLp+omcm CXaVe2QiD1c/433By76hPirw9T5s3xoFyqHI7li7XtLM1n5kk7CfyvXq8PcqKLpK8eY4mlgko mFcphevLtwlk9MDrqOJaD35HV/P1yTaLA8KfiHd1jkvRyEFLD+A1UdNWHL7g0fTEXKBpYQFNR qVLNdK+SYkN/vN0KDsnrHEQpM8YdT0Z+mOFPkfud2jvaLDT5RujSz3bbL2BukgWYPqmXx8SDv jnuJAYfHDwHzpTXXvM0Juiztr25XYPT+tF4fsUYGdsmyjTtrd1PhIFHOWKhfcfQ0YtV++gJZi PDPtJ1GnbxVjlE0mad6t8apKybxmfoJWZjcvWUOvoSJpzLQh94E4ucIimy/2+7fA3k2Gs7e66 ISlEC87uXp01R9ImZyQz1xwK0ZTGNe+uB0h4s2yVQ8pvfO4p7uQg3DX8uhQLnn8ywur3AsUH0 hUfYY3L8p+fa6OmkpWfCIcIwILiq3c6K3riEKx0kpKiwh2gSsOeHHAeYsEoqeT9dwcCtx7LYM YFu+icEpDahUdQrQmITVw8XCA43ax1UfF5+IXkGgWnsIA+Oh252TICTAuqImnqwdx5nOSk/Hv kQ47M2WMifBk1oVCJvqbwOzbt910tbO8gz3cntKmxqDoDmBl9Lyx6SclJWAh1bulZqn8xK8J6 BWWYPocQTJPrgjcg5Ocn3PZBDkBGZYzjhzO4AkhxbDx6K+z+2shkrRlrYEU/GLehz3l0AD+Ef JU8MC5IB+3YGErtVpdVXNVdL48g6fHrVxHrtfelX45qLbUzY6TbmXnewfxA+5hc/5gJs/tRbD uNQUTm8URKphLvi0mmgfrzVIGPqUuDWX7y21c+flc8Tzg= X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Paul, Am 11.05.24 um 08:20 schrieb Paul Richard Thomas: > Hi Harald, > > Thanks for the review. The attached resubmission fixes all the invalid > accesses, memory leaks and puts right the incorrect result. > > In the course of fixing the fix, I found that deferred character length > MOLDs gave an ICE because reallocation on assign was using 'dest_word_le= n' > before it was defined. This is fixed by not fixing 'dest_word_len' for > these MOLDs. Unfortunately, the same did not work for unlimited polymorp= hic > MOLD expressions and so I added a TODO error in iresolve.cc since it > results in all manner of memory errors in runtime. I will return to this > another day. > > A resubmission of the patch for PR113363 will follow since it depends on > this one to fix all the memory problems. > > OK for mainline? this is OK from my side. One minor nit: the updated testcase transfer_class_4.f90 has if (sz /=3D storage_size (real32)/8) stop 1 I think you meant either storage_size (r) or storage_size (1._real32) instead of checking the storage size of the integer real32 here... Thanks for the patch! Harald > Regards > > Paul > > On Thu, 9 May 2024 at 08:52, Paul Richard Thomas < > paul.richard.thomas@gmail.com> wrote: > >> Hi Harald, >> >> The Linaro people caught that as well. Thanks. >> >> Interestingly, I was about to re-submit the patch for PR113363, in whic= h >> all the invalid accesses and memory leaks are fixed but requires this p= atch >> to do so. The final transfer was thrown in because it seemed to be work= ing >> out of the box but should be checked anyway. >> >> Inserting your print statements, my test shows the difference in >> size(chr_a) but prints chr_a as "abcdefgjj" no matter what I do. Needle= ss >> to say, the latter was the only check that I did. The problem, I suspec= t, >> lies somewhere in the murky depths of >> trans-array.cc(gfc_alloc_allocatable_for_assignment) or in the array pa= rt >> of intrinsic_transfer, untouched by either patch, and is present in 13-= and >> 14-branches. >> >> I am onto it. >> >> Cheers >> >> Paul >> >> >> On Wed, 8 May 2024 at 22:06, Harald Anlauf wrote: >> >>> Hi Paul, >>> >>> this looks mostly good, but the new testcase transfer_class_4.f90 >>> does exhibit a problem with your patch. Run it with valgrind, >>> or with -fcheck=3Dbounds, or with -fsanitize=3Daddress, or add the >>> following around the final transfer: >>> >>> print *, storage_size (star_a), storage_size (chr_a), size (chr_a), le= n >>> (chr_a) >>> chr_a =3D transfer (star_a, chr_a) >>> print *, storage_size (star_a), storage_size (chr_a), size (chr_a), le= n >>> (chr_a) >>> print *, ">", chr_a, "<" >>> >>> This prints for me: >>> >>> 40 40 2 5$ >>> 40 40 4 5$ >>> >abcdefghij^@^@^@^@^@^@^@^@^@^@<$ >>> >>> So since the physical representation of chr_a is sufficient >>> to hold star_a (F2023:16.9.212), no reallocation with a wrong >>> calculated size should happen. (Intel and NAG get this right.) >>> >>> Can you check again? >>> >>> Thanks, >>> Harald >>> >>> >>> >