[ 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)
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
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
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
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
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
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
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.
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
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
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/
Note that this is still an issue with 3.3.1.
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
*** Bug 20535 has been marked as a duplicate of this bug. ***
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.
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.
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.
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
I have insufficient privileges to close this bug. Please, someone, close it as FIXED. Thanks.
(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.
*** Bug 30916 has been marked as a duplicate of this bug. ***
*** Bug 35214 has been marked as a duplicate of this bug. ***