Branching for GCC 3.0

Branching for GCC 3.0

[Mark Mitchell]

Richard's patch to support -shared-libgcc was the last functional item
on my list of things to do before GCC 3.0.

(I know that there are still some V3 issues on AIX, and HPUX.  These
need to get resolved before the release, but not necessarily before we
branch.  However, I would like to see these resolved ASAP.  This has
dragged on too long.  Benjamin, do you have access to an AIX box?  If
so, would you mind taking a look at what is going wrong at
initialization-time?)

(I also know that Jason and Richard are interested in incorporating
the high-level bits of the IA64 exception API into GCC.  I fully
support this effort -- but I think I would prefer not to hold up 3.0
for that work.  However, if Jason/Richard have a short-term time frame
for this work, it might make sense to incorporate it.)

Since there is definitely a trend towards major movement on the
mainline, I think it is appropriate to branch for GCC 3.0 sooner,
rather than later.  Many bug-fix patches will need to go on both
branches, but all new functionality can go on the mainline, and help
us keep the release branch stable.

I propose that we branch next weekend, on January 14th, assuming we're
getting successful bootstraps on some major platforms at that point.

As a baseball coach of mine used to say:

  Questions, comments, theories, or philosophies?

Thanks,

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

Re: Branching for GCC 3.0

[Joseph S. Myers]

On Sun, 7 Jan 2001, Mark Mitchell wrote:

> I propose that we branch next weekend, on January 14th, assuming we're
> getting successful bootstraps on some major platforms at that point.
>
> As a baseball coach of mine used to say:
>
>   Questions, comments, theories, or philosophies?

In no particular order:

* What's the rest of the release schedule?

* Can we have the htdocs/gcc-3.0/ directory filled out with schedule,
release notes, caveats, etc.?  Though I put features.html there so as to
obsolete NEWS, it and the other pages need filling out with the various
items that have appeared in the News section of the web pages and whatever
else people put in.

* Will the old libstdc++ still be included in 3.0 (in which case
references to EGCS in it should be cleaned up, etc.)?

* Will Java be moving its web pages / mailing lists to gcc.gnu.org before
the release?

A couple of specific questions from the "Open Issues" in the release
criteria:

     * Should -fstrict-aliasing be enabled?

     * Which open bugs need to be fixed?
(i.e., what will be happening in the way of cleaning up the fairly
meaningless priorities in GNATS so that the PRs marked "high" are those
considered release critical?)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Branching for GCC 3.0

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

[...]

| * Will the old libstdc++ still be included in 3.0 (in which case
| references to EGCS in it should be cleaned up, etc.)?

I'll vote no.

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

Re: Branching for GCC 3.0

[Jonathan Larmour]

In article < 20010107125803Q.mitchell@codesourcery.com > you write:
>
>Richard's patch to support -shared-libgcc was the last functional item
>on my list of things to do before GCC 3.0.

If gcc is branched now, does this mean that the libgcc ABI is now set
in stone?

I am specifically wondering because I wanted to investigate tidying up
the "gthread" API, but I hadn't had time - but I was very specifically
going to be given time soon (not before next week :-)).

My concern is that if I don't get it in in time for this branch it can
never ever happen... And similarly with any other future changes that
may ever change the libgcc ABI.

Or are my worries about the ABI unnecessary?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: Branching for GCC 3.0

[Phil Edwards]

On Mon, Jan 08, 2001 at 01:44:05PM +0100, Gabriel Dos Reis wrote:
> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> 
> | * Will the old libstdc++ still be included in 3.0 (in which case
> | references to EGCS in it should be cleaned up, etc.)?
> 
> I'll vote no.

I agree with Gaby.  The -v2 library predates the C++ standard and thus is
so noncompliant it's scary.  (Its authors should still be credited with
doing an excellent job, given that they weren't seers nor prophets and
couldn't have known what the LWG would end up with.)

I don't believe retaining the v2 library as part of the distribution
best serves anybody.  Maybe it should be archived with instructions on
how to install it with --disable-libstdcxx-v3, in case a user needs a
pre-standard library.


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: Branching for GCC 3.0

[Joe Buck]

