Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Paolo Bonzini

On 08/11/2011 08:24 PM, H.J. Lu wrote:

On Thu, Aug 11, 2011 at 11:19 AM, H.J. Luhjl.to...@gmail.com  wrote:

On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de  wrote:

Paolo Bonzinibonz...@gnu.org  writes:


On 08/10/2011 06:05 PM, Rainer Orth wrote:

  True: it is called once per multilib.


  Just to doublecheck, are we sure that unwind.h is always the same?

Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.


Patch doing rm -f is preapproved then.


Here's what I installed, after making libgcc/unwind-generic.h read-only,
reconfiguring and rebuilding first without and with the patch and
observe the bug gone on i386-pc-solaris2.10.

Rainer


2011-08-11  Rainer Orthr...@cebitec.uni-bielefeld.de

* Makefile.in (install-unwind_h): Remove destination file first.

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
+   rm -f $(gcc_objdir)/include/unwind.h
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r $(gcc_objdir)/include/unwind.h



It breaks bootstrap with make -j12 on a 24 core Linux/x86-64  :

http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

rm -f ../../.././gcc/include/unwind.h
cp unwind.h ../../.././gcc/include/unwind.h
rm -f ../.././gcc/include/unwind.h
chmod a+r ../../.././gcc/include/unwind.h
cp unwind.h ../.././gcc/include/unwind.h
chmod: cannot access `../../.././gcc/include/unwind.h': No such file
or directory
make[8]: *** [install-unwind_h] Error 1
make[8]: *** Waiting for unfinished jobs
chmod a+r ../.././gcc/include/unwind.h

We may have a race condition here.


I opened:

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


Does the attached patch work?

Paolo
# Makefile.in

# Copyright (C) 2005, 2006, 2009, 2010, 2011 Free Software Foundation
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify it under the
# terms of the GNU Library General Public License as published by the Free
# Software Foundation; either version 3 of the License, 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/.
#

libgcc_topdir = @libgcc_topdir@
host_subdir = @host_subdir@

gcc_srcdir = $(libgcc_topdir)/gcc
gcc_objdir = $(MULTIBUILDTOP)../../$(host_subdir)/gcc

srcdir = @srcdir@

prefix = @prefix@

exec_prefix = @exec_prefix@
libdir = @libdir@
shlib_slibdir = @slibdir@

SHELL = @SHELL@

cpu_type = @cpu_type@
enable_shared = @enable_shared@
double_type_size = @double_type_size@
long_double_type_size = @long_double_type_size@
decimal_float = @decimal_float@
enable_decimal_float = @enable_decimal_float@
fixed_point = @fixed_point@

host_noncanonical = @host_noncanonical@
target_noncanonical = @target_noncanonical@

# List of extra object files that should be compiled for this target machine.
# The rules for compiling them should be in the t-* file for the machine.
EXTRA_PARTS = @extra_parts@

# Multilib support variables.
MULTISRCTOP =
MULTIBUILDTOP =
MULTIDIRS =
MULTISUBDIR =
MULTIDO = true
MULTICLEAN = true

INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
mkinstalldirs = $(SHELL) $(libgcc_topdir)/mkinstalldirs

objext = .o

AR = @AR@
AR_FLAGS = rc

CC = @CC@
CFLAGS = @CFLAGS@
RANLIB = @RANLIB@
LN_S = @LN_S@

PWD_COMMAND = $${PWDCMD-pwd}

# Flags to pass to a recursive make.
FLAGS_TO_PASS = \
AR=$(AR) \
AR_FLAGS=$(AR_FLAGS) \
CC=$(CC) \
CFLAGS=$(CFLAGS) \
DESTDIR=$(DESTDIR) \
EXTRA_OFILES=$(EXTRA_OFILES) \
HDEFINES=$(HDEFINES) \
INSTALL=$(INSTALL) \
INSTALL_DATA=$(INSTALL_DATA) \
INSTALL_PROGRAM=$(INSTALL_PROGRAM) \
LDFLAGS=$(LDFLAGS) \
LOADLIBES=$(LOADLIBES) \
RANLIB=$(RANLIB) \
SHELL=$(SHELL) \
prefix=$(prefix) \
exec_prefix=$(exec_prefix) \
libdir=$(libdir) \
libsubdir=$(libsubdir) \
tooldir=$(tooldir)

# Dependencies for all are set later in the file.
all: all-multi
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
$(MAKE) install-leaf DESTDIR=$(gcc_objdir) \
  slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)

.PHONY: all-multi
all-multi:
# If this is the top-level multilib, build all the other
# multilibs.
@: $(MAKE) ; 

Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread H.J. Lu
On Fri, Aug 12, 2011 at 12:04 AM, Paolo Bonzini bonz...@gnu.org wrote:
 On 08/11/2011 08:24 PM, H.J. Lu wrote:

 On Thu, Aug 11, 2011 at 11:19 AM, H.J. Luhjl.to...@gmail.com  wrote:

 On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
 r...@cebitec.uni-bielefeld.de  wrote:

 Paolo Bonzinibonz...@gnu.org  writes:

 On 08/10/2011 06:05 PM, Rainer Orth wrote:

  True: it is called once per multilib.

  Just to doublecheck, are we sure that unwind.h is always the same?

 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

 Patch doing rm -f is preapproved then.

 Here's what I installed, after making libgcc/unwind-generic.h read-only,
 reconfiguring and rebuilding first without and with the patch and
 observe the bug gone on i386-pc-solaris2.10.

        Rainer


 2011-08-11  Rainer Orthr...@cebitec.uni-bielefeld.de

        * Makefile.in (install-unwind_h): Remove destination file first.

 diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
 --- a/libgcc/Makefile.in
 +++ b/libgcc/Makefile.in
 @@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 +       rm -f $(gcc_objdir)/include/unwind.h
        cp unwind.h $(gcc_objdir)/include/unwind.h
        chmod a+r $(gcc_objdir)/include/unwind.h


 It breaks bootstrap with make -j12 on a 24 core Linux/x86-64  :

 http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

 rm -f ../../.././gcc/include/unwind.h
 cp unwind.h ../../.././gcc/include/unwind.h
 rm -f ../.././gcc/include/unwind.h
 chmod a+r ../../.././gcc/include/unwind.h
 cp unwind.h ../.././gcc/include/unwind.h
 chmod: cannot access `../../.././gcc/include/unwind.h': No such file
 or directory
 make[8]: *** [install-unwind_h] Error 1
 make[8]: *** Waiting for unfinished jobs
 chmod a+r ../.././gcc/include/unwind.h

 We may have a race condition here.

 I opened:

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

 Does the attached patch work?


