Joel Sherrill | 5 Sep 16:37 2014

inttypes.h bug leads to inconsistent warnings cross platform

Hi

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

Hi,
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?

Thanks,
bin

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

	* libc/stdio/findfp.c (_cleanup_r): Call _fflush_r when
configuration
	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 *);
 #ifdef _STDIO_BSD_SEMANTICS
   /* 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

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

Thanks,
bin

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

	* 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> sourceware.org [mailto:newlib-
> owner <at> sourceware.org] On Behalf Of Corinna Vinschen
> Sent: 2014年9月4日 16:24
> To: newlib <at> sourceware.org
> 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/Makefile.am: Add dependencies.
> > 	* libc/machine/arm/Makefile.in: Regenerated.
> 
> Applied.
> 
> 
> Thanks,
(Continue reading)

Joel Sherrill | 4 Sep 16:54 2014

RTEMS Size Information on printf, gmtime, etc

Hi

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)

base:
  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
Picon

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
Picon

[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.

Regards,
(Continue reading)

Joern Rennecke | 3 Sep 21:26 2014

Re: selective linking of floating point support for *printf / *scanf

On 2 September 2014 16:28, Joseph S. Myers <joseph <at> codesourcery.com> wrote:
> On Tue, 2 Sep 2014, Joey Ye wrote:
>
>> Apparently newlib is not following this specification very well, as
>> there are symbols like _abc_r defined every where in current newlib. I
>> am not implying the spec should not be followed, but is newlib
>> designed to have a loose spec for the single underscore?
>
> Identifiers beginning with a single underscore are reserved with file
> scope.  This means an application cannot provide an external definition of
> them, because such an external definition would have file scope.  So it's
> fine for the implementation to define such identifiers and use them in the
> implementation of standard functions.

Hmm, this trows up another question how in GNU C, extensions interact with
the putatively unchanged parts of the standard.
If a user program defines an assembler name for a global function which is
different from the name used in the source code, is that assembler name
used at file scope?  It would seem to me it's only used at global/link scope.
As such, is the use of _[a-z].* as assembly names then part of the
user namespace?

Freddie Chopin | 3 Sep 20:16 2014
Picon

Fix some warnings in time sources

Patches and ChangeLog entry attached.

Regards,
FCh
2014-09-03  Freddie Chopin  <freddie_chopin <at> op.pl>

	* libc/time/clock.c (clock): Fix warnings about signed-unsigned
	comparisons.
	* libc/time/strftime.c (strftime): Likewise.
	* libc/time/strptime.c (match_string): Fix warning about discarding
	'restrict' qualifier from pointer target type.
From 64bf9acee35a830268c6e09b3ecb04b591ea8407 Mon Sep 17 00:00:00 2001
From: Freddie Chopin <freddie.chopin <at> gmail.com>
Date: Wed, 3 Sep 2014 20:06:51 +0200
Subject: [PATCH 1/2] libc/time/clock.c, libc/time/strftime.c: fix "comparison
 between signed and unsigned integer expressions" warnings

---
 newlib/libc/time/clock.c    | 2 +-
 newlib/libc/time/strftime.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/newlib/libc/time/clock.c b/newlib/libc/time/clock.c
index 64cf438..0bcfbb6 100644
--- a/newlib/libc/time/clock.c
+++ b/newlib/libc/time/clock.c
(Continue reading)

Freddie Chopin | 3 Sep 19:30 2014
Picon

[PATCH] _mktm_r: optimize speed

I attach patch (with ChangeLog entry) for _mktm_r() which replaces 
iterative calculations of day with a few divisions and multiplications.

This change results in the function working two times faster on ARM 
Cortex-M3 microcontroller - one million calls of "old" function using 
random numbers take ~70s, while the same calculations with "new" code 
take ~33s (clock of chip is 16MHz). Obviously the improvement depends on 
the input value - sometimes the patched code can be slower than the old 
one - for input values "close" to year 1970. On the other hand, the 
"further" from 1970, the bigger is the performance gain.

Both versions give the same results - tested with a few million random 
numbers - both versions were called for the same input value and result 
was compared with memcmp().

Regards,
FCh
2014-09-03  Freddie Chopin  <freddie_chopin <at> op.pl>

	* libc/time/mktm_r.c (_mktm_r): Optimize speed.
From 1179360279c5ba9b9c1bf53ccfa0b46f1bbdfc61 Mon Sep 17 00:00:00 2001
From: Freddie Chopin <freddie.chopin <at> gmail.com>
Date: Wed, 3 Sep 2014 19:16:12 +0200
Subject: [PATCH] _mktm_r: optimize speed

---
(Continue reading)

Thomas Preud'homme | 3 Sep 08:58 2014

RE: selective linking of floating point support for *printf / *scanf

> From: Joseph S. Myers [mailto:joseph <at> codesourcery.com]
> Sent: Tuesday, September 02, 2014 11:29 PM
> 
> Identifiers beginning with a single underscore are reserved with file
> scope.  This means an application cannot provide an external definition of
> them, because such an external definition would have file scope.  So it's
> fine for the implementation to define such identifiers and use them in the
> implementation of standard functions.

Ah yes, I mistook file scope with file scope with internal linkage. So then there
shouldn't be any problem since _printf_float and _scanf_float are only used
for external linkage, no macro refer to them.

Best regards,

Thomas 


Gmane