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

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

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

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

[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

[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

[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

[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

[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

[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 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

[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

[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

[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

[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

[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

[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]

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: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

[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

[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: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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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

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

[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

[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

[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

[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 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

[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

[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));
 	}
     }