Can you provide a patch instead of the whole Makefile.in?


-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Paolo Bonzini

On 08/12/2011 02:13 PM, H.J. Lu wrote:

We may have a race condition here.


I opened:

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


Does the attached patch work?


Can you provide a patch instead of the whole Makefile.in?


Sorry, that was not intended.

Paolo

2011-08-12  Paolo Bonzini  bonz...@gnu.org

	* Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h
	atomically.

Index: Makefile.in
===
--- Makefile.in	(revision 177688)
+++ Makefile.in	(working copy)
@@ -991,8 +1001,10 @@ gcc-extra-parts:
 all: $(extra-parts)
 
 install-unwind_h:
-	rm -f $(gcc_objdir)/include/unwind.h
-	cp unwind.h $(gcc_objdir)/include/unwind.h
+	cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
+	sh $(srcdir)/../move-if-change \
+		$(gcc_objdir)/include/tmp-unwind.h \
+		$(gcc_objdir)/include/unwind.h
 	chmod a+r $(gcc_objdir)/include/unwind.h
 
 all: install-unwind_h


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Pedro Alves
On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
   2011-08-12  Paolo Bonzini  bonz...@gnu.org
 
 * Makefile.in (install-unwind_h): Create 
 $(gcc_objdir)/include/unwind.h
 atomically.
 
 Index: Makefile.in
 ===
 --- Makefile.in (revision 177688)
 +++ Makefile.in (working copy)
 @@ -991,8 +1001,10 @@ gcc-extra-parts:
  all: $(extra-parts)
  
  install-unwind_h:
 -   rm -f $(gcc_objdir)/include/unwind.h
 -   cp unwind.h $(gcc_objdir)/include/unwind.h
 +   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 +   sh $(srcdir)/../move-if-change \
 +   $(gcc_objdir)/include/tmp-unwind.h \
 +   $(gcc_objdir)/include/unwind.h
 chmod a+r $(gcc_objdir)/include/unwind.h
  

Can't this sequence happen?

proc1:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h
proc2:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h

It sounds like the latter move-if-change could trip on
a non-extant tmp-unwind.h.

-- 
Pedro Alves


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread H.J. Lu
On Fri, Aug 12, 2011 at 5:38 AM, Pedro Alves pe...@codesourcery.com wrote:
 On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
   2011-08-12  Paolo Bonzini  bonz...@gnu.org

         * Makefile.in (install-unwind_h): Create 
 $(gcc_objdir)/include/unwind.h
         atomically.

 Index: Makefile.in
 ===
 --- Makefile.in (revision 177688)
 +++ Makefile.in (working copy)
 @@ -991,8 +1001,10 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 -       rm -f $(gcc_objdir)/include/unwind.h
 -       cp unwind.h $(gcc_objdir)/include/unwind.h
 +       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 +       sh $(srcdir)/../move-if-change \
 +               $(gcc_objdir)/include/tmp-unwind.h \
 +               $(gcc_objdir)/include/unwind.h
         chmod a+r $(gcc_objdir)/include/unwind.h


 Can't this sequence happen?

 proc1:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 proc2:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 proc1:       sh $(srcdir)/../move-if-change \
               $(gcc_objdir)/include/tmp-unwind.h \
               $(gcc_objdir)/include/unwind.h
 proc2:       sh $(srcdir)/../move-if-change \
               $(gcc_objdir)/include/tmp-unwind.h \
               $(gcc_objdir)/include/unwind.h

 It sounds like the latter move-if-change could trip on
 a non-extant tmp-unwind.h.


Yes, we should use an unique tmp unwind.h.


-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Paolo Bonzini

Can't this sequence happen?

proc1:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h
proc2:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h

It sounds like the latter move-if-change could trip on
a non-extant tmp-unwind.h.


Yes, we should use an unique tmp unwind.h.


Thanks, you are correct.

Paolo
2011-08-12  Paolo Bonzini  bonz...@gnu.org

	* Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h
	atomically.

Index: Makefile.in
===
--- Makefile.in	(revision 177688)
+++ Makefile.in	(working copy)
@@ -991,8 +1001,9 @@ gcc-extra-parts:
 all: $(extra-parts)
 
 install-unwind_h:
-	rm -f $(gcc_objdir)/include/unwind.h
-	cp unwind.h $(gcc_objdir)/include/unwind.h
-	chmod a+r $(gcc_objdir)/include/unwind.h
+	dest=$(gcc_objdir)/include/tmp-unwind.h; \
+	cp unwind.h $$dest; \
+	chmod a+r $$dest; \
+	sh $(srcdir)/../move-if-change $$dest $(gcc_objdir)/include/unwind.h
 
 all: install-unwind_h


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread H.J. Lu
On Fri, Aug 12, 2011 at 8:40 AM, Paolo Bonzini bonz...@gnu.org wrote:
 Can't this sequence happen?

 proc1:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 proc2:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
 proc1:       sh $(srcdir)/../move-if-change \
               $(gcc_objdir)/include/tmp-unwind.h \
               $(gcc_objdir)/include/unwind.h
 proc2:       sh $(srcdir)/../move-if-change \
               $(gcc_objdir)/include/tmp-unwind.h \
               $(gcc_objdir)/include/unwind.h

 It sounds like the latter move-if-change could trip on
 a non-extant tmp-unwind.h.

 Yes, we should use an unique tmp unwind.h.

 Thanks, you are correct.


It should work.

Thanks.

-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Paolo Bonzini

On 08/12/2011 05:50 PM, H.J. Lu wrote:

  Thanks, you are correct.

It should work.

Thanks.


I prefer to wait for testing results to commit it, the breakage is minor.

Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Pedro Alves
On Friday 12 August 2011 16:40:33, Paolo Bonzini wrote:
  install-unwind_h:
 -   rm -f $(gcc_objdir)/include/unwind.h
 -   cp unwind.h $(gcc_objdir)/include/unwind.h
 -   chmod a+r $(gcc_objdir)/include/unwind.h
 +   dest=$(gcc_objdir)/include/tmp-unwind.h; \
 +   cp unwind.h $$dest; \
 +   chmod a+r $$dest; \
 +   sh $(srcdir)/../move-if-change $$dest $(gcc_objdir)/include/unwind.h

