Kévin PETIT | 10 Jul 18:55 2014

[PATCH][AArch64] NEON-optimised memchr


Here’s an AArch64 NEON-optimised version of memchr. It has been tested on a
Cortex-A53 and Cortex-A57 and is on these cores vastly faster than all other
implementations I’ve found when searching more than a few bytes.

2014-07-10  Kévin Petit  <kevin.petit <at> arm.com>

	* libc/machine/aarch64/memchr.S: New file.
	* libc/machine/aarch64/memchr-stub.c: New file.
	* libc/machine/aarch64/Makefile.am: Add the new files.
	* libc/machine/aarch64/Makefile.in: Regenerated.


Nick Withers | 10 Jul 12:26 2014

[PATCH] Add missing strerror() strings, clean up

Hi all,

The attached patch:
- Adds to strerror()'s strerror.c strings for:
  - EADDRNOTAVAIL, "Address not available"
  - ECONNRESET, "Connection reset by peer"
  - EILSEQ, "Illegal byte sequence"
  - ENODATA, "No data" (full comment in errno.h was "No data (for no
delay io)")
  - EOVERFLOW, "Value too large for defined data type"

- Changes the following comments in errno.h to match the implementation:
  - EBADMSG, from "Trying to read unreadable message" to "Bad message"
  - EBUSY, from "Mount device busy" to "Device or resource busy"
  - ECONNABORTED, from "Connection aborted" to "Software caused
connection abort" (note that the previous comment reflected the
suggested text at
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html ,
perhaps here I should have changed the implementation instead?)
  - EDEADLK, from "Deadlock condition" to "Deadlock"
  - EDOM, from "Math arg out of domain of func" to "Math
argument" (would "Mathematics argument out of domain of function" or
"Mathematical (...)" be better?)
  - EILSEQ, from none to "Illegal byte sequence"
  - ENOLCK, from "No record locks available" to "No lock"
  - ENOLINK, from "The link has been severed" to "Virtual circuit is
gone" (reserved, according to
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html )
  - ENOMEM, from "Not enough core" to "Not enough space"
  - ENOSR, from "Out of streams resources" to "No stream resources"
(Continue reading)

Kyrill Tkachov | 3 Jul 17:29 2014

Default libm mode is XOPEN?

Hi all,

Looking at newlib/libm/common/fdlibm.h I see the lines:

/* REDHAT LOCAL: Default to XOPEN_MODE.  */
#define _XOPEN_MODE

Building an aarch64-none-elf compiler with newlib, the following test 
#include <stdio.h>
#include <math.h>

main (void)
   printf ("_LIB_VERSION: %d\n", _LIB_VERSION);
   printf ("_XOPEN_: %d\n", _XOPEN_);
   return 0;

_XOPEN_: 1

Is this /* REDHAT LOCAL: Default to XOPEN_MODE.  */ really intentional 
for all users of newlib?
I thought IEEE was supposed to be the default one. Or are targets 
expected to override this?

(Continue reading)

Thanks for email

Thanks for your email

This email is no long use . please resend your email to reservation <at> darahotels.com 

Best regard.

Bin Cheng | 26 Jun 09:43 2014

RE: [PATCH]Introducing small foot-print implementation for non-wide-char formatted IO

Hi Joel,
This message seems not delivered to mailing list because of rich format text.  Since newlib mailing list is
on CC list, I suppose you wanted it to be read publicly.
As for the question, it seems to me not very useful to list missing format specifiers because it would be mere
duplication of difference between C89 and any other standard.  To address your concern, I stated that only
C89 is supported in README, does it look good enough for you?


From: Joel Sherrill [mailto:Joel.Sherrill <at> oarcorp.com] 
Sent: Thursday, June 26, 2014 7:41 AM
To: Jeff Johnston
Cc: newlib <at> sourceware.org; Bin Cheng
Subject: Re: [PATCH]Introducing small foot-print implementation for non-wide-char formatted IO

Is there a specific list of missing format specifiers? Is C89 vs C99 all? 
I am just thinking that since you know what is missing, documenting it for you is easier than someone
recreating the list.
On Jun 25, 2014 6:27 PM, Jeff Johnston <jjohnstn <at> redhat.com> wrote:
Hi Bin,

Looks interesting.  I have a few minor comments/questions:

1. Your README section could be clarified.  Perhaps something like this:

+     This builds NEWLIB with a special implementation of formatted I/O functions, designed to
+     lower the size of applications on small systems with size constraint issues.  This option does not affect
(Continue reading)

Henderson, Stuart | 25 Jun 12:49 2014

Licensing and the newlib dir

"The newlib subdirectory is a collection of software from several sources.

Each file may have its own copyright/license that is embedded in the source
file.  Unless otherwise noted in the body of the source file(s), the following copyright
notices will apply to the contents of the newlib subdirectory: "

However, if a file has no copyright notice or license information, how are you supposed to correlate that
file to a particular license or copyright holder?

For instance, a lot of the crt files:
have nothing in them to suggest a license or copyright holder.

Do they default to the RedHat BSD license?   If so, is this the 2 or 3 clause BSD license?

Apologies if this is explained already.

(Continue reading)

Bin Cheng | 20 Jun 07:44 2014

[PATCH]Introducing small foot-print implementation for non-wide-char formatted IO


This is the second try to merge our work of formatted IO for small systems
originated from Newlib-nano library, in project "GNU Tools for ARM Embedded
Processors".  For the first time try, please refer to archived message at:

Since Newlib-nano in our project has been adopted/verified by many ARM
embedded developers and is relatively stable as far as I can see, here I am
trying again to upstream it.  In this patch I rebased/refactored code
against the latest trunk.  I also introduced a new configuration option
"--enable-newlib-nano-formatted-io" to control this small foot-print
implementation of formatted IO.  The new option can be used just like other
code size saving ones, and there is some straightforward description I added
for it in newlib/README, which is quoted here:

+     NEWLIB has a special implementation for formatted IO functions, it has
+     below features:
+      1) It only supports C89 standard and would never include other
+      2) It removes direct dependency on floating-point IO handling code.
+	 Programs that need to handle floating-point IO must now explicitly
+	 request the feature by providing options "-u _printf_float" or
+	 "-u _scanf_float" at linking command line.
+      3) It removes now redundant integer-only implementation of the
+	 printf/scanf family of routines (iprintf/iscanf, etc.).  These
+	 functions now alias the standard routines.  This avoids the risk
+	 of getting duplicated functionality when these operations are
+	 needed.  The affected functions are:
(Continue reading)

Richard Earnshaw | 11 Jun 12:45 2014

[AArch64] add optimized strchrnul

Hot on the heels of yesterday's strchr patch, here's the implementation
of strchrnul.  This is, in fact, easier to compute than strchr, since we
always return a non-null result, so we don't have to track why we've
finished scanning.

2014-06-11  Richard Earnshaw  <rearnsha <at> arm.com>

	* libc/machine/aarch64/strchrnul.S: New file.
	* libc/machine/aarch64/strchrnul-stub.c: New file.
	* libc/machine/aarch64/Makefile.am: Add them to build list.
	* libc/machine/aarch64/Makefile.in: Regenerated.

Index: Makefile.am
RCS file: /cvs/src/src/newlib/libc/machine/aarch64/Makefile.am,v
retrieving revision 1.8
diff -u -r1.8 Makefile.am
--- Makefile.am	10 Jun 2014 14:04:31 -0000	1.8
+++ Makefile.am	11 Jun 2014 09:39:27 -0000
 <at>  <at>  -20,6 +20,8  <at>  <at> 
 lib_a_SOURCES += setjmp.S
 lib_a_SOURCES += strchr-stub.c
 lib_a_SOURCES += strchr.S
+lib_a_SOURCES += strchrnul-stub.c
+lib_a_SOURCES += strchrnul.S
 lib_a_SOURCES += strcmp-stub.c
 lib_a_SOURCES += strcmp.S
 lib_a_SOURCES += strlen-stub.c
(Continue reading)

Richard Earnshaw | 10 Jun 16:08 2014

[AArch64] Add strchr optimized implementation.

This patch adds a hand-optimized assembly routine for strchr.  It makes
heavy use of Neon, permitting strings to be searched in chunks of 32
bytes at a time.  Benchmarking on Cortex-A57 suggests that this is very
rarely slower than a 'good' C implementation, but can be up to 3.5 times
as fast.

Because we use LD1 for fetching bytes from memory, there's no difference
between big-endian and little-endian code.

2014-06-10  Richard Earnshaw  <rearnsha <at> arm.com>

	* libc/machine/aarch64/strchr.S: New file
	* libc/machine/aarch64/strchr-stub.c: New file
	* libc/machine/aarch64/Makefile.am: Add them to build list.
	* libc/machine/aarch64/Makefile.in: Regenerated.


? autom4te.cache
Index: Makefile.am
RCS file: /cvs/src/src/newlib/libc/machine/aarch64/Makefile.am,v
retrieving revision 1.7
diff -u -r1.7 Makefile.am
--- Makefile.am	10 Jan 2013 13:02:19 -0000	1.7
+++ Makefile.am	10 Jun 2014 13:58:53 -0000
 <at>  <at>  -18,6 +18,8  <at>  <at> 
 lib_a_SOURCES += memset-stub.c
(Continue reading)

DJ Delorie | 10 Jun 00:50 2014

[patch] allow host-specific nano-malloc default

This patch makes a few minor changes to the configury to allow targets
to default to nano-malloc instead of the usual malloc.  It also makes
nano-malloc the default for msp430.  Ok to apply?

	* configure.host (default_newlib_nano_malloc): New.
	(msp430): Set it.
	* configure.in (newlib_nano_malloc): Leave unset if not set by
	the user.
	* configure: Regenerate.
	* libc/configure.in (NEWLIB_NANO_MALLOC): Set after running
	(newlib_nano_malloc): Leave unset if not set by	the user.
	* libc/configure: Regenerate.

Index: configure.host
RCS file: /cvs/src/src/newlib/configure.host,v
retrieving revision 1.134
diff -p -U 5 -r1.134 configure.host
--- configure.host	4 Apr 2014 21:40:58 -0000	1.134
+++ configure.host	9 Jun 2014 20:38:33 -0000
 <at>  <at>  -69,10 +69,11  <at>  <at>  have_sys_mach_dir=no
(Continue reading)

Herve SIBERT | 6 Jun 14:53 2014

License terms for specific newlib source files


We're working on an open-source project with BSD license, and planning to embed the following newlib
source files (from the "string" directory):

We've gone through the COPYING.NEWLIB list of licenses, but in order to keep things clear for end-users,
we'd like to include the exact license and copyright terms for each of these files. Are these files subject
to any license/copyright beyond that of RedHat? If so, which are the relevant licenses?

Besides, the RedHat license in COPYING.NEWLIB is pointing to BSD license definition on the OSI website but
does not mention whether it's the 2-Clause or the 3-Clause that applies. Which one should we take?

With best regards,