diff mbox series

PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

Message ID f1212d26-dda4-a0e1-e0ae-95b89e3ce61b@gmx.ch
State New
Headers
Series PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1 |

Commit Message

Manfred Schwarb Nov. 2, 2021, 12:57 p.m. UTC 
  Hi,

In addition to the patches of Steve Kargl for PR 91497:
The MIN1 and MAX1 intrinsics do explicit type conversions and should
be silenced too for -Wconversion and -Wconversion-extra.

Adjust testcase to only use *4 and *8 real types, provide a second
testcase for *10 and *16 precisions.

Regtested on Linux x86_64.

Signed-off-by Manfred Schwarb <manfred99@gmx.ch>

Comments

Thomas Koenig Nov. 2, 2021, 1:26 p.m. UTC | #1 
Hi Manfred,

> In addition to the patches of Steve Kargl for PR 91497:
> The MIN1 and MAX1 intrinsics do explicit type conversions and should
> be silenced too for -Wconversion and -Wconversion-extra.
> 
> Adjust testcase to only use *4 and *8 real types, provide a second
> testcase for *10 and *16 precisions.
Two points:

We should modify existing test cases only when necessary, because
modification can impede a regression test.  It is better to create
a new one.

While we do recognize real*4 and real*8 and so on, these are
non-standard extensions, and I would like to avoid to have these
with new test cases.

Instead of real*8, you can use real(8) or double precision.

OK with these changes to the test cases.

Thanks for the patch!

Best regards

	Thomas
Manfred Schwarb Nov. 2, 2021, 2:22 p.m. UTC | #2 
Am 02.11.21 um 14:26 schrieb Thomas Koenig:
> Hi Manfred,
>
>> In addition to the patches of Steve Kargl for PR 91497:
>> The MIN1 and MAX1 intrinsics do explicit type conversions and should
>> be silenced too for -Wconversion and -Wconversion-extra.
>>
>> Adjust testcase to only use *4 and *8 real types, provide a second
>> testcase for *10 and *16 precisions.
> Two points:
>
> We should modify existing test cases only when necessary, because
> modification can impede a regression test.  It is better to create
> a new one.
>

Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards
that Steve had used it as-is. The new testcase is more consistent and more complete.
Sandra got errors on targets without REAL(16) support and requested changes,
so I decided to split it.

So you want me to "split" it in 3 parts?
- existing test as is, only for targets with REAL(16) support
- additional tests incl. complex intrinsics for targets with REAL(16) support
- additional tests incl. complex intrinsics for all targets, only single and double precision

OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, either
it warns or it does not.

> While we do recognize real*4 and real*8 and so on, these are
> non-standard extensions, and I would like to avoid to have these
> with new test cases.
>
> Instead of real*8, you can use real(8) or double precision.
>

Well, double precision is deprecated AFAIK.

> OK with these changes to the test cases.
>
> Thanks for the patch!
>
> Best regards
>
>     Thomas
Thomas Koenig Nov. 2, 2021, 6:39 p.m. UTC | #3 
On 02.11.21 15:22, Manfred Schwarb wrote:
> Am 02.11.21 um 14:26 schrieb Thomas Koenig:
>> Hi Manfred,
>>
>>> In addition to the patches of Steve Kargl for PR 91497:
>>> The MIN1 and MAX1 intrinsics do explicit type conversions and should
>>> be silenced too for -Wconversion and -Wconversion-extra.
>>>
>>> Adjust testcase to only use *4 and *8 real types, provide a second
>>> testcase for *10 and *16 precisions.
>> Two points:
>>
>> We should modify existing test cases only when necessary, because
>> modification can impede a regression test.  It is better to create
>> a new one.
>>
> 
> Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards
> that Steve had used it as-is. The new testcase is more consistent and more complete.
> Sandra got errors on targets without REAL(16) support and requested changes,
> so I decided to split it.
> 
> So you want me to "split" it in 3 parts?
> - existing test as is, only for targets with REAL(16) support
> - additional tests incl. complex intrinsics for targets with REAL(16) support
> - additional tests incl. complex intrinsics for all targets, only single and double precision
> 
> OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, either
> it warns or it does not.

Anything that tests both complex and REAL(16) is fine by me.  I don't
think you need to test the combination of COMPLEX(16), both
codepaths have been seen by that time :-)

