Stefan Wallentowitz | 11 Dec 17:43 2014

[PATCH, OR1K] libgloss boards

Hi again,

the libor1k and crt0 depend on some symbols defined by the boards and 
call ini/exit functions there. Those are the pre-defined boards.

Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Stefan Wallentowitz | 11 Dec 17:41 2014

[PATCH, OR1K] libor1k

Hi again,

This patch is the libgloss' libor1k itself.

Attachment (or1k-libgloss.patch): text/x-patch, 79 KiB
Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Stefan Wallentowitz | 11 Dec 17:37 2014

[PATCH, OR1K] crt0

Hi again,

this patch contains the basic build files for ligbloss/or1k and the C 
runtime. It has some external dependencies that are fulfilled by libor1k 
and the board files that will follow.

Attachment (or1k-crt0.patch): text/x-patch, 28 KiB
Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Jonathan Roelofs | 11 Dec 17:08 2014

[Patch] Fix type signature of feof and ferror in c++

This fixes one of the libc++ tests: depr/depr.c.headers/stdio_h.pass.cpp

Jon Roelofs
jonathan <at>
CodeSourcery / Mentor Embedded
diff --git a/ChangeLog b/ChangeLog
index 5bea065..640bccf 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2014-12-11  Jonathan Roelofs  <jonathan <at>>
+	* libc/include/stdio.h: Fix type signature of feof and ferror in c++
 2014-07-05  Rainer Orth  <ro <at> CeBiTec.Uni-Bielefeld.DE>

 	* Don't accept isl 0.10.
diff --git a/newlib/libc/include/stdio.h b/newlib/libc/include/stdio.h
index c7d340c..7d9ac50 100644
--- a/newlib/libc/include/stdio.h
+++ b/newlib/libc/include/stdio.h
 <at>  <at>  -655,8 +655,8  <at>  <at>  _ELIDABLE_INLINE int __sputc_r(struct _reent *_ptr, int _c, FILE *_p) {
 #define	__sfileno(p)	((p)->_file)

 #ifndef _REENT_SMALL
-#define	feof(p)		__sfeof(p)
-#define	ferror(p)	__sferror(p)
(Continue reading)

Stefan Wallentowitz | 11 Dec 16:31 2014

[PATCH, OR1K] Support for optional delay slot

Dear all,

this patch adds support for the different variants of delay slots (its 
or1knd is the machine name without delay slot, or1k is the (standard) 
one with delay slot, and for compatibility we simply put a nop into the 
delay slot.


commit 0790c6718f2e51b45b03a8c77600bf8db22ef07b
Author: Stefan Wallentowitz <stefan.wallentowitz <at>>
Date:   Thu Dec 11 15:21:06 2014 +0100

     OR1K: Optional delay slot support

     The machine or1knd are OpenRISC implementations without delay slot

         * or1knd support, OpenRISC without delay slot
         * libc/include/machine/setjmp.h: Add or1knd
         * libc/machine/or1k/setjmp.S: Optional delay slot

diff --git a/config.guess b/config.guess
index 2055429..5e86705 100755
--- a/config.guess
+++ b/config.guess
 <at>  <at>  -967,6 +967,9  <at>  <at>  EOF
(Continue reading)

Stefan Wallentowitz | 11 Dec 16:22 2014

[PATCH, OR1K] Don't save parameter registers in setjmp/longjmp

Dear all,

this patch removes the save/restore of the parameter registers r3-r8 in 
setjmp/longjmp as they are not preserved across function calls.


Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Anthony Green | 11 Dec 12:54 2014

[Patch, moxie] Rebuild configure

One of my recent configury changes for the moxie target neglected to
include a rebuild configure file.  Here's that change, which I am
checking in....

2014-12-11  Anthony Green  <green <at>>

	* moxie/configure: Rebuilt.

Index: libgloss/moxie/configure
RCS file: /cvs/src/src/libgloss/moxie/configure,v
retrieving revision 1.2
diff -u -r1.2 configure
--- libgloss/moxie/configure	17 Jul 2013 06:14:27 -0000	1.2
+++ libgloss/moxie/configure	11 Dec 2014 11:51:02 -0000
 <at>  <at>  -585,6 +585,8  <at>  <at> 
 <at>  <at>  -2525,6 +2527,20  <at>  <at> 


(Continue reading)

Pei-Shiang Hung | 11 Dec 04:14 2014

[PATCH, NDS32] patch for nds32 port

Dear Jeff,

Attachments are patches for nds32 port.

Please help review.

Thank you.
Attachment (nds32_patches.tgz): application/x-gzip, 89 KiB
Stefan Wallentowitz | 10 Dec 11:48 2014

OpenRISC port

Dear all,

this is my first attempt to submit my OpenRISC port which I developed 
Due to the list's message size restrictions I cannot attach the patches:




The port is based on the never-upstreamed port maintained by the 
OpenRISC community. This one was unfortunately GPL and I corresponded 
with all authors in the final port to change the license to BSD.

The port is twofold: A rather large libgloss that contains a lot of 
baremetal support functions to handle exceptions, interrupts, etc. 
easily. Beside this, I added a sys folder for the or1k-elf target that 
uses dynamic reentrancy and depends on libgloss. The machine folder is 
still compatible with the or1k-rtems toolchain. I am really not sure if 
this is the way to go, so please comment on other ways.

The port already contains multicore support with a shared heap and 
private stacks, reentrancy data structures and port internal data 

(Continue reading)

Richard Earnshaw | 10 Dec 10:37 2014

[PATCH, AArch64]: Fix register allocation in strchrnul.S

Ooop!  I accidentally used a callee-saved register in the implementation
of strchrnul for AArch64.  Fortunately, the fix is trivial:

2014-12-10  Richard Earnshaw  <rearnsha <at>>

	* libc/machine/aarch64/strchrnul.S (vrepmask): Use a call-clobbered


Index: strchrnul.S
RCS file: /cvs/src/src/newlib/libc/machine/aarch64/strchrnul.S,v
retrieving revision 1.1
diff -u -p -r1.1 strchrnul.S
--- strchrnul.S	11 Jun 2014 10:42:54 -0000	1.1
+++ strchrnul.S	10 Dec 2014 09:21:54 -0000
 <at>  <at>  -55,7 +55,7  <at>  <at> 
 #define vhas_nul2	v4
 #define vhas_chr1	v5
 #define vhas_chr2	v6
-#define vrepmask	v15
+#define vrepmask	v7
 #define vend1		v16

 /* Core algorithm.
Yaakov Selkowitz | 9 Dec 21:58 2014

stdio_ext.h function implementations

Currently, the bulk of the <stdio_ext.h> functions[1][2] are implemented 
as inline code, or macros on non-gcc-compatible toolchains.  However, 
there are a few issues with that:

* Header-only implementations result in false negatives from 
AC_CHECK_FUNC tests and the like.  For instance, cpio FTBFS on Cygwin 
currently because it tries to implement a replacement for a "missing" 
__fpending which conflicts with the one already in <stdio_ext.h>.

* The Solaris and Linux documentation indicates that at least some, if 
not all, of these functions are thread-safe.  Does the current 
implementation suffice for that, or do these need to be real functions 
wrapped in _newlib_flockfile_{start,end} calls?

* Macro implementations of libc functions need to be undef'ed and backed 
by real functions with C++ (otherwise you get syntax errors in the 
::func form).  Are the inline implementations used by GCC safe for these 

* No documentation is generated for these functions.

In any case, for the first point alone, we need real code 
implementations of these functions.  I am prepared to make a patch for 
this, but exactly how depends on the second and third points above.



Yaakov Selkowitz
(Continue reading)