[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- Comment #66 from Daniel Marjamäki --- Thanks! I can appreciate that it's not very simple. Well using a flag is totally acceptable. I don't trust the sanitizer completely but those that do can use the optimisation.
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- Comment #63 from Daniel Marjamäki --- Sorry. I should have mentioned I am a Cppcheck developer in my comment.
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 Daniel Marjamäki changed: What|Removed |Added CC||daniel.marjamaki at gmail dot com --- Comment #62 from Daniel Marjamäki --- > I think using run-time warnings will miss a lot of bugs, compared to compile > time warnings. I fully agree. This current situation is just dangerous. In my humble opinion, the optimisations should be disabled until proper warnings are written. It is no silver bullet but to give a little confidence in your code you can currently use Cppcheck. Cppcheck writes a warning with id invalidTestForOverflow for `int + 100 > int`.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #23 from Daniel Marjamäki --- > If the user expects C to provide tests for "mathematically different", the user has some learning to do. I believe most users can appreciate this. But few users fully understand the integer conversions. I think it's dangerous. :-( > If, as I said, the user uses explicit casts, that's not good. Much better already is to use implicit casts, as I said; and much better than that is to fix the problems at the root (use proper types everywhere), as I said. You are de-facto advocating explicit casts because that is how everybody fixes these. The advice to use proper types is good, in my opinion everybody tries to do that. However as far as I see it's impossible in practice to never mix signed and unsigned types in real projects. > There is no simple fix, so GCC cannot give good guidance. Then people just blindly use explicit casts.. and I dislike that. > Oh, and don't try to insult me please, I'm much too dumb for that. I apologize! I do not want to insult people.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #20 from Daniel Marjamäki ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Daniel Marjamäki from comment #12)
> > So, how would you fix the warning for `f`? Many programmers would "fix" it
> > with a cast.
> >
> > Assuming that `s` and `u` can have arbitrary values, here is the proper
> > code:
> >
> > void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
> >
> > For this correct code, gcc warns.
>
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
>
> which makes it rather explicit what is going on.
>
> Still much better is to not mixed signedness in types at all.
Ping. Your "much better" code does not work. This code prints "equal" on the
screen:
void f1(long s, unsigned long u) {
unsigned long su = s;
if (su == u) printf("equal\n");
}
int main() { f1(-1L, ~0UL); return 0; }
Please try again.
You proved my point somewhat. The programmer gets a warning, the programmer
tries to fix it, the code still has the same bug but the warning has gone away.
However I feel that your fix is much safer than a cast because Cppcheck,
sanitizers, etc can still warn.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #19 from Daniel Marjamäki ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Daniel Marjamäki from comment #12)
> > So, how would you fix the warning for `f`? Many programmers would "fix" it
> > with a cast.
> >
> > Assuming that `s` and `u` can have arbitrary values, here is the proper
> > code:
> >
> > void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
> >
> > For this correct code, gcc warns.
>
> A much better fix is
>
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
>
> which makes it rather explicit what is going on.
>
> Still much better is to not mixed signedness in types at all.
That does not work.
Imagine that you call f1 like so : `f1(-1L, ~0UL)`. If you don't want that g()
is called when the argument values are mathematically different.. like here..
how do you do?
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #12 from Daniel Marjamäki ---
> Do you have examples of perfectly fine code where you get a warning?
So, how would you fix the warning for `f`? Many programmers would "fix" it with
a cast.
Assuming that `s` and `u` can have arbitrary values, here is the proper code:
void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
For this correct code, gcc warns.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #10 from Daniel Marjamäki --- Well I am just a happy gcc user.. if some gcc maintainer thinks this ticket is invalid feel free to close it. I can't expect that everybody will think just like me. :-) As a Cppcheck developer I am dissappointed that all compilers have these warnings. And it ruins our chances to find real bugs with proper analysis.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #9 from Daniel Marjamäki --- Problems; * Code that performs comparison properly gets a warning. * Code where programmer makes a mistake with a cast does not generate a warning. * This warning encourage programmers to cast and when they do make mistakes sometimes there is no warning. Yet you think this is all fine and you are happy about these problems. It's safer to shut off this warning and use better tools to find these issues. The casts will silence i.e. Cppcheck so it's safer to avoid the casts (it can't know if loss of data is by intention or by mistake when you tried to perform a sign-cast).
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
Daniel Marjamäki daniel.marjamaki at gmail dot com changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
--- Comment #7 from Daniel Marjamäki daniel.marjamaki at gmail dot com ---
+1
This is very annoying.
My code is:
unsigned int dostuff();
void f(int x) {
if (x = 0 x dostuff()) {}
}
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
I'd vote for either removing this warning or fixing it.
[Bug c/66773] New: sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Bug ID: 66773
Summary: sign-compare warning for == and != are pretty useless
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.marjamaki at gmail dot com
Target Milestone: ---
I wrote a clang bug report:
https://llvm.org/bugs/show_bug.cgi?id=24036
I recommend that -Wsign-compare is not written for == and != comparisons.
For relational comparisons the sign makes a direct difference, the result of 'a
b' can be different if you do a sign-cast of an operand.
For equality comparisons the sign does not make a direct difference. the result
of 'a == b' is the same even if you sign-cast an operand.
Code example:
void f(signed int a, unsigned int b) {
if (a == b) {}
}
gcc writes this warning:
signcompare.c:3:19: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
In my humble opinion the risk of a real bug here is really low. a has to be
negative. b has to be really large (unlikely). the bitpatterns of a and b has
to match. if the bitpatterns do match it might actually be the intention that
the test should succeed. but if that is not intentional then there is a bug.
The proper fix for this is to write:
if (a = 0 a == b) {}
However I have seen that this is fixed wrongly by a useless cast.
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
In my humble opinion the risk of a bug here is really low.
The proper fix for this is to write:
if (a = 0 a == b) {}
However I have seen that this is fixed by a useless cast.
This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #2 from Daniel Marjamäki daniel.marjamaki at gmail dot com ---
Thanks!
Hmm.. in my humble opinion, when I see the code:
int f(void) { return 0x == -1; }
.. I get the impression that the developer probably wants to test if the
bitpattern 0xfff.. matches -1.
I'd say an arbitrary U32 variable will rarelly have such large values unless
it's representing bitpatterns.. indexes, positions, sizes, etc are not that
large. and if you match a bitpattern against a negative value I'd say the match
is probably expected.
Is it possible to test how much noise this generates? My feeling is that if I
run this on various open source projects I will get lots of pure noise. If I am
right, do you think such noise would be convincing?
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773 --- Comment #4 from Daniel Marjamäki daniel.marjamaki at gmail dot com --- absolutely. there are often bugs in the boundaries. well. I was hoping to get more optimistic response. how about this.. imagine that we wrote a possible division by zero warning for every integer division that uses a non-constant rhs. every warning where rhs can't really be zero would be a false positive. That would be very noisy imo. imho the false positive rate should be similar here. If there is a comparison 'a == -1' and a is unsigned then this warning is useless if a can't be 0x. if a has arbitrary values then statistically it's as likely that a is 0x and 0. So I guess the false positive rate is somewhat similar. Maybe the message can be tweaked? comparison between signed and unsigned integer expressions [-Wsign-compare] I think this message is fine for relational comparisons. A sign-cast is a reasonable solution. For == and != I am afraid the message is somewhat misleading. A sign-cast is not a good solution.
[Bug rtl-optimization/53417] New: multiple assignments can be optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417
Bug #: 53417
Summary: multiple assignments can be optimized
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.marjam...@gmail.com
Hello!
It seems to me that assignments can be optimised more.
Example code:
struct X {
char a;
char b;
char c;
char d;
};
void dummy(struct X *x1);
void f() {
struct X x = {0,0,0,0};
dummy(x);
}
I compile that and look at the assembly code:
gcc -c -O2 test1.c
objdump -d test1.o
In the assembly output the struct is initialized using 4 movb instructions.
I wonder if there can't be an optimizer pass that replace these 4 movb
instructions with a single movl instruction. I assume that would be faster.
[Bug rtl-optimization/53417] optimize multiple movb into a single movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417 Daniel Marjamäki daniel.marjamaki at gmail dot com changed: What|Removed |Added Summary|multiple assignments can be |optimize multiple movb into |optimized |a single movl --- Comment #1 from Daniel Marjamäki daniel.marjamaki at gmail dot com 2012-05-19 17:29:18 UTC --- I changed the title a little. I hope it's more clear
[Bug rtl-optimization/53417] optimize multiple movb into a single movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417 --- Comment #2 from Daniel Marjamäki daniel.marjamaki at gmail dot com 2012-05-19 19:44:13 UTC --- To clarify a little. The objdump output from my code example is: f: 0:48 83 ec 18 sub$0x18,%rsp 4:48 89 e7 mov%rsp,%rdi 7:c6 04 24 00 movb $0x0,(%rsp) b:c6 44 24 01 00 movb $0x0,0x1(%rsp) 10:c6 44 24 02 00 movb $0x0,0x2(%rsp) 15:c6 44 24 03 00 movb $0x0,0x3(%rsp) 1a:e8 00 00 00 00 callq 1f f+0x1f 1f:48 83 c4 18 add$0x18,%rsp 23:c3 retq I guess it would be better ifthose movb was replaced with a movl.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Daniel Marjamäki daniel.marjamaki at gmail dot com changed:
What|Removed |Added
CC||daniel.marjamaki at gmail
||dot com
--- Comment #7 from Daniel Marjamäki daniel.marjamaki at gmail dot com
2011-07-29 13:28:41 UTC ---
In my experience this type of check is really noisy if there is a warning for
every fall through.
I recommend that the warning is written only if the fall through cause
redundant or bad behaviour. such as:
switch (foo) {
case 1: x = y; // - redundant assignment
case 2: x = z;
};
Or:
switch (foo) {
case 1: p = NULL;
case 2: *p = 2;// fall through = NULL pointer dereference
};
