real b double precision a PARAMETER(a=3.1415927d0) b=REAL(a) b=REAL(a, kind=4) end gives a.f:5:13: 5 | b=REAL(a) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] a.f:6:13: 6 | b=REAL(a, kind=4) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] for current trunk (no new regression though). gfortran should not warn about explicit type conversions with REAL(), INT() etc. Otherwise there is no possibility to silence this warning.
Unfortunately, -Wconversion has a problem with false positives. You can, of course, avoid the problem by not using the option.
Of course. But not being able to silence such warnings renders this option rather useless, IMO. I would have expected that explicit castings would have been special-cased in some way... And the manual talks explicitely about implicit conversion: -Wconversion Warn about implicit conversions ...
On Tue, Aug 20, 2019 at 04:12:47PM +0000, manfred99 at gmx dot ch wrote: > > --- Comment #2 from Manfred Schwarb <manfred99 at gmx dot ch> --- > Of course. But not being able to silence such warnings renders > this option rather useless, IMO. Yep. At the top of my Makefile.inc file, which all of my Makefiles pull in to set defaults, I have .ifdef EBUG CFLAGS+= -g -O FFLAGS+= -g -pipe -O -fmax-errors=1 -Werror -Wall -fcheck=all FFLAGS+= -ffpe-trap=invalid .else CFLAGS = -O2 -pipe -Wall -march=native -mtune=native FFLAGS += -O2 -pipe -march=native -mtune=native FFLAGS += -funroll-loops --param max-unroll-times=4 FFLAGS += -ftree-vectorize -Wall .endif # gfortran is too noisy FFLAGS += -Wno-maybe-uninitialized -Wno-conversion -Wno-integer-division These options produce too many false positives. > I would have expected that explicit castings would have been > special-cased in some way... > > And the manual talks explicitely about implicit conversion: > -Wconversion > Warn about implicit conversions ... Improvements to the documentation are encouraged.
On Tue, Aug 20, 2019 at 03:28:29PM +0000, kargl at gcc dot gnu.org wrote: > > --- Comment #1 from kargl at gcc dot gnu.org --- > Unfortunately, -Wconversion has a problem with false positives. > You can, of course, avoid the problem by not using the option. > This diff will silence warnings for explicit conversion using REAL() and INT() for the -Wconversion option. It does not silence warnings for -Wconversion-extra. Index: gcc/fortran/simplify.c =================================================================== --- gcc/fortran/simplify.c (revision 274676) +++ gcc/fortran/simplify.c (working copy) @@ -3572,6 +3572,7 @@ static gfc_expr * simplify_intconv (gfc_expr *e, int kind, const char *name) { gfc_expr *result = NULL; + int tmp; /* Convert BOZ to integer, and return without range checking. */ if (e->ts.type == BT_BOZ) @@ -3585,7 +3586,12 @@ simplify_intconv (gfc_expr *e, int kind, const char *n if (e->expr_type != EXPR_CONSTANT) return NULL; + /* For explicit conversion, turn off -Wconversion warning. Leave the + warning if -Wconversion-extra is used. */ + tmp = warn_conversion; + warn_conversion = 0; result = gfc_convert_constant (e, BT_INTEGER, kind); + warn_conversion = tmp; if (result == &gfc_bad_expr) return &gfc_bad_expr; @@ -6467,7 +6473,7 @@ gfc_expr * gfc_simplify_real (gfc_expr *e, gfc_expr *k) { gfc_expr *result = NULL; - int kind; + int kind, tmp; /* Convert BOZ to real, and return without range checking. */ if (e->ts.type == BT_BOZ) @@ -6495,7 +6501,12 @@ gfc_simplify_real (gfc_expr *e, gfc_expr *k) if (e->expr_type != EXPR_CONSTANT) return NULL; + /* For explicit conversion, turn off -Wconversion warning. Leave the + warning if -Wconversion-extra is used. */ + tmp = warn_conversion; + warn_conversion = 0; result = gfc_convert_constant (e, BT_REAL, kind); + warn_conversion = tmp; if (result == &gfc_bad_expr) return &gfc_bad_expr;
(In reply to Steve Kargl from comment #4) > This diff will silence warnings for explicit conversion > using REAL() and INT() for the -Wconversion option. It > does not silence warnings for -Wconversion-extra. This approcach looks very good. It might make sense to also extend it to -Wconversion-extra. Do you plan to commit? If you do, this patch is OK (we can discuss -Wconversion-extra later).
On Tue, Aug 20, 2019 at 06:58:27PM +0000, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > (In reply to Steve Kargl from comment #4) > > > This diff will silence warnings for explicit conversion > > using REAL() and INT() for the -Wconversion option. It > > does not silence warnings for -Wconversion-extra. > > This approcach looks very good. It might make sense to also extend it > to -Wconversion-extra. > > Do you plan to commit? If you do, this patch is OK (we can discuss > -Wconversion-extra later). > I wasn't going to commit until others had a chance to weigh in. In particular, I wasn't sure what to do with -Wconversion-extra as I haven't looked at the manual to see what "extra" implies.
Hopefully this rings some bells: The warnings happen only for parameters: real b double precision a,c,d PARAMETER(a=3.1415927d0) DATA c /3.1415927d0/ d=3.1415927d0 b=REAL(a) b=REAL(a, kind=4) b=REAL(c) b=REAL(d) end a.f:8:13: 8 | b=REAL(a) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] a.f:9:13: 9 | b=REAL(a, kind=4) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] Thanks for your efforts!
On Tue, Aug 20, 2019 at 07:50:06PM +0000, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #7 from Manfred Schwarb <manfred99 at gmx dot ch> --- > Hopefully this rings some bells: The warnings happen > only for parameters: Yeah. I know. See the diff I posted.
Hi Steve, I tried your patch in comment 4, it is a good starting point. However, SNGL and DBLE still throw warnings: real*4 a,aa real*8 b,bb real*10 c,cc real*16 d integer*2 e,ee integer*4 f,ff integer*8 g,gg PARAMETER(a=3.1415927_4) PARAMETER(b=3.1415927_8) PARAMETER(c=3.1415927_10) PARAMETER(d=3.1415927_16) PARAMETER(e=123_2) PARAMETER(f=123_4) PARAMETER(g=123_8) aa=REAL(b) aa=REAL(c) aa=REAL(d) aa=REAL(e) aa=REAL(f) aa=REAL(g) aa=FLOAT(f) aa=FLOOR(b) aa=FLOOR(c) aa=FLOOR(d) aa=CEILING(b) aa=CEILING(c) aa=CEILING(d) !---unknown but documented type conversions: !!aa=FLOATI(e) !!aa=FLOATJ(f) !!aa=FLOATK(g) !---documentation is wrong for sngl: aa=SNGL(c) aa=SNGL(d) bb=REAL(c, kind=8) bb=REAL(d, kind=8) bb=DBLE(c) bb=DBLE(d) bb=DFLOAT(g) bb=FLOOR(c) bb=FLOOR(d) bb=CEILING(c) bb=CEILING(d) cc=REAL(d, kind=10) cc=FLOOR(d) cc=CEILING(d) aa=AINT(b) aa=ANINT(b) aa=AINT(c) aa=ANINT(c) aa=AINT(d) aa=ANINT(d) bb=DINT(b) bb=DNINT(b) ee=INT(a, kind=2) ee=NINT(a, kind=2) ee=INT(b, kind=2) ee=NINT(b, kind=2) ee=INT(c, kind=2) ee=NINT(c, kind=2) ee=INT(d, kind=2) ee=NINT(d, kind=2) ee=INT(f, kind=2) ee=INT(g, kind=2) ee=IFIX(a) ee=IDINT(b) ee=IDNINT(b) ee=INT2(a) ee=INT2(b) ee=INT2(c) ee=INT2(d) ee=INT2(f) ee=INT2(g) ff=INT(a, kind=4) ff=NINT(a, kind=4) ff=INT(b, kind=4) ff=NINT(b, kind=4) ff=INT(c, kind=4) ff=NINT(c, kind=4) ff=INT(d, kind=4) ff=NINT(d, kind=4) ff=INT(f, kind=4) ff=INT(g, kind=4) ff=IFIX(a) ff=IDINT(b) ff=IDNINT(b) !---LONG not allowed anymore in gfortran 10 (?): !!ff=LONG(a) !!ff=LONG(b) !!ff=LONG(c) !!ff=LONG(d) !!ff=LONG(g) gg=INT(a, kind=8) gg=NINT(a, kind=8) gg=INT(b, kind=8) gg=NINT(b, kind=8) gg=INT(c, kind=8) gg=NINT(c, kind=8) gg=INT(d, kind=8) gg=NINT(d, kind=8) gg=INT(f, kind=8) gg=INT(g, kind=8) gg=IFIX(a) gg=IDINT(b) gg=IDNINT(b) gg=INT8(a) gg=INT8(b) gg=INT8(c) gg=INT8(d) gg=INT8(g) end a.f:34:14: 34 | aa=SNGL(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(4)' at (1) [-Wconversion] a.f:35:14: 35 | aa=SNGL(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(4)' at (1) [-Wconversion] a.f:38:14: 38 | bb=DBLE(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(8)' at (1) [-Wconversion] a.f:39:14: 39 | bb=DBLE(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(8)' at (1) [-Wconversion]
On Wed, Sep 11, 2019 at 02:25:23PM +0000, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #9 from Manfred Schwarb <manfred99 at gmx dot ch> --- > Hi Steve, > > I tried your patch in comment 4, it is a good starting point. > However, SNGL and DBLE still throw warnings: A patch similar to what appears in comment #4 need to be applied to gfc_simplify_dble and gfc_simplify_sngl. > !---unknown but documented type conversions: > !!aa=FLOATI(e) > !!aa=FLOATJ(f) > !!aa=FLOATK(g) The above are under the -fdec option. > !---LONG not allowed anymore in gfortran 10 (?): > !!ff=LONG(a) > !!ff=LONG(b) > !!ff=LONG(c) > !!ff=LONG(d) > !!ff=LONG(g) LONG was removed by by BOZ patch. It was documented to convert its argument to C's 32-bit long type. Not a good thing as long can be 64-bit. Note, SHORT was also removed. Fortunately, LONG and SHORT were in-line conversion, so no change to libgfortran was needed.
>> !---LONG not allowed anymore in gfortran 10 (?): >> !!ff=LONG(a) >> !!ff=LONG(b) >> !!ff=LONG(c) >> !!ff=LONG(d) >> !!ff=LONG(g) > >LONG was removed by by BOZ patch. It was documented >to convert its argument to C's 32-bit long type. Not >a good thing as long can be 64-bit. Note, SHORT was >also removed. Fortunately, LONG and SHORT were in-line >conversion, so no change to libgfortran was needed. Well, the error message is 92 | ff=LONG(a) | 1 Error: 'long' intrinsic subprogram at (1) has been deprecated. Use INT intrinsic subprogram. The message talks about "deprecated", so I assumed I could eliminate this error with "-std=legacy" or something similar. But in fact you have deleted this feature. This is very OK for me, but I find the message a bit confusing.
On Wed, Sep 11, 2019 at 11:08:52PM +0000, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #11 from Manfred Schwarb <manfred99 at gmx dot ch> --- > >> !---LONG not allowed anymore in gfortran 10 (?): > >> !!ff=LONG(a) > >> !!ff=LONG(b) > >> !!ff=LONG(c) > >> !!ff=LONG(d) > >> !!ff=LONG(g) > > > >LONG was removed by by BOZ patch. It was documented > >to convert its argument to C's 32-bit long type. Not > >a good thing as long can be 64-bit. Note, SHORT was > >also removed. Fortunately, LONG and SHORT were in-line > >conversion, so no change to libgfortran was needed. > > > Well, the error message is > 92 | ff=LONG(a) > | 1 > Error: 'long' intrinsic subprogram at (1) has been deprecated. Use INT > intrinsic subprogram. > > The message talks about "deprecated", so I assumed I could eliminate > this error with "-std=legacy" or something similar. But in fact you > have deleted this feature. This is very OK for me, but I find the message > a bit confusing. LONG and SHORT have been removed. There is no fallback via -std=legacy. I suppose I could (or someone who cares) can change the word "deprecated" to "removed".
FWIW, I briefly looked at conversions of complex variables and did not find any similar -Wconversion warnings for a patched compiler.
>FWIW, I briefly looked at conversions of complex variables >and did not find any similar -Wconversion warnings for a patched compiler. Well, I only looked at REAL,REALPART,AIMAG,IMAG,IMAGPART,DIMAG. For CMPLX, there is some warning: complex(4) ww complex(8) xx ww=CMPLX(1.0_8, 1.0_8) ww=CMPLX(1.0_8, 1.0_8, kind=4) ww=COMPLEX(1.0_8, 1.0_8) xx=CMPLX(1.0_10, 1.0_10) xx=CMPLX(1.0_10, 1.0_10, kind=8) xx=COMPLEX(1.0_10, 1.0_10) end c.f:4:15: 4 | ww=CMPLX(1.0_8, 1.0_8) | 1 Warning: Conversion from REAL(8) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] c.f:7:15: 7 | xx=CMPLX(1.0_10, 1.0_10) | 1 Warning: Conversion from REAL(10) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] This seems very reasonable though, no warnings when using an explicit kind statement. So no action needed here, from my point of view.
On Thu, Sep 12, 2019 at 12:10:21AM +0000, manfred99 at gmx dot ch wrote: > > c.f:4:15: > > 4 | ww=CMPLX(1.0_8, 1.0_8) > | 1 > Warning: Conversion from REAL(8) to default-kind COMPLEX(4) at (1) might lose > precision, consider using the KIND argument [-Wconversion] CMPLX() has historical baggage from Fortran 77. By default (ie., without a kind= argument), it will convert whatever the arguments are to default real kind. Most other intrinsic routines obtain the results kind from an argument, e.g., 'AIMAG(Z)' with 'Z' complex(8) will return a REAL(8) value. Note, also the RHS is evaluated without regards to the type of LHS variable, so the warning applies to the result of CMPLX() not from the assignment.
Created attachment 46873 [details] documentation changes for conversion intrinsics
Here is the documentation fallout I mentioned, previous attachment. And probably a lot of @multitable @columnfractions .20 .20 .20 .25 entries should be widened for the last column, as "Fortran 77 and later" and alike does not fit in a normal 80char Terminal, otherwise.
On Thu, Sep 12, 2019 at 09:23:54AM +0000, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #17 from Manfred Schwarb <manfred99 at gmx dot ch> --- > Here is the documentation fallout I mentioned, previous attachment. > > And probably a lot of > @multitable @columnfractions .20 .20 .20 .25 > entries should be widened for the last column, as "Fortran 77 and later" > and alike does not fit in a normal 80char Terminal, otherwise. > Manfred, If you have commit access, then patches that fix-up the gfortran docs are pre-approve. IMHO, only doc patches that may be controversal or were one might be seeking advice on the English/gammar need a review.
Created attachment 46963 [details] extended patch from comment #4 to also cover gfc_simplify_dble and gfc_simplify_sngl Note, I do not have neither commit rights nor assigment. Supresses all warnings of the test in comment #9 and regtests cleanly.
Author: kargl Date: Thu Oct 3 20:46:26 2019 New Revision: 276532 URL: https://gcc.gnu.org/viewcvs?rev=276532&root=gcc&view=rev Log: 2019-10-03 Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/91497 * simplify.c (gfc_simplify_dble, simplify_intconv, gfc_simplify_real, gfc_simplify_sngl): Disable -Wconversion and -Wconversion-extra warnings for explicit conversion of literal constants. 2019-10-03 Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/91497 * gfortran.dg/pr91497.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91497.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk. Thanks bug report and extending patch to cover SNGL and DBLE. Note, the committed patch also disables warnings for -Wconversion-extra.
Author: kargl Date: Sat Oct 5 14:27:26 2019 New Revision: 276626 URL: https://gcc.gnu.org/viewcvs?rev=276626&root=gcc&view=rev Log: 2019-10-05 Steven G. Kargl <kargl@gcc.gnu.org> PR fortran/91497 * gfortran.dg/pr91497.f90: Run on i?86-*-* and x86_64-*-* only. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr91497.f90
Created attachment 51686 [details] add dg-require-effective-target to testcase The new testcase is FAILing on x86 targets configured without REAL*16 support, like so: /path/to/gcc/testsuite/gfortran.dg/pr91497.f90:14:14: Error: Old-style type declaration REAL*16 not supported at (1) /path/to/gcc/testsuite/gfortran.dg/pr91497.f90:21:31: Error: Invalid real kind 16 at (1) compiler exited with status 1 I've got this patch to add some dg-require-effective-target tests, but maybe it would be better to fix the testcase so that it does not depend on target-specific floating-point types? Or add a second testcase that doesn't require all the target restrictions, for broader test coverage on more platforms?
Sandra, I will look into this. Probably streamlining the patch to only use *4 and *8 is appropriate.
Same issue for MAX1 and MIN1: 88 | ff=MAX1(a, a) | 1 Warning: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)' at (1) [-Wconversion] Surprisingly, I could not provoke a warning for AMAX0 and AMIN0. I will prepare a patch.
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>: https://gcc.gnu.org/g:f1215db08126fbd2d69d971d65611508cf83b4ae commit r12-5958-gf1215db08126fbd2d69d971d65611508cf83b4ae Author: Manfred Schwarb <manfred99@gmx.ch> Date: Tue Dec 14 16:28:58 2021 +0100 fortran: Silence conversion warnings for MIN1 and MAX1 gcc/fortran/ChangeLog: PR fortran/91497 * simplify.c (simplify_min_max): Disable conversion warnings for MIN1 and MAX1.
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>: https://gcc.gnu.org/g:44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe commit r12-5959-g44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe Author: Manfred Schwarb <manfred99@gmx.ch> Date: Tue Dec 14 16:30:27 2021 +0100 testsuite: Silence conversion warnings for MIN1 and MAX1 gcc/testsuite/ChangeLog: PR fortran/91497 * gfortran.dg/pr91497.f90: Adjust test to use dg-require-effective-target directive. * gfortran.dg/pr91497_2.f90: New test to cover all targets. Cover MAX1 and MIN1 intrinsics.