[PATCH] MAINTAINERS: Update email address

[Joel Sherrill]

---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 15973503722..847df62a934 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -145,7 +145,7 @@ solaris Rainer Orth 

 netbsd Jason Thorpe
 netbsd Krister Walfridsson 
 sh-linux-gnu   Kaz Kojima  
-RTEMS PortsJoel Sherrill   
+RTEMS PortsJoel Sherrill   
 RTEMS PortsRalf Corsepius  
 RTEMS PortsSebastian Huber 

 VMSDouglas Rupp
-- 
2.24.4

Re: [PATCH][GCC] arm: Add Cortex-R52+ multilib

[Joel Sherrill]

On Thu, Sep 30, 2021, 3:37 PM Przemyslaw Wirkus 
wrote:

> > Subject: Re: [PATCH][GCC] arm: Add Cortex-R52+ multilib
> >
> > I think the RTEMS multilibs are based on the products that RTEMS
> supports,
> > so this is really the RTEMS maintainers' call.
> >
> > Joel?
>
> Ping :)
>

I'm ok deferring it since Sebastian doesn't think there is a user right
now. But I'm actually rather ambivalent. If it makes it easier to maintain
versus the other embedded arm targets then I'm all for it. Maintaining
these configurations are a pain.

--joel


> > On 22/09/2021 09:46, Przemyslaw Wirkus via Gcc-patches wrote:
> > > Patch is adding multilib entries for `cortex-r52plus` CPU.
> > >
> > > See:
> > > https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52-plus
> > >
> > > OK for master?
> > >
> > > gcc/ChangeLog:
> > >
> > > 2021-09-16  Przemyslaw Wirkus  
> > >
> > > * config/arm/t-rtems: Add "-mthumb -mcpu=cortex-r52plus
> > > -mfloat-abi=hard" multilib.
> > >
>

Re: GCC documentation: porting to Sphinx

[Joel Sherrill]

For RTEMS, we switched from texinfo to Sphinx and the dependency
on Python3 for Sphinx has caused a bit of hassle. Is this going to be
an issue for GCC?

Also we rely on TexLive for PDF output and that's a bit of a pain to
install. Tex was incorrectly packaged on some RHEL/CentOS versions.

This ignores a couple of plugins we use that I don't expect GCC to use.

It works great but the host dependencies are sometimes a pain. We've
ended up writing host OS specific advice/howto's to address this. Any
expectations on host pain versus the pretty painless texinfo?

Thanks.

--joel
RTEMS

On Wed, Jun 2, 2021 at 2:37 AM Martin Liška  wrote:

> On 6/1/21 3:31 PM, Michael Matz wrote:
> > Hello,
> >
> > On Tue, 1 Jun 2021, Martin Liška wrote:
> >
> >> On 5/31/21 5:49 PM, Michael Matz wrote:
> >>> Hello Martin,
> >>>
> >>> On Mon, 31 May 2021, Martin Liška wrote:
> >>>
>  I've made quite some progress with the porting of the documentation
> and
>  I would like to present it to the community now:
>  https://splichal.eu/scripts/sphinx/
> Note the documentation is automatically ([1]) generated from
> texinfo with
>  a
>  GitHub workflow ([2]).
> >>>
> >>> One other thing I was recently thinking about, in the Spinx vs. texinfo
> >>> discussion: locally available documentation browsable/searchable in
> >>> terminal with info(1) (or equivalents).
> >>
> >> Yes, that's handy.
> >>
> >>> I think the above (i.e. generating .rst from the texinfo file) would
> >>> immediately nullify all my worries.  So, just to be extra sure: your
> >>> proposal now is to generate the .rst files, and that .texinfo remains
> >>> the maintained sources, right?
> >>
> >> No, .texinfo files will be gone. However, Sphinx can output to info
> >> format:
> >>
> https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-M
> >
> > I see, that's good to hear.
> >
> >> And I've just added the generated Info pages here:
> >> https://splichal.eu/scripts/sphinx/
> >
> > Okay, but there's something amiss, just compare a local gcc.info with
> > that.  The sphinx generated one seems to only contain command line
> > options, but none of the other topics, in particular it seems to contain
> > the "Invoking GCC" chapter (and only that) as top-level, and all other
> > ones are missing (like "C implementation", "C++ implementation", "C
> > extension", and so on).
>
> You are right, I reduced that to 'Invoking GCC', which is simply what 'man
> gcc'
> presents. However, I moved that back to the entire GCC manual what you can
> see now in the info page.
>
> >
> > Looking at gccint.info I also seem quite some confusion, it's unclear to
> > me if content is missing or not.  But e.g. the top-level structure has a
> > different order (a less logical one, this one is btw. shared with the
> > order of the HTML generated docu, so it's probably specific to sphinx
> > setup or such).
>
> Yes, the organization was bad and I fixed that. Now it's much better.
>
> Martin
>
> >
> > Ignoring that missing content what is there right now does seem somewhat
> > acceptable for local use, though.
> >
> >
> > Ciao,
> > Michael.
> >
>
>

Re: [PATCH] RTEMS: Add LEON3/SPARC multilibs

[Joel Sherrill]

Committed to the head.

Is this too radical to also go on the 4.8 branch?
We would need to discuss it on the RTEMS side but it
only impacts us if the multilib is there for sparc-elf
on 4.8.

Thanks Sebastian.

On 8/30/2013 6:58 AM, Daniel Hellstrom wrote:
> Hello Sebastian,
> 
> That seems like a good idea.
> 
> Thanks,
> Daniel
> 
> 
> On 08/29/2013 01:04 PM, Sebastian Huber wrote:
>> Recently support for LEON3 specific instructions were added to GCC.
>> Make this support available for RTEMS.
>>
>> This patch should be committed to GCC 4.9.
>>
>> gcc/ChangeLog
>> 2013-08-29  Sebastian Huber  
>>
>>  * config/sparc/t-rtems: Add leon3 multilibs.
>> ---
>>   gcc/config/sparc/t-rtems |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
>> index 63d0217..f1a3d84 100644
>> --- a/gcc/config/sparc/t-rtems
>> +++ b/gcc/config/sparc/t-rtems
>> @@ -17,6 +17,6 @@
>>   # <http://www.gnu.org/licenses/>.
>>   #
>>   
>> -MULTILIB_OPTIONS = msoft-float mcpu=v8
>> -MULTILIB_DIRNAMES = soft v8
>> +MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3
>> +MULTILIB_DIRNAMES = soft v8 leon3
>>   MULTILIB_MATCHES = msoft-float=mno-fpu
> 



-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

[PATCH 1/3] Add aarch64-*-rtems* target

[Joel Sherrill]

* gcc/config.gcc, libgcc/config.host: Add aarch64-*-rtems*.
* gcc/config/aarch64/rtems.h: New file.
---
 gcc/config.gcc | 11 +--
 gcc/config/aarch64/rtems.h | 28 
 libgcc/config.host |  2 +-
 3 files changed, 38 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/aarch64/rtems.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index e26742e..3b280e0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -906,11 +906,18 @@ case ${target} in
 esac
 
 case ${target} in
-aarch64*-*-elf)
+aarch64*-*-elf | aarch64*-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-elf-raw.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
-   use_gcc_stdint=wrap
+   case $target in
+   aarch64-*-elf*)
+   use_gcc_stdint=wrap
+   ;;
+   aarch64-*-rtems*)
+   tm_file="${tm_file} rtems.h aarch64/rtems.h"
+   ;;
+   esac
case $target in
aarch64_be-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
diff --git a/gcc/config/aarch64/rtems.h b/gcc/config/aarch64/rtems.h
new file mode 100644
index 000..a166034
--- /dev/null
+++ b/gcc/config/aarch64/rtems.h
@@ -0,0 +1,28 @@
+/* Definitions for RTEMS based AARCH64 system.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+ 
+   This file is part of GCC.
+ 
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+ 
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+ 
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#define HAS_INIT_SECTION
+
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+do {   \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+} while (0)
diff --git a/libgcc/config.host b/libgcc/config.host
index ef7dfd0..1f85c46 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -327,7 +327,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 esac
 
 case ${host} in
-aarch64*-*-elf)
+aarch64*-*-elf | aarch64*-*-rtems*)
extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
-- 
1.8.3.1

[PATCH 2/3] Add x86_64-*-rtems* target

[Joel Sherrill]

* gcc/config.gcc, libgcc/config.host: Add x86_64-*-rtems*.
* gcc/config/i386/rtems-64.h: New file.
---
 gcc/config.gcc |  3 +++
 gcc/config/i386/rtems-64.h | 30 ++
 libgcc/config.host |  2 +-
 3 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/i386/rtems-64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3b280e0..4cc6438 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1421,6 +1421,9 @@ i[34567]86-*-elf*)
 x86_64-*-elf*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/x86-64.h"
;;
+x86_64-*-rtems*)
+   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtems-64.h"
+   ;;
 i[34567]86-*-rdos*)
 tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
newlib-stdint.h i386/i386elf.h i386/rdos.h"
 ;;
diff --git a/gcc/config/i386/rtems-64.h b/gcc/config/i386/rtems-64.h
new file mode 100644
index 000..b087d44
--- /dev/null
+++ b/gcc/config/i386/rtems-64.h
@@ -0,0 +1,30 @@
+/* Definitions for rtems targeting an x86_64
+   Copyright (C) 2016 Free Software Foundation, Inc.
+   Contributed by Joel Sherrill (j...@oarcorp.com).
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+/* Specify predefined symbols in preprocessor.  */
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+}  \
+  while (0)
diff --git a/libgcc/config.host b/libgcc/config.host
index 1f85c46..b61a579 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -577,7 +577,7 @@ i[34567]86-*-elfiamcu)
 i[34567]86-*-elf*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
;;
-x86_64-*-elf*)
+x86_64-*-elf* | x86_64-*-rtems*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
;;
 i[34567]86-*-dragonfly*)
-- 
1.8.3.1

[PATCH 3/3] contrib/config-list.mk: Add aarch64-rtems and x86_64-rtems

[Joel Sherrill]

* contrib/config-list.mk: Add aarch64-rtems and x86_64-rtems
---
 contrib/config-list.mk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 0f15464..6a83a84 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -11,7 +11,7 @@ TEST=all-gcc
 # nohup nice make -j25 -l36 -f ../gcc/contrib/config-list.mk > make.out 2>&1 &
 #
 # v850e1-elf is rejected by config.sub
-LIST = aarch64-elf aarch64-linux-gnu \
+LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   alpha-linux-gnu alpha-freebsd6 alpha-netbsd alpha-openbsd \
   alpha64-dec-vms alpha-dec-vms am33_2.0-linux \
   arc-elf32OPT-with-cpu=arc600 arc-elf32OPT-with-cpu=arc700 \
@@ -76,7 +76,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
   x86_64-knetbsd-gnuOPT-enable-obsolete x86_64-w64-mingw32 \
-  x86_64-mingw32OPT-enable-sjlj-exceptions=yes xstormy16-elf xtensa-elf \
+  x86_64-mingw32OPT-enable-sjlj-exceptions=yes x86_64-rtems \
+  xstormy16-elf xtensa-elf \
   xtensa-linux \
   i686-interix3OPT-enable-obsolete
 
-- 
1.8.3.1

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

[Joel Sherrill]

On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer  wrote:
>On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
>> I propose to commit this patch later this week.
>
>+   Support for revisions of the ARM architecture prior to ARMv4t
>has
>+   been deprecated and will be removed in a future GCC release.
>+   This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM,
>and
>+   Faraday fa526 and fa626 devices, which do not have support for
>+   the Thumb execution state.
>
>I am wondering whether this may be confusing for those not 
>intricately familiar with the older history of ARM platforms.
>
>ARMv8 is pretty new, googling for it has 
>  http://www.arm.com/products/processors/armv8-architecture.php
>as first hit, for example, and the only difference versus ARM8 
>is that little lower-case "v".

I assume this means a number of values for the various -mXXX arguments will be 
removed. Would it be more helpful to list those values?

I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs 
but based on that wording, I don't know which.

>Gerald

--joel

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

[Joel Sherrill]

On 2/29/2016 5:37 AM, Kyrill Tkachov wrote:


On 28/02/16 21:34, Joel Sherrill wrote:


On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer  wrote:

On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:

I propose to commit this patch later this week.

+   Support for revisions of the ARM architecture prior to ARMv4t
has
+   been deprecated and will be removed in a future GCC release.
+   This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM,
and
+   Faraday fa526 and fa626 devices, which do not have support for
+   the Thumb execution state.

I am wondering whether this may be confusing for those not
intricately familiar with the older history of ARM platforms.

ARMv8 is pretty new, googling for it has
   http://www.arm.com/products/processors/armv8-architecture.php
as first hit, for example, and the only difference versus ARM8
is that little lower-case "v".

I assume this means a number of values for the various -mXXX arguments will be 
removed. Would it be more helpful to list those values?

I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs 
but based on that wording, I don't know which.


ARM8 is a processor, whereas ARMv8-A is an architecture.
I think Richard's link earlier in the thread:

https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors

gives a good explanation of the naming schemes.
The -mcpu/-mtune arguments that would be deprecated can be found by looking at 
the
file config/arm/arm-cores.def and finding all the ARM_CORE entries that have 
'4' or lower in their
4th field These would be:


That you referred to code to know the impact seems to confirm my concern that 
this is not something most users would realize.


arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710,
arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110,
strongarm1100,strongarm1110,fa526,fa626.

The arguments to -march that would be deprecated are:
armv2,armv2a,armv3,armv3m,armv4.

I personally think that list is a bit too long for changes.html.


It didn't seem that long and makes a nice checklist.

FWIW I am one of the original RTEMS developers, 25+ years of embedded work, 
gcc, etc. and I couldn't have have evaluated the impact of the original 
statement easily. Those with more knowledge ARM GCC specifics (like you) gave a 
precise detailed answer with what sounds like just a few minutes.


Do you think it would add more clarity for people who are not familiar with the 
situation?


Absolutely. That's an authoritative list. From that list, anyone can grep their 
build system to see which boards and configurations would be impacted.

And honestly, when I saw the initial statement, I was concerned about how many 
older ARM RTEMS BSPs would be obsoleted. But seeing the specific list, I don't 
think we have any that are impacted.

The extra information just makes it very precise and clear what's going away.

FWIW I am on a standards group and one of the things I repeatedly say is that 
if we leave room for someone to ask a question, then they have a chance to get 
an answer we didn't intend. So try to avoid letting someone with less knowledge 
ask the question. :)

--joel


Thanks,
Kyrill


Gerald

--joel

Re: [PATCH v2] RTEMS: Generalize t-rtems usage

[Joel Sherrill]

