From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9F40A3858D34; Thu, 2 Jul 2020 16:41:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F40A3858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1593708067; bh=kXYMyESr38+t+JMZ23K8/RB7YcboDS3ttPB05+MvlI4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OkUUDHA6d2wtJtibAqXs2P2SmU4lQu5oArYoFKFKYdGfMylveSODbGeWZQ/dN65c3 eSp6D+QKcqxHSQOeZLEdH0piAJ0/7lZ2dY8yCc0Yq6+ebxKOUlYBC8NXj+ErsC56L/ KP0Vq1YgYoYB4C1IllnbMs7wMUxrKky+khpbjPYU= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52279] Fortran translation issues Date: Thu, 02 Jul 2020 16:41:07 +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.7.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 16:41:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D52279 --- Comment #8 from Steve Kargl -= -- On Thu, Jul 02, 2020 at 03:53:22PM +0000, jakub at gcc dot gnu.org wrote: >=20 > --- Comment #7 from Jakub Jelinek --- > (In reply to kargl from comment #6) > > There is no -fno-allow-invalid-boz option. The option is > > -fallow-invalid-boz. fortan/lang.opt defines the options > > with the RejectNegative annotation. >=20 > Why is it RejectNegative? Because there is nothing to negate. real :: x =3D z'1234' end is an invalid use of a BOZ. gfortran 10.1 will issue an error for this construct (and a number of previously documented and=20 undocumented extensions). Unfortunately, older vesions of gfortran accepted the above without error or warning. When I fixed gfortran's handling of BOZ to conform to the Fortran 2008/2018 standard (i.e., emit an error for the above code), I introduced -fallow-invalid-boz to down-grade the error to a warning, so that older codes will compile.=20=20 gfortran -c a.f90 <-- error gfortran -c -fallow-invalid-boz a.f90 <-- warning gfortran -c -fallow-invalid-boz -fno-allow-invalid-boz a.f90 <-- stupidity > Is there some other option that acts as it negative option? IMO, there is nothing to negative. If you don't want the option, then don't use it. > If it is just a standalone boolean option, it should have a negative, > so that if e.g. one uses -fallow-invalid-boz in $FFLAGS for most of > files in some project, but there is a specific one that shouldn't > allow it, one can just append -fno-allow-invalid-boz for it to cancel > the earlier option. This makes no sense to me. gfortran will accept valid uses of a BOZ without any option. If you add -fallow-invalid-boz to $FFLAGS, then you're simply accepting invalid Fortran (with a warning) in addition to valid Fortran. If a programmer is adding a new file=20 to a project and $FFLAGS includes -fallow-invalid-boz, then programmer will get a warning about invalid code instead of an error. The programmer is informed about the issue, and can make the necessary=20 change, e.g.,=20 real :: x =3D real(z'1234', 4) end in the new file. The point of the option is to allow backwards compatibility, but to be verbose about the invalid Fortran; hopefully, to=20 encourage the programmer to fix their code.=