date:20101101

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

2010-11-01 Thread eric

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

e...@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
Window.h:26: error: class Graph_lib::Window
Simple_window.h:17: error: reference to ‘Window’ is ambiguous
/usr/include/X11/X.h:96: error: candidates are: typedef XID Window
Window.h:26: error: class Graph_lib::Window
e...@eric-laptop:~/BStrou/usingC++4/code/Chapter12$ 

--
should I also post this to X.org and gcc 's mailing list?
-
this is code of chapter.12.7.2.cpp(same as that newgroup's Drill.cpp)
again my compiler is not MS visual c++, it is gnu gcc 4.4.3 on linux
plz help

//--

int main ()
try
{ 
Point tl(100,100); // top-left corner of our window

Simple_window win(tl,600,400,Canvas);
// screen coordinate tl for top-left corner
// window size(600*400)
// title: Canvas
win.wait_for_button(); // Display!
} 
catch(exception e) {
// some error reporting
return 1;
}
catch(...) {
// some more error reporting
return 2;
}

//--
-

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

2010-11-01 Thread Jonathan Wakely

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.

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Andrew Haley

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.

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Andrew Haley

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.

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

2010-11-01 Thread Paul Brook

  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

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Dave Korn

On 01/11/2010 03:48, Andrew Pinski wrote:
 On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer ger...@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

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Dave Korn

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,
  DaveK

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Geert Bosch


On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
 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?

No, the language will only be built if a suitable bootstrap compiler
is present. 

  -Geert

Re: PATCH RFA: Do not build java by default

2010-11-01 Thread Joern Rennecke


Quoting Geert Bosch bo...@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.

how much is the effort required to retarget gcc?

2010-11-01 Thread Hui Yan Cheah

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

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

2010-11-01 Thread Paul Koning

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

Paul Koning paul_kon...@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
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
aaa-5v57ooxfyrm:build pkoning$

I see the same for a couple of different fortran compile testcases; this is the
first of those. (In fact, right now I get 32 testsuite fails for Fortran, all
caused by this one issue.)

From some code reading I'm guessing that this problem occurs when RTL is being
generated from the tree, so I tried looking at the tree dumps. That didn't
tell me much; I've never looked there and don't really know what to look for.

1 2 >

1 - 100 of 110 matches

Mail list logo