Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Steven Bosscher]

xf. http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01640.html

On Wed, 26 Mar 2008, Kaveh R. GHAZI wrote:
> I think showing progress on this front would help establish that objc++ is
> actively maintained and strengthen the argument to put it in the default
> bootstrap list.  Stan, are you able to contribute on this front?

Is "actively maintained" an argument to enable a language by default?
Ada is actively maintained, and the Ada language probably has far more
users than ObjC++ does. But GNAT is not enabled by default. It is good
that Stan has stood up to maintain it, but the real maintenance hassle
is not on Stan but on everyone who wants to change the C, ObjC, or C++
front ends. If I look at the ObjC++ front end, I see a
dump-and-disappear action by the front end contributors, burdening the
community with the maintenance for it.

So who is going to benefit from enabling ObjC++ by default? Certainly
not any of the groups and individuals who actively contribute to GCC
development. Maybe the odd-one-out Apple user who builds GCC from
source, but that wouldn't justify enabling the front end for everyone
by default, IMHO.

The SC tried to avoid exactly the situation GCC is in now
(http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
nobody will be required to test Objective-C++ as part of the check-in
cycle, and people who cause defects in Objective-C++ will not
necessarily be required to fix them, although good manners dictates
that people will help clean up their own mess where practical."

Gr.
Steven

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

> The SC tried to avoid exactly the situation GCC is in now
> (http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
> nobody will be required to test Objective-C++ as part of the check-in
> cycle, and people who cause defects in Objective-C++ will not
> necessarily be required to fix them, although good manners dictates
> that people will help clean up their own mess where practical."

As I interpret it, if the patches are very invasive (such as the once 
that changed tree nodes internal to the parsers, to be separate C 
structs) no one should be forced to rework Objective-C++.  But in most 
cases, spending half an hour on a fix is just "good manners".

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

> The SC tried to avoid exactly the situation GCC is in now
> (http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
> nobody will be required to test Objective-C++ as part of the check-in
> cycle, and people who cause defects in Objective-C++ will not
> necessarily be required to fix them, although good manners dictates
> that people will help clean up their own mess where practical."

As I interpret it, if the patches are very invasive (such as the once 
that changed tree nodes internal to the parsers, to be separate C 
structs) no one should be forced to rework Objective-C++.  But in most 
cases, spending half an hour on a fix is just "good manners".

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Joseph S. Myers]

On Thu, 27 Mar 2008, Steven Bosscher wrote:

> Is "actively maintained" an argument to enable a language by default?
> Ada is actively maintained, and the Ada language probably has far more
> users than ObjC++ does. But GNAT is not enabled by default. It is good

It was disabled when tree-ssa was merged, because it wasn't ready for 
tree-ssa at that time.  I'm not aware of any policy decision to disable 
it, just what should have been temporary disabling until a problem was 
fixed; I think we should enable it by default again, while still allowing 
people not to test patches with Ada since they may not have bootstrap Ada 
compilers.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Mark Mitchell]

Joseph S. Myers wrote:

> It was disabled when tree-ssa was merged, because it wasn't ready for 
> tree-ssa at that time.  I'm not aware of any policy decision to disable 
> it, just what should have been temporary disabling until a problem was 
> fixed; I think we should enable it by default again, while still allowing 
> people not to test patches with Ada since they may not have bootstrap Ada 
> compilers.

I think that having all GCC developers build/test all languages all the 
time is overkill.  I'm all for testing, and I certainly think that 
people should make an effort to test languages that it seems like their 
paches might be likely to impact (e.g., major C++ changes are likely to 
affect Objectie-C++), but adding hours to everyones build/test cycles 
seems like a bad tradeoff.  Instead, people who break Ada, 
Objective-C++, etc., should be responsible to requests to fix the 
breakage, and willing to revert their patches if no fix is immediately 
found.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Kaveh R. GHAZI]

On Thu, 27 Mar 2008, Mark Mitchell wrote:

> I think that having all GCC developers build/test all languages all the
> time is overkill.  I'm all for testing, and I certainly think that
> people should make an effort to test languages that it seems like their
> paches might be likely to impact (e.g., major C++ changes are likely to
> affect Objectie-C++), but adding hours to everyones build/test cycles
> seems like a bad tradeoff.  Instead, people who break Ada,
> Objective-C++, etc., should be responsible to requests to fix the
> breakage, and willing to revert their patches if no fix is immediately
> found.


I think a middle ground could be that we enable building objc++ by
default, but not run its testsuite unless it is specifically enabled.

This would catch the type of bootstrap errors we've seen several times
recently without causing significant extra time in the overall build time.
I think there's like three extra .o files necessary to link cc1objcplus,
the remainder are reused modules from the C and C++ frontends.  It
certainly wouldn't be "adding hours" to everyone's test cycle.  And
there's no objc++ specific target library AFAICT, so it's really cheap to
activate.

Does this sound like a balanced and fair compromise?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

On Thu, Mar 27, 2008 at 3:34 PM, Kaveh R. GHAZI
<ghazi@caip.rutgers.edu> wrote:
>  I think a middle ground could be that we enable building objc++ by
>  default, but not run its testsuite unless it is specifically enabled.

The testsuite for Objective-C++ is so small, it is not even a blimp in
my testing time.  So I don't think this is a good middle ground.

-- Pinski

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Thu, Mar 27, 2008 at 11:34 PM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Thu, 27 Mar 2008, Mark Mitchell wrote:
>
>  > I think that having all GCC developers build/test all languages all the
>  > time is overkill.  I'm all for testing, and I certainly think that
>  > people should make an effort to test languages that it seems like their
>  > paches might be likely to impact (e.g., major C++ changes are likely to
>  > affect Objectie-C++), but adding hours to everyones build/test cycles
>  > seems like a bad tradeoff.  Instead, people who break Ada,
>  > Objective-C++, etc., should be responsible to requests to fix the
>  > breakage, and willing to revert their patches if no fix is immediately
>  > found.
>
>
>  I think a middle ground could be that we enable building objc++ by
>  default, but not run its testsuite unless it is specifically enabled.
>
>  This would catch the type of bootstrap errors we've seen several times
>  recently without causing significant extra time in the overall build time.
>  I think there's like three extra .o files necessary to link cc1objcplus,
>  the remainder are reused modules from the C and C++ frontends.  It
>  certainly wouldn't be "adding hours" to everyone's test cycle.  And
>  there's no objc++ specific target library AFAICT, so it's really cheap to
>  activate.
>
>  Does this sound like a balanced and fair compromise?

Even the 130 tests of the objc++ testsuite won't hurt anyone.  Building
and testing libjava is what is most of the pain ;)

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Kaveh R. GHAZI]

On Thu, 27 Mar 2008, Richard Guenther wrote:

> On Thu, Mar 27, 2008 at 11:34 PM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> > On Thu, 27 Mar 2008, Mark Mitchell wrote:
> >
> >  > I think that having all GCC developers build/test all languages all the
> >  > time is overkill.  I'm all for testing, and I certainly think that
> >  > people should make an effort to test languages that it seems like their
> >  > paches might be likely to impact (e.g., major C++ changes are likely to
> >  > affect Objectie-C++), but adding hours to everyones build/test cycles
> >  > seems like a bad tradeoff.  Instead, people who break Ada,
> >  > Objective-C++, etc., should be responsible to requests to fix the
> >  > breakage, and willing to revert their patches if no fix is immediately
> >  > found.
> >
> >
> >  I think a middle ground could be that we enable building objc++ by
> >  default, but not run its testsuite unless it is specifically enabled.
> >
> >  This would catch the type of bootstrap errors we've seen several times
> >  recently without causing significant extra time in the overall build time.
> >  I think there's like three extra .o files necessary to link cc1objcplus,
> >  the remainder are reused modules from the C and C++ frontends.  It
> >  certainly wouldn't be "adding hours" to everyone's test cycle.  And
> >  there's no objc++ specific target library AFAICT, so it's really cheap to
> >  activate.
> >
> >  Does this sound like a balanced and fair compromise?
>
> Even the 130 tests of the objc++ testsuite won't hurt anyone.  Building
> and testing libjava is what is most of the pain ;)
> Richard.


