Re: Developer branches

[Richard Biener via Gcc]

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 required to be listed in https://gcc.gnu.org/git.html ?  I
> >> notice it mentioned a whole pile of them, most of which don't seem to
> >> exist.
> >
> > A devel/ branch (one in refs/heads/devel/) is a shared development branch,
> > which may be created by anyone with write access (who can decide how it
> > will work in terms of patch approvals etc.), should be documented in
> > git.html, and will not accept non-fast-forward pushes or branch deletion.
> >
> > A user branch (in refs/users//heads/) is a personal development
> > branch, which may be created by that user (sourceware username), may not
> > necessarily be documented in git.html, and can have non-fast-forward
> > pushes or branch deletion (it's up to that user to decide the rules for
> > that branch, including for non-fast-forward pushes).  Likewise a vendor
> > branch (in refs/vendors//heads/).
> >
> > All branches are subject to the same legal requirements (copyright
> > assignment or DCO for code committed there).
> > ...
>
> 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 is so small and isolated?  I assume the other 
> person would need (as a minimum) write-after-approval privs.

Note another option is to host int on github or gitlab and base it off
their mirrors of the GCC repo.

Without write-after-approval access the person would not be able to
push to the repo
at gcc.gnu.org but of course you could do this with changes sent by
mail for example.

Richard.

>
> paul
>

Re: Developer branches

[Jonathan Wakely via Gcc]

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. Are they required to be listed in https://gcc.gnu.org/git.html ?  I 
> >> notice it mentioned a whole pile of them, most of which don't seem to 
> >> exist.
> >
> > Which ones? All the one I looked for exist.
>
> Perhaps I did the procedures wrong.  I did a git pull, then git branch -a 
> |fgrep devel.  I see 24 entries.  Looking at the git.html page, that mentions 
> a lot more.  Some examples that do exist: modula-2, ira-select.  Some that 
> don't: the ave* branches, x86, var-template.

Ah, the text that says "Active development branches have names
starting devel/ in Git." is wrong. All of them are there, just not
under /devel e.g. `git ls-remote origin fortran-dev` shows it's at
refs/dead/heads/fortran-dev

We should clean up the list.

Re: Developer branches

[Jonathan Wakely via Gcc]

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 is so small and isolated?  I assume the other 
> > person would need (as a minimum) write-after-approval privs.
>
> Note another option is to host int on github or gitlab and base it off
> their mirrors of the GCC repo.
>
> Without write-after-approval access the person would not be able to
> push to the repo
> at gcc.gnu.org but of course you could do this with changes sent by
> mail for example.

With Git it's really not necessary for everybody to write to the same
repo. The other collaborator could have their own repo hosted on
gitlab or github and send pull requests to you, for you to merge into
your repo. Then you could push your branch (containing commits from
you and the other collaborator) to a devel or user branch on
gcc.gnu.org if you want (or not if you don't want to).

Or you could both write to the same repo hosted on
gitlab/github/wherever, by granting access appropriately. And then
push the results to a branch on gcc.gnu.org (or not).

With Subversion that didn't really work, there was no easy way to keep
in sync with the gcc.gnu.org trunk unless your devel branch was also
hosted on gcc.gnu.org, but with Git it's mostly irrelevant whether you
host your branch on gcc.gnu.org or not. If you have no other way to
host a repo that all collaborators can pull from (and you don't want
to exchange patches by email) then hosting a branch at gcc.gnu.org is
a good solution. But that's rarely the case, because there are
numerous zero-cost repo hosting platforms available that most people
can use (unless they are banned from all those platforms or firewalled
in some way that makes them reachable).

Announcement : An AArch64 (Arm64) Darwin port is planned for GCC12

[Iain Sandoe]

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 for a GCC port (starting with 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168) - and, of great kudos to 
the gfortran team, one of the main drivers is folks using Fortran.

Fortunately, I was able to obtain access to one of the DTKs, courtesy of the 
OSS folks, and using that managed to draft an initial attempt at the port last 
year (however, nowhere near ready for presentation in GCC11).  Nevertheless (as 
an aside) despite being a prototype, the port is in use with many via hombrew, 
macports or self-builds - which has shaken out some of the fixable bugs.

The work done in the prototype identified three issues that could not be coded 
around without work on generic parts of the compiler.

I am very happy to say that two of our colleagues, Andrew Burgess and Maxim 
Blinov (both from embecosm) have joined me in drafting a postable version of 
the port and we are seeking sponsorship to finish this in the GCC12 timeframe.

Maxim has a lightning talk on the GNU tools track at LPC (right after the 
steering committee session) that will focus on the two generic issues that 
we’re tackling (1 and 2 below).

Here is a short summary of the issues and proposed solutions (detailed 
discussion of any of the parts below would better be in new threads).

-

1. GCC’s default model for nested functions uses a trampoline on the stack; 
requiring an executable stack.  Executable stack is prohibited by the security 
model for Arm64 macOS.

  — We cannot punt on this because, in addition to the GCC extension to C to 
provide nested functions, the facility is used by Fortran (and Ada, of course), 
and many real-world examples fail without it (as reported to the prototype 
issues tracker).

  — the prototype has a hacked implementation of the descriptor-based solution 
proposed some time ago for Ada (that uses a reserved bit in the address).  This 
is, of course, completely unacceptable for the final port - and does not work 
when there are callbacks to system functions.

  Andrew Burgess is pursuing a solution which is essentially based on our 
reasoning of the problem and the discussion in the descriptor thread here:
  https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00066.html

  The mechanism would, of course, be opt-in (but is expected to be potentially 
useful to other OSs where the security model would require a non-executable 
stack).

  The summary is to allocate a memory area to contain the trampolines and to 
allocate (and free) these with the nesting of function pointer uses.  It is 
allowed for Arm64 macOS to have such a section of memory (granted by 
permissions on the executable).  Such an area cannot be both writable and 
executable at the same time, so we have to consider the implications of 
switching when an allocation or free occurs.

 This means modifying the nested function code to wrap allocations of 
trampolines in a cleanup.
 The current design also uses builtin functions to implement the actual 
management of the trampoline page(s), these would be part of libgcc.

 A note in passing: Apple’s implementation of libFFI and libObjC makes use of a 
similar technique - but the trampoline areas are placed in a code-signed SO (so 
that its authenticity is determined at load-time).  This isn’t a suitable 
mechanism for GCC, since it would involve somehow getting a codesigned SO 
distributed with the OS.  We are also assured that JIT code (which is 
more-or-less what this is) will be allowed for the forseeable future in macOS.

2. The darwinpcs (variant of the AAPCS64) has a lowering for function arguments 
that places them differently for ’normal’ and ‘variadic’ calls.

 — the prototype has an outrageous hack to allow it function.

Maxim Blinov is working on a proper solution to this, thus:

Many ports go to quite some lengths to track their register and stack use via 
the cummulative args mechanism.  However, when the lowering is done to RTL for 
calls, the code there assumes that the layout of a stack-placed argument will 
be the same for named and unnamed cases.

For the darwinpcs, named arguments are passed naturally-aligned on the stack 
(with necessary padding) - but unnamed arguments are passed word-aligned.

The current proposed solution is to extend the use of the cummulative args 
mechanism to provide callbacks that allow the computed layout in the cum. args 
to be used when placing arguments on the stack.

3. GCC's current PCH model requires that we load the compiler executable at the 
same address each time; this is prohibited by the security model for Arm64 
macOS, which does not allow non-PIE executables.

  — at present, there is no solution proposed for this and we will initially, 
at le

Re: [FYI] bugzilla cleanup

[Martin Sebor via Gcc]

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 disabled
some versions which are about developmental branches which are
inactive too.
I also disabled the java, libgcj, fastjar, libmudflap, treelang and
libf2c components.

I am in the process of moving away from having an inline-asm component
to an inline-asm keyword instead; this was suggested on IRC and I
agree.  After the current open bugs have moved away from the
inline-asm component, I will disable it also.

If anyone else has any other suggestions that should be done, please
let me know and I will look into doing it.


Re: Keywords: I find it useful to differentiate between two kinds of
diagnostic bugs: false positives and false negatives (the latter for
existing warnings that don't trigger when intended, as opposed to
requests to enhance existing warnings or add new ones). I've been
using Personal Tags for this but it might be useful to others as
well.  If you agree and add the corresponding new keywords
(false-positive and false-negative) I'll set them based on my Tags.

One other suggestion: every once in a while someone asks if
ice-on-invalid-code bugs apply to syntactically well-formed code that
has undefined behavior (I don't believe it does).  It would help to
clarify the Description for this Keyword (and, correspondingly, for
ice-on-valid).  E.g., something like

ice-on-invalid-code: ICE on code that is not syntactically valid.
ice-on-valid-code: ICE on code that is syntactically valid.

Martin

Add new ABI '__memcmpeq()' to libc

[Noah Goldstein via Gcc]

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()'.

 Interface 

int __memcmpeq(void const * s1, const void * s2, size_t n)


 Description 

The '__memcmpeq()' function would compare the two byte sequences 's1'
and 's2', each of length 'n'. If the two byte sequences are equal, the
return would be zero. Otherwise it would return some non-zero
value. 'memcmp()' is a valid implementation of '__memcmpeq()'.


 Use Case 

1. The goal is that '__memcmpeq()' will be usable as an optimization
   by compilers if a program uses the return value of 'memcmp()' as a
   boolean. For example:


void foo(const void* s1, const void* s2, size_t n)
{
if (!memcmp(s1, s2, n)) {
printf("memcmp can be optimized to __memcmpeq in this use case\n");
}
}


- In the above case '__memcmpeq()' could be used instead. Due to the
  simpler constraints on the return value of '__memcmpeq()', it will
  be able to be implemented more optimally for this case than
  'memcmp()'. If there is no separately optimized version of
  '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
  fast.

2. Possibly use cases in security as the runtime of the function will
   be *more* oblivious to the byte sequences being compared.


 Argument Specifications 

1. 's1'
- All 'n' bytes in the byte sequence starting at 's1' and ending
  at, but not including, 's1 + n' must be accessible memory. There
  are no guarantees about the order the sequence will be
  traversed.
2. 's2'
- All 'n' bytes in the byte sequence starting at 's2' and ending
  at, but not including, 's2 + n' must be accessible memory. There
  are no guarantees about the order the sequence will be
  traversed.
3. 'n'
- 'n' may be any value that does not violate the specifications on
  's1' and 's2'.

If any of the argument specifications are violated there are no
guarantees about the behavior of the interface.


 Return Value Specification 

If the byte sequences starting at 's1' and 's2' are equals the
function will return zero. Otherwise the function will return a
non-zero value.

Equality between the byte sequences starting at 's1' and 's2' is
defined as follows:

1. If 'n' is zero the two sequences are zero.
2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
   offset 'i' of 's1' equals the byte at offset 'i' in 's2'.

For a simple C implementation of '__memcmpeq()' could be as follows:


int __memcmpeq(const void* s1, const void* s2, size_t n)
{
int ret;
size_t i;
const char *s1c, *s2c;
s1c = (const char*)s1;
s2c = (const char*)s2;
for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
ret = s1c[i] - s2c[i]
}
return ret;
}


 Notes 

This interface is essentially old 'bcmp()' and 'memcmp()' will always
be a valid implementation of '__memcmpeq()'.


 ABI vs API 

This proposal is for '__memcmpeq()' as a new ABI. As an ABI
'__memcmpeq()' will have value, as using the return value of
'memcmp()' is quite idiomatic in C code.

It is, however, possible that this would also be useful as a new API
as well. Especially if there are likely use cases where the compiler
would be unable to prove that '__memcmpeq()' would be a valid
replacement for 'memcmp()'.


 Further Options 

If this proposal is received positively, libc could also add
interfaces for '__streq()', '__strneq()', '__wcseq()' and '__wcsneq()'
which similarly would loosen return value restrictions on 'strcmp()',
'strncmp()', 'wcscmp()' and 'wcsncmp()' respectively.

Best,
Noah

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Chris Kennelly via Gcc]

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, '__memcmpeq()', which shares the same behavior as the old
> 'bcmp()'.
>
>  Interface 
>
> int __memcmpeq(void const * s1, const void * s2, size_t n)
>
>
>  Description 
>
> The '__memcmpeq()' function would compare the two byte sequences 's1'
> and 's2', each of length 'n'. If the two byte sequences are equal, the
> return would be zero. Otherwise it would return some non-zero
> value. 'memcmp()' is a valid implementation of '__memcmpeq()'.
>
>
>  Use Case 
>
> 1. The goal is that '__memcmpeq()' will be usable as an optimization
>by compilers if a program uses the return value of 'memcmp()' as a
>boolean. For example:
>
>
> void foo(const void* s1, const void* s2, size_t n)
> {
> if (!memcmp(s1, s2, n)) {
> printf("memcmp can be optimized to __memcmpeq in this use case\n");
> }
> }
>
>
> - In the above case '__memcmpeq()' could be used instead. Due to the
>   simpler constraints on the return value of '__memcmpeq()', it will
>   be able to be implemented more optimally for this case than
>   'memcmp()'. If there is no separately optimized version of
>   '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
>   fast.
>

LLVM does this transformation (but to bcmp), as part of
https://reviews.llvm.org/rG8e16d73346f8091461319a7dfc4ddd18eedcff13.  I
seem to recall a small amount of trickiness around determining whether the
platform had a bcmp.

Since this is intentionally the same as bcmp, is it possible to clarify the
motivation for additional symbol?


> 2. Possibly use cases in security as the runtime of the function will
>be *more* oblivious to the byte sequences being compared.
>
>
>  Argument Specifications 
>
> 1. 's1'
> - All 'n' bytes in the byte sequence starting at 's1' and ending
>   at, but not including, 's1 + n' must be accessible memory. There
>   are no guarantees about the order the sequence will be
>   traversed.
> 2. 's2'
> - All 'n' bytes in the byte sequence starting at 's2' and ending
>   at, but not including, 's2 + n' must be accessible memory. There
>   are no guarantees about the order the sequence will be
>   traversed.
> 3. 'n'
> - 'n' may be any value that does not violate the specifications on
>   's1' and 's2'.
>
> If any of the argument specifications are violated there are no
> guarantees about the behavior of the interface.
>
>
>  Return Value Specification 
>
> If the byte sequences starting at 's1' and 's2' are equals the
> function will return zero. Otherwise the function will return a
> non-zero value.
>
> Equality between the byte sequences starting at 's1' and 's2' is
> defined as follows:
>
> 1. If 'n' is zero the two sequences are zero.
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
>offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()' could be as follows:
>
>
> int __memcmpeq(const void* s1, const void* s2, size_t n)
> {
> int ret;
> size_t i;
> const char *s1c, *s2c;
> s1c = (const char*)s1;
> s2c = (const char*)s2;
> for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> ret = s1c[i] - s2c[i]
> }
> return ret;
> }
>
>
>  Notes 
>
> This interface is essentially old 'bcmp()' and 'memcmp()' will always
> be a valid implementation of '__memcmpeq()'.
>
>
>  ABI vs API 
>
> This proposal is for '__memcmpeq()' as a new ABI. As an ABI
> '__memcmpeq()' will have value, as using the return value of
> 'memcmp()' is quite idiomatic in C code.
>
> It is, however, possible that this would also be useful as a new API
> as well. Especially if there are likely use cases where the compiler
> would be unable to prove that '__memcmpeq()' would be a valid
> replacement for 'memcmp()'.
>
>
>  Further Options 
>
> If this proposal is received positively, libc could also add
> interfaces for '__streq()', '__strneq()', '__wcseq()' and '__wcsneq()'
> which similarly would loosen return value restrictions on 'strcmp()',
> 'strncmp()', 'wcscmp()' and 'wcsncmp()' respectively.
>
> Best,
> Noah
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Noah Goldstein via Gcc]

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()' 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()'.
> >
> >  Interface 
> >
> > int __memcmpeq(void const * s1, const void * s2, size_t n)
> >
> >
> >  Description 
> >
> > The '__memcmpeq()' function would compare the two byte sequences 's1'
> > and 's2', each of length 'n'. If the two byte sequences are equal, the
> > return would be zero. Otherwise it would return some non-zero
> > value. 'memcmp()' is a valid implementation of '__memcmpeq()'.
> >
> >
> >  Use Case 
> >
> > 1. The goal is that '__memcmpeq()' will be usable as an optimization
> >by compilers if a program uses the return value of 'memcmp()' as a
> >boolean. For example:
> >
> >
> > void foo(const void* s1, const void* s2, size_t n)
> > {
> > if (!memcmp(s1, s2, n)) {
> > printf("memcmp can be optimized to __memcmpeq in this use
> case\n");
> > }
> > }
> >
> >
> > - In the above case '__memcmpeq()' could be used instead. Due to the
> >   simpler constraints on the return value of '__memcmpeq()', it will
> >   be able to be implemented more optimally for this case than
> >   'memcmp()'. If there is no separately optimized version of
> >   '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
> >   fast.
> >
>
> LLVM does this transformation (but to bcmp), as part of
> https://reviews.llvm.org/rG8e16d73346f8091461319a7dfc4ddd18eedcff13.  I
> seem to recall a small amount of trickiness around determining whether the
> platform had a bcmp.
>
> Since this is intentionally the same as bcmp, is it possible to clarify the
> motivation for additional symbol?
>

The motivation is to get a new reserved namespace for a function that
memcmp() calls can be transformed to if the return value is only used
for its boolean value.

I tried to add an optimized version of bcmp() to support LLVM's
transformation: https://patches-gcc.linaro.org/patch/60168/
But the consensus seems to be that bcmp() is not suitable because 1)
it is not a reserved namespace and 2) since it has had the same
functionality as memcmp() programs might have started relying on that
feature.

