Re: Branching for GCC 3.0

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

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

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

[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

[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

[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

[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

[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

[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

Subreg-byte patches (was: Branching for GCC 3.0)

[Gerald Pfeifer]

On Mon, 8 Jan 2001, Jakub Jelinek wrote:
>>> 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.
> 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.

In my opinion that means we should really consider integrating it into our
mainline ASAP, and in fact an additional release criterion for GCC 3.0.

Else, GNU/Linux distributions for SPARC (which means UltraSPARC these
days) have *no* *choice* but rolling a GCC release of their own, similiar
to what Red Hat did with GCC 2.96, and we certainly don't really want
that, do we?

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

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Joe Buck]

> 

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

Jakub Jelinek wrote:
> > 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.

Gerald writes:
> In my opinion that means we should really consider integrating it into our
> mainline ASAP, and in fact an additional release criterion for GCC 3.0.

> Else, GNU/Linux distributions for SPARC (which means UltraSPARC these
> days) have *no* *choice* but rolling a GCC release of their own, similiar
> to what Red Hat did with GCC 2.96, and we certainly don't really want
> that, do we?

I want to be careful about giving Mark a big additional job to do, but I
see your point.  In an ideal world this thing would have been merged some
time ago, but lacking time machines we have to decide now.

What is the level of effort required to get the subreg patch in?  How
badly have things diverged since 2.96-RH was forked off?

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Geoff Keating]

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

> > 
> 
> > >>> 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.
> 
> Jakub Jelinek wrote:
> > > 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.
> 
> Gerald writes:
> > In my opinion that means we should really consider integrating it into our
> > mainline ASAP, and in fact an additional release criterion for GCC 3.0.
> 
> > Else, GNU/Linux distributions for SPARC (which means UltraSPARC these
> > days) have *no* *choice* but rolling a GCC release of their own, similiar
> > to what Red Hat did with GCC 2.96, and we certainly don't really want
> > that, do we?
> 
> I want to be careful about giving Mark a big additional job to do, but I
> see your point.  In an ideal world this thing would have been merged some
> time ago, but lacking time machines we have to decide now.
> 
> What is the level of effort required to get the subreg patch in?  How
> badly have things diverged since 2.96-RH was forked off?

I would pose another question.

If the patch didn't go in, how soon could we integrate it and make
another release?  Do you think this would be significantly more time
than it would take to integrate and it starting now?

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

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> I would pose another question.

Geoff> If the patch didn't go in, how soon could we integrate it and make
Geoff> another release?  Do you think this would be significantly more time
Geoff> than it would take to integrate and it starting now?

	This is a fundamental question about the release.  How many
features do we want to cram into GCC 3.0 versus getting the release out,
possibly without full functionality on all major platforms.  And then
following up quickly (e.g. 3-6 months) with GCC 3.1 filling in those
missing features.  This would be separate from bug fix updates to GCC 3.0
during this period.

	I think that we need to view GCC 3.0 as a test release and not the
be-all, end-all GCC release.  We probably can ensure that the C compiler
is in good shape, and likely that the C++ compiler and Fortran compiler
will be good as well.  Java (not part of release criteria) and
libstdc++-v3 are much more difficult to get right on all patforms on the
first attempt.

David

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jakub Jelinek]

On Mon, Jan 08, 2001 at 05:01:07PM -0800, Joe Buck wrote:
> > In my opinion that means we should really consider integrating it into our
> > mainline ASAP, and in fact an additional release criterion for GCC 3.0.
> 
> > Else, GNU/Linux distributions for SPARC (which means UltraSPARC these
> > days) have *no* *choice* but rolling a GCC release of their own, similiar
> > to what Red Hat did with GCC 2.96, and we certainly don't really want
> > that, do we?
> 
> I want to be careful about giving Mark a big additional job to do, but I
> see your point.  In an ideal world this thing would have been merged some
> time ago, but lacking time machines we have to decide now.
> 
> What is the level of effort required to get the subreg patch in?

It needs a global write privileges maintainer to spend a day or more
probably couple of days reviewing it. Andrew MacLeod is AFAIK updating
subreg-byte branch to current CVS trunk at the moment, I can put my hands on
it as well.

	Jakub

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Andreas Jaeger]

Jakub,

can you refresh my memory and explain what those patches are doing?
What kind of operations (on registers) are enabled and why is this a
pre requisite for Ultrasparc support?

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jakub Jelinek]

On Tue, Jan 09, 2001 at 11:04:01AM +0100, Andreas Jaeger wrote:
> can you refresh my memory and explain what those patches are doing?
> What kind of operations (on registers) are enabled and why is this a
> pre requisite for Ultrasparc support?

SUBREG's second argument so far (SUBREG_WORD) used to mean for
non-paradoxical SUBREGs the "word count" either within a register
(in which case SUBREG_WORD 0 was the low part) or MEM (in which case
SUBREG_WORD 0 was the smallest memory address).

The major problem SPARC v9 has (there are other architectures with similar
problems) with this is that it is a 64bit architecture, thus WORD size is
64bits, but there are still 32bit registers (float SFmode registers), so
there were problems in expressing e.g. store of high 32bits of 64bit %f8
register) etc. I believe this was the main reason why David Miller and
Richard Henderson (somebody else as well?) decided in 1998 that this needs
to change.

