On Wed, Sep 22, 2021 at 12:46 PM Christoph Müllner
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
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_bui
On Fri, Sep 17, 2021 at 9:27 AM Florian Weimer via Libc-alpha <
libc-al...@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
On Fri, Sep 17, 2021, at 9:36 PM, James Y Knight via Libc-alpha wrote:
> Glibc currently implements bcmp as an alias to memcmp -- which is valid,
> but provides more than just the boolean equality semantics. There was
> concern raised that modifying that might break existing binaries. However,
> th
On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
Per spec, bcmp is not a three-way comparison, it is an equality comparison
with exactly the same
On Fri, Sep 17, 2021 at 3:32 AM Richard Biener via Gcc
wrote:
> On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer
> wrote:
> >
> > * Richard Biener via Gcc:
> >
> > > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
> wrote:
> > >>
> > >> On Thu, 16 Sep 2021, Chris Kennelly wrote:
> > >>
> > >> > In
On 9/17/21 3:12 AM, Jakub Jelinek via Gcc wrote:
On Fri, Sep 17, 2021 at 10:08:34AM +0200, Florian Weimer via Gcc wrote:
So the compiler would emit a call to __memcmpeq and at the same time
emit a weak alias of __memcmpeq to memcmp so the program links
when the libc version targeted does not pro
* 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
On Fri, 17 Sep 2021, Richard Biener via Gcc wrote:
> when the libc version targeted does not provide __memcmpeq? Or would
> glibc through magically communicate the availability of the new ABI
> without actually declaring the function?
> (I'm not sure whether a GCC build-time decision via configu
On Fri, Sep 17, 2021 at 10:37 AM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote:
> >>
> >> * Richard Biener via Gcc:
> >>
> >> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
> >> > wrote:
> >> >>
> >> >> On Thu, 16 Sep 2021, Chris Kennel
On Fri, Sep 17, 2021 at 10:08:34AM +0200, Florian Weimer via Gcc wrote:
> > So the compiler would emit a call to __memcmpeq and at the same time
> > emit a weak alias of __memcmpeq to memcmp so the program links
> > when the libc version targeted does not provide __memcmpeq? Or would
> > glibc thr
* Richard Biener:
> On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote:
>>
>> * Richard Biener via Gcc:
>>
>> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
>> > wrote:
>> >>
>> >> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>> >>
>> >> > In terms of relying on the feature: If __memcmpeq is
On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote:
>
> * Richard Biener via Gcc:
>
> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers
> > wrote:
> >>
> >> On Thu, 16 Sep 2021, Chris Kennelly wrote:
> >>
> >> > In terms of relying on the feature: If __memcmpeq is ever exposed as an
> >> > a
* Richard Biener via Gcc:
> On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers wrote:
>>
>> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>>
>> > In terms of relying on the feature: If __memcmpeq is ever exposed as an a
>> > simple alias for memcmp (since the notes mention that it's a valid
>> > impleme
On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers wrote:
>
> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>
> > In terms of relying on the feature: If __memcmpeq is ever exposed as an a
> > simple alias for memcmp (since the notes mention that it's a valid
> > implementation), does that open up the pos
On Thu, Sep 16, 2021 at 5:25 PM Chris Kennelly via Libc-alpha <
libc-al...@sourceware.org> wrote:
> On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
>
> > plus testing for _equality_ can (as mentioned earlier) have slightly
> > different properties from the three-way comparator behavior of
> > bcmp()/m
On Thu, 16 Sep 2021, Chris Kennelly wrote:
> The mem* functions are extremely sensitive to instruction cache effects, so
> having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar,
I don't think anyone is suggesting 3 unique implementations. The
obsolescent name bcmp would be
On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
llvm-libc's implementation only returns the boolean, though.
The mem* functions are extremely s
On Thu, Sep 16, 2021, 4:50 PM enh via Libc-alpha
wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
How does bcmp() have a three-way comparator?
Or do you mean how it is currently im
plus testing for _equality_ can (as mentioned earlier) have slightly
different properties from the three-way comparator behavior of
bcmp()/memcmp().
On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers
wrote:
> On Thu, 16 Sep 2021, James Y Knight wrote:
>
> > Wouldn't it be far simpler to just un-deprec
On Thu, 16 Sep 2021, James Y Knight wrote:
> Wouldn't it be far simpler to just un-deprecate bcmp?
The aim is to have something to which calls can be generated in all
standards modes. bcmp has never been part of ISO C; there's nothing to
undeprecate there.
--
Joseph S. Myers
jos...@codesourc
Wouldn't it be far simpler to just un-deprecate bcmp?
On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
wrote:
> Hi All,
>
> This is a proposal for a new interface to be supported by libc.
>
> The new interface is the same as the old 'bcmp()' routine. Essentially
> the goal of this proposal is to a
(Android libc maintainer.)
should __memcmpeq be in compiler-rt rather than libc?
On Thu, Sep 16, 2021 at 1:35 PM Joseph Myers
wrote:
> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>
> > In terms of relying on the feature: If __memcmpeq is ever exposed as an
> a
> > simple alias for memcmp (since
On Thu, 16 Sep 2021, Chris Kennelly wrote:
> In terms of relying on the feature: If __memcmpeq is ever exposed as an a
> simple alias for memcmp (since the notes mention that it's a valid
> implementation), does that open up the possibility of depending on the
> bcmp-like behavior that we were tr
On Thu, Sep 16, 2021 at 2:31 PM Noah Goldstein
wrote:
>
>
> On Thu, Sep 16, 2021 at 12:55 PM Chris Kennelly via Libc-alpha <
> libc-al...@sourceware.org> wrote:
>
>> On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
>> wrote:
>>
>> > Hi All,
>> >
>> > This is a proposal for a new interface to be su
On Thu, Sep 16, 2021 at 12:55 PM Chris Kennelly via Libc-alpha <
libc-al...@sourceware.org> wrote:
> On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
> wrote:
>
> > Hi All,
> >
> > This is a proposal for a new interface to be supported by libc.
> >
> > The new interface is the same as the old 'bcmp
On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
wrote:
> Hi All,
>
> This is a proposal for a new interface to be supported by libc.
>
> The new interface is the same as the old 'bcmp()' routine. Essentially
> the goal of this proposal is to add a reserved namespace for a new
> function, '__memcmp
27 matches
Mail list logo