> If gcc is branched now, does this mean that the libgcc ABI is now set
> in stone?

It was our intention to have an ABI that would live for a long time or
at least be backward-compatible.  So anything that conflicts with that
needs to be resolved in a hurry.

Re: Branching for GCC 3.0

[Jonathan Larmour]

Joe Buck wrote:
> 
> > If gcc is branched now, does this mean that the libgcc ABI is now set
> > in stone?
> 
> It was our intention to have an ABI that would live for a long time or
> at least be backward-compatible.  So anything that conflicts with that
> needs to be resolved in a hurry.

Thinking about another option, would there be any difficulties with ABI
changes for targets that don't use a shared libgcc? Presumably not since
it's the same as before?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: Branching for GCC 3.0

[Joseph S. Myers]

On Mon, 8 Jan 2001, Jonathan Larmour wrote:

> If gcc is branched now, does this mean that the libgcc ABI is now set
> in stone?

What about the symbols marked with ??? in libgcc-std.ver?  They need to
either go or not, now.

  # Basic block profile symbols.
  # ??? Some of these are for `-a', which ought to die.
  __bb
  __bb_exit_func
  __bb_fork_func
  __bb_init_func
  __bb_init_trace_func
  __bb_trace_func
  __bb_trace_ret

  # ??? Symbols that perhaps unused should be nuked.
  __builtin_saveregs
  __clear_cache
  __dummy
  __empty
  __eprintf
  __gcc_bcmp

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Branching for GCC 3.0

[Marc Espie]

In article < 20010107125803Q.mitchell@codesourcery.com > you write:

>Since there is definitely a trend towards major movement on the
>mainline, I think it is appropriate to branch for GCC 3.0 sooner,
>rather than later.  Many bug-fix patches will need to go on both
>branches, but all new functionality can go on the mainline, and help
>us keep the release branch stable.

>  Questions, comments, theories, or philosophies?

I have some patches for various OpenBSD platforms (including the missing
configuration fragments for ppc and a few others) that I definitely like to
see in gcc 3.0, since these appear to be working (gcc 3.0 bumps 
notwithstanding).

My only problem is that I've been very busy checking patches and verifying
whether 2.95.3 candidate works or not, vax et al.

Since those patches won't hinder the release, I assume they're still okay
even a bit after january 14th, right ?

Otherwise, making the gcc 3.0 branch date almost coincide with the 2.95.3
release date is a bit unfair for those of us with an investment in making
stable releases work...

Re: Branching for GCC 3.0

[Mark Mitchell]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

    Marc> Since those patches won't hinder the release, I assume
    Marc> they're still okay even a bit after january 14th, right ?

Yes.

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

Re: Branching for GCC 3.0

[Chris G. Demetriou]

jbuck@racerx.synopsys.com (Joe Buck) writes:
> > If gcc is branched now, does this mean that the libgcc ABI is now set
> > in stone?
> 
> It was our intention to have an ABI that would live for a long time or
> at least be backward-compatible.  So anything that conflicts with that
> needs to be resolved in a hurry.

y'all might look at:

	http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00967.html

(I've not had time lately to even think about reposting it... 8-S)


chris

Re: Branching for GCC 3.0

[Mark Mitchell]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

    Joseph> In no particular order:

    Joseph> * What's the rest of the release schedule?

I have a new policy on this topic: I utterly refuse to speculate.

The reason is simple: I do not control many of the critical resources
involved.  To date, many things have taken longer than I had hoped,
largely due to people who agreed to do things being unable to complete
those things on anything approximating the agreed-upon schedule.

I've therefore decided to be more humble; I will try to guide the
process, make good decisions along the way, and do all I can to fix
bugs, etc. -- but I cannot commit to a schedule.  Not that I won't
hound people who I think could/should be helping out... :-)

    Joseph> * Can we have the htdocs/gcc-3.0/ directory filled out
    Joseph> with schedule, release notes, caveats, etc.?  Though I put
    Joseph> features.html there so as to obsolete NEWS, it and the
    Joseph> other pages need filling out with the various items that
    Joseph> have appeared in the News section of the web pages and
    Joseph> whatever else people put in.

