--- 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
--- 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
everity: 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
--- 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
--- 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
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
ion: 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 &quo
e
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
ht
--- 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 agai
--- 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 any
--- 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
--- 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
--- 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
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: i6
--- 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 &
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
o: 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
--- 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 &q
--- 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
--- 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, a
--- 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
--- 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
bably 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
31 matches
Mail list logo
