This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
- From: "rth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 17 Jan 2011 18:40:33 +0000
- Subject: [Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
- Auto-submitted: auto-generated
- References: <bug-47311-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47311
--- Comment #17 from Richard Henderson <rth at gcc dot gnu.org> 2011-01-17 18:40:05 UTC ---
(In reply to comment #16)
> ==5267== Invalid read of size 8
> ==5267== at 0x11E4E24: search_line_sse42(unsigned char const*, unsigned
It's fine. (1) Note that we've already verified above that the address is
aligned and (2) that we will in fact find the end-of-line marker that we
expect before we examine data beyond END.
I suppose valgrind expects us to update EDX in
> 454â /* Main loop, processing 16 bytes at a time. By doing the whole loop
> 455â in inline assembly, we can make proper use of the flags set. */
> 456â __asm ( "sub $16, %1\n"
> 457â " .balign 16\n"
> 458â "0: add $16, %1\n"
> 459â " %vpcmpestri $0, (%1), %2\n"
> 460â " jnc 0b"
> 461â : "=&c"(index), "+r"(s)
> 462â> : "x"(search), "a"(4), "d"(16));
so that it can tell that we're examining only the first EDX bytes of the
value read, but that would require a bit of useless arithmetic here.
If there's some easy way we can add a valgrind exception for these
functions to the gcc source tree, I'd be open to do so. But I also don't
want to figure out how to do that myself.