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 fo
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 && "idiom
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 re
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 condi
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};
// Val
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 behaviou
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 the
On 12/9/20 1:44 PM, Tomar, Sourabh Singh via Gcc wrote:
Hi Folks,
I observed some leaks using valgrind while compiling a sample program using GCC.
==32090== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
Also 3.13 is rather old. 3.16.1 is the current release - not that
On 12/9/20 1:44 PM, Tomar, Sourabh Singh via Gcc wrote:
Hi Folks,
I observed some leaks using valgrind while compiling a sample program using GCC.
Could anyone aware of these details provide any insights to these leaks ?
==32090== Rerun with --leak-check=full to see details of leaked memory
> On 4 Jun 2018, at 16:50, Rainer Orth wrote:
>
> Hi Jonathan,
>
>> On 2 June 2018 at 11:29, Paul Floyd wrote:
>>> Secondly I’ve been doing some work on adding support for C++14 and C++17
>>> sized/aligned new and delete operators.
>>
>> Aren
Hi
I’ve been having 2 issues with GCC head on Solaris. Firstly. The build is
currently broken
gmake[3]: Leaving directory `/export/home/paulf/scratch/gcc/build'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
i386-pc-solaris2.11/amd64/libgcc/avx_resm
13 matches
Mail list logo
