On Thu, Sep 16, 2021 at 1:37 AM Paul Koning via Gcc wrote:
>
>
>
> > On Sep 15, 2021, at 5:21 PM, Joseph Myers wrote:
> >
> > On Wed, 15 Sep 2021, Paul Koning via Gcc wrote:
> >
> >> Some questions about developer branches:
> >>
> >> 1. Who may create one? Who may write to them?
> >> 2. Are they
On Thu, 16 Sept 2021 at 00:34, Paul Koning wrote:
>
>
>
> > On Sep 15, 2021, at 4:34 PM, Jonathan Wakely wrote:
> >
> > On Wed, 15 Sept 2021 at 21:12, Paul Koning via Gcc wrote:
> >>
> >> Some questions about developer branches:
> >>
> >> 1. Who may create one? Who may write to them?
> >> 2. Ar
On Thu, 16 Sept 2021 at 09:15, Richard Biener wrote:
>
> On Thu, Sep 16, 2021 at 1:37 AM Paul Koning wrote:
> > Thanks, that's useful. Suppose I want to collaborate with one other person
> > (for now) on pdp11 target work, does it make sense to keep that in a user
> > branch since the community
Folks,
As many of you know, Apple has now released an AArch64-based version of macOS
and desktop/laptop platforms using the ‘M1’ chip to support it. This is in
addition to the existing iOS mobile platforms (but shares some of their
constraints).
There is considerable interest in the user-base
On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote:
Hi all,
I am doing some bugzilla cleanup. This includes disabling some
components and some versions for new bugs.
So far I have disabled versions before GCC 4 because we have not had a
report from someone for those versions in over 7 years. I
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, '__memcmpeq()', which shares the same behavior as the old
'bcmp()'.
Int
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
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 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, 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
(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
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
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
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, 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
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
Snapshot gcc-9-20210916 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210916/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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: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, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc wrote:
> ice-on-invalid-code: ICE on code that is not syntactically valid.
> ice-on-valid-code: ICE on code that is syntactically valid.
Presumably, the distinction is there because more attention would get
paid to the latter over the former.
20 matches
Mail list logo