Those are all good things, but it's premature to write release notes,
etc. at this point.

    Joseph> * Will the old libstdc++ still be included in 3.0 (in
    Joseph> which case references to EGCS in it should be cleaned up,
    Joseph> etc.)?

No.  As soon as GCJ doesn't need it, we will remove V2 from the source
tree.  At least I think that's what we agreed upon the last time this
went around.

    Joseph> * Will Java be moving its web pages / mailing lists to
    Joseph> gcc.gnu.org before the release?

I sure hope so.

    Joseph> A couple of specific questions from the "Open Issues" in
    Joseph> the release criteria:

    Joseph>      * Should -fstrict-aliasing be enabled?

As I've stated before, I am going to remain entirely agnostic on this
issue.  The SC will have to make a decision.  The SC rules do not
allow me to abstain from voting (IIRC), but I will not engage in any
debate on the issue.

    Joseph>      * Which open bugs need to be fixed?  (i.e., what will
    Joseph> be happening in the way of cleaning up the fairly
    Joseph> meaningless priorities in GNATS so that the PRs marked
    Joseph> "high" are those considered release critical?)

We will need volunteers for that.  Once we branch, this will become
one of the next major tasks.  Together with the functional
requirements (largely met at this time), we will use the open bugs to
drive the robustness of the release.  That will be the major metric of
when we are "done enough".

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

Re: Branching for GCC 3.0

[Martin Kahlert]

Hello Mark,

On Tue, Jan 09, 2001 at 11:44:39AM -0800, Mark Mitchell wrote:
> >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>     Joseph> * Will Java be moving its web pages / mailing lists to
>     Joseph> gcc.gnu.org before the release?
> 
> I sure hope so.

So the java and the gcc teams are separated up to now?
When i have questions regarding gjc should i write to the
java-discuss or to the gcc list?
I thought, that after the integration the gcc list would be enough.

Background: I find the java to object file compilation quite usable
(without any optimization at least), but .class ---> .o is very
instable for large sources (the problem seems to be GC). Since i am
not allowed to give these files away, i have to dig into them myself,
but i would need some basic information on how this all is supposed to
work, for example, when can which memory pool be garbage collected
and so on. So i would like to ask some questions.

Thanks,
Martin.

-- 
The early bird gets the worm. If you want something else for       
breakfast, get up later.

Re: Branching for GCC 3.0

[Mark Mitchell]

>>>>> "Martin" == Martin Kahlert <martin.kahlert@infineon.com> writes:

    Martin> Hello Mark,

    Martin> On Tue, Jan 09, 2001 at 11:44:39AM -0800, Mark Mitchell
    Martin> wrote:
    >> >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
    Joseph> * Will Java be moving its web pages / mailing lists to
    Joseph> gcc.gnu.org before the release?
    >>  I sure hope so.

    Martin> So the java and the gcc teams are separated up to now?

To some extent -- but much less so that they used to be.  Everybody is
working hard to achieve a closer working relationship.

    Martin> When i have questions regarding gjc should i write to the
    Martin> java-discuss or to the gcc list?  I thought, that after
    Martin> the integration the gcc list would be enough.

Most Java discussions are still taking place on the Java lists.

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

Re: Branching for GCC 3.0

[Nathan Sidwell]

Mark Mitchell wrote:
>     Joseph>      * Which open bugs need to be fixed?  (i.e., what will
>     Joseph> be happening in the way of cleaning up the fairly
>     Joseph> meaningless priorities in GNATS so that the PRs marked
>     Joseph> "high" are those considered release critical?)
> 
> We will need volunteers for that.  Once we branch, this will become
> one of the next major tasks.  Together with the functional
> requirements (largely met at this time), we will use the open bugs to
> drive the robustness of the release.  That will be the major metric of
> when we are "done enough".
You mean the ratio of analyzed high priority to closed high priority bugs.

When going through the C++ bugs, I've refrained from prioritizing them
when setting them to analyzed. Though I did mark two as high priority
- not that it's actually sped up me getting to them!

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Branching for GCC 3.0

[Alexandre Petit-Bianco]

