Joern Rennecke | 1 Nov 2010 05:30
Favicon

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 2010 09:46
Picon
Favicon

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 2010 09:59
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 2010 09:59
Picon
Favicon

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 2010 10:03
Picon
Favicon

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 2010 10:50
Gravatar

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 2010 11:34
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

Joern Rennecke | 1 Nov 2010 11:47
Favicon

Re: PATCH RFA: Do not build java by default

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

> On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>> But to get that coverage, testers will need to have gnat installed.
>> Will that become a requirement for middle-end patch regression testing?
>
> No, the language will only be built if a suitable bootstrap compiler
> is present.

I know that.  My question was aimed at soliciting opinions on patch
submission policy in the case that libjava build & testing are dropped
from standard bootstrap tests.

Hui Yan Cheah | 1 Nov 2010 14:21
Picon

how much is the effort required to retarget gcc?

Hi,

We are working on a new project which requires a retargetting a
compiler to a small cpu on FPGA.
The cpu is hand-coded and it supports only a limited number of instruction sets.

My questions are:

1. Since I have very limited experience with compilers (this is my
first compiler project), is it wise to begin with gcc? I have
googled-up smaller compilers like pcc, lcc and small-c and they seem
like very good candidates. However, I would like to listen to the
opinions of programmers who have worked with gcc or retargetted gcc.

2. How much is the effort in retargetting compilers? I heard it took
months but it all depends on the level of experience of the
programmer. So if an experienced programmer took 2 month, it might
have taken a beginner 6 months or so.

Thanks,
HY

Paul Koning | 1 Nov 2010 15:52
Picon
Favicon

Re: help debugging ICE in fortran testsuite (was: TARGET_VALID_POINTER_MODE unused?)


On Oct 31, 2010, at 2:39 PM, Ian Lance Taylor wrote:

> Paul Koning <paul_koning <at> dell.com> writes:
> 
>> What triggered the question is that I'm trying to debug a testsuite
>> ICE in fortran, pdp11 target, where it aborts in
>> convert_memory_address_addr_space apparently trying to make a 32 bit
>> pointer.  But only 16 bit pointers are valid, ptr_mode is HImode as
>> expected and as far as I can tell from gccint everything is set up
>> correctly for that to be the only pointer type.  I don't have
>> TARGET_VALID_POINTER_MODE defined and from what the documentation says
>> it doesn't seem like I have to.  So where should I look to find an
>> explanation for why the fortran compiler is trying to make an SImode
>> pointer?
> 
> This should not happen and I agree that TARGET_VALID_POINTER_MODE is
> irrelevant here.  This sounds like a bug somewhere but I don't know
> here.  In the absence of additional information, like which test case is
> failing, all I can advise is to debug it to find out where the invalid
> pointer mode is coming from.

I've changed the subject string to match better what we're talking about...

aaa-5v57ooxfyrm:build pkoning$ pdp11-aout-gfortran -mfloat32 /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f:
In function
‘dimoid’:
/Users/pkoning/Documents/svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f:54:0:
internal compiler error: in convert_memory_address_addr_space, at explow.c:327
(Continue reading)


Gmane