https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #28 from Richard Earnshaw ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #27 from Richard Earnshaw ---
> ==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 unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #26 from Richard Earnshaw ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #25 from Mark Wielaard ---
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-lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #24 from Richard Earnshaw ---
(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 pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #23 from Andreas Schwab ---
valgrind replaces str/mem functions with its own versions so that it can do
better checking and avoid false positives.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #22 from David Binderman ---
(In reply to Richard Earnshaw from comment #21)
> commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
> Author: Richard Earnshaw
> Date: Thu Mar 22 17:54:55 2012 +
>
> * lex.c (search_line_fast):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #21 from Richard Earnshaw ---
FTR it was this patch that added this code. So 2012!
commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
Author: Richard Earnshaw
Date: Thu Mar 22 17:54:55 2012 +
* lex.c (search_line_fast): Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #19 from Mark Wielaard ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #18 from David Binderman ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #17 from Mark Wielaard ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #16 from Jonathan Wakely ---
Not sheer fluke, it was the same ^d4ba3b369c commit both times, because that
was the oldest commit in your clone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #15 from David Binderman ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #14 from David Binderman ---
(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 tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Biener changed:
What|Removed |Added
Target||arm
--- Comment #13 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #12 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #11 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #10 from Jonathan Wakely ---
(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 ide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #8 from Andrew Pinski ---
e75b54a2d932 libcpp/lex.c (Richard Earnshaw 2012-03-22 17:54:55 +
869) /* Align the source pointer. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #7 from David Binderman ---
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. *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #6 from David Binderman ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #5 from David Binderman ---
(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
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #4 from Jonathan Wakely ---
That's what the ^ on the commit suggests is happening.
You can fix your history with:
git fetch --unshallow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #3 from Jonathan Wakely ---
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
David Binderman changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #1 from Andrew Pinski ---
This could also be a valgrind issue ...
28 matches
Mail list logo