Martin Kahlert <martin.kahlert@infineon.com> writes:

> When i have questions regarding gjc should i write to the
> java-discuss or to the gcc list?

It's probably better to write to `java-discuss', though we also
monitor what goes in gcc, gcc-patches and gcc-bugs.

./A

Re: Branching for GCC 3.0

[Mike Stump]

> Date: Mon, 8 Jan 2001 11:47:48 -0500 (EST)
> From: Brad Lucier <lucier@math.purdue.edu>
> To: lucier@math.purdue.edu, mark@codesourcery.com
> Cc: gcc@gcc.gnu.org

> I've assumed for some months (years?) that some people are getting
> paid to work on gcc; the amount of effort that many people are
> putting into it seems far beyond what would be possible on a
> volunteer basis.

What, us to get paid to work on gcc, no...  :-)

Re: Branching for GCC 3.0

[Geoff Keating]

> From: dewar@gnat.com
> Cc: gcc@gcc.gnu.org
> Date: Sun,  7 Jan 2001 21:08:45 -0500 (EST)
> 
> We certainly consider the support of 64-bit Ultrasparc to be very
> important, and we definitely need this for the first complete GNAT
> release using 3.x.

I believe Red Hat has a similar opinion for its Sparc Linux releases,
and so we used the subreg-byte patches for our Linux compilers.  We
also used them for our Solaris compilers for Sun.

(Of course, these statements are irrelevant to the 3.0 release since
it will not have Ada and will not be a Red Hat compiler.  Hopefully
the 3.1 release will have Ada, but hopefully it won't require the
subreg-byte patches just to get Ada into the tree.)

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Branching for GCC 3.0

[Jakub Jelinek]

On Mon, Jan 08, 2001 at 09:54:13AM -0700, Jeffrey A Law wrote:
> 
>   In message < 5.0.2.1.2.20010108173238.020e8c80@mail.lauterbach.com >you write:
>   > Well, actually I would think the subreg-byte-branch got more real world 
>   > testing on alpha/x86/sparc than the current mainline, cause it's part of 
>   > the RedHat7 gcc-2.96 AFAIK.
> I believe the patch is only installed into the sources if you're building
> a sparc platform.  I don't think it gets used on any other platform.

No, the patch is used on all platforms (ie. alpha, x86, sparc, sparc64 at
least, plus I think some people are using the same source on powerpc) all
the time.

	Jakub

Re: Branching for GCC 3.0

[Franz Sirl]

At 17:54 2001-01-08, Jeffrey A Law wrote:

>   In message < 5.0.2.1.2.20010108173238.020e8c80@mail.lauterbach.com >you 
> write:
>   > Well, actually I would think the subreg-byte-branch got more real world
>   > testing on alpha/x86/sparc than the current mainline, cause it's part of
>   > the RedHat7 gcc-2.96 AFAIK.
>I believe the patch is only installed into the sources if you're building
>a sparc platform.  I don't think it gets used on any other platform.

No, I just checked gcc.spec again, it's not conditionalized AFAICS.

Franz.

Re: Branching for GCC 3.0

[Jeffrey A Law]

  In message < 5.0.2.1.2.20010108173238.020e8c80@mail.lauterbach.com >you write:
  > Well, actually I would think the subreg-byte-branch got more real world 
  > testing on alpha/x86/sparc than the current mainline, cause it's part of 
  > the RedHat7 gcc-2.96 AFAIK.
I believe the patch is only installed into the sources if you're building
a sparc platform.  I don't think it gets used on any other platform.

jeff

Re: Branching for GCC 3.0

[Brad Lucier]

> From mitchell@codesourcery.com  Sun Jan  7 17:52:38 2001
> 
>     Brad> Considering how many years Sun's 64-bit Ultrasparc
>     Brad> implementation has been out without proper support from gcc,
>     Brad> this may be considered an embarrassment.
> 
> It's the usual volunteer-driven thing; there's been eons of time to
> get 64-bit Ultrasparc into GCC, and if it hasn't happenned yet, that
> can only indicate that it is either hard, or that nobody has been
> terribly motivated.