Thanks, that looks good to me.

-- 
Pedro Alves


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread H.J. Lu
On Fri, Aug 12, 2011 at 8:57 AM, Paolo Bonzini bonz...@gnu.org wrote:
 On 08/12/2011 05:50 PM, H.J. Lu wrote:

   Thanks, you are correct.

 It should work.

 Thanks.

 I prefer to wait for testing results to commit it, the breakage is minor.

It bootstraps successfully with make -j12 on a 24 core machine.

Thanks.


-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-12 Thread Paolo Bonzini

On 08/12/2011 06:25 PM, H.J. Lu wrote:


  I prefer to wait for testing results to commit it, the breakage is minor.

It bootstraps successfully with make -j12 on a 24 core machine.

Thanks.


Committed.

Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Paolo Bonzini

On 08/10/2011 06:50 PM, Pedro Alves wrote:

On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:

  Paolo Bonzinibonz...@gnu.org  writes:


True: it is called once per multilib.

  
Just to doublecheck, are we sure that unwind.h is always the same?


  Yep: it's unwind-generic.h for almost all targets, just a few arm
  targets use config/arm/unwind-arm.h for all multilibs.

Doesn't each multilib get its own build subdir?
Can't the file be copied there instead and thus get rid of this wart?


It would need an additional per-multilib directory in the include path. 
 It's simpler for now to leave it as is, and it will go away as soon as 
nothing in the gcc directory will need unwind.h.  Rainer has already 
removed countless dependencies between gcc and libgcc, adding one is not 
too bad.


Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 On 08/10/2011 06:50 PM, Pedro Alves wrote:
 On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
   Paolo Bonzinibonz...@gnu.org  writes:
 
 True: it is called once per multilib.
   
 Just to doublecheck, are we sure that unwind.h is always the same?
 
   Yep: it's unwind-generic.h for almost all targets, just a few arm
   targets use config/arm/unwind-arm.h for all multilibs.
 Doesn't each multilib get its own build subdir?
 Can't the file be copied there instead and thus get rid of this wart?

 It would need an additional per-multilib directory in the include
 path. It's simpler for now to leave it as is, and it will go away as soon
 as nothing in the gcc directory will need unwind.h.  Rainer has already
 removed countless dependencies between gcc and libgcc, adding one is not
 too bad.

The actual problem are not the runtime libraries, which already know to
search $builddir/.../libgcc for unwind.h and related files.  The
copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
gnat.dg, and gcc.dg) where I was too lazy to deal with changing (or even
setting ) the include paths, but took the easy way out since gcc/include
is in the include path by default.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Joseph S. Myers
On Thu, 11 Aug 2011, Rainer Orth wrote:

 The actual problem are not the runtime libraries, which already know to
 search $builddir/.../libgcc for unwind.h and related files.  The
 copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
 gnat.dg, and gcc.dg) where I was too lazy to deal with changing (or even
 setting ) the include paths, but took the easy way out since gcc/include
 is in the include path by default.

unwind.h is an installed header.  Are you sure nothing outside of GCC uses 
it?

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Paolo Bonzini

On 08/11/2011 04:25 PM, Joseph S. Myers wrote:

  The actual problem are not the runtime libraries, which already know to
  search $builddir/.../libgcc for unwind.h and related files.  The
  copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
  gnat.dg, and gcc.dg) where I was too lazy to deal with changing (or even
  setting ) the include paths, but took the easy way out since gcc/include
  is in the include path by default.

unwind.h is an installed header.  Are you sure nothing outside of GCC uses
it?


Why does it matter?  It is still installed in trunk, and you could also 
move the installation to libgcc's Makefiles if it weren't copied anymore 
to $builddir/gcc/include.


Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Rainer Orth
Joseph S. Myers jos...@codesourcery.com writes:

 On Thu, 11 Aug 2011, Rainer Orth wrote:

 The actual problem are not the runtime libraries, which already know to
 search $builddir/.../libgcc for unwind.h and related files.  The
 copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
 gnat.dg, and gcc.dg) where I was too lazy to deal with changing (or even
 setting ) the include paths, but took the easy way out since gcc/include
 is in the include path by default.

 unwind.h is an installed header.  Are you sure nothing outside of GCC uses 
 it?

No, I'm not.  On the contrary, the patch that started to install it

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01653.html

strongly suggests that it should stay this way.  If the backcopy is
removed some day, once testsuite users have been adapted, it has to be
added to the libgcc install target.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Joseph S. Myers
On Thu, 11 Aug 2011, Paolo Bonzini wrote:

 On 08/11/2011 04:25 PM, Joseph S. Myers wrote:
The actual problem are not the runtime libraries, which already know to
search $builddir/.../libgcc for unwind.h and related files.  The
copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
gnat.dg, and gcc.dg) where I was too lazy to deal with changing (or even
setting ) the include paths, but took the easy way out since gcc/include
is in the include path by default.
  
  unwind.h is an installed header.  Are you sure nothing outside of GCC uses
  it?
 
 Why does it matter?  It is still installed in trunk, and you could also move
 the installation to libgcc's Makefiles if it weren't copied anymore to
 $builddir/gcc/include.

Actually I think the installation of all the installed target headers 
should move to libgcc's Makefiles (and the headers themselves should move 
under the libgcc/ directory).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 On 08/10/2011 06:05 PM, Rainer Orth wrote:
   True: it is called once per multilib.
 
   Just to doublecheck, are we sure that unwind.h is always the same?
 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

 Patch doing rm -f is preapproved then.

Here's what I installed, after making libgcc/unwind-generic.h read-only,
reconfiguring and rebuilding first without and with the patch and
observe the bug gone on i386-pc-solaris2.10.

Rainer


2011-08-11  Rainer Orth  r...@cebitec.uni-bielefeld.de

* Makefile.in (install-unwind_h): Remove destination file first.

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -994,6 +994,7 @@ gcc-extra-parts:
 all: $(extra-parts)
 
 install-unwind_h:
+   rm -f $(gcc_objdir)/include/unwind.h
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r $(gcc_objdir)/include/unwind.h
 
-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Rainer Orth
Joseph S. Myers jos...@codesourcery.com writes:

 Actually I think the installation of all the installed target headers 
 should move to libgcc's Makefiles (and the headers themselves should move 
 under the libgcc/ directory).

Agreed, added to my ever-growing todo list for the libgcc move.  This
would be

* gcc/ginclude, from gcc/Makefile.in (USER_H),

* extra_headers from gcc/config.gcc, and

* EXTRA_HEADERS from the gcc/config t-* files.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Paolo Bonzini

On 08/11/2011 05:26 PM, Rainer Orth wrote:



  Actually I think the installation of all the installed target headers
  should move to libgcc's Makefiles (and the headers themselves should move
  under the libgcc/ directory).

Agreed, added to my ever-growing todo list for the libgcc move.  This
would be

* gcc/ginclude, from gcc/Makefile.in (USER_H),

* extra_headers from gcc/config.gcc, and

* EXTRA_HEADERS from the gcc/config t-* files.


Writing that down in a wiki page (even as unformatted text)  would be 
useful.


Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 Writing that down in a wiki page (even as unformatted text)  would be
 useful.

While I'm not too fond of WiKis, I've added some text to

http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration

It's ugly right now, but better than nothing.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread H.J. Lu
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 08/10/2011 06:05 PM, Rainer Orth wrote:
   True: it is called once per multilib.
 
   Just to doublecheck, are we sure that unwind.h is always the same?
 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

 Patch doing rm -f is preapproved then.

 Here's what I installed, after making libgcc/unwind-generic.h read-only,
 reconfiguring and rebuilding first without and with the patch and
 observe the bug gone on i386-pc-solaris2.10.

        Rainer


 2011-08-11  Rainer Orth  r...@cebitec.uni-bielefeld.de

        * Makefile.in (install-unwind_h): Remove destination file first.

 diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
 --- a/libgcc/Makefile.in
 +++ b/libgcc/Makefile.in
 @@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 +       rm -f $(gcc_objdir)/include/unwind.h
        cp unwind.h $(gcc_objdir)/include/unwind.h
        chmod a+r $(gcc_objdir)/include/unwind.h


It breaks bootstrap with make -j12 on a 24 core Linux/x86-64  :

http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

rm -f ../../.././gcc/include/unwind.h
cp unwind.h ../../.././gcc/include/unwind.h
rm -f ../.././gcc/include/unwind.h
chmod a+r ../../.././gcc/include/unwind.h
cp unwind.h ../.././gcc/include/unwind.h
chmod: cannot access `../../.././gcc/include/unwind.h': No such file
or directory
make[8]: *** [install-unwind_h] Error 1
make[8]: *** Waiting for unfinished jobs
chmod a+r ../.././gcc/include/unwind.h

We may have a race condition here.

-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread H.J. Lu
On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
 r...@cebitec.uni-bielefeld.de wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 08/10/2011 06:05 PM, Rainer Orth wrote:
   True: it is called once per multilib.
 
   Just to doublecheck, are we sure that unwind.h is always the same?
 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

 Patch doing rm -f is preapproved then.

 Here's what I installed, after making libgcc/unwind-generic.h read-only,
 reconfiguring and rebuilding first without and with the patch and
 observe the bug gone on i386-pc-solaris2.10.

        Rainer


 2011-08-11  Rainer Orth  r...@cebitec.uni-bielefeld.de

        * Makefile.in (install-unwind_h): Remove destination file first.

 diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
 --- a/libgcc/Makefile.in
 +++ b/libgcc/Makefile.in
 @@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 +       rm -f $(gcc_objdir)/include/unwind.h
        cp unwind.h $(gcc_objdir)/include/unwind.h
        chmod a+r $(gcc_objdir)/include/unwind.h


 It breaks bootstrap with make -j12 on a 24 core Linux/x86-64  :

 http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

 rm -f ../../.././gcc/include/unwind.h
 cp unwind.h ../../.././gcc/include/unwind.h
 rm -f ../.././gcc/include/unwind.h
 chmod a+r ../../.././gcc/include/unwind.h
 cp unwind.h ../.././gcc/include/unwind.h
 chmod: cannot access `../../.././gcc/include/unwind.h': No such file
 or directory
 make[8]: *** [install-unwind_h] Error 1
 make[8]: *** Waiting for unfinished jobs
 chmod a+r ../.././gcc/include/unwind.h

 We may have a race condition here.

I opened:

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


