public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
@ 2023-12-16 16:39 dcb314 at hotmail dot com
2023-12-16 16:44 ` [Bug target/113045] " pinskia at gcc dot gnu.org
` (27 more replies)
0 siblings, 28 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-16 16:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Bug ID: 113045
Summary: armv7l-unknown-linux-gnueabihf: valgrind error during
build of libcc1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just tried a valgrind build of gcc trunk on my Raspberry PI 3B+.
It said:
echo | /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
-nostdinc -E -dM - | \
sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
sort -u > tmp-macro_list
==9933== Invalid read of size 8
==9933== at 0x151D554: vld1q_u8 (arm_neon.h:10455)
==9933== by 0x151D554: search_line_fast (lex.cc:872)
==9933== by 0x151D554: _cpp_clean_line (lex.cc:960)
==9933== by 0x151DA0F: bool get_fresh_line_impl<false>(cpp_reader*)
(lex.cc:3747)
$ grep -E "^Config|^==[0-9]" mk.out
Configuring in ./libiberty
Configuring in ./fixincludes
Configuring in ./lto-plugin
Configuring in build-armv7l-unknown-linux-gnueabihf/libiberty
Configuring in build-armv7l-unknown-linux-gnueabihf/fixincludes
Configuring in build-armv7l-unknown-linux-gnueabihf/libcpp
Configuring in ./zlib
Configuring in ./libbacktrace
Configuring in ./libcody
Configuring in ./libdecnumber
Configuring in ./c++tools
Configuring in ./libcpp
Configuring in ./gcc
Configuring in ./libcc1
==9933== Invalid read of size 8
==9933== at 0x151D554: vld1q_u8 (arm_neon.h:10455)
==9933== by 0x151D554: search_line_fast (lex.cc:872)
==9933== by 0x151D554: _cpp_clean_line (lex.cc:960)
==9933== by 0x151DA0F: bool get_fresh_line_impl<false>(cpp_reader*)
(lex.cc:3
747)
Configure line is
../trunk/configure --disable-multilib \
--disable-bootstrap \
--enable-checking=valgrind \
--enable-languages=c,c++
And there is some tweeking of the top level Makefile:
sed 's;-O2;-O2 -march=native;' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
@ 2023-12-16 16:44 ` pinskia at gcc dot gnu.org
2023-12-17 17:35 ` dcb314 at hotmail dot com
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-16 16:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This could also be a valgrind issue ...
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
2023-12-16 16:44 ` [Bug target/113045] " pinskia at gcc dot gnu.org
@ 2023-12-17 17:35 ` dcb314 at hotmail dot com
2023-12-17 18:18 ` redi at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-17 17:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
David Binderman <dcb314 at hotmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redi at gcc dot gnu.org
--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
The source code in lex.cc is
/* Align the source pointer. */
misalign = (uintptr_t)s & 15;
p = (const uint8_t *)((uintptr_t)s & -16);
data = vld1q_u8 (p);
git blame has
^d4ba3b369c (Jonathan Wakely 2022-11-01 09:48:41 +0000 869) /* Align the
source pointer. */
^d4ba3b369c (Jonathan Wakely 2022-11-01 09:48:41 +0000 870) misalign =
(uintptr_t)s & 15;
^d4ba3b369c (Jonathan Wakely 2022-11-01 09:48:41 +0000 871) p = (const
uint8_t *)((uintptr_t)s & -16);
^d4ba3b369c (Jonathan Wakely 2022-11-01 09:48:41 +0000 872) data =
vld1q_u8 (p);
Adding author of code for their opinion.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
2023-12-16 16:44 ` [Bug target/113045] " pinskia at gcc dot gnu.org
2023-12-17 17:35 ` dcb314 at hotmail dot com
@ 2023-12-17 18:18 ` redi at gcc dot gnu.org
2023-12-17 18:21 ` redi at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-17 18:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I don't recognise that code, are you sure I wrote it? d4ba3b369c did not touch
that code.
Do you have a shallow clone, which happens to have my d4ba3b369c as the oldest
commit?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (2 preceding siblings ...)
2023-12-17 18:18 ` redi at gcc dot gnu.org
@ 2023-12-17 18:21 ` redi at gcc dot gnu.org
2023-12-17 18:50 ` dcb314 at hotmail dot com
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-17 18:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That's what the ^ on the commit suggests is happening.
You can fix your history with:
git fetch --unshallow
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (3 preceding siblings ...)
2023-12-17 18:21 ` redi at gcc dot gnu.org
@ 2023-12-17 18:50 ` dcb314 at hotmail dot com
2023-12-17 18:57 ` dcb314 at hotmail dot com
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-17 18:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> I don't recognise that code, are you sure I wrote it? d4ba3b369c did not
> touch that code.
No idea. git blame is known to lie from time to time. I am no
expert at it.
> Do you have a shallow clone, which happens to have my d4ba3b369c as the
> oldest commit?
No idea. I know the gcc project is over 30 years old and it is not
feasible for me to download the entire history, it is too large.
I have the last 18 months or so history and that's a whopping
3.8 Gig on it's own.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (4 preceding siblings ...)
2023-12-17 18:50 ` dcb314 at hotmail dot com
@ 2023-12-17 18:57 ` dcb314 at hotmail dot com
2023-12-17 19:55 ` dcb314 at hotmail dot com
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-17 18:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> That's what the ^ on the commit suggests is happening.
Righto.
> You can fix your history with:
> git fetch --unshallow
trunk.year $ git fetch --unshallow
remote: Enumerating objects: 1072084
^C
trunk.year $
It is not practical for me to download more than a million objects.
I think it would be a reasonable git enhancement if it could
handle the last (year, 3 years, 5 years, 10 years) of commits
without having to download 30+ years of commits.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (5 preceding siblings ...)
2023-12-17 18:57 ` dcb314 at hotmail dot com
@ 2023-12-17 19:55 ` dcb314 at hotmail dot com
2023-12-17 20:06 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-17 19:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
I tried:
$ git fetch --shallow-since=1/1/2021
and the blame still has ^ on the front of it.
^abca670596 libcpp/lex.c (Ian Lance Taylor 2020-12-31 11:23:30 -0800 869)
/* Align the source pointer. */
^abca670596 libcpp/lex.c (Ian Lance Taylor 2020-12-31 11:23:30 -0800 870)
misalign = (uintptr_t)s & 15;
^abca670596 libcpp/lex.c (Ian Lance Taylor 2020-12-31 11:23:30 -0800 871)
p = (const uint8_t *)((uintptr_t)s & -16);
^abca670596 libcpp/lex.c (Ian Lance Taylor 2020-12-31 11:23:30 -0800 872)
data = vld1q_u8 (p);
IMHO, most ARM bugs seem to land in the in-tray of Richard Sandiford.
Maybe Richard might recognise the code ?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (6 preceding siblings ...)
2023-12-17 19:55 ` dcb314 at hotmail dot com
@ 2023-12-17 20:06 ` pinskia at gcc dot gnu.org
2023-12-17 20:11 ` pinskia at gcc dot gnu.org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-17 20:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
e75b54a2d932 libcpp/lex.c (Richard Earnshaw 2012-03-22 17:54:55 +0000
869) /* Align the source pointer. */
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (7 preceding siblings ...)
2023-12-17 20:06 ` pinskia at gcc dot gnu.org
@ 2023-12-17 20:11 ` pinskia at gcc dot gnu.org
2023-12-17 21:05 ` redi at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-17 20:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
Last reconfirmed| |2023-12-17
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is almost definitely a valgrind issue.
We start with:
/* Align the source pointer. */
misalign = (uintptr_t)s & 15;
p = (const uint8_t *)((uintptr_t)s & -16);
data = vld1q_u8 (p);
Which all other targets do too.
Basically this is how you realign the pointer and if don't depend on the bytes
that is not in the original pointer, then this is valid.
Does it work correctly without valgrind?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (8 preceding siblings ...)
2023-12-17 20:11 ` pinskia at gcc dot gnu.org
@ 2023-12-17 21:05 ` redi at gcc dot gnu.org
2023-12-17 22:22 ` redi at gcc dot gnu.org
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-17 21:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > I don't recognise that code, are you sure I wrote it? d4ba3b369c did not
> > touch that code.
>
> No idea. git blame is known to lie from time to time. I am no
> expert at it.
It never lies. Here it's telling you the lines in question are present in the
oldest commit in your repo. It's not git's fault that your history stops at
that commit.
You can use https://gcc.gnu.org/git or https://github.com/gcc-mirror/gcc to see
the full history (and check blame for that file).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (9 preceding siblings ...)
2023-12-17 21:05 ` redi at gcc dot gnu.org
@ 2023-12-17 22:22 ` redi at gcc dot gnu.org
2023-12-17 22:25 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-17 22:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #5)
> I have the last 18 months or so history and that's a whopping
> 3.8 Gig on it's own.
I have a full clone with all history and it's only 3.3g, I'm not sure what you
have there.
(In reply to David Binderman from comment #6)
> I think it would be a reasonable git enhancement if it could
> handle the last (year, 3 years, 5 years, 10 years) of commits
> without having to download 30+ years of commits.
Git can already do that fine. You just told it to create a shallow clone with a
year of history, so of course it can't tell you about anything older than that.
If you increase the depth to 3 years, or 10 years, then it will be able to tell
you about that history.
Anyway, if you don't want a full clone that's fine - just realise the
limitations of that and use something different to find who wrote the code:
https://gcc.gnu.org/git/?p=gcc.git;a=blame;f=libcpp/lex.cc;h=273f6b263c8e0f061d643cae9d7f56a22379c773;hb=HEAD
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (10 preceding siblings ...)
2023-12-17 22:22 ` redi at gcc dot gnu.org
@ 2023-12-17 22:25 ` redi at gcc dot gnu.org
2023-12-18 8:18 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-17 22:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Because otherwise I'm going to get blamed for every bug older than 2022-11-01!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (11 preceding siblings ...)
2023-12-17 22:25 ` redi at gcc dot gnu.org
@ 2023-12-18 8:18 ` rguenth at gcc dot gnu.org
2023-12-19 8:23 ` dcb314 at hotmail dot com
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-18 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |arm
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah, I think that's an artifact of using valgrind. But I can't see how
valgrind could be fixed here apart from trying to special-case a bigger
instruction pattern.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (12 preceding siblings ...)
2023-12-18 8:18 ` rguenth at gcc dot gnu.org
@ 2023-12-19 8:23 ` dcb314 at hotmail dot com
2023-12-19 8:28 ` dcb314 at hotmail dot com
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-19 8:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #14 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Andrew Pinski from comment #9)
> Does it work correctly without valgrind?
Yes. No one has yet attempted to reproduce my results.
vld1q_u8 is a 128 bit ARM hardware instruction.
I assume that the requirements for this instruction are
not being met in some way by some data.
Maybe a short string ?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (13 preceding siblings ...)
2023-12-19 8:23 ` dcb314 at hotmail dot com
@ 2023-12-19 8:28 ` dcb314 at hotmail dot com
2023-12-19 9:22 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-19 8:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #15 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jonathan Wakely from comment #12)
> Because otherwise I'm going to get blamed for every bug older than
> 2022-11-01!
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1
My apologies for this. AFAIK sheer fluke git produced your name twice.
I have extended my local history out to 20210101, nearly three years.
That should reduce the size of the problem and I now know where to
get full history.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (14 preceding siblings ...)
2023-12-19 8:28 ` dcb314 at hotmail dot com
@ 2023-12-19 9:22 ` redi at gcc dot gnu.org
2023-12-19 12:58 ` mark at gcc dot gnu.org
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-19 9:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Not sheer fluke, it was the same ^d4ba3b369c commit both times, because that
was the oldest commit in your clone.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (15 preceding siblings ...)
2023-12-19 9:22 ` redi at gcc dot gnu.org
@ 2023-12-19 12:58 ` mark at gcc dot gnu.org
2023-12-19 16:53 ` dcb314 at hotmail dot com
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: mark at gcc dot gnu.org @ 2023-12-19 12:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #17 from Mark Wielaard <mark at gcc dot gnu.org> ---
I am surprised valgrind memcheck doesn't produce more output, normally it would
tell you why & where it found the address invalid. I assume somehow valgrind
memcheck believes it is reading past the end of a data buffer, while the code
assumes this is fine because it will mask off the bits it won't use.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (16 preceding siblings ...)
2023-12-19 12:58 ` mark at gcc dot gnu.org
@ 2023-12-19 16:53 ` dcb314 at hotmail dot com
2023-12-19 17:18 ` mark at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2023-12-19 16:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #18 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Mark Wielaard from comment #17)
> I am surprised valgrind memcheck doesn't produce more output, normally it
> would tell you why & where it found the address invalid.
The valgrind output I gave originally looks to be in the usual valgrind format
to me.
Perhaps you are assuming some other debugging tool like asan or ubsan ?
> I assume somehow
> valgrind memcheck believes it is reading past the end of a data buffer,
> while the code assumes this is fine because it will mask off the bits it
> won't use.
valgrind doesn't normally produce an error for copying around un-initialised
bytes.
However, it will produce an error if those bytes are used in a decision
like an if statement.
Your unconfirmed assumption agrees with mine, though.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (17 preceding siblings ...)
2023-12-19 16:53 ` dcb314 at hotmail dot com
@ 2023-12-19 17:18 ` mark at gcc dot gnu.org
2024-01-02 14:40 ` rearnsha at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: mark at gcc dot gnu.org @ 2023-12-19 17:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #19 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to David Binderman from comment #18)
> (In reply to Mark Wielaard from comment #17)
> > I am surprised valgrind memcheck doesn't produce more output, normally it
> > would tell you why & where it found the address invalid.
>
> The valgrind output I gave originally looks to be in the usual valgrind
> format to me.
> Perhaps you are assuming some other debugging tool like asan or ubsan ?
Normally valgrind adds something like:
Address 0xaaaaaa is x bytes inside a block of size y free'd
please a stacktrace where that block was allocated/freed
In this case I would expect to say something like that the address that is
being access is after a block. Assuming it is indeed not accessible.
The read of 4 bytes is interesting, it seems to mean that valgrind decided to
chop up this read into smaller blocks.
> > I assume somehow
> > valgrind memcheck believes it is reading past the end of a data buffer,
> > while the code assumes this is fine because it will mask off the bits it
> > won't use.
>
> valgrind doesn't normally produce an error for copying around un-initialised
> bytes.
>
> However, it will produce an error if those bytes are used in a decision
> like an if statement.
Or it will produce an error if it is an unaddressible location. Which seems to
be the case here.
I would try to figure out which address exactly it is, what the exact arm/neon
(?) instruction it is that is being executed. How many bytes it is supposed to
read and if that many bytes are actually available.
If this is an overread then you might try --partial-loads-ok=yes (although that
should be the default these days). If that doesn't work then valgrind might
have chopped up the read into smaller blocks, so memcheck cannot see that it is
a larger load and the backend (VEX/priv/guest_arm_toIR.c) might have to be
adjusted.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (18 preceding siblings ...)
2023-12-19 17:18 ` mark at gcc dot gnu.org
@ 2024-01-02 14:40 ` rearnsha at gcc dot gnu.org
2024-01-02 14:49 ` rearnsha at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 14:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rearnsha at gcc dot gnu.org
--- Comment #20 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> This is almost definitely a valgrind issue.
> We start with:
> /* Align the source pointer. */
> misalign = (uintptr_t)s & 15;
> p = (const uint8_t *)((uintptr_t)s & -16);
> data = vld1q_u8 (p);
>
>
> Which all other targets do too.
>
> Basically this is how you realign the pointer and if don't depend on the
> bytes that is not in the original pointer, then this is valid.
>
> Does it work correctly without valgrind?
Yes, for the first fetch, we align down to a 16-byte boundary and fetch the
full 16 bytes. We then mask off the bytes that are before the real start of
the buffer so that they cannot affect the result. So the code is safe, but
valgrind has no real way of knowing this.
Tricks like this wouldn't work with capability pointers, but we're not
concerned about that here; even MTE (on aarch64) would be ok because the
alignment used matches the tag granule size.
So I'm pretty sure this is a false positive. But perhaps we should just
disable the vectorized scanning when valgrind checking is enabled.
Note that glibc implementations of str* functions can perform a similar trick,
but perhaps valgrind has special knowledge of such cases.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (19 preceding siblings ...)
2024-01-02 14:40 ` rearnsha at gcc dot gnu.org
@ 2024-01-02 14:49 ` rearnsha at gcc dot gnu.org
2024-01-02 15:05 ` dcb314 at hotmail dot com
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 14:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #21 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
FTR it was this patch that added this code. So 2012!
commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
Author: Richard Earnshaw <rearnsha@arm.com>
Date: Thu Mar 22 17:54:55 2012 +0000
* lex.c (search_line_fast): Provide Neon-optimized version for ARM.
From-SVN: r185702
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index 97177e89916..133620b3b70 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,7 @@
+2012-03-22 Richard Earnshaw <rearnsha@arm.com>
+
+ * lex.c (search_line_fast): Provide Neon-optimized version for ARM.
+
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (20 preceding siblings ...)
2024-01-02 14:49 ` rearnsha at gcc dot gnu.org
@ 2024-01-02 15:05 ` dcb314 at hotmail dot com
2024-01-02 15:14 ` schwab@linux-m68k.org
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dcb314 at hotmail dot com @ 2024-01-02 15:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #22 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Richard Earnshaw from comment #21)
> commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
> Author: Richard Earnshaw <rearnsha@arm.com>
> Date: Thu Mar 22 17:54:55 2012 +0000
>
> * lex.c (search_line_fast): Provide Neon-optimized version for ARM.
Is the optimization still worthwhile some 12 years later ?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (21 preceding siblings ...)
2024-01-02 15:05 ` dcb314 at hotmail dot com
@ 2024-01-02 15:14 ` schwab@linux-m68k.org
2024-01-02 15:18 ` rearnsha at gcc dot gnu.org
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: schwab@linux-m68k.org @ 2024-01-02 15:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #23 from Andreas Schwab <schwab@linux-m68k.org> ---
valgrind replaces str/mem functions with its own versions so that it can do
better checking and avoid false positives.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (22 preceding siblings ...)
2024-01-02 15:14 ` schwab@linux-m68k.org
@ 2024-01-02 15:18 ` rearnsha at gcc dot gnu.org
2024-01-02 16:25 ` mark at gcc dot gnu.org
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 15:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #24 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to David Binderman from comment #22)
> Is the optimization still worthwhile some 12 years later ?
Almost certainly. Vector operations have become much better than they were at
the time the patch went in, so it's probably even more worthwhile.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (23 preceding siblings ...)
2024-01-02 15:18 ` rearnsha at gcc dot gnu.org
@ 2024-01-02 16:25 ` mark at gcc dot gnu.org
2024-01-02 16:28 ` rearnsha at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: mark at gcc dot gnu.org @ 2024-01-02 16:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #25 from Mark Wielaard <mark at gcc dot gnu.org> ---
Note comment #16 which explains that valgrind seems to translate this large
read into smaller chunks. Which most likely causes memcheck to flag the (last)
8 bytes read as fully invalid. See
--partial-loads-ok=<yes|no> [default: yes]
Controls how Memcheck handles 32-, 64-, 128- and 256-bit naturally
aligned loads from addresses for which some bytes are addressable and others
are not. When yes, such loads do not produce an address error. Instead, loaded
bytes originating from illegal addresses are marked as uninitialised, and those
corresponding to legal addresses are handled in the normal way.
When no, loads from partially invalid addresses are treated the same as
loads from completely invalid addresses: an illegal-address error is issued,
and the resulting bytes are marked as initialised.
It would be helpful to see if someone with arm knowledge (and valgrind VEX
knowledge) can see if there is a better translation of the vld1 instruction so
that it is one big read. That way memcheck at least has a chance of detecting
that the part that is invalid isn't actually used. See
https://sourceware.org/cgit/valgrind/tree/VEX/priv/guest_arm_toIR.c#n8383
But maybe there is no good/natural translation of these vector loads that would
help memcheck see it is a valid read and only the defined bytes are used.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (24 preceding siblings ...)
2024-01-02 16:25 ` mark at gcc dot gnu.org
@ 2024-01-02 16:28 ` rearnsha at gcc dot gnu.org
2024-01-02 16:35 ` rearnsha at gcc dot gnu.org
2024-01-02 17:23 ` rearnsha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 16:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #26 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I think it's more likely that this is at the start of the buffer rather than
the end, and related to rounding the address down to a 16-byte alignment. But
it could also occur at the end of the buffer as well if the buffer is (nearly)
full.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (25 preceding siblings ...)
2024-01-02 16:28 ` rearnsha at gcc dot gnu.org
@ 2024-01-02 16:35 ` rearnsha at gcc dot gnu.org
2024-01-02 17:23 ` rearnsha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 16:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #27 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
> ==9933== by 0x151D554: search_line_fast (lex.cc:872)
This is the entry code; so the issue is with the initial alignment code (unless
the buffer is smaller than 16 bytes, when we might get both under reading and
overreading).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
` (26 preceding siblings ...)
2024-01-02 16:35 ` rearnsha at gcc dot gnu.org
@ 2024-01-02 17:23 ` rearnsha at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2024-01-02 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #28 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to David Binderman from comment #5)
> No idea. I know the gcc project is over 30 years old and it is not
> feasible for me to download the entire history, it is too large.
>
> I have the last 18 months or so history and that's a whopping
> 3.8 Gig on it's own.
$ cd ~/gnusrc/gcc/master/.git
$ du -sh .
1.8G .
So on my machine the entire git history is just 1.8G; that's because the
history is very densely packed on the server and pulling the entire history
does not require an unpack-repack-send sequence.
But if you download a partial history, then the git server has to unpack and
then repack the required history in order to send it; that makes the process
much slower and results in far more data being transmitted (the on-the-fly
repack is not as dense because it would take too much time).
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2024-01-02 17:23 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-16 16:39 [Bug target/113045] New: armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 dcb314 at hotmail dot com
2023-12-16 16:44 ` [Bug target/113045] " pinskia at gcc dot gnu.org
2023-12-17 17:35 ` dcb314 at hotmail dot com
2023-12-17 18:18 ` redi at gcc dot gnu.org
2023-12-17 18:21 ` redi at gcc dot gnu.org
2023-12-17 18:50 ` dcb314 at hotmail dot com
2023-12-17 18:57 ` dcb314 at hotmail dot com
2023-12-17 19:55 ` dcb314 at hotmail dot com
2023-12-17 20:06 ` pinskia at gcc dot gnu.org
2023-12-17 20:11 ` pinskia at gcc dot gnu.org
2023-12-17 21:05 ` redi at gcc dot gnu.org
2023-12-17 22:22 ` redi at gcc dot gnu.org
2023-12-17 22:25 ` redi at gcc dot gnu.org
2023-12-18 8:18 ` rguenth at gcc dot gnu.org
2023-12-19 8:23 ` dcb314 at hotmail dot com
2023-12-19 8:28 ` dcb314 at hotmail dot com
2023-12-19 9:22 ` redi at gcc dot gnu.org
2023-12-19 12:58 ` mark at gcc dot gnu.org
2023-12-19 16:53 ` dcb314 at hotmail dot com
2023-12-19 17:18 ` mark at gcc dot gnu.org
2024-01-02 14:40 ` rearnsha at gcc dot gnu.org
2024-01-02 14:49 ` rearnsha at gcc dot gnu.org
2024-01-02 15:05 ` dcb314 at hotmail dot com
2024-01-02 15:14 ` schwab@linux-m68k.org
2024-01-02 15:18 ` rearnsha at gcc dot gnu.org
2024-01-02 16:25 ` mark at gcc dot gnu.org
2024-01-02 16:28 ` rearnsha at gcc dot gnu.org
2024-01-02 16:35 ` rearnsha at gcc dot gnu.org
2024-01-02 17:23 ` rearnsha at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).