gcc 3.0

gcc 3.0

[Paulo Pinto]

    I just wish to give my congratulations to
everyone that was worked in gcc and made
gcc 3.0 possible.

    You guys are like an inspiration to me.
    
--
 Paulo Pinto

Re: gcc 3.0

[Craig Rodrigues]

On Sat, Sep 08, 2001 at 04:02:50PM -0500, N V Krishna wrote:
> Hi,
> 	I was looking at the 3.0 gcc code. And was wondering if there are
> options/switches by which I can print the intermediate tree representation?
> The other point I wanted to ask was how do you debug, gcc with so many macros?

If you look in gcc/gcc/gdbinit.in, you will see some gdb
macros which call some internal debugging functions.

pt calls debug_tree
pr calls debug_rtx
ptc prints the tree code of a node



In terms of dumping stuff to a file, you might want
to look at the gcc manual:
http://gcc.gnu.org/onlinedocs/gcc-3.0.1/gcc_17.html#SEC171

There are some flags:
-dR, -dr, -di and others that allow you to dump RTL to a file.

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

gcc 3.0

[N V Krishna]

Hi,
	I was looking at the 3.0 gcc code. And was wondering if there are
options/switches by which I can print the intermediate tree representation?
The other point I wanted to ask was how do you debug, gcc with so many macros?
I mean, say, you want to check the node type then the macro available is
TREE_NODE, but how do you work when debugging?

Any help in this regard would be very useful..

Thanks and regards
Krishna

RE: GCC 3.0

[Gerald Pfeifer]

On Mon, 2 Jul 2001, Bobby McNulty II wrote:
> Gerald, I have GCC 3.0 working on a Pentium CPU running at 166 MHZ.l
> Operating system: Linux
> I586-pc-linux-gnu

Thanks, I added this to our build status page for GCC 3.0.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

RE: GCC 3.0

[Bobby McNulty II]

Gerald, I have GCC 3.0 working on a Pentium CPU running at 166 MHZ.l
Operating system: Linux
I586-pc-linux-gnu

-----Original Message-----
From: gcc-owner@gcc.gnu.org [ mailto:gcc-owner@gcc.gnu.org]On Behalf Of
Gerald Pfeifer
Sent: Sunday, July 01, 2001 1:33 PM
To: Wouter Demuynck
Cc: gcc@gcc.gnu.org
Subject: Re: GCC 3.0

On Sun, 1 Jul 2001, Wouter Demuynck wrote:
> config.guess output: i586-pc-cygwin

Thanks! I added this to our build status page.

Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at
http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0

[Gerald Pfeifer]

On Sun, 1 Jul 2001, Wouter Demuynck wrote:
> config.guess output: i586-pc-cygwin

Thanks! I added this to our build status page.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

GCC 3.0

[Wouter Demuynck]

Hello there,

I managed to compile and install GCC 3.0 with Cygwin 1.3.2 on my Win98
Celeron 433 MHz
The installation help said I should notify this, so:

config.guess output: i586-pc-cygwin

Sincerely, Wouter Demuynck

Re: gcc 3.0

[Geert Bosch]

GCC has supported 64-bit addressing for many many years (always?), 
for example the DEC Alpha is one of the older 64-bit ports.
More 64-bit ports get added over time, for HP-PA/HPUX and SPARC/Solaris 
for example. However, I don't think the support for these last two platforms 
is complete yet in GCC 3.0.

On Tue, 19 Jun 2001, Kuraisa, Roy wrote:
  Congrats for getting 3.0 out ;) !  I was looking at the new features but did
  not see any mention of supporting 64-bit address space -- so am I correct in
  thinking that 3.0 does not support 64-bit on targets like solaris/sunos?
  tia.

gcc 3.0

[Kuraisa, Roy]

Hi,
Congrats for getting 3.0 out ;) !  I was looking at the new features but did
not see any mention of supporting 64-bit address space -- so am I correct in
thinking that 3.0 does not support 64-bit on targets like solaris/sunos?
tia.

cheers,
roy

Roy Kuraisa
Rosetta Inpharmatics, Inc. / Informatics
12040 115th Ave NE / Kirkland, WA 98034
425.636.6398




