From patchwork Sun May 28 23:16:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerry DeLisle X-Patchwork-Id: 767972 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wbbNS447xz9s2G for ; Mon, 29 May 2017 09:16:38 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Z7KPvy3l"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=ci4oxEGdQnMGh3KrMDf8HVtdlf9wLBin0jBIb7MoYUbKWPJuSd ySg4GpeojN3yvq+hFhFzfE4OAP35WbYCtGYtmhQWdEU3Bvom0fqTAs+k2LLy5jzw vowRjdvpx/qVAf5PGNCML2SoSdrCdHtt6/KwHQd95VRHlVMm3JvtspKFI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=BGsE84vC82CG6Rz1vMSCapq8n5E=; b=Z7KPvy3lk8F7MV8FeW9H R8GfZFn5o1HxDvclMOhYIbKtG9O4zFzUeZCtRZ3m3YURfWUIE5TFjv+okcxG9XsX iY9OhmdBBk9UejDIxr8PuY56ssYhOA7TJZGTIgvtOQXZ35NkxALyy0E7s4cEj1gT UAhiMKVCqWBi030+Sq+n2CU= Received: (qmail 104630 invoked by alias); 28 May 2017 23:16:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 104564 invoked by uid 89); 28 May 2017 23:16:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=U*jvdelisle, sk:jvdelis, 2, 4 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mtaout003-public.msg.strl.va.charter.net Received: from mtaout003-public.msg.strl.va.charter.net (HELO mtaout003-public.msg.strl.va.charter.net) (68.114.190.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 May 2017 23:16:16 +0000 Received: from impout005 ([68.114.189.20]) by mtaout003.msg.strl.va.charter.net (InterMail vM.9.00.023.01 201-2473-194) with ESMTP id <20170528231618.UVON7355.mtaout003.msg.strl.va.charter.net@impout005>; Sun, 28 May 2017 18:16:18 -0500 Received: from amda8.localdomain ([76.178.132.41]) by impout005 with charter.net id RzGG1v0090tkpWs01zGHY2; Sun, 28 May 2017 18:16:18 -0500 X-Authority-Analysis: v=2.2 cv=VrVTO6+n c=1 sm=1 tr=0 a=Y8XvaKYZbF3VPrlWiqOmuQ==:117 a=Y8XvaKYZbF3VPrlWiqOmuQ==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=mDV3o1hIAAAA:8 a=zrVvIoSWIsSuQR0AHlQA:9 a=QEXdDO2ut3YA:10 a=C-fMl3qiiAr78zLMYroA:9 a=+jEqtf1s3R9VXZ0wqowq2kgwd+I=:19 a=hquHOILUSkIA:10 a=f3TNgKstUldWk5hqQyEA:9 a=CS4BpTW1uVAA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Auth-id: anZkZWxpc2xlQGNoYXJ0ZXIubmV0 To: "fortran@gcc.gnu.org" Cc: GCC Patches From: Jerry DeLisle Subject: [patch, libgfortran] PR53029 missed optimization in internal read (without implied-do-loop) Message-ID: Date: Sun, 28 May 2017 16:16:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Hi all, The problem here is that we never set the err return to LIBERROR_END in all cases. For the example case we are detecting the EOF condition inside the read_integer procedure and it gets acted on correctly at higher levels in the code. Consequently in the big loop over the array where we call list_formatted_read_scalar, we never returned an error code so we never exited the loop early. The patch tests for the EOF first locally as before, but then returns the error flags set in dtp->common.flags which are set globally in the individual read procedures whene hit_eof is called. Regression tested on x86_64. I have added a test case which will check the execution time of the loop. The previous results of the REAd were correct, just took a long time on large arrays. OK for trunk? Regards, Jerry 2017-05-28 Jerry DeLisle PR libgfortran/35339 * list_read.c.c (list_formatted_read_scala): Set the err return value to the common.flags error values. diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c index 6c00d11b..b6cd6670 100644 --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -2298,11 +2298,16 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p, free_saved (dtp); cleanup: + /* err may have been set above from finish_separator, so if it is set + trigger the hit_eof. The hit_eof will set bits in common.flags. */ if (err == LIBERROR_END) { free_line (dtp); hit_eof (dtp); } + /* Now we check common.flags for any errors that could have occurred in + a READ elsewhere such as in read_integer. */ + err = dtp->common.flags & IOPARM_LIBRETURN_MASK; fbuf_flush_list (dtp->u.p.current_unit, LIST_READING); return err; }