From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13930 invoked by alias); 10 Jan 2014 17:09:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13875 invoked by uid 48); 10 Jan 2014 17:08:55 -0000 From: "jvdelisle at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/59700] [4.8/4.9 Regression] Misleading/buggy runtime error message: Bad integer for item 0 in list input Date: Fri, 10 Jan 2014 17:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: minor X-Bugzilla-Who: jvdelisle at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01140.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59700 --- Comment #14 from Jerry DeLisle --- The item_count variable serves two purposes. This was done because we were trying to preserve dtp space and ABI compatibility. I dont remember all the details of why. At any rate, when reading logicals we have to scan ahead to confirm a valid read, so we created the infamous line_buffer. The variable item_count related to the line_buffer is just a pointer into the line_buffer, it contains the current position in that scan ahead process. The error messages just need to change and not refer to the item in the read list. Instead, they should refer to the location in the line where the error occurred. 642 dtp->u.p.line_buffer[dtp->u.p.item_count++] = c; is simply getting the next character in the line. We probably could have used some sort of substructure union like u.p.uu.place and u.p.uu.item_count to avoid the confusion. Unrelated to this PR.