This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH PR Fortran/89286] Intrinsic sign and GNU Extension


On 10 July 2019 17:52:40 CEST, Steve Kargl <sgk@troutmask.apl.washington.edu> 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  <mark.eggleston@codethink.com>
>> 
>>      PR fortran/89286
>>          * check.c (gfc_check_sign): Deleted.

ChangeLog has to be in present tense per convention.

>>      * 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 <mark.eggleston@codethink.com>
>> 
>>      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 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.

At least make them explicit under explicit extension or at least -legacy or whatever its called.

thanks,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]