From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-15.smtpout.orange.fr [80.12.242.15]) by sourceware.org (Postfix) with ESMTPS id 5A85E385841A for ; Sat, 25 Feb 2023 16:35:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A85E385841A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id VxVopCOHkkAmIVxVup75wt; Sat, 25 Feb 2023 17:35:11 +0100 X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sat, 25 Feb 2023 17:35:11 +0100 X-ME-IP: 86.215.161.51 Content-Type: multipart/mixed; boundary="------------036syM6GAxz5w82mhCsbT0T5" Message-ID: <48878e99-0ecb-3688-0c2e-db7ec69856df@orange.fr> Date: Sat, 25 Feb 2023 17:35:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 From: Mikael Morin Subject: fortran: Reuse associated_dummy memory if previously allocated [PR108923] To: gfortran , gcc-patches Cc: Harald Anlauf Content-Language: en-US X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,LOCALPART_IN_SUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: This is a multi-part message in MIME format. --------------036syM6GAxz5w82mhCsbT0T5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Harald found a testcase with memory still leaking despite my previous patch for PR108923. That patch was fixing a leak caused by absence of memory release, the attached patch fixes a leak caused by pointer overwrite. I haven't investigated why sort_actual is called several times( which causes the memory leak) nor tried to avoid that. Theoretically, one could assert that the previous associated_dummy value is the same as the one to be written (it should be the same at each sort_actual invocation), but I have preferred to silently overwrite, and fix just the memory problem. Manually tested on Harald's testcase (predcom-1.f) and ran the full fortran testsuite on x86_64-pc-linux-gnu. OK for master and 12 and 11? --------------036syM6GAxz5w82mhCsbT0T5 Content-Type: text/x-patch; charset=UTF-8; name="0001-fortran-Reuse-associated_dummy-memory-if-previously-.patch" Content-Disposition: attachment; filename*0="0001-fortran-Reuse-associated_dummy-memory-if-previously-.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA5Yjg4MjA4ZWM0MTMwNzEyZDMzZDVjN2VkNzRmYzE3NDY2NjI0YTBjIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBNaWthZWwgTW9yaW4gPG1pa2FlbEBnY2MuZ251Lm9y Zz4KRGF0ZTogU2F0LCAyNSBGZWIgMjAyMyAxNjoyNzoyNCArMDEwMApTdWJqZWN0OiBbUEFU Q0hdIGZvcnRyYW46IFJldXNlIGFzc29jaWF0ZWRfZHVtbXkgbWVtb3J5IGlmIHByZXZpb3Vz bHkKIGFsbG9jYXRlZCBbUFIxMDg5MjNdCgpUaGlzIGF2b2lkcyBtYWtpbmcgdGhlIGFzc29j aXRlZF9kdW1teSBmaWVsZCBwb2ludCB0byBhIG5ldyBtZW1vcnkgY2h1bmsKaWYgaXQncyBh bHJlYWR5IHBvaW50aW5nIHNvbWV3aGVyZSwgaW4gd2hpY2ggY2FzZSBkb2luZyBzbyB3b3Vs ZCBsZWFrIHRoZQpwcmV2aW91c2x5IGFsbG9jYXRlZCBjaHVuay4KCmdjYy9mb3J0cmFuL0No YW5nZUxvZzoKCgkqIGludHJpbnNpYy5jYyAoZ2V0X2ludHJpbnNpY19kdW1teV9hcmcsCglz ZXRfaW50cmluc2ljX2R1bW15X2FyZyk6IFJlbmFtZSB0aGUgZm9ybWVyIHRvIHRoZSBsYXR0 ZXIuCglSZW1vdmUgdGhlIHJldHVybiB2YWx1ZSwgYWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBs aHMgYXMgYXJndW1lbnQsCglhbmQgZG8gdGhlIHBvaW50ZXIgYXNzaWdubWVudCBpbnNpZGUg dGhlIGZ1bmN0aW9uLiAgRG9uJ3QgZG8KCWl0IGlmIHRoZSBwb2ludGVyIGlzIGFscmVhZHkg bm9uLU5VTEwuCgkoc29ydF9hY3R1YWwpOiBVcGRhdGUgY2FsbGVyLgotLS0KIGdjYy9mb3J0 cmFuL2ludHJpbnNpYy5jYyB8IDExICsrKysrLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgNSBp bnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2djYy9mb3J0cmFu L2ludHJpbnNpYy5jYyBiL2djYy9mb3J0cmFuL2ludHJpbnNpYy5jYwppbmRleCAxN2VlOTk5 YzNiOS4uZTY5ZTU0MWVmZTAgMTAwNjQ0Ci0tLSBhL2djYy9mb3J0cmFuL2ludHJpbnNpYy5j YworKysgYi9nY2MvZm9ydHJhbi9pbnRyaW5zaWMuY2MKQEAgLTQyNTksMTUgKzQyNTksMTQg QEAgcmVtb3ZlX251bGxhcmdzIChnZmNfYWN0dWFsX2FyZ2xpc3QgKiphcCkKIH0KIAogCi1z dGF0aWMgZ2ZjX2R1bW15X2FyZyAqCi1nZXRfaW50cmluc2ljX2R1bW15X2FyZyAoZ2ZjX2lu dHJpbnNpY19hcmcgKmludHJpbnNpYykKK3N0YXRpYyB2b2lkCitzZXRfaW50cmluc2ljX2R1 bW15X2FyZyAoZ2ZjX2R1bW15X2FyZyAqJmR1bW15X2FyZywgZ2ZjX2ludHJpbnNpY19hcmcg KmludHJpbnNpYykKIHsKLSAgZ2ZjX2R1bW15X2FyZyAqIGNvbnN0IGR1bW15X2FyZyA9IGdm Y19nZXRfZHVtbXlfYXJnICgpOworICBpZiAoZHVtbXlfYXJnID09IE5VTEwpCisgICAgZHVt bXlfYXJnID0gZ2ZjX2dldF9kdW1teV9hcmcgKCk7CiAKICAgZHVtbXlfYXJnLT5pbnRyaW5z aWNuZXNzID0gR0ZDX0lOVFJJTlNJQ19EVU1NWV9BUkc7CiAgIGR1bW15X2FyZy0+dS5pbnRy aW5zaWMgPSBpbnRyaW5zaWM7Ci0KLSAgcmV0dXJuIGR1bW15X2FyZzsKIH0KIAogCkBAIC00 NDMwLDcgKzQ0MjksNyBAQCBkb19zb3J0OgogICAgICAgaWYgKGEgPT0gTlVMTCkKIAlhID0g Z2ZjX2dldF9hY3R1YWxfYXJnbGlzdCAoKTsKIAotICAgICAgYS0+YXNzb2NpYXRlZF9kdW1t eSA9IGdldF9pbnRyaW5zaWNfZHVtbXlfYXJnIChmKTsKKyAgICAgIHNldF9pbnRyaW5zaWNf ZHVtbXlfYXJnIChhLT5hc3NvY2lhdGVkX2R1bW15LCBmKTsKIAogICAgICAgaWYgKGFjdHVh bCA9PSBOVUxMKQogCSphcCA9IGE7Ci0tIAoyLjM5LjEKCg== --------------036syM6GAxz5w82mhCsbT0T5--