I guess you're right :-) we might as well throw in the few tests that it
has.  After all, there are thousands of tests in the other directories.
I double running the obj-c++ tests will make a dent.

I'll do a bootstrap --enable-langauges=all and run the testsuite with and
without the patch below to see what the actual timing difference is.

Assuming it's "really small" I hope no one objects to this patch?

		--Kaveh


2008-03-28  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* config-lang.in (build_by_default): Build obj-c++ by default.

diff -rup orig/egcc-SVN20080327/gcc/objcp/config-lang.in egcc-SVN20080327/gcc/objcp/config-lang.in
--- orig/egcc-SVN20080327/gcc/objcp/config-lang.in	2008-03-14 00:34:31.000000000 +0100
+++ egcc-SVN20080327/gcc/objcp/config-lang.in	2008-03-28 00:58:54.000000000 +0100
@@ -28,9 +28,6 @@ language="obj-c++"

 compilers="cc1objplus\$(exeext)"

-# Per GCC Steering Committee.
-build_by_default="no"
-
 # By building the Objective-C and C++ front-ends, we will get
 # the object files we need, along with the libraries (libstdc++,
 # libobjc).

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Kaveh R. GHAZI]

On Thu, 27 Mar 2008, Kaveh R. GHAZI wrote:

> I'll do a bootstrap --enable-langauges=all and run the testsuite with and
> without the patch below to see what the actual timing difference is.

I got the results.  Tests were on on an 8-way x86_64-unknown-linux-gnu
box.  I ran the tests at the same time to minimize load related factors,
and the make's were all serial.  No special RUNTESTFLAGS, so no extra
passes in the testsuite.  Just one regular run through was done.

Since mainline cannot bootstrap objc++ because of the recent breakage, I
did the experiment on the 4.3 branch using --enable-checking=yes to
simulate what developers will see on mainline.

The baseline bootstrap --enable-languages=all and "make check" took
3:40:59.  The patched bootstrap enabling objc++ by default took 3:41:41,
so that's only *42 seconds* longer, or 0.3% more.

So once objc++ is back to bootstrap-land, may I install my patch to
activate it by default on mainline?

		Thanks,
		--Kaveh

PS: For comparison I added in Ada and it took 4:14:58 which is almost 34
minutes longer than the baseline, or 15.4% more.  I don't have an opinion
about whether it should be on by default or not.  Just throwing the
statistic out there.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

> The baseline bootstrap --enable-languages=all and "make check" took
> 3:40:59.  The patched bootstrap enabling objc++ by default took 3:41:41,
> so that's only *42 seconds* longer, or 0.3% more.

When I'll remove target libiberty, I hope to save more than that. 
Throwing another piece of data in the thread. :-)

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Fri, Mar 28, 2008 at 7:04 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
>  > The baseline bootstrap --enable-languages=all and "make check" took
>  > 3:40:59.  The patched bootstrap enabling objc++ by default took 3:41:41,
>  > so that's only *42 seconds* longer, or 0.3% more.
>
>  When I'll remove target libiberty, I hope to save more than that.
>  Throwing another piece of data in the thread. :-)

:)

So I thought I make some measurements myself.  For "bad" patches
I do all-languages and multilib bootstrap and tests on x86_64-linux.
Bootstrap takes

11566.82user 835.02system 37:41.31elapsed 548%CPU

and multilib testing (RUNTESTFLAGS="--target_board=unix/\{,-m32\}")

10793.09user 3616.46system 59:11.61elapsed 405%CPU

on a moderately old 8 core machine (with enough memory to allow
-j10 bootstrap and -j8 test).  As you can see we can not even fully
utilize all the CPUs (the big generator files are likely a problem and
bad parallelism in the libjava build is another), testing time is also
hugely dominated by all the forks() (see that system time number!).

Still this means my regular bootstrap and testing time is around
one hour (minus ada and minus the -m32 testing), which IMHO is
very reasonable.  If you double that it would be the time it takes
on a single-CPU quad-core machine which I expect a free-time
volunteer GCC developer to have access to ;)

If we can improve on the bootlenecks (dejagnu anyone?  splitting
insn-* and gen*, or building the generator files optimized during
stage1?) it would maybe scale even better, which even I would
appreciate.

Thanks,
Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

> If we can improve on the bootlenecks (dejagnu anyone?  splitting
> insn-* and gen*, or building the generator files optimized during
> stage1?)

A while ago people were speaking of building stage1 optimized... can you 
test with STAGE1_CFLAGS="-O2 -g"?

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
>  > If we can improve on the bootlenecks (dejagnu anyone?  splitting
>  > insn-* and gen*, or building the generator files optimized during
>  > stage1?)
>
>  A while ago people were speaking of building stage1 optimized... can you
>  test with STAGE1_CFLAGS="-O2 -g"?

10473.53user 849.12system 34:57.32elapsed 539%CPU

so not too much effect on the elapsed time (3 minutes).

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

Sent from my iPhone

On Mar 28, 2008, at 6:07, "Richard Guenther"  
<richard.guenther@gmail.com> wrote:

> On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org>  
> wrote:
>>
>>> If we can improve on the bootlenecks (dejagnu anyone?  splitting
>>> insn-* and gen*, or building the generator files optimized during
>>> stage1?)
>>
>> A while ago people were speaking of building stage1 optimized...  
>> can you
>> test with STAGE1_CFLAGS="-O2 -g"?
>
> 10473.53user 849.12system 34:57.32elapsed 539%CPU
>
> so not too much effect on the elapsed time (3 minutes).

On the Cell the effect should be more for optimized stage1 because of  
it handles loads after stores ( no load bypass).

-- Pinski


>
>
> Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

Richard Guenther wrote:
> On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>>  > If we can improve on the bootlenecks (dejagnu anyone?  splitting
>>  > insn-* and gen*, or building the generator files optimized during
>>  > stage1?)
>>
>>  A while ago people were speaking of building stage1 optimized... can you
>>  test with STAGE1_CFLAGS="-O2 -g"?
> 
> 10473.53user 849.12system 34:57.32elapsed 539%CPU
> 
> so not too much effect on the elapsed time (3 minutes).

IMO not worth the difference since, at least for development, 
unoptimized stage1 means you don't have to recompile anything to debug 
testsuite failures (just make stage1-start).

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[H.J. Lu]

On Fri, Mar 28, 2008 at 4:05 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
>  > If we can improve on the bootlenecks (dejagnu anyone?  splitting
>  > insn-* and gen*, or building the generator files optimized during
>  > stage1?)
>
>  A while ago people were speaking of building stage1 optimized... can you
>  test with STAGE1_CFLAGS="-O2 -g"?
>

I think it is a bad idea. It will make all stages of gcc very hard to debug.


H.J.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Jakub Jelinek]

On Fri, Mar 28, 2008 at 11:58:03AM +0100, Richard Guenther wrote:
> If we can improve on the bootlenecks (dejagnu anyone?  splitting
> insn-* and gen*, or building the generator files optimized during
> stage1?) it would maybe scale even better, which even I would
> appreciate.

Low-hanging fruit e.g. could be a configure switch to disable building
libgcj.a/libgcj-tools.a when libgcj.so/libgcj-tools.so is built.
As statically linking -lgcj/-lgcj-tools has very significant limitations
and issues, libgcj.a/libgcj-tools.a really should be used just
on targets which don't support shared libraries.
Not sure if libtool can be easily convinced to avoid building everything
twice though.  But could very well save 30% or 40% of libjava build time.

	Jakub

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Ralf Wildenhues]

* Jakub Jelinek wrote on Fri, Mar 28, 2008 at 02:21:05PM CET:
> Not sure if libtool can be easily convinced to avoid building everything
> twice though.