I've assumed for some months (years?) that some people are getting paid
to work on gcc; the amount of effort that many people are putting into
it seems far beyond what would be possible on a volunteer basis.

So if Sun paid Red Hat to have Jakub work on the subreg-byte branch,
maybe it's Red Hat that should be embarrassed that it isn't ready for
3.0?  (1/2 :-)

As a side remark, Jakub has posted (excellent) regression results for
the subreg-byte branch from last July, so it seems to have been in
pretty good form for some time.

Personally, I've basically given up on gcc on Sparc; since I bought an
Alpha machine, I've been doing nearly all my heavy-duty work on the
alpha.  Until Jeff pointed it out, I hadn't realized how big a job it
might be to merge the subreg-byte branch; I had assumed that a merge
would not be so bad, and that it could be done in time for the branch.

Brad

Re: Branching for GCC 3.0

[Franz Sirl]

At 17:16 2001-01-08, Robert Lipe wrote:
>Jeffrey A Law wrote:
> >   In message < 20010107145939R.mitchell@codesourcery.com >you write:
> >   > It's the usual volunteer-driven thing; there's been eons of time to
> >   > get 64-bit Ultrasparc into GCC, and if it hasn't happenned yet, that
> >   > can only indicate that it is either hard, or that nobody has been
> >   > terribly motivated.
> > That is the core of the problem.  The subreg patch is big and touches
> > just about every file that deals with RTL if I understand correctly.
>
>Additionally, in fairness to Mark's sanity, the GCC3 criteria were
>published for comment some time ago.  Neither the words "ultra" or
>"v9" appear in it.  At the last moment, suggesting the inclusion of
>additional work that hasn't seen as much testing isn't likely to be well
>received.

Well, actually I would think the subreg-byte-branch got more real world 
testing on alpha/x86/sparc than the current mainline, cause it's part of 
the RedHat7 gcc-2.96 AFAIK.
Also if the merge with the mainline is postponed after 3.0 is branched off, 
that will make backporting fixes to the gcc-3_0-branch much more difficult.

So I believe we should at least seriously think about a possible inclusion 
into 3.0.

What I would like to see is something like:

  - bring the subreg-byte-branch uptodate with the mainline
  - encourage developers to commit all changes to both mainline and branch 
for a few days
  - analyze any differences in the testresults

This should give us a better picture if merging the subreg-byte-branch 
makes sense for 3.0.

Franz.

Re: Branching for GCC 3.0

[Robert Lipe]

Jeffrey A Law wrote:
>   In message < 20010107145939R.mitchell@codesourcery.com >you write:
>   > It's the usual volunteer-driven thing; there's been eons of time to
>   > get 64-bit Ultrasparc into GCC, and if it hasn't happenned yet, that
>   > can only indicate that it is either hard, or that nobody has been
>   > terribly motivated.
> That is the core of the problem.  The subreg patch is big and touches
> just about every file that deals with RTL if I understand correctly.

Additionally, in fairness to Mark's sanity, the GCC3 criteria were
published for comment some time ago.  Neither the words "ultra" or
"v9" appear in it.  At the last moment, suggesting the inclusion of
additional work that hasn't seen as much testing isn't likely to be well
received.

Signed,
Having Flashbacks To Marketing Changing Requirements at the End of Code Freeze.

Re: Branching for GCC 3.0

[Jeffrey A Law]

  In message < 20010107145939R.mitchell@codesourcery.com >you write:
  > It's the usual volunteer-driven thing; there's been eons of time to
  > get 64-bit Ultrasparc into GCC, and if it hasn't happenned yet, that
  > can only indicate that it is either hard, or that nobody has been
  > terribly motivated.
That is the core of the problem.  The subreg patch is big and touches
just about every file that deals with RTL if I understand correctly.

Getting someone to review a patch of that magnitude is tough.  

jeff

Re: Branching for GCC 3.0

[dewar]

We certainly consider the support of 64-bit Ultrasparc to be very
important, and we definitely need this for the first complete GNAT
release using 3.x.

Robert Dewar

Re: Branching for GCC 3.0

[Brad Lucier]

