https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #16 from martin.lu...@ohb.de ---
I ran more tests on different systems.
Native Linux installation (Fedora 40) on my laptop:
No issue with valgrind 3.23, g++ 14.2.1, GLIBC 2.41
Stone-age CentOS 7 inside Virtualbox:
No issue with valgrind 3.1
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #15 from martin.lu...@ohb.de ---
(In reply to Mark Wielaard from comment #14)
> Very odd. On an almost identical Fedora 40 setup both ./a.out and valgrind
> -q --tool=massif ./a.out simply return 0 (as they should) for the memchr
> example.
>
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #14 from Mark Wielaard ---
Very odd. On an almost identical Fedora 40 setup both ./a.out and valgrind -q
--tool=massif ./a.out simply return 0 (as they should) for the memchr example.
Could you run with valgrind -v and see which architectur
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #13 from martin.lu...@ohb.de ---
Please ignore my comment about the different output of valgrind. This is
obviously because the first run is with memcheck and the second with massif.
--
You are receiving this mail because:
You are watching
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #12 from martin.lu...@ohb.de ---
Also, not sure if it is relevant, but all tries before were also on a Linux VM,
not native, in VirtualBox 6.50. I run native Windows 10.
CPU is Intel Core i7-9700.
--
You are receiving this mail because:
You
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #11 from martin.lu...@ohb.de ---
I was now able to set up a Fedora 40 VM. Still reproducible:
user@fedora:~$ uname -a
Linux fedora 6.8.5-301.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10
UTC 2024 x86_64 GNU/Linux
user@fedora:~$ valg
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #10 from Paul Floyd ---
With Fedora 40, GCC 14.2.1 and glibc 2.39 I still have no problem with tests2.
objdump --disassemble=main test2
gives me
00401156 :
401156: 55 push %rbp
401157: 48 89
https://bugs.kde.org/show_bug.cgi?id=492549
martin.lu...@ohb.de changed:
What|Removed |Added
Version|3.19.0 |3.23.0
--
You are receiving this mail bec
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #9 from martin.lu...@ohb.de ---
(In reply to Paul Floyd from comment #7)
> Can you build Valgrind from source? It doesn't have any glic dependencies.
I rebuilt it from the Fedora 40/update sources, but it still fails on my
machine if the cha
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #8 from Paul Floyd ---
(In reply to martin.lueck from comment #5)
> Says 0 normally, but 0x1fff000120 (a heap address?) with massif:
String literals like "haystack" generally either get put into rodata (an ELF
segment in the bibary file t
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #7 from Paul Floyd ---
Can you build Valgrind from source? It doesn't have any glic dependencies.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #6 from martin.lu...@ohb.de ---
(In reply to Mark Wielaard from comment #4)
> 3.19.0 is a pretty old version, have you tried with 3.23.0?
> It seems to work fine here (Fedora 40 on x86_64).
Can reproduce the issue with 3.20.0:
#include
int
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #5 from martin.lu...@ohb.de ---
It seems that the behaviour of __builtin_memchr depends on where the source
string is stored. The following two programs have different output with massif,
but otherwise the same output:
Always says 0 (= not f
https://bugs.kde.org/show_bug.cgi?id=492549
Mark Wielaard changed:
What|Removed |Added
CC||m...@klomp.org
--- Comment #4 from Mark Wielaar
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #3 from Paul Floyd ---
On FreeBSD (clang++ with libc++ and g++ with libstdc++) it seems to work OK.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=492549
--- Comment #2 from martin.lu...@ohb.de ---
Looking at basic_string.tcc from
https://github.com/gcc-mirror/gcc/blob/releases/gcc-11/libstdc%2B%2B-v3/include/bits/basic_string.tcc
I found that:
- find(char) uses __gnu_cxx::char_traits::find
- find(const
https://bugs.kde.org/show_bug.cgi?id=492549
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #1 from Paul Floyd
17 matches
Mail list logo