Do you want me to update the above proposal with this information or
were you just asking for more clarity for the thread?


>
>
> > 2. Possibly use cases in security as the runtime of the function will
> >be *more* oblivious to the byte sequences being compared.
> >
> >
> >  Argument Specifications 
> >
> > 1. 's1'
> > - All 'n' bytes in the byte sequence starting at 's1' and ending
> >   at, but not including, 's1 + n' must be accessible memory. There
> >   are no guarantees about the order the sequence will be
> >   traversed.
> > 2. 's2'
> > - All 'n' bytes in the byte sequence starting at 's2' and ending
> >   at, but not including, 's2 + n' must be accessible memory. There
> >   are no guarantees about the order the sequence will be
> >   traversed.
> > 3. 'n'
> > - 'n' may be any value that does not violate the specifications on
> >   's1' and 's2'.
> >
> > If any of the argument specifications are violated there are no
> > guarantees about the behavior of the interface.
> >
> >
> >  Return Value Specification 
> >
> > If the byte sequences starting at 's1' and 's2' are equals the
> > function will return zero. Otherwise the function will return a
> > non-zero value.
> >
> > Equality between the byte sequences starting at 's1' and 's2' is
> > defined as follows:
> >
> > 1. If 'n' is zero the two sequences are zero.
> > 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
> >offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
> >
> > For a simple C implementation of '__memcmpeq()' could be as follows:
> >
> >
> > int __memcmpeq(const void* s1, const void* s2, size_t n)
> > {
> > int ret;
> > size_t i;
> > const char *s1c, *s2c;
> > s1c = (const char*)s1;
> > s2c = (const char*)s2;
> > for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> > ret = s1c[i] - s2c[i]
> > }
> > return ret;
> > }
> >
> >
> >  Notes 
> >
> > This interface is essentially old 'bcmp()' and 'memcmp()' will always
> > be a valid implementation of '__memcmpeq()'.
> >
> >
> >  ABI vs API 
> >
> > This proposal is for '__memcmpeq()' as a new ABI. As an ABI
> > '__memcmpeq()' will have value, as using the return value of
> > 'memcmp()' is quite idiomatic in C code.
> >
> > It is, however, possible that this would also be useful as a new API
> > as well. Especially if there are likely use cases where the compiler
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Chris Kennelly via Gcc]

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 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()'.
>> >
>> >  Interface 
>> >
>> > int __memcmpeq(void const * s1, const void * s2, size_t n)
>> >
>> >
>> >  Description 
>> >
>> > The '__memcmpeq()' function would compare the two byte sequences 's1'
>> > and 's2', each of length 'n'. If the two byte sequences are equal, the
>> > return would be zero. Otherwise it would return some non-zero
>> > value. 'memcmp()' is a valid implementation of '__memcmpeq()'.
>> >
>> >
>> >  Use Case 
>> >
>> > 1. The goal is that '__memcmpeq()' will be usable as an optimization
>> >by compilers if a program uses the return value of 'memcmp()' as a
>> >boolean. For example:
>> >
>> >
>> > void foo(const void* s1, const void* s2, size_t n)
>> > {
>> > if (!memcmp(s1, s2, n)) {
>> > printf("memcmp can be optimized to __memcmpeq in this use
>> case\n");
>> > }
>> > }
>> >
>> >
>> > - In the above case '__memcmpeq()' could be used instead. Due to the
>> >   simpler constraints on the return value of '__memcmpeq()', it will
>> >   be able to be implemented more optimally for this case than
>> >   'memcmp()'. If there is no separately optimized version of
>> >   '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
>> >   fast.
>> >
>>
>> LLVM does this transformation (but to bcmp), as part of
>> https://reviews.llvm.org/rG8e16d73346f8091461319a7dfc4ddd18eedcff13.  I
>> seem to recall a small amount of trickiness around determining whether the
>> platform had a bcmp.
>>
>> Since this is intentionally the same as bcmp, is it possible to clarify
>> the
>> motivation for additional symbol?
>>
>
> The motivation is to get a new reserved namespace for a function that
> memcmp() calls can be transformed to if the return value is only used
> for its boolean value.
>
> I tried to add an optimized version of bcmp() to support LLVM's
> transformation: https://patches-gcc.linaro.org/patch/60168/
> But the consensus seems to be that bcmp() is not suitable because 1)
> it is not a reserved namespace and 2) since it has had the same
> functionality as memcmp() programs might have started relying on that
> feature.
>

