Andrew Pinski | 1 Nov 04:48 2010
Picon

Re: PATCH RFA: Do not build java by default

On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer <gerald <at> pfeifer.com> wrote:
> On Sun, 31 Oct 2010, Steven Bosscher wrote:
>> Is it possible to build and test java without all of libjava?
>
> configure --disable-libgcj.  I have been using this for my daily
> bootstraps for a while.

But it does not test java.  Since the java testsuite depends on libjava.

Thanks,
Andrew Pinski

Geert Bosch | 1 Nov 05:06 2010

Re: PATCH RFA: Do not build java by default


On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
> The argument against disabling java as a default language always was
> that there should be at least one default language that requires
> non-call exceptions. I recall testing many patches without trouble if
> I did experimental builds with just C, C++, and Fortran, only to find
> lots of java test suite failures in a complete bootstrap+test cycle.
> So the second point is, IMVHO, not really true.

Feel free to enable Ada. Builds and tests faster than Java, 
and is known to expose many more middle end bugs, including
ones that require non-call exceptions.

  -Geert

Joern Rennecke | 1 Nov 05:30 2010

Re: PATCH RFA: Do not build java by default

Quoting Geert Bosch <bosch <at> adacore.com>:

>
> On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
>> The argument against disabling java as a default language always was
>> that there should be at least one default language that requires
>> non-call exceptions. I recall testing many patches without trouble if
>> I did experimental builds with just C, C++, and Fortran, only to find
>> lots of java test suite failures in a complete bootstrap+test cycle.
>> So the second point is, IMVHO, not really true.
>
> Feel free to enable Ada. Builds and tests faster than Java,
> and is known to expose many more middle end bugs, including
> ones that require non-call exceptions.

But to get that coverage, testers will need to have gnat installed.
Will that become a requirement for middle-end patch regression testing?

eric | 1 Nov 09:46 2010
Picon
Picon

Re: [Bulk] Re: your (or Stroustrup) chapter.12.3.cpp (and 12.7.2.cpp)can not compile on my ubuntu/linux10.03

On Sun, 2010-10-31 at 21:48 -0700, C.W. Holeman II wrote:
> You might try:
> 
> http://groups.google.com/group/ppp-public?pli=1
> 
> --
> C.W.Holeman II | cwhii <at> JulianLocals.com |  http://JulianLocals.com/cwhii
>  To only a fraction of the  human  race does God  give the  privilege of
>  earning one's bread doing what one would have  gladly pursued free, for
>  passion. I am very thankful. The Mythical Man-Month Epilogue/F.P.Brooks
> 
> 
> 
----------------------------
dear Holeman:

  I follow your advice read that mailing list (or newsgroup) article,
and download fltk-1.3.x-r7769
re autoconf
   ./configure
   make
   sudo make install

  then recompile
--------------------
eric <at> eric-laptop:~/BStrou/usingC++4/code/Chapter12$ g++ -Wno-deprecated
chapter.12.7.2.cpp   -lfltk 
In file included from chapter.12.7.2.cpp:7:
Simple_window.h:17: error: reference to ‘Window’ is ambiguous
/usr/include/X11/X.h:96: error: candidates are: typedef XID Window
(Continue reading)

Jonathan Wakely | 1 Nov 09:59 2010
Picon

Re: [Bulk] Re: your (or Stroustrup) chapter.12.3.cpp (and 12.7.2.cpp)can not compile on my ubuntu/linux10.03

On 1 November 2010 08:46, eric  wrote:
> should I also post this to X.org and gcc 's mailing list?

No.  This mailing list is not for help using GCC, and your problem is
not caused by GCC.  Please post somewhere else more appropriate, such
as the gcc-help list.

Andrew Haley | 1 Nov 09:59 2010
Picon

Re: PATCH RFA: Do not build java by default

On 10/31/2010 07:09 PM, Ian Lance Taylor wrote:

> This patch should not of course change whether or not distros choose to
> package the Java compiler; undoubtedly they would continue to do so,
> just as they package the Ada compiler today.
> 
> Comments?  Approvals?

