[Bug c/27136] New: Compile failure with -O -ffast-math
This program, compiled -O -ffast-math, seems to consume infinite stack space
/* -O -ffast-math */
void foo()
{
double x;
for (x = 2; x < 10; x *= x)
;
}
--
Summary: Compile failure with -O -ffast-math
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug preprocessor/27137] New: Without -I- gcc needs another way to defer source dir. search
The -I option inhibits the use of the current file directory as the first search directory for #include "file". This is important for software development which uses partially populated source trees for which the build "looks through" other trees to find the missing pieces. Without -I- gcc should offer something like the IBM xlc -qidirfirst option: Specifies the search order for files included with the '#include' directive. Use -qidirfirst with the -I option. If -qidirfirst is specified, the directories specified by the -I option are searched before the directory where the current file resides. The default is -qnoidirfirst. This is all we need, but over the last 10 years we have instead pushed vendors to support the -I- option. It is sadly ironic that gcc deprecates it. My employer does not use `nmake', but `nmake' has noticed this too: http://www.bell-labs.com/project/nmake/newsletters/issue021.html -- Summary: Without -I- gcc needs another way to defer source dir. search Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trt at acm dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug preprocessor/27137] Without -I- gcc needs another way to defer source dir. search
--- Comment #3 from trt at acm dot org 2006-04-13 14:05 --- The patch for bug 19541 should resolve this, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #7 from trt at acm dot org 2006-05-04 17:21 --- For the tree-vrp.c part of this, perhaps VR_VARYING should be deprecated? I notice there is a single place (set_value_range_to_varying) which assigns VR_VARYING but a couple dozen places that check it. If instead a type-based VR_RANGE were assigned then all those checks could be omitted. And I think vrp would also do a better job. It looks like this is already being considered: http://gcc.gnu.org/ml/gcc/2006-03/msg00790.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug libmudflap/27526] New: mudflap mishandles mmap when compiled -D_FILE_OFFSET_BITS=64
On a SLES9 box, the program below compiles and runs fine when compiled with
-fmudflap -lmudflap (annoying redundancy, that). But when compiled with `large
files' enabled: -fmudflap -lmudflap -D_FILE_OFFSET_BITS=64 the munmap results
in 256 complaints (256*4096 == one megabyte):
mudflap violation 1 (unregister): time=1147206201.931785 ptr=0x4023
size=4096
pc=0x4001ed26
/opt/gcc42t/lib/libmudflap.so.0(__mf_unregister+0x36) [0x4001ed26]
/opt/gcc42t/lib/libmudflap.so.0(munmap+0xf0) [0x40021260]
The reason seems to be the the D_FILE_OFFSET_BITS=64 causes mmap2() to be
called instead, and that seems to be unsupported by mudflap.
#include
#include
#include
int main ()
{
void *storage;
long allocsize = 1024*1024;
storage = mmap(0, allocsize, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
if (storage == MAP_FAILED)
perror("mmap");
munmap(storage, allocsize);
return 0;
}
--
Summary: mudflap mishandles mmap when compiled -
D_FILE_OFFSET_BITS=64
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC build triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27526
[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks
--- Comment #5 from trt at acm dot org 2005-11-15 15:43 --- Since fold() is increasingly used for internal speculative computations, I think it should avoid issuing warnings as false positives are too likely. So perhaps this warning belongs in parser_build_binary_op() in c-typeck.c Similarly for bug 16302 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534
[Bug tree-optimization/31261] Missed tree optimizations: (8 - (x & 7)) & 7
--- Comment #4 from trt at acm dot org 2007-03-21 18:28 --- I think this could be generalized to more operators, e.g. (y | (x & 7)) & 7 ^ (bitwise or, xor, multiply, ...) This optimization could be for "e & M" where e contains a subexpression of the form "t & N" which can (sometimes) be simplified to "t". I suppose that would require walking the tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31261
[Bug c/8268] no compile time array index checking
--- Additional Comments From trt at acm dot org 2005-06-21 15:55 --- Since there is mudflap, it is especially important to avoid false positives. One type occurs in code that never actually executes, e.g. conditional lookup: #define LOOKUP(i) (i < XSIZE ? x[i]: 0) To defend against that, issue the warning only if skip_evaluation is zero. (For a more general fix, see http://gcc.gnu.org/ml/gcc/2004-10/msg00859.html) Another is taking the address one past the last element, e.g. int a[10]; int *aend = &a[10]; // this is perfectly valid, and common -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/23113] New: The -Wunused (value computed is not used) option missed an important case
The following program, compiled with gcc -Wunused, issues no warnings
int foo (void);
void
bar (int *p)
{
*p++; /* perhaps (*p)++ was intended? */
foo () + foo ();
foo () + foo (), foo ();
}
(gcc 2.9.6 issues warnings for all three lines)
I have found *p++; to be a fairly common error.
When sizeof(*p) == 1 or (*p)++ is illegal this is usually a superfluous `*',
but otherwise it is quite often a real bug and so there should be a warning.
I don't care much about things like 3+foo(), but mention them
because of this inoperative comment in c-typeck.c
/* With -Wunused, we should also warn if the left-hand operand does have
side-effects, but computes a value which is not used. For example, in
`foo() + bar(), baz()' the result of the `+' operator is not used,
so we should issue a warning. */
It looks like this code in stmt.c needs yet more tweaking:
maybe_warn:
/* If this is an expression with side effects, don't warn. */
if (TREE_SIDE_EFFECTS (exp))
return 0;
--
Summary: The -Wunused (value computed is not used) option missed
an important case
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23113
[Bug c/23113] The -Wunused (value computed is not used) option missed an important case
--- Additional Comments From trt at acm dot org 2005-07-28 19:27 --- In what sense is this bug "invalid"? The comment I noted in c-typeck.c does not match the current implementation, so one or both of those must be incorrect. Older versions of gcc issued a warning for "*p++;" and so should newer versions. Yes it has a side-effect of increasing p by sizeof(int), but that is not a reason to suppress the warning, it is the reason that the warning should be issued! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23113
[Bug c/23113] [3.4/4.0/4.1 regression] The -Wunused (value computed is not used) option missed an important case
--- Additional Comments From trt at acm dot org 2005-08-01 16:48 --- Thanks! I did a grep of the gcc sources: find . -name '*.c' -print | xargs grep '^[ ]*\*[a-zA-Z_]*++;' and found 3 harmless cases of *p++ (* superfluous, sizeof(*p)==1), but also: ./libobjc/gc.c: *current++; I'm fairly sure that (*current)++; was intended. I'm not familiar with objective C, does it share warning messages with C? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23113
[Bug tree-optimization/15353] [tree-ssa] Merge two "if"s if one subsumes the other.
--- Additional Comments From trt at acm dot org 2005-08-11 15:52 --- I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643 is closely related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug c++/23447] False trigraph warning about literal string.
--- Additional Comments From trt at acm dot org 2005-08-17 20:25 ---
Perhaps the message could be clearer or less ominous, e.g.
c.cc:4:15: warning: "??(" not changed, use -trigraphs to change it to "["
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23447
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Comment #11 from trt at acm dot org 2006-01-24 20:33 --- HP liked this warning suggestion. It will be in their next compiler release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/27007] New: Missed optimization of comparison with 'limited range'
This function always returns 1, but gcc misses the optimization:
int foo(unsigned char x)
{
return (x+1) != 0;
}
fold-const.c converts the comparison to "x != -1", but that's it.
shorten_compare() in c-common.c would optimize it, but it doesn't get called.
fold-const.c has similar code on lines approx. 9307..9454 but is less general
(and uglier) than shorten_compare() and misses this case. tree-vrp.c says x is
varying and doesn't help out either.
An example of this construct is line 527 of libmudflap/mf-runtime.c
if (*optstr+1)
That looks like a buglet, by the way.
--
Summary: Missed optimization of comparison with 'limited range'
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #3 from trt at acm dot org 2006-04-03 19:22 --- Since x is unsigned char, default promotions apply and x+1 will be a signed integer in the range 1..256 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug middle-end/16302] gcc fails to warn about some common logic errors
--- Additional Comments From trt at acm dot org 2005-04-29 20:20 --- The patch given in comment #4 no successfully applies because the warning() function has new initial parameter. Also the fold_buildN() cleanup invalidated (and fixed) the "REAL_CST" part of the patch. Some "speculative folding" is now causing false positives, for which there is a simple fix: suppress warnings when doing such folds. For example *** tree-ssa-loop-niter.c.orig Wed Apr 27 13:48:21 2005 --- tree-ssa-loop-niter.c Wed Apr 27 14:28:59 2005 *** *** 778,780 --- 778,782 notcond = invert_truthvalue (cond); + inhibit_warnings++; e = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, notcond, te); + inhibit_warnings--; if (nonzero_p (e)) People who think warnings belong only in the front-end might balk. I could submit an alternate indirect check for this situation in parser_build_binary_op. It would be tidy, but would no longer warn about non-C glitches such as: libjava/gnu/java/security/x509/X500DistinguishedName.java:447:if (sep != '+' || sep != ',') libjava/java/net/HttpURLConnection.java:555:if (((code / 100) != 4) || ((code / 100) != 5)) libjava/javax/swing/plaf/basic/BasicGraphicsUtils.java:401:if ((underlinedChar >= 0) || (underlinedChar <= 0x)) libjava/javax/security/auth/x500/X500Principal.java:380:if (sep != '+' || sep != ',') Please let me know if there is any interest in a C-only patch. (Or any interest in pursuing this PR.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16302
[Bug c/21380] New: ICE compiling with -O
When compiling the program below, gcc 4.0.0 dies with an ICE.
This also happens with gcc version 4.0.1 20050430 (prerelease)
gcc400 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/opt/gcc400
Thread model: posix
gcc version 4.0.0
command line:
gcc400 -O -c foo.c
program:
void bar (void);
void
foo (int *diff)
{
double deltay = 0.0;
int Stangent = 0;
int mindiff;
int Sflipped = 0;
int i;
int Sturn, Snofit;
Sturn = 1;
if (Sturn)
Stangent = 1;
if (Sturn)
{
Sflipped = 0;
Snofit = 1;
while (Snofit)
{
Snofit = 0;
mindiff = 0;
for (i = 0; i < 4; i++)
mindiff = diff[i];
while (!Snofit && (mindiff < 0.0))
{
deltay = (Stangent ? deltay : 0.0);
if (deltay < 0.0)
Snofit = 1;
for (i = 0; i < 4; i++)
{
}
}
if (Snofit)
if (Sflipped)
break;
}
if (Snofit)
bar ();
}
}
--
Summary: ICE compiling with -O
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
[Bug c/21474] New: missed optimizations when comparing address to NULL
The program below gives some expressions which gcc could, but does not, evaluate
to true. E.g. gcc considers &p->a true, even when a is the first element
of the struct (is this a bug?), but does not consider &p->b[3] to be true.
struct foo {int a, b[10];};
int subr(int i, struct foo *p)
{
int x[10];
#if 0
// gcc folds this
if (&p->a) return 1;
#else
// but not these
if (&p->b[3]) return 1;
if (&x[3] != 0) return 1;
if (&x[i] != 0) return 1; // not sure if this one is safe to fold
#endif
return 0;
}
--
Summary: missed optimizations when comparing address to NULL
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
[Bug middle-end/21474] missed optimizations when comparing address to NULL
--- Additional Comments From trt at acm dot org 2005-05-12 15:08 --- I think it is reasonable to assume the address of an auto variable is non-NULL, and so the address of anything in the local "int x[10];" is non-NULL. So gcc can (and does) fold "if (x) ..." and "if (&x[0]) ..." gcc does not fold "if (&x[3]) ..." due to the the quirk that that it is represented as x+3 and fold does not recognize that to be non-NULL. Now consider "if (&x[i])". The only legal values for i are 0..10, which precludes any value of `i' that might cause &x[i] to be NULL. I suppose if x were a pointer, instead of an array, then we wouldn't know the legal range of values for `i'. But whatever the legal range happens to be would still (I think) preclude values which could cause &x[i] to be NULL. The argument for 'if (&p->b[3])' is more convoluted. Suppose p is non-NULL, then surely this address should be considered non-NULL for basically the same reason that &x[3] above is considered to be non-NULL. Suppose instead that p is NULL, then surely a non-zero offset added to p yields a non-NULL value. That leaves "if (&p->a)" which gcc folds even though a's offset is zero. I think this is arguably a bug. But if no one reports it as a bug ... well I think this one could be argued either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
[Bug c/21550] New: i686 floating point performance 33% slower than gcc 3.4.3
gcc 4.0.0 generates slower code than gcc 3.4.3 for the BLAS "axpy" operation.
(This is no doubt specific to IA32, and perhaps also to the processor version.)
The program is below, here are the timing results:
gcc 3.4.3gcc 4.0.0
Method cpu secs cpu secs
z[]=x[]+alpha*y[] 1.45 1.72
z[]=z[]+alpha*y[] 1.47 2.03
z[]=z[]+y[] 1.44 1.57
The second method is a common special case of the first,
so it is unfortunate that gcc 4 does poorly on it.
The program is in two files to defeat inlining: rzvaxpy.c and zvaxpy.c
and here is the script I used to compile/run them:
for m in METH1 METH2 METH3
do
for cc in gcc343 gcc400
do
$cc -march=i686 -O3 -D$m rzvaxpy.c zvaxpy.c
echo $cc $m `(time a.out)2>&1`
done
done
zvaxpy.c
void
zvaxpy(double *z, double *x, double *y, int n, double alpha)
{
int i;
#if defined(METH1)
for (i = 0; i < n; i++) z[i] = x[i] + alpha * y[i];
#elif defined(METH2)
for (i = 0; i < n; i++) z[i] = z[i] + alpha * y[i];
#else
for (i = 0; i < n; i++) z[i] = z[i] + y[i];
#endif
}
rzvaxpy.c
#include
#define N 100
#define NITER ((300*1000*1000)/N)
double a[100], b[100];
extern void zvaxpy(double *, double *, double *, int, double);
int
main()
{
int i;
double sum;
for (i = 0; i < 100; i++) { a[i] = 0; b[i] = 1; }
for (i = 0; i < NITER; i++) zvaxpy(a,a, b, N, 1.1);
sum = 0; for (i = 0; i < N; i++) sum += a[i];
printf("sum %g\n", sum);
return 0;
}
--
Summary: i686 floating point performance 33% slower than gcc
3.4.3
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21550
[Bug tree-optimization/21643] GCC fails to merge ranges in comparison.
--- Additional Comments From trt at acm dot org 2005-05-18 17:21 --- This is because fold-const.c only does ad-hoc re-association. Here is an example for fold_truthop (approx line 8805) /* Check for the possibility of merging component references. If our lhs is another similar operation, try to merge its rhs with our rhs. Then try to merge our lhs and rhs. */ if (TREE_CODE (arg0) == code && 0 != (tem = fold_truthop (code, type, TREE_OPERAND (arg0, 1), arg1))) return fold_build2 (code, type, TREE_OPERAND (arg0, 0), tem); A similar hack could be done for fold_range_test. (I wrote a helper fold_assoc (f, x, code, type, op1, op2) that does this in a more general way, but it in turn needed `find_assoc_p' and `commutes_p' functions, and handling EXPR_MINUS was onerous. It might be too slow for general use. Basically, it needs a fast way to check for common subexpressions to avoid pointless recursions.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643
[Bug tree-optimization/21643] GCC fails to merge ranges in comparison.
--- Additional Comments From trt at acm dot org 2005-05-18 17:28 ---
Here is a equivalent case that gcc also misses (but beyond scope of
fold-const.c). By the way, since there is a missing final return, can't gcc just
simplify all three functions into "return 1;" :-)
int fish3(unsigned char c)
{
if (c =='"') return 1;
if (c == 0x20) return 1;
if (c < 0x20) return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Additional Comments From trt at acm dot org 2005-06-02 18:40 --- The current warning algorithm is too simple. This would be better: For each function that contains call(s) to setjmp(), compute: ref_nz The set of variables that might possibly be live (referenced) after a setjmp() returns a non-zero value. set_any The set of variables that might possibly be set (defined) after a call to setjmp() returns. Issue a warning for all variables in the intersection of the sets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug middle-end/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!
--- Additional Comments From trt at acm dot org 2005-06-06 15:48 --- I recommend a version with fewer false positives. I've been using a warning like this for years, with zero false positives. The current gcc-4-ified version is: - /* check for comparing string constant with anything besides simple zero */ - if (TREE_CODE_CLASS (code) == tcc_comparison && extra_warnings - && (code1 == STRING_CST) != (code2 == STRING_CST) - && !integer_zerop (arg1.value) && !integer_zerop (arg2.value)) - warning (0, "comparison of pointer with string literal"); An older suggestion is http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00548.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7776
[Bug c/17946] New: wanted: warning for "a && MASK" when "a & MASK" was probably intended
People sometimes code "a && MASK" when they intended "a & MASK". It would be good if gcc issued a warning for suspect cases. -- Summary: wanted: warning for "a && MASK" when "a & MASK" was probably intended Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trt at acm dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Additional Comments From trt at acm dot org 2004-10-12 14:45 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00990.html This patch does not warn about "a && 1" for the reason noted in comment #1. Some mistakes will go unwarned, but it still catches quite a lot. The concern expressed in comment #2 is quite plausible, but I have not found it to be an issue in practice. e.g. A gcc "make bootstrap" never triggers this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Additional Comments From trt at acm dot org 2004-10-12 18:52 --- Given the problem pointed out in http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01013.html I do not see how this patch can be readily made to work. To avoid redundant truthvalue conversion it might be necessary e.g. to change "enum tree_code original_code" to "tree original_value" in c-tree.h with related changes to c-parse.in and c-typeck.c. That might be justifiable for other reasons, but probably not this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Additional Comments From trt at acm dot org 2004-10-14 15:54 --- > a && 4 in their code meaning a != 0 && 4 !=0 That happens, but when it does `a' is not integer type. I use a gcc with this warning on a 35Mloc code base. There are currently 4 warnings, all pointing to real bugs. This is an excellent warning, it just doesn't fit neatly into the gcc front end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Additional Comments From trt at acm dot org 2004-12-08 18:48 --- I should mention there is a hack for the problem noted in comment #5: do the temporary truthvalue conversions with warnings suppressed. That is, change the two instances of tree t = lang_hooks.truthvalue_conversion (default_conversion ($1.value)); to instead be tree t; inhibit_warnings++; t = lang_hooks.truthvalue_conversion (default_conversion ($1.value)); inhibit_warnings--; So, this can be "readily made to work" after all. But ugh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #9 from trt at acm dot org 2007-01-17 18:15 --- I made lvalue_p a global function in my personal gcc. I've proposed a dozen different warnings-related things for gcc, and never made headway on any of them. I'm just a random user and don't know the secret handshake. The people who do seem utterly uninterested in gcc diagnostics. If you, or anyone, would get this patch working and into gcc, I would be delighted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