llvm-libc's bcmp differs from memcmp, but agreed that Hyrum's Law can cause
problems on point #2.

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 trying to escape?


>
> Do you want me to update the above proposal with this information or
> were you just asking for more clarity for the thread?
>
>
>>
>>
>> > 2. Possibly use cases in security as the runtime of the function will
>> >be *more* oblivious to the byte sequences being compared.
>> >
>> >
>> >  Argument Specifications 
>> >
>> > 1. 's1'
>> > - All 'n' bytes in the byte sequence starting at 's1' and ending
>> >   at, but not including, 's1 + n' must be accessible memory. There
>> >   are no guarantees about the order the sequence will be
>> >   traversed.
>> > 2. 's2'
>> > - All 'n' bytes in the byte sequence starting at 's2' and ending
>> >   at, but not including, 's2 + n' must be accessible memory. There
>> >   are no guarantees about the order the sequence will be
>> >   traversed.
>> > 3. 'n'
>> > - 'n' may be any value that does not violate the specifications on
>> >   's1' and 's2'.
>> >
>> > If any of the argument specifications are violated there are no
>> > guarantees about the behavior of the interface.
>> >
>> >
>> >  Return Value Specification 
>> >
>> > If the byte sequences starting at 's1' and 's2' are equals the
>> > function will return zero. Otherwise the function will return a
>> > non-zero value.
>> >
>> > Equality between the byte sequences starting at 's1' and 's2' is
>> > defined as follows:
>> >
>> > 1. If 'n' is zero the two sequences are zero.
>> > 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
>> >offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>> >
>> > For a simple C implementation of '__memcmpeq()' could be as follows:
>> >
>> >
>> > int __memcmpeq(const void* s1, const void* s2, size_t n)
>> > {
>> > int ret;
>> > size_t i;
>> > const char *s1c, *s2c;
>> > s1c = (const char*)s1;
>> > s2c = (const char*)s2;
>> > for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
>> > ret =

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Joseph Myers]

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 trying to escape?