Or you can split it three ways, like you wrote above.

>> While we do recognize real*4 and real*8 and so on, these are
>> non-standard extensions, and I would like to avoid to have these
>> with new test cases.
>>
>> Instead of real*8, you can use real(8) or double precision.
>>
> 
> Well, double precision is deprecated AFAIK.

Not in Fortran 2018.

Best regards

	Thomas
Manfred Schwarb Nov. 6, 2021, 3:37 p.m. UTC | #4 
Am 02.11.21 um 19:39 schrieb Thomas Koenig:
> On 02.11.21 15:22, Manfred Schwarb wrote:
>> Am 02.11.21 um 14:26 schrieb Thomas Koenig:
>>> Hi Manfred,
>>>
>>>> In addition to the patches of Steve Kargl for PR 91497:
>>>> The MIN1 and MAX1 intrinsics do explicit type conversions and should
>>>> be silenced too for -Wconversion and -Wconversion-extra.
>>>>
>>>> Adjust testcase to only use *4 and *8 real types, provide a second
>>>> testcase for *10 and *16 precisions.
>>> Two points:
>>>
>>> We should modify existing test cases only when necessary, because
>>> modification can impede a regression test.  It is better to create
>>> a new one.
>>>

I only changed the test case to use dg-require-effective-target and real(n) notation now.

Added a second case without real(10) and real(16), but for all targets, which
covers MIN1 and MAX1 too.


>>
>> Yes, but this was a quick-and-dirty test of mine, and I realized only afterwards
>> that Steve had used it as-is. The new testcase is more consistent and more complete.
>> Sandra got errors on targets without REAL(16) support and requested changes,
>> so I decided to split it.
>>
>> So you want me to "split" it in 3 parts?
>> - existing test as is, only for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for all targets, only single and double precision
>>
>> OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, either
>> it warns or it does not.
>
> Anything that tests both complex and REAL(16) is fine by me.  I don't
> think you need to test the combination of COMPLEX(16), both
> codepaths have been seen by that time :-)
>
> Or you can split it three ways, like you wrote above.
>
>>> While we do recognize real*4 and real*8 and so on, these are
>>> non-standard extensions, and I would like to avoid to have these
>>> with new test cases.
>>>
>>> Instead of real*8, you can use real(8) or double precision.
>>>
>>
>> Well, double precision is deprecated AFAIK.
>
> Not in Fortran 2018.
>
> Best regards
>
> 	Thomas
>
Thomas Koenig Nov. 6, 2021, 6:28 p.m. UTC | #5 
Hi Manfred,

looks good to me.

Thanks for the patch!

Best regards

	Thomas
diff mbox series

Patch

2021-11-02  Manfred Schwarb  <manfred99@gmx.ch>

gcc/fortran/ChangeLog:

	PR fortran/91497
	* simplify.c (simplify_min_max): Disable conversion warnings for
	MIN1 and MAX1.

--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5087,6 +5087,7 @@  min_max_choose (gfc_expr *arg, gfc_expr
 static gfc_expr *
 simplify_min_max (gfc_expr *expr, int sign)
 {
+  int tmp1, tmp2;
   gfc_actual_arglist *arg, *last, *extremum;
   gfc_expr *tmp, *ret;
   const char *fname;
@@ -5131,7 +5132,16 @@  simplify_min_max (gfc_expr *expr, int si
   if ((tmp->ts.type != BT_INTEGER || tmp->ts.kind != gfc_integer_4_kind)
       && (strcmp (fname, "min1") == 0 || strcmp (fname, "max1") == 0))
     {
+      /* Explicit conversion, turn off -Wconversion and -Wconversion-extra
+         warnings.  */
+      tmp1 = warn_conversion;
+      tmp2 = warn_conversion_extra;
+      warn_conversion = warn_conversion_extra = 0;
+
       ret = gfc_convert_constant (tmp, BT_INTEGER, gfc_integer_4_kind);
+
+      warn_conversion = tmp1;
+      warn_conversion_extra = tmp2;
     }
   else if ((tmp->ts.type != BT_REAL || tmp->ts.kind != gfc_real_4_kind)
 	   && (strcmp (fname, "amin0") == 0 || strcmp (fname, "amax0") == 0))