SUBREG_BYTE patches change the meaning of the second SUBREG's argument to
SUBREG_BYTE, plus the meaning is unified between REGs and MEMs, ie.
SUBREG_BYTE 0 is always the lowest addressable part, as if you stored the
whole REG into memory. Thus, lowest 8 bits of some 64bit register on big
endian machine are (subreg:QI (reg:DI xx) 56).

	Jakub

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jeffrey A Law]

  In message < 20010109051946.N1120@devserv.devel.redhat.com >you write:
  > The major problem SPARC v9 has (there are other architectures with similar
  > problems) with this is that it is a 64bit architecture, thus WORD size is
  > 64bits, but there are still 32bit registers (float SFmode registers), so
  > there were problems in expressing e.g. store of high 32bits of 64bit %f8
  > register) etc. I believe this was the main reason why David Miller and
  > Richard Henderson (somebody else as well?) decided in 1998 that this needs
  > to change.
But this can also be solved by other means.

  1. You claim all registers are 64bits wide, including the FP registers.

  2. Obviously you cut the number of FP regs in half


The PA has 28 FP registers (%fr4 - %fr31).  They are 64bits wide.  However,
we can access either half of the 64bit quantity for storing and operating 
on single precision FP values.  For the PA32 port we expose the fact that
we can address the upper and lower halves of the FP registers.

Not surprisingly we ran into the same problem on the PA64 port as you've
run into on the sparc64 port.  However, we solved it in a completely 
different (and IMHO) much simpler, cleaner way.

Specifically we don't expose the fact that we can access the upper and
lower halves of FP registers independently.  ie, we expose 28 FP registers
that can hold either a 64bit value or a 32bit value.

The code is extremely clean and doesn't require any revamping of the
machine independent code because we don't have the SUBREG ambiguity to
deal with.

What did we lose with this scheme?  Nothing in reality.  Yes, we have fewer
places to stuff 32bit FP values (28regs instead of 56regs).  But the way the
FP pipeline works on the PA, it's actually very bad to access the upper and
lower halves of an FP register independently.

I'm not familiar enough with newer sparc architectures to know if this
scheme will work or not.  But I think it's worth consideration.

jeff

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jakub Jelinek]

On Tue, Jan 09, 2001 at 09:51:34AM -0700, Jeffrey A Law wrote:
> 
>   In message < 20010109051946.N1120@devserv.devel.redhat.com >you write:
>   > The major problem SPARC v9 has (there are other architectures with similar
>   > problems) with this is that it is a 64bit architecture, thus WORD size is
>   > 64bits, but there are still 32bit registers (float SFmode registers), so
>   > there were problems in expressing e.g. store of high 32bits of 64bit %f8
>   > register) etc. I believe this was the main reason why David Miller and
>   > Richard Henderson (somebody else as well?) decided in 1998 that this needs
>   > to change.
> But this can also be solved by other means.

