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

[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

[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

[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

[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

[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

[Dave Korn]

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

[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

[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

[Joern Rennecke]

Quoting Geert Bosch :


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?

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

[Paul Koning]

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

> Paul Koning  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  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.

paul

UNITS_PER_SIMD_WORD

[roy rosen]

Hi All,

Is it possible to define UNITS_PER_SIMD_WORD as a global variable and
to set this varibale using a pragma (even once for a compilation) and
that way to be able to compile one file with UNITS_PER_SIMD_WORD = 8
and another file with UNITS_PER_SIMD_WORD = 16?

Thanks, Roy.

Re: UNITS_PER_SIMD_WORD

[Paul Brook]

> Hi All,
> 
> Is it possible to define UNITS_PER_SIMD_WORD as a global variable and
> to set this varibale using a pragma (even once for a compilation) and
> that way to be able to compile one file with UNITS_PER_SIMD_WORD = 8
> and another file with UNITS_PER_SIMD_WORD = 16?

No. This is an internal value that is a property of the vector ISA you're 
targeting.

AFAIK there's only one supported target that supports variable length vectors 
(ARM NEON), which allows selecting between doubleword and quadword vectors via 
a target specific commandline option.  Idealy you wouldn't need this at all, 
but I don;t believe the vectorizer is capable of handling this.

Paul

Re: UNITS_PER_SIMD_WORD

[H.J. Lu]

On Mon, Nov 1, 2010 at 9:27 AM, Paul Brook  wrote:
>> Hi All,
>>
>> Is it possible to define UNITS_PER_SIMD_WORD as a global variable and
>> to set this varibale using a pragma (even once for a compilation) and
>> that way to be able to compile one file with UNITS_PER_SIMD_WORD = 8
>> and another file with UNITS_PER_SIMD_WORD = 16?
>
> No. This is an internal value that is a property of the vector ISA you're
> targeting.
>
> AFAIK there's only one supported target that supports variable length vectors
> (ARM NEON), which allows selecting between doubleword and quadword vectors via
> a target specific commandline option.  Idealy you wouldn't need this at all,
> but I don;t believe the vectorizer is capable of handling this.

x86 supports either 128bit (SSE) or 256bit (AVX) vectors. It works OK.



-- 
H.J.

Re: RFC: Add zlib source to src CVS resposity

[Nick Clifton]

Hi Guys,

>>> So this becomes a question for the binutils maintainers: do

the binutils want to be self-contained, or do they want to follow the
path of gcc and require additional libraries to be installed before a
build can succeed?


As I see it the pros of having a copy of the zlib sources in the 
binutils tree are that:


  * The tools can be built on a host that does not have
zlib installed.

  * We can be sure exactly which version of zlib is being
used.

  * It simplifies our configure scripts and sources.  We
always know that zlib is present and the API to use.

Whereas the cons of having our own copy of zlib are that:

  * We have to manually import any bug-fixes or enhancements
to the official zlib sources.  Which means that we have
to watch the zlib sources and be ready to evaluate any
changes.

  * We have to make sure that zlib will build on all of the
hosts that we care about.  Should the situation arise
where the zlib does not build on a particular host, and
the zlib maintainers are not interested in making it
build there, then it will be down to us to fix it.  Or
else abandon compression support on that host.

  * It is essentially a waste of space on hosts that already
have zlib installed.

At the moment I feel that the pros outweigh the cons.  What do other 
people think ?


Cheers
  Nick

Re: RFC: Add zlib source to src CVS resposity

[Daniel Jacobowitz]

On Mon, Nov 01, 2010 at 05:13:44PM +, Nick Clifton wrote:
> At the moment I feel that the pros outweigh the cons.  What do other
> people think ?

I was asked not to include expat in GDB, which was a similar
situation.  I don't remember if this was an FSF issue; I know that the
FSF, in general, dislikes duplicated source code in packages, but I
don't know if they care when the duplicated bits are non-GNU.  There
were definitely GDB developers that disliked bundling expat, so
perhaps you can find the reasons in the archives.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Discussion about merging Go frontend

[Tom Tromey]

> "Ian" == Ian Lance Taylor  writes:

Ian> This patch puts the code in libiberty, but it could equally well go in
Ian> gcc.  Anybody want to make an argument one way or another?

Ian> +extern const char *
Ian> +objfile_attributes_compare (objfile_attributes *attrs1,

GDB already uses the name "objfile" for one of its modules.
I don't think we have any name clashes with this patch right now, but I
would prefer to avoid the eventual confusion.
So, if this is in libiberty, could it please have a different name?

thanks,
Tom

Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor]

Dave Korn  writes:

> 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".

I think the two statements are essentially equivalent.  These days, when
most ordinary users get their compiler from a distro or other binary
form, the set of default languages is most important for gcc developers.
We currently say that for middle-end or backend patches you must
bootstrap with all default languages.  Changing the set of default
languages is a way of changing that statement.  It's not, in my opinion,
a category error.

Ian

Re: PATCH RFA: Do not build java by default

[Tom Tromey]

> "Steven" == Steven Bosscher  writes:

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

Is it possible to convert all failures of this form into a C++ test case
with -fnon-call-exceptions?  If so then at least there is a way to add
regression tests.

Steven> Is it possible to build and test java without all of libjava?

As far as I'm aware, not at present.  I think even the minimal possible
subset of libjava is pretty big, on the order of hundreds of classes,
IIRC.

Tom

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

On 11/01/2010 05:50 PM, Tom Tromey wrote:
>> "Steven" == Steven Bosscher  writes:
> 
> Steven> The argument against disabling java as a default language always was
> Steven> that there should be at least one default language that requires
> Steven> non-call exceptions. I recall testing many patches without trouble if
> Steven> I did experimental builds with just C, C++, and Fortran, only to find
> Steven> lots of java test suite failures in a complete bootstrap+test cycle.
> Steven> So the second point is, IMVHO, not really true.
> 
> Is it possible to convert all failures of this form into a C++ test case
> with -fnon-call-exceptions?  If so then at least there is a way to add
> regression tests.

In practice, no.  We don't know what the C++ equivalent is until we've
seen the Java (or Ada) test failure.  In the Rumsfeld epistemology it's
an unknown uknown, something that we don't know we don't know.

> Steven> Is it possible to build and test java without all of libjava?
> 
> As far as I'm aware, not at present.  I think even the minimal possible
> subset of libjava is pretty big, on the order of hundreds of classes,
> IIRC.

And the failures I've seen have been in some of the crazy cases, not
just simple Java code, where things get complicated.

Andrew.

Re: PATCH RFA: Do not build java by default

[Diego Novillo]

On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor  wrote:

> Comments?  Approvals?

FWIW, I agree with this patch for the same reasons stated by Ian.
Other than massively increasing build times, I have not seen
substantial benefits for having java enabled by default.  Ada, on the
other hand, has shown more usefulness in exposing bugs (particularly,
middle end) and is many times faster.

This is the kind of patch that requires more consensus or agreement
from the java maintainers.  aph, are you dead set against disabling
java?  Is there anything we could do to change your mind?


Thanks.  Diego.

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Tom Tromey  writes:

>> "Ian" == Ian Lance Taylor  writes:
>
> Ian> This patch puts the code in libiberty, but it could equally well go in
> Ian> gcc.  Anybody want to make an argument one way or another?
>
> Ian> +extern const char *
> Ian> +objfile_attributes_compare (objfile_attributes *attrs1,
>
> GDB already uses the name "objfile" for one of its modules.
> I don't think we have any name clashes with this patch right now, but I
> would prefer to avoid the eventual confusion.
> So, if this is in libiberty, could it please have a different name?

Sure.

Any suggestions?

Ian

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

On 11/01/2010 06:16 PM, Diego Novillo wrote:
> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor  wrote:
> 
>> Comments?  Approvals?
> 
> FWIW, I agree with this patch for the same reasons stated by Ian.
> Other than massively increasing build times, I have not seen
> substantial benefits for having java enabled by default.  Ada, on the
> other hand, has shown more usefulness in exposing bugs (particularly,
> middle end) and is many times faster.
> 
> This is the kind of patch that requires more consensus or agreement
> from the java maintainers.  aph, are you dead set against disabling
> java?

No.

> Is there anything we could do to change your mind?

Yes, if we have an autotester that runs the libgcj test suite and
mails maintainers (or the list) when they break things.

Andrew.

Re: PATCH RFA: Do not build java by default

[H.J. Lu]

On Mon, Nov 1, 2010 at 11:58 AM, Andrew Haley  wrote:
>
>> Is there anything we could do to change your mind?
>
> Yes, if we have an autotester that runs the libgcj test suite and
> mails maintainers (or the list) when they break things.
>

I don't mind enabling Java in my autotesters for Linux/ia32 and
Linux/x86-64.


-- 
H.J.

Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor]

Andrew Haley  writes:

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

TYPE_IS_SIZETYPE (for some definition of "bug").

More seriously, Ada permits all sorts of integer subtypes which do not,
as far as I know, exist in Java.  Ada is also the only frontend which
generates PLACEHOLDER_EXPR.

Ian

Re: PATCH RFA: Do not build java by default

[Richard Kenner]

> More seriously, Ada permits all sorts of integer subtypes which do not,
> as far as I know, exist in Java.  Ada is also the only frontend which
> generates PLACEHOLDER_EXPR.

And it heavily uses variable-sized types.

Re: how much is the effort required to retarget gcc?

[Ian Lance Taylor]

Hui Yan Cheah  writes:

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

That's a tough question to answer.  gcc is well designed for targeting
new processors and that part of gcc is well documented.  There are also
many existing examples to look at.  On the other hand, gcc is a large
and powerful C compiler and it can take a fair amount of work to get
optimal code out of it.  And if something goes wrong in your port, such
that you have to understand the gcc code to figure out what is
happening, it can take some time to figure out how gcc works well enough
to debug it.

I don't have any experience with the other compilers you mention, so I
really don't know how hard it would be to retarget them.


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

That sounds about right, if you replace "experienced programmer" with
"experienced GCC developer" and replace "beginner" with "experienced
programmer with no GCC experience."  I would estimate that a person
whose first serious programming task is retargeting gcc would take more
than six months.  You can't port a compiler without a deep understanding
of how computers work, and developing that understanding takes time.

Of course, that is the general case.  A lot depends on the target CPU.
If the CPU has
  * a limited number of instructions, but providing all math instructions
  * orthogonal registers with no dedicated registers except perhaps PC
  * no unusual instructions
  * 8-bit bytes
  * simple call instruction
  * simple indirect call instruction
  * simple indirect jump instruction
  * simple register plus offset addressing
  * an existing assembler with standard ELF syntax
then a GCC port is pretty simple, and an experienced GCC programmer
could probably do it in two or three weeks.  Unfortunately I have never
yet seen such a CPU in real hardware, and the difficulties arise in the
ways in which the real CPU departs from that ideal.

Finally, there are companies and individual contractors which specialize
in porting gcc to new hardware, and they would be happy to take this
burden from your hands, for a fee.  I have no idea how much that fee is
these days.

Ian

Re: PATCH RFA: Do not build java by default

[Richard Guenther]

On Mon, Nov 1, 2010 at 10:03 AM, Andrew Haley  wrote:
> 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?

In the 5 years working on GCC (and usually testing both Java and Ada)
Ada caught infinitely more bugs than Java (which caught zero) for me.

I think enabling Ada by default if gnat is installed makes sense.

Richard.

> Andrew.
>

Re: RFC: Add zlib source to src CVS resposity

[Alan Modra]

On Mon, Nov 01, 2010 at 05:13:44PM +, Nick Clifton wrote:
>   * We have to make sure that zlib will build on all of the
> hosts that we care about.  Should the situation arise
> where the zlib does not build on a particular host, and
> the zlib maintainers are not interested in making it
> build there, then it will be down to us to fix it.  Or
> else abandon compression support on that host.

This would mean we need to keep machinery to conditionally compile
in compressed debug support, removal of said support being HJ's stated
reason for importing zlib.

I'm against importing zlib into binutils, and I think we should keep
support of compressed debug sections conditional, to avoid potential
bootstrap problems or circular dependencies.

-- 
Alan Modra
Australia Development Lab, IBM

ipa on all files together

[Hongtao]

 Hi All,

While using gcc-4.6 with option -flto, I found that interprocedural
analysis were performed on each source file separately. For example for
the pass pass_ipa_pta, if we compile two files like :
 gcc -O -flto f1.c f2.c
we have the pass run twice, one for each source file. So is there a way
that can perform IPA on all source files together?


Thanks,
Hongtao
Purdue University

Re: ipa on all files together

[Diego Novillo]

On Mon, Nov 1, 2010 at 19:57, Hongtao  wrote:
>  Hi All,
>
> While using gcc-4.6 with option -flto, I found that interprocedural
> analysis were performed on each source file separately. For example for
> the pass pass_ipa_pta, if we compile two files like :
>         gcc -O -flto f1.c f2.c
> we have the pass run twice, one for each source file. So is there a way
> that can perform IPA on all source files together?

With -combine you used to be able to do this, but it has been removed
in favour of -flto (actually, I'm not quite sure whether it's been
removed already, but it's on the chopping block).

With -flto, IPA will be performed on all the files together, as well
as each file separately.  In your example, IPA runs 3 times.  Once for
each f1.c and f2.c, and a third time with both f1.o and f2.o as a
single translation unit.


Diego.

Re: ipa on all files together

[Hongtao]

 On 11/01/10 20:35, Diego Novillo wrote:
> On Mon, Nov 1, 2010 at 19:57, Hongtao  wrote:
>>  Hi All,
>>
>> While using gcc-4.6 with option -flto, I found that interprocedural
>> analysis were performed on each source file separately. For example for
>> the pass pass_ipa_pta, if we compile two files like :
>> gcc -O -flto f1.c f2.c
>> we have the pass run twice, one for each source file. So is there a way
>> that can perform IPA on all source files together?
> With -combine you used to be able to do this, but it has been removed
> in favour of -flto (actually, I'm not quite sure whether it's been
> removed already, but it's on the chopping block).
>
> With -flto, IPA will be performed on all the files together, as well
> as each file separately.  In your example, IPA runs 3 times.  Once for
> each f1.c and f2.c, and a third time with both f1.o and f2.o as a
> single translation unit. 
  Thanks. But can I only keep the third pass, i.e.  I want to perform a
pass only on all units together without on each unit separately?

  Hongtao

> Diego.
>

Re: RFC: Add zlib source to src CVS resposity

[Christopher Faylor]

On Tue, Nov 02, 2010 at 10:25:50AM +1030, Alan Modra wrote:
>On Mon, Nov 01, 2010 at 05:13:44PM +, Nick Clifton wrote:
>>   * We have to make sure that zlib will build on all of the
>> hosts that we care about.  Should the situation arise
>> where the zlib does not build on a particular host, and
>> the zlib maintainers are not interested in making it
>> build there, then it will be down to us to fix it.  Or
>> else abandon compression support on that host.
>
>This would mean we need to keep machinery to conditionally compile
>in compressed debug support, removal of said support being HJ's stated
>reason for importing zlib.
>
>I'm against importing zlib into binutils, and I think we should keep
>support of compressed debug sections conditional, to avoid potential
>bootstrap problems or circular dependencies.

FWIW, I agree.  I think that having to keep zlib up-to-date wrt
potential security issues or other serious bugs is a burden that we
shouldn't take on.  Shouldn't we be trying to use any system shared
libraries for these types of things specifically so that the vendor
can handle problems for us?

cgf

not quite polymorphism

[eric lin]

/usr/include/c++/4.4/backward/backward_warning.h:28:2: warning:
#warning This file includes at least one deprecated or antiquated
header which may be removed without further notice at a future date.
Please use a non-deprecated interface with equivalent functionality
instead. For a listing of replacement headers and interfaces, consult
the  file  backward_warning.h.  To  disable  this  warning  use
-Wno-deprecated.
In file included from Simple_window.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
Simple_window.cpp: In constructor
‘Simple_window::Simple_window(Point, int, int, const String&)’:
Simple_window.cpp:12: 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.cpp:12: error: class ‘Simple_window’ does not have any
field named ‘Window’
Simple_window.cpp:16: error: ‘attach’ was not declared in this scope
Simple_window.cpp:  In  member  function  ‘bool
Simple_window::wait_for_button()’:
Simple_window.cpp:26: error: ‘show’ was not declared in this scope
Simple_window.cpp: In member function ‘void Simple_window::next()’:
Simple_window.cpp:53: error: ‘hide’ was not declared in this scope
# cc1plus 0.54 0.04
make[1]: *** [Simple_window.o] Error 1
rm Graph.o GUI.o
make[1]: Leaving directory `/home/eric/BStrou/usingC++4/code/GUI'
make: *** [../GUI/libbookgui.a] Error 2
e...@eric-laptop:~/BStrou/usingC++4/code/Chapter12$
-link 
fltk with example program of book by Stroustrup--
I am using 4.4.3, could anyone have experience to use different(newer) version 
of gcc/g++ so it can distinquish different useage of same variable, i.e. 
Window, in my case without response by compile time error?

thans your time and effort a lot in advance, Eric


_
Luxmail.com is spam free. However, we do not throw your important emails into 
spam box like other defective email systems.

Re: PATCH RFA: Do not build java by default

[Jeff Law]

 On 11/01/10 12:16, Diego Novillo wrote:

On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor  wrote:


Comments?  Approvals?

FWIW, I agree with this patch for the same reasons stated by Ian.
Other than massively increasing build times, I have not seen
substantial benefits for having java enabled by default.  Ada, on the
other hand, has shown more usefulness in exposing bugs (particularly,
middle end) and is many times faster.

This is the kind of patch that requires more consensus or agreement
from the java maintainers.  aph, are you dead set against disabling
java?  Is there anything we could do to change your mind?
Building libjava (at least for me) is primarily painful due to 2 files 
(the names escape me) and the rather poor coarse level parallelism 
(can't build the 32bit and 64bit multilibs in parallel for example).


Has anyone looked at fixing the build machinery for libjava to make it 
more sensible?


I'd personally prefer java over ada as I'm able to understand java code 
easier, thus when something does go wrong I'm able to debug it much faster.


Jeff

Re: PATCH RFA: Do not build java by default

[H.J. Lu]

On Mon, Nov 1, 2010 at 8:39 PM, Jeff Law  wrote:
>  On 11/01/10 12:16, Diego Novillo wrote:
>>
>> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor  wrote:
>>
>>> Comments?  Approvals?
>>
>> FWIW, I agree with this patch for the same reasons stated by Ian.
>> Other than massively increasing build times, I have not seen
>> substantial benefits for having java enabled by default.  Ada, on the
>> other hand, has shown more usefulness in exposing bugs (particularly,
>> middle end) and is many times faster.
>>
>> This is the kind of patch that requires more consensus or agreement
>> from the java maintainers.  aph, are you dead set against disabling
>> java?  Is there anything we could do to change your mind?
>
> Building libjava (at least for me) is primarily painful due to 2 files (the
> names escape me) and the rather poor coarse level parallelism (can't build
> the 32bit and 64bit multilibs in parallel for example).
>
> Has anyone looked at fixing the build machinery for libjava to make it more
> sensible?
>
> I'd personally prefer java over ada as I'm able to understand java code
> easier, thus when something does go wrong I'm able to debug it much faster.
>

FWIW, it takes about 33minutes to bootstap gcc trunk on Fedora 13/Intel
Core i7 870 with both 32bit and 64bit libraries. I configure gcc with

-enable-clocale=gnu --with-system-zlib --with-demangler-in-ld  --enab
le-shared --enable-threads=posix --enable-haifa  --prefix=/usr/gcc-4.6.0 --with-
local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld.gold --enable-gold
 --with-fpmath=sse


-- 
H.J.

Re: not quite polymorphism

[Ian Lance Taylor]

"eric lin"  writes:

> I am using 4.4.3, could anyone have experience to use different(newer)
> version of gcc/g++ so it can distinquish different useage of same
> variable, i.e. Window, in my case without response by compile time
> error?

This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for issues regarding the development of gcc itself.  It would
be appropriate for the mailing list gcc-h...@gcc.gnu.org.  Please take
any followups to gcc-help.  Thanks.

Unfortunately I don't know the answer to your question, as you did not
provide any source code.  In the absence of other information it appears
to be a language question rather than a compiler question.

Ian

Re: PATCH RFA: Do not build java by default

[Matthias Klose]

On 31.10.2010 20:09, Ian Lance Taylor wrote:

Currently we build the Java frontend and libjava by default.  At the GCC
Summit we raised the question of whether should turn this off, thus only
building it when java is explicitly selected at configure time with
--enable-languages.  Among the people at the summit, there was general
support for this, and nobody was opposed to it.

Here is a patch which implements that.  I'm sending this to the mailing
lists gcc@ and java@, as well as the relevant -patches@ lists, because
it does deserve some broader discussion.

This is not a proposal to remove the Java frontend nor is it leading up
to that.  It is a proposal to not build the frontend by default, putting
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; 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++, thus building and testing
libjava does not in practice help ensure the stability of the compiler.
A supporting argument is since Sun has released their Java tools under
the GPL, community interest seems to have shifted toward the Sun tools;
gcc's Java frontend is in maintenance mode, with little new development
currently planned.


please note that gcj is still required for a bootstrap of openjdk on platforms 
which don't yet have a working openjdk. At least for this purpose it is still 
maintained.



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?


if build speed is the only issue, why not

 - disable the static libgcj build, if not explicitely enabled?

 - disable the biarch build for libgcj? most distributions don't
   have all of the depending libraries available for biarch builds.

Matthias