-- 
H.J.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-11 Thread Paolo Bonzini
On Thu, Aug 11, 2011 at 20:19, H.J. Lu hjl.to...@gmail.com wrote:
 On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
 r...@cebitec.uni-bielefeld.de wrote:
 Paolo Bonzini bonz...@gnu.org writes:

 On 08/10/2011 06:05 PM, Rainer Orth wrote:
   True: it is called once per multilib.
 
   Just to doublecheck, are we sure that unwind.h is always the same?
 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

 Patch doing rm -f is preapproved then.

 Here's what I installed, after making libgcc/unwind-generic.h read-only,
 reconfiguring and rebuilding first without and with the patch and
 observe the bug gone on i386-pc-solaris2.10.

        Rainer


 2011-08-11  Rainer Orth  r...@cebitec.uni-bielefeld.de

        * Makefile.in (install-unwind_h): Remove destination file first.

 diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
 --- a/libgcc/Makefile.in
 +++ b/libgcc/Makefile.in
 @@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 +       rm -f $(gcc_objdir)/include/unwind.h
        cp unwind.h $(gcc_objdir)/include/unwind.h
        chmod a+r $(gcc_objdir)/include/unwind.h


 It breaks bootstrap with make -j12 on a 24 core Linux/x86-64  :

 http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

 rm -f ../../.././gcc/include/unwind.h
 cp unwind.h ../../.././gcc/include/unwind.h
 rm -f ../.././gcc/include/unwind.h
 chmod a+r ../../.././gcc/include/unwind.h
 cp unwind.h ../.././gcc/include/unwind.h
 chmod: cannot access `../../.././gcc/include/unwind.h': No such file
 or directory
 make[8]: *** [install-unwind_h] Error 1
 make[8]: *** Waiting for unfinished jobs
 chmod a+r ../.././gcc/include/unwind.h

 We may have a race condition here.

Will take a look tomorrow.

Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Joseph S. Myers
This appears to have brought back PR 26478, build failure with readonly 
source directory:

cp unwind.h ../../.././gcc/include/unwind.h
cp: cannot create regular file `../../.././gcc/include/unwind.h': Permission 
denied
make[4]: *** [install-unwind_h] Error 1

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Rainer Orth
Joseph S. Myers jos...@codesourcery.com writes:

 This appears to have brought back PR 26478, build failure with readonly 
 source directory:

 cp unwind.h ../../.././gcc/include/unwind.h
 cp: cannot create regular file `../../.././gcc/include/unwind.h': Permission 
 denied
 make[4]: *** [install-unwind_h] Error 1

This is strange: they copy explicitly goes into $(gcc_objdir): from
libgcc/Makefile.in:

install-unwind_h:
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r $(gcc_objdir)/include/unwind.h

For an in-tree build, the source directory cannot be read-only, for a
VPATH build I don't see how this can happen.  Could you please check?

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Joseph S. Myers
On Wed, 10 Aug 2011, Rainer Orth wrote:

 Joseph S. Myers jos...@codesourcery.com writes:
 
  This appears to have brought back PR 26478, build failure with readonly 
  source directory:
 
  cp unwind.h ../../.././gcc/include/unwind.h
  cp: cannot create regular file `../../.././gcc/include/unwind.h': 
  Permission denied
  make[4]: *** [install-unwind_h] Error 1
 
 This is strange: they copy explicitly goes into $(gcc_objdir): from
 libgcc/Makefile.in:
 
 install-unwind_h:
 cp unwind.h $(gcc_objdir)/include/unwind.h
 chmod a+r $(gcc_objdir)/include/unwind.h
 
 For an in-tree build, the source directory cannot be read-only, for a
 VPATH build I don't see how this can happen.  Could you please check?

This is a VPATH build and the issue is that the *file* unwind.h is 
readonly having been copied from a readonly source (and install-unwind_h 
must, I suppose, end up getting called more than once so that the second 
copy tries to copy over a readonly file; the 26478 fix was to remove the 
target of the copy with rm -f before copying).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Rainer Orth
Joseph S. Myers jos...@codesourcery.com writes:

 This is strange: they copy explicitly goes into $(gcc_objdir): from
 libgcc/Makefile.in:
 
 install-unwind_h:
 cp unwind.h $(gcc_objdir)/include/unwind.h
 chmod a+r $(gcc_objdir)/include/unwind.h
 
 For an in-tree build, the source directory cannot be read-only, for a
 VPATH build I don't see how this can happen.  Could you please check?

 This is a VPATH build and the issue is that the *file* unwind.h is 
 readonly having been copied from a readonly source (and install-unwind_h 

I see.  I'd been thinking of a source tree mounted read-only, not the
actual files changed to be read-only.

 must, I suppose, end up getting called more than once so that the second 
 copy tries to copy over a readonly file; the 26478 fix was to remove the 

True: it is called once per multilib.

 target of the copy with rm -f before copying).

Makes sense.  Toplevel dependencies should take care that the file isn't
used by another target library in the small time window between removal
and copy.

Could you try the obvious patch?  It's probably quicker than me
recreating the setup.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Joseph S. Myers
On Wed, 10 Aug 2011, Rainer Orth wrote:

 Could you try the obvious patch?  It's probably quicker than me
 recreating the setup.

Actually I think it will be quicker for you to do this test.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Paolo Bonzini

On 08/10/2011 03:56 PM, Rainer Orth wrote:

Joseph S. Myersjos...@codesourcery.com  writes:


This is strange: they copy explicitly goes into $(gcc_objdir): from
libgcc/Makefile.in:

install-unwind_h:
 cp unwind.h $(gcc_objdir)/include/unwind.h
 chmod a+r $(gcc_objdir)/include/unwind.h

For an in-tree build, the source directory cannot be read-only, for a
VPATH build I don't see how this can happen.  Could you please check?


This is a VPATH build and the issue is that the *file* unwind.h is
readonly having been copied from a readonly source (and install-unwind_h


I see.  I'd been thinking of a source tree mounted read-only, not the
actual files changed to be read-only.


must, I suppose, end up getting called more than once so that the second
copy tries to copy over a readonly file; the 26478 fix was to remove the


True: it is called once per multilib.


Just to doublecheck, are we sure that unwind.h is always the same?

Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 True: it is called once per multilib.

 Just to doublecheck, are we sure that unwind.h is always the same?

Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Paolo Bonzini

On 08/10/2011 06:05 PM, Rainer Orth wrote:

  True: it is called once per multilib.


  Just to doublecheck, are we sure that unwind.h is always the same?

Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.


Patch doing rm -f is preapproved then.

Paolo



Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-10 Thread Pedro Alves
On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
 Paolo Bonzini bonz...@gnu.org writes:
 
  True: it is called once per multilib.
 
  Just to doublecheck, are we sure that unwind.h is always the same?
 
 Yep: it's unwind-generic.h for almost all targets, just a few arm
 targets use config/arm/unwind-arm.h for all multilibs.

Doesn't each multilib get its own build subdir?
Can't the file be copied there instead and thus get rid of this wart?

-- 
Pedro Alves


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 On 08/06/2011 05:07 PM, Mikael Morin wrote:
 On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
 Can you try this instead?
 It works. Thanks

 Committed, thanks.

Thanks for fixing this.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Rainer Orth
Andreas Schwab sch...@linux-m68k.org writes:

 It's already fixed, 'twas the missing ldflags.

I see, so I wasn't the only victim :-)

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Rainer Orth
Richard Sandiford rdsandif...@googlemail.com writes:

 Rainer Orth r...@cebitec.uni-bielefeld.de writes:
  * config.host (unwind_header): New variable.
  (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
  (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
  *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
  (*-*-solaris2*): Add t-eh-dw2-dip to tmake_file.

 The combination of this and the soft-fp patch meant that t-mips
 wasn't included by mips*-linux-gnu.  The fix below seemed obvious,
 especially given the solaris case, so I applied it after testing
 on mips64-linux-gnu.

Indeed.  I think the default should be to append to variables, with
every exception requiring a comment explaining what's going on.  I'm
trying to do so in the rest of the patch series.  config.host (and
config.gcc) will probably require a final pass checking for such cases.

Thanks for fixing this.

Rainer

 libgcc/
   * config.host (*-*-darwin*, *-*-freebsd*, *-*-linux*, frv-*-*linux*)
   (*-*-kfreebsd*-gnu, *-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu):
   Add to tmake_file rather than overriding it.

 Index: libgcc/config.host
 ===
 --- libgcc/config.host2011-08-06 15:36:16.0 +0100
 +++ libgcc/config.host2011-08-06 15:36:52.0 +0100
 @@ -163,7 +163,7 @@ esac
  case ${host} in
  *-*-darwin*)
asm_hidden_op=.private_extern
 -  tmake_file=t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin
 +  tmake_file=$tmake_file t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin
extra_parts=crt3.o
;;
  *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
 @@ -179,10 +179,10 @@ case ${host} in
# This is the generic ELF configuration of FreeBSD.  Later
# machine-specific sections may refine and add to this
# configuration.
 -  tmake_file=t-eh-dw2-dip
 +  tmake_file=$tmake_file t-eh-dw2-dip
;;
  *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* 
 | *-*-kopensolaris*-gnu)
 -  tmake_file=t-eh-dw2-dip
 +  tmake_file=$tmake_file t-eh-dw2-dip
extra_parts=crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o
;;
  *-*-netbsd*)

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Andreas Schwab
Rainer Orth r...@cebitec.uni-bielefeld.de writes:

 Andreas Schwab sch...@linux-m68k.org writes:

 It's already fixed, 'twas the missing ldflags.

 I see, so I wasn't the only victim :-)

