From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93637 invoked by alias); 3 Apr 2016 13:36:04 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 93605 invoked by uid 89); 3 Apr 2016 13:36:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Contributed, caf, Besides, UD:as X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 03 Apr 2016 13:35:53 +0000 Received: from vepi2 ([88.77.160.134]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LinyL-1bP3of3fSv-00cwXq; Sun, 03 Apr 2016 15:35:49 +0200 Date: Sun, 03 Apr 2016 13:36:00 -0000 From: Andre Vehreschild To: GCC-Patches-ML , GCC-Fortran-ML Subject: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS Message-ID: <20160403153547.5b7ff61a@vepi2> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/NM_P6Qy4v62HNJSX5S7Pio_" X-UI-Out-Filterresults: notjunk:1;V01:K0:60VtaVZp9Gc=:F0z8mFe2q4cTuHe0t27HuP Z7x98lZdpM4/2PjuF93qN7X6AZSTJUAIzC+VsPZc2BXopYK6MvpIL3bq5W/5VlYE6H3WS+VNN M3OcXCVDgTphe7Nz4osTEbZG7P8yhnGjSiwMwdfD3CI5KzUGBnmPFMM6ReFXa9y3Nre5Ha0Gm 7RCZejajY5qyzMPtQfxQH4Pq97eVNiVHvV0zzDri0o0b88sH5wWk5A9Cx98wJaL/9Jn8Ns9Ay 9K+JVdCm2zrcZXkMfcurhQePbr7EnRPXUzC3SOah7szA1mAyNloT4putmRZJiPaFUwXwYtPiN CG6wMltlbOdhXw9+QNRql/c1bj6/+U7oqNqA/2uhXaQXpUhv/zZID+F6mve8jPDVdb3DzTbsS esYv03rtICqpggRGzhvw8iyBLpmRgXox3tgVHEhyW5g703UBkw9O8vDPkazJxH/bnRtgi03oG s7VUY/aX2Etn+UNhCZx6hdutwjgHTVeRfZPo5ERSibUT73T2K/9OTBsmf8OmLFIcmiMCL7+kM cRVor647ewWhJWJOFfkYBYmOIO6cfox06L3ysJMYR7+31/E/6gDS/zXEt5+TDACErnGatuH+B BDPMeweLeib8plbKPcmW71Qj3grNyABKJSVegxr8cPc24F9xMBzqxDO4GJ+lXfWqzQksfJe1k axsHzirVEEJO4qsf1ippbyhjnDMEZGE73jjsABZFEcj6xnvjDWetg+oWOMJdZisQJVei3i9dL 7k4yNsiR2bdvVMM7XU+VFchizZK1TjCJwgih0wFf96MdAV80RgGHi6yhkmI= X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00009.txt.bz2 --MP_/NM_P6Qy4v62HNJSX5S7Pio_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 1230 Hi all, attached patch fixes a segfault when allocating a coarray of a type that has allocatable components. Before the patch the compiler tried to ref the component to nullify from the coarray's base address and not from its .data component. The proposed patch fixes this by preventing the nullify of the components in the array_allocate() for coarrays, because the components are nullified again afterwards by copying a fully nullified copy of the type to the coarray's data component. There albeit is an alternative to this patch: trans-array.c: 5556+ - tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr, + tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, coarray ? + pointer : se->expr, ref->u.ar.as->rank); The above adds a second nullify to the generated code before the one done the object copy mentioned above. Because I am unsure which patch is best, I propose both. I do favor of course the one without the duplicate nullify as attached. Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for trunk? The patch also applies (with a small delta) to gcc-5 w/o any regressions. Ok for gcc-5-branch? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de --MP_/NM_P6Qy4v62HNJSX5S7Pio_ Content-Type: application/octet-stream; name=pr65795_1.clog Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pr65795_1.clog Content-length: 631 Z2NjL2ZvcnRyYW4vQ2hhbmdlTG9nOgoKMjAxNi0wNC0wMyAgQW5kcmUgVmVo cmVzY2hpbGQgIDx2ZWhyZUBnY2MuZ251Lm9yZz4KCglQUiBmb3J0cmFuLzY1 Nzk1CgkqIHRyYW5zLWFycmF5LmMgKGdmY19hcnJheV9hbGxvY2F0ZSk6IFdo ZW4gdGhlIGFycmF5IGlzIGEgY29hcnJheSwKCWRvIG5vdCBudWxseWZpbmcg aXRzIGFsbG9jYXRhYmxlIGNvbXBvbmVudHMgaW4gYXJyYXlfYWxsb2NhdGUs IGJlY2F1c2UKCXRoZSBudWxsaWZ5IG1pc3NlZCB0aGUgYXJyYXkgcmVmIGFu ZCBudWxsaWZpZXMgdGhlIHdyb25nIGNvbXBvbmVudC4KCUNvc21ldGljcy4K CmdjYy90ZXN0c3VpdGUvQ2hhbmdlTG9nOgoKMjAxNi0wNC0wMyAgQW5kcmUg VmVocmVzY2hpbGQgIDx2ZWhyZUBnY2MuZ251Lm9yZz4KCglQUiBmb3J0cmFu LzY1Nzk1CgkqIGdmb3J0cmFuLmRnL2NvYXJyYXlfYWxsb2NhdGVfNi5mMDg6 IE5ldyB0ZXN0LgoKCg== --MP_/NM_P6Qy4v62HNJSX5S7Pio_ Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=pr65795_1.patch Content-length: 1400 diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index 649b80f..825dfb8 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -5550,8 +5550,8 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, else gfc_add_expr_to_block (&se->pre, set_descriptor); - if ((expr->ts.type == BT_DERIVED) - && expr->ts.u.derived->attr.alloc_comp) + if (expr->ts.type == BT_DERIVED && expr->ts.u.derived->attr.alloc_comp + && !coarray) { tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr, ref->u.ar.as->rank); diff --git a/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08 b/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08 new file mode 100644 index 0000000..8394c30 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08 @@ -0,0 +1,27 @@ +! { dg-do run } +! { dg-options "-fcoarray=single" } + +! Contributed by Tobias Burnus +! Test fix for pr65795. + +implicit none + +type t2 + integer, allocatable :: x +end type t2 + +type t3 + type(t2), allocatable :: caf[:] +end type t3 + +!type(t3), save, target :: c, d +type(t3), target :: c, d +integer :: stat + +allocate(c%caf[*], stat=stat) +end + +! Besides checking that the executable does not crash anymore, check +! that the cause has been remove. +! { dg-final { scan-tree-dump-not "c.caf.x = 0B" "original" } } + --MP_/NM_P6Qy4v62HNJSX5S7Pio_--