This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309

--- Comment #51 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-22 15:01:08 UTC ---
Looks like a real SPEC bug to me.

PerlIO_funcs *
PerlIO_find_layer(pTHX_ const char *name, STRLEN len, int load)
{
    IV i;
    if ((SSize_t) len <= 0)
        len = strlen(name);
    for (i = 0; i < PL_known_layers->cur; i++) {
        PerlIO_funcs *f = PL_known_layers->array[i].funcs;
        if (memEQ(f->name, name, len) && f->name[len] == 0) {
            PerlIO_debug("%.*s => %p\n", (int) len, name, (void*)f);
            return f;
        }
    }

memEQ is memcmp, and my reading of ISO C99 or
http://pubs.opengroup.org/onlinepubs/9699919799/functions/memcmp.html is that
it is a bug to call memcmp ("abcdef", "defg", 6).  A valid memcmp
implementation could preread all bytes from both arrays (of the given length)
and only then compare.  And, at least some implementations (e.g. glibc
string/memcmp.c) does that if the two strings aren't starting at the same
address modulo size of word.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]