[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #9 from Jakub Jelinek --- Testcase that shows this isn't just about cmpq, but also cmpl and cmpw on x86_64: extern int strcmp (const char *, const char *); extern void abort (void); __attribute__((noipa, noinline, noclone)) void foo

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #8 from Martin Liška --- (In reply to jseward from comment #6) > (In reply to Martin Liška from comment #5) > > > > > > That should make it run clean even without using > > > --expensive-definedness-checks=yes. Does it? > > > > Yes

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jseward at acm dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #7 from jseward at acm dot org --- (In reply to Jakub Jelinek from comment #3) > Because, say in the memcmp case, if the first 4 bytes are defined and are > not equal to the first bytes of the other value, then it will be non-equal > r

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jseward at acm dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #6 from jseward at acm dot org --- (In reply to Martin Liška from comment #5) > > > > That should make it run clean even without using > > --expensive-definedness-checks=yes. Does it? > > Yes, as mentioned in https://gcc.gnu.org/bug

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #5 from Martin Liška --- > > That should make it run clean even without using > --expensive-definedness-checks=yes. Does it? Yes, as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9#c2

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jseward at acm dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 jseward at acm dot org changed: What|Removed |Added CC||jseward at acm dot org --- Comme

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Jakub Jelinek --- On the other side, I wonder how many real-world bugs can it find if valgrind has this strict behavior, isn't the most common case of bugs where all of the bytes are uninitialized, or none of them are? Do we w

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #2 from Martin Liška --- Fixed with: $ gcc lib1560.c -O2 && valgrind --expensive-definedness-checks=yes ./a.out ==15329== Memcheck, a memory error detector ==15329== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|

[Bug tree-optimization/88889] [9 Regression] New valgrind warning since r261039

2019-01-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-1-17 CC|