[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #27 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe commit r12-5959-g44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe Author: Manfred Schwarb 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #26 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:f1215db08126fbd2d69d971d65611508cf83b4ae commit r12-5958-gf1215db08126fbd2d69d971d65611508cf83b4ae Author: Manfred Schwarb 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #25 from Manfred Schwarb --- 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #24 from Manfred Schwarb --- Sandra, I will look into this. Probably streamlining the patch to only use *4 and *8 is appropriate.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #23 from sandra at gcc dot gnu.org --- Created attachment 51686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51686=edit 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?
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #22 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Oct 5 14:27:26 2019 New Revision: 276626 URL: https://gcc.gnu.org/viewcvs?rev=276626=gcc=rev Log: 2019-10-05 Steven G. Kargl 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
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #21 from kargl at gcc dot gnu.org --- Fixed on trunk. Thanks bug report and extending patch to cover SNGL and DBLE. Note, the committed patch also disables warnings for -Wconversion-extra.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #20 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Oct 3 20:46:26 2019 New Revision: 276532 URL: https://gcc.gnu.org/viewcvs?rev=276532=gcc=rev Log: 2019-10-03 Steven G. Kargl 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 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
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #19 from Manfred Schwarb --- Created attachment 46963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46963=edit 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #18 from Steve Kargl --- On Thu, Sep 12, 2019 at 09:23:54AM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #17 from Manfred Schwarb --- > 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #17 from Manfred Schwarb --- 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #16 from Manfred Schwarb --- Created attachment 46873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46873=edit documentation changes for conversion intrinsics
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #15 from Steve Kargl --- On Thu, Sep 12, 2019 at 12:10:21AM +, 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #14 from Manfred Schwarb --- >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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #13 from Manfred Schwarb --- FWIW, I briefly looked at conversions of complex variables and did not find any similar -Wconversion warnings for a patched compiler.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #12 from Steve Kargl --- On Wed, Sep 11, 2019 at 11:08:52PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #11 from Manfred Schwarb --- > >> !---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".
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #11 from Manfred Schwarb --- >> !---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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #10 from Steve Kargl --- On Wed, Sep 11, 2019 at 02:25:23PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #9 from Manfred Schwarb --- > 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #9 from Manfred Schwarb --- 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]
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #8 from Steve Kargl --- On Tue, Aug 20, 2019 at 07:50:06PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #7 from Manfred Schwarb --- > Hopefully this rings some bells: The warnings happen > only for parameters: Yeah. I know. See the diff I posted.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #7 from Manfred Schwarb --- 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!
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #6 from Steve Kargl --- On Tue, Aug 20, 2019 at 06:58:27PM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #5 from Thomas Koenig --- > (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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #5 from Thomas Koenig --- (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).
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #4 from Steve Kargl ---
On Tue, Aug 20, 2019 at 03:28:29PM +, 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 == _bad_expr)
return _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 == _bad_expr)
return _bad_expr;
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #3 from Steve Kargl --- On Tue, Aug 20, 2019 at 04:12:47PM +, manfred99 at gmx dot ch wrote: > > --- Comment #2 from Manfred Schwarb --- > 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.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 Manfred Schwarb changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Manfred Schwarb --- 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 ...
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- 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.
