From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 6EE29385842C; Mon,  8 Apr 2024 10:00:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6EE29385842C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712570446;
	bh=wV4Grs+P37tK98kxJAi7rsEoohIslMAFmXG8bdPxPPc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ebSJ1jsolo/2UTQ8xszobImbXwPBTisZOGJAXUMjMCPgT+a+t3TJAz9hn2ieuVrOS
	 WNOjceQaAIxq+UNIQgLXZjHZ0/12gGa80GhNa2kVBKbMZxKI7/Lv6P+isdOAyxWscU
	 nMHbVw256fAN/cMU9CnPQmBUTTMrPAaeSGnM9/RQ=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBsaWJmb3J0cmFuLzExNDMwNF0gWzEzLzE0IFJlZ3Jlc3Np?=
 =?UTF-8?B?b25dIGxpYmdmb3J0cmFuIEkvTyDigJMgYm9ndXMgIlNlbWljb2xvbiBub3Qg?=
 =?UTF-8?B?YWxsb3dlZCBhcyBzZXBhcmF0b3Igd2l0aCBERUNJTUFMPSdwb2ludCci?=
Date: Mon, 08 Apr 2024 10:00:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114304-4-jJsLaOt9Nl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114304

--- Comment #30 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #29)
> Might be for \r\n line endings?

New lines are handled slightly differently =E2=80=93 and \f and \v don't se=
em to be
handled at all.

Comparing the result with ifort/ifx/flang, they handle a bare '\r' (in cont=
rast
to \r\n) at fewer places than gfortran =E2=80=93 albeit from the code it lo=
oks as if a
\r not followed by \n is not handled consistently either.

> I'd keep it for the sake of preserving
> previous behavior.  isspace(3) tests for \f, \n, \r, \t, \v and space
> (but of course all depends on the locale, not sure whether libgfortran
> needs to care for locales)

I have added one example to the testcase, but that seems to be already hand=
led
by the code further below which handles '\r' and '\n' - thus, the patch does
not handle it explicitly.

The Fortran standard does not seem to permit \f, \t, \v at all =E2=80=93 at=
 least I
only found those in the C interop section. The standard does not really def=
ine
what new line actually is, but: "A newline character is a nonblank character
returned by the intrinsic function NEW_LINE." =E2=80=93 This handles differ=
ent
character kinds, but always returns a single character (e.g. \r vs. \n woul=
d be
possible, but not \r\n).

* * *

Patch =E2=80=93 which handles '\t':
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648950.html=