Branch created: gcc-3_3-e500-branch

Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

I've just created a branch called gcc-3_3-e500-branch.  On this branch
I am going to backport the PowerPC/E500 work, done mostly by Aldy
Hernandez, from the mainline sources to 3.3.  I don't have any plans
to merge this branch back onto 3.3, but that might make sense in the
future.

The branch will be regularly updated from the 3.3 branch.  Commits
require explicit approval from me.

zw

Re: Branch created: gcc-3_3-e500-branch

[Kumar Gala]

Why dont you have plans to merge this branch back into 3.3?  It would 
seem useful to make sure that the e500 support in 3.3 was correct, and 
a number of Aldy's patches that have been made to the mainline do that.

- kumar

On Tuesday, April 15, 2003, at 04:43 PM, Zack Weinberg wrote:

>
> I've just created a branch called gcc-3_3-e500-branch.  On this branch
> I am going to backport the PowerPC/E500 work, done mostly by Aldy
> Hernandez, from the mainline sources to 3.3.  I don't have any plans
> to merge this branch back onto 3.3, but that might make sense in the
> future.
>
> The branch will be regularly updated from the 3.3 branch.  Commits
> require explicit approval from me.
>
> zw

Re: Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

Kumar Gala <kumar.gala@motorola.com> writes:

> Why dont you have plans to merge this branch back into 3.3?  It would
> seem useful to make sure that the e500 support in 3.3 was correct, and
> a number of Aldy's patches that have been made to the mainline do that.

It is not appropriate to do it now, when we are trying to stabilize
the branch for the 3.3.0 release.  It may well be a good thing to do
for 3.3.1, but that decision I leave to the PowerPC port maintainers.
I'm certainly not going to object to a merge.

zw

Re: Branch created: gcc-3_3-e500-branch

[Kumar Gala]

Zack,

I could not ask for any more.

Aldy,

Have you pushed all the ABI fixes for e500 to the mainline yet?  It 
would be good to make sure what Zach back ports is actually e500 ABI 
1.0 compatible.

- kumar

On Tuesday, April 15, 2003, at 07:06 PM, Zack Weinberg wrote:

> Kumar Gala <kumar.gala@motorola.com> writes:
>
>> Why dont you have plans to merge this branch back into 3.3?  It would
>> seem useful to make sure that the e500 support in 3.3 was correct, and
>> a number of Aldy's patches that have been made to the mainline do 
>> that.
>
> It is not appropriate to do it now, when we are trying to stabilize
> the branch for the 3.3.0 release.  It may well be a good thing to do
> for 3.3.1, but that decision I leave to the PowerPC port maintainers.
> I'm certainly not going to object to a merge.
>
> zw

Re: Branch created: gcc-3_3-e500-branch

[Gerald Pfeifer]

On Tue, 15 Apr 2003, Zack Weinberg wrote:
> I've just created a branch called gcc-3_3-e500-branch.  On this branch
> I am going to backport the PowerPC/E500 work, done mostly by Aldy
> Hernandez, from the mainline sources to 3.3.  I don't have any plans
> to merge this branch back onto 3.3, but that might make sense in the
> future.
>
> The branch will be regularly updated from the 3.3 branch.  Commits
> require explicit approval from me.

Would you mind documenting this in cvs.html?

Gerald

PS: Laurent, I just realize that there we have a couple of (mostly)
dead branches which nobody submitted information about; what do you
think about removing them?

PPS: I also had an idea on how to make this more structured: Could I
convince you to gather all those branches that have been merged to
mainline in a separate subsubsection at the end of that subsection? ;-)
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Branch created: gcc-3_3-e500-branch

[Aldy Hernandez]

> Have you pushed all the ABI fixes for e500 to the mainline yet?  It 
> would be good to make sure what Zach back ports is actually e500 ABI 
> 1.0 compatible.
>

All my patches are in mainline.  There are still more to come, but 
everything I've done is out on mainline.

Aldy

Re: Branch created: gcc-3_3-e500-branch

[Kumar Gala]

What is left to submit / get working in the mainline w/respect to the 
ABI?

- kumar

On Wednesday, April 16, 2003, at 10:33 AM, Aldy Hernandez wrote:

>> Have you pushed all the ABI fixes for e500 to the mainline yet?  It 
>> would be good to make sure what Zach back ports is actually e500 ABI 
>> 1.0 compatible.
>>
>
> All my patches are in mainline.  There are still more to come, but 
> everything I've done is out on mainline.
>
> Aldy

Re: Branch created: gcc-3_3-e500-branch

[Aldy Hernandez]

On Wednesday, April 16, 2003, at 11:53  AM, Kumar Gala wrote:

> What is left to submit / get working in the mainline w/respect to the 
> ABI?
>

varargs are broken because of GCC infrastructure problems for subregs 
of simd types on hard registers.  I suggested an approach, but Jan 
Hubicka had another idea which he hasn't implemented.  I may kludge it 
on the e500 branch, since there doesn't seem to be an agreement on how 
to fix GCC.