Either pass -static/-shared in {,AM_,target_}GCJFLAGS or pass
--tag=disable-static/ --tag=disable-shared before the --tag=GCJ argument
(Automake 1.10 has {,AM_,target_}LIBTOOLFLAGS for this, with 1.9.6
something like
  LIBTOOL = @LIBTOOL@ --tag=disable-static

should work.  If you can decide globally per configure, then passing
--disable-static/--disable-shared to that is preferable, though.

Cheers,
Ralf

Improving parallel build (was: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage)

[Ralf Wildenhues]

[ trimming Cc: list ]

Hello Richard,

* Richard Guenther wrote on Fri, Mar 28, 2008 at 11:58:03AM CET:
> Bootstrap takes
> 
> 11566.82user 835.02system 37:41.31elapsed 548%CPU

> on a moderately old 8 core machine (with enough memory to allow
> -j10 bootstrap and -j8 test).

> As you can see we can not even fully utilize all the CPUs (the big
> generator files are likely a problem and bad parallelism in the
> libjava build is another),

FWIW, until gij, excj, classpath/tools/tools.zip are built, I see good
parallelism in libjava: 707%CPU on an 8-way.  After that it's pretty
much single cpu.  I have not looked into that any further yet, probably
some of the more expensive objects could be moved.

> If we can improve on the bootlenecks (dejagnu anyone?  splitting
> insn-* and gen*, or building the generator files optimized during
> stage1?) it would maybe scale even better, which even I would
> appreciate.

Here's a small analysis for gcc/.

Summary conclusion: better schedule hinting for GNU make is cheap and
should be done before splitting insn-attrtab.c and insn-recog.o.  You
should use the patch below and -j8.

First, a few measurements, all done on an otherwise-quiet 8-way system
with plenty of RAM:

The work of gen-* is not relevant yet (shown is time to update target
without its dependencies):

s-attrtab
12.57user 0.14system 0:12.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+64437minor)pagefaults 0swaps
s-automata
1.73user 0.08system 0:01.84elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+37814minor)pagefaults 0swaps

Of insn-*, these are the most costly files:
insn-attrtab.o
107.99user 0.89system 1:48.90elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+441498minor)pagefaults 0swaps
insn-recog.o
48.07user 0.34system 0:48.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+116151minor)pagefaults 0swaps
insn-emit.o
11.71user 0.21system 0:11.97elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+67973minor)pagefaults 0swaps
insn-automata.o
1.42user 0.12system 0:01.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+42380minor)pagefaults 0swaps

FWIW, the most costly non-insn:
fold-const.o
26.98user 0.30system 0:27.41elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+97186minor)pagefaults 0swaps

insn-recog.c has lots of non-large static functions, could be split
easily (but they'd have to be global then).

insn-attrtab.c's functions are already global, but at least for x86_64,
two functions make up for roughly a third of the file each, so only
splitting at function borders only will still leave it at the top of the
list.  Which means it makes sense to look at insn-emit only after
splitting the big switch statements inside internal_dfa_insn_code and
insn_default_latency (in that order), and only after you've bought a
16-way system.

But before splitting, really make could do better, and this is why:

$ make clean; make -j20 all
872.38user 25.53system 3:28.88elapsed 429%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+6247181minor)pagefaults 0swaps

$ make clean; \time make -j20 insn-attrtab.o
131.47user 2.96system 2:05.84elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+822606minor)pagefaults 0swaps

$ make all; touch insn-attrtab.o; \time make -j20 all
6.60user 2.95system 0:03.79elapsed 252%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+283480minor)pagefaults 0swaps

This shows that if make knew to give insn-attrtab.o and its dependencies
appropriate priority, the build could be pushed down to approximately
2:10.  (make doesn't do that right now, because after triggering the
dependencies for insn-*, i.e., the compiles for gen-*, it walks the
complete set of objects before returning to insn-*).

Below is a patch to use an order-only dependency of all objects on all
the generated files.  With it, we get down to

$ make clean; \time make -j20
880.34user 26.30system 3:06.76elapsed 485%CPU (0avgtext+0avgdata 0maxresident)k
0:inputs+0outputs (0major+6245542minor)pagefaults 0swaps

which is noticeably better but not what we expected.  Now the rule for
insn-attrtab.o is spawned nicely early, but it has to compete with other
processes for cpu time.  So let's not let the kernel scheduler interfere
with make's:

$ make clean; \time make -j8
882.91user 24.80system 2:19.52elapsed 650%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+6283548minor)pagefaults 0swaps

Note that it's really the order-only prerequisite that makes the job
number matter: without the patch below, -j8 is as fast as -j20.

I do not know if this patch could also trigger the make bug that
prevented automatic dependency tracking, but I haven't been able
to get make to hang with some casual testing.

Otherwise, it passed bootstrap.  OK for trunk?

Thanks for reading this far,
Ralf

gcc/ChangeLog:
2008-03-30  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.in (ALL_OBJS): New macro.
	$(ALL_OBJS): Order-depend on the generated files, for parallel
	efficiency.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 407e2fe..eef6613 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1255,6 +1255,9 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS-archive)
 
 OBJS-onestep = libbackend.o $(OBJS-archive)
 
+ALL_OBJS = $(OBJS) $(GNAT1_OBJS) $(GNATBIND_OBJS) $(CXX_OBJS) $(F95_OBJS) \
+  $(JAVA_OBJS) $(OBJC_OBJS) $(OBJCXX_OBJS)
+
 BACKEND = main.o @TREEBROWSER@ libbackend.a $(CPPLIB) $(LIBDECNUMBER)
 
 MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \
@@ -3008,6 +3011,11 @@ $(simple_generated_c:insn-%.c=s-%): s-%: build/gen%$(build_exeext) \
 	$(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c
 	$(STAMP) s-$*
 
+# In order for parallel make to really start compiling the expensive
+# objects from $(OBJS-common) as early as possible, build all their
+# prerequisites strictly before all objects.
+$(ALL_OBJS) : | $(simple_generated_h) $(simple_generated_c)
+
 # genconstants needs to run before insn-conditions.md is available
 # (because the constants may be used in the conditions).
 insn-constants.h: s-constants; @true

Re: Improving parallel build (was: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage)

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sun, Mar 30, 2008 at 04:37:15PM CEST:
> 
> Otherwise, it passed bootstrap.  OK for trunk?

I should add that I did not test Ada.

> gcc/ChangeLog:
> 2008-03-30  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> 
> 	* Makefile.in (ALL_OBJS): New macro.
> 	$(ALL_OBJS): Order-depend on the generated files, for parallel
> 	efficiency.

Re: Improving parallel build

[Paolo Bonzini]

Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Sun, Mar 30, 2008 at 04:37:15PM CEST:
>> Otherwise, it passed bootstrap.  OK for trunk?

Yep.

Paolo

Re: Improving parallel build (was: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage)

[Richard Guenther]

On Sun, Mar 30, 2008 at 4:37 PM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> [ trimming Cc: list ]
>
>  Hello Richard,
>
[...]
>  $ make clean; \time make -j8
>  882.91user 24.80system 2:19.52elapsed 650%CPU (0avgtext+0avgdata 0maxresident)k
>  0inputs+0outputs (0major+6283548minor)pagefaults 0swaps
>
>  Note that it's really the order-only prerequisite that makes the job
>  number matter: without the patch below, -j8 is as fast as -j20.
>
>  I do not know if this patch could also trigger the make bug that
>  prevented automatic dependency tracking, but I haven't been able
>  to get make to hang with some casual testing.

Heh, that's a pretty big savings for a small patch :)

Thanks,
Richard.

Re: Improving parallel build

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> Below is a patch to use an order-only dependency of all objects
Ralf> on all the generated files.

A couple notes on this...

First, one theory I had about the auto-dependency make failure was
that it was related to order-only dependencies.  So, make sure to try
the problem case there (touch Makefile.in; make -j2 cc1).

Second, you'll need the install.texi change from that patch if this
goes in, as it bumps the make version requirement to 3.80.

Tom

Re: Improving parallel build

[Ralf Wildenhues]

* Tom Tromey wrote on Sun, Mar 30, 2008 at 04:34:25PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> Ralf> Below is a patch to use an order-only dependency of all objects
> Ralf> on all the generated files.

> First, one theory I had about the auto-dependency make failure was
> that it was related to order-only dependencies.  So, make sure to try
> the problem case there (touch Makefile.in; make -j2 cc1).

Yes, I assumed that it related to order-only, and I tried that problem
case, without exposing the make bug.  Which doesn't mean much, it may
just be that it takes a different case to trigger it.

I'm wondering whether I should just retract the patch, for safety.

> Second, you'll need the install.texi change from that patch if this
> goes in, as it bumps the make version requirement to 3.80.

Yes, sorry for that omission.  It would also be cleaner to pick those
bits from your patch that define per-fronted *_OBJS, and use those.

Thanks,
Ralf

Re: Improving parallel build

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> I'm wondering whether I should just retract the patch, for safety.

A simple patch like this that helps build times is pretty appealing.
Personally I'd prefer to give it a shot.  We can always back it out
again if we run into trouble.

Tom

Re: Improving parallel build

[Ralf Wildenhues]

* Tom Tromey wrote on Sun, Mar 30, 2008 at 08:04:30PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> Ralf> I'm wondering whether I should just retract the patch, for safety.
> 
> A simple patch like this that helps build times is pretty appealing.
> Personally I'd prefer to give it a shot.  We can always back it out
> again if we run into trouble.

OK, here's the patch redone in terms of your automatic dependency patch.
What's really funny is that it's almost a strict subset of your patch
(modulo reordering in Makefile.in, copyright year updates, merging in
the obj-c++ typo patch, and documentation), which is why I haven't put
my name on most ChangeLog entries.  So there is some benefit from all
your work.  :-)