> 
> Brad Lucier <lucier@math.purdue.edu> writes:
> 
> > Considering how many years Sun's 64-bit Ultrasparc implementation has been
> > out without proper support from gcc, this may be considered an embarrassment.
> > 
> > But maybe it is Sun that should be embarrassed; I can't imagine why they
> > haven't thrown even a little bit of money at gcc development to get this
> > situation fixed.
> 
> To be fair, they did; I believe that's one of the reasons there is a
> subreg-byte branch at all.
> 
> I guess the important thing is that if we release GCC 3.0 without the
> subreg-byte stuff, then it gets integrated right afterwards, so that
> at least it'll be in GCC 3.1.

For the record, I'm most interested in 64-bit support for floating
point code.  In 32-bit mode, one can use 16 fp regs; in 64-bit land,
one gets 32 registers, and this can make a big difference.

Brad

Re: Branching for GCC 3.0

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> To be fair, they did; I believe that's one of the reasons there is a
Geoff> subreg-byte branch at all.

	I would not be surprised if this were just one of many support
contracts from companies who thought that functionality they paid for and
full support for their platform would be incorporated into the next FSF
release.

David

Re: Branching for GCC 3.0

[Geoff Keating]

Brad Lucier <lucier@math.purdue.edu> writes:

> Considering how many years Sun's 64-bit Ultrasparc implementation has been
> out without proper support from gcc, this may be considered an embarrassment.
> 
> But maybe it is Sun that should be embarrassed; I can't imagine why they
> haven't thrown even a little bit of money at gcc development to get this
> situation fixed.

To be fair, they did; I believe that's one of the reasons there is a
subreg-byte branch at all.

I guess the important thing is that if we release GCC 3.0 without the
subreg-byte stuff, then it gets integrated right afterwards, so that
at least it'll be in GCC 3.1.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Branching for GCC 3.0

[dewar]

>are likely to be stabilizing on other targets, this will probably have


I assume a "de" is missing above?

Re: Branching for GCC 3.0

[Mark Mitchell]

>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:

    >>  I'd like to see GCC 3.0 support 64-bit binaries on sparc,
    >> which would involve merging Jakub's subreg-branch.
    >> 
    >> I have no objection in principle -- but this is definitely not
    >> a high priority.  And, if the subreg branch contains
    >> substantial changes that are likely to be stabilizing on other
    >> targets, this will probably have

    Brad>                    ^^^^^^^^^^^ I presume you mean
    Brad> destabilizing.

Indeed.  Sorry!

    >> to wait.

    Brad> Considering how many years Sun's 64-bit Ultrasparc
    Brad> implementation has been out without proper support from gcc,
    Brad> this may be considered an embarrassment.

It's the usual volunteer-driven thing; there's been eons of time to
get 64-bit Ultrasparc into GCC, and if it hasn't happenned yet, that
can only indicate that it is either hard, or that nobody has been
terribly motivated.

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

Re: Branching for GCC 3.0

[Brad Lucier]

> 
>   I'd like to see GCC 3.0 support 64-bit binaries on sparc,
>   which would involve merging Jakub's subreg-branch.
> 
> I have no objection in principle -- but this is definitely not a high
> priority.  And, if the subreg branch contains substantial changes that
> are likely to be stabilizing on other targets, this will probably have
                   ^^^^^^^^^^^
I presume you mean destabilizing.

> to wait.

Considering how many years Sun's 64-bit Ultrasparc implementation has been
out without proper support from gcc, this may be considered an embarrassment.

But maybe it is Sun that should be embarrassed; I can't imagine why they
haven't thrown even a little bit of money at gcc development to get this
situation fixed.

Brad

Re: Branching for GCC 3.0

[Mark Mitchell]

  I'd like to see GCC 3.0 support 64-bit binaries on sparc,
  which would involve merging Jakub's subreg-branch.

I have no objection in principle -- but this is definitely not a high
priority.  And, if the subreg branch contains substantial changes that
are likely to be stabilizing on other targets, this will probably have
to wait.

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

Re: Branching for GCC 3.0

[Brad Lucier]

I'd like to see GCC 3.0 support 64-bit binaries on sparc,
which would involve merging Jakub's subreg-branch.

Brad