-rtems"
>   tm_file="h8300/h8300.h dbxelf.h elfos.h h8300/elf.h h8300/rtems.h 
> rtems.h newlib-stdint.h"
>   ;;
>  h8300-*-elf*)
> @@ -1500,7 +1501,7 @@ i[34567]86-*-nto-qnx*)
>   ;;
>  i[34567]86-*-rtems*)
>   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
> i386/i386elf.h i386/rtemself.h rtems.h newlib-stdint.h"
> - tmake_file="${tmake_file} i386/t-rtems t-rtems"
> + tmake_file="${tmake_file} i386/t-rtems"
>   ;;
>  i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
>   tm_file="${tm_file} i386/unix.h i386/att.h ${sol2_tm_file}"
> @@ -1748,7 +1749,6 @@ lm32-*-elf*)
>  lm32-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} lm32/rtems.h rtems.h 
> newlib-stdint.h"
>   tmake_file="${tmake_file} lm32/t-lm32"
> - tmake_file="${tmake_file} t-rtems"
>   tmake_file="${tmake_file} lm32/t-rtems"
>   ;;
>  lm32-*-uclinux*)
> @@ -1763,7 +1763,7 @@ m32rle-*-elf*)
>   ;;
>  m32r-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} m32r/rtems.h rtems.h 
> newlib-stdint.h"
> - tmake_file="m32r/t-m32r t-rtems"
> + tmake_file="${tmake_file} m32r/t-m32r"
>   ;;
>  m32r-*-linux*)
>   tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} 
> m32r/linux.h"
> @@ -1854,7 +1854,7 @@ m68k-*-linux*)  # Motorola m68k's 
> running GNU/Linux
>  m68k-*-rtems*)
>   default_m68k_cpu=68020
>   default_cf_cpu=5206
> - tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems 
> m68k/t-rtems m68k/t-mlibs"
> + tmake_file="${tmake_file} m68k/t-floatlib m68k/t-m68kbare 
> m68k/t-crtstuff m68k/t-rtems m68k/t-mlibs"
>   tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h 
> m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h newlib-stdint.h"
>   tm_defines="${tm_defines} MOTOROLA=1"
>   ;;
> @@ -1904,7 +1904,7 @@ microblaze*-*-rtems*)
>   c_target_objs="${c_target_objs} microblaze-c.o"
>   cxx_target_objs="${cxx_target_objs} microblaze-c.o"
>   tmake_file="${tmake_file} microblaze/t-microblaze"
> - tmake_file="${tmake_file} t-rtems microblaze/t-rtems"
> + tmake_file="${tmake_file} microblaze/t-rtems"
>  ;;
>  microblaze*-*-elf)
>   case $target in
> @@ -2079,7 +2079,7 @@ mips64orion-*-elf* | mips64orionel-*-elf*)
>   ;;
>  mips*-*-rtems*)
>   tm_file="elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/rtems.h 
> rtems.h"
> - tmake_file="mips/t-elf t-rtems mips/t-rtems"
> + tmake_file="${tmake_file} mips/t-elf mips/t-rtems"
>   ;;
>  mips-wrs-vxworks)
>   tm_file="elfos.h ${tm_file} mips/elf.h vx-common.h vxworks.h 
> mips/vxworks.h"
> @@ -2236,7 +2236,7 @@ powerpc-*-eabi*)
>  powerpc-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
> rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/rtems.h rtems.h"
>   extra_options="${extra_options} rs6000/sysv4.opt"
> - tmake_file="rs6000/t-fprules rs6000/t-rtems t-rtems rs6000/t-ppccomm"
> + tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems 
> rs6000/t-ppccomm"
>   ;;
>  powerpc*-*-linux*)
>   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h rs6000/sysv4.h"
> @@ -2607,7 +2607,7 @@ sh-*-elf* | sh[12346l]*-*-elf* | \
>   tmake_file="$tmake_file t-sysroot-suffix"
>   ;;
>  sh-*-rtems*)
> - tmake_file="sh/t-sh t-rtems sh/t-rtems"
> + tmake_file="${tmake_file} sh/t-sh sh/t-rtems"
>   tm_file="${tm_file} dbxelf.h elfos.h sh/elf.h sh/embed-elf.h 
> sh/rtemself.h rtems.h newlib-stdint.h"
>   ;;
>  sh-wrs-vxworks)
> @@ -2630,7 +2630,7 @@ sparc-*-elf*)
>   ;;
>  sparc-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h sparc/sp-elf.h 
> sparc/rtemself.h rtems.h newlib-stdint.h"
> - tmake_file="sparc/t-sparc sparc/t-elf sparc/t-rtems t-rtems"
> + tmake_file="${tmake_file} sparc/t-sparc sparc/t-elf sparc/t-rtems"
>   ;;
>  sparc-*-linux*)
>   tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h gnu-user.h linux.h 
> glibc-stdint.h sparc/tso.h"
> @@ -2684,7 +2684,7 @@ sparc64-*-elf*)
>  sparc64-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h sparc/sysv4.h 
> sparc/sp64-elf.h sparc/rtemself.h rtems.h"
>   extra_options="${extra_options}"
> - tmake_file="${tmake_file} sparc/t-sparc sparc/t-rtems-64 t-rtems"
> + tmake_file="${tmake_file} sparc/t-sparc sparc/t-rtems-64"
>   ;;
>  sparc64-*-linux*)
>   tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h sparc/sysv4.h 
> gnu-user.h linux.h glibc-stdint.h sparc/default-64.h sparc/linux64.h 
> sparc/tso.h"
> @@ -2761,7 +2761,7 @@ v850-*-rtems*)
>   tm_file="dbxelf.h elfos.h v850/v850.h"
>   tm_file="${tm_file} rtems.h v850/rtems.h newlib-stdint.h"
>   tmake_file="${tmake_file} v850/t-v850"
> - tmake_file="${tmake_file} t-rtems v850/t-rtems"
> + tmake_file="${tmake_file} v850/t-rtems"
>   use_collect2=no
>   c_target_objs="v850-c.o"
>   cxx_target_objs="v850-c.o"
> @@ -2834,7 +2834,6 @@ am33_2.0-*-linux*)
>   ;;
>  m32c-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} m32c/rtems.h rtems.h 
> newlib-stdint.h"
> - tmake_file="${tmake_file} t-rtems"
>   c_target_objs="m32c-pragma.o"
>   cxx_target_objs="m32c-pragma.o"
>   ;;

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads

[Joel Sherrill]

On 10/31/2015 10:47 AM, Jan Sommer wrote:

Hi,

This patch changes the Ada-declaration of the pthread-related structs such as 
pthread_attr_t from a field-equivalent declaration to just reserving the right 
amount of memory.
It is only rtems related and essentially copies the way how the types are 
defined in s-osinte-linux.ads. It makes the declarations independent of a 
particular newlib-version and fixes the bug I filed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68169

CC are the rtems developers for discussion.


I am ok with this patch unless Arnaud says otherwise.

I would like to apply it to 4.9 and newer.

Comments?


Best regards,

Jan



--
-- Joel Sherrill
Ask me about RTEMS: a free RTOS
Support and Training Available

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

[Joel Sherrill]

On December 2, 2015 2:14:22 AM EST, Jeff Law  wrote:
>On 12/01/2015 12:56 PM, Jan Sommer wrote:
>> Am Monday 30 November 2015, 16:19:30 schrieb Jeff Law:
>>> On 11/30/2015 03:06 PM, Jan Sommer wrote:
 Could someone with write access please commit the patch?
 The paperwork with the FSF has gone through. If something else is
>missing, please tell me.
 I won't be available next week.
>>> I'm not sure what you built your patches again, but I can't apply
>them
>>> to the trunk.  Can you resend a patch as a diff against the trunk.
>>>
>>> Often I can fix things by hand, but this is Ada and I'd be much more
>>> likely to botch something.
>>
>> I updated the patches again. They should now fit with the heads of
>the respective branches again.
>> Maybe the Changelog will be out of synch again.
>> The patches are for the following branches:
>> ada-68169_4.9.diff   -->  gcc-4_9-branch
>> ada-68169_5.x.diff  -->   gcc-5-branch
>> ada-68169_trunk.diff --> trunk
>>
>> Let me know if they apply this time. I used svn diff to create them
>and used patch -p0 to test if they apply locally.
>THanks.  I've committed this to the trunk based on Joel's comments.
>
>The gcc-5 branch is frozen for the upcoming release and gcc-4.9 is 
>regression/doc fixes only.  It'll be up to the release managers whether
>
>or not to backport to those branches.

Thanks Jeff. 

I would consider this a regression. RTEMS changed the pthread_attr_t when we 
added thread affinity and updating Ada to match slipped through. We knew it 
needed attention for SMP but missed this critical piece to keep it working.

Jan.. Is there a gcc PR for this? To get it on a release branch, it is better 
to have one.

>Thanks.
>
>Jeff

--joel

Re: [PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

[Joel Sherrill]

On December 4, 2015 12:44:57 PM CST, Jeff Law  wrote:
>On 12/02/2015 03:23 PM, Jan Sommer wrote:
>> Am Wednesday 02 December 2015, 08:13:20 schrieb Joel Sherrill:
>>>
>>> On December 2, 2015 2:14:22 AM EST, Jeff Law 
>>> wrote:
>>>> On 12/01/2015 12:56 PM, Jan Sommer wrote:
>>>>> Am Monday 30 November 2015, 16:19:30 schrieb Jeff Law:
>>>>>> On 11/30/2015 03:06 PM, Jan Sommer wrote:
>>>>>>> Could someone with write access please commit the patch?
>>>>>>> The paperwork with the FSF has gone through. If something
>>>>>>> else is
>>>> missing, please tell me.
>>>>>>> I won't be available next week.
>>>>>> I'm not sure what you built your patches again, but I can't
>>>>>> apply
>>>> them
>>>>>> to the trunk.  Can you resend a patch as a diff against the
>>>>>> trunk.
>>>>>>
>>>>>> Often I can fix things by hand, but this is Ada and I'd be
>>>>>> much more likely to botch something.
>>>>>
>>>>> I updated the patches again. They should now fit with the heads
>>>>> of
>>>> the respective branches again.
>>>>> Maybe the Changelog will be out of synch again. The patches are
>>>>> for the following branches: ada-68169_4.9.diff   -->
>>>>> gcc-4_9-branch ada-68169_5.x.diff  -->   gcc-5-branch
>>>>> ada-68169_trunk.diff --> trunk
>>>>>
>>>>> Let me know if they apply this time. I used svn diff to create
>>>>> them
>>>> and used patch -p0 to test if they apply locally. THanks.  I've
>>>> committed this to the trunk based on Joel's comments.
>>>>
>>>> The gcc-5 branch is frozen for the upcoming release and gcc-4.9
>>>> is regression/doc fixes only.  It'll be up to the release
>>>> managers whether
>>>>
>>>> or not to backport to those branches.
>>>
>>> Thanks Jeff.
>>>
>>> I would consider this a regression. RTEMS changed the
>>> pthread_attr_t when we added thread affinity and updating Ada to
>>> match slipped through. We knew it needed attention for SMP but
>>> missed this critical piece to keep it working.
>OK.  I wasn't aware of this.  Given this note, I went ahead and 
>committed the change to the gcc-5 and gcc-4.9 branches.  However, it 
>missed the deadline for 5.3, which went out earlier this morning.

Thanks. 

Releases and freezes happen independent of bugs being discovered and fixed. We 
all just have to keep plugging on and patching.  We just like to build tools 
with released versions and as few patches as possible. That's all we can strive 
for.

>Jeff

--joel

[PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Joel Sherrill]

Change the preprocessor logic so RTEMS uses utime().
gcc/ada/
* adaint.c (__gnat_copy_attribs): RTEMS should use utime().
---
 gcc/ada/adaint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 0a90c92402c..d3b83f61076 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -3270,7 +3270,7 @@ __gnat_copy_attribs (char *from ATTRIBUTE_UNUSED, char 
*to ATTRIBUTE_UNUSED,
  return -1;
   }
 
-#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7)
+#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) || defined(__rtems__)
 
   /* VxWorks prior to 7 only has utime.  */
 
-- 
2.24.4

Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Joel Sherrill]

L

On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer 
wrote:

> On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer <
> rep.dot@gmail.com> wrote:
> >On 1 April 2021 20:32:34 CEST, Joel Sherrill  wrote:
> >>Change the preprocessor logic so RTEMS uses utime().
> >>gcc/ada/
> >>  * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
> >
> >RTEMS probably doesn't care alot about accurate time, from the looks.
> >Otherwise it would not mandate use of the obsolescent utime() (AFA SUS
> >is concerned WRT nanoseconds precision) it seems?
> >They probably know what they're doing I suppose.
> >thanks,
> >PS I shouldn't reply to none of my business, I know.
>

RTEMS is a single address space real-time operating system.  It's not that
we don't care about nanoaecond accurate time. It's just that we don't
support the utimesat() call yet. Given a choice, I'll take still compiles
and works. :)

A filesystem is not required with RTEMS and few deployed systems would have
much beyond a static root filesystem anyway.


> Meh. Okok. You got me. April 1st ;)
> grats :)
>

We'd be happy to have help implementing the missing POSIX *at() methods.
And that's not an April Fools Day joke. :)

--joel

>

[PATCH] config.gcc: Obsolete m32c-rtems target

[Joel Sherrill]

---
 gcc/config.gcc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c8824367b13..fe93a72a16c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -252,6 +252,7 @@ case ${target} in
  | cr16-*-*\
  | hppa[12]*-*-hpux10* \
  | hppa[12]*-*-hpux11* \
+ | m32c-*-rtems*   \
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
-- 
2.24.4

[GCC-WWWDocs v1] htdocs/gcc-12/changes.html: Obsolete m32c-*-rtems*

[Joel Sherrill]

---
 htdocs/gcc-12/changes.html | 4 
 1 file changed, 4 insertions(+)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index b1c88670..c69b301e 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -66,6 +66,10 @@ a work-in-progress.
 The hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*
 configurations targeting 32-bit PA-RISC with HP-UX have been obsoleted and
 will be removed in a future release.
+  
+  
+The m32c*-*-rtems* configuration has been obsoleted and will
+be removed in a future release.
   
 The support for the m32r-*-linux*, 
m32rle-*-linux*,
 m68k*-*-openbsd* and vax-*-openbsd* 
configurations
-- 
2.24.4

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

[Joel Sherrill]

On Fri, Dec 17, 2021 at 12:53 PM Eric Gallager  wrote:
>
> On Fri, Dec 17, 2021 at 11:11 AM Joel Sherrill  wrote:
> >
> > ---
> >  gcc/config.gcc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > index c8824367b13..fe93a72a16c 100644
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -252,6 +252,7 @@ case ${target} in
> >   | cr16-*-*\
> >   | hppa[12]*-*-hpux10* \
> >   | hppa[12]*-*-hpux11* \
> > + | m32c-*-rtems*   \
> >   )
> >  if test "x$enable_obsolete" != xyes; then
> >echo "*** Configuration ${target} is obsolete." >&2
> > --
> > 2.24.4
> >
>
> Hi, be sure to note this obsoletion in the Caveats section of
> gcc-12/changes.html; thanks.

Thanks for reminding me. Patch for that posted also.

--joel

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

[Joel Sherrill]

On Fri, Dec 17, 2021, 9:57 PM Jeff Law  wrote:

>
>
> On 12/17/2021 9:10 AM, Joel Sherrill wrote:
> > ---
> >   gcc/config.gcc | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > index c8824367b13..fe93a72a16c 100644
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -252,6 +252,7 @@ case ${target} in
> >| cr16-*-* \
> >| hppa[12]*-*-hpux10*  \
> >| hppa[12]*-*-hpux11*  \
> > + | m32c-*-rtems* \
> >)
> >   if test "x$enable_obsolete" != xyes; then
> > echo "*** Configuration ${target} is obsolete." >&2
> OK.  Given that last time I tried, I couldn't even get m32c to build
> newlib, I'm not terribly surprised you're deprecating it from rtems.
>

We removed it over a while back. The last release branch with it was using
gcc 7 or 8.

We had no indication there were any users and it led to removing some
alternative implementations optimised for 16 bit CPUs.


> I would support deprecation of m32c-*.
>

No complaint here.

--joel

>
> jeff
>

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

[Joel Sherrill]

On Sat, Dec 18, 2021 at 10:13 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Dec 17, 2021, 9:57 PM Jeff Law  wrote:
>>
>>
>>
>> On 12/17/2021 9:10 AM, Joel Sherrill wrote:
>> > ---
>> >   gcc/config.gcc | 1 +
>> >   1 file changed, 1 insertion(+)
>> >
>> > diff --git a/gcc/config.gcc b/gcc/config.gcc
>> > index c8824367b13..fe93a72a16c 100644
>> > --- a/gcc/config.gcc
>> > +++ b/gcc/config.gcc
>> > @@ -252,6 +252,7 @@ case ${target} in
>> >| cr16-*-* \
>> >| hppa[12]*-*-hpux10*  \
>> >| hppa[12]*-*-hpux11*  \
>> > + | m32c-*-rtems* \
>> >)
>> >   if test "x$enable_obsolete" != xyes; then
>> > echo "*** Configuration ${target} is obsolete." >&2
>> OK.  Given that last time I tried, I couldn't even get m32c to build
>> newlib, I'm not terribly surprised you're deprecating it from rtems.
>
>
> We removed it over a while back. The last release branch with it was using 
> gcc 7 or 8.
>
> We had no indication there were any users and it led to removing some 
> alternative implementations optimised for 16 bit CPUs.
>
>>
>> I would support deprecation of m32c-*.
>
>
> No complaint here.

Can I commit the gcc and wwwdocs patch for m32c-rtems and let Jeff or
someone follow up completely eliminating m32c?

Thanks.

--joel

>
> --joel
>>
>>
>> jeff

Re: [PATCH] config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file

[Joel Sherrill]

Thanks for submitting the patch. This patch is OK to merge to the
master and all open branches that have this target.

A corresponding patch for the RTEMS Source Builder is necessary
because a gcc release with this patch won't be available for a while.

I am starting a build with this now.  If Sebastian pushes it before me,
that's OK.

--joel

On Fri, Apr 6, 2018 at 3:05 PM, Amaan Cheval  wrote:

> Hi!
>
> All the gcc targets for RTEMS include gcc/config/rtems.h in tm_file to add
> specific linker options using LIB_SPEC.
>
> This patch simply intends to add the same to the x86_64 target.
>
> There are no tests in this patch because I don't see any tests for any of
> the
> other RTEMS targets - let me know if you'd be interested in a patch for
> that,
> and I can look into adding general tests for all the RTEMS targets or just
> specific ones that _must_ support these switches - Joel and Sebastian may
> be
> able to shed light on which it should be, if any.
>
> P.S. - I've also added this patch to rtems-source-builder and built gcc to
> verify that it works (in that the new switches do not throw "unrecognized
> command line option" errors anymore, at least). Let me know if you'd like a
> patch to test with rtems-source-builder, if that makes it easier for you to
> verify.
>
> Thanks!
>
> gcc/ChangeLog:
>
> 2018-04-07  Amaan Cheval  
>
> * config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file for
> custom LIB_SPEC setup.
>
> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc  (revision 259188)
> +++ gcc/config.gcc  (working copy)
> @@ -1496,7 +1496,7 @@ x86_64-*-elf*)
> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h"
> ;;
>  x86_64-*-rtems*)
> -   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h"
> +   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
> ;;
>  i[34567]86-*-rdos*)
>  tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/rdos.h"
>

[PATCH 2/3] libada/Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C.
---
 libada/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libada/Makefile.in b/libada/Makefile.in
index c307b99..93da740 100644
--- a/libada/Makefile.in
+++ b/libada/Makefile.in
@@ -60,7 +60,7 @@ CFLAGS=-g
 PICFLAG = @PICFLAG@
 GNATLIBFLAGS= -W -Wall -gnatpg -nostdinc
 GNATLIBCFLAGS= -g -O2
-GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) \
+GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \
-fexceptions -DIN_RTS @have_getipinfo@
 
 host_subdir = @host_subdir@
-- 
1.9.3

[PATCH 1/3] gcc/ada/s-osinte-rtems.adb: Correct formatting of comment

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* s-osinte-rtems.adb: Correct formatting of line in license block.
---
 gcc/ada/s-osinte-rtems.adb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/s-osinte-rtems.adb b/gcc/ada/s-osinte-rtems.adb
index de21785..9f01128 100644
--- a/gcc/ada/s-osinte-rtems.adb
+++ b/gcc/ada/s-osinte-rtems.adb
@@ -22,7 +22,7 @@
 -- You should have received a copy of the GNU General Public License and--
 -- a copy of the GCC Runtime Library Exception along with this program; --
 -- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