The patch passed parallel bootstrap of languages != ada, obj-c++,
giving virtually the same speedup, and passed the
  touch $top_srcdir/gcc/Makefile.in && make -j2 cc1

test using make 3.80.  Sequential bootstrap of all languages is running.
OK for trunk if that passes?  OK if I apply this or would you like to,
Tom?

Thanks,
Ralf

gcc/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>
	    Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* config/m68k/t-uclinux (generated_files): Add sysroot-suffix.h.
	* config/bfin/t-bfin-linux (generated_files): Add
	linux-sysroot-suffix.h.
	* doc/install.texi (Prerequisites): Require make 3.80.
	* doc/sourcebuild.texi (Front End Directory): Document new
	variable.
	* Makefile.in (generated_files): New variable.
	(ALL_HOST_OBJS): New variable.
	($(ALL_HOST_OBJS)): New target.

gcc/java/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>

	* Make-lang.in (java_OBJS): New variable.

gcc/objc/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>

	* Make-lang.in (objc_OBJS): New variable.

gcc/objcp/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>

	* Make-lang.in (obj-c++_OBJS): New variable.

gcc/cp/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>

	* Make-lang.in (c++_OBJS): New variable.

gcc/fortran/ChangeLog:
2008-03-31  Tom Tromey  <tromey@redhat.com>

	* Make-lang.in (fortran_OBJS): New variable.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 407e2fe..388d966 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1255,6 +1255,15 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS-archive)
 
 OBJS-onestep = libbackend.o $(OBJS-archive)
 
+# This lists all host object files, whether they are included in this
+# compilation or not.
+ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \
+  @TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \
+  $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \
+  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
+  mips-tfile.o mips-tdump.o \
+  $(PROTO_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS)
+
 BACKEND = main.o @TREEBROWSER@ libbackend.a $(CPPLIB) $(LIBDECNUMBER)
 
 MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \
@@ -3008,6 +3017,16 @@ $(simple_generated_c:insn-%.c=s-%): s-%: build/gen%$(build_exeext) \
 	$(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c
 	$(STAMP) s-$*
 
+generated_files = config.h tm.h $(TM_P_H) $(TM_H) multilib.h \
+       $(simple_generated_h) $(simple_generated_c) specs.h \
+       tree-check.h genrtl.h insn-modes.h tm-preds.h tm-constrs.h \
+       $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h gcov-iov.h
+
+# In order for parallel make to really start compiling the expensive
+# objects from $(OBJS-common) as early as possible, build all their
+# prerequisites strictly before all objects.
+$(ALL_HOST_OBJS) : | $(generated_files)
+
 # genconstants needs to run before insn-conditions.md is available
 # (because the constants may be used in the conditions).
 insn-constants.h: s-constants; @true
diff --git a/gcc/config/bfin/t-bfin-linux b/gcc/config/bfin/t-bfin-linux
index f79ccac..849dcee 100644
--- a/gcc/config/bfin/t-bfin-linux
+++ b/gcc/config/bfin/t-bfin-linux
@@ -33,3 +33,5 @@ linux-sysroot-suffix.h: $(srcdir)/config/bfin/print-sysroot-suffix.sh
 	$(SHELL) $(srcdir)/config/bfin/print-sysroot-suffix.sh \
 	  "$(SYSTEM_HEADER_DIR)/../.." "$(MULTILIB_MATCHES)" \
 	  "$(MULTILIB_OPTIONS)" > $@
+
+generated_files += linux-sysroot-suffix.h
diff --git a/gcc/config/m68k/t-uclinux b/gcc/config/m68k/t-uclinux
index 3ee359d..f860672 100644
--- a/gcc/config/m68k/t-uclinux
+++ b/gcc/config/m68k/t-uclinux
@@ -14,3 +14,5 @@ sysroot-suffix.h: $(srcdir)/config/m68k/print-sysroot-suffix.sh
 	$(SHELL) $(srcdir)/config/m68k/print-sysroot-suffix.sh \
 	  "$(SYSTEM_HEADER_DIR)/../.." "$(MULTILIB_MATCHES)" \
 	  "$(MULTILIB_OPTIONS)" > $@
+
+generated_files += sysroot-suffix.h
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 6207ed1..e1447b0 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -86,6 +86,8 @@ CXX_AND_OBJCXX_OBJS = cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o \
 # Language-specific object files for C++.
 CXX_OBJS = cp/cp-lang.o stub-objc.o $(CXX_AND_OBJCXX_OBJS)
 
+c++_OBJS = $(CXX_OBJS) dummy-checksum.o cc1plus-checksum.o cp/g++spec.o
+
 # Use strict warnings for this front end.
 cp-warn = $(STRICT_WARN) $(CXX_COMPAT_WARN)
 
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 45d982c..027b169 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -285,7 +285,7 @@ requirements.
 Necessary to uncompress GCC @command{tar} files when source code is
 obtained via FTP mirror sites.
 
-@item GNU make version 3.79.1 (or later)
+@item GNU make version 3.80 (or later)
 
 You must have GNU make installed to build GCC@.
 
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index d4b7753..f2ad7f8 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -642,6 +642,9 @@ all generated files in the source directory that are not checked into
 CVS, but should not delete anything checked into CVS@.
 @end table
 
+@file{Make-lang.in} must also define a variable @code{@var{lang}_OBJS}
+to a list of host object files that are used by that language.
+
 @item lang.opt
 This file registers the set of switches that the front end accepts on
 the command line, and their @option{--help} text.  @xref{Options}.
diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index 1702b9f..d9056a1 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -1,6 +1,7 @@
 # -*- makefile -*-
 # Top level makefile fragment for GNU gfortran, the GNU Fortran 95 compiler.
-# Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software
+# Foundation, Inc.
 # Contributed by Paul Brook <paul@nowt.org
 # and Steven Bosscher <s.bosscher@student.tudelft.nl>
 
@@ -67,6 +68,8 @@ F95_OBJS = $(F95_PARSER_OBJS) \
     fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \
     fortran/trans-stmt.o fortran/trans-types.o
 
+fortran_OBJS = $(F95_OBJS) gfortranspec.o
+
 #\f
 # Define the names for selecting gfortran in LANGUAGES.
 fortran: f951$(exeext)
diff --git a/gcc/java/Make-lang.in b/gcc/java/Make-lang.in
index bfb57a3..d799c13 100644
--- a/gcc/java/Make-lang.in
+++ b/gcc/java/Make-lang.in
@@ -1,7 +1,7 @@
 # Top level -*- makefile -*- fragment for the GNU compiler for the Java(TM)
 # language.
 #   Copyright (C) 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
-#   2005, 2006, 2007 Free Software Foundation, Inc.
+#   2005, 2006, 2007, 2008 Free Software Foundation, Inc.
 
 #This file is part of GCC.
 
@@ -90,6 +90,8 @@ JCFDUMP_OBJS = java/jcf-dump.o java/jcf-io.o java/jcf-depend.o java/jcf-path.o \
 
 JVGENMAIN_OBJS = java/jvgenmain.o java/mangle_name.o errors.o intl.o
 
+java_OBJS = $(sort $(JAVA_OBJS) $(JCFDUMP_OBJS) $(JVGENMAIN_OBJS)) jvspec.o
+
 # Use strict warnings for this front end.
 java-warn = $(STRICT_WARN)
 
diff --git a/gcc/objc/Make-lang.in b/gcc/objc/Make-lang.in
index af68816..93a0042 100644
--- a/gcc/objc/Make-lang.in
+++ b/gcc/objc/Make-lang.in
@@ -1,6 +1,6 @@
 # Top level -*- makefile -*- fragment for GNU Objective-C
-#   Copyright (C) 1997, 1998, 2000, 2001, 2002, 2003, 2004, 2005, 2007
-#   Free Software Foundation, Inc.
+#   Copyright (C) 1997, 1998, 2000, 2001, 2002, 2003, 2004, 2005, 2007,
+#   2008 Free Software Foundation, Inc.
 
 #This file is part of GCC.
 
@@ -49,6 +49,8 @@ objc-warn = $(STRICT_WARN)
 # Language-specific object files for Objective C.
 OBJC_OBJS = objc/objc-lang.o objc/objc-act.o
 
+objc_OBJS = $(OBJC_OBJS) cc1obj-checksum.o
+
 cc1obj-dummy$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS)
 	$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
 	      $(OBJC_OBJS) $(C_AND_OBJC_OBJS) dummy-checksum.o \
diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in
index 97b79c2..695df4d 100644
--- a/gcc/objcp/Make-lang.in
+++ b/gcc/objcp/Make-lang.in
@@ -1,5 +1,5 @@
 # Top level -*- makefile -*- fragment for GNU Objective-C++
-#   Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+#   Copyright (C) 2005, 2007, 2008 Free Software Foundation, Inc.
 #   Contributed by Ziemowit Laski  <zlaski@apple.com>
 
 #This file is part of GCC.
@@ -51,6 +51,8 @@ objcp-warn = $(STRICT_WARN) -DOBJCPLUS -I$(srcdir)/objc -I$(srcdir)/cp
 OBJCXX_OBJS = objcp/objcp-act.o objcp/objcp-lang.o objcp/objcp-decl.o \
    $(CXX_AND_OBJCXX_OBJS)
 
+obj-c++_OBJS = $(OBJCXX_OBJS) cc1objplus-checksum.o
+
 cc1objplus-dummy$(exeext): $(OBJCXX_OBJS) dummy-checksum.o $(BACKEND) \
 		$(LIBDEPS)
 	$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \

Re: Improving parallel build

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

Ralf> Sequential bootstrap of all languages is running.
Ralf> OK for trunk if that passes?  OK if I apply this or would you like to,
Ralf> Tom?

I think you should be the one.

Tom

Re: Improving parallel build

[Richard Guenther]

On Mon, Mar 31, 2008 at 9:18 PM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> * Tom Tromey wrote on Sun, Mar 30, 2008 at 08:04:30PM CEST:
>
>
> > >>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>  >
>  > Ralf> I'm wondering whether I should just retract the patch, for safety.
>  >
>  > A simple patch like this that helps build times is pretty appealing.
>  > Personally I'd prefer to give it a shot.  We can always back it out
>  > again if we run into trouble.
>
>  OK, here's the patch redone in terms of your automatic dependency patch.
>  What's really funny is that it's almost a strict subset of your patch
>  (modulo reordering in Makefile.in, copyright year updates, merging in
>  the obj-c++ typo patch, and documentation), which is why I haven't put
>  my name on most ChangeLog entries.  So there is some benefit from all
>  your work.  :-)
>
>  The patch passed parallel bootstrap of languages != ada, obj-c++,
>  giving virtually the same speedup, and passed the
>   touch $top_srcdir/gcc/Makefile.in && make -j2 cc1

Btw, it looks like target libraries are checked non-parallel!?  (I
have the imagination
that this changed recently)  Thus, a 'make -k -j8 check' in the toplevel does
check-gcc in parallel but then serially tests libstdc++, libmudflap,
libffi, libjava, etc.

Did this really change? ...

Thanks,
Richard.

Re: Improving parallel build

[Ralf Wildenhues]

* Richard Guenther wrote on Wed, Apr 02, 2008 at 12:47:26AM CEST:
> 
> Btw, it looks like target libraries are checked non-parallel!?  (I
> have the imagination that this changed recently)

See <http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00128.html>.

Cheers,
Ralf

Re: Improving parallel build

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Mon, Mar 31, 2008 at 09:18:34PM CEST:
> 
> Sequential bootstrap of all languages is running.
> OK for trunk if that passes?

It passed.  I assume I do need reapproval for this patch?  So, OK?

Thanks,
Ralf

> gcc/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 	    Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> 
> 	* config/m68k/t-uclinux (generated_files): Add sysroot-suffix.h.
> 	* config/bfin/t-bfin-linux (generated_files): Add
> 	linux-sysroot-suffix.h.
> 	* doc/install.texi (Prerequisites): Require make 3.80.
> 	* doc/sourcebuild.texi (Front End Directory): Document new
> 	variable.
> 	* Makefile.in (generated_files): New variable.
> 	(ALL_HOST_OBJS): New variable.
> 	($(ALL_HOST_OBJS)): New target.
> 
> gcc/java/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 
> 	* Make-lang.in (java_OBJS): New variable.
> 
> gcc/objc/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 
> 	* Make-lang.in (objc_OBJS): New variable.
> 
> gcc/objcp/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 
> 	* Make-lang.in (obj-c++_OBJS): New variable.
> 
> gcc/cp/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 
> 	* Make-lang.in (c++_OBJS): New variable.
> 
> gcc/fortran/ChangeLog:
> 2008-03-31  Tom Tromey  <tromey@redhat.com>
> 
> 	* Make-lang.in (fortran_OBJS): New variable.

Re: Improving parallel build

[Paolo Bonzini]

Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Mon, Mar 31, 2008 at 09:18:34PM CEST:
>> Sequential bootstrap of all languages is running.
>> OK for trunk if that passes?
> 
> It passed.  I assume I do need reapproval for this patch?  So, OK?

Yes.

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Mark Mitchell]

Kaveh R. GHAZI wrote:

> I think a middle ground could be that we enable building objc++ by
> default, but not run its testsuite unless it is specifically enabled.

I'm mildly opposed, but not so much so that I would make much of an 
argument for it.

> It certainly wouldn't be "adding hours" to everyone's test cycle.

I agree.  That comment was meant to refer to the possibility of adding 
all of Ada, Java, Fortran, etc. to all build/test cycles.  I see 
Objective-C++ as a pretty minor issue; neither the costs nor benefits 
are terribly great.  Some of the other languages are more widely used, 
but also more expensive to build/test.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Thu, Mar 27, 2008 at 11:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Kaveh R. GHAZI wrote:
>
>  > I think a middle ground could be that we enable building objc++ by
>  > default, but not run its testsuite unless it is specifically enabled.
>
>  I'm mildly opposed, but not so much so that I would make much of an
>  argument for it.
>
>
>  > It certainly wouldn't be "adding hours" to everyone's test cycle.
>
>  I agree.  That comment was meant to refer to the possibility of adding
>  all of Ada, Java, Fortran, etc. to all build/test cycles.  I see
>  Objective-C++ as a pretty minor issue; neither the costs nor benefits
>  are terribly great.  Some of the other languages are more widely used,
>  but also more expensive to build/test.

Obj-C++ is certainly not a problem.  Java and Fortran are already part of all
build/test cycles, libjava being a huge memory eater.  Ada isn't too bad and
I tend to include it for middle-end patches (after all I can remember "ada",
but most of the time misspell obj-c++(?) as objcp or objc++(?)).

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Thu, Mar 27, 2008 at 11:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Kaveh R. GHAZI wrote:
>
>  > I think a middle ground could be that we enable building objc++ by
>  > default, but not run its testsuite unless it is specifically enabled.
>
>  I'm mildly opposed, but not so much so that I would make much of an
>  argument for it.
>
>
>  > It certainly wouldn't be "adding hours" to everyone's test cycle.
>
>  I agree.  That comment was meant to refer to the possibility of adding
>  all of Ada, Java, Fortran, etc. to all build/test cycles.  I see
>  Objective-C++ as a pretty minor issue; neither the costs nor benefits
>  are terribly great.  Some of the other languages are more widely used,
>  but also more expensive to build/test.

