[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.22.394.2109171415400.3813920@digraph.polyomino.org.uk>
Date: Fri, 17 Sep 2021 14:19:53 +0000
From: Joseph Myers <joseph@...esourcery.com>
To: Richard Biener <richard.guenther@...il.com>
CC: GCC Development <gcc@....gnu.org>, GNU C Library
<libc-alpha@...rceware.org>, <libc-coord@...ts.openwall.com>
Subject: Re: Add new ABI '__memcmpeq()' to libc
On Fri, 17 Sep 2021, Richard Biener via Gcc wrote:
> when the libc version targeted does not provide __memcmpeq? Or would
> glibc through <string.h> magically communicate the availability of the new ABI
> without actually declaring the function?
> (I'm not sure whether a GCC build-time decision via configure is the
> very best idea)
I was supposing a build-time decision (using GCC_GLIBC_VERSION_GTE_IFELSE
to know if the glibc version on the target definitely has this function).
But if we add a header declaration, you could check for __memcmpeq being
declared (and so cover arbitrary C libraries, not just glibc, and avoid
issues of needing to disable this logic for freestanding compilations,
which would otherwise be an issue if a glibc-target toolchain is used for
a freestanding kernel compilation). The case of people calling
__builtin_memcmp (or declaring memcmp themselves) without string.h
included probably isn't one it's important to optimize.
--
Joseph S. Myers
joseph@...esourcery.com
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
