[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: [libc-coord] Add new ABI '__memcmpeq()' to libc
From:       Noah Goldstein via Gcc <gcc () gcc ! gnu ! org>
Date:       2021-09-22 18:15:24
Message-ID: CAFUsyf+i9hFE3WE_2PL=tt9RzU3Jv1N6qsrkEtxY9XLBo+avOw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Sep 22, 2021 at 12:46 PM Christoph M=C3=BCllner <cmuellner@gcc.gnu.=
org>
wrote:

> Would it make sense to extend this proposal to include __strcmpeq()
> and __strncmpeq()?
>
> Both are already available internally in GCC in form of
> BUILT_IN_STRCMP_EQ and BUILT_IN_STRNCMP_EQ
> (tree-ssa-strlen.c detects them in handle_builtin_string_cmp() and
> builtins.c tries to inline them in expand_builtin_memcmp()).
> However, they are currently restricted to cases where the length of
> the string or the size of the array (of both arguments) is known.
>
> A use case for strcmpeq() would be the comparison of std::type_info
> objects (equality and inequality operator) in libstdc++.
>
> I agree and am happy to implement them along side __memcmpeq()
if the proposal is accepted. Do they need a seperate writeup with full
specifications?


> On Tue, Sep 21, 2021 at 9:54 PM Noah Goldstein via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > On Fri, Sep 17, 2021 at 9:27 AM Florian Weimer via Libc-alpha <
> > libc-alpha@sourceware.org> wrote:
> >
> > > * Joseph Myers:
> > >
> > > > 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 us=
ed
> > > 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.
> > >
> > > The header-less case looks relevant to C++ and other language front
> > > ends, though.  So a GCC_GLIBC_VERSION_GTE_IFELSE check could still ma=
ke
> > > sense for them.
> > >
> > > (Dropping libc-coord.)
> > >
> > > Thanks,
> > > Florian
> > >
> > >
> > What are we going with?
> >
> > Should I go forward with the proposal in GLIBC?
> >
> > If I should go forward with it should I include a def in string.h?
>
[prev in list] [next in list] [prev in thread] [next in thread]