Obj-C++ is certainly not a problem.  Java and Fortran are already part of all
build/test cycles, libjava being a huge memory eater.  Ada isn't too bad and
I tend to include it for middle-end patches (after all I can remember "ada",
but most of the time misspell obj-c++(?) as objcp or objc++(?)).

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

On Thu, Mar 27, 2008 at 3:49 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>  Obj-C++ is certainly not a problem.  Java and Fortran are already part of all
>  build/test cycles, libjava being a huge memory eater.

libstdc++ testing is also a huge memory eater.  I ran into swapping
while it is running all the time.

-- Pinski

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Mark Mitchell]

Richard Guenther wrote:

> Obj-C++ is certainly not a problem.  Java and Fortran are already part of all
> build/test cycles, libjava being a huge memory eater.

Is that a good thing?  I've done little middle-end work, so I don't have 
much experience with this.  How often does a change to the optimizers 
pass all of the C/C++ testsuites, but fail in the Java or Fortran 
testsuites?

These aren't rhetorical questions; I have no idea.  I'm interested in 
what actual experience is like here.  My guess would be that changes to 
the build machinery are quite likely to break various languages, but 
that changes to (say) the register allocator are unlikely to work 
reliably in C/C++, but not in Fortran/Java.  And, that, in fact, Ada is 
the language other than C/C++ most likely to show up problems.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

On Thu, Mar 27, 2008 at 3:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>  These aren't rhetorical questions; I have no idea.  I'm interested in
>  what actual experience is like here.  My guess would be that changes to
>  the build machinery are quite likely to break various languages, but
>  that changes to (say) the register allocator are unlikely to work
>  reliably in C/C++, but not in Fortran/Java.  And, that, in fact, Ada is
>  the language other than C/C++ most likely to show up problems.

Examples of where I have had issues:
Changing complex types, Fortran, Ada, and C++ show up more issues than
C testing, more in Fortran than anywhere else really.

Inlining changes: Ada, C and C++ show more issues than Fortran.

For Pointer Plus, C++ was the hardest one to convert, it was full of
pointer arithmetic all the place.

For PHI_NODE memory reduction, C++ and Fortran showed the issue which
did not show up in C.

Vector changes, not tested that well at all even with the auto
vectorizer testsuite (tested locally on most of the internal sources
here at Sony).

Thanks,
Andrew Pinski

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Mark Mitchell]

Andrew Pinski wrote:
> On Thu, Mar 27, 2008 at 3:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>>  These aren't rhetorical questions; I have no idea.  I'm interested in
>>  what actual experience is like here.  My guess would be that changes to
>>  the build machinery are quite likely to break various languages, but
>>  that changes to (say) the register allocator are unlikely to work
>>  reliably in C/C++, but not in Fortran/Java.  And, that, in fact, Ada is
>>  the language other than C/C++ most likely to show up problems.
> 
> Examples of where I have had issues:

This is useful data.  It would seem to suggest that C/C++ testing would 
have caught most of your problems, with the exception of the 
complex-number testing, where you found Fortran testing to be most 
effective.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

On Thu, Mar 27, 2008 at 4:35 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>  This is useful data.  It would seem to suggest that C/C++ testing would
>  have caught most of your problems, with the exception of the
>  complex-number testing, where you found Fortran testing to be most
>  effective.

For me, yes but this was just from memory and is not exactly the full
truth.  As I was touching in most cases the front-ends, I needed to
test them anyways so just testing C/C++ was not the correct thing to
do really.  Also sometimes you never know which front-end's testsuite
will produce a problem with the patch you are working on; you can
estimate but this is never a good idea. Also why are we complaining
about testing times?

I rather we have more testing than less when it comes to testing the
compiler.  Everytime I see a bug, I always try to add a testcase.  But
sometimes bugs show up only because the IR that is produced by one
specific front-end.  How do you know if you change that code, it will
not break the corner case you just found?  I am against not requiring
testing of the Fortran or Ada or Objective-C or Java front-ends for
middle end or target changes.  They found useful bugs and in some
cases you can add a C testcase for the same issue (I have tried doing
that in some cases).  Yes running only the C testsuite simplifies
testing but that should only be done during the development of the
patch and you should do a full bootstrap and test before submitting.
I usually start a full bootstrap/test before I go bed or leave for the
day so I have the results in the morning.  Most of the time I don't
find issues but when I do, I go back and look at them and look at why
the C testsuite was not testing it.  I think this comes down to how
people develop, and we should not force a development mechanism on
them except when they are ready to submit the patch and only then we
can say how did you test it.

I have a feeling that this thread has gone way off topic and should
start a new one about testing before submitting.

-- Pinski

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Thu, Mar 27, 2008 at 11:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
>  > Obj-C++ is certainly not a problem.  Java and Fortran are already part of all
>  > build/test cycles, libjava being a huge memory eater.
>
>  Is that a good thing?  I've done little middle-end work, so I don't have
>  much experience with this.  How often does a change to the optimizers
>  pass all of the C/C++ testsuites, but fail in the Java or Fortran
>  testsuites?
>
>  These aren't rhetorical questions; I have no idea.  I'm interested in
>  what actual experience is like here.  My guess would be that changes to
>  the build machinery are quite likely to break various languages, but
>  that changes to (say) the register allocator are unlikely to work
>  reliably in C/C++, but not in Fortran/Java.  And, that, in fact, Ada is
>  the language other than C/C++ most likely to show up problems.

Sadly it happens often enough that only libjava or java testing is affected
by a patch.  Likewise Fortran is often special in the kinds of IL produced.
Ada testing doesn't show failures most of the time, but it excercises parts
of the middle-end no other frontend does.

So they are all useful in that coverage of the C and C++ testsuite isn't
good enough to catch even obvious problems sometimes.

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Paolo Bonzini]

> It was disabled when tree-ssa was merged, because it wasn't ready for 
> tree-ssa at that time.  I'm not aware of any policy decision to disable 
> it, just what should have been temporary disabling until a problem was 
> fixed; I think we should enable it by default again, while still allowing 
> people not to test patches with Ada since they may not have bootstrap Ada 
> compilers.

Not to mention, that the old issue that required you to "make 
gnatlib_and_tools" before "make install" (otherwise you'd screw up an 
existing GNAT install) is gone.

Paolo

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[FX Coudert]

Hi,

I'm adding a little comment here:

> Inlining changes: Ada, C and C++ show more issues than Fortran.

More inlining opportunities are expected in Fortran when the multiple- 
decls-per-function issue is fixed (I'm working on it for 4.4). I  
don't know if it will make us on par with other languages.

Another comment: my feeling is that the Fortran front-end and  
testsuite have exposed quite a few tree-optimization regressions  
during 4.2 and 4.3 development. I'm wondering what are the times of  
the different testsuites (C, C++, Fortran, Java); from my feeling (as  
front-end maintainer, I don't often test C, rarely C++, and almost  
never Java), C++ and Java are the major resource eaters.

FX


-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Dominique Dhumieres]

I have opened pr35704 this morning, though my summary was not explicit
enough. The patch fixed the bootstrap issue for me.

Dominique

[C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Doug Gregor]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

My SFINAE patch to the C++ front end broke the Objective-C++ front
end. This patch fixes the problem, which involves some renaming of
routines in the C++ front end as well as minor fixes to the
Objective-C++ front end. Okay for mainline?

  - Doug

2008-03-25  Douglas Gregor  <doug.gregor@gmail.com>

	* typeck.c (build_x_compound_expr): Use cp_build_compound_expr.
	(build_compound_expr): New, for compatibility with C
	build_compound_expr.
	(cp_build_compound_expr): Renamed from build_compound_expr.
	(build_c_cast): New, for compatibility with C build_c_cast.
	(cp_build_c_cast): Renamed from build_c_cast.
	* init.c (build_vec_delete_1): Fix calls to build_compound_expr.
	* decl.c (cxx_maybe_build_cleanup): Ditto.
	* cp-tree.h (build_compound_expr): Add C-compatibile prototype.
	(cp_build_compound_expr): Renamed from build_compound_expr.
	(build_c_cast): Add C-compatible prototype.
	(cp_build_c_cast): Renamed from build_c_cast.
	* typeck2.c (build_functional_cast): Use cp_build_c_cast.
	* parser.c (cp_parser_cast_expression): Fix call to build_c_cast.