--- <http://www.gnu.org/licenses/>. 
+-- <http://www.gnu.org/licenses/>.  --
 --  --
 -- GNARL was developed by the GNARL team at Florida State University. It is --
 -- now maintained by Ada Core Technologies Inc. in cooperation with Florida --
-- 
1.9.3

[PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* socket.c: Add conditionals for RTEMS. Add include of 
and so correct prototype of gethostbyname_r() is used.
---
 gcc/ada/socket.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/socket.c b/gcc/ada/socket.c
index 4a9e6ad..631bfdc 100644
--- a/gcc/ada/socket.c
+++ b/gcc/ada/socket.c
@@ -60,6 +60,11 @@ typedef int IOCTL_Req_T;
 #include 
 /* Required for memcpy() */
 
+#if defined(__rtems__)
+#include 
+/* Required, for read(), write(), and close() */
+#endif
+
 extern void __gnat_disable_sigpipe (int fd);
 extern void __gnat_disable_all_sigpipes (void);
 extern int  __gnat_create_signalling_fds (int *fds);
@@ -184,7 +189,7 @@ __gnat_gethostbyname (const char *name,
   struct hostent *rh;
   int ri;
 
-#if defined(__linux__) || defined(__GLIBC__)
+#if defined(__linux__) || defined(__GLIBC__) || defined(__rtems__)
   (void) gethostbyname_r (name, ret, buf, buflen, &rh, h_errnop);
 #else
   rh = gethostbyname_r (name, ret, buf, buflen, h_errnop);
-- 
1.9.3

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

On 8/11/2014 1:15 PM, Mike Stump wrote:
> On Aug 11, 2014, at 8:08 AM, Joel Sherrill  wrote:
>> +#if defined(__rtems__)
>> +#include 
>> +/* Required, for read(), write(), and close() */
>> +#endif
> Strikes me as exceptionally odd.  Should be done unconditionally, and any 
> system that doesn’t like that should be the odd ball.

I assume on other targets, these get prototyped by some implicit include.
I found it odd that this wasn't included already also.

Any Ada maintainers want to comment?

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

On 8/11/2014 3:09 PM, Arnaud Charlet wrote:
>>> This patch is needed to make Ada compile for *-*-rtems*
>>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
>> OK.
> Actually, these includes should go in gsocket.h, as done on other targets,
> which also answers your previous question.
Where do you want the include of unistd.h? It doesn't appear to be
included in
gsocket.h and none of the other areas specific to RTEMS make sense to
add it.

I think the best place is below this:

#if defined (__vxworks) && ! defined (__RTP__)
#include 
#else
#include 
#endif

And just move the conditional from socket.c with comment.
> Can you please repost an updated patch for review?
No problem.
> Arno

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH 1/3] gcc/ada/s-osinte-rtems.adb: Correct formatting of comment

[Joel Sherrill]

Thanks. This is committed.

I leaned toward obvious as well but figured I already had two
patches that needed a review, so why not. :)

On 8/11/2014 3:05 PM, Arnaud Charlet wrote:
>> This patch is needed to make Ada compile for *-*-rtems*
>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
> Yes. This one even falls under the obvious category IMO.
>
>> 2014-08-11  Joel Sherrill 
>>
>>  * s-osinte-rtems.adb: Correct formatting of line in license block.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

[PATCH 1/2] libada/Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C

[Joel Sherrill]

This didn't get any comments earlier. Is it OK to comment?

Somewhere along the way, the Ada run-time Makefile's quit
honoring CFLAGS_FOR_TARGET. This just adds it back.

2014-08-12  Joel Sherrill 

* Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C.
---
 libada/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libada/Makefile.in b/libada/Makefile.in
index c307b99..93da740 100644
--- a/libada/Makefile.in
+++ b/libada/Makefile.in
@@ -60,7 +60,7 @@ CFLAGS=-g
 PICFLAG = @PICFLAG@
 GNATLIBFLAGS= -W -Wall -gnatpg -nostdinc
 GNATLIBCFLAGS= -g -O2
-GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) \
+GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \
-fexceptions -DIN_RTS @have_getipinfo@
 
 host_subdir = @host_subdir@
-- 
1.9.3

[PATCH 2/2] gcc/ada/socket.c, gsocket.h: Add conditionals for RTEMS

[Joel Sherrill]

Hopefully this addresses the comments.

OK to comment?

2014-08-12  Joel Sherrill 

* socket.c: For RTEMS, use correct prototype of gethostbyname_r().
* gsocket.h Add include of  on RTEMS.
---
 gcc/ada/gsocket.h | 5 +
 gcc/ada/socket.c  | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/gsocket.h b/gcc/ada/gsocket.h
index f139d72..2034137 100644
--- a/gcc/ada/gsocket.h
+++ b/gcc/ada/gsocket.h
@@ -184,6 +184,11 @@
 #include 
 #endif
 
