Freddie Chopin | 15 Sep 19:37 2014

Patches for various warnings in string/...


I attach 4 patches with a single ChangeLog entry for various warnings 
detected in string/ subfolder of newlib's libc. The changes are pretty 
trivial and self-explaining - I hope (;

2014-09-15  Freddie Chopin  <freddie_chopin <at>>

	* libc/string/memccpy.c (memccpy): Fix warning about signed-unsigned
	* libc/string/memchr.c (memchr): Ditto.
	* libc/string/memrchr.c (memrchr): Ditto.
	* libc/string/memset.c: (memset): Ditto.
	* libc/string/rawmemchr.c (rawmemchr): Ditto.
	* libc/string/local.h (__locale_cjk_lang): Fix "function declaration
	isn't a prototype" warning.
	* libc/string/strcasestr.c (strcasestr): Ditto.
	* libc/string/u_strerr.c (_user_strerror): Fix "unused parameter"
	* libc/string/rawmemchr.c (rawmemchr): Fix comment type
	"// ..." -> "/* ... */".
From f1eed1d6e0bca402567b0bbcec648221c2da0ce4 Mon Sep 17 00:00:00 2001
From: Freddie Chopin <freddie.chopin <at>>
Date: Sat, 13 Sep 2014 10:15:50 +0200
(Continue reading)

Pavel Pisa | 14 Sep 16:45 2014

[PATCH/RFC] More strict __DECONST, __DEVOLATILE and __DEQUALIFY implementation.

From: Pavel Pisa <ppisa <at>>

This implementation is able to catch cast to type
which differs not only in qualifiers. It suppresses
warning about incompatible pointer assignment only for
case where pointer types differs in volatile and const
in the first indirection level. If pointers differs
other way, the standard waning is reported.

The actual implementation does not distinguish between
volatile and const removal which is equivalent
to the C++ const_cast which is used for C++ code
too. This can be implemented but there would be
much more lines.

Signed-off-by: Pavel Pisa <pisa <at>>
 newlib/libc/include/sys/cdefs.h | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

This patch tries to restore some safety in pointers manipulation.
The __DECONST, __DEVOLATILE and __DEQUALIFY macros supress
false warning but original implementation hides more serious
errors when pointers for different types are mixed.

The proposed solution has been tested in some of our projects
and proposed even for RTEMS but discussion with people more
aware of GCC internals is welcomed. I am not sure why cast
to __uintptr_t is used in original code - for warnings
suppression it is not necessary for C/GCC mode. Use of const_cast
(Continue reading)

Logan Anteau | 12 Sep 23:21 2014

tzcalc_limits.c:49:28: error: 'month_lengths' undeclared

I believe tzcalc_limits.c line 49 should use __month_lengths instead.


Thomas Uhle | 9 Sep 20:05 2014

Support for long long type for C99 and C++11 compliant compilers


the attached patch fixes some issues with long long type support for
compilers that have C99 or C++11 compliance. For instance, llabs(),
lldiv() and atoll() have been missing if g++ was invoked with option


Thomas Uhle


Thomas Uhle
System Specification Mixed-Signal Systems
Fraunhofer Institute for Integrated Circuits IIS
Design Automation Division EAS
Zeunerstr. 38, 01069 Dresden, Germany
phone: +49 (0) 351 4640-786
mailto:thomas.uhle <at>
Joel Sherrill | 5 Sep 16:37 2014

inttypes.h bug leads to inconsistent warnings cross platform


This code will compile warning free on some targets but not
on others. This issue should exist on all targets base on the
CPU architecture as shown below.

#include <stdio.h>
#include <inttypes.h>

void f( uintptr_t p )
  printf( "Value = %" PRIuPTR "\n", p );

This is a list of warning/no warning for every RTEMS target
that compiles on the head.

=== arm-rtems4.11-gcc - no warning
=== bfin-rtems4.11-gcc - warning
=== i386-rtems4.11-gcc - warning
=== lm32-rtems4.11-gcc - no warning
=== m68k-rtems4.11-gcc - warning
=== nios2-rtems4.11-gcc - no warning
=== or1k-rtems4.11-gcc - warning
=== powerpc-rtems4.11-gcc - no warning
=== sh-rtems4.11-gcc - no warning
=== sparc64-rtems4.11-gcc - no warning
=== sparc-rtems4.11-gcc - no warning
=== v850-rtems4.11-gcc - no warning

(Continue reading)

Bin Cheng | 5 Sep 05:33 2014

[PATCH Newlib]Call _fflush_r instead of _fclose_r when cleanup if --enable-lite-exit is in effect

Currently there is a FIXME in _cleanup_r in newlib, saying we may want to
call _fflush_r instead of _fclose_r.  This patch fixes the problem by using
--enable-lite-exit.  It makes sense to call light weight function _fflush_r
when lite exit is in effect.

Build and link with/without --enable-lite-exit.  Is it OK?


2014-09-05  Bin Cheng  <bin.cheng <at>>

	* libc/stdio/findfp.c (_cleanup_r): Call _fflush_r when
	option "--enable-lite-exit" is in effect.  Refactor the code.
diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
index 9ee43b5..deb5163 100644
--- a/newlib/libc/stdio/findfp.c
+++ b/newlib/libc/stdio/findfp.c
 <at>  <at>  -174,17 +174,22  <at>  <at>  _VOID
 _DEFUN(_cleanup_r, (ptr),
        struct _reent *ptr)
+  int (*cleanup_func) (struct _reent *, FILE *);
   /* BSD and Glibc systems only flush streams which have been written to
      at exit time.  Calling flush rather than close for speed, as on
      the aforementioned systems. */
(Continue reading)

Bin Cheng | 5 Sep 05:14 2014

[PATCH]Remove redundant test for _fwalk_reent

This is a simple patch removing redundant test in function _fwalk_reent.  Is
it OK?


2014-09-05  Bin Cheng  <bin.cheng <at>>

	* libc/stdio/fwalk.c (_fwalk_reent): Remove redundant test.
diff --git a/newlib/libc/stdio/fwalk.c b/newlib/libc/stdio/fwalk.c
index 975e4b0..cceaa96 100644
--- a/newlib/libc/stdio/fwalk.c
+++ b/newlib/libc/stdio/fwalk.c
 <at>  <at>  -73,11 +73,8  <at>  <at>  _DEFUN(_fwalk_reent, (ptr, reent_function),
   for (g = &ptr->__sglue; g != NULL; g = g->_next)
     for (fp = g->_iobs, n = g->_niobs; --n >= 0; fp++)
-      if (fp->_flags != 0)
-        {
-          if (fp->_flags != 0 && fp->_flags != 1 && fp->_file != -1)
-            ret |= (*reent_function) (ptr, fp);
-        }
+      if (fp->_flags != 0 && fp->_flags != 1 && fp->_file != -1)
+	ret |= (*reent_function) (ptr, fp);

   return ret;
(Continue reading)

Hale Wang | 5 Sep 04:14 2014

RE: Support __aeabi_memcpy, __aeabi_memcpy4 and __aeabi_memcpy8 routines in the arm backend.

Hi Corinna,

Thanks for your help to commit the aeabi_memcpy patch. There may be a problem that you have missed the file
"aeabi_memcpy.c". This may cause the make failed. Would you please help to fix this?

Thanks and Best Regards,
Hale Wang

> -----Original Message-----
> From: newlib-owner <at> [mailto:newlib-
> owner <at>] On Behalf Of Corinna Vinschen
> Sent: 2014年9月4日 16:24
> To: newlib <at>
> Subject: Re: Support __aeabi_memcpy, __aeabi_memcpy4 and
> __aeabi_memcpy8 routines in the arm backend.
> On Sep  3 15:55, Hale Wang wrote:
> > Hi,
> >
> > This patch is used to resubmit the previous aeabi_memcpy patch.
> > [...]
> > 	* libc/machine/arm/aeabi_memcpy.c: New file.
> > 	* libc/machine/arm/aeabi_memcpy-armv7a.S: New file.
> > 	* libc/machine/arm/ Add dependencies.
> > 	* libc/machine/arm/ Regenerated.
> Applied.
> Thanks,
(Continue reading)

Joel Sherrill | 4 Sep 16:54 2014

RTEMS Size Information on printf, gmtime, etc


I thought having something to compare to on an architecture
with less than the densest code might provide some insight.

The code is attached. Most RTEMS applications are statically
linked including the RTOS services needed, libc services needed,
BSP startup and shutdown, etc.  I started with the Init()
task only having a call to exit(0) and then progressively added
calls so we could see what each added.

- sparc v7 (erc32) at -O2
- start up, single task, exit(0)

  66688       1408       7856      75952      128b0    o-optimize/time01.exe

add start and end printf (constant strings):
  73616       1408       7856      82880      143c0    o-optimize/time01.exe

add call to time():
  75840       1408       7856      85104      14c70    o-optimize/time01.exe

add gmtime call()
  77888       1472       7856      87216      154b0    o-optimize/time01.exe

add printf() to print MM/DD/YY HH::MM::SS
 106720       1600       7856     116176      1c5d0    o-optimize/time01.exe

I hope this provides a useful set of data.
(Continue reading)

Freddie Chopin | 4 Sep 12:56 2014

Re: [PATCH] libc/time/gmtime_r.c, libc/time/lcltime_r.c,, libc/time/local.h, libc/time/mktm_r.c: move localtime related functionality, from _mktm_r() to new _mklocaltm_r() to break dependency of gmtime() on, timezones

W dniu 2014-09-04 10:36, Corinna Vinschen pisze:
> How does that work?  _mktm_r and _mklocaltm_r are still in the same source
> file, so if you get one, you also get the other.  Where did you get your
> savings from?

Hmm... My tests were done by compiling newlib sources as part of the 
project, and I always use "-ffunction-sections -fdata-sections" for 
compilation and "--gc-sections" for linking, so that unused functions 
are removed even if they are in the same file.

I guess that for this savings to work in "normal" scenario (newlib used 
as a library) these would really need to be split, right?

Initially I planned to split these functions to separate files, but I 
didn't feel like modifying makefiles and there's the problem of sharing 
the arrays (all of these functions use the array with number of days in 
the months).

If such separation is required, I'd like to extend the change further, 
doing deeper changes that would actually simplify stuff. First of all - 
in my opinion - this _mktm_r() is actually not very useful (in the 
patched version) - it's just gmtime_r() - I'd like to move all this code 
to gmtime_r(). This new function which does time zone adjustments - 
_mklocaltm_r() - is not really useful alone too - I'd like to move all 
that code to localtime_r(), which would initially just call gmtime_r(), 
then do the time zone adjustments on the result. The only local/internal 
function that would be left would be __tzcalc_limits() which is used by 
3 other functions. Array mon_lengths[] from mktm_r.c would probably need 
to be put in separate source file - it is used by _mktm_r() 
(gmtime_r()), _mklocaltm_r() (localtime_r()) and __tzcalc_limits().
(Continue reading)

Freddie Chopin | 3 Sep 21:59 2014

[PATCH] libc/time/gmtime_r.c, libc/time/lcltime_r.c,, libc/time/local.h, libc/time/mktm_r.c: move localtime related functionality, from _mktm_r() to new _mklocaltm_r() to break dependency of gmtime() on, timezones

Hello again (;

I attach patch and a ChangeLog entry with a bigger change to 
time-related sources.

Currently functions gmtime() and localtime() are both implemented with 
common code in _mktm_r(), which decides whether to do time zone 
adjustments by additional parameter - is_gmtime, true for gmtime() and 
false for localtime(). This way if you use gmtime() and don't care about 
time zones, you get them anyway in the final binary.

This change moves all time zone related stuff from _mktm_r() to new 
function _mklocaltm_r(). gmtime_r() still calls _mktm_r() (but with this 
boolean parameter removed), while localtime_r() first calls _mktm_r() 
and then calls _mklocaltm_r() using the result of _mktm_r().

This way you get time zone stuff in the final link only if it's really 
needed - when you use localtime(). If you use just gmtime(), the time 
zone functions are not linked, which saves about 1kB of flash and a 
little below 100B of RAM (on ARM Cortex-M3). (the savings would be 
bigger if proper locks are implemented - by default only stubs are used 
and no code for mutexes is needed)

Actually the names of the functions are not 100% good, but changing the 
name of _mktm_r() to something clearer (_mkgmtime_r()?) should come with 
changing the name of the source file, so I decided to leave that as it 
is... If you think that the names should change too, I could modify the 
patch and extend it.

(Continue reading)