From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103596 invoked by alias); 3 Oct 2017 14:27:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 103576 invoked by uid 89); 3 Oct 2017 14:27:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=comply, argue, enhancing, (unknown) X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qt0-f176.google.com Received: from mail-qt0-f176.google.com (HELO mail-qt0-f176.google.com) (209.85.216.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Oct 2017 14:27:17 +0000 Received: by mail-qt0-f176.google.com with SMTP id a43so7337154qta.0; Tue, 03 Oct 2017 07:27:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IEw8RW4JWwtEi6UD0E91D00zhcoq3MOloQVL5uFGhzk=; b=j4uZ7eVl3ohFCy2vkdRQfqi26/9ZJBjUEBAFrXmALtpEYCvoUcxI8n27Xc1fNkJ7v8 1ljCioL3d3FGrPk8L18fRyVwfuaobkHwHrC50soyvik26y7pPOV9ynCZyiEcglZywNYr BlvlrTaiRaZZtkObmxHQxA/+lhtjac6DmytLjJXnWShkwpPFzHcBM22Mz2aBJIwsl1d+ Z+K61/ltQj60xuOJa12yj7fDnjUACB2I2EHIgViuvwGdJ4t7EF3s2gp0MQalbUS8ekH4 JPeobuPE2kGNvZ5vXaFllT+3gHP5OASBdCI/Qmb2ZiElQvVfhbfAh3PkyOjY8Wa+iAdS 1KBg== X-Gm-Message-State: AMCzsaXTtysPxvl0rqWresH5Ebr9at2uWPYZNzjSmlj9kFtXsWcNc2Gh vXsSpCFv2SC+fQ/ORRKlgoEH7KGy5UMCJ0UcIA8= X-Google-Smtp-Source: AOwi7QBDF8Ai+yvWrUrV3S/p5IoBfjtQkg6ds3U5lLjWjTNuuqaKFa9K622deOdx+wmnE4Xla9V1TXFp/IZZsFUT6Uw= X-Received: by 10.13.235.214 with SMTP id u205mr4167303ywe.349.1507040835927; Tue, 03 Oct 2017 07:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.162.88 with HTTP; Tue, 3 Oct 2017 07:27:15 -0700 (PDT) In-Reply-To: <20171001195825.GA87938@troutmask.apl.washington.edu> References: <20170927193624.GA91517@troutmask.apl.washington.edu> <20170929140847.GA11837@troutmask.apl.washington.edu> <20171001195825.GA87938@troutmask.apl.washington.edu> From: Janus Weil Date: Tue, 03 Oct 2017 14:27:00 -0000 Message-ID: Subject: Re: [PATCH] Fix fortran/81509 To: Steve Kargl Cc: gfortran , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-10/txt/msg00118.txt.bz2 Hi Steve, >> >> In general one can argue about whether or not it's a good idea to use >> >> non-std extensions. But I think gfortran should rather leave the >> >> choice to its users, whether they want to use 'dirty and covenient' >> >> code or have very strict checking. We have nice mechanisms for this, >> >> and I do think we should keep them. >> >> >> > >> > It is undefined behavior. >> >> ... with regards to the F08 standard, which forbids it, yes. I guess >> that is the nature of a "non-standard extension". It can still give a >> meaningful result, after the smaller kind is implicitly converted to >> the larger kind. > > F95 and F03 have > > IAND(I,J) > > Arguments. > > I shall be of type integer. > J shall be of type integer with the same kind type parameter as I. > > and F08 has > > I shall be of type integer or a boz-literal-constant. > J shall be of type integer or a boz-literal-constant. If both I and J > are of type integer, they shall have the same kind type parameter. > I and J shall not both be boz-literal-constants. > > If a user wants to mix the kind type parameters, then the user > can use AND, OR, and XOR. ... which are non-standard, just as differing kinds in IAND. Why would AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view? >> Btw, contrary to your earlier claim, the extension is actually >> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html > > A parenthetical remark hardly counts as documentation. It is pretty much better than nothing I'd say. Lack of documentation is not a good motivation for removing a feature (but rather for enhancing the documentation). >>> I withdraw the patch. >> >> Why? It does fix a rejects-valid bug after all, doesn't it? I >> completely agree with Paul's earlier review that this is good and >> necessary. >> >> All I'm saying is that I don't think it's a good idea to turn the >> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the >> patch is ok for trunk from my side. > > gfortran should encourage users to write standard conforming code. I absolutely fully agree here. But it should not do this by unimplementing non-standard features, but rather by providing a mechanism to let the user choose between * "I want my code to strictly comply with my favorite Fortran standard" and * "I need to use this or that non-standard feature, for this or that reason. I know that Steve doesn't like it, but quite frankly it's not his decision to make." Note that such a mechanism is very nicely provided by the flag "-std=...", which is certainly one of the stronger points of gfortran. https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html > % cat a.f90 > program foo > integer(4) :: i = 4 > integer(8) :: j = 5 > print *, iand(i,j) > end program foo > % gfortran6 -Wall -c a.f90 > % gfortran6 -Wconversion -c a.f90 > % gfortran6 -Wall -Wextra -c a.f90 > % gfortran6 -Wall -Wextra -Wsurprising -c a.f90 > > There is no mechanism available to warn the user of nonstandard code. Of course there is: $ gfortran -std=f2008 a.f90 a.f90:4:17: print *, iand(i,j) 1 Error: GNU Extension: Different type kinds at (1) > Finally, I have neither the time nor energy to debate the merits of > a dubious undocumented bug/feature. I have supplied a patch. An > objection has been raised. I withdraw the patch. If every patch submitter would withdraw his patches after getting a review, gfortran wouldn't be going anywhere I guess. I never claimed that your patch is all bullshit. I told told you one detail I don't like about it, and I think that's my good right (or even my duty) as a reviewer. It's actually very simple to fix, but you already got two OKs, so you can just as well ignore my opinion and commit your patch as posted. Cheers, Janus