+#if defined(__rtems__)
+#include 
+/* Required, for read(), write(), and close() */
+#endif
+
 /*
  * RTEMS has these .h files but not until you have built and installed RTEMS.
  * When building a C/C++ toolset, you also build the newlib C library, so the
diff --git a/gcc/ada/socket.c b/gcc/ada/socket.c
index 4a9e6ad..ad88268 100644
--- a/gcc/ada/socket.c
+++ b/gcc/ada/socket.c
@@ -184,7 +184,7 @@ __gnat_gethostbyname (const char *name,
   struct hostent *rh;
   int ri;
 
-#if defined(__linux__) || defined(__GLIBC__)
+#if defined(__linux__) || defined(__GLIBC__) || defined(__rtems__)
   (void) gethostbyname_r (name, ret, buf, buflen, &rh, h_errnop);
 #else
   rh = gethostbyname_r (name, ret, buf, buflen, h_errnop);
-- 
1.9.3

Re: [PATCH 1/2] libada/Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C

[Joel Sherrill]

On 8/12/2014 12:33 PM, Arnaud Charlet wrote:
>> This didn't get any comments earlier. Is it OK to comment?
> This one is a bit tricky so requires more thoughts. On which targets did
> you test it?
native CentOS and sparc-rtems4.11.  I don't have access to much else
except *-rtems* which is basically the same thing with different backend
gcc issues.

The build needs a way to see the RTEMS network .h files since they are
not installed with the libc files. libc/gcc .h files are part of the
normal GNU toolset. The others are part of the BSP install.
>> Somewhere along the way, the Ada run-time Makefile's quit
>> honoring CFLAGS_FOR_TARGET. This just adds it back.
>>
>> 2014-08-12  Joel Sherrill 
>>
>>  * Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C.
> I guess this is OK on principle, but if someone reports an issue with this
> patch, we might need to revert it.
It was in the rts Makefile back when it was under gcc. I suspect it
disappeared when this
all moved to libada. Could check the history if we need to.
> Arno

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH 1/2] libada/Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C

[Joel Sherrill]

On 8/12/2014 2:22 PM, Arnaud Charlet wrote:
>> It was in the rts Makefile back when it was under gcc. I suspect it
>> disappeared when this
>> all moved to libada. Could check the history if we need to.
> Well, libada has been introduced many many years ago. Are you saying you
> haven't built Ada since then, or were using local patches?
I don't know when I last built it but it has been broken for a while and
I didn't get
a chance to track it down and submit patches.

I have had local patches but didn't like them.  Ada is just a volunteer
activity at this
point for me. If AdaCore would like to include one RTEMS target in your
automated
testing, that would help.

> Arno

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Doc Bug: cxa-atexit not use-cxa-atexit

[Joel Sherrill]

Hi

I think this is a minor documentation bug which is in the head but also
seems to be in the gcc 4.4.7 docs shipped with CentOS 6.x.

OK to commit?

2014-08-18  Joel Sherrill 

* doc/invoke.texi: -fno-cxa-atexit should be -fno-use-cxa-atexit.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6374261..80b0d96 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13778,7 +13778,7 @@ are compatible with as many systems and code
bases as po
 @item -mkernel
 @opindex mkernel
 Enable kernel development mode.  The @option{-mkernel} option sets
-@option{-static}, @option{-fno-common}, @option{-fno-cxa-atexit},
+@option{-static}, @option{-fno-common}, @option{-fno-use-cxa-atexit},
 @option{-fno-exceptions}, @option{-fno-non-call-exceptions},
 @option{-fapple-kext}, @option{-fno-weak} and @option{-fno-rtti} where
 applicable.  This mode also sets @option{-mno-altivec},

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

spar-rtems add leon3 multlib to 4.9

[Joel Sherrill]

I would like to add this patch to the 4.9 branch. It is RTEMS
specific and takes advantage of the leon3 multilib support from
Eric Botcazou. 

OK to commit?

--joel

gcc/ChangeLog
2013-08-29  Sebastian Huber

* config/sparc/t-rtems: Add leon3 multilibs.
---
  gcc/config/sparc/t-rtems |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
index 63d0217..f1a3d84 100644
--- a/gcc/config/sparc/t-rtems
+++ b/gcc/config/sparc/t-rtems
@@ -17,6 +17,6 @@
  #<http://www.gnu.org/licenses/>.
  #

-MULTILIB_OPTIONS = msoft-float mcpu=v8
-MULTILIB_DIRNAMES = soft v8
+MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3
+MULTILIB_DIRNAMES = soft v8 leon3
  MULTILIB_MATCHES = msoft-float=mno-fpu

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] SPARC: add mcpu=leon3v7 target

[Joel Sherrill]

T_SPEC AS_LEON_FLAG
> +#endif
> +
>  #endif
>  
>  #if !defined(CPP_CPU32_DEFAULT_SPEC) || !defined(CPP_CPU64_DEFAULT_SPEC)
> @@ -285,6 +291,7 @@ extern enum cmodel sparc_cmodel;
>  %{mcpu=hypersparc:-D__hypersparc__ -D__sparc_v8__} \
>  %{mcpu=leon:-D__leon__ -D__sparc_v8__} \
>  %{mcpu=leon3:-D__leon__ -D__sparc_v8__} \
> +%{mcpu=leon3v7:-D__leon__} \
>  %{mcpu=v9:-D__sparc_v9__} \
>  %{mcpu=ultrasparc:-D__sparc_v9__} \
>  %{mcpu=ultrasparc3:-D__sparc_v9__} \
> @@ -334,6 +341,7 @@ extern enum cmodel sparc_cmodel;
>  %{mcpu=hypersparc:-Av8} \
>  %{mcpu=leon:" AS_LEON_FLAG "} \
>  %{mcpu=leon3:" AS_LEON_FLAG "} \
> +%{mcpu=leon3v7:" AS_LEON_FLAG "} \
>  %{mv8plus:-Av8plus} \
>  %{mcpu=v9:-Av9} \
>  %{mcpu=ultrasparc:%{!mv8plus:-Av9a}} \
> diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
> index 174a6b1..b074367 100644
> --- a/gcc/config/sparc/sparc.md
> +++ b/gcc/config/sparc/sparc.md
> @@ -215,6 +215,7 @@
> hypersparc,
> leon,
> leon3,
> +   leon3v7,
> sparclite,
> f930,
> f934,
> diff --git a/gcc/config/sparc/sparc.opt b/gcc/config/sparc/sparc.opt
> index 3ccd54f..ac9e6b1 100644
> --- a/gcc/config/sparc/sparc.opt
> +++ b/gcc/config/sparc/sparc.opt
> @@ -149,6 +149,9 @@ EnumValue
>  Enum(sparc_processor_type) String(leon3) Value(PROCESSOR_LEON3)
>  
>  EnumValue
> +Enum(sparc_processor_type) String(leon3v7) Value(PROCESSOR_LEON3V7)
> +
> +EnumValue
>  Enum(sparc_processor_type) String(sparclite) Value(PROCESSOR_SPARCLITE)
>  
>  EnumValue
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 508bbb4..21b122a 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -19606,8 +19606,8 @@ the rules of the ABI@.
>  Set the instruction set, register set, and instruction scheduling parameters
>  for machine type @var{cpu_type}.  Supported values for @var{cpu_type} are
>  @samp{v7}, @samp{cypress}, @samp{v8}, @samp{supersparc}, @samp{hypersparc},
> -@samp{leon}, @samp{leon3}, @samp{sparclite}, @samp{f930}, @samp{f934},
> -@samp{sparclite86x}, @samp{sparclet}, @samp{tsc701}, @samp{v9},
> +@samp{leon}, @samp{leon3}, @samp{leon3v7}, @samp{sparclite}, @samp{f930},
> +@samp{f934}, @samp{sparclite86x}, @samp{sparclet}, @samp{tsc701}, @samp{v9},
>  @samp{ultrasparc}, @samp{ultrasparc3}, @samp{niagara}, @samp{niagara2},
>  @samp{niagara3} and @samp{niagara4}.
>  
> @@ -19625,7 +19625,7 @@ implementations.
>  
>  @table @asis
>  @item v7
> -cypress
> +cypress, leon3v7
>  
>  @item v8
>  supersparc, hypersparc, leon, leon3
> @@ -19690,11 +19690,11 @@ option @option{-mcpu=@var{cpu_type}} does.
>  The same values for @option{-mcpu=@var{cpu_type}} can be used for
>  @option{-mtune=@var{cpu_type}}, but the only useful values are those
>  that select a particular CPU implementation.  Those are @samp{cypress},
> -@samp{supersparc}, @samp{hypersparc}, @samp{leon}, @samp{leon3}, @samp{f930},
> -@samp{f934}, @samp{sparclite86x}, @samp{tsc701}, @samp{ultrasparc},
> -@samp{ultrasparc3}, @samp{niagara}, @samp{niagara2}, @samp{niagara3} and
> -@samp{niagara4}.  With native Solaris and GNU/Linux toolchains, @samp{native}
> -can also be used.
> +@samp{supersparc}, @samp{hypersparc}, @samp{leon}, @samp{leon3},
> +@samp{leon3v7}, @samp{f930}, @samp{f934}, @samp{sparclite86x}, @samp{tsc701},
> +@samp{ultrasparc}, @samp{ultrasparc3}, @samp{niagara}, @samp{niagara2},
> +@samp{niagara3} and @samp{niagara4}.  With native Solaris and GNU/Linux
> +toolchains, @samp{native} can also be used.
>  
>  @item -mv8plus
>  @itemx -mno-v8plus

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: Doc Bug: cxa-atexit not use-cxa-atexit

[Joel Sherrill]

On 8/23/2014 11:19 AM, Gerald Pfeifer wrote:
> On Mon, 18 Aug 2014, Joel Sherrill wrote:
>> I think this is a minor documentation bug which is in the head but also
>> seems to be in the gcc 4.4.7 docs shipped with CentOS 6.x.
>>
>> OK to commit?
>>
>> 2014-08-18  Joel Sherrill 
>>
>> * doc/invoke.texi: -fno-cxa-atexit should be -fno-use-cxa-atexit.
> Sure thing.  Okay for all open branches.
I think it is safely committed to 4.8 and newer.
> Gerald

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH, i386]: Enable soft-float multilibs for x86-32 RTEMS

[Joel Sherrill]

On 11/5/2013 10:26 AM, Uros Bizjak wrote:
> On Tue, Nov 5, 2013 at 5:23 PM, Uros Bizjak  wrote:
> 
>> Attached patch enables soft-float multilibs for x86-32 RTEMS. The
>> patch activates SFmode and DFmode soft-float support routines. The
>> XFmode is mapped to DFmode due to lack of XFmode support in
>> soft-float. We already disable FPU return registers for -mno-80387, so
>> ABI is already changed for soft-float. The XFmode->DFmode mapping just
>> rides on this change.
> 
> Please note that the change to gcc/config/i386/t-rtems, as included in
> the patch, was only for reference and was not committed to SVN.

Unless someone objects, Ralf tested them. Feel free to commit
them.

Thanks for fixing this. I assumed x86-32 soft-float was
dead and buried.

FWIW this configuration is easily testable on RTEMS or bare
metal configurations using qemu.


> Uros.
> 



-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

[Joel Sherrill]

Attached is an updated version of the patch which includes
some commentary above the include of stdint.h.

Is this OK to apply?

--joel

On 11/10/2014 1:03 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
>> On 10/11/14 12:01 -0600, Joel Sherrill wrote:
>>> cc'ing since both lists should be included.
>>>
>>> The m32c has 24-bit pointers and 16-bit size_t. This changes
>>> pushing a pointer through a size_t to pushing it through a
>>> uintptr_t.
>> I'm OK with this change if Paolo is.
> No problem with the experiment (frankly, I'm not at all sure that the 
> targets not providing  are *that* much uncommon than the 
> target which we are fixing with the patch), but please add a comment 
> about  in the code, then if bootstrap actually breaks the 
> issue is clear...
>
> Paolo.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available    (256) 722-9985

From d1468be689dc23e39209b5cc981d00e89a465673 Mon Sep 17 00:00:00 2001
From: Joel Sherrill 
Date: Mon, 10 Nov 2014 09:34:15 -0600
Subject: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) ==
 sizeof(size_t)

2014-11-14  Joel Sherrill 

	* src/c++98/mt_allocator.cc: Fix assumption that sizeof(void *) is
	equal to sizeof(size_t). The m32c breaks this assumption.
---
 libstdc++-v3/src/c++98/mt_allocator.cc | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc b/libstdc++-v3/src/c++98/mt_allocator.cc
index 38e17df..51b2605 100644
--- a/libstdc++-v3/src/c++98/mt_allocator.cc
+++ b/libstdc++-v3/src/c++98/mt_allocator.cc
@@ -31,6 +31,11 @@
 #include 
 #include 
 
+// The include file is needed for uintptr_t. If this file does not compile,
+// check to make sure the target has  and that it provides
+// uintptr_t.
+#include 
+
 namespace
 {
 #ifdef __GTHREADS
@@ -74,7 +79,7 @@ namespace
 __freelist& freelist = get_freelist();
 {
   __gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
-  size_t _M_id = reinterpret_cast(__id);
+  uintptr_t _M_id = reinterpret_cast(__id);
   
   typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
   _Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
@@ -627,7 +632,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 	__freelist& freelist = get_freelist();
 	void* v = __gthread_getspecific(freelist._M_key);
-	size_t _M_id = (size_t)v;
+	uintptr_t _M_id = (uintptr_t)v;
 	if (_M_id == 0)
 	  {
 	{
-- 
1.9.3

Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

[Joel Sherrill]

On 11/14/2014 10:37 AM, Jonathan Wakely wrote:
> On 14/11/14 10:10 -0600, Joel Sherrill wrote:
>> Attached is an updated version of the patch which includes
>> some commentary above the include of stdint.h.
>>
>> Is this OK to apply?
> OK, thanks.
Committed. Thanks for all the feedback.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Fix spelling error in top level configure.ac

[Joel Sherrill]

Hi

Not a huge patch. Just changes "developement" to "development" in a
comment and error message. The larger issue is that it is in the top level
configure.ac. :)

OK to comment and where?

2015-01-14  Joel Sherrill 

* configure.ac: Fix spelling error.
* configure: Regenerate.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

>From 2245d177fb2d5b396168c56d5dfdacc48a1bf94e Mon Sep 17 00:00:00 2001
From: Joel Sherrill 
Date: Wed, 14 Jan 2015 16:59:07 -0600
Subject: [PATCH] configure.ac: Fix spelling error

2015-01-14  Joel Sherrill 

	* configure.ac: Fix spelling error.
	* configure: Regenerate.
---
 configure| 4 ++--
 configure.ac | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 64d287d..1536c11 100755
--- a/configure
+++ b/configure
@@ -7553,7 +7553,7 @@ fi
 # multilib is not explicitly enabled.
 case "$target:$have_compiler:$host:$target:$enable_multilib" in
   x86_64-*linux*:yes:$build:$build:)
-# Make sure we have a developement environment that handles 32-bit
+# Make sure we have a development environment that handles 32-bit
 dev64=no
 echo "int main () { return 0; }" > conftest.c
 ${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
@@ -7564,7 +7564,7 @@ case "$target:$have_compiler:$host:$target:$enable_multilib" in
 fi
 rm -f conftest*
 if test x${dev64} != xyes ; then
-  as_fn_error "I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib." "$LINENO" 5
+  as_fn_error "I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib." "$LINENO" 5
 fi
 ;;
 esac
diff --git a/configure.ac b/configure.ac
index 5badc7f..7c7ee18 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2921,7 +2921,7 @@ fi
 # multilib is not explicitly enabled.
 case "$target:$have_compiler:$host:$target:$enable_multilib" in
   x86_64-*linux*:yes:$build:$build:)
-# Make sure we have a developement environment that handles 32-bit
+# Make sure we have a development environment that handles 32-bit
 dev64=no
 echo "int main () { return 0; }" > conftest.c
 ${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
@@ -2932,7 +2932,7 @@ case "$target:$have_compiler:$host:$target:$enable_multilib" in
 fi 
 rm -f conftest*
 if test x${dev64} != xyes ; then
-  AC_MSG_ERROR([I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
+  AC_MSG_ERROR([I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
 fi
 ;;
 esac
-- 
1.9.3

Add CFLAGS_FOR_TARGET to Ada OS Constant Extraction Process

[Joel Sherrill]

Hi

When building Ada for RTEMS, you need to pass in the CFLAGS_FOR_TARGET
to see OS specific .h files. This was already done for the RTS but needed to
be added to the process which extracts value settings from the .h files.

This patch is against 4.9.  OK to apply to 4.8, 4.9, and head assuming it
applies cleanly?

2015-02-10  Joel Sherrill 

* gcc-interface/Makefile.in: Add CFLAGS_TO_TARGET to OSCONS_CPP
and OSCONS_EXTRACT.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

2015-02-10  Joel Sherrill 

* gcc-interface/Makefile.in: Add CFLAGS_TO_TARGET to OSCONS_CPP
and OSCONS_EXTRACT.

Index: gcc/ada/gcc-interface/Makefile.in
===
--- gcc/ada/gcc-interface/Makefile.in   (revision 220002)
+++ gcc/ada/gcc-interface/Makefile.in   (working copy)
@@ -115,7 +115,7 @@
 # Pretend that _Unwind_GetIPInfo is available for the target by default.  This
 # should be autodetected during the configuration of libada and passed down to
 # here, but we need something for --disable-libada and hope for the best.
-GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) \
+GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \
-fexceptions -DIN_RTS -DHAVE_GETIPINFO
 ALL_ADAFLAGS = $(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS)
 THREAD_KIND = native
@@ -2748,9 +2748,9 @@
 # for running it from $(RTSDIR)
 OSCONS_CC=`echo "$(GCC_FOR_TARGET)" \
   | sed -e 's^\./xgcc^../../xgcc^' -e 's^-B./^-B../../^'`
-OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS) -E -C \
+OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) -E -C \
   -DTARGET=\"$(target)\" $(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i
-OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS) -S s-oscons-tmplt.i
+OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) -S 
s-oscons-tmplt.i
 endif
 
 ./bldtools/oscons/xoscons: xoscons.adb xutil.ads xutil.adb

Re: Add CFLAGS_FOR_TARGET to Ada OS Constant Extraction Process

[Joel Sherrill]

On 2/11/2015 1:22 AM, Arnaud Charlet wrote:
>> When building Ada for RTEMS, you need to pass in the CFLAGS_FOR_TARGET
>> to see OS specific .h files. This was already done for the RTS but needed to
>> be added to the process which extracts value settings from the .h files.
>>
>> This patch is against 4.9.  OK to apply to 4.8, 4.9, and head assuming it
>> applies cleanly?
> This patch won't apply cleanly for head I think, where I suspect at least
> part of your patch is OBE.
OK. Rebuilding on the head.
> It would be better to first have a patch for trunk (if still relevant)
> and then backport it to the other branches, since changes on trunk have
> already been done in a different way to address at least partly this issue
> (e.g. use of GNATLIBCFLAGS_FOR_C in OSCONS_CPP, different computation of
> OSCONS_CC).
I am happy to do and from your description it sounds like the it would
have built
if the code had my previous patch to add CFLAGS_FOR_TARGET to the
GNATLIBCFLAGS.

GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \
-fexceptions -DIN_RTS -DHAVE_GETIPINFO

But the build didn't get far enough to know. It fails before that with:

gcc -c -g -O2  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated
-Iada -I/users/joel/test-gcc/gcc/gcc/ada
-I/users/joel/test-gcc/gcc/gcc/ada/gcc-interface
/users/joel/test-gcc/gcc/gcc/ada/a-ioexce.ads -o ada/a-ioexce.o
a-ioexce.ads:21:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:22:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:23:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:24:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:25:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:26:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:27:19: violation of restriction "No_Elaboration_Code" at
system.ads:53
a-ioexce.ads:28:19: violation of restriction "No_Elaboration_Code" at
system.ads:53

Any ideas?

My native compiler is from the head back in August. I will rebuild it
overnight
and try again in the morning in case that's a factor.

> Arno

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Joel Sherrill]

On 2/18/2015 10:54 AM, Mike Frysinger wrote:
> On 18 Feb 2015 04:56, H.J. Lu wrote:
>> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker  
>> wrote:
>>> On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote:
>>>> This patch enhances config/zlib.m4 to introduce an extra option
>>>> --with-libz-prefix which allows us to provide the location of
>>>> the zlib library we want to use during the build.
>>>>
>>>> config/ChangeLog:
>>>>
>>>> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support.
>>>>
>>>> I didn't see any file in the GCC project that uses this macro,
>>>> so for the GCC repository, the change to zlib.m4 is it. But
>>>> I am also attaching to this email a copy of the patch that
>>>> will be applied to the binutils-gdb.git repository, with all
>>>> configury using this macro being re-generated - mostly for info,
>>>> also as a heads-up to both binutils and GDB.
>>>>
>>>> This was tested by regenerating all autoconf/automake files in
>>>> the binutils-gdb project, and rebuilding GDB, using the following
>>>> combinations:
>>>>
>>>>   --with-zlib (system zlib used)
>>>>   --with-libz-prefix=/zlib/prefix (specific zlib linked in)
>>>>   --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in)
>>>>
>>>>   --without-zlib (zlib support turned off)
>>>>   --without-zlib --with-zlib-prefix (zlib support turned off)
>>>>
>>>>   --with-zlib (no system zlib available, configure fails with expected 
>>>> error)
>>>>   --with-zlib --with-libz-prefix=/invalid/zlib/prefix
>>>>   (no system zlib, configure fails with same error)
>>>>
>>>> OK to commit?
>> Why do you want to turn off zlib? On Linux/x86,  zlib is required
>> for assembler.  At least, you should issue an error when --without-libz
>> is used in binutils for Linux/x86 target.
> err, when did that happen ?  why would zlib be possibly required for an 
> assembler ?

Is there going to be a configure error when the system does not have zlib
and no argument is specified?

This is a common issue for people building tools for RTEMS for the first
time.
> -mike

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: select SPARC multilibs

[Joel Sherrill]

On November 7, 2014 2:40:43 AM CST, Eric Botcazou  wrote:
>> I think this would be good for 4.8, 4.9 and trunk.
>> 
>> 2014-11-06  Daniel Hellstrom  
>> 
>>  * config.gcc (sparc-*-rtems*): Clean away unused t-elf
>>  * config/sparc/t-rtems: Add leon3v7 and muser-mode multilibs
>
>OK everywhere as far as I'm concerned but the RTEMS folks have the
>final say.

Fine with me.

Does spatc-elf need a refresh on its multilibs?

--joel

[PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

[Joel Sherrill]

2014-11-10  Joel Sherrill 

* src/c++98/mt_allocator.cc: Fix assumption that sizeof(void *) is
equal to sizeof(size_t). The m32c breaks this assumption.
---
 libstdc++-v3/src/c++98/mt_allocator.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc 
b/libstdc++-v3/src/c++98/mt_allocator.cc
index 38e17df..04dd8ad 100644
--- a/libstdc++-v3/src/c++98/mt_allocator.cc
+++ b/libstdc++-v3/src/c++98/mt_allocator.cc
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 namespace
 {
@@ -74,7 +75,7 @@ namespace
 __freelist& freelist = get_freelist();
 {
   __gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
-  size_t _M_id = reinterpret_cast(__id);
+  uintptr_t _M_id = reinterpret_cast(__id);
   
   typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
   _Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
@@ -627,7 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__freelist& freelist = get_freelist();
void* v = __gthread_getspecific(freelist._M_key);
-   size_t _M_id = (size_t)v;
+   uintptr_t _M_id = (uintptr_t)v;
if (_M_id == 0)
  {
{
-- 
1.9.3

Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

[Joel Sherrill]

cc'ing since both lists should be included.

The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.

--joel
On 11/10/2014 9:36 AM, Joel Sherrill wrote:
> 2014-11-10  Joel Sherrill 
>
>   * src/c++98/mt_allocator.cc: Fix assumption that sizeof(void *) is
>   equal to sizeof(size_t). The m32c breaks this assumption.
> ---
>  libstdc++-v3/src/c++98/mt_allocator.cc | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc 
> b/libstdc++-v3/src/c++98/mt_allocator.cc
> index 38e17df..04dd8ad 100644
> --- a/libstdc++-v3/src/c++98/mt_allocator.cc
> +++ b/libstdc++-v3/src/c++98/mt_allocator.cc
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  namespace
>  {
> @@ -74,7 +75,7 @@ namespace
>  __freelist& freelist = get_freelist();
>  {
>__gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
> -  size_t _M_id = reinterpret_cast(__id);
> +  uintptr_t _M_id = reinterpret_cast(__id);
>
>typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
>_Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
> @@ -627,7 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>{
>   __freelist& freelist = get_freelist();
>   void* v = __gthread_getspecific(freelist._M_key);
> - size_t _M_id = (size_t)v;
> + uintptr_t _M_id = (uintptr_t)v;
>   if (_M_id == 0)
> {
>   {

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

[Joel Sherrill]

On 11/10/2014 1:03 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
>> On 10/11/14 12:01 -0600, Joel Sherrill wrote:
>>> cc'ing since both lists should be included.
>>>
>>> The m32c has 24-bit pointers and 16-bit size_t. This changes
>>> pushing a pointer through a size_t to pushing it through a
>>> uintptr_t.
>> I'm OK with this change if Paolo is.
> No problem with the experiment (frankly, I'm not at all sure that the 
> targets not providing  are *that* much uncommon than the 
> target which we are fixing with the patch), but please add a comment 
> about  in the code, then if bootstrap actually breaks the 
> issue is clear...
Just to be clear add a comment above the include of stdint.h that it is
assumed
that a target provides this header file and defines uintptr_t.
> Paolo.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] newlib-stdint.h: Remove 32 bit longs

[Joel Sherrill]

RTEMS uses the PRI constants and we don't see warnings. Is there a specific 
test case which would demonstrate this is actually broken. The file 
newlib-stdint.h will impact more targets than Zephyr and I think they owe a 
demo case.

On August 19, 2016 7:37:22 PM EDT, Andrew Pinski  wrote:
>On Fri, Aug 19, 2016 at 12:16 PM, Andy Ross 
>wrote:
>> We ran into this issue in the Zephyr project with our toolchain (gcc
>> built with --enable-newlib).  Basically GCC appears to be honoring a
>> legacy requirement to give newlib a "long" instead of "int" for
>> __INT32_TYPE__, which then leaks out through the current newlib
>> headers as a long-valued int32_t, which produces gcc warnings when a
>> uint32_t is passed to an unqualified printf format specifier like
>> "%d".
>>
>> But the newlib headers, if __INT32_TYPE__ is *not* defined by the
>> compiler, have code to chose a "int" over "long" immediately
>> thereafter.  It seems whatever requirement this was honoring isn't
>> valid anymore.
>
>Couple of things missing here.  A changelog is the first thing.
>The second thing is it seems like Zephyr project should be using the
>PRIdx, etc. instead of just %d for int32_t to be portable.
>
>Thanks,
>Andrew
>
>
>>
>> From 784fb1760a930d0309f878bbae7bfd38137f5689 Mon Sep 17 00:00:00
>2001
>> From: Andy Ross 
>> Date: Fri, 19 Aug 2016 09:40:42 -0700
>> Subject: [PATCH] newlib-stdint.h: Remove 32 bit longs
>>
>> This would make __INT32_TYPE__ a "long" instead of an "int", which
>> would then percolate down in newlib's own headers into a typedef for
>> int32_t.  Which is wrong.  Newlib's headers, if __INT32_TYPE__ were
>> not defined, actually would chose an int for this type.  The comment
>> that newlib uses a 32 bit long appears to be a lie, perhaps
>> historical.
>>
>> Signed-off-by: Andy Ross 
>> ---
>>  gcc/config/newlib-stdint.h | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/config/newlib-stdint.h b/gcc/config/newlib-stdint.h
>> index eb99556..0275948 100644
>> --- a/gcc/config/newlib-stdint.h
>> +++ b/gcc/config/newlib-stdint.h
>> @@ -22,10 +22,9 @@ a copy of the GCC Runtime Library Exception along
>with this program;
>>  see the files COPYING3 and COPYING.RUNTIME respectively.  If not,
>see
>>  .  */
>>
>> -/* newlib uses 32-bit long in certain cases for all non-SPU
>> -   targets.  */
>> +/* newlib used to use a 32-bit long, no longer */
>>  #ifndef STDINT_LONG32
>> -#define STDINT_LONG32 (LONG_TYPE_SIZE == 32)
>> +#define STDINT_LONG32 0
>>  #endif
>>
>>  #define SIG_ATOMIC_TYPE "int"
>> --
>> 2.7.4
>>

--joel

moxie-rtems patch for libgcc/config.host

[Joel Sherrill]

Hi

For some unknown reason, moxie-rtems has its own stanza
in libgcc/config.host which does not include extra_parts.
This results in C++ RTEMS applications not linking.

Also the tmake_file variable is overridden by the
shared moxie stanza rather than being added to.

This patch addresses both issues. This patch (or some
minor variant) needs to be applied to every branch from
4.9 to master.

Comments?


2015-04-18  Joel Sherrill 

* config.host (moxie-*-rtems*): Merge this stanza with
other moxie targets so the same extra_parts are built.
Also have tmake_file add on to its value rather than override.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available(256) 722-9985
>From fbeb49b7d12cb7a6c9ef15a9f3b000c9fc7b641e Mon Sep 17 00:00:00 2001
From: Joel Sherrill 
Date: Mon, 18 Apr 2016 16:31:06 -0500
Subject: [PATCH] config.host: Merge moxie-rtems stanza with other moxie
 targets

	2015-04-18  Joel Sherrill 

	* config.host (moxie-*-rtems*): Merge this stanza with
	other moxie targets so the same extra_parts are built.
	Also have tmake_file add on to its value rather than override.
---
 libgcc/config.host | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libgcc/config.host b/libgcc/config.host
index b61a579..16a45c8 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -931,14 +931,9 @@ mmix-knuth-mmixware)
 mn10300-*-*)
 	tmake_file=t-fdpbit
 	;;
