On 08-04-24 09:19, Matheus Afonso Martins Moreira via Gcc wrote:
+ It's becoming common
Despite being specific to the Linux kernel,
support for it is showing up in other systems.
FreeBSD implements limited support[4] for Linux ABIs.
Windows Subsystem
On 03-04-24 14:32, Martin Uecker via Gcc wrote:
The backdoor was hidden in a complicated autoconf script...
How many uncomplicated autoconf scripts exist in the real world?
A+
Paul
On 18-09-23 22:52, Martin Uecker wrote:
Is the problem that valgrind transforms the code before it then
emulates it and the problem is that during emulation the code
could trap?
Yes, roughly the process is
guest ISA -> IR -> IR transformations -> IR optimizations -> execution
The &&
On 18-09-23 21:09, Martin Uecker wrote:
I do not understand why memcheck cares about the potential trap when
deciding to do the backwards transformation that combines the two
comparisons? Can't you just remove this condition? I assume it
is meant as a filter to only transform cases which
On 18-09-23 16:55, Richard Biener wrote:
What you could do is report the access only on the point of use of
the accessed value? (and disregard when the register holding the
value is re-used)
Hi Richard
Not sure that I follow what you're saying.
memcheck triggers errors like this at
On 17-09-23 22:51, Jonathan Wakely wrote:
Why would it be trapping? It's loading an int64_t, which might be
uninitialised but it can't trap.
In this context I think that Valgrind is considering that any memory
load could trap.
*f on a std::optional is not like dereferencing a pointer,
Hi
I'm looking at a Valgrind issue. Full details here
https://bugs.kde.org/show_bug.cgi?id=472329
This code
void foo(std::optional f) {
std::cout << (f ? *f : 0) << std::endl;
std::set test;
test.emplace(0);
auto it{test.begin()};
while (it != test.end()) {
int64_t b{*it};
//
Hi
the main reason why it looks like a false positive is that I've had
these valgrind warnings ... since probably ever, but it was never
causing issues.
I cannot tell from the sources if there is anything wrong, so I am
better asking here.
Well, that's the nature of undefined
On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
Hello,
from time to time, I come upon a testcase that failed during the automated
runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what warnings are valid and which are false
positives? Is