2008-03-25  Douglas Gregor  <doug.gregor@gmail.com>

	* objc-act.c (objc_build_component_ref): Fix call to
	finish_class_member_access_expr.
	(objc_generate_cxx_ctor_or_dtor): Fix call to
	build_special_member_call.

[-- Attachment #2: sfinae-339-objc.patch --]
[-- Type: application/octet-stream, Size: 7113 bytes --]

Index: cp/typeck.c
===================================================================
--- cp/typeck.c	(revision 133519)
+++ cp/typeck.c	(working copy)
@@ -5037,7 +5037,7 @@ build_x_compound_expr (tree op1, tree op
   result = build_new_op (COMPOUND_EXPR, LOOKUP_NORMAL, op1, op2, NULL_TREE,
 			 /*overloaded_p=*/NULL, complain);
   if (!result)
-    result = build_compound_expr (op1, op2, complain);
+    result = cp_build_compound_expr (op1, op2, complain);
 
   if (processing_template_decl && result != error_mark_node)
     return build_min_non_dep (COMPOUND_EXPR, result, orig_op1, orig_op2);
@@ -5045,10 +5045,18 @@ build_x_compound_expr (tree op1, tree op
   return result;
 }
 
+/* Like cp_build_compound_expr, but for the c-common bits.  */
+
+tree
+build_compound_expr (tree lhs, tree rhs)
+{
+  return cp_build_compound_expr (lhs, rhs, tf_warning_or_error);
+}
+
 /* Build a compound expression.  */
 
 tree
-build_compound_expr (tree lhs, tree rhs, tsubst_flags_t complain)
+cp_build_compound_expr (tree lhs, tree rhs, tsubst_flags_t complain)
 {
   lhs = convert_to_void (lhs, "left-hand operand of comma", complain);
 
@@ -5775,11 +5783,19 @@ build_const_cast (tree type, tree expr, 
 			     /*valid_p=*/NULL);
 }
 
+/* Like cp_build_c_cast, but for the c-common bits.  */
+
+tree
+build_c_cast (tree type, tree expr)
+{
+  return cp_build_c_cast (type, expr, tf_warning_or_error);
+}
+
 /* Build an expression representing an explicit C-style cast to type
    TYPE of expression EXPR.  */
 
 tree
-build_c_cast (tree type, tree expr, tsubst_flags_t complain)
+cp_build_c_cast (tree type, tree expr, tsubst_flags_t complain)
 {
   tree value = expr;
   tree result;
@@ -6466,7 +6482,7 @@ build_ptrmemfunc (tree type, tree pfn, i
   /* Handle null pointer to member function conversions.  */
   if (integer_zerop (pfn))
     {
-      pfn = build_c_cast (type, integer_zero_node, tf_warning_or_error);
+      pfn = build_c_cast (type, integer_zero_node);
       return build_ptrmemfunc1 (to_type,
 				integer_zero_node,
 				pfn);
Index: cp/init.c
===================================================================
--- cp/init.c	(revision 133519)
+++ cp/init.c	(working copy)
@@ -2528,15 +2528,13 @@ build_vec_delete_1 (tree base, tree maxi
   body = build_compound_expr
     (body, cp_build_modify_expr (tbase, NOP_EXPR,
 				 build2 (POINTER_PLUS_EXPR, ptype, tbase, tmp),
-				 tf_warning_or_error),
-     tf_warning_or_error);
+				 tf_warning_or_error));
   body = build_compound_expr
     (body, build_delete (ptype, tbase, sfk_complete_destructor,
-			 LOOKUP_NORMAL|LOOKUP_DESTRUCTOR, 1),
-     tf_warning_or_error);
+			 LOOKUP_NORMAL|LOOKUP_DESTRUCTOR, 1));
 
   loop = build1 (LOOP_EXPR, void_type_node, body);
-  loop = build_compound_expr (tbase_init, loop, tf_warning_or_error);
+  loop = build_compound_expr (tbase_init, loop);
 
  no_destructor:
   /* If the delete flag is one, or anything else with the low bit set,
@@ -2582,7 +2580,7 @@ build_vec_delete_1 (tree base, tree maxi
   else if (!body)
     body = deallocate_expr;
   else
-    body = build_compound_expr (body, deallocate_expr, tf_warning_or_error);
+    body = build_compound_expr (body, deallocate_expr);
 
   if (!body)
     body = integer_zero_node;
Index: cp/decl.c
===================================================================
--- cp/decl.c	(revision 133519)
+++ cp/decl.c	(working copy)
@@ -12229,7 +12229,7 @@ cxx_maybe_build_cleanup (tree decl)
       call = build_delete (TREE_TYPE (addr), addr,
 			   sfk_complete_destructor, flags, 0);
       if (cleanup)
-	cleanup = build_compound_expr (cleanup, call, tf_warning_or_error);
+	cleanup = build_compound_expr (cleanup, call);
       else
 	cleanup = call;
     }
Index: cp/cp-tree.h
===================================================================
--- cp/cp-tree.h	(revision 133519)
+++ cp/cp-tree.h	(working copy)
@@ -4804,11 +4804,13 @@ extern tree build_x_conditional_expr		(t
                                                  tsubst_flags_t);
 extern tree build_x_compound_expr_from_list	(tree, const char *);
 extern tree build_x_compound_expr		(tree, tree, tsubst_flags_t);
-extern tree build_compound_expr			(tree, tree, tsubst_flags_t);
+extern tree build_compound_expr                 (tree, tree);
+extern tree cp_build_compound_expr		(tree, tree, tsubst_flags_t);
 extern tree build_static_cast			(tree, tree, tsubst_flags_t);
 extern tree build_reinterpret_cast		(tree, tree, tsubst_flags_t);
 extern tree build_const_cast			(tree, tree, tsubst_flags_t);
-extern tree build_c_cast			(tree, tree, tsubst_flags_t);
+extern tree build_c_cast			(tree, tree);
+extern tree cp_build_c_cast			(tree, tree, tsubst_flags_t);
 extern tree build_x_modify_expr			(tree, enum tree_code, tree,
 						 tsubst_flags_t);
 extern tree cp_build_modify_expr		(tree, enum tree_code, tree,
Index: cp/typeck2.c
===================================================================
--- cp/typeck2.c	(revision 133519)
+++ cp/typeck2.c	(working copy)
@@ -1342,7 +1342,7 @@ build_functional_cast (tree exp, tree pa
 
       /* This must build a C cast.  */
       parms = build_x_compound_expr_from_list (parms, "functional cast");
-      return build_c_cast (type, parms, complain);
+      return cp_build_c_cast (type, parms, complain);
     }
 
   /* Prepare to evaluate as a call to a constructor.  If this expression
@@ -1363,7 +1363,7 @@ build_functional_cast (tree exp, tree pa
      conversion is equivalent (in definedness, and if defined in
      meaning) to the corresponding cast expression.  */
   if (parms && TREE_CHAIN (parms) == NULL_TREE)
-    return build_c_cast (type, TREE_VALUE (parms), complain);
+    return cp_build_c_cast (type, TREE_VALUE (parms), complain);
 
   /* [expr.type.conv]
 
Index: cp/parser.c
===================================================================
--- cp/parser.c	(revision 133519)
+++ cp/parser.c	(working copy)
@@ -5880,7 +5880,7 @@ cp_parser_cast_expression (cp_parser *pa
 	    return error_mark_node;
 
 	  /* Perform the cast.  */
-	  expr = build_c_cast (type, expr, tf_warning_or_error);
+	  expr = build_c_cast (type, expr);
 	  return expr;
 	}
     }