Unfortunately it didn't really fix it, the undefined symbol is still
present in libgcc_s.so.  I'll experiment with the config file juggling.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Andreas Schwab
The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
I've verified that the resulting libgcc_s.so aggrees with the one
produced by the 4.6 branch.  Checked in as obvious.

Andreas.

2011-08-09  Andreas Schwab  sch...@linux-m68k.org

* config.host (ia64*-*-linux*): Move ia64/t-glibc after
t-libunwind.

diff --git a/libgcc/config.host b/libgcc/config.host
index d35ee3a..9972bf0 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -472,7 +472,7 @@ ia64*-*-freebsd*)
;;
 ia64*-*-linux*)
extra_parts=crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o
-   tmake_file=ia64/t-ia64 t-crtfm t-softfp-tf ia64/t-softfp t-softfp 
ia64/t-softfp-compat ia64/t-glibc ia64/t-eh-ia64 t-libunwind
+   tmake_file=ia64/t-ia64 t-crtfm t-softfp-tf ia64/t-softfp t-softfp 
ia64/t-softfp-compat ia64/t-eh-ia64 t-libunwind ia64/t-glibc
if test x$with_system_libunwind != xyes ; then
tmake_file=${tmake_file} t-libunwind-elf 
ia64/t-glibc-libunwind
fi
-- 
1.7.6


-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-09 Thread Rainer Orth
Andreas,

 The definition of LIB2ADDEH from ia64/t-glibc is supposed to prevail.
 I've verified that the resulting libgcc_s.so aggrees with the one
 produced by the 4.6 branch.  Checked in as obvious.

in that case, ia64/t-eh-ia64 should be removed since it's overridden
completely and only serves to confuse.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-08 Thread Andreas Schwab
It's already fixed, 'twas the missing ldflags.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-06 Thread Mikael Morin
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:
 On Fri, Aug 5, 2011 at 20:18, Mikael Morin mikael.mo...@sfr.fr wrote:
  I suppose it is this patch that breaks bootstrap
The culprit is indeed r177447.

 
 Adding a -I flag?  I suppose that makes sense even if crtstuff is
 moved soon to toplevel libgcc.
How about this? It fixes the problem.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (révision 177491)
+++ gcc/Makefile.in (copie de travail)
@@ -1088,7 +1088,7 @@
 INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
   -I$(srcdir)/../include @INCINTL@ \
   $(CPPINC) $(GMPINC) $(DECNUMINC) \
-  $(PPLINC) $(CLOOGINC)
+  $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc
 
 .c.o:
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION)


Mikael


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-06 Thread Paolo Bonzini

On 08/06/2011 12:43 PM, Mikael Morin wrote:

On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:

On Fri, Aug 5, 2011 at 20:18, Mikael Morinmikael.mo...@sfr.fr  wrote:

I suppose it is this patch that breaks bootstrap

The culprit is indeed r177447.



Adding a -I flag?  I suppose that makes sense even if crtstuff is
moved soon to toplevel libgcc.

How about this? It fixes the problem.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (révision 177491)
+++ gcc/Makefile.in (copie de travail)
@@ -1088,7 +1088,7 @@
  INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
   -I$(srcdir)/../include @INCINTL@ \
   $(CPPINC) $(GMPINC) $(DECNUMINC) \
-  $(PPLINC) $(CLOOGINC)
+  $(PPLINC) $(CLOOGINC) -I$(srcdir)/../libgcc

  .c.o:
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $  $(OUTPUT_OPTION)


Thanks.

Can you try this instead?

Paolo

2011-08-06  Paolo Bonzini  bonz...@gnu.org
Mikael Morin   mikael.mo...@sfr.fr

* Makefile.in (INCLUDES_FOR_TARGET): New.
(LIBGCC2_CFLAGS): Use it.
(CRTSTUFF_CFLAGS): Use it instead of INCLUDES.
Index: ../gcc/gcc/Makefile.in
===
--- ../gcc/gcc/Makefile.in	(revision 177266)
+++ ../gcc/gcc/Makefile.in	(working copy)
@@ -668,9 +668,9 @@ endif
 # Options to use when compiling libgcc2.a.
 #
 LIBGCC2_DEBUG_CFLAGS = -g
-LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) \
-		 $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \
-		 -DIN_LIBGCC2 \
+LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(INCLUDES_FOR_TARGET) $(GCC_CFLAGS) \
+		 $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) \
+		 $(GTHREAD_FLAGS) -DIN_LIBGCC2 \
 		 -fbuilding-libgcc -fno-stack-protector \
 		 $(INHIBIT_LIBC_CFLAGS)
 
