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> 

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>] 
Sent: Thursday, June 26, 2014 7:41 AM
To: Jeff Johnston
Cc: newlib <at>; 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>> 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>>

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

RCS file: /cvs/src/src/newlib/libc/machine/aarch64/,v
retrieving revision 1.8
diff -u -r1.8
---	10 Jun 2014 14:04:31 -0000	1.8
+++	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>>

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


? autom4te.cache
RCS file: /cvs/src/src/newlib/libc/machine/aarch64/,v
retrieving revision 1.7
diff -u -r1.7
---	10 Jan 2013 13:02:19 -0000	1.7
+++	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?

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

RCS file: /cvs/src/src/newlib/,v
retrieving revision 1.134
diff -p -U 5 -r1.134
---	4 Apr 2014 21:40:58 -0000	1.134
+++	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,

Emmanuel Blot | 15 May 22:29 2014

Cannot (cross-)build newlib 2.21 with GCC for arm-eabi target


I've been using newlib with GCC for many years (4.3 ... 4.9), but
starting with the very latest official tarball (2.1), I can no longer
build newlib along with GCC.

There is no issue if I replace newlib 2.1 with 2.0 using the very same
compiler source, and the same binutils package (2.24).

newlib/ and libgloss/ directories are copied to the top directory of
gcc source, and gcc is built out of source using the following
configure options (I've removed the path specifiers for the local
library reps (gmp, mpfr, etc.):

../configure --target=arm-eabi
             --disable-shared --with-gnu-as --with-gnu-ld
             --with-newlib --enable-softfloat --disable-bigendian
             --disable-fpu --disable-underscore --enable-multilibs
             --with-float=soft --enable-interwork --enable-lto
             --with-multilib --enable-plugins
             --with-abi=aapcs --enable-languages=cc++
             --with-gmp --with-mpfr --with-mpc --with-cloog
             --with-isl --with-libelf --enable-cloog-backend=isl
             --disable-debug --disable-__cxa_atexit

Here is the error message:

==> make
make[4]: *** No rule to make target
`../../../../libgloss/arm/../config/', needed by `Makefile'.
(Continue reading)

Markus Eisenmann | 15 May 14:34 2014

[PATCH: assert.h] Suppose nothrow-behaviour of assert-funcs (for g++)


Based on my current findings (I.e., optimizing compiler-output/code) and experiences with
I have the suggestion to "mark" the inner assert-functions __assert() and __assert_func() with nothrow. 

In most cases the assert-macro is used for debugging (w/o functional need). But in C++ definitions/ 
implementations with nothrow- or noexcept-semantik the GNU C++ compiler adds an exception-guard. 
Assuming that no other "throwing" call is used, this does not appear in a release build. 

Okay, I'm little pedantic about compiler-generated code ... :-) 

IMHO, following patch should applied to newlib's <assert.h> to give the compiler a small "hint", 
that the __assert-funcs does have a nothrow-behaviour (in addition to the noreturn-semantik): 

--- assert.h Tue Oct 16 21:00:30 2012 
+++ assert.h Thu May 15 14:00:48 2014 
 <at>  <at>  -37,7 +37,7  <at>  <at>  
#endif /* !NDEBUG */ 

-void _EXFUN(__assert, (const char *, int, const char *) 
+void _EXFUN_NOTHROW(__assert, (const char *, int, const char *) 
_ATTRIBUTE ((__noreturn__))); 
-void _EXFUN(__assert_func, (const char *, int, const char *, const char *) 
+void _EXFUN_NOTHROW(__assert_func, (const char *, int, const char *, const char *) 
_ATTRIBUTE ((__noreturn__))); 

Best regards from Salzburg, 
(Continue reading)