From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90472 invoked by alias); 26 Oct 2015 10:03:21 -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 90455 invoked by uid 89); 26 Oct 2015 10:03:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 26 Oct 2015 10:03:18 +0000 Received: from vepi2 ([92.213.0.123]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjquD-1aNEU60cWn-00braT; Mon, 26 Oct 2015 11:03:15 +0100 Date: Mon, 26 Oct 2015 10:03:00 -0000 From: Andre Vehreschild To: Paul Richard Thomas Cc: Dominique =?UTF-8?B?ZCdIdW1pw6hyZXM=?= , gcc-patches , Mikael Morin , GNU GFortran Subject: Re: [Patch, Fortran, 66927, v2.1] [6 Regression] ICE in gfc_conf_procedure_call Message-ID: <20151026110314.29862118@vepi2> In-Reply-To: <20151025133102.2aa5ebd6@vepi2> References: <20151025133102.2aa5ebd6@vepi2> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/FNlp2nWgbMcpgyWtlmBdUha" X-UI-Out-Filterresults: notjunk:1;V01:K0:rSp+GCKwzms=:sA7lXvytQs3U3DC93wrzAo WrCwl8juDT3lshrJBFplF5fr9Fsc0hA42AF5aBremoq5w2o9btDFoAEx+844WEkAwK3RFc9sq JNRoTOXySlrQMn6l7XWOHGf+AP9lRtc2J8/4C3RHRU032hkV1W/dpDYodSv7cSJ2CaO7k6Mw5 BtMzbmXknJsQjyAdn4TD5YxbpNf+ERxrp+BGDv4Ofzsckgfz5OSxMlXfAc8RmN2tq0qpb8e2n M8p3nuU4tCLTI3khmRpHQDrrAL4PH9BCMGdZLd/qo4qOXD+Pz2A35taO5QI5E1uV3RqgJQAbR N9IxfbBVPjwPhSUA39Jt6OJ3s1lWyTo3SmfdjTPGIV8Q0dZTClJFH+ma66uruI8O3l8eWneNn xvrRmyZga6p8ZZ+OwxSsu321b8KrZ7fDNId45Bn8ART10MqcZ38zc8uiGy9RulFnEVqlzrW7z gLaWua2fItGSpjYU0nznVZkn4kBLS2HHvawah1B/cPDsDbzmGFc99wc3kpZibWHb6qmr9DgsK D6akEzjmUG2l+isKPYrJBcnCMgaguX2dO7+kD7O8F1PjHDJquVT/9ppRXzvwyB1AUk/qrSGZB 0lNUB3zs4of+8BPPud7eWoD6Ng/Tzf4zGpXz1l4+1vky6ye6DqXj+Be2E7uaQQft4i9s3jtKC tfAwCpoXprBeVG/s36gFUP7pIh57PaAhZjhkmPX81ITFSw43BBngOIM83QzG1W5wMGrH2TGai MI64+uLGtAar0M4Sli+XS3zhYreF4vIEBzBVTkUs+i3jJCzUQUrfCWWDsFQ= X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00144.txt.bz2 --MP_/FNlp2nWgbMcpgyWtlmBdUha Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 2477 Hi all, unfortunately did my last patch create a segfault on some 32-bit system. This happens because in the scalarizer the lower bound of the deferred length array of the source=3D expression was taken to be constant zero instead of taking that information from the array descriptor. This patch fixes the segfault by taking the lower -- and to keep it in sync also the upper -- bound from the array descriptor when doing the array assign in the allocate ().=20 Bootstrapped and regtested on x86_64-linux-gnu/f21. Ok for trunk? Sorry for the regression. Regards, Andre On Sun, 25 Oct 2015 13:31:02 +0100 Andre Vehreschild wrote: > Hi Paul, hi all, >=20 > thanks for the review. Submitted as r229294. >=20 > Regards, > Andre >=20 > On Sun, 25 Oct 2015 08:43:24 +0100 > Paul Richard Thomas wrote: >=20 > > Dear Andre, > >=20 > > As far as I can see, the problems with PR57117 are specific to RESHAPE > > and need not affect committing your patch. To my surprise, the > > combination of your patch and mine for PR67171 fixes PR67044 in that > > the ICE no longer occurs. I have to get my head around how to write a > > testcase for it that tests the functionality though! > >=20 > > You can commit this patch to trunk. As I said elsewhere, I will rename > > the testcase for PR67171. > >=20 > > Many thanks for the patch. > >=20 > > Paul > >=20 > > On 23 October 2015 at 09:44, Paul Richard Thomas > > wrote: > > > Dear Andre, > > > > > > I will wait until you fix the problems that Dominique has pointed out. > > > However, if by Sunday afternoon (rain forecast!) you haven't found the > > > time, I will see if I can locate the source of these new problems. > > > > > > With best regards > > > > > > Paul > > > > > > On 7 October 2015 at 19:51, Dominique d'Humi=C3=A8res wrote: > > >> This patch also fixes pr57117 comment 2, the original test and the t= est in comment 3 now give an ICE > > >> > > >> pr57117.f90:82:0: > > >> > > >> allocate(z(9), source=3Dreshape(x, (/ 9 /))) > > >> 1 > > >> internal compiler error: Segmentation fault: 11 > > >> > > >> and pr67044. > > >> > > >> Thanks, > > >> > > >> Dominique > > >> > > > > > > > > > > > > -- > > > Outside of a dog, a book is a man's best friend. Inside of a dog it's > > > too dark to read. > > > > > > Groucho Marx > >=20 > >=20 > >=20 >=20 >=20 --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20 --MP_/FNlp2nWgbMcpgyWtlmBdUha Content-Type: application/octet-stream; name=pr66927_3.clog Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pr66927_3.clog Content-length: 529 Z2NjL2ZvcnRyYW4vQ2hhbmdlTG9nOgoKMjAxNS0xMC0yNiAgQW5kcmUgVmVo cmVzY2hpbGQgIDx2ZWhyZUBnbXguZGU+CgoJKiB0cmFucy1hcnJheS5jIChl dmFsdWF0ZV9ib3VuZCk6IEZvciBkZWZlcnJlZCBsZW5ndGggYXJyYXlzIGdl dCB0aGUKCWJvdW5kcyBkaXJlY3RseSBmcm9tIHRoZSBkZXNjcmlwdG9yLCBp LmUuLCBwcmV2ZW50IHVzaW5nIGNvbnN0YW50Cgl6ZXJvIGxvd2VyIGJvdW5k IGZyb20gdGhlIGdmY19jb252X2FycmF5X2xib3VuZCAoKSByb3V0aW5lLgoJ KGdmY19jb252X3NlY3Rpb25fc3RhcnRzdHJpZGUpOiBIYW5kIGRlZmVycmVk IGFycmF5IHN0YXR1cyB0bwoJZXZhbHVhdGVfYm91bmQgKCkuCgkoZ2ZjX2Nv bnZfZXhwcl9kZXNjcmlwdG9yKTogU2FtZS4KCgo= --MP_/FNlp2nWgbMcpgyWtlmBdUha Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=pr66927_3.patch Content-length: 2416 diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index b726998..f6e980d 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -3809,7 +3809,7 @@ gfc_trans_scalarized_loop_boundary (gfc_loopinfo * loop, stmtblock_t * body) static void evaluate_bound (stmtblock_t *block, tree *bounds, gfc_expr ** values, - tree desc, int dim, bool lbound) + tree desc, int dim, bool lbound, bool deferred) { gfc_se se; gfc_expr * input_val = values[dim]; @@ -3824,6 +3824,17 @@ evaluate_bound (stmtblock_t *block, tree *bounds, gfc_expr ** values, gfc_add_block_to_block (block, &se.pre); *output = se.expr; } + else if (deferred) + { + /* The gfc_conv_array_lbound () routine returns a constant zero for + deferred length arrays, which in the scalarizer wrecks havoc, when + copying to a (newly allocated) one-based array. + Keep returning the actual result in sync for both bounds. */ + *output = lbound ? gfc_conv_descriptor_lbound_get (desc, + gfc_rank_cst[dim]): + gfc_conv_descriptor_ubound_get (desc, + gfc_rank_cst[dim]); + } else { /* No specific bound specified so use the bound of the array. */ @@ -3864,14 +3875,18 @@ gfc_conv_section_startstride (stmtblock_t * block, gfc_ss * ss, int dim) desc = info->descriptor; stride = ar->stride[dim]; + /* Calculate the start of the range. For vector subscripts this will be the range of the vector. */ - evaluate_bound (block, info->start, ar->start, desc, dim, true); + evaluate_bound (block, info->start, ar->start, desc, dim, true, + ar->as->type == AS_DEFERRED); /* Similarly calculate the end. Although this is not used in the scalarizer, it is needed when checking bounds and where the end is an expression with side-effects. */ - evaluate_bound (block, info->end, ar->end, desc, dim, false); + evaluate_bound (block, info->end, ar->end, desc, dim, false, + ar->as->type == AS_DEFERRED); + /* Calculate the stride. */ if (stride == NULL) @@ -6965,7 +6980,8 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr) gcc_assert (n == codim - 1); evaluate_bound (&loop.pre, info->start, ar->start, - info->descriptor, n + ndim, true); + info->descriptor, n + ndim, true, + ar->as->type == AS_DEFERRED); loop.from[n + loop.dimen] = info->start[n + ndim]; } else --MP_/FNlp2nWgbMcpgyWtlmBdUha--