@@ -682,8 +682,8 @@ LIBGCC2_INCLUDES =
 TARGET_LIBGCC2_CFLAGS =
 
 # Options to use when compiling crtbegin/end.
-CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
-  -finhibit-size-directive -fno-inline -fno-exceptions \
+CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES_FOR_TARGET) $(MULTILIB_CFLAGS) \
+  -g0 -finhibit-size-directive -fno-inline -fno-exceptions \
   -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
   -fno-stack-protector \
   $(INHIBIT_LIBC_CFLAGS)
@@ -1102,6 +1102,9 @@ INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(s
 	   $(CPPINC) $(GMPINC) $(DECNUMINC) \
 	   $(PPLINC) $(CLOOGINC)
 
+INCLUDES_FOR_TARGET = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
+	   -I$(srcdir)/../include $(DECNUMINC) -I$(srcdir)/../libgcc
+
 .c.o:
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ $(OUTPUT_OPTION)
 


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-06 Thread Mikael Morin
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
 Can you try this instead?
It works. Thanks

Mikael



Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-06 Thread Paolo Bonzini

On 08/06/2011 05:07 PM, Mikael Morin wrote:

On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:

Can you try this instead?

It works. Thanks


Committed, thanks.

Paolo



Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-06 Thread Richard Sandiford
Thanks again for doing this.

Rainer Orth r...@cebitec.uni-bielefeld.de writes:
   * config.host (unwind_header): New variable.
   (*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
   (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
   *-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
   (*-*-solaris2*): Add t-eh-dw2-dip to tmake_file.

The combination of this and the soft-fp patch meant that t-mips
wasn't included by mips*-linux-gnu.  The fix below seemed obvious,
especially given the solaris case, so I applied it after testing
on mips64-linux-gnu.

Richard


libgcc/
* config.host (*-*-darwin*, *-*-freebsd*, *-*-linux*, frv-*-*linux*)
(*-*-kfreebsd*-gnu, *-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu):
Add to tmake_file rather than overriding it.

Index: libgcc/config.host
===
--- libgcc/config.host  2011-08-06 15:36:16.0 +0100
+++ libgcc/config.host  2011-08-06 15:36:52.0 +0100
@@ -163,7 +163,7 @@ esac
 case ${host} in
 *-*-darwin*)
   asm_hidden_op=.private_extern
-  tmake_file=t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin
+  tmake_file=$tmake_file t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin
   extra_parts=crt3.o
   ;;
 *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
@@ -179,10 +179,10 @@ case ${host} in
   # This is the generic ELF configuration of FreeBSD.  Later
   # machine-specific sections may refine and add to this
   # configuration.
-  tmake_file=t-eh-dw2-dip
+  tmake_file=$tmake_file t-eh-dw2-dip
   ;;
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)
-  tmake_file=t-eh-dw2-dip
+  tmake_file=$tmake_file t-eh-dw2-dip
   extra_parts=crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o
   ;;
 *-*-netbsd*)


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Rainer Orth
Paolo Bonzini bonz...@gnu.org writes:

 How should we proceed with this patch, especially given the quite
 moderate comments from most affected target maintainers?

 ARM is the only target we should care a bit about.  Any chance you can try
 cross-compiling it (with a combined tree it should not be hard)? Just to
 see that it builds.

I've tried to setup crosstool-NG in the past, but failed and haven't
gotten around to debugging this yet.  I still mean to, especially given
that I need to investigate testsuite issues in a cross environment.

Nick already ok'ed the arm (and frv) parts, so we should be ok for now.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Paolo Bonzini

On 08/05/2011 01:46 PM, Rainer Orth wrote:

  How should we proceed with this patch, especially given the quite
  moderate comments from most affected target maintainers?


  ARM is the only target we should care a bit about.  Any chance you can try
  cross-compiling it (with a combined tree it should not be hard)? Just to
  see that it builds.

I've tried to setup crosstool-NG in the past, but failed and haven't
gotten around to debugging this yet.  I still mean to, especially given
that I need to investigate testsuite issues in a cross environment.

Nick already ok'ed the arm (and frv) parts, so we should be ok for now.


Ok then.

Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Paolo Bonzini
On Fri, Aug 5, 2011 at 20:18, Mikael Morin mikael.mo...@sfr.fr wrote:
 I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2:
 /home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No
 such file or directory

 Fixed by the the following pat^Whack
 Index: crtstuff.c
 ===
 --- crtstuff.c  (révision 177469)
 +++ crtstuff.c  (copie de travail)
 @@ -61,7 +61,7 @@
  #include tsystem.h
  #include coretypes.h
  #include tm.h
 -#include unwind-dw2-fde.h
 +#include ../libgcc/unwind-dw2-fde.h

  #ifndef FORCE_CODE_SECTION_ALIGN
  # define FORCE_CODE_SECTION_ALIGN

 There is probably something better, but I have no clue.

Adding a -I flag?  I suppose that makes sense even if crtstuff is
moved soon to toplevel libgcc.

Paolo


[build] Move unwinder to toplevel libgcc (v2)

2011-08-03 Thread Rainer Orth
This is the revised/updated version of the patch originally posted at

[build] Move unwinder to toplevel libgcc
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html

and reposted as CFT at

http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00201.html

It should incorporate all review comments and a few errors I've noticed
during final review have been corrected.

I've received approval for the Darwin bits, Steve successfully tested on
HP-UX/IA64 and Linux/IA64 at least bootstrapped.  VMS/IA64 approval has
been given conditional on the approval of the other IA64 bits.  I've
also received approval for the libjava parts.

Bootstrapped without regressions (together with the next two, to be
resubmitted shortly: fp-bit and soft-fp moves) on
x86_64-unknown-linux-gnu.

i386-pc-solaris2.10, sparc-sun-solaris2.11, alpha-dec-osf5.1b,
mips-sgi-irix6.5 and i386-apple-darwin9.8.0 bootstraps in progress.
powerpc-apple-darwin9.8.0 currently broken (SIGBUS compiling
c-family/c-pretty-print.c and cp/call.c).

How should we proceed with this patch, especially given the quite
moderate comments from most affected target maintainers?

Thanks.
Rainer


2011-06-12  Rainer Orth  r...@cebitec.uni-bielefeld.de