-moxie-*-elf | moxie-*-moxiebox* | moxie-*-uclinux*)
-	tmake_file="moxie/t-moxie t-softfp-sfdf t-softfp-excl t-softfp"
-	extra_parts="$extra_parts crti.o crtn.o crtbegin.o crtend.o"
-	;;
-moxie-*-rtems*)
+moxie-*-elf | moxie-*-moxiebox* | moxie-*-uclinux* | moxie-*-rtems*)
 	tmake_file="$tmake_file moxie/t-moxie t-softfp-sfdf t-softfp-excl t-softfp"
-	# Don't use default.
-	extra_parts=
+	extra_parts="$extra_parts crti.o crtn.o crtbegin.o crtend.o"
 	;;
 msp430*-*-elf)
 	tmake_file="$tm_file t-crtstuff t-fdpbit msp430/t-msp430"
-- 
1.8.3.1

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joel Sherrill]

On August 20, 2015 5:22:47 PM EDT, Joseph Myers  wrote:
>On Thu, 20 Aug 2015, FX wrote:
>
>> > Well, they aren't *targets*, but *host* and *build* systems.
>> 
>> Yes, but do we maintain a list of support host or build systems, that
>
>> would be different from our list of supported targets?
>
>I don't think there's such a list.  For any such system that's not a 
>supported target to work in practice, it would need a reasonably modern
>
>C++ compiler, which probably rules out a lot of systems that have been 
>obsoleted as targets.

Wouldn't a list be able to be compiled from major branch release announcements? 
There should be a deprecated and removed note in two release branch 
descriptions. Even if we screwed up and forgot to list it on both, if it likely 
to be in one of them.

--joel

Re: [PATCH] Multilib changes ARM RTEMS

[Joel Sherrill]

I would like to hear from an ARM maintainer before I commit this.

--joel

On 5/8/2013 5:06 AM, Sebastian Huber wrote:

This patch should be applied to all open GCC branches.

This patch removes the mthumb/march=armv7 since it is virtually equal to
the mthumb/march=armv7-m multilib.  Add variants for ARMv7-A and
ARMv7-R.

I tried to use the MULTILIB_REQUIRED option, but this didn't work for
patterns with more than two options.

gcc/ChangeLog
2013-05-08  Sebastian Huber 

* config/arm/t-rtems-eabi: Remove mthumb/march=armv7 multilib.
Add mthumb/march=armv7-a multilib.
Add mthumb/march=armv7-r multilib.
Add mthumb/march=armv7-a/mfpu=neon/mfloat-abi=hard multilib.
---
  gcc/config/arm/t-rtems-eabi |   51 +-
  1 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/gcc/config/arm/t-rtems-eabi b/gcc/config/arm/t-rtems-eabi
index f0e714a..d81fbf7 100644
--- a/gcc/config/arm/t-rtems-eabi
+++ b/gcc/config/arm/t-rtems-eabi
@@ -1,8 +1,47 @@
  # Custom RTEMS EABI multilibs
  
-MULTILIB_OPTIONS= mthumb march=armv6-m/march=armv7/march=armv7-m

-MULTILIB_DIRNAMES   = thumb armv6-m armv7 armv7-m
-MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m
-MULTILIB_MATCHES=
-MULTILIB_EXCLUSIONS =
-MULTILIB_OSDIRNAMES =
+MULTILIB_OPTIONS  = mthumb 
march=armv6-m/march=armv7-a/march=armv7-r/march=armv7-m mfpu=neon 
mfloat-abi=hard
+MULTILIB_DIRNAMES = thumb armv6-m armv7-a armv7-r armv7-m neon hard
+
+# Enumeration of multilibs
+
+MULTILIB_EXCEPTIONS =
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv6-m
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-a
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-r
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-m
+MULTILIB_EXCEPTIONS += mthumb/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb
+MULTILIB_EXCEPTIONS += march=armv6-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv6-m/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv6-m/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv6-m
+MULTILIB_EXCEPTIONS += march=armv7-a/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-a/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-a/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-a
+MULTILIB_EXCEPTIONS += march=armv7-r/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-r/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-r/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-r
+MULTILIB_EXCEPTIONS += march=armv7-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-m/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m
+MULTILIB_EXCEPTIONS += mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mfpu=neon
+MULTILIB_EXCEPTIONS += mfloat-abi=hard



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] Multilib changes ARM RTEMS

[Joel Sherrill]

Committed to 4.7, 4.8 and head.

On 5/8/2013 5:06 AM, Sebastian Huber wrote:

This patch should be applied to all open GCC branches.

This patch removes the mthumb/march=armv7 since it is virtually equal to
the mthumb/march=armv7-m multilib.  Add variants for ARMv7-A and
ARMv7-R.

I tried to use the MULTILIB_REQUIRED option, but this didn't work for
patterns with more than two options.

gcc/ChangeLog
2013-05-08  Sebastian Huber 

* config/arm/t-rtems-eabi: Remove mthumb/march=armv7 multilib.
Add mthumb/march=armv7-a multilib.
Add mthumb/march=armv7-r multilib.
Add mthumb/march=armv7-a/mfpu=neon/mfloat-abi=hard multilib.
---
  gcc/config/arm/t-rtems-eabi |   51 +-
  1 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/gcc/config/arm/t-rtems-eabi b/gcc/config/arm/t-rtems-eabi
index f0e714a..d81fbf7 100644
--- a/gcc/config/arm/t-rtems-eabi
+++ b/gcc/config/arm/t-rtems-eabi
@@ -1,8 +1,47 @@
  # Custom RTEMS EABI multilibs
  
-MULTILIB_OPTIONS= mthumb march=armv6-m/march=armv7/march=armv7-m

-MULTILIB_DIRNAMES   = thumb armv6-m armv7 armv7-m
-MULTILIB_EXCEPTIONS = march=armv6-m march=armv7 march=armv7-m
-MULTILIB_MATCHES=
-MULTILIB_EXCLUSIONS =
-MULTILIB_OSDIRNAMES =
+MULTILIB_OPTIONS  = mthumb 
march=armv6-m/march=armv7-a/march=armv7-r/march=armv7-m mfpu=neon 
mfloat-abi=hard
+MULTILIB_DIRNAMES = thumb armv6-m armv7-a armv7-r armv7-m neon hard
+
+# Enumeration of multilibs
+
+MULTILIB_EXCEPTIONS =
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv6-m/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv6-m
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-a/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-a
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-r/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-r
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/march=armv7-m/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb/march=armv7-m
+MULTILIB_EXCEPTIONS += mthumb/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mthumb/mfpu=neon
+MULTILIB_EXCEPTIONS += mthumb/mfloat-abi=hard
+# MULTILIB_EXCEPTIONS += mthumb
+MULTILIB_EXCEPTIONS += march=armv6-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv6-m/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv6-m/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv6-m
+MULTILIB_EXCEPTIONS += march=armv7-a/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-a/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-a/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-a
+MULTILIB_EXCEPTIONS += march=armv7-r/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-r/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-r/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-r
+MULTILIB_EXCEPTIONS += march=armv7-m/mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m/mfpu=neon
+MULTILIB_EXCEPTIONS += march=armv7-m/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += march=armv7-m
+MULTILIB_EXCEPTIONS += mfpu=neon/mfloat-abi=hard
+MULTILIB_EXCEPTIONS += mfpu=neon
+MULTILIB_EXCEPTIONS += mfloat-abi=hard



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

sparc64*-*-rtems* should not define __svr4__

[Joel Sherrill]

Hi

sparc64*-*-rtems* ends up with __svr4__ defined. The attached
patch corrects that.

OK to apply?

013-05-10  Joel Sherrill  

* config.gcc (sparc64*-*-rtems*): Use sp64-rtemself.h.
RTEMS target should not have -D__svr4__ in CPP_SUBTARGET_SPEC.
* config/sparc/sp64-rtemself.h: New file.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

2013-05-10  Joel Sherrill  

* config.gcc (sparc64*-*-rtems*): Use sp64-rtemself.h
RTEMS target should not have -D__svr4__ in CPP_SUBTARGET_SPEC.
* config/sparc/sp64-rtemself.h: New file.

Index: gcc/config/sparc/sp64-rtemself.h
===
--- gcc/config/sparc/sp64-rtemself.h(revision 0)
+++ gcc/config/sparc/sp64-rtemself.h(working copy)
@@ -0,0 +1,37 @@
+/* Definitions for rtems targeting a SPARC64 using ELF.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+   Contributed by Joel Sherrill (joel.sherr...@oarcorp.com).
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+/* Target OS builtins.  */
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   builtin_define ("__rtems__");   \
+   builtin_define ("__USE_INIT_FINI__");   \
+   builtin_assert ("system=rtems");\
+}  \
+  while (0)
+
+/* Use the default */
+#undef LINK_GCC_C_SEQUENCE_SPEC
+
+/* we are not svr4 */
+#undef CPP_SUBTARGET_SPEC
+#define CPP_SUBTARGET_SPEC ""
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 198775)
+++ gcc/config.gcc  (working copy)
@@ -2516,7 +2516,7 @@
tmake_file="${tmake_file} sparc/t-sparc"
;;
 sparc64-*-rtems*)
-   tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h sparc/sysv4.h 
sparc/sp64-elf.h sparc/rtemself.h rtems.h"
+   tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h sparc/sysv4.h 
sparc/sp64-elf.h sparc/sp64-rtemself.h rtems.h"
extra_options="${extra_options}"
tmake_file="${tmake_file} sparc/t-sparc sparc/t-rtems-64 t-rtems"
;;

Re: sparc64*-*-rtems* should not define __svr4__

[Joel Sherrill]

Thanks Eric. This is better. spaec64-elf should not define it either.

Eric Botcazou  wrote:


> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.

Let's remove the FIXME instead.  Applied to mainline.


2013-05-14  Eric Botcazou  

* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likewise.


--
Eric Botcazou

Re: sparc64*-*-rtems* should not define __svr4__

[Joel Sherrill]

I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.

Please and thank you

Eric Botcazou  wrote:


> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.

Let's remove the FIXME instead.  Applied to mainline.


2013-05-14  Eric Botcazou  

* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likewise.


--
Eric Botcazou

Re: [PATCH] RTEMS thread model configuration

[Joel Sherrill]

Thanks for the ping.

I updated the date on the ChangeLog and committed this.

--joel



On 9/17/2014 8:26 AM, Sebastian Huber wrote:

Ping^2.

On 02/05/14 10:46, Sebastian Huber wrote:

Ping.

On 2014-04-18 12:11, Sebastian Huber wrote:

From: Sebastian Huber 

The command line to build a GCC for RTEMS contained virtually always a
'--enable-threads'.  This patch helps to avoid this extra configuration
command line parameter and makes the GCC build a bit more user friendly
for RTEMS.

This patch should be applied to GCC 4.9 branch and master.

2014-04-18  Sebastian Huber  

 * config.gcc (*-*-rtems*): Default to 'rtems' thread model.
 Enable selection of 'posix' or no thread model.
---
   gcc/config.gcc | 8 +++-
   1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3c55c88..93d5994 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -791,7 +791,13 @@ case ${target} in
 ;;
   *-*-rtems*)
 case ${enable_threads} in
-yes) thread_file='rtems' ;;
+"" | yes | rtems) thread_file='rtems' ;;
+posix) thread_file='posix' ;;
+no) ;;
+*)
+  echo 'Unknown thread configuration for RTEMS'
+  exit 1
+  ;;
 esac
 tmake_file="${tmake_file} t-rtems"
 extra_options="${extra_options} rtems.opt"








--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Update contrib/config-list.mk

[Joel Sherrill]

Is there anyone else from GCC who needs to approve this?

As RTEMS maintainer for GCC, I am ok with it.

--joel

On 9/17/2014 8:37 AM, Sebastian Huber wrote:
> contrib/ChangeLog
> 2014-09-17  Sebastian Huber  
>
>   * config-list.mk (LIST): Add arm-rtems.
>   Add nios2-rtems.  Remove extra option from powerpc-rtems.
> ---
>  contrib/config-list.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 4345487..056fbf0 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -17,7 +17,7 @@ LIST = aarch64-elf aarch64-linux-gnu \
>arc-elf32OPT-with-cpu=arc600 arc-elf32OPT-with-cpu=arc700 \
>arc-linux-uclibcOPT-with-cpu=arc700 arceb-linux-uclibcOPT-with-cpu=arc700 \
>arm-wrs-vxworks arm-netbsdelf \
> -  arm-linux-androideabi arm-uclinux_eabi arm-eabi \
> +  arm-linux-androideabi arm-uclinux_eabi arm-eabi arm-rtems \
>arm-symbianelf avr-rtems avr-elf \
>bfin-elf bfin-uclinux bfin-linux-uclibc bfin-rtems bfin-openbsd \
>c6x-elf c6x-uclinux cr16-elf cris-elf cris-linux crisv32-elf crisv32-linux 
> \
> @@ -48,13 +48,13 @@ LIST = aarch64-elf aarch64-linux-gnu \
>moxie-uclinux moxie-rtems \
>msp430-elf \
>nds32le-elf nds32be-elf \
> -  nios2-elf nios2-linux-gnu \
> +  nios2-elf nios2-linux-gnu nios2-rtems \
>pdp11-aout picochip-elfOPT-enable-obsolete \
>powerpc-darwin8 \
>powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
>powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
>powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
> -  powerpc-rtems4.11OPT-enable-threads=yes powerpc-linux_spe \
> +  powerpc-rtems powerpc-linux_spe \
>powerpc-linux_paired powerpc64-linux_altivec \
>powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-lynxos powerpcle-elf \
>powerpcle-eabisim powerpcle-eabi rs6000-ibm-aix4.3 rs6000-ibm-aix5.1.0 \

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Update contrib/config-list.mk

[Joel Sherrill]

On 9/17/2014 10:41 AM, Sebastian Huber wrote:
> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian 
>> Huber  wrote:
>>>> contrib/ChangeLog
>>>> 2014-09-17  Sebastian Huber
>>>>
>>>>* config-list.mk (LIST): Add arm-rtems.
>>>>Add nios2-rtems.  Remove extra option from powerpc-rtems.
>> What's the rationale for removing --enable-threads=yes here, as well
>> as the specific version number?
> The version number can be arbitrary.  All the other RTEMS targets in 
> this list omit it.
>
> The --enable-threads=yes is not specific to PowerPC for RTEMS.  So all 
> RTEMS targets should have it or none.  With a recent commit this option 
> is superfluous.
>
I was noticing that at least the v850 is not represented
by any target.  Other than that, it looks like all the RTEMS
targets except that the or1k (which is not in the FSF tree
yet) are included.  I didn't review against the list of *-elf
targets though.

What is the rationale for inclusion on the list? Should
v850-elf and v850-rtems also be added?

And is this the input to your buildbot? :)

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Update contrib/config-list.mk

[Joel Sherrill]

I committed this to 4.9 and head.

Sebastian.. please double check that it is OK please.
I had some issues with applying it to the head and
manually did it.

--joel
On 9/17/2014 8:37 AM, Sebastian Huber wrote:
> contrib/ChangeLog
> 2014-09-17  Sebastian Huber  
>
>   * config-list.mk (LIST): Add arm-rtems.
>   Add nios2-rtems.  Remove extra option from powerpc-rtems.
> ---
>  contrib/config-list.mk | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 4345487..056fbf0 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -17,7 +17,7 @@ LIST = aarch64-elf aarch64-linux-gnu \
>arc-elf32OPT-with-cpu=arc600 arc-elf32OPT-with-cpu=arc700 \
>arc-linux-uclibcOPT-with-cpu=arc700 arceb-linux-uclibcOPT-with-cpu=arc700 \
>arm-wrs-vxworks arm-netbsdelf \
> -  arm-linux-androideabi arm-uclinux_eabi arm-eabi \
> +  arm-linux-androideabi arm-uclinux_eabi arm-eabi arm-rtems \
>arm-symbianelf avr-rtems avr-elf \
>bfin-elf bfin-uclinux bfin-linux-uclibc bfin-rtems bfin-openbsd \
>c6x-elf c6x-uclinux cr16-elf cris-elf cris-linux crisv32-elf crisv32-linux 
> \
> @@ -48,13 +48,13 @@ LIST = aarch64-elf aarch64-linux-gnu \
>moxie-uclinux moxie-rtems \
>msp430-elf \
>nds32le-elf nds32be-elf \
> -  nios2-elf nios2-linux-gnu \
> +  nios2-elf nios2-linux-gnu nios2-rtems \
>pdp11-aout picochip-elfOPT-enable-obsolete \
>powerpc-darwin8 \
>powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
>powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
>powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
> -  powerpc-rtems4.11OPT-enable-threads=yes powerpc-linux_spe \
> +  powerpc-rtems powerpc-linux_spe \
>powerpc-linux_paired powerpc64-linux_altivec \
>powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-lynxos powerpcle-elf \
>powerpcle-eabisim powerpcle-eabi rs6000-ibm-aix4.3 rs6000-ibm-aix5.1.0 \

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Update contrib/config-list.mk

[Joel Sherrill]

On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
> On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill  
> wrote:
>> On 9/17/2014 10:41 AM, Sebastian Huber wrote:
>>> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>>>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian 
>>>> Huber  wrote:
>>>>>> contrib/ChangeLog
>>>>>> 2014-09-17  Sebastian Huber
>>>>>>
>>>>>>  * config-list.mk (LIST): Add arm-rtems.
>>>>>>  Add nios2-rtems.  Remove extra option from powerpc-rtems.
>>>> What's the rationale for removing --enable-threads=yes here, as well
>>>> as the specific version number?
> [...]
>> And is this the input to your buildbot? :)
> Yes, the target list in contrib/config-list.mk is what'll be built
> using the config-list.mk-building backend. (The robot has another
> backend using a different build strategy, which has a separate target
> list, though one could argue that I'd also include all the
> config-list.mk targets in that other list as well.)
>
>   And to tell the whole story, Sebastian approached me with extending
> the target lists in use by those targets he sent a patch for; I just
> asked him to go this route, because I guess that'd be beneficial for
> other folks as well.
OK. Thanks for clarifying that. I suspected there was a link.