I think Richard and DaveM should comment here.
> 
>   1. You claim all registers are 64bits wide, including the FP registers.
> 
>   2. Obviously you cut the number of FP regs in half
> 
> 
> The PA has 28 FP registers (%fr4 - %fr31).  They are 64bits wide.  However,
> we can access either half of the 64bit quantity for storing and operating 
> on single precision FP values.  For the PA32 port we expose the fact that
> we can address the upper and lower halves of the FP registers.
> 
> Not surprisingly we ran into the same problem on the PA64 port as you've
> run into on the sparc64 port.  However, we solved it in a completely 
> different (and IMHO) much simpler, cleaner way.

SPARC v9 is similar here (well, things are little bit more complicated
because first 16 DFmode registers (%f0 - %f30) can be accessed as 32bit
SFmode halves and the remaining 16 DFmode registers (%f32 - %f62) can be
accessed as DFmode only (plus the architecture allows accessing pairs of
DFmode as TFmode but the instructions working on TFmode are software
emulated).
But this would not work for SPARC v9 ABI, because some values are
specifically passed in even and some values in odd SFmode registers (e.g.
float arguments are passed in %f1, %f3, ... while if passing small structure
containing some floats, they should be passed in the corresponding %fX
register, say struct { float f; int i; int j; float h; }; will be passed
as argument in f = %f0, i = %o0, j = upper 32 bits of %o1, h = %f3 ).

	Jakub

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Richard Henderson]

On Tue, Jan 09, 2001 at 12:08:58PM -0500, Jakub Jelinek wrote:
> But this would not work for SPARC v9 ABI, because some values are
> specifically passed in even and some values in odd SFmode registers...

Yes, that is the reason we can't simply hide the SFmode regs.
And by not hiding them we get into troubles with the FP->DImode
conversion instructions, when gcc starts taking subregs of the
DImode result.

This could also be fixed in a different way for 3.0 if necessary,
by using CLASS_CANNOT_CHANGE_MODE, though we would generate worse
code on some common cases because of it.

Long-term, SUBREG_BYTE is the correct solution.


r~

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jeffrey A Law]

  In message < 20010109120858.R1120@devserv.devel.redhat.com >you write:
  > But this would not work for SPARC v9 ABI, because some values are
  > specifically passed in even and some values in odd SFmode registers (e.g.
  > float arguments are passed in %f1, %f3, ... while if passing small structur
  > containing some floats, they should be passed in the corresponding %fX
  > register, say struct { float f; int i; int j; float h; }; will be passed
  > as argument in f = %f0, i = %o0, j = upper 32 bits of %o1, h = %f3 ).
What a mess.  Ugh.  Nevermind, the simple solution won't work for this
ABI.

jeff

Re: Subreg-byte patches (was: Branching for GCC 3.0)

[Jeffrey A Law]

  In message < Pine.BSF.4.31.0101090129360.27889-100000@deneb.dbai.tuwien.ac.at >
you write:
  > On Mon, 8 Jan 2001, Jakub Jelinek wrote:
  > >>> 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 o
  > f
  > >>> the RedHat7 gcc-2.96 AFAIK.
  > > 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.
  > 
  > In my opinion that means we should really consider integrating it into our
  > mainline ASAP, and in fact an additional release criterion for GCC 3.0.
Well, as Richard mentioned, there is an alternate solution.  It has
performance drawbacks for the code generated for the sparc64 though.

Part of me wants badly to get the SUBREG_BYTE stuff installed, but part of
me also wants to avoid it given its size and potential for causing problems.


jeff

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

[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

[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

[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

[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

[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

[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

[dewar]

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


I assume a "de" is missing above?

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

[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

[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

[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

[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

[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

[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

[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

[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