[patch] PR 51417

2012-03-05 Thread Ralf Corsépius

Hi,

The patch below addresses an issue with gcc-4.7.0 the issue I had 
reported in

http://gcc.gnu.org/ml/gcc/2012-03/msg00035.html

and somebody else had bz'ed as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417

Tested by cross-building gcc-4_7-branch for several *rtems targets on 
Fedora 16. Further test-builds are in progress.


No native build-testing, yet.

OK to apply?

Ralf

2012-03-05  Ralf Corsépius  ralf.corsep...@rtems.org

	PR target/51417
	* Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext),
	gcc-nm$(exeext), gcc-ranlib$(exeext).
	Don't double canonicalize if cross-compiling.


diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f6cf8ff..2319cab 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -4811,20 +4811,18 @@ install-collect2: collect2 installdirs
 install-lto-wrapper: lto-wrapper$(exeext)
 	$(INSTALL_PROGRAM) lto-wrapper$(exeext) $(DESTDIR)$(libexecsubdir)/lto-wrapper$(exeext)
 
-install-gcc-ar:
-	set -e ; \
-	for i in ar nm ranlib ; do \
-	  install_name=`echo gcc-$$i|sed '$(program_transform_name)'`$(exeext) ;\
-	  target_install_name=$(target_noncanonical)-`echo gcc-$$i|sed '$(program_transform_name)'`$(exeext) ; \
-	  binname=gcc-$$i$(exeext) ; \
-	  rm -f $(DESTDIR)$(bindir)/$$install_name ; \
-	  rm -f $(DESTDIR)$(bindir)/$$target_install_name ; \
-	  $(INSTALL_PROGRAM) $$binname $(DESTDIR)$(bindir)/$$install_name ;\
-	  if test -f $(DESTDIR)$(bindir)$$target_install_name ; then \
+install-gcc-ar: installdirs gcc-ar$(exeext) gcc-nm$(exeext) gcc-ranlib$(exeext)
+	for i in gcc-ar gcc-nm gcc-ranlib; do \
+	  install_name=`echo $$i|sed '$(program_transform_name)'` ;\
+	  target_install_name=$(target_noncanonical)-`echo $$i|sed '$(program_transform_name)'` ; \
+	  rm -f $(DESTDIR)$(bindir)/$$install_name$(exeext) ; \
+	  $(INSTALL_PROGRAM) $$i$(exeext) $(DESTDIR)$(bindir)/$$install_name$(exeext) ;\
+	  if test -f gcc-cross$(exeext); then \
 	:; \
 	  else \
+	rm -f $(DESTDIR)$(bindir)/$$target_install_name$(exeext); \
 	( cd $(DESTDIR)$(bindir)  \
-	  $(LN) $$install_name $$target_install_name ) ; \
+	  $(LN) $$install_name$(exeext) $$target_install_name$(exeext) ) ; \
 	  fi ; \
 	done
 


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

2013-09-18 Thread Ralf Corsépius

On 09/17/2013 08:12 PM, Joel Sherrill wrote:

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.


Not quite. The problem is not GCC-4.8 vs. GCC-4.9, the problems are in 
RTEMS.


Why? sparc-rtems*gccs  4.8 doesn't support -mcpu=leon3 and thus will 
abort when -mcpu=leon3 will be used.


I.e. you
a) CANNOT use -mcpu=leon3 in RTEMS's bsp_specs and in RTEMS cpukit, 
until the toolchains are guaranteed to support it.

or
b) MUST backport -mcpu=leon3 to GCC-4.8

In other words, if you are sure leon3 works with GCC-4.8, you'd better 
off backporting this to GCC-4.8. If there are known bugs in 
GCC-4.8/leon3, you'd better of not using -mcpu=leon3 in RTEMS.


To my knowledge, GCC up to 4.8.1 doesn't support -mcpu=leon3 at all, but 
I don't know about the status on current gcc-4_8-branch.


Ralf