And it is committed.  And I will post a follow up patch to
add v850-elf and v850-rtems.

--joel
> MfG, JBG
>

[PATCH] Add v850-rtems to contrib/config-list.mk

[Joel Sherrill]

OK to commit?

2014-09-18  Joel Sherrill 

* config-list.mk (LIST): Add v850-rtems.

Index: contrib/config-list.mk
===
--- contrib/config-list.mk  (revision 215357)
+++ contrib/config-list.mk  (working copy)
@@ -68,7 +68,7 @@
   sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux
sparc64-freebsd6 \
   sparc64-netbsd sparc64-openbsd spu-elf \
   tilegx-linux-gnu tilegxbe-linux-gnu tilepro-linux-gnu \
-  v850e-elf v850-elf vax-linux-gnu \
+  v850e-elf v850-elf v850-rtems vax-linux-gnu \
   vax-netbsdelf vax-openbsd x86_64-apple-darwin \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] Add v850-rtems to contrib/config-list.mk

[Joel Sherrill]

Thanks. Committed to 4.9 and head.

--joel
On 9/18/2014 1:28 PM, Jeff Law wrote:
> On 09/18/14 09:31, Joel Sherrill wrote:
>> OK to commit?
>>
>> 2014-09-18  Joel Sherrill 
>>
>>  * config-list.mk (LIST): Add v850-rtems.
> Yes.
>
> jeff
>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Update contrib/config-list.mk

[Joel Sherrill]

On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
> On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill  
> wrote:
>> On 9/17/2014 10:41 AM, Sebastian Huber wrote:
>>> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>>>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian 
>>>> Huber  wrote:
>>>>>> contrib/ChangeLog
>>>>>> 2014-09-17  Sebastian Huber
>>>>>>
>>>>>>  * config-list.mk (LIST): Add arm-rtems.
>>>>>>  Add nios2-rtems.  Remove extra option from powerpc-rtems.
>>>> What's the rationale for removing --enable-threads=yes here, as well
>>>> as the specific version number?
> [...]
>> And is this the input to your buildbot? :)
> Yes, the target list in contrib/config-list.mk is what'll be built
> using the config-list.mk-building backend. (The robot has another
> backend using a different build strategy, which has a separate target
> list, though one could argue that I'd also include all the
> config-list.mk targets in that other list as well.)
>
>   And to tell the whole story, Sebastian approached me with extending
> the target lists in use by those targets he sent a patch for; I just
> asked him to go this route, because I guess that'd be beneficial for
> other folks as well.
I only see one RTEMS target that has been built in the top page.
Are more than the powerpc-rtems being built? How can I check?

Thanks.
> MfG, JBG
>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Use __cxa_atexit by default for RTEMS

[Joel Sherrill]

This is now committed.

Please double check me, Sebastian.

--joel

On 7/31/2013 2:02 AM, Sebastian Huber wrote:

Ping.

On 2013-07-08 15:29, Sebastian Huber wrote:

The __cxa_atexit support is a reqirement for destructor registration of
thread-local objects.

For *-*-elf it is already enabled by default.  See comment line 810 in
"gcc/config.gcc".

Define TARGET_LIBGCC_SDATA_SECTION on PowerPC for RTEMS to ".sdata" to
place the __dso_handle.  The __dso_handle is referenced by application
code.  In case this code uses the small data section, the __dso_handle
must be there.

This patch should be committed to GCC 4.8 and 4.9.

Test results:

http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00671.html

gcc/ChangeLog
2013-07-08  Sebastian Huber  

* config.gcc (*-*-rtems*): Use __cxa_atexit by default.
* config/rs6000/rtems.h (TARGET_LIBGCC_SDATA_SECTION): Define.
---
   gcc/config.gcc|1 +
   gcc/config/rs6000/rtems.h |3 +++
   2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index a927964..1648dfe 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -734,6 +734,7 @@ case ${target} in
   yes) thread_file='rtems' ;;
 esac
 extra_options="${extra_options} rtems.opt"
+  default_use_cxa_atexit=yes
 use_gcc_stdint=wrap
 ;;
   *-*-uclinux*)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index b910b5e..fb22be1 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -34,6 +34,9 @@
   } \
 while (0)

+#undef TARGET_LIBGCC_SDATA_SECTION
+#define TARGET_LIBGCC_SDATA_SECTION ".sdata"
+
   #undef CPP_OS_DEFAULT_SPEC
   #define CPP_OS_DEFAULT_SPEC "%(cpp_os_rtems)"







--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

lm32 build error

[Joel Sherrill]

Hi

This has been around for a while as PR52466 which has
a patch. I have attached the patch.  Is it OK to apply to
the open branches?

2013-08-07  Joel Sherrill 

* configure.ac (lm32*-*-*): Use SJLJ exceptions.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

diff --git a/gcc/configure.ac b/gcc/configure.ac
index f629d15..d00c69b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1209,6 +1209,10 @@ force_sjlj_exceptions=yes],
 force_sjlj_exceptions=yes
 enableval=yes
 ;;
+  lm32*-*-*)
+force_sjlj_exceptions=yes
+enableval=yes
+;;
   *)
 force_sjlj_exceptions=no
 ;;

Re: Convert arm-rtems to EABI on 4.6 and 4.7 branches

[Joel Sherrill]

On 3/7/2013 3:50 AM, Eric Botcazou wrote:

We would like to get the 4.7 patch applied so arm-rtems is not obsolete.

If there are any hints of a plan to release another 4.6 version, we would
like to apply a patch to that branch to switch from arm-elf to arm-eabi
as our foundation.

Please adjust the ChangeLog entry on the branches, putting 2013-02-22 for a
patch installed on 2013-03-06 doesn't make much sense.  There is an example
just below on the 4.7 branch.  TIA.


Done.

Sorry. I used Sebastian's entries without even thinking they were at 
least a week old.


--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] Sort targets alphabetically

[Joel Sherrill]

Committed to 4.8 branch and head as obvious and cosmetic.

--joel
RTEMS

On 3/22/2013 3:42 PM, Sebastian Huber wrote:

gcc/testsuite/ChangeLog
2013-03-22  Sebastian Huber  

* gcc.c-torture/execute/builtins/builtins.exp: Sort targets
alphabetically.
---
  gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp 
b/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
index 1e3359c..d157fe3 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
@@ -43,8 +43,8 @@ if [istarget "powerpc-*-darwin*"] {
  }
  if { [istarget *-*-eabi*]
   || [istarget *-*-elf]
- || [istarget *-*-rtems*]
- || [istarget *-*-mingw*] } {
+ || [istarget *-*-mingw*]
+ || [istarget *-*-rtems*] } {
 lappend additional_flags "-Wl,--allow-multiple-definition"
  }
  



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] Add -pthread option for RTEMS

[Joel Sherrill]

I committed this patch which reduces test failures.

http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01373.html

2013-01-29  Sebastian Huber  

* config/rtems.opt: Add -pthread option.


--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Ping on PowerPC PR55033

[Joel Sherrill]

Hi

Would it be possible for a PowerPC maintainer to look
into committing the fix to this PR to the impacted
branches which are open?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00970.html

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: GCC 4.7.3 Status Report (2013-04-03)

[Joel Sherrill]

The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the 
past few days. It is a one line arm-rtems specific path to libcpp configure.

Can I commit that?

--joel
RTEMS

Richard Biener  wrote:


Status
==

The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.7.3 which should happen roughly
one week after the release candidate.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   86   +  2
P36   - 12
---   ---
Total92   - 10


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html


The next report will be sent by me after the release

Re: GCC 4.7.3 Status Report (2013-04-03)

[Joel Sherrill]

On 4/3/2013 8:36 AM, Richard Biener wrote:

On Wed, 3 Apr 2013, Joel Sherrill wrote:


The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the 
past few days. It is a one line arm-rtems specific path to libcpp configure.

Can I commit that?

Sure, if it got RTEMS maintainer approval.

That's me. So I will commit it .

Thanks.

Richard.


--joel
RTEMS

Richard Biener  wrote:


Status
==

The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.7.3 which should happen roughly
one week after the release candidate.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   86   +  2
P36   - 12
---   ---
Total92   - 10


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html


The next report will be sent by me after the release





--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH v2] PR56771: Fix arm-rtems target for 32-bit hosts

[Joel Sherrill]

This patch has been applied to 4.7, 4.8 and 4.9.

PR 56771 closed.

--joel

On 4/2/2013 10:08 AM, Sebastian Huber wrote:

This patch is for GCC 4.8 and 4.9.

v2: Fix ChangeLog.

libcpp/ChangeLog
2013-04-02  Sebastian Huber  

PR target/56771
* configure.ac: Require 64-bit int for arm*-*-rtems*.
* configure: Regenerate.
---
  libcpp/configure|1 +
  libcpp/configure.ac |1 +
  2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libcpp/configure b/libcpp/configure
index f21b361..7158186 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -7153,6 +7153,7 @@ case $target in
aarch64*-*-* | \
alpha*-*-* | \
arm*-*-*eabi* | \
+   arm*-*-rtems* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \
diff --git a/libcpp/configure.ac b/libcpp/configure.ac
index e0c4ae6..43ac9ba 100644
--- a/libcpp/configure.ac
+++ b/libcpp/configure.ac
@@ -185,6 +185,7 @@ case $target in
aarch64*-*-* | \
alpha*-*-* | \
arm*-*-*eabi* | \
+   arm*-*-rtems* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH v2] RTEMS: Generalize t-rtems usage

[Joel Sherrill]

  tm_file="h8300/h8300.h dbxelf.h elfos.h h8300/elf.h h8300/rtems.h 
> rtems.h newlib-stdint.h"
>   ;;
>  h8300-*-elf*)
> @@ -1500,7 +1501,7 @@ i[34567]86-*-nto-qnx*)
>   ;;
>  i[34567]86-*-rtems*)
>   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
> i386/i386elf.h i386/rtemself.h rtems.h newlib-stdint.h"
> - tmake_file="${tmake_file} i386/t-rtems t-rtems"
> + tmake_file="${tmake_file} i386/t-rtems"
>   ;;
>  i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
>   tm_file="${tm_file} i386/unix.h i386/att.h ${sol2_tm_file}"
> @@ -1748,7 +1749,6 @@ lm32-*-elf*)
>  lm32-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} lm32/rtems.h rtems.h 
> newlib-stdint.h"
>   tmake_file="${tmake_file} lm32/t-lm32"
> - tmake_file="${tmake_file} t-rtems"
>   tmake_file="${tmake_file} lm32/t-rtems"
>   ;;
>  lm32-*-uclinux*)
> @@ -1763,7 +1763,7 @@ m32rle-*-elf*)
>   ;;
>  m32r-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} m32r/rtems.h rtems.h 
> newlib-stdint.h"
> - tmake_file="m32r/t-m32r t-rtems"
> + tmake_file="${tmake_file} m32r/t-m32r"
>   ;;
>  m32r-*-linux*)
>   tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} 
> m32r/linux.h"
> @@ -1854,7 +1854,7 @@ m68k-*-linux*)  # Motorola m68k's 
> running GNU/Linux
>  m68k-*-rtems*)
>   default_m68k_cpu=68020
>   default_cf_cpu=5206
> - tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems 
> m68k/t-rtems m68k/t-mlibs"
> + tmake_file="${tmake_file} m68k/t-floatlib m68k/t-m68kbare 
> m68k/t-crtstuff m68k/t-rtems m68k/t-mlibs"
>   tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h 
> m68k/m68kemb.h m68k/m68020-elf.h m68k/rtemself.h rtems.h newlib-stdint.h"
>   tm_defines="${tm_defines} MOTOROLA=1"
>   ;;
> @@ -1904,7 +1904,7 @@ microblaze*-*-rtems*)
>   c_target_objs="${c_target_objs} microblaze-c.o"
>   cxx_target_objs="${cxx_target_objs} microblaze-c.o"
>   tmake_file="${tmake_file} microblaze/t-microblaze"
> - tmake_file="${tmake_file} t-rtems microblaze/t-rtems"
> + tmake_file="${tmake_file} microblaze/t-rtems"
>  ;;
>  microblaze*-*-elf)
>   case $target in
> @@ -2079,7 +2079,7 @@ mips64orion-*-elf* | mips64orionel-*-elf*)
>   ;;
>  mips*-*-rtems*)
>   tm_file="elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/rtems.h 
> rtems.h"
> - tmake_file="mips/t-elf t-rtems mips/t-rtems"
> + tmake_file="${tmake_file} mips/t-elf mips/t-rtems"
>   ;;
>  mips-wrs-vxworks)
>   tm_file="elfos.h ${tm_file} mips/elf.h vx-common.h vxworks.h 
> mips/vxworks.h"
> @@ -2236,7 +2236,7 @@ powerpc-*-eabi*)
>  powerpc-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
> rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/rtems.h rtems.h"
>   extra_options="${extra_options} rs6000/sysv4.opt"
> - tmake_file="rs6000/t-fprules rs6000/t-rtems t-rtems rs6000/t-ppccomm"
> + tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems 
> rs6000/t-ppccomm"
>   ;;
>  powerpc*-*-linux*)
>   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h rs6000/sysv4.h"
> @@ -2607,7 +2607,7 @@ sh-*-elf* | sh[12346l]*-*-elf* | \
>   tmake_file="$tmake_file t-sysroot-suffix"
>   ;;
>  sh-*-rtems*)
> - tmake_file="sh/t-sh t-rtems sh/t-rtems"
> + tmake_file="${tmake_file} sh/t-sh sh/t-rtems"
>   tm_file="${tm_file} dbxelf.h elfos.h sh/elf.h sh/embed-elf.h 
> sh/rtemself.h rtems.h newlib-stdint.h"
>   ;;
>  sh-wrs-vxworks)
> @@ -2630,7 +2630,7 @@ sparc-*-elf*)
>   ;;
>  sparc-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h sparc/sp-elf.h 
> sparc/rtemself.h rtems.h newlib-stdint.h"
> - tmake_file="sparc/t-sparc sparc/t-elf sparc/t-rtems t-rtems"
> + tmake_file="${tmake_file} sparc/t-sparc sparc/t-elf sparc/t-rtems"
>   ;;
>  sparc-*-linux*)
>   tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h gnu-user.h linux.h 
> glibc-stdint.h sparc/tso.h"
> @@ -2684,7 +2684,7 @@ sparc64-*-elf*)
>  sparc64-*-rtems*)
>   tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h sparc/sysv4.h 
> sparc/sp64-elf.h sparc/rtemself.h rtems.h"
>   extra_options="${extra_options}"
> - tmake_file="${tmake_file} sparc/t-sparc sparc/t-rtems-64 t-rtems"
> + tmake_file="${tmake_file} sparc/t-sparc sparc/t-rtems-64"
>   ;;
>  sparc64-*-linux*)
>   tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h sparc/sysv4.h 
> gnu-user.h linux.h glibc-stdint.h sparc/default-64.h sparc/linux64.h 
> sparc/tso.h"
> @@ -2761,7 +2761,7 @@ v850-*-rtems*)
>   tm_file="dbxelf.h elfos.h v850/v850.h"
>   tm_file="${tm_file} rtems.h v850/rtems.h newlib-stdint.h"
>   tmake_file="${tmake_file} v850/t-v850"
> - tmake_file="${tmake_file} t-rtems v850/t-rtems"
> + tmake_file="${tmake_file} v850/t-rtems"
>   use_collect2=no
>   c_target_objs="v850-c.o"
>   cxx_target_objs="v850-c.o"
> @@ -2834,7 +2834,6 @@ am33_2.0-*-linux*)
>   ;;
>  m32c-*-rtems*)
>   tm_file="dbxelf.h elfos.h ${tm_file} m32c/rtems.h rtems.h 
> newlib-stdint.h"
> - tmake_file="${tmake_file} t-rtems"
>   c_target_objs="m32c-pragma.o"
>   cxx_target_objs="m32c-pragma.o"
>   ;;

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] RTEMS: Add Nios 2 support

[Joel Sherrill]

Unless someone objects, I am going to commit this to the
4.9 branch and head.

--joel

On 7/7/2014 1:42 AM, Sebastian Huber wrote:
> Ping.
>
> On 2014-06-26 13:43, Sebastian Huber wrote:
>> This patch should be applied to GCC 4.9 and mainline.  I do not have
>> write access, so in case this gets approved, please commit it for me.
>>
>> gcc/ChangeLog
>> 2014-06-26  Sebastian Huber  
>>
>>  * config.gcc (nios2-*-*): Add RTEMS support.
>>  * config/nios2/rtems.h: New file.
>>  * config/nios2/t-rtems: Likewise.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

libgcc/config.host: Fix v850-rtems bug

[Joel Sherrill]

Hi

It took a while to find this but v850-rtems lost the include
paths for the rtems specific .h files in newlib due to
the line that resets tmake_file rather than appends to it.

Is this OK to apply to all impacted branches and the head?

2014-03-20  Joel Sherrill  

* config.host (v850*-*-*): Add to tmake_file instead of resetting
it. This was removing the v850*-*-rtems* settings.

diff --git a/libgcc/config.host b/libgcc/config.host
index bdc725f..f8f74cc 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1195,7 +1195,7 @@ tilepro*-*-linux*)
md_unwind_header=tilepro/linux-unwind.h
 ;;
 v850*-*-*)
-   tmake_file="v850/t-v850 t-fdpbit"
+   tmake_file="${tmake_file} v850/t-v850 t-fdpbit"
;;
 vax-*-linux*)
