public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: xela@slit.de To: gcc-gnats@gcc.gnu.org Subject: fortran/7487: wrong line numbers after INCLUDE Date: Sun, 04 Aug 2002 08:26:00 -0000 [thread overview] Message-ID: <20020804151757.20915.qmail@sources.redhat.com> (raw) >Number: 7487 >Category: fortran >Synopsis: wrong line numbers after INCLUDE >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Sun Aug 04 08:26:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: xela@slit.de >Release: gcc 2.95.3 (SuSE), gcc 3.0.1 (SuSE), gcc 3.1 (vanilla) >Organization: >Environment: no special hardware type (same on Intel, PPC, ...) >Description: A source file 'main.f' INCLUDEs a file 'second.f' that itself INCLUDEs 'third.f'. The contents of 'main.f' and 'third.f' don't matter much. If 'second.f' has the INCLUDE 'third.f' statement as the last line of the source (or nothing but empty lines follow it), the line numbers are wrong in 'main.f' after the INCLUDE 'second.f' statement. This affects both debugging (GDB) as well as G77 error and warning messages for lines in 'main.f'. It seems that the line numbering after an INCLUDE is generally wrong if there's nothing in the same file after the INCLUDE. However, normally that just means there are no more lines, and it will not show up. If the including file itself is included, however, it does (as above), as lines will follow in the original including file ('main.f'). The error in line numbering depends on the size of the file 'third.f', ie the more lines it has, the worse the error. >How-To-Repeat: Eg use the following source files: (the 'syntax error' line simply causes an error message) --------(main.f)---------------- include 'second.f' end syntax error --------(second.f)-------------- --------(third.f)--------------- ! nothing special, may be empty, ! but the more lines this has, ! the worse the error in line ! numbering... ! ! ! ! ! -------------------------------- Then simply run g77 main.f and you'll get something like main.f:14: syntax error 1 2 Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2) (note '14') even though the file 'main.f' has just 3 lines of code. Similarly, when using '-g', GDB will show the wrong parts of the source code. >Fix: I have not looked at the compiler sources. An intermediate fix is to put some line of code (*not* a comment) after the INCLUDE 'third.f' statement in 'second.f', *AND* another line with at least a space or at least two empty lines after that line of code. In another situation, when using '-ffree-form', even a *comment* did work. So this fix may depend on whether using fix or free form. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-08-04 15:26 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-08-04 8:26 xela [this message] 2002-08-04 12:18 toon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020804151757.20915.qmail@sources.redhat.com \ --to=xela@slit.de \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).