Re: C++ warnings vs. errors
On Thu, Jun 19, 2008 at 5:08 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> 2008/6/18 Mark Mitchell:
>>> * I don't think the pedwarn in joust() in cp/call.c should be a
>>> permerror, is this a GNU extension?
>>> if (warn)
>>>{
>>> pedwarn ("\
>>> ISO C++ says that these are ambiguous, even \
>>> though the worst conversion for the first is better than \
>>> the worst conversion for the second:");
>>> print_z_candidate (_("candidate 1:"), w);
>>> print_z_candidate (_("candidate 2:"), l);
>>>}
>>
>> Yes, that is a historical GNU extension. I think this should just be a
>> warning, given that the whole section of code is guarded with !pedantic.
>
> OK. Should I also get rid of the escaped newlines and rely on string
> concatenation for the text?
yes, please.
>
> Jon
>
>
>
>
>>> * I don't know if these in cp/typeck.c should be permerrors, DTRT
>>> implies not, but should tf_error be changed to tf_warning?
>>
>> I think "DTRT" here means "do what whoever wrote this code thinks the
>> standard should say" not "do what the standard says". Please make these
>> permerrors.
>>
>> Thanks,
>>
>> --
>> Mark Mitchell
>> CodeSourcery
>> [EMAIL PROTECTED]
>> (650) 331-3385 x713
>>
>>
>
Re: Should we remove java from the default bootstrap languages?
Tom Tromey wrote: >> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes: > >>> We could look into this. The minimum subset is probably several >>> hundred classes. For instance, Class refers to URL, which will >>> probably pull in most of java.net. > > Florian> Can't you fallback to the interpreter for the URL class? > > We prefer to build most of the core without -findirect-dispatch, > because it yields better performance. This means that all the direct > dependencies must be compiled and linked in. > > Of course we could try to change this. No. It would cause all manner of problems at startup; not worth it. Andrew.
Re: C++ warnings vs. errors
Jonathan Wakely wrote: Thanks for the review, here's another patch ... Shall I commit this? Yes, please. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Should we remove java from the default bootstrap languages?
On Fri, 20 Jun 2008, Tom Tromey wrote: > Andrew> My suggestion is that we build jc1 but not libgcj by default. > Andrew> HOWEVER, we build libgcj on the autobuilders and make very sure that > Andrew> if anyone breaks the libgcj build they have to fix their breakage, > Andrew> even tho it's not part of the default build. That will prevent most > Andrew> of the bitrot while we figure out how to go forward. > > Good idea. > > Maybe instead of removing libgcj from the default builds, we can just > say that maintainers can --disable-libjava for regression testing > purposes. This would make testers continue to test libgcj by default. > Tom Ugh, I think this is a terrible idea. It took me all of zero days to find an example of libjava breaking when someone didn't test it: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html If we make not testing java an actual policy, you can expect much more breakage. Things that aren't tested suffer bitrot, plain and simple. That aside, our current policy already allows e.g. not testing java if your change is to a part of the compiler that can't possible affect it. E.g. changing the fortran or ada frontends doesn't affect java. But IMHO we shouldn't relax the testing rules for the overlapping parts if we want to keep our bits all working nicely. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > That aside, our current policy already allows e.g. not testing java if > your change is to a part of the compiler that can't possible affect it. I didn't make it completely clear, but my suggestion was mostly to help us middle/back-end hackers. Diego.
Re: Should we remove java from the default bootstrap languages?
On Fri, 20 Jun 2008, Diego Novillo wrote: > On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > > > That aside, our current policy already allows e.g. not testing java if > > your change is to a part of the compiler that can't possible affect it. > > I didn't make it completely clear, but my suggestion was mostly to > help us middle/back-end hackers. > Diego. Yeah, that's what worries me, all roads lead through the middle-end. :-) --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote: > On Fri, 20 Jun 2008, Diego Novillo wrote: > > > On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > > > > > That aside, our current policy already allows e.g. not testing java if > > > your change is to a part of the compiler that can't possible affect it. > > > > I didn't make it completely clear, but my suggestion was mostly to > > help us middle/back-end hackers. > > Diego. > > Yeah, that's what worries me, all roads lead through the middle-end. :-) But if I understood the proposal correctly, auto-testers (as well as Java developers) would continue to test Java on a daily basis, and anyone submitting a patch that caused breakage would be responsible for fixing the damage or reverting. If problems are always detected within one day, the opportunities for rot are limited. Beyond that I wouldn't venture an opinion on whether it's the right thing.
Re: Should we remove java from the default bootstrap languages?
On Fri, Jun 20, 2008 at 11:16 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > On Fri, 20 Jun 2008, Diego Novillo wrote: > >> On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: >> >> > That aside, our current policy already allows e.g. not testing java if >> > your change is to a part of the compiler that can't possible affect it. >> >> I didn't make it completely clear, but my suggestion was mostly to >> help us middle/back-end hackers. >> Diego. > > Yeah, that's what worries me, all roads lead through the middle-end. :-) What is far more worrying to me, actually, is that libjava grows bigger and bigger and bigger with every release, so that testing it costs developers who care zilch about java (i.e. most people) get penalized more and more with increased bootstrap and test times. In my latest timings, building and testing java takes close to two thirds of the total bootstrap+test time with all default languages enabled. That's a lot for a practically unused library and front end. It is the limiting time factor for me, at least, when doing gcc development. Things would be so much better for me if we'd only test a subset of libjava by default... *sigh* Gr. Steven
Re: Should we remove java from the default bootstrap languages?
From: "Steven Bosscher" <[EMAIL PROTECTED]> Date: Sat, 21 Jun 2008 00:09:26 +0200 > What is far more worrying to me, actually, is that libjava grows > bigger and bigger and bigger with every release, so that testing it > costs developers who care zilch about java (i.e. most people) get > penalized more and more with increased bootstrap and test times. I agree and will admit that this is the one thing that has curtailed severely my contributions to GCC in the past 4 to 5 years. I used to be able to bootstrap gcc fully in minutes on average hardware 6 or so years ago. Those days are long gone. On my largest 64 cpu and 128 cpu boxes it takes forever these days. The libjava build is notoriously not helped by parallelization because certain compiles are extremely expensive, which effectively single-threads the build.
Re: Should we remove java from the default bootstrap languages?
From: "Joe Buck" <[EMAIL PROTECTED]> On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote: On Fri, 20 Jun 2008, Diego Novillo wrote: > On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> > wrote: > > > That aside, our current policy already allows e.g. not testing java > > if > > your change is to a part of the compiler that can't possible affect > > it. > > I didn't make it completely clear, but my suggestion was mostly to > help us middle/back-end hackers. > Diego. Yeah, that's what worries me, all roads lead through the middle-end. :-) But if I understood the proposal correctly, auto-testers (as well as Java developers) would continue to test Java on a daily basis, and anyone submitting a patch that caused breakage would be responsible for fixing the damage or reverting. If problems are always detected within one day, the opportunities for rot are limited. Fundamentally, our philosophy has been to catch errors *before* they get into the repository. Sure one day of breaking the trunk isn't so bad, but when it breaks it affects hundreds of developers and it adds up. Everyone separately either stops and waits, or tracks down which patch it was and reverts it so they can continue working. Either way lots of time is wasted, and this serves as a counter argument against the time spent testing patches with java enabled. I suspect some people run their tests overnight, in that case it doesn't matter if the regtest takes 2 hours or 5. Either way the results will be waiting for you in the morning. I don't like the idea of taking java out, but if we do I suggest we swap in objc++. That would only add 42 seconds to the bootstrap and test process. :-) http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01763.html --Kaveh
gcc-4.4-20080620 is now available
Snapshot gcc-4.4-20080620 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080620/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 136993 You'll find: gcc-4.4-20080620.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080620.tar.bz2 C front end and core compiler gcc-ada-4.4-20080620.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080620.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080620.tar.bz2 C++ front end and runtime gcc-java-4.4-20080620.tar.bz2 Java front end and runtime gcc-objc-4.4-20080620.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080620.tar.bz2The GCC testsuite Diffs from 4.4-20080613 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Should we remove java from the default bootstrap languages?
> Fundamentally, our philosophy has been to catch errors *before* they get > into the repository. Sure one day of breaking the trunk isn't so bad, but > when it breaks it affects hundreds of developers and it adds up. Everyone > separately either stops and waits, or tracks down which patch it was and > reverts it so they can continue working. An interesting question that I see as relevant here and for which I have no data is: what percentage of the time does a patch cause an error *only* in libjava? I think you have to weigh the cost of the build of that library against the number of bugs that it finds.
Ask for help: constraints error
I got following error after changing some GCC code, can anyone give me
some hints what's wrong here?
---
error: insn does not satisfy its constraints:
(insn:HI 690 689 1267 79 libgcc/config/libbid/bid_binarydecimal.c:146450
(parallel [
(set (mem/c:DI (plus:SI (reg:SI 2 cx [59])
(const_int -264 [0xfef8])) [1440
lC.3833+0 S8 A64])
(sign_extend:DI (reg:SI 0 ax [351])))
(clobber (reg:CC 17 flags))
(clobber (reg:SI 2 cx))
]) 123 {*extendsidi2_1} (nil))
*extendsidi2_1 is like:
(define_insn "*extendsidi2_1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=*A,r,?r,?*o")
(sign_extend:DI (match_operand:SI 1 "register_operand"
"0,0,r,r")))
(clobber (reg:CC FLAGS_REG))
(clobber (match_scratch:SI 2 "=X,X,X,&r"))]
"!TARGET_64BIT"
"#")
Thanks - Joey
Re: Ask for help: constraints error
On Sat, Jun 21, 2008 at 06:50:26AM +0800, Joey Ye wrote:
> I got following error after changing some GCC code, can anyone give me
> some hints what's wrong here?
>
> ---
> error: insn does not satisfy its constraints:
> (insn:HI 690 689 1267 79 libgcc/config/libbid/bid_binarydecimal.c:146450
> (parallel [
> (set (mem/c:DI (plus:SI (reg:SI 2 cx [59])
^^^
> (const_int -264 [0xfef8])) [1440
> lC.3833+0 S8 A64])
> (sign_extend:DI (reg:SI 0 ax [351])))
> (clobber (reg:CC 17 flags))
> (clobber (reg:SI 2 cx))
^^^
> ]) 123 {*extendsidi2_1} (nil))
I don't think you can use cx for both clobber and memory address.
H.J.
Re: Should we remove java from the default bootstrap languages?
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote: > Fundamentally, our philosophy has been to catch errors *before* they get > into the repository. Sure one day of breaking the trunk isn't so bad, but > when it breaks it affects hundreds of developers and it adds up. But, for languages that are not enabled by default, no-one is directly affected except the people who might have caused the breakage, and the people who are working on the broken part of the compiler. In the case of java, there are not hundreds but only a handful of people working on it. > I don't like the idea of taking java out, but if we do I suggest we swap in > objc++. That would only add 42 seconds to the bootstrap and test process. > :-) Exchange one unused language for another, great idea :-) I'd rather see objc++ go away completely, since Apple is clearly not keeping its promise to maintain it, and AFAIK no-one else uses this language. Gr. Steven
