From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87107 invoked by alias); 23 Jul 2019 00:23:18 -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 87092 invoked by uid 89); 23 Jul 2019 00:23:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=fan, dim X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Jul 2019 00:23:16 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34A9EC028353; Tue, 23 Jul 2019 00:23:15 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-9.rdu2.redhat.com [10.10.112.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id C72A760BEC; Tue, 23 Jul 2019 00:23:13 +0000 (UTC) Subject: Re: [PATCH PR Fortran/89286] Intrinsic sign and GNU Extension To: sgk@troutmask.apl.washington.edu, Mark Eggleston Cc: fortran , gcc-patches References: <892ed9cb-9915-85c9-a3b7-5fe41861d8e8@codethink.co.uk> <20190710155240.GA75088@troutmask.apl.washington.edu> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <42ea4d6e-a045-ca10-5cf0-1b9a48e63d61@redhat.com> Date: Tue, 23 Jul 2019 00:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190710155240.GA75088@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01469.txt.bz2 On 7/10/19 9:52 AM, Steve Kargl wrote: > On Wed, Jul 10, 2019 at 02:50:47PM +0100, Mark Eggleston wrote: >> The attached patch treats the intrinsic SIGN in the same way as MOD and >> DIM as it has the same arguments. >> >> Tested using make -j 8 check-fortran on x86_64 >> >> Conditional compilation using #ifdef __GFC_REAL_16__ has been employed >> where appropriate in the test cases so should be OK on platforms without >> REAL(16). >> >> Change logs: >> >> gcc/fortran >> >>     Mark Eggleston  >> >>     PR fortran/89286 >>         * check.c (gfc_check_sign): Deleted. >>     * intrinsic.c (add_functions): Call add_sym_2 with gfc_check_a_p >>     instead of gfc_check_sign for "sign". >>     * intrinsic.h: Remove declaration of gfc_check_sign. >>     * iresolve.c (gfc_resolve_sign): Check for largest kind of the actual >>     arguments and convert the smaller. Set return kind to be the largest. >>     * simplify.c (gfc_simplify_sign): Use the largest kind of the actual >>     arguments for return >>     * intrinsic.texi: Add GNU extension notes for return value to SIGN. >> >> gcc/testsuite >> >>     Mark Eggleston >> >>     PR fortran/89240 >>     * gfortran.dg/sign_gnu_extension_1.f90: New test. >>     * gfortran.dg/sign_gnu_extension_2.f90: New test. >>     * gfortran.dg/pr78619.f90: Check for "must have" instead of "must be". >> >> If OK please can someone commit as I do not have the privileges. >> > > We really need to get you commit access to the tree. I will handle that directly with Mark. > > I also am not a fan of this type of change. Having spent the > last few days working on fixing BOZ to conform to F2018, I'm > finding all sorts of undocumented "extensions". Personally, > I think gfortran should be moving towards the standard by > deprecating of these types of extensions. I'd tend to agree. The problem is getting real world codebases moved can be exceedingly difficult. At the very least these extensions should be behind suitable flags IMHO. jeff