Index: objc/objc-act.c
===================================================================
--- objc/objc-act.c	(revision 133518)
+++ objc/objc-act.c	(working copy)
@@ -1255,7 +1255,8 @@ objc_build_component_ref (tree datum, tr
      front-end, but 'finish_class_member_access_expr' seems to be
      a worthy substitute.  */
 #ifdef OBJCPLUS
-  return finish_class_member_access_expr (datum, component, false);
+  return finish_class_member_access_expr (datum, component, false,
+                                          tf_warning_or_error);
 #else
   return build_component_ref (datum, component);
 #endif
@@ -4493,7 +4494,7 @@ objc_generate_cxx_ctor_or_dtor (bool dto
 	     (build_special_member_call
 	      (build_ivar_reference (DECL_NAME (ivar)),
 	       dtor ? complete_dtor_identifier : complete_ctor_identifier,
-	       NULL_TREE, type, LOOKUP_NORMAL));
+	       NULL_TREE, type, LOOKUP_NORMAL, tf_warning_or_error));
 	}
     }
 

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Andrew Pinski]

On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> My SFINAE patch to the C++ front end broke the Objective-C++ front
> end. This patch fixes the problem, which involves some renaming of
> routines in the C++ front end as well as minor fixes to the
> Objective-C++ front end. Okay for mainline?

This is the third bootstrap failure for Objective-C++ in less than two
weeks.  I think it is either time to require Objective-C++ building or
decide we should remove it.

-- Pinski

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
>  > My SFINAE patch to the C++ front end broke the Objective-C++ front
>  > end. This patch fixes the problem, which involves some renaming of
>  > routines in the C++ front end as well as minor fixes to the
>  > Objective-C++ front end. Okay for mainline?
>
>  This is the third bootstrap failure for Objective-C++ in less than two
>  weeks.  I think it is either time to require Objective-C++ building or
>  decide we should remove it.

I agree.  It is too tightly coupled to common C/C++ code to be not
enabled by default if it stays in.  But you can add a +1 for the voting count
for removing the ObjC++ frontend.

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[NightStrike]

On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> >  > My SFINAE patch to the C++ front end broke the Objective-C++ front
> >  > end. This patch fixes the problem, which involves some renaming of
> >  > routines in the C++ front end as well as minor fixes to the
> >  > Objective-C++ front end. Okay for mainline?
> >
> >  This is the third bootstrap failure for Objective-C++ in less than two
> >  weeks.  I think it is either time to require Objective-C++ building or
> >  decide we should remove it.
>
> I agree.  It is too tightly coupled to common C/C++ code to be not
> enabled by default if it stays in.  But you can add a +1 for the voting count
> for removing the ObjC++ frontend.

Why do you want to remove the frontend?

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Richard Guenther]

On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
>
> On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
>  > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>  > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
>  > >  > My SFINAE patch to the C++ front end broke the Objective-C++ front
>  > >  > end. This patch fixes the problem, which involves some renaming of
>  > >  > routines in the C++ front end as well as minor fixes to the
>  > >  > Objective-C++ front end. Okay for mainline?
>  > >
>  > >  This is the third bootstrap failure for Objective-C++ in less than two
>  > >  weeks.  I think it is either time to require Objective-C++ building or
>  > >  decide we should remove it.
>  >
>  > I agree.  It is too tightly coupled to common C/C++ code to be not
>  > enabled by default if it stays in.  But you can add a +1 for the voting count
>  > for removing the ObjC++ frontend.
>
>  Why do you want to remove the frontend?

Because it is basically unmaintained.

Richard.

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Doug Gregor]

On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
>  >
>  > On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
>  >  > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>  >  > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
>  >  > >  > My SFINAE patch to the C++ front end broke the Objective-C++ front
>  >  > >  > end. This patch fixes the problem, which involves some renaming of
>  >  > >  > routines in the C++ front end as well as minor fixes to the
>  >  > >  > Objective-C++ front end. Okay for mainline?
>  >  > >
>  >  > >  This is the third bootstrap failure for Objective-C++ in less than two
>  >  > >  weeks.  I think it is either time to require Objective-C++ building or
>  >  > >  decide we should remove it.
>  >  >
>  >  > I agree.  It is too tightly coupled to common C/C++ code to be not
>  >  > enabled by default if it stays in.  But you can add a +1 for the voting count
>  >  > for removing the ObjC++ frontend.
>  >
>  >  Why do you want to remove the frontend?
>
>  Because it is basically unmaintained.

Which means I don't even know whether I can commit this patch to *fix*
the front end or not. I'll give it 24 more hours, and commit if I
don't hear any screams.

  - Doug

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Kaveh R. GHAZI]

On Wed, 26 Mar 2008, Doug Gregor wrote:

> On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> >
> > On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
> >  >
> >  > On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> >  >  > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> >  >  > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> >  >  > >  > My SFINAE patch to the C++ front end broke the Objective-C++ front
> >  >  > >  > end. This patch fixes the problem, which involves some renaming of
> >  >  > >  > routines in the C++ front end as well as minor fixes to the
> >  >  > >  > Objective-C++ front end. Okay for mainline?
> >  >  > >
> >  >  > >  This is the third bootstrap failure for Objective-C++ in less than two
> >  >  > >  weeks.  I think it is either time to require Objective-C++ building or
> >  >  > >  decide we should remove it.
> >  >  >
> >  >  > I agree.  It is too tightly coupled to common C/C++ code to be not
> >  >  > enabled by default if it stays in.  But you can add a +1 for the voting count
> >  >  > for removing the ObjC++ frontend.
> >  >
> >  >  Why do you want to remove the frontend?
> >
> >  Because it is basically unmaintained.
>
> Which means I don't even know whether I can commit this patch to *fix*
> the front end or not. I'll give it 24 more hours, and commit if I
> don't hear any screams.
>   - Doug

Actually we do have a maintainer, Stan would you please take a look?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Tom Tromey]

>>>>> "Andrew" == Andrew Pinski <pinskia@gmail.com> writes:

Andrew> This is the third bootstrap failure for Objective-C++ in less
Andrew> than two weeks.  I think it is either time to require
Andrew> Objective-C++ building or decide we should remove it.

FWIW, I agree.

Tom

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Stan Shebs]

Andrew Pinski wrote:
> On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
>   
>> My SFINAE patch to the C++ front end broke the Objective-C++ front
>> end. This patch fixes the problem, which involves some renaming of
>> routines in the C++ front end as well as minor fixes to the
>> Objective-C++ front end. Okay for mainline?
>>     
>
> This is the third bootstrap failure for Objective-C++ in less than two
> weeks.  I think it is either time to require Objective-C++ building or
> decide we should remove it.
>   
So I must be missing something, because I've bootstrapped it several 
times in the past couple weeks, and didn't see any breakage. Do I need 
to be monitoring a particular list, or on irc, or bootstrapping every 
day, or what?

Stan

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Kaveh R. GHAZI]

On Wed, 26 Mar 2008, Stan Shebs wrote:

> Andrew Pinski wrote:
> > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> >
> >> My SFINAE patch to the C++ front end broke the Objective-C++ front
> >> end. This patch fixes the problem, which involves some renaming of
> >> routines in the C++ front end as well as minor fixes to the
> >> Objective-C++ front end. Okay for mainline?
> >>
> >
> > This is the third bootstrap failure for Objective-C++ in less than two
> > weeks.  I think it is either time to require Objective-C++ building or
> > decide we should remove it.
> >
> So I must be missing something, because I've bootstrapped it several
> times in the past couple weeks, and didn't see any breakage. Do I need
> to be monitoring a particular list, or on irc, or bootstrapping every
> day, or what?
> Stan

IMHO, you shouldn't have to notice and/or clean up other people's breakage
after the fact.  Since objc++ has you as a maintainer, IMHO we should turn
it on by default. Then instead of fixing breakage, you could work through
some of the objc++ bugzilla entries. :-)
http://tinyurl.com/36m46m

Here's one showing objc++, objc and libobjc:
http://tinyurl.com/3aanju

I think showing progress on this front would help establish that objc++ is
actively maintained and strengthen the argument to put it in the default
bootstrap list.  Stan, are you able to contribute on this front?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage

[Stan Shebs]

Doug Gregor wrote:
> My SFINAE patch to the C++ front end broke the Objective-C++ front
> end. This patch fixes the problem, which involves some renaming of
> routines in the C++ front end as well as minor fixes to the
> Objective-C++ front end. Okay for mainline?
>   
Yes, this looks fine. Sorry to take a day to get to it - hadn't sunk in 
that it was breaking builds. :-)

Stan