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

[Doug Gregor]

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 <***@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 <***@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.

[Andrew Pinski]

Post by Doug Gregor
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

[Richard Guenther]

Post by Andrew Pinski

Post by Doug Gregor
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.

[NightStrike]

Post by Richard Guenther

Post by Andrew Pinski

Post by Doug Gregor
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?

[Richard Guenther]

Post by NightStrike

Post by Richard Guenther

Post by Andrew Pinski

Post by Doug Gregor
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.

[Doug Gregor]

On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther

Post by Richard Guenther

Post by NightStrike

Post by Richard Guenther

Post by Andrew Pinski

Post by Doug Gregor
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

[Kaveh R. GHAZI]

Post by Doug Gregor
On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther

Post by Richard Guenther

Post by NightStrike

Post by Richard Guenther

Post by Andrew Pinski

Post by Doug Gregor
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 ***@caip.rutgers.edu

[Tom Tromey]

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

[Stan Shebs]

Post by Andrew Pinski

Post by Doug Gregor
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

[Kaveh R. GHAZI]

Post by Stan Shebs

Post by Andrew Pinski

Post by Doug Gregor
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 ***@caip.rutgers.edu

[Stan Shebs]

Post by Doug Gregor
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

[Dominique Dhumieres]

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

Dominique

[Steven Bosscher]

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

Post by Kaveh R. GHAZI
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

[Paolo Bonzini]

Post by Steven Bosscher
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

[Joseph S. Myers]

Post by Steven Bosscher
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.

[Mark Mitchell]

Post by Joseph S. Myers
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.

[Kaveh R. GHAZI]

Post by Mark Mitchell
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 ***@caip.rutgers.edu

[Andrew Pinski]

On Thu, Mar 27, 2008 at 3:34 PM, Kaveh R. GHAZI

Post by Kaveh R. GHAZI
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

[Richard Guenther]

Post by Kaveh R. GHAZI

Post by Mark Mitchell
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.

[Kaveh R. GHAZI]

Post by Richard Guenther

Post by Kaveh R. GHAZI

Post by Mark Mitchell
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 <***@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).

[Kaveh R. GHAZI]

Post by Kaveh R. GHAZI
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 ***@caip.rutgers.edu

[Paolo Bonzini]

Post by Kaveh R. GHAZI
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

[Richard Guenther]

Post by Paolo Bonzini

Post by Kaveh R. GHAZI
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.

[Paolo Bonzini]

Post by Richard Guenther
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

[Richard Guenther]

Post by Paolo Bonzini

Post by Richard Guenther
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.

[Andrew Pinski]

Sent from my iPhone

On Mar 28, 2008, at 6:07, "Richard Guenther"

Post by Richard Guenther

Post by Paolo Bonzini

Post by Richard Guenther
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

Post by Richard Guenther
Richard.

[Paolo Bonzini]

Post by Richard Guenther

Post by Paolo Bonzini

Post by Richard Guenther
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

[H.J. Lu]

Post by Paolo Bonzini

Post by Richard Guenther
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.

[Jakub Jelinek]

Post by Richard Guenther
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

[Ralf Wildenhues]

Post by Jakub Jelinek
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

[Ralf Wildenhues]

[ trimming Cc: list ]

Hello Richard,

Post by Richard Guenther
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.

Post by Richard Guenther
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 <***@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

[Ralf Wildenhues]

Post by Ralf Wildenhues
Otherwise, it passed bootstrap. OK for trunk?

I should add that I did not test Ada.

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

[Paolo Bonzini]

Post by Ralf Wildenhues
Otherwise, it passed bootstrap. OK for trunk?

Yep.

Paolo

[Richard Guenther]

Post by Ralf Wildenhues
[ trimming Cc: list ]
Hello Richard,

[...]

Post by Ralf Wildenhues
$ 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.

[Tom Tromey]

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

[Ralf Wildenhues]

Post by Tom Tromey
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.

Post by Tom Tromey
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

[Tom Tromey]

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

[Ralf Wildenhues]

Post by Tom Tromey
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 <***@redhat.com>
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 <***@redhat.com>

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

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

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

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

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

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

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

gcc/fortran/ChangeLog:
2008-03-31 Tom 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 ***@.

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 ***@.
@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 <***@nowt.org
# and Steven 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
+
#
# 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 <***@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 $@ \

[Tom Tromey]

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

[Richard Guenther]

Post by Ralf Wildenhues

Post by Tom Tromey
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.

[Ralf Wildenhues]

Post by Richard Guenther
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

[Ralf Wildenhues]

Post by Ralf Wildenhues
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

Post by Ralf Wildenhues
* 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.
* Make-lang.in (java_OBJS): New variable.
* Make-lang.in (objc_OBJS): New variable.
* Make-lang.in (obj-c++_OBJS): New variable.
* Make-lang.in (c++_OBJS): New variable.
* Make-lang.in (fortran_OBJS): New variable.

[Paolo Bonzini]

Post by Ralf Wildenhues

Post by Ralf Wildenhues
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

[Mark Mitchell]

Post by Kaveh R. GHAZI
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.

Post by Kaveh R. GHAZI
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,

[Richard Guenther]

Post by Mark Mitchell

Post by Kaveh R. GHAZI
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.

Post by Kaveh R. GHAZI
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.

[Andrew Pinski]

On Thu, Mar 27, 2008 at 3:49 PM, Richard Guenther

Post by Richard Guenther
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

[Mark Mitchell]

Post by Richard Guenther
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.

[Andrew Pinski]

Post by Mark Mitchell
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

[Mark Mitchell]

Post by Mark Mitchell
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.

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.

[Andrew Pinski]

Post by Mark Mitchell
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

[Richard Guenther]

Post by Mark Mitchell

Post by Richard Guenther
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.

[Paolo Bonzini]

Post by Joseph S. Myers
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

[FX Coudert]

Hi,

Post by Andrew Pinski
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