The proposal is as an ABI only (compilers would generate calls to 
__memcmpeq from boolean uses of memcmp, users wouldn't write calls to 
__memcmpeq directly, __memcmpeq wouldn't be declared in installed libc 
headers).  If such dependence arises, that would suggest a compiler bug 
wrongly generating such calls for non-boolean memcmp uses.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[enh via Gcc]

(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 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 trying to escape?
>
> The proposal is as an ABI only (compilers would generate calls to
> __memcmpeq from boolean uses of memcmp, users wouldn't write calls to
> __memcmpeq directly, __memcmpeq wouldn't be declared in installed libc
> headers).  If such dependence arises, that would suggest a compiler bug
> wrongly generating such calls for non-boolean memcmp uses.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[James Y Knight via Gcc]

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 add a reserved namespace for a new
> function, '__memcmpeq()', which shares the same behavior as the old
> 'bcmp()'.
>
>  Interface 
>
> int __memcmpeq(void const * s1, const void * s2, size_t n)
>
>
>  Description 
>
> The '__memcmpeq()' function would compare the two byte sequences 's1'
> and 's2', each of length 'n'. If the two byte sequences are equal, the
> return would be zero. Otherwise it would return some non-zero
> value. 'memcmp()' is a valid implementation of '__memcmpeq()'.
>
>
>  Use Case 
>
> 1. The goal is that '__memcmpeq()' will be usable as an optimization
>by compilers if a program uses the return value of 'memcmp()' as a
>boolean. For example:
>
>
> void foo(const void* s1, const void* s2, size_t n)
> {
> if (!memcmp(s1, s2, n)) {
> printf("memcmp can be optimized to __memcmpeq in this use case\n");
> }
> }
>
>
> - In the above case '__memcmpeq()' could be used instead. Due to the
>   simpler constraints on the return value of '__memcmpeq()', it will
>   be able to be implemented more optimally for this case than
>   'memcmp()'. If there is no separately optimized version of
>   '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
>   fast.
>
> 2. Possibly use cases in security as the runtime of the function will
>be *more* oblivious to the byte sequences being compared.
>
>
>  Argument Specifications 
>
> 1. 's1'
> - All 'n' bytes in the byte sequence starting at 's1' and ending
>   at, but not including, 's1 + n' must be accessible memory. There
>   are no guarantees about the order the sequence will be
>   traversed.
> 2. 's2'
> - All 'n' bytes in the byte sequence starting at 's2' and ending
>   at, but not including, 's2 + n' must be accessible memory. There
>   are no guarantees about the order the sequence will be
>   traversed.
> 3. 'n'
> - 'n' may be any value that does not violate the specifications on
>   's1' and 's2'.
>
> If any of the argument specifications are violated there are no
> guarantees about the behavior of the interface.
>
>
>  Return Value Specification 
>
> If the byte sequences starting at 's1' and 's2' are equals the
> function will return zero. Otherwise the function will return a
> non-zero value.
>
> Equality between the byte sequences starting at 's1' and 's2' is
> defined as follows:
>
> 1. If 'n' is zero the two sequences are zero.
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
>offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()' could be as follows:
>
>
> int __memcmpeq(const void* s1, const void* s2, size_t n)
> {
> int ret;
> size_t i;
> const char *s1c, *s2c;
> s1c = (const char*)s1;
> s2c = (const char*)s2;
> for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> ret = s1c[i] - s2c[i]
> }
> return ret;
> }
>
>
>  Notes 
>
> This interface is essentially old 'bcmp()' and 'memcmp()' will always
> be a valid implementation of '__memcmpeq()'.
>
>
>  ABI vs API 
>
> This proposal is for '__memcmpeq()' as a new ABI. As an ABI
> '__memcmpeq()' will have value, as using the return value of
> 'memcmp()' is quite idiomatic in C code.
>
> It is, however, possible that this would also be useful as a new API
> as well. Especially if there are likely use cases where the compiler
> would be unable to prove that '__memcmpeq()' would be a valid
> replacement for 'memcmp()'.
>
>
>  Further Options 
>
> If this proposal is received positively, libc could also add
> interfaces for '__streq()', '__strneq()', '__wcseq()' and '__wcsneq()'
> which similarly would loosen return value restrictions on 'strcmp()',
> 'strncmp()', 'wcscmp()' and 'wcsncmp()' respectively.
>
> Best,
> Noah
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Joseph Myers]

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...@codesourcery.com

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[enh via Gcc]

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-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...@codesourcery.com
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Noah Goldstein via Gcc]

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 implemented as an alias to 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-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...@codesourcery.com
> >
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Chris Kennelly via Gcc]

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 sensitive to instruction cache effects, so
having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar,
but subtly different things can be a hidden performance cost--one that is
hard to demonstrate with a microbenchmark.  Our experience developing
optimized mem* routines ended up showing better performance in actual
applications when we accepted seemingly worse microbenchmark performance by
optimizing for code footprint instead (more extensive notes for mem* in
general

and
memcmp specifically (section 4.4)

).