****************************************************************************
This e-mail message is the property of Rosetta Inpharmatics 
and may contain information that is confidential and/or 
privileged.  If you are not the intended recipient, any use, 
disclosure, copying, or communication of the contents of this 
message is prohibited.  If this message was received in error, 
please forward a copy to mail_admin@rii.com and delete the 
message and any attachments from your computer.  Thank you. 
****************************************************************************

Re: GCC 3.0

[Toon Moene]

Mark Mitchell wrote:

[ .... Ramblings about aliens removed :-) .... ]

> I would like to branch in the relatively near future.

There are no known Fortran features pending (i.e. that are polished
enough for GCC 3.0).

Cheers,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> - Does V3 work on the major architectures yet, or are we still hung
Mark> up on AIX and HPUX?

	I am not aware of progress on AIX.  We still need to figure out
why reference counting fails for the revised I/O ctor/dtor strategy.

David

GCC 3.0

[Mark Mitchell]

Since I have spent so little time on GCC in the last few weeks, a lot
of you have probably been wondering if I have been abducted by aliens.

I have been -- but that's another story. :-)

I've been swamped with personal and professional tasks, and then the
holidays, and ...

However, I have now complete cleared the boards -- my only technical
task is now GCC.

Obviously, I will be focusing most of my energy on the GCC 3.0
release.

I would like to branch in the relatively near future.  I know of only
one major feature outstanding, after a recent pow-wow between Kosnik,
Henderson, Keating, Petit-Bianco, and myself:

  - Richard is going to make a driver switch to control whether or not
    we use libgcc.so.

There is one optional feature, that I do not think we need to hold up
branching for:

  - Adopting the high-level IA64 ABI EH model, rather than the current
    run-time interface.

I'm sure there are many remaining technical problems.  

  - Does V3 work on the major architectures yet, or are we still hung
    up on AIX and HPUX?

  - Other major functional failures?

I'm looking for major pieces of missing functionality that would
prevent branching, not just bugs, however serious.

Richard, what's a reasonable time-frame for the driver switch?

In the meantime, I'm working on compile-time performance stuff.  On
the way back from Nashville, I knoced another few percent off on C++
testcase; patches coming soon...

Assume that I'm out of touch with GCC mail not sent to me personally
-- I couldn't keep up with the lists the last couple of weeks.  If
there's something you think I should be aware of, feel free to zap it
to me directly -- no need to copy the lists.

Sorry for the long absence,
  
--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Mark Mitchell]

>>>>> "Theodore" == Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

    Theodore> There is the promise floating around that after 3.0
    Theodore> there will be no more intempestive ABI changes and IIRC
    Theodore> by this people also mean ABI changes within the C++
    Theodore> standard library.

There will still be some changes to the library.  However, you should
be able to upgrade the compiler (and not the library) if you want to
preserve backwards compatiblity.  If we wait for the library to
completely stabilize, we'll need to wait a year or two at best.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Mark Mitchell]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:

    Benjamin> to enable the generic, stdio interface as an
    Benjamin> alternate. (This is what I'm now working on.)

I like the idea of using the generic stdio interface.  We'll need that
for some systems anyhow probably -- and that allows us to switch over
to the rest of the new library without dealing with the problematic
libio bits.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@racerx.synopsys.com> writes:

    Joe> It seems that most of the problems are associated with the
    Joe> wide characters and locales.  Perhaps have some #ifdef that
    Joe> takes that out on platforms where it doesn't work yet?  We
    Joe> can then test everything else.

I think that's where most of the problems lie, but there may be other
issues as well.  I know that there are thread-safety problems on AIX,
for example.  In any case, I agree with your suggestion: turn off the
bits that don't work yet.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

[...]

| There are I think three solutions:
| 
| 	- relax the release criterion which is questionnable.

I agree that is questionnable.

| 	- release only the sub-part of V3 that is stable.

Which sub-part exactly?  The STL?  I can't imagine we won't have I/O
facilities.  If that should be the case then I'd much prefer v-2. 

| 	- use some compiler trickery, I know nothing about...

The compiler is already difficult to understand.  Before going through
additional compiler black magic hackery in order to support a broken
library I would prefer  
  1) we reimplement the front-end (before putting in extra-linguistic 
     magics) 
  2) we invest effort in implementing the library.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC 3.0

[Phil Edwards]