long doubles are broken on purpose on mainline.  The ABI specifies 128 
bit long doubles, but I have left them as 64 bits since there are no 
emulation bits for powerpc-eabi*.

vector types going on varargs, in the named section of the arguments, 
are supposed to be split.  They currently are not.

Everything above I'm "working on".

Finally, there are a mess of multilibs to be built by default.  I have 
a patch, but I'm still testing the multilibs before I commit to 
mainline.

Re: Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> On Tue, 15 Apr 2003, Zack Weinberg wrote:
>> I've just created a branch called gcc-3_3-e500-branch.  On this branch
>> I am going to backport the PowerPC/E500 work, done mostly by Aldy
>> Hernandez, from the mainline sources to 3.3.  I don't have any plans
>> to merge this branch back onto 3.3, but that might make sense in the
>> future.
>>
>> The branch will be regularly updated from the 3.3 branch.  Commits
>> require explicit approval from me.
>
> Would you mind documenting this in cvs.html?

Sure.

zw

===================================================================
Index: cvs.html
--- cvs.html	25 Mar 2003 00:23:04 -0000	1.100
+++ cvs.html	16 Apr 2003 16:50:19 -0000
@@ -268,6 +268,11 @@ particular releases or snapshots or the 
   <dt>x86-64-branch</dt>
   <dd></dd>
 
+  <dt>gcc-3_3-e500-branch</dt>
+  <dd>This branch is for backporting the PowerPC/E500 back end to GCC
+  3.3.  See <a href="http://gcc.gnu.org/ml/gcc/2003-04/msg00733.html"
+  >this message</a> for details.</dd>
+
   <dt>cp-parser-branch</dt>
   <dd>This branch has been merged into the mainline.</dd>
 

Re: Branch created: gcc-3_3-e500-branch

[Jan Hubicka]

> 
> On Wednesday, April 16, 2003, at 11:53  AM, Kumar Gala wrote:
> 
> >What is left to submit / get working in the mainline w/respect to the 
> >ABI?
> >
> 
> varargs are broken because of GCC infrastructure problems for subregs 
> of simd types on hard registers.  I suggested an approach, but Jan 
> Hubicka had another idea which he hasn't implemented.  I may kludge it 
> on the e500 branch, since there doesn't seem to be an agreement on how 
> to fix GCC.

We should proceed somewhat on the SIMD stuff.  I probably won't be able
to work on it in next 3 weeks, so it is bit long since I am burned alive
in my TODO list (bugfixes, merging of patches for 3.3 and so on) and I
am leaving for study in Barcelona.  In case for Motorola bits
implementing the named patterns to extract/set the specific field of
vector (not the RTL construct as I believe we don't need it because we
do have VEC_SELECT/VEC_MERGE/VEC_DUPLICATE), please go forward for it.
I beleive there will be needed anyway even when we will need some more
complex machinery to fit all the weird side corners of SSE instruction
set.

Sorry if I delayed you by being overcomplicating the issue.

Honza
> 
> long doubles are broken on purpose on mainline.  The ABI specifies 128 
> bit long doubles, but I have left them as 64 bits since there are no 
> emulation bits for powerpc-eabi*.
> 
> vector types going on varargs, in the named section of the arguments, 
> are supposed to be split.  They currently are not.
> 
> Everything above I'm "working on".
> 
> Finally, there are a mess of multilibs to be built by default.  I have 
> a patch, but I'm still testing the multilibs before I commit to 
> mainline.

Re: Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

Aldy Hernandez <aldyh@redhat.com> writes:

> varargs are broken because of GCC infrastructure problems for subregs
> of simd types on hard registers.  I suggested an approach, but Jan
> Hubicka had another idea which he hasn't implemented.  I may kludge it
> on the e500 branch, since there doesn't seem to be an agreement on how
> to fix GCC.
>
> long doubles are broken on purpose on mainline.  The ABI specifies 128
> bit long doubles, but I have left them as 64 bits since there are no
> emulation bits for powerpc-eabi*.
>
> vector types going on varargs, in the named section of the arguments,
> are supposed to be split.  They currently are not.
>
> Everything above I'm "working on".
>
> Finally, there are a mess of multilibs to be built by default.  I have
> a patch, but I'm still testing the multilibs before I commit to
> mainline.

Can I impose upon you to test and commit your future E500 patches both
on the mainline and on the new branch?  (Once I've got the backport
done.)  That way people using the branch automatically stay up to date.

zw

Re: Branch created: gcc-3_3-e500-branch

[Aldy Hernandez]

> Can I impose upon you to test and commit your future E500 patches both
> on the mainline and on the new branch?  (Once I've got the backport
> done.)  That way people using the branch automatically stay up to date.

/me whines
/me cries
/me complains

Ok, no problem ;-).  Let me know when you've backported everything.

Re: Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

Aldy Hernandez <aldyh@redhat.com> writes:

>> Can I impose upon you to test and commit your future E500 patches both
>> on the mainline and on the new branch?  (Once I've got the backport
>> done.)  That way people using the branch automatically stay up to date.
>
> /me whines
> /me cries
> /me complains
>
> Ok, no problem ;-).  Let me know when you've backported everything.

Thanks, I really appreciate this.  I should be done by the end of the
week.

zw

Re: Branch created: gcc-3_3-e500-branch

[Kumar Gala]

Zach, Aldy

What's the state of the gcc-3_3-e500-branch?  Is it feasible to merge 
it back into 3.3 so that 3.3.1 has fully working e500 support?

thanks

- kumar

Re: Branch created: gcc-3_3-e500-branch

[Zack Weinberg]

Kumar Gala <kumar.gala@motorola.com> writes:

> Zach, Aldy
>
> What's the state of the gcc-3_3-e500-branch? 

It works, as far as I know.  I need to do another merge from the 3.3
release branch now that GCC 3.3.0 has officially been shipped.  I'm
also considering applying David Edelsohn's patches for the 440 chip;
it's not strictly relevant to the e500, but my clients want it.

> Is it feasible to merge it back into 3.3 so that 3.3.1 has fully
> working e500 support?

That's a question you should be asking the PowerPC port maintainers
and the release manager, not either of us.  I would like to see it
happen; however, some of the changes I had to backport could be seen
as risky, such as the 3.4 genautomata.c (although not any of the rest
of the scheduler).

zw

Re: Branch created: gcc-3_3-e500-branch

[Kumar Gala]

Zach,

Thanks for the relpy.

Mark, Geoff, David

What is your feeling of allowing this branch to be merged back into the 
3.3 line?  I know we have a number of customers that this would greatly 
facilitate.

Thanks

- kumar

On Wednesday, May 14, 2003, at 11:38 PM, Zack Weinberg wrote:

> Kumar Gala <kumar.gala@motorola.com> writes:
>
>> Zach, Aldy
>>
>> What's the state of the gcc-3_3-e500-branch?
>
> It works, as far as I know.  I need to do another merge from the 3.3
> release branch now that GCC 3.3.0 has officially been shipped.  I'm
> also considering applying David Edelsohn's patches for the 440 chip;
> it's not strictly relevant to the e500, but my clients want it.
>
>> Is it feasible to merge it back into 3.3 so that 3.3.1 has fully
>> working e500 support?
>
> That's a question you should be asking the PowerPC port maintainers
> and the release manager, not either of us.  I would like to see it
> happen; however, some of the changes I had to backport could be seen
> as risky, such as the 3.4 genautomata.c (although not any of the rest
> of the scheduler).
>
> zw

altivec testsuite

[Kumar Gala]

Zach,

I believe you where interested in the Altivec testsuite we had produced 
a number of years ago.  We have recently assigned over the copyright of 
the testsuite to the FSF.  I know Aldy was willing at one time to work 
on taking the tests and integration of them into the dejagnu frame work.

- kumar

Re: Branch created: gcc-3_3-e500-branch

[Mark Mitchell]

On Thu, 2003-05-15 at 07:41, Kumar Gala wrote:
> Zach,
> 
> Thanks for the relpy.
> 
> Mark, Geoff, David
> 
> What is your feeling of allowing this branch to be merged back into the 
> 3.3 line?

I feel that there are two many changes in this branch to permit its
being merged back into GCC 3.3.1.  The dot-releases are supposed to
contain fixes for critical defects only.  We have occasionally allowed
new architectures to be merged in on release branches, but only when
they were completely separate and therefore could not impact existing
code.

Yours,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Branch created: gcc-3_3-e500-branch

[Geoff Keating]

> X-Original-To: geoffk@foam.wonderslug.com
> From: Mark Mitchell <mark@codesourcery.com>
> Cc: Zack Weinberg <zack@codesourcery.com>, geoffk@geoffk.org,
>    dje@watson.ibm.com, gcc@gcc.gnu.org, Aldy Hernandez <aldyh@redhat.com>
> Date: 15 May 2003 08:42:59 -0700
> X-OriginalArrivalTime: 15 May 2003 15:43:04.0424 (UTC) FILETIME=[AC77A680:01C31AF8]
> 
> On Thu, 2003-05-15 at 07:41, Kumar Gala wrote:
> > Zach,
> > 
> > Thanks for the relpy.
> > 
> > Mark, Geoff, David
> > 
> > What is your feeling of allowing this branch to be merged back into the 
> > 3.3 line?
> 
> I feel that there are two many changes in this branch to permit its
> being merged back into GCC 3.3.1.  The dot-releases are supposed to
> contain fixes for critical defects only.  We have occasionally allowed
> new architectures to be merged in on release branches, but only when
> they were completely separate and therefore could not impact existing
> code.

I'm inclined to agree; the risks of integrating it into the 3.3
release outweigh the relativly small cost of simply keeping it on the
gcc-3_3-e500-branch during the GCC 3.3 life cycle.

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