gcc:
* Makefile.in (UNWIND_H): Remove.
(LIB2ADDEH, LIB2ADDEHSTATIC, LIB2ADDEHSHARED): Move to
../libgcc/Makefile.in.
(LIBUNWIND, SHLIBUNWIND_LINK, SHLIBUNWIND_INSTALL): Likewise.
(LIBUNWINDDEP): Remove.
(libgcc-support): Remove LIB2ADDEH, $(srcdir)/emutls.c dependencies.
(libgcc.mvars): Remove LIB2ADDEH, LIB2ADDEHSTATIC, LIB2ADDEHSHARED,
LIBUNWIND, SHLIBUNWIND_LINK, SHLIBUNWIND_INSTALL.
(stmp-int-hdrs): Remove $(UNWIND_H) dependency.
Don't copy $(UNWIND_H).
* config.gcc (ia64*-*-linux*): Remove with_system_libunwind
handling.
* configure.ac (GCC_CHECK_UNWIND_GETIPINFO): Remove.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* emutls.c, unwind-c.c, unwind-compat.c, unwind-compat.h,
unwind-dw2-fde-compat.c, unwind-dw2-fde-glibc.c, unwind-dw2-fde.c,
unwind-dw2-fde.h, unwind-dw2.c, unwind-dw2.h, unwind-generic.h,
unwind-pe.h, unwind-sjlj.c, unwind.inc: Move to ../libgcc.
* unwind-dw2-fde-darwin.c: Move to ../libgcc/config.
* config/arm/libunwind.S, config/arm/pr-support.c,
config/arm/unwind-arm.c, config/arm/unwind-arm.h: Move to
../libgcc/config/arm.
* config/arm/t-bpabi (UNWIND_H, LIB2ADDEH): Remove.
* config/arm/t-symbian (UNWIND_H, LIB2ADDEH): Remove.
* config/frv/t-frv ($(T)frvbegin$(objext)): Use
$(srcdir)/../libgcc to refer to unwind-dw2-fde.h.
($(T)frvend$(objext)): Likewise.
* config/ia64/t-glibc (LIB2ADDEH): Remove.
* config/ia64/t-glibc-libunwind: Move to ../libgcc/config/ia64.
* config/ia64/fde-glibc.c, config/ia64/fde-vms.c,
config/ia64/unwind-ia64.c, config/ia64/unwind-ia64.h: Move to
../libgcc/config/ia64.
* config/ia64/t-hpux (LIB2ADDEH): Remove.
* config/ia64/t-ia64 (LIB2ADDEH): Remove.
* config/ia64/t-vms (LIB2ADDEH): Remove.
* config/ia64/vms.h (UNW_IVMS_MODE,
MD_UNW_COMPATIBLE_PERSONALITY_P): Remove.
* config/picochip/t-picochip (LIB2ADDEH): Remove.
* config/rs6000/aix.h (R_LR, MD_FROB_UPDATE_CONTEXT): Remove.
* config/rs6000/t-darwin (LIB2ADDEH): Remove.
* config/rs6000/darwin-fallback.c: Move to ../libgcc/config/rs6000.
* config/sh/t-sh ($(T)unwind-dw2-Os-4-200.o): Use
$(srcdir)/../libgcc to refer to unwinder sources.
* config/spu/t-spu-elf (LIB2ADDEH): Remove.
* config/t-darwin (LIB2ADDEH): Remove.
* config/t-freebsd (LIB2ADDEH): Remove.
* config/t-libunwind (LIB2ADDEH, LIB2ADDEHSTATIC): Remove.
* config/t-libunwind-elf: Move to ../libgcc/config.
* config/t-linux (LIB2ADDEH): Remove.
* config/t-sol2 (LIB2ADDEH): Remove.
* config/xtensa/t-xtensa (LIB2ADDEH): Remove.
* system.h (MD_FROB_UPDATE_CONTEXT): Poison.

gcc/po:
* EXCLUDES (unwind-c.c, unwind-dw2-fde-darwin.c)
(unwind-dw2-fde-glibc.c, unwind-dw2-fde.c, unwind-dw2-fde.h)
(unwind-dw2.c, unwind-pe.h, unwind-sjlj.c, unwind.h): Remove.

libgcc:
* Makefile.in (LIB2ADDEH, LIB2ADDEHSTATIC, LIB2ADDEHSHARED): New
variables.
(LIBUNWIND, SHLIBUNWIND_LINK, SHLIBUNWIND_INSTALL): New variables.
(LIB2ADDEH, LIB2ADDEHSTATIC, LIB2ADDEHSHARED): Add $(srcdir)/emutls.c.
(install-unwind_h): New target.
(all): Depend on it.
* config.host (unwind_header): New variable.
(*-*-freebsd*): Set tmake_file to t-eh-dw2-dip.
(*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu, *-*-knetbsd*-gnu,
*-*-gnu*): Likewise, also for *-*-kopensolaris*-gnu.
(*-*-solaris2*): Add t-eh-dw2-dip to tmake_file.

Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-03 Thread Nick Clifton

Hi Rainer,


How should we proceed with this patch, especially given the quite
moderate comments from most affected target maintainers?


I have no objections to the patch from an ARM or FRV point of view.

Cheers
  Nick



Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-03 Thread Benjamin Kosnik

 +++ b/libstdc++-v3/acinclude.m4
 @@ -685,9 +685,9 @@ AC_DEFUN([GLIBCXX_EXPORT_INCLUDES], [
fi
  
# Stuff in the actual top level.  Currently only used by libsupc++
 to
 -  # get unwind* headers from the gcc dir.
 -  #TOPLEVEL_INCLUDES='-I$(toplevel_srcdir)/gcc
 -I$(toplevel_srcdir)/include'
 -  TOPLEVEL_INCLUDES='-I$(toplevel_srcdir)/gcc'
 +  # get unwind* headers from the libgcc dir.
 +  #TOPLEVEL_INCLUDES='-I$(toplevel_srcdir)/libgcc
 -I$(toplevel_srcdir)/include'
 +  TOPLEVEL_INCLUDES='-I$(toplevel_srcdir)/libgcc'
  
# Now, export this to all the little Makefiles
AC_SUBST(GLIBCXX_INCLUDES)

Ok, as a formality.

-benjamin