Message ID | f1212d26-dda4-a0e1-e0ae-95b89e3ce61b@gmx.ch |
---|---|
State | New |
Headers | show |
Series | PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1 | expand |
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
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
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
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 >
Hi Manfred, looks good to me. Thanks for the patch! Best regards Thomas
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))