The alternative would be to alias (as the NOTES suggest as a possible
implementation), but I think that raises James' question of why not just
use bcmp?  Dependencies on non-boolean implementations of bcmp seem
rare--namely, I haven't actually seen one.


> 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-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...@codesourcery.com
>>
>

gcc-9-20210916 is now available

[GCC Administrator via Gcc]

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 releases/gcc-9 
revision 22c708a2b4fb5da51a727d6c4a1faeff8470a2fe

You'll find:

 gcc-9-20210916.tar.xzComplete GCC

  SHA256=2d90a909ef13d79882b502ef631cc6096cbc80a29630ed5aed551ab4a62af926
  SHA1=28284e59ed1c26d823af0c632b55e5fd00eaa516

Diffs from 9-20210909 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Joseph Myers]

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 aliased to either __memcmpeq or memcmp 
(depending on whether there are concerns about existing binaries depending 
on bcmp acting like memcmp).  (And __memcmpeq and memcmp would be aliases 
on architectures without a separate optimized __memcmpeq.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[Noah Goldstein via Gcc]

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()/memcmp().
> >
>
> llvm-libc's implementation only returns the boolean, though.
>
> The mem* functions are extremely sensitive to instruction cache effects, so
> having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar,
> but subtly different things can be a hidden performance cost--one that is
> hard to demonstrate with a microbenchmark.  Our experience developing
> optimized mem* routines ended up showing better performance in actual
> applications when we accepted seemingly worse microbenchmark performance by
> optimizing for code footprint instead (more extensive notes for mem* in
> general
> <
> https://storage.googleapis.com/pub-tools-public-publication-data/pdf/4f7c3da72d557ed418828823a8e59942859d677f.pdf
> >
> and
> memcmp specifically (section 4.4)
> <
> https://storage.googleapis.com/pub-tools-public-publication-data/pdf/e52f61fd2c51e8962305120548581efacbc06ffc.pdf
> >
> ).
>

Regarding the code bloat found in memcmp in the paper, I think that is
pretty
exclusive to the sse4 implementation:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-sse4.S;h=b82adcd5fab5b60a0327819f6041a689a276916a;hb=HEAD

 And I think there is a fair argument to not include a __memcmpeq() based on
that implementation.

The older versions:
sse2:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/memcmp.S;h=870e15c5a080162b336b13bac24cf7afbac6874b;hb=HEAD
avx2:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S;h=2621ec907aedb781fcf0444e831c801f18fa68ba;hb=HEAD
evex:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-evex-movbe.S;h=654dc7ac8ccb9445b2c7107a7cf2d9f6ce4b1010;hb=HEAD

Have a much more reasonable code size footprint.

Also the __memcmpeq() code will itself have a smaller code size footprint
that memcmp()

With the implementations from my patch the code size is shrunk the
following:
sse2: -66
avx2: -436
avx2: -500




> The alternative would be to alias (as the NOTES suggest as a possible
> implementation), but I think that raises James' question of why not just
> use bcmp?  Dependencies on non-boolean implementations of bcmp seem
> rare--namely, I haven't actually seen one.
>
>
> > 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-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...@codesourcery.com
> >>
> >
>

Re: [FYI] bugzilla cleanup

[NightStrike via Gcc]

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.  An alternative would be to just
have "ice", and thus perhaps it might cause more overall bugs to get
fixed in the end.