I see your point, but this will lead to some quality regressions in gcc
itself.  libgcj is a good stress test for gcc, and has revealed some
bugs in the past.  It might be possible to mitigate some of this with
autotesters that run a full libgcj bootstrap every night.

Andrew.

Andrew Haley | 1 Nov 10:03 2010
Picon

Re: PATCH RFA: Do not build java by default

On 11/01/2010 04:06 AM, Geert Bosch wrote:
> 
> On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
>> The argument against disabling java as a default language always was
>> that there should be at least one default language that requires
>> non-call exceptions. I recall testing many patches without trouble if
>> I did experimental builds with just C, C++, and Fortran, only to find
>> lots of java test suite failures in a complete bootstrap+test cycle.
>> So the second point is, IMVHO, not really true.
> 
> Feel free to enable Ada. Builds and tests faster than Java, 
> and is known to expose many more middle end bugs,

Hmm, weasely use of passive voice noted.  ;-)

Out of interest, why would Ada expose more midle-end bugs?

Andrew.

Paul Brook | 1 Nov 10:50 2010

Re: dual result function & ABI (using extra register), e.g. for Go

> > Does the Go language define a specific ABI convention for returning
> > two values from a function thru registers? If yes, how does GCC
> > implement it? Or is it some future work?
> 
> The Go language does not define an ABI for returning multiple values.
> The gccgo frontend implements it by saying that a function which returns
> multiple values returns a struct with fields whose types are the types
> of the result parameter.
> 
> It's desirable to make it possible to write C functions which return
> multiple values to Go code.  For example, some of the runtime support
> functions work that way.  Having the Go return a struct ensures that it
> is easy to write compatible C code.

So the original question becomes "How are structures returned from a 
function". The answer depends on the ABI.

If the ABI for your favourite target doesn't behave as you might like I guess 
we could invent a target attribute to change this on a per-function basis, 
similar to __attribute__((regparm)).  Some third party ARM toolchains already 
have this.

Paul

Dave Korn | 1 Nov 11:34 2010
Picon

Re: PATCH RFA: Do not build java by default

On 01/11/2010 03:48, Andrew Pinski wrote:
> On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer <gerald <at> pfeifer.com> wrote:
>> On Sun, 31 Oct 2010, Steven Bosscher wrote:
>>> Is it possible to build and test java without all of libjava?
>> configure --disable-libgcj.  I have been using this for my daily
>> bootstraps for a while.
> 
> But it does not test java.  Since the java testsuite depends on libjava.

  Indeed, it doesn't do anything at all.  There is no java testsuite (i.e.
nothing in gcc/testsuite/java.*).  There is only a libjava testsuite.

    cheers,
      DaveK

Dave Korn | 1 Nov 11:54 2010
Picon

Re: PATCH RFA: Do not build java by default

On 31/10/2010 19:09, Ian Lance Taylor wrote:

> Java in the same category as Ada and Objective C++.  The main argument
> in favor of this proposal is twofold: 1) building libjava is a large
> component of gcc bootstrap time, and thus a large component in the
> amount of time it takes to test changes; 

  Proposing to change the compiler as a solution to that problem seems to be a
category error to me.  You can achieve the same end-result by social rather
than technical means: just change the rules for patch submission to say "You
don't have to test your patch against Java".

> 2) it is in practice very
> unusual for middle-end or back-end changes to cause problems with Java
> without also causing problems for C/C++, 

  This seems like false reasoning as well.  It may (or may not - I don't
suppose anyone's actually done the number on this, have they?) be unusual, but
the bugs that meet this criterion are nonetheless real bugs that we do not
want to put into our compiler if we can possibly help it, they will
subsequently need discovering, analysing and fixing, and will require manpower
and resources to do so.

  I find it hard not to expect that the long-term outcome will be a gradual
decline in quality of gcj if we do this.  Particularly on minority platforms,
which are exactly the ones that have the least manpower available to fix problems.

  For these reasons, my "vote" is against making this change.

    cheers,
(Continue reading)


Gmane