On Tue, Oct 03, 2000 at 01:05:40PM -0400, David Edelsohn wrote:
> >>>>> Joe Buck writes:
> 
> Joe> It seems that most of the problems are associated with the wide characters
> Joe> and locales.  Perhaps have some #ifdef that takes that out on platforms
> Joe> where it doesn't work yet?  We can then test everything else.
> 
> Joe> Or am I missing something?
> 
> 	Shared libraries.
> 	Thread support.
> 	Atomicity.
> 	ctype.

The library does have some --enable/disable flags to help in porting these
kinds of things.  Essentially:  for a new host, disable them all and just
make certain that the library will build.  Then re-enable them one at
a time.  For the points above, we have --disable-shared, --disable-threads,
and --disable-wchar.

Working with glibc 2.2 still presents problems due to the #inclusion of
at least one header that doesn't exist everywhere, or exists but doesn't
define the things which glibc assumes it does.


> 	Bad interaction with vendor headers (_POSIX_SOURCE, _XOPEN_SOURCE, ...)

The library also has a generic --enable-cxx-flags which can pass around
arbitrary compiler flags.  There are serious caveats when using this method,
but it occasionally helps.

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: GCC 3.0

[Theodore Papadopoulo]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

jbuck@racerx.synopsys.com said:

>> Mark writes:
>> I would prefer that we go to a non-conforming -- but approximately
>> working -- implementation sooner, if that is possible.  If we can turn
>> on V3 approximately now, and not make things a whole lot more
>> non-conforming than they already are with V2, that would be a good
>> thing.

> It seems that most of the problems are associated with the wide
> characters and locales.  Perhaps have some #ifdef that takes that out
> on platforms where it doesn't work yet?  We can then test everything
> else. 


Just one more thought that I got when I read Mark's E-mail...

There is the promise floating around that after 3.0 there will be no 
more intempestive ABI changes and IIRC by this people also mean ABI changes
within the C++ standard library. I do not know the current status of 
locales, but if some major work is still under consideration there 
will certainly be some breakage of some sort...

There are I think three solutions:

	- relax the release criterion which is questionnable.
	- release only the sub-part of V3 that is stable.
	- use some compiler trickery, I know nothing about...

Please tell me I'm wrong....

On the other hand, it is clear that V3 should just undergo some "large scale"
testing now, if gcc-3.0 is to come within the next 6 months (certainly
an over-estimation, but sometimes I like pessimistic bounds... all 
the more that g++-3.0 has so many new things :-) ).


--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------



