From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9433 invoked by alias); 23 Jan 2010 21:54:29 -0000 Received: (qmail 9398 invoked by uid 48); 23 Jan 2010 21:54:18 -0000 Date: Sat, 23 Jan 2010 21:54:00 -0000 Message-ID: <20100123215418.9397.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bugs at 59A2 dot org" 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 X-SW-Source: 2010-01/txt/msg02808.txt.bz2 ------- Comment #2 from bugs at 59A2 dot org 2010-01-23 21:54 ------- > In other words, fix your code by putting an & in column 72. This is not a solution since it makes it invalid fixed-form source: Error: Syntax error in argument list at (1) Not treating the char-73 & specially makes -Wline-truncation useless in projects containing source that is intended to be both fixed and free-form. I realize the note is not normative, and the spec states "If a source line contains only default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor dependent". However, there are many people formatting code according to note 4.10, especially header code provided by libraries. Choosing fixed or free-form forces a convention on users, and this is really unacceptable. So, in lieu of gfortran addressing this ticket, the only way for a library to not break its users' ability to use -Wline-truncation would be to generate two versions of the header, but this is work to maintain and requires users to update all include statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852