tmake_file="$tmake_file vax/t-linux"

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: libgcc/config.host: Fix v850-rtems bug

[Joel Sherrill]

On 3/20/2014 10:57 AM, Rainer Orth wrote:
> Hi Joel,
>
>> It took a while to find this but v850-rtems lost the include
>> paths for the rtems specific .h files in newlib due to
>> the line that resets tmake_file rather than appends to it.
>>
>> Is this OK to apply to all impacted branches and the head?
>>
>> 2014-03-20  Joel Sherrill  
>>
>> * config.host (v850*-*-*): Add to tmake_file instead of resetting
>> it. This was removing the v850*-*-rtems* settings.
> Omit the `This was removing...' part: no explanations in ChangeLogs.
>
> I believe this is your call as RTEMS maintainer, even this late in the
> 4.9 release cycle, since it cannot affect any other target.
Done. This is a minor issue which results in the target being unbuildable.

Also committed to 4.7 and 4.8.

Thanks.
>   Rainer
>

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Convert arm-rtems to EABI on 4.6 and 4.7 branches

[Joel Sherrill]

Hi

The RTEMS Community has realized we allowed something to occur
that should not have happened. As arm-elf was deprecated and removed,
we should have moved to EABI as our base.  The gcc head and 4.8 have
this situation corrected. Unfortunately, we let the arm-rtems target
get marked obsolete in 4.7 and 4.6 still is based on arm-elf.

All of the RTEMS preferred object format targets follow the
pattern CPU-rtems. Sebastian Huber has posted patches multiple
times with test results which we are happy with. These do not
touch any other target or the test suite. He updated them and
posted them again.

http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01063.html
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01064.html


All of our documentation, howto's, scripts, and users etc. have built up
the expectation that the preferred tool target is CPU-rtems. Having to
use arm-rtemseabi is an aberration from that pattern and is confusing
to our community.

We would like to get the 4.7 patch applied so arm-rtems is not obsolete.

If there are any hints of a plan to release another 4.6 version, we would
like to apply a patch to that branch to switch from arm-elf to arm-eabi
as our foundation.

As RTEMS GCC target maintainer, I can approve these changes but I would
like concurrence with the branch release managers.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: serious libgcc regression added recently

[Joel Sherrill]

On 11/02/2011 03:36 PM, David Miller wrote:

My sparc-linux-gnu builds with --enable-targets=all is failing with:

../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global 
register use not covered by .register pseudo-op
../../../../gcc/libgcc/config/sparc/lb1spc.S:134: Error: detected global 
register use not covered by .register pseudo-op
...

It looks like it's trying to build 32-bit sparc files during the -m64
64-bit multiarch build or similar.  Or, alternatively, doing the
32-bit multiarch build with 64-bit options.

And others have reported link failures during the testsuite on
other targets.


Is this similar to what I just got for sparc-rtems when compiling
libgcc2 with -mcpu=v8?

/tmp/cczMc4jN.s: Assembler messages:
/tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for 
"smul".
/tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for 
"smul".
/tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for 
"umul".


I can prepare a PR if you think it is different.

Rainer it seems it might be your changes?



--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: serious libgcc regression added recently

[Joel Sherrill]

On 11/02/2011 05:30 PM, David Miller wrote:

From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500


Is this similar to what I just got for sparc-rtems when compiling
libgcc2 with -mcpu=v8?

/tmp/cczMc4jN.s: Assembler messages:
/tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
"smul".
/tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
"smul".
/tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
"umul".

I can prepare a PR if you think it is different.

I don't think so.  The bug I'm hitting seems to be simply that
config/sparc/t-linux64 wasn't migrated up into the libgcc configure
area properly the way that config/sparc/t-linux was.

I'm working on a fix right now.

I filed a PR for this so it doesn't get lost.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979

I am happy to retest whenever something changes.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

GCC: Add microblaze-*-rtems*

[Joel Sherrill]

This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?

2012-05-07  Joel Sherrill 

* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file

--
Joel Sherrill, Ph.D. Director of Research&   Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available (256) 722-9985

GCC: Add microblaze-*-rtems* (w/ diff)

[Joel Sherrill]

Sorry.. missed the attachment

This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?

2012-05-07 Joel Sherrill 

* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file.

--
Joel Sherrill, Ph.D. Director of Research&   Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available (256) 722-9985


Index: gcc/config.gcc
===
--- gcc/config.gcc	(revision 187223)
+++ gcc/config.gcc	(working copy)
@@ -1700,6 +1700,12 @@
 	c_target_objs="${c_target_objs} microblaze-c.o"
 	cxx_target_objs="${cxx_target_objs} microblaze-c.o"
 	;;
+microblaze-*-rtems*)
+	tm_file="${tm_file} dbxelf.h microblaze/rtems.h rtems.h newlib-stdint.h"
+	c_target_objs="${c_target_objs} microblaze-c.o"
+	cxx_target_objs="${cxx_target_objs} microblaze-c.o"
+tmake_file="${tmake_file} microblaze/t-microblaze t-rtems"
+	;;
 microblaze*-*-*)
 tm_file="${tm_file} dbxelf.h"
 	c_target_objs="${c_target_objs} microblaze-c.o"
Index: gcc/config/microblaze/rtems.h
===
--- gcc/config/microblaze/rtems.h	(revision 0)
+++ gcc/config/microblaze/rtems.h	(revision 0)
@@ -0,0 +1,42 @@
+/* Definitions for rtems targeting a Microblaze using ELF.
+   Copyright (C) 2012 Free Software Foundation, Inc.
+   Contributed by Joel Sherrill (j...@oarcorp.com).
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+/* Target OS builtins.  */
+#undef TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()		\
+  do		\
+{		\
+	builtin_define ("__rtems__");		\
+	builtin_assert ("system=rtems");	\
+}		\
+  while (0)
+
+/* Use the default */
+#undef LINK_GCC_C_SEQUENCE_SPEC
+
+/* Extra switches sometimes passed to the linker.  */
+/* -xl-mode-xmdstub translated to -Zxl-mode-xmdstub -- deprecated.  */
+/* RTEMS: Remove use of xilinx.ld but keep other parts for compatibility */
+#undef LINK_SPEC
+#define LINK_SPEC "%{shared:-shared} -N -relax \
+  %{Zxl-mode-xmdstub:-defsym _TEXT_START_ADDR=0x800} \
+  %{mxl-mode-xmdstub:-defsym _TEXT_START_ADDR=0x800} \
+  %{mxl-gp-opt:%{G*}} %{!mxl-gp-opt: -G 0}"
+

arm-rtems switch default target to EABI

[Joel Sherrill]

Hi

Since patches in PRs don't get much attention,
this is an email about the attached patches
from Sebastian Huber and myself to correct
the arm rtems target name situation.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325

There is a long explanation in the PR but the short
version is that although we fully intended to switch
the arm-rtems target from ELF to EABI we never
intended the target name "arm-*-rtemseabi*" to
become the preferred arm RTEMS target name.
We want all RTEMS target names to be of the form
-rtems.  Unfortunately, we screwed up
and arm-rtems is marked as deprecated in 4.7.

These patches do the following:

+ rename arm-*-rtems* to arm-*-rtemself*
+ make arm-*-rtemself* deprecated
+ make arm-*-rtems* an accepted name for
arm-*-rtemseabi*

arm-*-rtemself* can disappear when the ARM elf
targets are generally removed.

Sebastian tested them and the results are at:

http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00322.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00323.html
http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00324.html

RTEMS is very consistent across target architectures
and this just slipped through. We handled switches from
a.out -> coff -> elf in a similar manner in the past.

I hope it is OK to merge this.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research&   Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available (256) 722-9985


commit 367ff875a7bb92a02c2f7390cdf9d0027435a099
Author: Sebastian Huber 
Date:   Fri May 4 09:23:58 2012 +0200

ARM RTEMS changes

2012-04-04  Sebastian Huber 

* config.gcc (arm*-*-rtemself*): New.
(arm*-*-rtems*): Removed.
(arm*-*-eabi* | arm*-*-symbianelf*): Add (arm*-*-rtems*).
* config/arm/rtems-eabi.h: New file.
* config/arm/t-rtems-eabi: New file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 129e7db..671d64f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -870,7 +870,13 @@ arm*-*-ecos-elf)
tmake_file="arm/t-arm arm/t-arm-elf"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-eabi* | arm*-*-symbianelf* )
+arm*-*-rtemself*)
+   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
+   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
+   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
+   use_gcc_stdint=provide
+   ;;
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3.  Correctly modeling that requires the use of
# TImode.
@@ -885,6 +891,11 @@ arm*-*-eabi* | arm*-*-symbianelf* )
  tmake_file="${tmake_file} arm/t-bpabi"
  use_gcc_stdint=wrap
  ;;
+   arm*-*-rtems*)
+ tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
+ tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
+ use_gcc_stdint=provide
+ ;;
arm*-*-symbianelf*)
  tm_file="${tm_file} arm/symbian.h"
  # We do not include t-bpabi for Symbian OS because the system
@@ -895,11 +906,6 @@ arm*-*-eabi* | arm*-*-symbianelf* )
tm_file="${tm_file} arm/aout.h arm/arm.h"
tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
;;
-arm*-*-rtems*)
-   tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h 
arm/arm.h arm/rtems-elf.h rtems.h newlib-stdint.h"
-   tmake_file="arm/t-arm arm/t-arm-elf t-rtems arm/t-rtems"
-   tmake_file="${tmake_file} arm/t-arm-softfp soft-fp/t-softfp"
-   ;;
 arm*-*-elf)
tm_file="dbxelf.h elfos.h newlib-stdint.h arm/unknown-elf.h arm/elf.h 
arm/aout.h arm/arm.h"
tmake_file="arm/t-arm arm/t-arm-elf"
diff --git a/gcc/config/arm/rtems-eabi.h b/gcc/config/arm/rtems-eabi.h
new file mode 100644
index 000..ced98a9
--- /dev/null
+++ b/gcc/config/arm/rtems-eabi.h
@@ -0,0 +1,29 @@
+/* Definitions for RTEMS based ARM systems using EABI.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+ 
+   This file is part of GCC.
+ 
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+ 
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+ 
+   You should have received a copy of the GNU General Public License
+ 

m32r-rtems libgcc config missing crtinit/fini

[Joel Sherrill]

Hi

When moving stuff into libgcc, a line for m32r-rtems
got lost.  This is PR53314.

Is this OK for the head and 4.7?

2012-05-16  Joel Sherrill 

* config.host (m32r-*-rtems*): Include crtinit.o and crtfinit.o
as extra_parts.

diff --git a/libgcc/config.host b/libgcc/config.host
index 14c705b..b79f321 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -679,6 +682,7 @@ m32r-*-elf*)
;;
 m32r-*-rtems*)
tmake_file="$tmake_file m32r/t-m32r t-fdpbit"
+   extra_parts="$extra_parts crtinit.o crtfini.o"
;;
 m32rle-*-elf*)
tmake_file=t-fdpbit

--
Joel Sherrill, Ph.D. Director of Research&   Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available (256) 722-9985

Re: [arm] Remove obsolete FPA support (1/n): obsolete target removal

[Joel Sherrill]

It will naturally disappear when gcc does the clean up. It won't be around 
long. 

Sebastian Huber  wrote:

>On 06/13/2012 02:51 PM, Richard Earnshaw wrote:
>>  (arm*-*-rtems*): Remove.
>
>For RTEMS the intention was to rename arm*-*-rtemseabi* into arm*-*-rtems* and 
>provide an arm*-*-rtemself* legacy target.  My personal opinion is to avoid a 
>arm*-*-rtemself* legacy target, but it was decided otherwise by the RTEMS 
>community.
>
>See also:
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
>http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00939.html
>
>-- 
>Sebastian Huber, embedded brains GmbH
>
>Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>Phone   : +49 89 18 90 80 79-6
>Fax : +49 89 18 90 80 79-9
>E-Mail  : sebastian.hu...@embedded-brains.de
>PGP : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: [PATCH] GCC 4.7 and 4.8 PowerPC RTEMS (libgcc)

[Joel Sherrill]

Hi,

This patch is OK by me but I want to clarify something
with the PowerPC libgcc experts.

This makes tmake_file settings the same for powerpc-rtems
and powerpc-eabi. But our settings for extra_parts is different.
We are missing crtbegin.o and crtend.o but have the variant
names. Shouldn't they also be the same?

And if they should be the same, wouldn't it make
sense to combine the stanzas?

Just wanting advice from someone who knows more. :)

--joel


Hi, please have a look at the attached patch. Test suite results for 
GCC 4.7 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html

--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
2012-03-08  Sebastian Huber

 * config.host (powerpc-*-rtems*): Add rs6000/t-savresfgpr to
 tmake_file.

diff --git a/libgcc/config.host b/libgcc/config.host
index 257622a..f6432c5 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -884,7 +884,7 @@ powerpc-*-eabi*)
extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o 
crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
;;
  powerpc-*-rtems*)
-   tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-crtstuff t-crtstuff-pic 
t-fdpbit"
+   tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr 
rs6000/t-crtstuff t-crtstuff-pic t-fdpbit"
extra_parts="$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o 
ncrti.o ncrtn.o"
    ;;
  powerpc-*-linux* | powerpc64-*-linux*)


--
Joel Sherrill, Ph.D. Director of Research&   Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available (256) 722-9985

Re: [build] Cleanup rs6000/t-ppccomm configurations (PR other/51022)

[Joel Sherrill]

On 11/21/2011 11:25 AM, Rainer Orth wrote:

Paolo Bonzini  writes:


Wrong patch attached.

Indeed ;-)


Does this patch apply OK for others?

Ranier.. you can just send me the impacted files if you like.  I have
no local changes to libgcc.

$ cat /tmp/libgcc-t-savresfgpr.patch | patch -p1
patching file libgcc/config.host
Hunk #1 succeeded at 843 (offset -9 lines).
patching file libgcc/config/rs6000/t-ppccomm
patching file libgcc/config/rs6000/t-ppccomm-ldbl
patching file libgcc/config/rs6000/t-ppccomm
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 21.
2 out of 2 hunks FAILED -- saving rejects to file 
libgcc/config/rs6000/t-ppccomm.rej



--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: [build] Cleanup rs6000/t-ppccomm configurations (PR other/51022)

[Joel Sherrill]

Thanks.

Works for me.  I posted test results for powerpc-rtems4.11
at http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02314.html

From the rtems perspective, you can commit it.

--joel

On 11/21/2011 12:08 PM, Rainer Orth wrote:

Joel Sherrill  writes:


Does this patch apply OK for others?

Ranier.. you can just send me the impacted files if you like.  I have
no local changes to libgcc.

$ cat /tmp/libgcc-t-savresfgpr.patch | patch -p1
patching file libgcc/config.host
Hunk #1 succeeded at 843 (offset -9 lines).
patching file libgcc/config/rs6000/t-ppccomm
patching file libgcc/config/rs6000/t-ppccomm-ldbl
patching file libgcc/config/rs6000/t-ppccomm
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 21.
2 out of 2 hunks FAILED -- saving rejects to file
libgcc/config/rs6000/t-ppccomm.rej

Released versions of patch cannot deal with git-style patches (a copy in
this case), it seems.  git patch (or a snapshot from alpha.gnu.org)
should be ok.

I'm including libgcc/config/rs6000/t-savresfgpr for your convenience.

Rainer

RTEMS Specific Ada Patch

[Joel Sherrill]

Hi,

The attached patch is necessary to let the gcc head
compile Ada for *-*-rtems*.  Other than terminals.c,
the files impacted are RTEMS specific.  OK to commit?

I have posted ACATS results for sparc-rtems4.11 at

http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00108.html

These are better results than what I posted back in
April for a 4.6.1 prerelease:

http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00209.html

2011-12-01  Joel Sherrill 

* gcc/ada/s-tpopsp-rtems.adb: Use ATCB_Key rather than
RTEMS_Ada_Self variable for consistency with other ports.
* gcc/ada/s-osinte-rtems.adb: Add body for dummy implementation
of pthread_rwlockattr_setkind_np().
* gcc/ada/s-osinte-rtems.ads: Add missing clock and rwlock 
bindings.

* gcc/ada/terminals.c: Add __rtems__ conditionals to account
for differences in termios implementation.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985


2011-12-01  Joel Sherrill 

* gcc/ada/s-tpopsp-rtems.adb: Use ATCB_Key rather than
RTEMS_Ada_Self variable for consistency with other ports.
* gcc/ada/s-osinte-rtems.adb: Add body for dummy implementation
of pthread_rwlockattr_setkind_np().
* gcc/ada/s-osinte-rtems.ads: Add missing clock and rwlock bindings.
* gcc/ada/terminals.c: Add __rtems__ conditionals to account
for differences in termios implementation.

Index: gcc/ada/s-tpopsp-rtems.adb
===
--- gcc/ada/s-tpopsp-rtems.adb  (revision 181881)
+++ gcc/ada/s-tpopsp-rtems.adb  (working copy)
@@ -10,7 +10,7 @@
 -- $Revision: 1.2 $
 --  --
 --Copyright (C) 1991-2003, Florida State University --
---Copyright (C) 2008, Free Software Foundation, Inc.--
+--Copyright (C) 2008-2011, Free Software Foundation, Inc.   --
 --  --
 -- GNARL is free software; you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -48,8 +48,8 @@
--  The following gives the Ada run-time direct access to a variable
--  context switched by RTEMS at the lowest level.
 
-   RTEMS_Ada_Self : System.Address;
-   pragma Import (C, RTEMS_Ada_Self, "rtems_ada_self");
+   ATCB_Key : System.Address;
+   pragma Import (C, ATCB_Key, "rtems_ada_self");
 

-- Initialize --
@@ -59,8 +59,7 @@
   pragma Warnings (Off, Environment_Task);
 
begin
-  ATCB_Key := No_Key;
-  RTEMS_Ada_Self := To_Address (Environment_Task);
+  ATCB_Key := To_Address (Environment_Task);
end Initialize;
 
---
@@ -69,7 +68,7 @@
 
function Is_Valid_Task return Boolean is
begin
-  return RTEMS_Ada_Self /= System.Null_Address;
+  return ATCB_Key /= System.Null_Address;
end Is_Valid_Task;
 
-
@@ -78,7 +77,7 @@
 
procedure Set (Self_Id : Task_Id) is
begin
-  RTEMS_Ada_Self := To_Address (Self_Id);
+  ATCB_Key := To_Address (Self_Id);
end Set;
 
--
@@ -102,7 +101,7 @@
   Result : System.Address;
 
begin
-  Result := RTEMS_Ada_Self;
+  Result := ATCB_Key;
 
   --  If the key value is Null, then it is a non-Ada task.
 
Index: gcc/ada/s-osinte-rtems.adb
===
--- gcc/ada/s-osinte-rtems.adb  (revision 181881)
+++ gcc/ada/s-osinte-rtems.adb  (working copy)
@@ -122,4 +122,17 @@
   return 0;
end sigaltstack;
 
+   ---
+   -- pthread_rwlockattr_setkind_np --
+   ---
+
+   function pthread_rwlockattr_setkind_np
+ (attr : access pthread_rwlockattr_t;
+  pref : int) return int is
+  pragma Unreferenced (attr);
+  pragma Unreferenced (pref);
+   begin
+  return 0;
+   end pthread_rwlockattr_setkind_np;
+
 end System.OS_Interface;
Index: gcc/ada/s-osinte-rtems.ads
===
--- gcc/ada/s-osinte-rtems.ads  (revision 181881)
+++ gcc/ada/s-osinte-rtems.ads  (working copy)
@@ -6,7 +6,7 @@
 --  --
 --   S p e c--
 --  --
---  Copyright (C) 1997-2009 Free Software Foundation, Inc.  --
+--  Copyright (C) 1997-2011 Free 

Re: RTEMS Specific Ada Patch

[Joel Sherrill]

On 12/02/2011 01:48 AM, Arnaud Charlet wrote:

The attached patch is necessary to let the gcc head
compile Ada for *-*-rtems*.  Other than terminals.c,
the files impacted are RTEMS specific.  OK to commit?

OK

Thanks.  Committed.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

rs6000 options change for rtems.h

[Joel Sherrill]

Hi,

I have been testing with this for almost a month.  It is
my attempt to follow the changes I think Joseph made
to other rs6000 targets. If this change looks right,
I would like to commit it.

Test results have been posted for it.

Thanks.

2011-12-02  Joel Sherrill 

* config/rs6000/rtems.h: Switch to using global_options_set
in SUBSUBTARGET_OVERRIDE_OPTIONS.


--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985


Index: gcc/config/rs6000/rtems.h
===
--- gcc/config/rs6000/rtems.h   (revision 181924)
+++ gcc/config/rs6000/rtems.h   (working copy)
@@ -57,15 +57,15 @@
   { "cpp_os_rtems",CPP_OS_RTEMS_SPEC }
 
 #undef SUBSUBTARGET_OVERRIDE_OPTIONS
-#define SUBSUBTARGET_OVERRIDE_OPTIONS  \
-  do { \
-if (TARGET_E500)   \
-  {
\
-if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs)  \
-  rs6000_float_gprs = 1;   \
-if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe)\
-  rs6000_spe = 1;  \
-if (rs6000_spe && !rs6000_explicit_options.spe_abi)\
-  rs6000_spe_abi = 1;  \
-  }
\
+#define SUBSUBTARGET_OVERRIDE_OPTIONS   \
+  do {  \
+   if (TARGET_E500)  \
+  {  \
+if (!global_options_set.x_rs6000_float_gprs) \
+  rs6000_float_gprs = 1; \
+if (!global_options_set.x_rs6000_spe)\
+  rs6000_spe = 1;\
+if (!global_options_set.x_rs6000_spe_abi)\
+  rs6000_spe_abi = 1;\
+  }  \
   } while(0)

Re: rs6000 options change for rtems.h

[Joel Sherrill]

On 12/02/2011 10:38 AM, Joseph S. Myers wrote:

On Fri, 2 Dec 2011, Joel Sherrill wrote:


2011-12-02  Joel Sherrill

 * config/rs6000/rtems.h: Switch to using global_options_set
 in SUBSUBTARGET_OVERRIDE_OPTIONS.

Is it deliberate that you are removing the first part of each "if"
condition (thus, no longer checking TARGET_HARD_FLOAT before setting
rs6000_float_gprs, no longer checking rs6000_float_gprs before setting
rs6000_spe, etc.)?


I patterned this after what was in other files.
It is done this way everywhere it is referenced.

Should all of them be changed?

$ grep global_options_set.x_rs6000_float_gprs *
e500-double.h:  if (!global_options_set.x_rs6000_float_gprs) \
eabispe.h:  if (!global_options_set.x_rs6000_float_gprs) \
linuxspe.h:  if (!global_options_set.x_rs6000_float_gprs) \
rs6000.c: if (!global_options_set.x_rs6000_float_gprs)
rtems.h:if (!global_options_set.x_rs6000_float_gprs) \

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: rs6000 options change for rtems.h

[Joel Sherrill]

On 12/02/2011 11:57 AM, Joseph S. Myers wrote:

On Fri, 2 Dec 2011, Joel Sherrill wrote:


On 12/02/2011 10:38 AM, Joseph S. Myers wrote:

On Fri, 2 Dec 2011, Joel Sherrill wrote:


2011-12-02  Joel Sherrill

  * config/rs6000/rtems.h: Switch to using global_options_set
  in SUBSUBTARGET_OVERRIDE_OPTIONS.

Is it deliberate that you are removing the first part of each "if"
condition (thus, no longer checking TARGET_HARD_FLOAT before setting
rs6000_float_gprs, no longer checking rs6000_float_gprs before setting
rs6000_spe, etc.)?


I patterned this after what was in other files.
It is done this way everywhere it is referenced.

Should all of them be changed?

Not necessarily.

I described how I think this sort of logic should work in
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854>.  I think that means
something closer to the other headers than to rtems.h - but I don't think
a semantic change should be mixed with a change that's just supposed to
get things to build again.


OK.  I obviously read too much into the other uses.
I did not intend to change semantics just account for
the change making this not compile.

How does the the new version look?

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985


Index: rtems.h
===
--- rtems.h (revision 181924)
+++ rtems.h (working copy)
@@ -57,15 +57,15 @@
   { "cpp_os_rtems",CPP_OS_RTEMS_SPEC }
 
 #undef SUBSUBTARGET_OVERRIDE_OPTIONS
-#define SUBSUBTARGET_OVERRIDE_OPTIONS  \
-  do { \
-if (TARGET_E500)   \
-  {
\
-if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs)  \
-  rs6000_float_gprs = 1;   \
-if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe)\
-  rs6000_spe = 1;  \
-if (rs6000_spe && !rs6000_explicit_options.spe_abi)\
-  rs6000_spe_abi = 1;  \
-  }
\
+#define SUBSUBTARGET_OVERRIDE_OPTIONS \
+  do {\
+   if (TARGET_E500)   \
+  {   \
+if (TARGET_HARD_FLOAT && !global_options_set.x_rs6000_float_gprs) \
+  rs6000_float_gprs = 1;  \
+if (rs6000_float_gprs != 0 && !global_options_set.x_rs6000_spe)   \
+  rs6000_spe = 1; \
+if (rs6000_spe && !global_options_set.x_rs6000_spe_abi)   \
+  rs6000_spe_abi = 1; \
+  }   \
   } while(0)

RTEMS Go Patch

[Joel Sherrill]

Hi,

This addresses all of the Go compilation issues on the
head except one.

Ian.. Is this OK to commit? Or do you have suggestions
on how to make it more general?

Thanks.

2011-12-02  Joel Sherrill 

* runtime/go-signal.c: Add conditional on SIGPROF.
* runtime/mem_posix_memalign.c: Add USED directives.
* libgo/go/syscall/wait.c:  Conditionalize on WIFxxx macros
and SIGxxx being defined.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985


Index: libgo/runtime/go-signal.c
===
--- libgo/runtime/go-signal.c   (revision 181924)
+++ libgo/runtime/go-signal.c   (working copy)
@@ -122,12 +122,14 @@
   const char *msg;
   int i;
 
+#ifdef SIGPROF
   if (sig == SIGPROF)
 {
   /* FIXME.  */
   runtime_sigprof (0, 0, nil, nil);
   return;
 }
+#endif
 
   /* FIXME: Should check siginfo for more information when
  available.  */
@@ -257,6 +259,7 @@
 void
 runtime_resetcpuprofiler(int32 hz)
 {
+#ifdef SIGPROF
   struct itimerval it;
   struct sigaction sa;
   int i;
@@ -289,6 +292,7 @@
   i = setitimer (ITIMER_PROF, &it, NULL);
   __go_assert (i == 0);
 }
+#endif
 
   runtime_m()->profilehz = hz;
 }
Index: libgo/runtime/mem_posix_memalign.c
===
--- libgo/runtime/mem_posix_memalign.c  (revision 181924)
+++ libgo/runtime/mem_posix_memalign.c  (working copy)
@@ -36,10 +36,13 @@
 void*
 runtime_SysReserve(void *v, uintptr n)
 {
+   USED(v);
return runtime_SysAlloc(n);
 }
 
 void
 runtime_SysMap(void *v, uintptr n)
 {
+   USED(v);
+   USED(n);
 }
Index: libgo/go/syscall/wait.c
===
--- libgo/go/syscall/wait.c (revision 181924)
+++ libgo/go/syscall/wait.c (working copy)
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include "runtime.h"
 
 extern _Bool Exited (uint32_t *w)
   __asm__ 
("libgo_syscall.syscall.Exited.N32_libgo_syscall.syscall.WaitStatus");
@@ -37,7 +38,12 @@
 _Bool
 Stopped (uint32_t *w)
 {
+#ifndef WIFSTOPPED
+  USED(w);
+  return 0;
+#else
   return WIFSTOPPED (*w) != 0;
+#endif
 }
 
 extern _Bool Continued (uint32_t *w)
@@ -46,7 +52,12 @@
 _Bool
 Continued (uint32_t *w)
 {
+#ifndef WIFCONTINUED
+  USED(w);
+  return 0;
+#else
   return WIFCONTINUED (*w) != 0;
+#endif
 }
 
 extern _Bool CoreDump (uint32_t *w)
@@ -55,7 +66,12 @@
 _Bool
 CoreDump (uint32_t *w)
 {
+#ifndef WCOREDUMP
+  USED(w);
+  return 0;
+#else
   return WCOREDUMP (*w) != 0;
+#endif
 }
 
 extern int ExitStatus (uint32_t *w)
@@ -95,9 +111,10 @@
   __asm__ 
("libgo_syscall.syscall.TrapCause.N32_libgo_syscall.syscall.WaitStatus");
 
 int
-TrapCause (uint32_t *w __attribute__ ((unused)))
+TrapCause (uint32_t *w)
 {
-#ifndef __linux__
+#if !(defined(WIFSTOPPED) && defined(WSTOPSIG) && defined(SIGTRAP))
+  USED(w);
   return -1;
 #else
   if (!WIFSTOPPED (*w) || WSTOPSIG (*w) != SIGTRAP)

Re: rs6000 options change for rtems.h

[Joel Sherrill]

On 12/02/2011 06:37 PM, Joseph S. Myers wrote:

On Fri, 2 Dec 2011, Joel Sherrill wrote:


OK.  I obviously read too much into the other uses.
I did not intend to change semantics just account for
the change making this not compile.

How does the the new version look?

This version is OK.


Thanks. Committed now.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: [build] Move Solaris 2 startup files to toplevel libgcc, revised

[Joel Sherrill]

I am on travel and only doing email from my phone. Ralf and I had dinner 
together last night and he mentioned not understanding some parts of the patch. 
 I won't be home until next week to actually test this. 

I guess hoping due diligence was used and knowing I may whine next week if it 
breaks RTEMS, do a visual double check please on the RTEMS specific parts and 
commit it.  Either that or wait for a test report from me.

--joel

Rainer Orth  wrote:

>Paolo Bonzini  writes:
>
>> On 05/30/2011 04:29 PM, Rainer Orth wrote:
> * Non-Solaris SPARC changes:
> >>
> >> After I had moved sparc/sol2-c[in].asm to libgcc, I noticed that
> >> despite the name a few non-Solaris targets uses those files, too:
> >>
> >> sparc-*-elf*, sparc-*-rtems*, sparc64-*-elf*, sparc64-*-rtems*
 >
 >  Yes, I tried to untangle that, but the RTEMS folks complained so I had 
 > to
 >  backpedal.  Note that this is also the case on the i386 side.
>>> Drats, I hadn't expected anything like this ;-(
>>>
>>> Here's the updated patch which takes care of this.  I've taken the
>>> liberty to rename gcc/config/i386/t-rtems-i386 to
>>> gcc/config/i386/t-rtems, following all other RTEMS makefile fragments.
>>> I'd be really grateful if the RTEMS maintainers could give it a whirl.
>>>
>>> Besides, I still need build and SPARC maintainer approval for the
>>> non-Solaris parts of the patch from as outlined in the previous
>>> submission:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02181.html
>>>
>>> Bootstrapped without regressions on i386-pc-solaris2.10,
>>> i386-pc-solaris2.11 and sparc-sun-solaris2.11.
>>>
>>> Ok for mainline after the RTEMS parts have been tested/approved?
>>
>> Looks good as far as I'm concerned.  As a followup, please delete
>> t-slibgcc-darwin and use the new t-slibgcc-dummy instead (even better, you
>> could "svn mv" it).
>
>I think I just need RTEMS testing/approval now, everything else should
>be set?
>
>   Rainer
>
>-- 
>-
>Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH, ARM] Switch to EABI version 5 for RTEMS

[Joel Sherrill]

On 04/13/2011 03:38 AM, Sebastian Huber wrote:

On 04/06/2011 07:20 PM, Sebastian Huber wrote:

On 06/04/11 18:24, Ralf Corsepius wrote:

On 04/06/2011 05:20 PM, Sebastian Huber wrote:


there were several requests for ARM Cortex-M support on RTEMS
recently.  The
first step towards this is a suitable ARM tool chain.  I want to use
this event
to clean up the multilibs and switch to the EABI version 5.  The
benefit of
EABI version 5 is that this brings RTEMS more in line with the
primary GCC
platform arm-linux-gnueabi.

These patches are not OK with me, because these are widely
incompatible to what has been used in RTEMS up today

Can you please list these incompatibilities.  The RTEMS test suite shows
no problems with this tool chain.  The GCC test suite looks also good.

[...]

It is not really helpful to claim something without an explanation.  The
missing tool chain for the ARM Cortex architecture blocks RTEMS from further
development on a very important embedded systems platform.  A lot of competing
real time operating systems provide ARM Cortex support for a long time.

Lets look at the GCC test suite results:


Wow!  The improvement is fantastic.

These would impact only new release branches of RTEMS and
we are months away from a new release branch.  If something
breaks, now if the time to find it out.


RTEMS 4.11, GCC 4.6.0 (EABI)

=== gcc Summary ===

# of expected passes72429
# of unexpected failures200
# of unexpected successes   7
# of expected failures  183
# of unresolved testcases   138
# of unsupported tests  1103

=== g++ Summary ===

# of expected passes25494
# of unexpected failures11
# of unexpected successes   1
# of expected failures  160
# of unsupported tests  427

RTEMS 4.11, GCC 4.6.0 (old ABI)

=== gcc Summary ===

# of expected passes43613
# of unexpected failures15916
# of unexpected successes   8
# of expected failures  181
# of unresolved testcases   11127
# of unsupported tests  1124

=== g++ Summary ===

# of expected passes20709
# of unexpected failures2590
# of expected failures  157
# of unresolved testcases   291
# of unsupported tests  430

RTEMS 4.10, GCC 4.4.5 (old ABI)

=== gcc Summary ===

# of expected passes34293
# of unexpected failures11273
# of expected failures  237
# of unresolved testcases   7878
# of unsupported tests  683

=== g++ Summary ===

# of expected passes15707
# of unexpected failures1726
# of expected failures  155
# of unresolved testcases   26
# of unsupported tests  194

RTEMS 4.9, GCC 4.3.2 (old ABI)

=== gcc Summary ===

# of expected passes47164
# of unexpected failures2070
# of expected failures  97
# of unresolved testcases   92
# of untested testcases 35
# of unsupported tests  792

=== g++ Summary ===

# of expected passes17019
# of unexpected failures52
# of unexpected successes   2
# of expected failures  82
# of unresolved testcases   49
# of unsupported tests  164

The EABI tool chain has by far the best test suite results.

The RTEMS test suite was run with the edb7312 BSP and shows good results.  It
works also on real hardware with the lpc24xx and lpc32xx BSPs.

All ARM BSPs compile and link all tests with the EABI tool chain.

We use the VFP floating point format in all ARM BSPs since 2010-04-30.

All ARM BSPs support the init and fini array sections since 2010-12-03.

The C++ exceptions change from SJLJ to a table based implementation is an
implementation detail.

The required ARM/Thumb interwork is an enhancement.

I don't claim that the switch to the EABI tool chain will be without problems,
but we have to use it to figure this out.  The multilib selection may need
further changes.  I am concerned about the enabled exceptions in some libgcc
functions.




--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985