Version: 2.4.0 (using KDE KDE 3.4.1) Installed from: 0Debian testing/unstable Packages Compiler: 3.3 Try -O2, also works with gcc-4.0 OS: Linux Gcc does a single load for the compare statement, causing valgrind to complain about reading uninitialized value. In fact, outcome of compare is determined by initialized bytes, so warning is spurious. This hit me in real code in SDL, which uses a struct { char type; union u { ... } }. asm (gcc-3.3 -O2): test_thing: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax popl %ebp cmpw $513, 4(%eax) sete %al movzbl %al, %eax ret C code: struct thing { /* This ensures the structure is int-aligned. */ int val; char a; char b; /* Uninitialized field */ }; int test_thing(struct thing *thing) { /* Gcc 3.3 (at least) does this in a single compare */ return (thing->a == 1 && thing->b == 2); } int main() { struct thing thing; thing.a = 0; printf("%i\n", test_thing(&thing)); return 0; }
I can't reproduce this. I've tried gcc 4.0.0 on both 32 and 64 bit platforms and both produce code very similar to what you showed but neither valgrind 2.4.0 nor the current valgrind 3.0 SVN code report any problems. Which instruction does valgrind report the problem against? The compare? or the sete?
Neither, of course. It is only when the printf actually uses the resulting value that the warning is triggered. I'll add an attachment containing the x86 asm for to avoid the compiler as a variable.
Created attachment 12031 [details] x86 asm which triggers bogus warning in valgrind.
I can reproduce this now, and I understand the problem. What gcc is doing is correct but rather horrible for valgrind... The problem is that memcheck normally does a quick and dirty handling of EQ/NE comparisons by treating the results as undefined if any part of either argument is undefined. It does have an alternate 'expensive' version of EQ/NE which treats the result as defined if it can find defined bits which would determine the result as in this case. That expensive version of EQ/NE is only used if the code being translated contains certain magic constants - the intention is to recognise and handle inlined string operations which often rely on such trickery. In this case there doesn't look to be anything we could use to trigger the expensive checks. Julian can probably say more, but I suspect this is a case where the advice against running memcheck on optimised code is appropriate.
> That expensive version of EQ/NE is only used if the code being translated > contains certain magic constants - the intention is to recognise and handle > inlined string operations which often rely on such trickery. In this case > there doesn't look to be anything we could use to trigger the expensive > checks. I'd be interested to know if hardwiring the expensive checks always actually makes the problem go away (I'd hope so). It's unfortunate that a handful of rogue cases like this necessitate expensive handling which is just a performance burden for 99.999% of code. I suppose a command-line flag could be added which selects the expensive scheme(s) all the time (there are expensive variants for integer +, -, ==, !=). But I'd prefer not to. As Tom says ... we've never recommended using Memcheck on code optimised at -O2 or above. If you're lucky it may work OK, but making it work well is not a priority. I'd recommend dropping back to -O.
If you want to try hardwiring it then (in the 2.4.0 code) change False to True in the initialisation of bogusLiterals at line 501 on memcheck/mc_translate.c.
Hmm... I've just tried it with the 3.0 code and it doesn't seem to have helped...
If the origin Members still active on this or have an Ticket, MR or PR (as in Invent or on the Kanban), can you insert it to the Bug Report? Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with either Plasma 5.27 (the current LTS version) or Plasma 6.3 (the latest released version). Regards, [Tizen](https://invent.kde.org/tizen)
Valgrind is a guest in the KDE bug tracker but it does not use KDE development processes so please ignore that last comment.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.