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
Am Montag, dem 18.09.2023 um 22:15 +0200 schrieb Paul Floyd via Gcc:
>
> 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
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
Am Montag, dem 18.09.2023 um 19:56 +0200 schrieb Paul Floyd via Gcc:
>
> 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
>
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 Mon, Sep 18, 2023 at 4:49 PM Floyd, Paul via Gcc wrote:
>
> Hi Richard and Jonathan
>
> On 18/09/2023 10:00, Richard Biener wrote:
> > On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc
> > wrote:
> >> Yes, GCC assumes that the reference is bound to a valid object, because C++
> >> requi
Hi Richard and Jonathan
On 18/09/2023 10:00, Richard Biener wrote:
On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc wrote:
Yes, GCC assumes that the reference is bound to a valid object, because C++
requires that to be true. Of course memcheck can't assume that, because one
of its main
On Sep 17 2023, Paul Floyd via Gcc wrote:
> However, Valgrind thinks that these transpositions can't be done when
> there are potentially trapping memory loads like *f.
*f is not doing any pointer dereference. It just reads the _M_payload
member of f.
--
Andreas Schwab, SUSE Labs, sch...@suse.
On Mon, 18 Sept 2023 at 08:23, Jonathan Wakely wrote:
>
>
>
> On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>>
>>
>>
>> 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
On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc wrote:
>
> On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>
> >
> >
> > 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
On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>
>
> 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 c
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,
On Sun, 17 Sept 2023, 20:33 Paul Floyd via Gcc, wrote:
> 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);
>
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
14 matches
Mail list logo
