GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 9072 - -Wconversion should be split into two distinct flags
Summary: -Wconversion should be split into two distinct flags
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.2.1
: P3 enhancement
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
: 20535 30916 35214 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-12-27 15:36 UTC by 128950
Modified: 2008-02-15 20:50 UTC (History)
11 users (show)

See Also:
Host: i386-linux
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-18 00:36:20


Attachments
split current functionality of Wconversion in two different options (4.29 KB, patch)
2006-07-05 11:15 UTC, Manuel López-Ibáñez
Details | Diff
Adds a new function which detects when a real value can be exactly represented as an integer. (672 bytes, patch)
2006-07-05 11:18 UTC, Manuel López-Ibáñez
Details | Diff
detect implicit conversions where a value may change (2.40 KB, patch)
2006-07-05 11:22 UTC, Manuel López-Ibáñez
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description 128950 2002-12-27 15:36:02 UTC
[ Reported to the Debian BTS as report #128950.
  Please CC 128950@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/128950 ]
	
The -Wconversion option to gcc is documented as doing two things:

------------------------------------------------------------------------
`-Wconversion'
     Warn if a prototype causes a type conversion that is different
     from what would happen to the same argument in the absence of a
     prototype.  This includes conversions of fixed point to floating
     and vice versa, and conversions changing the width or signedness
     of a fixed point argument except when the same as the default
     promotion.

     Also, warn if a negative integer constant expression is implicitly
     converted to an unsigned type.  For example, warn about the
     assignment `x = -1' if `x' is unsigned.  But do not warn about
     explicit casts like `(unsigned) -1'.
------------------------------------------------------------------------

It'd be nice if these two behaviors were two controlled via two
separate flags.  The second behavior would have caught a bug I've been
hunting for hours, while the first behavior is very undesirable to me
(and useless since I also compile with -Wstrict-prototypes).

Release:
3.2.1 (Debian) (Debian unstable)

Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
host: i386-linux
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.2 20021212 (Debian prerelease)
Comment 1 Segher Boessenkool 2002-12-28 17:56:27 UTC
From: Segher Boessenkool <segher@koffie.nl>
To: 128950@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sat, 28 Dec 2002 17:56:27 +0100

 Matthias Klose wrote:
 > 
 > The -Wconversion option to gcc is documented as doing two things:
 > 
 > ------------------------------------------------------------------------
 > `-Wconversion'
 >      Warn if a prototype causes a type conversion that is different
 >      from what would happen to the same argument in the absence of a
 >      prototype.  This includes conversions of fixed point to floating
 >      and vice versa, and conversions changing the width or signedness
 >      of a fixed point argument except when the same as the default
 >      promotion.
 > 
 >      Also, warn if a negative integer constant expression is implicitly
 >      converted to an unsigned type.  For example, warn about the
 >      assignment `x = -1' if `x' is unsigned.  But do not warn about
 >      explicit casts like `(unsigned) -1'.
 > ------------------------------------------------------------------------
 > 
 > It'd be nice if these two behaviors were two controlled via two
 > separate flags.  The second behavior would have caught a bug I've been
 > hunting for hours, while the first behavior is very undesirable to me
 > (and useless since I also compile with -Wstrict-prototypes).
 
 I remember having been annoyed by -Wconversion its behaviour, too.  Maybe
 this patch will do what you want?
 
 
 Segher
 
 
 
 2002-12-28  Segher Boessenkool  <segher@koffie.nl>
 
 	* c-typeck.c (convert_arguments): Don't warn about arguments
 	passed as `float' unless -Wtraditional given.  Add warning
 	to -Wconversion for passing floating point arguments in smaller
 	precision.  Add warning to -Wtraditional for passing integers with
 	different width due to prototype.
 	* doc/invoke.texi (Warning Options): Document this.  Clarify.
 	* doc/trouble.texi (Protoize Caveats): Ditto.
 
 
 
 *** ../../gcc-clean/gcc/c-typeck.c	Fri Dec 27 03:21:39 2002
 --- ./c-typeck.c	Sat Dec 28 16:44:19 2002
 *************** convert_arguments (typelist, values, nam
 *** 1645,1657 ****
   		    {
   		      /* Warn if any argument is passed as `float',
   			 since without a prototype it would be `double'.  */
 ! 		      if (formal_prec == TYPE_PRECISION (float_type_node))
   			warn_for_assignment ("%s as `float' rather than `double' due to prototype", (char *) 0, name, parmnum + 1);
   		    }
   		  /* Detect integer changing in width or signedness.
 ! 		     These warnings are only activated with
   		     -Wconversion, not with -Wtraditional.  */
 ! 		  else if (warn_conversion && INTEGRAL_TYPE_P (type)
   			   && INTEGRAL_TYPE_P (TREE_TYPE (val)))
   		    {
   		      tree would_have_been = default_conversion (val);
 --- 1645,1659 ----
   		    {
   		      /* Warn if any argument is passed as `float',
   			 since without a prototype it would be `double'.  */
 ! 		      if (warn_traditional && formal_prec == TYPE_PRECISION (float_type_node))
   			warn_for_assignment ("%s as `float' rather than `double' due to prototype", (char *) 0, name, parmnum + 1);
 + 		      else if (warn_conversion && TYPE_PRECISION (TREE_TYPE (val)) < formal_prec)
 + 			warn_for_assignment ("%s with smaller precision due to prototype", (char *) 0, name, parmnum + 1);
   		    }
   		  /* Detect integer changing in width or signedness.
 ! 		     The warning for signedness is only activated with
   		     -Wconversion, not with -Wtraditional.  */
 ! 		  else if (INTEGRAL_TYPE_P (type)
   			   && INTEGRAL_TYPE_P (TREE_TYPE (val)))
   		    {
   		      tree would_have_been = default_conversion (val);
 *************** convert_arguments (typelist, values, nam
 *** 1666,1671 ****
 --- 1668,1675 ----
   		      else if (formal_prec != TYPE_PRECISION (type1))
   			warn_for_assignment ("%s with different width due to prototype", (char *) 0, name, parmnum + 1);
   		      else if (TREE_UNSIGNED (type) == TREE_UNSIGNED (type1))
 + 			;
 + 		      else if (!warn_conversion)
   			;
   		      /* Don't complain if the formal parameter type
   			 is an enum, because we can't tell now whether
 *** ../../gcc-clean/gcc/doc/invoke.texi	Fri Dec 27 03:21:40 2002
 --- ./doc/invoke.texi	Sat Dec 28 16:27:54 2002
 *************** traditional C case.
 *** 2600,2610 ****
   
   @item
   Conversions by prototypes between fixed/floating point values and vice
 ! versa.  The absence of these prototypes when compiling with traditional
   C would cause serious problems.  This is a subset of the possible
   conversion warnings, for the full set use @option{-Wconversion}.
   
   @item
   Use of ISO C style function definitions.  This warning intentionally is
   @emph{not} issued for prototype declarations or variadic functions
   because these ISO C features will appear in your code when using
 --- 2600,2616 ----
   
   @item
   Conversions by prototypes between fixed/floating point values and vice
 ! versa, and conversion by prototypes between different width types when
 ! not equal to the default promotions.
 ! The absence of these prototypes when compiling with traditional
   C would cause serious problems.  This is a subset of the possible
   conversion warnings, for the full set use @option{-Wconversion}.
   
   @item
 + Use of @code{float} in prototypes.  Traditional C would pass such
 + parameters as @code{double}, while ISO C does not.
 + 
 + @item
   Use of ISO C style function definitions.  This warning intentionally is
   @emph{not} issued for prototype declarations or variadic functions
   because these ISO C features will appear in your code when using
 *************** this is why we did not make @option{-Wal
 *** 2671,2681 ****
   
   @item -Wconversion
   @opindex Wconversion
 ! Warn if a prototype causes a type conversion that is different from what
 ! would happen to the same argument in the absence of a prototype.  This
 ! includes conversions of fixed point to floating and vice versa, and
 ! conversions changing the width or signedness of a fixed point argument
 ! except when the same as the default promotion.
   
   Also, warn if a negative integer constant expression is implicitly
   converted to an unsigned type.  For example, warn about the assignment
 --- 2677,2687 ----
   
   @item -Wconversion
   @opindex Wconversion
 ! Warn if a prototype causes an implicit type conversion that is different
 ! from the default promotion.  This includes conversions of fixed point to
 ! floating and vice versa, and conversions changing the width or
 ! signedness of a fixed point argument (except when the same as the default
 ! promotion).
   
   Also, warn if a negative integer constant expression is implicitly
   converted to an unsigned type.  For example, warn about the assignment
 *** ../../gcc-clean/gcc/doc/trouble.texi	Mon Sep 16 00:48:05 2002
 --- ./doc/trouble.texi	Sat Dec 28 16:29:53 2002
 *************** without them.
 *** 1110,1117 ****
   
   @opindex Wconversion
   You can find all the places where this problem might occur by compiling
 ! the program with the @option{-Wconversion} option.  It prints a warning
 ! whenever an argument is converted.
   
   @item
   Both conversion programs can be confused if there are macro calls in and
 --- 1110,1117 ----
   
   @opindex Wconversion
   You can find all the places where this problem might occur by compiling
 ! the program with the @option{-Wtraditional -Wconversion} options.  It
 ! prints a warning whenever an argument is converted.
   
   @item
   Both conversion programs can be confused if there are macro calls in and
 
 

Comment 2 Zack Weinberg 2002-12-29 00:37:58 UTC
From: Zack Weinberg <zack@codesourcery.com>
To: Segher Boessenkool <segher@koffie.nl>
Cc: 128950@bugs.debian.org,  gcc-patches@gcc.gnu.org, 
 gcc-gnats@gcc.gnu.org,
	  debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 00:37:58 -0800

 Segher Boessenkool <segher@koffie.nl> writes:
 > Matthias Klose wrote:
 >> It'd be nice if these two behaviors were two controlled via two
 >> separate flags.  The second behavior would have caught a bug I've been
 >> hunting for hours, while the first behavior is very undesirable to me
 >> (and useless since I also compile with -Wstrict-prototypes).
 >
 > I remember having been annoyed by -Wconversion its behaviour, too.  Maybe
 > this patch will do what you want?
 
 I'm very much in favor of making -Wconversion more useful, but is
 there any reason not to shift the argument-type-conversion warnings
 entirely over to -Wtraditional?  Particularly if the warning is
 avoided for prototypes in system headers (so that 'sinf' and the like
 raise no complaints) -- this would, for instance, catch the occasional
 problem we have with arguments of type 'bool' in GCC itself.
 
 Then -Wconversion would be entirely for dubious type conversions on
 assignment.
 
 zw

Comment 3 Zack Weinberg 2002-12-29 01:05:43 UTC
From: Zack Weinberg <zack@codesourcery.com>
To: Segher Boessenkool <segher@koffie.nl>
Cc: 128950@bugs.debian.org,  gcc-patches@gcc.gnu.org, 
 gcc-gnats@gcc.gnu.org,
	  debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 01:05:43 -0800

 Segher Boessenkool <segher@koffie.nl> writes:
 > Zack Weinberg wrote:
 >> 
 >> I'm very much in favor of making -Wconversion more useful, but is
 >> there any reason not to shift the argument-type-conversion warnings
 >> entirely over to -Wtraditional?  Particularly if the warning is
 >> avoided for prototypes in system headers (so that 'sinf' and the like
 >> raise no complaints) -- this would, for instance, catch the occasional
 >> problem we have with arguments of type 'bool' in GCC itself.
 >> 
 >> Then -Wconversion would be entirely for dubious type conversions on
 >> assignment.
 >
 > This is the intended behaviour of my patch, modulo in my opinion passing
 > a "too wide" argument to a function is a dubious assignment, too.
 
 I may have misunderstood the effect of your patch - it seemed like you
 would need to give both -Wconversion and -Wtraditional to get the
 argument-type conversion warnings.  I was suggesting that this should
 happen with just -Wtraditional.
 
 zw

Comment 4 Segher Boessenkool 2002-12-29 09:48:17 UTC
From: Segher Boessenkool <segher@koffie.nl>
To: Zack Weinberg <zack@codesourcery.com>
Cc: 128950@bugs.debian.org, gcc-patches@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 09:48:17 +0100

 Zack Weinberg wrote:
 > 
 > I'm very much in favor of making -Wconversion more useful, but is
 > there any reason not to shift the argument-type-conversion warnings
 > entirely over to -Wtraditional?  Particularly if the warning is
 > avoided for prototypes in system headers (so that 'sinf' and the like
 > raise no complaints) -- this would, for instance, catch the occasional
 > problem we have with arguments of type 'bool' in GCC itself.
 > 
 > Then -Wconversion would be entirely for dubious type conversions on
 > assignment.
 
 This is the intended behaviour of my patch, modulo in my opinion passing
 a "too wide" argument to a function is a dubious assignment, too.
 
 
 Segher

Comment 5 Joseph S. Myers 2002-12-29 11:59:26 UTC
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Segher Boessenkool <segher@koffie.nl>,  <128950@bugs.debian.org>, 
     <gcc-patches@gcc.gnu.org>,  <gcc-gnats@gcc.gnu.org>, 
     <debian-gcc@lists.debian.org>
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 29 Dec 2002 11:59:26 +0000 (GMT)

 On Sun, 29 Dec 2002, Zack Weinberg wrote:
 
 > I'm very much in favor of making -Wconversion more useful, but is
 > there any reason not to shift the argument-type-conversion warnings
 > entirely over to -Wtraditional?  Particularly if the warning is
 > avoided for prototypes in system headers (so that 'sinf' and the like
 > raise no complaints) -- this would, for instance, catch the occasional
 > problem we have with arguments of type 'bool' in GCC itself.
 > 
 > Then -Wconversion would be entirely for dubious type conversions on
 > assignment.
 
 I believe -Wconversion should have exactly the following simple
 specification: warn for any implicit conversion that may change a value.  
 This implies -Wsign-compare, parts of the existing -Wconversion (but not
 those for widening through prototype, etc.), and various cases that there
 isn't currently a warning option for (e.g. assigning a signed int to an
 unsigned int), and would be useful for security auditing.  The same
 intelligence used by -Wsign-compare to avoid warning where problems cannot
 in fact arise (e.g. comparing a constant positive signed integer to an
 unsigned integer) should be used.  Depending on how many warnings this
 generates for reasonable code, there may need to be options to disable
 individual parts (beyond the existing -Wno-sign-compare).
 
 Some parts of this might also be useful in -Wtraditional.
 
 Such a -Wconversion implementation would need thorough testcases (probably
 a few hundred lines, likely rather longer than the rest of the patch) for
 all the different cases of implicit conversion that do warn, or don't warn
 because that type conversion can't change values, or don't warn because
 that conversion is converting a constant (etc.) to the same value.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 
Comment 6 agthorr 2003-02-02 18:34:44 UTC
From: Agthorr <agthorr@barsoom.org>
To: Segher Boessenkool <segher@koffie.nl>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, bangerth@dealii.org,
	128950@bugs.debian.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Sun, 2 Feb 2003 18:34:44 -0800

 On Mon, Feb 03, 2003 at 02:57:26AM +0100, Segher Boessenkool wrote:
 > I didn't intend for it to be reviewed; I just asked if this was
 > the kind of thing that was asked for.  Writing a good patch for
 > this was far more work (esp. writing a testcase that covers
 > all cases).  I have one in the works but as there was not
 > much interest I dropped it on the floor.  If anyone still wants
 > it, better speak up.
 
 Hello,
 
 I'm the person who originally filed this bug.  Your patch does indeed
 seem to do what I want, and I would love to see it (or something
 similar) in a future version of gcc.  I agree that passing a parameter
 to a function should be considered an assignment for -Wconversion
 purposes.  I also agree with Joseph Myers' statement that -Wconversion
 should "warn for any implicit conversion that may change a value".
 
 > True.  But no consensus was reached on whether this was a good idea
 > at all.  As this is mostly tedious, non-fun work and I don't get
 > paid a dime to do it, and no-one cheered me on, it wasn't a priority
 > work for me (and I forgot about it, really).
 
 CHEER!  CHEER!
 
 I apologize for not responding sooner.  I'm a graduate student and
 have been ill on-and-off since mid-December.  This does not make for
 free time for responding to email :)
 
 I realize that this is not a high-priority issue, but I do appreciate
 any effort that goes into making -Wconversion more useful.
 
 -- Agthorr

Comment 7 Wolfgang Bangerth 2003-02-02 22:54:20 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Has been analyzed. Patch is even in the audit trail, but
    seems to have become stuck in gcc's patch acceptance machinery...
    
    W.
Comment 8 Joseph S. Myers 2003-02-03 00:08:30 UTC
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: <bangerth@dealii.org>,  <128950@bugs.debian.org>,  <agthorr@barsoom.org>, 
     <gcc-bugs@gcc.gnu.org>,  <segher@koffie.nl>,  <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 3 Feb 2003 00:08:30 +0000 (GMT)

 On 2 Feb 2003 bangerth@dealii.org wrote:
 
 >     Has been analyzed. Patch is even in the audit trail, but
 >     seems to have become stuck in gcc's patch acceptance machinery...
 
 The patch isn't even one suitable for review, as it lacks testcases.  It
 is established procedure [0] that patches failing to follow the standards
 adequately get ignored.  Even with them, it just papers over particular
 problems rather than actually implementing a sensible consistent
 specification for -Wconversion.
 
 [0] This is very bad procedure; ignoring patches rather than explaining
 what is wrong is far too likely to lose potential contributors.  It is,
 however, what happens; patches not following the standards are more
 tedious to review than ones following the standards, and even many good
 patches following the standards get ignored.  However, this patch was not
 ignored; it received several comments on what ought to be done.
 
 I expect a patch that followed the GNU and GCC coding standards, including
 thorough testcases, and implemented the simple specification I gave for
 -Wconversion (warn for any implicit conversion that may change a value),
 would get reviewed.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Comment 9 Segher Boessenkool 2003-02-03 02:57:26 UTC
From: Segher Boessenkool <segher@koffie.nl>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: bangerth@dealii.org, 128950@bugs.debian.org, agthorr@barsoom.org,
	gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 03 Feb 2003 02:57:26 +0100

 Joseph S. Myers wrote:
 > On 2 Feb 2003 bangerth@dealii.org wrote:
 > 
 > 
 >>    Has been analyzed. Patch is even in the audit trail, but
 >>    seems to have become stuck in gcc's patch acceptance machinery...
 > 
 > 
 > The patch isn't even one suitable for review, as it lacks testcases.  It
 
 I didn't intend for it to be reviewed; I just asked if this was
 the kind of thing that was asked for.  Writing a good patch for
 this was far more work (esp. writing a testcase that covers
 all cases).  I have one in the works but as there was not
 much interest I dropped it on the floor.  If anyone still wants
 it, better speak up.
 
 > [0] This is very bad procedure; ignoring patches rather than explaining
 > what is wrong is far too likely to lose potential contributors.  It is,
 
 Agreed.
 
 > however, what happens; patches not following the standards are more
 > tedious to review than ones following the standards, and even many good
 > patches following the standards get ignored.  However, this patch was not
 > ignored; it received several comments on what ought to be done.
 
 True.  But no consensus was reached on whether this was a good idea
 at all.  As this is mostly tedious, non-fun work and I don't get
 paid a dime to do it, and no-one cheered me on, it wasn't a priority
 work for me (and I forgot about it, really).
 
 > I expect a patch that followed the GNU and GCC coding standards, including
 > thorough testcases, and implemented the simple specification I gave for
 > -Wconversion (warn for any implicit conversion that may change a value),
 > would get reviewed.
 
 I'd like to hear whether this change to the semantics of -Wconversion
 is likely to be accepted, first.
 
 
 Cheers,
 
 Segher
 

Comment 10 Wolfgang Bangerth 2003-02-03 10:31:41 UTC
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: 128950@bugs.debian.org, <agthorr@barsoom.org>, <gcc-bugs@gcc.gnu.org>,
   <segher@koffie.nl>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c/9072: -Wconversion should be split into two distinct flags
Date: Mon, 3 Feb 2003 10:31:41 -0600 (CST)

 On Mon, 3 Feb 2003, Joseph S. Myers wrote:
 > >     Has been analyzed. Patch is even in the audit trail, but
 > >     seems to have become stuck in gcc's patch acceptance machinery...
 > 
 > The patch isn't even one suitable for review, as it lacks testcases.  It
 > is established procedure [0] that patches failing to follow the standards
 > adequately get ignored.
 
 Sorry, don't flame me :-) I am just trying to find ways to get patch 
 submitters and potential reviewers together. 
 
 The bug database is full with reports that have patches attached. If 
 nobody with the ability to judge things takes a look at them, then they 
 will remain open forever. I'm just trying to spark discussion on them. 
 Every once in a while I succeed to get a patch into CVS this way. I think 
 that's better than just letting them sleep.
 
 
 > [0] This is very bad procedure; ignoring patches rather than explaining
 > what is wrong is far too likely to lose potential contributors.
 
 Exactly. If there's someone with little knowledge of gcc processes who 
 manages to find a patch that then never gets any attention, he's not 
 likely to try again next time. If he does get feedback, and be it only 
 that the patch is basically that it is ok but a Changelog entry missing 
 and that the ChangeLog format is described at XYZ, then that'll motivate 
 people. 
 
 I do understand why this is so, but we're doing badly in this field!
 
 Regards
   Wolfgang
 
 PS: Segher - I think the idea of this PR is right, and I would certainly 
 appreciate if you could submit a patch! Thanks!
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
Comment 11 Jay St. Pierre 2003-10-03 15:24:03 UTC
Note that this is still an issue with 3.3.1.
Comment 12 Dieter 2005-03-15 23:22:39 UTC
I observe that gcc -Wconversion generates the exact same warning
message for converting from narrow to wide as it does for converting
from wide to narrow.  Correct me if I'm wrong, but converting from
narrow to wide should always be safe, while converting from wide to
narrow is not safe.  I would like to be able to find the unsafe
conversions without drowning in warning messages about safe conversions.
This would make porting code from ILP32 to LP64 easier.

sopwith cat conversion2.c
#include <stdio.h>

void func1(int);
void func2(long);

int
main(void)
{
  long a;

  func1(5);
  func2(5);  /* line 12 - conversion appears to be harmless? */

  a = 5;
  func1(a); /* line 15 - conversion appears to be harmless? (since the data fits
in 32 bits) */
  func2(a);

  a = 50000000000;
  func1(a); /* line 19 - conversion throws away data */
  func2(a);

  return 0;
}

void
func1(int arg)
{
  printf("func1: arg = %d\n", arg);
}

void
func2(long arg)
{
  printf("func2: arg = %ld\n", arg);
}
sopwith gcc -O2 -Wconversion conversion2.c -o conversion2
conversion2.c: In function `main':
conversion2.c:12: warning: passing arg 1 of `func2' with different width due to
prototype
conversion2.c:15: warning: passing arg 1 of `func1' with different width due to
prototype
conversion2.c:19: warning: passing arg 1 of `func1' with different width due to
prototype
sopwith ./conversion2
func1: arg = 5
func2: arg = 5
func1: arg = 5
func2: arg = 5
func1: arg = -1539607552
func2: arg = 50000000000
sopwith 
Comment 13 Joseph S. Myers 2005-03-19 13:34:45 UTC
*** Bug 20535 has been marked as a duplicate of this bug. ***
Comment 14 Manuel López-Ibáñez 2006-07-05 11:15:57 UTC
Created attachment 11826 [details]
split current functionality of Wconversion in two different options

This patch divides the functionality of Wconversion into two additional warning options Wtradtional-conversion and Wcoercion as part of the Wcoercion project  (
http://gcc.gnu.org/wiki/Wcoercion#Background ). These are added for the sake of clarity (in order to distinguish them from the current Wconversion) and during the development phase and they are not meant to be the final form that the options will take.

Bootstrapped and tested in i686-pc-linux-gnu for trunk revision 115112.
Comment 15 Manuel López-Ibáñez 2006-07-05 11:18:59 UTC
Created attachment 11827 [details]
Adds a new function which detects when a real value can be exactly represented as an integer.

Patch 2of3 http://gcc.gnu.org/wiki/Wcoercion#Background

Adds a new function which detects when a real value can be exactly represented as an integer. This function is needed for the next patch.
Comment 16 Manuel López-Ibáñez 2006-07-05 11:22:09 UTC
Created attachment 11828 [details]
detect implicit conversions where a value may change

patch 3of3 http://gcc.gnu.org/wiki/Wcoercion#Background

Detect implicit conversions where a value may change by narrowing, loss of precision or change of sign when passing arguments and in assignments. It includes testcases.
Comment 17 Manuel López-Ibáñez 2006-11-23 18:39:47 UTC
Subject: Bug 9072

Author: manu
Date: Thu Nov 23 18:39:32 2006
New Revision: 119129

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119129
Log:
2006-11-23  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>

	PR c/9072 
	* c.opt (Wtraditional-conversion): New.
	(Wconversion): Update description.
	* c-typeck.c (convert_arguments): Warnings for prototypes causing
	type conversions different from what would happen in the absence
	of prototype are now handled by Wtraditional-conversion.
	* doc/invoke.texi (Wtraditional-conversion): New.
	(Wconversion): Update description.
	* doc/trouble.texi (Wconversion): Replace Wconversion by
	Wtraditional-conversion.

testsuite/

	PR c/9072 
	* gcc.dg/builtin-protos-1.c: Replace Wconversion by
	Wtraditional-conversion.
	* gcc.dg/overflow-warn-2.c: Likewise.
	* gcc.dg/Wconversion.c: Likewise. Renamed as
	Wtraditional-conversion.c .
	* gcc.dg/Wconversion-2.c: Likewise. Renamed as
	Wtraditional-conversion-2.c .
	* gcc.dg/dfp/Wconversion-2.c: Likewise. Renamed as
	Wtraditional-conversion-2.c 
	* gcc.dg/Wconversion-negative-constants.c: New.


Added:
    trunk/gcc/testsuite/gcc.dg/Wconversion-negative-constants.c
    trunk/gcc/testsuite/gcc.dg/Wtraditional-conversion-2.c
      - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/Wconversion-2.c
    trunk/gcc/testsuite/gcc.dg/Wtraditional-conversion.c
      - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/Wconversion.c
    trunk/gcc/testsuite/gcc.dg/dfp/Wtraditional-conversion-2.c
      - copied, changed from r119128, trunk/gcc/testsuite/gcc.dg/dfp/Wconversion-2.c
Removed:
    trunk/gcc/testsuite/gcc.dg/Wconversion-2.c
    trunk/gcc/testsuite/gcc.dg/Wconversion.c
    trunk/gcc/testsuite/gcc.dg/dfp/Wconversion-2.c
Modified:
    trunk/ChangeLog
    trunk/gcc/ChangeLog
    trunk/gcc/c-typeck.c
    trunk/gcc/c.opt
    trunk/gcc/doc/invoke.texi
    trunk/gcc/doc/trouble.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/builtin-protos-1.c
    trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c

Comment 18 Manuel López-Ibáñez 2006-11-23 18:55:13 UTC
I have insufficient privileges to close this bug. Please, someone, close it as FIXED. Thanks.
Comment 19 Andrew Pinski 2006-11-23 22:51:21 UTC
(In reply to comment #18)
> I have insufficient privileges to close this bug. Please, someone, close it as
> FIXED. Thanks.

You should be able to use your @gcc.gnu.org account to close the bug report.
Comment 20 Manuel López-Ibáñez 2007-02-23 16:09:15 UTC
*** Bug 30916 has been marked as a duplicate of this bug. ***
Comment 21 Andrew Pinski 2008-02-15 20:50:35 UTC
*** Bug 35214 has been marked as a duplicate of this bug. ***