[-- Attachment #2: pgp00000.pgp --]
[-- Type: text/plain, Size: 2006 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii



jbuck@racerx.synopsys.com said:

>> Mark writes:
>> I would prefer that we go to a non-conforming -- but approximately
>> working -- implementation sooner, if that is possible.  If we can turn
>> on V3 approximately now, and not make things a whole lot more
>> non-conforming than they already are with V2, that would be a good
>> thing.

> It seems that most of the problems are associated with the wide
> characters and locales.  Perhaps have some #ifdef that takes that out
> on platforms where it doesn't work yet?  We can then test everything
> else. 


Just one more thought that I got when I read Mark's E-mail...

There is the promise floating around that after 3.0 there will be no 
more intempestive ABI changes and IIRC by this people also mean ABI changes
within the C++ standard library. I do not know the current status of 
locales, but if some major work is still under consideration there 
will certainly be some breakage of some sort...

There are I think three solutions:

	- relax the release criterion which is questionnable.
	- release only the sub-part of V3 that is stable.
	- use some compiler trickery, I know nothing about...

Please tell me I'm wrong....

On the other hand, it is clear that V3 should just undergo some "large scale"
testing now, if gcc-3.0 is to come within the next 6 months (certainly
an over-estimation, but sometimes I like pessimistic bounds... all 
the more that g++-3.0 has so many new things :-) ).


- --------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE52hcLIzTj8qrxOU4RAlPvAJ9tgf++cDv+opc+3Q3f69a28dhx9wCguWC8
IMeBa6IFnR/TcISMDMWL6So=
=FfgP
-----END PGP SIGNATURE-----

Re: GCC 3.0

[Jeffrey A Law]

  In message < 200010031647.JAA10461@racerx.synopsys.com >you write:
  > Mark writes:
  > 
  > > I would prefer that we go to a non-conforming -- but approximately
  > > working -- implementation sooner, if that is possible.  If we can turn
  > > on V3 approximately now, and not make things a whole lot more
  > > non-conforming than they already are with V2, that would be a good
  > > thing.
  > 
  > It seems that most of the problems are associated with the wide characters
  > and locales.  Perhaps have some #ifdef that takes that out on platforms
  > where it doesn't work yet?  We can then test everything else.
If that's all it is, then I'd like to see us go forward, even if it means
we have to ifdef or disable the wide char/locale code somehow.

jeff

Re: GCC 3.0

[Benjamin Kosnik]

> It seems that most of the problems are associated with the wide characters
> and locales.  Perhaps have some #ifdef that takes that out on platforms
> where it doesn't work yet?  We can then test everything else.

Right. Phil Edwards posted a patch on the libstdc++ list to separate most
of the wide character/advanced locale bits from the base narrow character
bits with an enable flag, ie something like
--enable-wchar_t/--disable-wchar_t. This seems like a sane approach.

The rest of the problems center around the merged libio sources: glibc 2.2
and libstdc++-v3 have (mostly) merged sources now, a codebase that is
substantially different than the libio used for libstdc++-v2. I'm not
quite sure if it'll be easiest to work through the libio ports or to
enable the generic, stdio interface as an alternate. (This is what I'm now
working on.)

-benjamin

Re: GCC 3.0

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> It seems that most of the problems are associated with the wide characters
Joe> and locales.  Perhaps have some #ifdef that takes that out on platforms
Joe> where it doesn't work yet?  We can then test everything else.

Joe> Or am I missing something?

	Shared libraries.
	Thread support.
	Atomicity.
	ctype.
	Bad interaction with vendor headers (_POSIX_SOURCE, _XOPEN_SOURCE, ...)

David

Re: GCC 3.0

[Joe Buck]

Mark writes:

> I would prefer that we go to a non-conforming -- but approximately
> working -- implementation sooner, if that is possible.  If we can turn
> on V3 approximately now, and not make things a whole lot more
> non-conforming than they already are with V2, that would be a good
> thing.

It seems that most of the problems are associated with the wide characters
and locales.  Perhaps have some #ifdef that takes that out on platforms
where it doesn't work yet?  We can then test everything else.

Or am I missing something?

Re: GCC 3.0

[Tim Prince]

Some ambitious goals on non-regression were set for g77, but snapshot g77
has been so broken until recently that there wasn't any point in trying the
prescribed tests, nor is there any chance of them running as prescribed on
some of the interesting (but not fully supported) targets.  It could be that
people were waiting to see if anyone thought the thing had reached a stable
enough stage to start trying the regression tests on those "supported"
targets where they ought to be possible.  It could also be that enough of us
thought that g77 had reached a stage where we ought to give up on it being
supported as part of GCC.  Why, I don't even see gcc-2.95.2 being supported
as a standard part of linux distributions, so there seems quite a big
divergence between where GCC is and most of the g77 usage.
----- Original Message -----
From: "Mark Mitchell" <mark@codesourcery.com>
To: <gcc@gcc.gnu.org>
Sent: Sunday, October 01, 2000 11:37 AM
Subject: GCC 3.0


>
> I am becoming increasingly concerned about the release f GCC 3.0.
>
> Progress on some aspects of the GCC 3.0 release criteria (namely,
> turning on libstdc++ V3 and the conversion of the Java front-end to
> use the new C++ ABI) have shown little progress in quite some time.
> Those changes, together with libgcc.so (which, thanks to Richard, we
> are making some progress on) are critical -- and to my knowledge the
> only major pieces of functionality missing.
>
> It is imperative that these items be completed in the near future.
>
> To some extent, this is my fault.  I have tried to avoid riding
> everybody too hard, and I have also not put as much time into GCC
> (coding these bits myself) as I had hoped.  As mentioned before, GCC
> 3.0 is one of my two primary tasks for the next several months; I am
> not scheduled on any other projects.  I hope to redeem myself,
> plugging some holes soon.
>
> On the other hand, I'm disappointed in the follow through from
> maintainers for these parts of the toolchain.  The information about
> what needs doing hasn't changed in several months, and there's been
> little progress.  I understand that everyone has been busy, but the
> failure of this stuff to get done puts me in a difficult position.
>
> Please attempt to focus on these critical issues in the short term.
>
> If you are a volunteer looking for something to do, your contributions
> in these areas will be more valuable than other miscellaneous
> improvements.
>
> Thank you,
>
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Mark Mitchell]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:

    Benjamin> For what it's worth I've backed out of my original plan
    Benjamin> to finish the locale implementation and have now started

Thank you.  I think that is a good decision.

    Benjamin> working on the libstdc++ stabilization and cleanup on
    Benjamin> non-linux platforms. I'll be working on that after the
    Benjamin> namespace/shadow header work gets done, which is
    Benjamin> necessary for a conforming implementation that uses
    Benjamin> namespaces.

I would prefer that we go to a non-conforming -- but approximately
working -- implementation sooner, if that is possible.  If we can turn
on V3 approximately now, and not make things a whole lot more
non-conforming than they already are with V2, that would be a good
thing.

I want to reach approximate functional completeness, slush the
sources, finish functional details, and branch. 

The V3 switchover is gating the new ABI switchover.  Once both of
those have happenned you and I will be wicked busy fixing bugs, but I
will be a happy camper because otherwise we won't even know those bugs
exist. :-(

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0

[Benjamin Kosnik]

Hey Mark.

> Progress on some aspects of the GCC 3.0 release criteria (namely,
> turning on libstdc++ V3 and the conversion of the Java front-end to
> use the new C++ ABI) have shown little progress in quite some time.

Well. 

For what it's worth I've backed out of my original plan to finish the
locale implementation and have now started working on the libstdc++
stabilization and cleanup on non-linux platforms. I'll be working on
that after the namespace/shadow header work gets done, which is
necessary for a conforming implementation that uses namespaces.

I am aware of your impatience, and am sorry for the delay.

-benjamin

Re: GCC 3.0

[H . J . Lu]

On Sun, Oct 01, 2000 at 11:37:09AM -0700, Mark Mitchell wrote:
> 
> I am becoming increasingly concerned about the release f GCC 3.0.
> 
> Progress on some aspects of the GCC 3.0 release criteria (namely,
> turning on libstdc++ V3 and the conversion of the Java front-end to

Just turn on libstdc++ V3 now. I am sure there will expose quite a few
problems. But if no one reports bug, they won't be fixed. Not many
people will work on libstdc++ V3 unless it is configured by default.
The same goes for shared library and threads. Right now you have to
enable them by hand. As far as I can tell from the gcc testsuite
mailing list, not many people do that, even on Linux where shared
library and threads should be enabled by default.

> use the new C++ ABI) have shown little progress in quite some time.
> Those changes, together with libgcc.so (which, thanks to Richard, we
> are making some progress on) are critical -- and to my knowledge the
> only major pieces of functionality missing.
> 

I am very concerned about shared libgcc. There is a discussion on the
patch list. Not all people, myself included, are on the patch list. As
I said, I don't want the shared libgcc to be linked in by default under
Linux. Under Linux, I'd like to see a separate system library with a
published ABI alone with the C library which serves the same purpose
what the shared libgcc is supposed to do.



H.J.

GCC 3.0

[Mark Mitchell]

I am becoming increasingly concerned about the release f GCC 3.0.

Progress on some aspects of the GCC 3.0 release criteria (namely,
turning on libstdc++ V3 and the conversion of the Java front-end to
use the new C++ ABI) have shown little progress in quite some time.
Those changes, together with libgcc.so (which, thanks to Richard, we
are making some progress on) are critical -- and to my knowledge the
only major pieces of functionality missing.

It is imperative that these items be completed in the near future.

To some extent, this is my fault.  I have tried to avoid riding
everybody too hard, and I have also not put as much time into GCC
(coding these bits myself) as I had hoped.  As mentioned before, GCC
3.0 is one of my two primary tasks for the next several months; I am
not scheduled on any other projects.  I hope to redeem myself,
plugging some holes soon.

On the other hand, I'm disappointed in the follow through from
maintainers for these parts of the toolchain.  The information about
what needs doing hasn't changed in several months, and there's been
little progress.  I understand that everyone has been busy, but the
failure of this stuff to get done puts me in a difficult position.

Please attempt to focus on these critical issues in the short term.

If you are a volunteer looking for something to do, your contributions
in these areas will be more valuable than other miscellaneous
improvements.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com