Re: Freescale 68HC11/68HC12 port

[Paolo Bonzini]

On 01/26/2011 03:55 PM, James Murray wrote:

On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:


Stephane Carrez is listed as maintainer of the port, so he should
know how to contribute fixes to the port upstream.



Yes, but as I said... he is no longer active on this port. His last
published contributions are 4+ years ago.


I agree, we should deprecate m68hc11.  When I did the cond-optab work 
the port was hardly able to generate code.


Paolo

Re: Proposal: Improving patch tracking and review using Rietveld

[Paolo Bonzini]

On 01/26/2011 08:56 PM, Diego Novillo wrote:

At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).

The best way of thinking about it is "bugzilla for patches".  The
system creates an entry for every patch submitted, provides a web tool
for manipulating the patch (comments, different views of the diff,
highlighting, etc) and it also has an email gateway.

We have discussed patch tracking mechanisms in the past, and none so
far has taken hold.  The reason why I like Rietveld is that it doesn't
really matter whether we all switch to using it at once:

1- Rietveld always send the patch sent to it to gcc-patches@ (provided
the submitter added gcc-patches to the CC list).
2- The whole trail of discussion on the patch also get sent to
gcc-patches and everyone else is CC'd in it.
3- Reviewers do not need to use the web tool to reply to the patch.
One can simply respond to the e-mail, and it will get added to the
patch discussion trail.


How does this work WRT multiple versions of the same patch?

Paolo

Re: Proposal: Improving patch tracking and review using Rietveld

[Richard Guenther]

On Wed, Jan 26, 2011 at 8:56 PM, Diego Novillo  wrote:
> At Google we use a code review tool which was open sourced a couple of
> years ago: Rietveld
> (http://code.google.com/appengine/articles/rietveld.html).
>
> The best way of thinking about it is "bugzilla for patches".  The
> system creates an entry for every patch submitted, provides a web tool
> for manipulating the patch (comments, different views of the diff,
> highlighting, etc) and it also has an email gateway.
>
> We have discussed patch tracking mechanisms in the past, and none so
> far has taken hold.  The reason why I like Rietveld is that it doesn't
> really matter whether we all switch to using it at once:
>
> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided
> the submitter added gcc-patches to the CC list).
> 2- The whole trail of discussion on the patch also get sent to
> gcc-patches and everyone else is CC'd in it.
> 3- Reviewers do not need to use the web tool to reply to the patch.
> One can simply respond to the e-mail, and it will get added to the
> patch discussion trail.
>
> So, for people who do not want to use the tool, Rietveld will not get
> in the way.  They can simply respond to the patch as usual, and as
> long as they keep the rietveld email address in the CC list, the patch
> trail will be updated automatically.
>
> At Google we will start using Rietveld to send patches.  The only
> difference folks will notice is that Rietveld-generated email has some
> extra text.
>
> I have created a wiki page that explains the basics of using Rietveld
> (thanks Jeffrey for the instructions):
> http://gcc.gnu.org/wiki/rietveld
>
> Once again, I'd like to underscore the fact that if a patch submitter
> chooses to use Rietveld for tracking their patches, this should not
> affect in any way the traditional mail-based review.  All I ask is
> that reviewers maintain the CC and Subject line intact in order to not
> confuse the tool.
>
> Jeffrey, would you mind looking over the instructions I've written to
> make sure they're correct?

Does the tool know when a patch is approved or rejected based on
review e-mail content?  Does it track patches that are related
somehow (either split patch series or updates to patches after
these are requested from a reviewer)?  And how does this integrate
with reviewers not using the tool but old-style e-mails?

Thus, is the tool useful to track stalled patches?  (does it know when
a patch is committed and where?)

Richard.

Re: Proposal: Improving patch tracking and review using Rietveld

[Paolo Bonzini]

On 01/26/2011 08:56 PM, Diego Novillo wrote:

At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).

The best way of thinking about it is "bugzilla for patches".  The
system creates an entry for every patch submitted, provides a web tool
for manipulating the patch (comments, different views of the diff,
highlighting, etc) and it also has an email gateway.

We have discussed patch tracking mechanisms in the past, and none so
far has taken hold.  The reason why I like Rietveld is that it doesn't
really matter whether we all switch to using it at once:

1- Rietveld always send the patch sent to it to gcc-patches@ (provided
the submitter added gcc-patches to the CC list).
2- The whole trail of discussion on the patch also get sent to
gcc-patches and everyone else is CC'd in it.
3- Reviewers do not need to use the web tool to reply to the patch.
One can simply respond to the e-mail, and it will get added to the
patch discussion trail.


How does this work WRT multiple revisions of the same patch?

I am taking the liberty of CCing qemu-devel since I forwarded your 
message there.


Paolo

Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[Laurynas Biveinis]

The --enable-checking=valgrind does two things. First, it provides
Valgrind annotations for internal GCC allocators so that Valgrind has
a better idea about memory blocks which are not supposed to be
accessed. Second, it actually invokes Valgrind on every compiler
invocation. This makes the option very nice for e.g. ensuring that
bootstrap and testsuite are Valgrind-clean. However if one wants to
use Valgrind only to analyze a particular testcase, then the price of
full Valgrind'ified bootstrap is prohibitive.

Thus I propose to separate the two. To avoid introducing another
--enable-checking option, let's move the annotations to the "misc"
checking and also enable "misc" too if "valgrind" is requested. Both
these options are disabled for releases, so no performance loss there.

There are two drawbacks I can think of. First, if one wants Valgrind
annotations but does not have the required headers, then the compiler
will be built without them - silently (currently
--enable-checking=valgrind fails if headers are not found). Second,
the compiler binary will be built slightly different if "misc" is
enabled depending on the presence or absence of those headers. I
believe these are minor enough.

I have a prototype patch which I've been using on gc-improv (not
committed there yet).

What do you think?

-- 
Laurynas

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[Richard Guenther]

On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis
 wrote:
> The --enable-checking=valgrind does two things. First, it provides
> Valgrind annotations for internal GCC allocators so that Valgrind has
> a better idea about memory blocks which are not supposed to be
> accessed. Second, it actually invokes Valgrind on every compiler
> invocation. This makes the option very nice for e.g. ensuring that
> bootstrap and testsuite are Valgrind-clean. However if one wants to
> use Valgrind only to analyze a particular testcase, then the price of
> full Valgrind'ified bootstrap is prohibitive.
>
> Thus I propose to separate the two. To avoid introducing another
> --enable-checking option, let's move the annotations to the "misc"
> checking and also enable "misc" too if "valgrind" is requested. Both
> these options are disabled for releases, so no performance loss there.
>
> There are two drawbacks I can think of. First, if one wants Valgrind
> annotations but does not have the required headers, then the compiler
> will be built without them - silently (currently
> --enable-checking=valgrind fails if headers are not found). Second,
> the compiler binary will be built slightly different if "misc" is
> enabled depending on the presence or absence of those headers. I
> believe these are minor enough.
>
> I have a prototype patch which I've been using on gc-improv (not
> committed there yet).
>
> What do you think?

I think we should drop the behavior that --enable-checking=valgrind
invokes valgrind, this seems like an odd feature.  Doing the annotations
under an --enable-checking flag also sounds odd, we for example
have --enable-gather-detailed-mem-stats, I'd have expected a
--enable-valgrind-annotations to do that.

I have no preference how to change the existing (odd) behavior, but
maybe introduce --enable-valgrind-annotations for the annotations
and enable that when valgrind checking is enabled?

Richard.

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

[H.J. Lu]

On Thu, Jan 27, 2011 at 5:08 AM, Richard Guenther
 wrote:
> On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis
>  wrote:
>> The --enable-checking=valgrind does two things. First, it provides
>> Valgrind annotations for internal GCC allocators so that Valgrind has
>> a better idea about memory blocks which are not supposed to be
>> accessed. Second, it actually invokes Valgrind on every compiler
>> invocation. This makes the option very nice for e.g. ensuring that
>> bootstrap and testsuite are Valgrind-clean. However if one wants to
>> use Valgrind only to analyze a particular testcase, then the price of
>> full Valgrind'ified bootstrap is prohibitive.
>>
>> Thus I propose to separate the two. To avoid introducing another
>> --enable-checking option, let's move the annotations to the "misc"
>> checking and also enable "misc" too if "valgrind" is requested. Both
>> these options are disabled for releases, so no performance loss there.
>>
>> There are two drawbacks I can think of. First, if one wants Valgrind
>> annotations but does not have the required headers, then the compiler
>> will be built without them - silently (currently
>> --enable-checking=valgrind fails if headers are not found). Second,
>> the compiler binary will be built slightly different if "misc" is
>> enabled depending on the presence or absence of those headers. I
>> believe these are minor enough.
>>
>> I have a prototype patch which I've been using on gc-improv (not
>> committed there yet).
>>
>> What do you think?
>
> I think we should drop the behavior that --enable-checking=valgrind
> invokes valgrind, this seems like an odd feature.  Doing the annotations

I think it is useful. I have run --enable-checking=valgrind once and it
took daays to finish.  But I haven't got time analyze the result.

-- 
H.J.

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Thu, Jan 27, 2011 at 05:24, Paolo Bonzini  wrote:

> How does this work WRT multiple versions of the same patch?

It supports refreshening the patch.  See for instance the phony review
I've set up with some random changes I've made to the pph branch
(http://codereview.appspot.com/4060045/).

Different patches sent can be viewed as different patchsets for the
same issue, or they can be viewed as a single unified patch.


Diego.

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Thu, Jan 27, 2011 at 05:25, Richard Guenther
 wrote:

> Does the tool know when a patch is approved or rejected based on
> review e-mail content?

I don't think so (the internal version we use does, but I haven't seen
this one implement the same scoring system).  An issue is either open
or closed.  The original sender can close it once it's been approved.

> Does it track patches that are related
> somehow (either split patch series or updates to patches after
> these are requested from a reviewer)?

Yes, a single issue can track multiple versions of the same patch and
patch sets.  The tool can show you different views of the patches as
well.

> And how does this integrate
> with reviewers not using the tool but old-style e-mails?

If you respond by e-mail (with the subject and CC lines untouched), it
will add the email to the issue trail, just like bugzilla does.

>
> Thus, is the tool useful to track stalled patches?  (does it know when
> a patch is committed and where?)

Issues will remain visible to you (when you log in) until they are
marked closed by the patch creator.  So, yes.  I don't think the tool
knows when the patch is committed, though.

Currently, we are using the standard deployment of Rietveld on
appspot, but if we find this generally useful we could deploy another
instance on sourceware.  It should not be hard and I'd volunteer to do
it if there is sufficient interest.  I would like to give it a try
first, though.


Diego.

Re: Proposal: Improving patch tracking and review using Rietveld

[Richard Guenther]

On Thu, Jan 27, 2011 at 3:46 PM, Diego Novillo  wrote:
> On Thu, Jan 27, 2011 at 05:25, Richard Guenther
>  wrote:
>
>> Does the tool know when a patch is approved or rejected based on
>> review e-mail content?
>
> I don't think so (the internal version we use does, but I haven't seen
> this one implement the same scoring system).  An issue is either open
> or closed.  The original sender can close it once it's been approved.
>
>> Does it track patches that are related
>> somehow (either split patch series or updates to patches after
>> these are requested from a reviewer)?
>
> Yes, a single issue can track multiple versions of the same patch and
> patch sets.  The tool can show you different views of the patches as
> well.
>
>> And how does this integrate
>> with reviewers not using the tool but old-style e-mails?
>
> If you respond by e-mail (with the subject and CC lines untouched), it
> will add the email to the issue trail, just like bugzilla does.
>
>>
>> Thus, is the tool useful to track stalled patches?  (does it know when
>> a patch is committed and where?)
>
> Issues will remain visible to you (when you log in) until they are
> marked closed by the patch creator.  So, yes.  I don't think the tool
> knows when the patch is committed, though.
>
> Currently, we are using the standard deployment of Rietveld on
> appspot, but if we find this generally useful we could deploy another
> instance on sourceware.  It should not be hard and I'd volunteer to do
> it if there is sufficient interest.  I would like to give it a try
> first, though.

Sure, as it is non-invasive trying it is ok.  I just wanted to see if it
fixes any existing problem - it does not seem to (apart from
maybe e-mail is so hard, a minor problem compared to
programming GCC is so hard ;))

Richard.

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Thu, Jan 27, 2011 at 09:49, Richard Guenther
 wrote:

> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it
> fixes any existing problem - it does not seem to (apart from
> maybe e-mail is so hard, a minor problem compared to
> programming GCC is so hard ;))

For it to be a proper patch tracker, the reviewer should sign in to
get to their dashboard of pending patches.  Perhaps if we deployed it
on sourceware, it could be tied to SVN to notice commits, but I'm not
sure.

Jeffrey, do you know if that's the case?


Diego.

Re: Proposal: Improving patch tracking and review using Rietveld

[Richard Guenther]

On Thu, Jan 27, 2011 at 3:53 PM, Diego Novillo  wrote:
> On Thu, Jan 27, 2011 at 09:49, Richard Guenther
>  wrote:
>
>> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it
>> fixes any existing problem - it does not seem to (apart from
>> maybe e-mail is so hard, a minor problem compared to
>> programming GCC is so hard ;))
>
> For it to be a proper patch tracker, the reviewer should sign in to
> get to their dashboard of pending patches.  Perhaps if we deployed it
> on sourceware, it could be tied to SVN to notice commits, but I'm not
> sure.
>
> Jeffrey, do you know if that's the case?

It's of course more useful if it is integrated with bugzilla, SVN and
possibly a patch tester doing bootstrap & regtest (you probably
have all that internally).

Richard.

Re: Proposal: Improving patch tracking and review using Rietveld

[Diego Novillo]

On Thu, Jan 27, 2011 at 09:55, Richard Guenther
 wrote:

> It's of course more useful if it is integrated with bugzilla, SVN and
> possibly a patch tester doing bootstrap & regtest (you probably
> have all that internally).

Yes.  Internally, it has bug fields and it detects commits.


Diego.

Re: Proposal: Improving patch tracking and review using Rietveld

[Jeffrey Yasskin]

On Thu, Jan 27, 2011 at 6:53 AM, Diego Novillo  wrote:
> On Thu, Jan 27, 2011 at 09:49, Richard Guenther
>  wrote:
>
>> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it
>> fixes any existing problem - it does not seem to (apart from
>> maybe e-mail is so hard, a minor problem compared to
>> programming GCC is so hard ;))
>
> For it to be a proper patch tracker, the reviewer should sign in to
> get to their dashboard of pending patches.  Perhaps if we deployed it
> on sourceware, it could be tied to SVN to notice commits, but I'm not
> sure.
>
> Jeffrey, do you know if that's the case?

I don't think it currently has such support, but I've also never
looked for it. If you submit patches to let people tie it to SVN, I'm
sure they'd be welcome. The source is at
http://code.google.com/p/rietveld/.

Jeffrey

Gcc Plugin and AST/variable question

[Kyle Girard]

I have two files:

foo.h:

extern int x;
extern int y;

foo.c:

#include "foo.h"

int x;
int y;

I have written a gcc plugin that traverses the gcc AST ... However in
the situation where I compile the above file I cannot seem to access the
int x and int y decls.  If I place a dummy function in the foo.c file I
can get the decl's for x and y and I'm good however this isn't always
the case in real code.  

Is there a list buried in gcc somewhere that I can traverse to get
access these decls?  Or are they ignored?

Thanks,

Kyle

Turi acis un ausis valjaa

[Pavels]

Latus interneta (online) var pelnit sekojot saitei:

http://www.labanauda.lv

Siiks izklaasts un video!

Online cash metode tiem, kas pelna interneta

[Rapex]

Istu naudu internetaa pelnit ir reaali:

www. tavalaime. lv (ludzu, izdzes tukshumus un iekope browseri, tad stradas)

Loti labs izklasts un video rullis!!

Re: Proposal: Improving patch tracking and review using Rietveld

[Ian Lance Taylor]

Richard Guenther  writes:

> Sure, as it is non-invasive trying it is ok.  I just wanted to see if it
> fixes any existing problem - it does not seem to (apart from
> maybe e-mail is so hard, a minor problem compared to
> programming GCC is so hard ;))

It does fix an existing problem, which is that it is much easier to
review a patch in Reitveld than via e-mail (assuming you have a fast
Internet connection).  You can see as much context as you want in the
file, it's easy to comment on specific lines.  We use Reitveld for Go
patches and it is a huge time saver.  In Go we also can commit the exact
patch straight from Reitveld; I don't know if the subversion integration
supports that.  (Go uses Mercurial.)

Ian

Building Secondary Languages After Newlib is Installed

[Joel Sherrill]

Hi,

There are now 14 RTEMS targets which I try to
test regularly on the head.  Where possible,
I try to test C, C++, Ada, and Go.  The procedure
is roughly

+ build and install C, C++ with newlib multilibed
+ build and install RTEMS
+ build and install C, Adawith newlib multilibed
+ build and install C, Gowith newlib multilibed

This works well but there is no reason to spend
time building newlib over and over.  On targets
with lots of multilibs, this takes a long time.

To speed up the Ada and Go builds, I want to use
the newlib installed in the first step and not
build it again.  But obviously the configure
scripts have to pick up things correctly.

libstdc++-v3/configure.ac tests $with_newlib to
set a number of flags.

What is the preferred combination of
--enable-newlib and --with-newlib settings
to build with newlib in the gcc source tree
but not build it and use the installed copy
for the Ada and Go builds?

Thanks.

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

libgo multilib issues.

[David Daney]

Ian,

In trying to build libgo on mips64-linux we try to build all three 
multilibs (o32, n32 and n64 ABIs)


For the n32 ABI, the configure script generates syscall_arch.go:
---
package syscall
const ARCH = "mips64"
const OS = "linux"
---

The Makefile has GOARCH = mips64, so it is trying to compile my new 
syscalls/syscall_linux_mips64.go.


So far so good.

But now what will happen for the n64 ABI?  It has the exact same GOARCH. 
 This is not good because n64 will need a different 
syscalls/syscall_linux_${GOARCH}.go


Actually I think my syscall_linux_mips.go can be shared between both the 
o32 and n32 libraries.


How to sort this out?

David Daney

Re: Plugin that parse tree

[Tom Tromey]

> "Ian" == Ian Lance Taylor  writes:

Ian> The problem with warnings for this kind of code in C/C++ is that it
Ian> often arises in macro expansions.  I think it would be necessary to
Ian> first develop a scheme which lets us determine whether code resulted
Ian> from a macro expansion or not, which I think would be quite useful in a
Ian> number of different cases.

There is a patch series pending for this.

See the thread "Tracking locations of tokens resulting from macro
expansion".

Tom

Re: libgo multilib issues.

[Ian Lance Taylor]

David Daney  writes:

> In trying to build libgo on mips64-linux we try to build all three
> multilibs (o32, n32 and n64 ABIs)
>
> For the n32 ABI, the configure script generates syscall_arch.go:
> ---
> package syscall
> const ARCH = "mips64"
> const OS = "linux"
> ---
>
> The Makefile has GOARCH = mips64, so it is trying to compile my new
> syscalls/syscall_linux_mips64.go.
>
> So far so good.
>
> But now what will happen for the n64 ABI?  It has the exact same
> GOARCH. This is not good because n64 will need a different
> syscalls/syscall_linux_${GOARCH}.go
>
> Actually I think my syscall_linux_mips.go can be shared between both
> the o32 and n32 libraries.
>
> How to sort this out?

I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
target.  If you need a different syscall_linux_${GOARCH} file for
different mips64 targets, then I think we're going to need to test some
conditional in libgo/Makefile.am to add the file to build.  E.g., look
at syscall_filesize_file.

Ian

Re: libgo multilib issues.

[Rainer Orth]

Ian Lance Taylor  writes:

> I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
> target.  If you need a different syscall_linux_${GOARCH} file for
> different mips64 targets, then I think we're going to need to test some
> conditional in libgo/Makefile.am to add the file to build.  E.g., look
> at syscall_filesize_file.

This is the same difference as between sparc and sparc64/sparcv9: while
all recent SPARC CPUs are capable of executing 64-bit insns, there's
both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).

On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
there's also O64.

It again comes down to what GOARCH is supposed to mean: an ABI, or what
else?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Plugin that parse tree

[Daniel Marjamäki]

I see. Good.

2011/1/27 Tom Tromey :
>> "Ian" == Ian Lance Taylor  writes:
>
> Ian> The problem with warnings for this kind of code in C/C++ is that it
> Ian> often arises in macro expansions.  I think it would be necessary to
> Ian> first develop a scheme which lets us determine whether code resulted
> Ian> from a macro expansion or not, which I think would be quite useful in a
> Ian> number of different cases.
>
> There is a patch series pending for this.
>
> See the thread "Tracking locations of tokens resulting from macro
> expansion".
>
> Tom
>

Re: Bugzilla permissions

[Tony Poppleton]

Hi,

On Wed, Jan 26, 2011 at 2:36 PM, Richard Guenther
 wrote:
> I have added you to the reconfirmers group, please check if that makes
> it work.

Thanks, however I am still unable to make the changes in bugzilla, specifically;
 - modify "known to fail"/"known to work" fields
 - transition a bug status from UNCONFIRMED to NEW
 - change "Target Milestone"
 - potentially change priority/severity

Could someone with the powers please modify my permissions to the above?

(as an aside, shouldn't modifying the "known to fail/work" fields be
enabled by default for all?)

Many thanks,
Tony

Re: libgo multilib issues.

[Ian Lance Taylor]

Rainer Orth  writes:

> Ian Lance Taylor  writes:
>
>> I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
>> target.  If you need a different syscall_linux_${GOARCH} file for
>> different mips64 targets, then I think we're going to need to test some
>> conditional in libgo/Makefile.am to add the file to build.  E.g., look
>> at syscall_filesize_file.
>
> This is the same difference as between sparc and sparc64/sparcv9: while
> all recent SPARC CPUs are capable of executing 64-bit insns, there's
> both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).
>
> On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
> 32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
> there's also O64.
>
> It again comes down to what GOARCH is supposed to mean: an ABI, or what
> else?

That's a good point.  I guess it has to mean an ABI.  So we should be
using different values for the different MIPS ABIs.

Ian

Re: libgo multilib issues.

[Paul Koning]

On Jan 27, 2011, at 4:00 PM, Ian Lance Taylor wrote:

> Rainer Orth  writes:
> 
>> Ian Lance Taylor  writes:
>> 
>>> I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
>>> target.  If you need a different syscall_linux_${GOARCH} file for
>>> different mips64 targets, then I think we're going to need to test some
>>> conditional in libgo/Makefile.am to add the file to build.  E.g., look
>>> at syscall_filesize_file.
>> 
>> This is the same difference as between sparc and sparc64/sparcv9: while
>> all recent SPARC CPUs are capable of executing 64-bit insns, there's
>> both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).
>> 
>> On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
>> 32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
>> there's also O64.
>> 
>> It again comes down to what GOARCH is supposed to mean: an ABI, or what
>> else?
> 
> That's a good point.  I guess it has to mean an ABI.  So we should be
> using different values for the different MIPS ABIs.

What about all the other things you can do to MIPS with multilib?  Different 
ISAs?  Soft float vs. hard float?  

paul

Re: libgo multilib issues.

[David Daney]

On 01/27/2011 11:49 AM, Rainer Orth wrote:

Ian Lance Taylor  writes:


I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
target.  If you need a different syscall_linux_${GOARCH} file for
different mips64 targets, then I think we're going to need to test some
conditional in libgo/Makefile.am to add the file to build.  E.g., look
at syscall_filesize_file.


This is the same difference as between sparc and sparc64/sparcv9: while
all recent SPARC CPUs are capable of executing 64-bit insns, there's
both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).

On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
there's also O64.



That's right, but for the sake of argument I would say that o64 is 
unimportant as it is not supported by the Linux kernel.




It again comes down to what GOARCH is supposed to mean: an ABI, or what
else?



I would say it is only useful to distinguish the various ABIs.  That is 
the only thing any program really sees.


The output of 'uname -m' is an almost completely usless piece of 
information, so I don't think assigning the value of GOARCH to it makes 
much sense.


Since libgo doesn't even currently build under linux-mips*, we could 
change the values of GOARCH generated for mips without causing regressions.


I would suggest:

GOARCH=mips# o32
GOARCH=mips64n32   # Would you believe n32?
GOARCH=mips64n64   # ...n64


David Daney

Re: libgo multilib issues.

[David Daney]

On 01/27/2011 01:02 PM, Paul Koning wrote:


On Jan 27, 2011, at 4:00 PM, Ian Lance Taylor wrote:


Rainer Orth  writes:


Ian Lance Taylor  writes:


I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS
target.  If you need a different syscall_linux_${GOARCH} file for
different mips64 targets, then I think we're going to need to test some
conditional in libgo/Makefile.am to add the file to build.  E.g., look
at syscall_filesize_file.


This is the same difference as between sparc and sparc64/sparcv9: while
all recent SPARC CPUs are capable of executing 64-bit insns, there's
both a 32-bit ABI (sparc) and a 64-bit one (sparcv9/sparc64).

On MIPS (at least IRIX and obviously Linux/MIPS as well), you have two
32-bit ABIs (O32 and N32) and one 64-bit one (N64), on other systems
there's also O64.

It again comes down to what GOARCH is supposed to mean: an ABI, or what
else?


That's a good point.  I guess it has to mean an ABI.  So we should be
using different values for the different MIPS ABIs.


What about all the other things you can do to MIPS with multilib?  Different 
ISAs?  Soft float vs. hard float?



The current default GCC behavior under linux-mips64* is to ignore all 
those details.


Based on my almost complete lack of libgo knowlege, I think the 
selection of a specific syscall_linux_${GOARCH}.go file would not care 
about soft/hard float issues.


David Daney

Re: libgo multilib issues.

[Ian Lance Taylor]

David Daney  writes:

> That's right, but for the sake of argument I would say that o64 is
> unimportant as it is not supported by the Linux kernel.

It's unimportant but I'd like to make sure the scheme leaves room for
it.

>> It again comes down to what GOARCH is supposed to mean: an ABI, or what
>> else?
>>
>
> I would say it is only useful to distinguish the various ABIs.  That
> is the only thing any program really sees.

I agree.

> Since libgo doesn't even currently build under linux-mips*, we could
> change the values of GOARCH generated for mips without causing
> regressions.
>
> I would suggest:
>
> GOARCH=mips# o32
> GOARCH=mips64n32   # Would you believe n32?
> GOARCH=mips64n64   # ...n64

I think the only real question is whether that first "64" helps.
Perhaps we should just use mipso32, mipsn32, and mipsn64?  Or should we
just use mips instead of mipso32?

Ian

gcc-4.5-20110127 is now available

[gccadmin]

Snapshot gcc-4.5-20110127 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 169339

You'll find:

 gcc-4.5-20110127.tar.bz2 Complete GCC (includes all of below)

  MD5=57a464f1e2e09892caa7fd9ef7c15bee
  SHA1=530ecafe2df5cbd5c64c6f72207afc4ee36744b8

 gcc-core-4.5-20110127.tar.bz2C front end and core compiler

  MD5=7dbdf06186dc98955221b2f7b987645b
  SHA1=d9489ae68eb75a46faa4d5a35cd078f31c710abd

 gcc-ada-4.5-20110127.tar.bz2 Ada front end and runtime

  MD5=067672b640d0b912298791c1837606bc
  SHA1=4179e9e05a2fc59b293634eb7e6b5cc2d6c422bb

 gcc-fortran-4.5-20110127.tar.bz2 Fortran front end and runtime

  MD5=c741c614e975c858cffb9e78b0b5124f
  SHA1=78cb359a45cbb0167a2e0c11493413a23dd87c4a

 gcc-g++-4.5-20110127.tar.bz2 C++ front end and runtime

  MD5=4893036a98d8bedf44fe0741dfec6e1f
  SHA1=bdd0ba59392d3699609fa54b5d57ee35dbb099a5

 gcc-go-4.5-20110127.tar.bz2  Go front end and runtime

  MD5=598200995deb70ac82721ee869cef553
  SHA1=dd9355d50c8d6dbb1814c20e36160bd7a62b0c1c

 gcc-java-4.5-20110127.tar.bz2Java front end and runtime

  MD5=0db5f2150e27476295a99ed514fa192a
  SHA1=ed30ae4f4ba4a40b1b1a256740cd79267909ae24

 gcc-objc-4.5-20110127.tar.bz2Objective-C front end and runtime

  MD5=b141fadc984cc0c1c0f15feb16db14e5
  SHA1=93360e7c2297e4bfa8accd0e40cf5e6963452ed3

 gcc-testsuite-4.5-20110127.tar.bz2   The GCC testsuite

  MD5=daffd2ba5917a263cdff5f38dcf8c323
  SHA1=d021c8007b3b92e7bc18bfe728081a95da81c677

Diffs from 4.5-20110120 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Target deprecations for 4.6

[Joseph S. Myers]

There have been some discussions of possible target deprecations in 4.6, 
including a list I sent at 
, but no 
particular conclusions.  Here is a concrete list I propose for deprecation 
in 4.6; please send any other suggestions, or say if you wish to volunteer 
to maintain one of these targets to avoid deprecation (and start sending 
patches and test results in that case; m68hc11 has a nominal maintainer, 
but no test results after July 2007).

* ARC (arc-*) (unmaintained for a long time).

* M68hc1x (m68hc11-*-*, m6811-*-*, m68hc12-*-*, m6812-*-*) (see 
).

* Interix (i[34567]86-*-interix3*) (see PR 47096).

* Generic ARM PE (arm-*-pe* not matching arm*-wince-pe*).

* MCore PE, and with it svr3.h (mcore-*-pe*).

* i[34567]86-*-pe (an alias for Cygwin in config.gcc rather than 
config.sub, so not effectively treated as an alias elsewhere).

* M68K uClinux old ABI (m68k-*-uclinuxoldabi*).

* a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*, 
i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd* 
not matching vax-*-netbsdelf*).

* SH SymbianOS (sh-*-symbianelf*) (see PR 47119).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Building Secondary Languages After Newlib is Installed

[Ralf Corsepius]

On 01/27/2011 07:15 PM, Joel Sherrill wrote:

Hi,

There are now 14 RTEMS targets which I try to
test regularly on the head. Where possible,
I try to test C, C++, Ada, and Go. The procedure
is roughly

+ build and install C, C++ with newlib multilibed
+ build and install RTEMS
+ build and install C, Adawith newlib multilibed
+ build and install C, Gowith newlib multilibed

This works well but there is no reason to spend
time building newlib over and over. On targets
with lots of multilibs, this takes a long time.

To speed up the Ada and Go builds, I want to use
the newlib installed in the first step and not
build it again. But obviously the configure
scripts have to pick up things correctly.

libstdc++-v3/configure.ac tests $with_newlib to
set a number of flags.

What is the preferred combination of
--enable-newlib and --with-newlib settings
to build with newlib in the gcc source tree
but not build it and use the installed copy
for the Ada and Go builds?


Theoretically, none at all, because building against an installed newlib 
should be equivalent to "standard cross-building".


Ralf

Re: Target deprecations for 4.6

[Dave Korn]

On 28/01/2011 01:11, Joseph S. Myers wrote:

> * i[34567]86-*-pe (an alias for Cygwin in config.gcc rather than 
> config.sub, so not effectively treated as an alias elsewhere).

  Makes sense to me, thank you.  (I've never heard of anyone using it, I don't
think it would even matter if you just removed it as obsolete historical cruft.)

cheers,
  DaveK

Re: Building Secondary Languages After Newlib is Installed

[Ian Lance Taylor]

Ralf Corsepius  writes:

> On 01/27/2011 07:15 PM, Joel Sherrill wrote:
>
>> What is the preferred combination of
>> --enable-newlib and --with-newlib settings
>> to build with newlib in the gcc source tree
>> but not build it and use the installed copy
>> for the Ada and Go builds?
>
> Theoretically, none at all, because building against an installed
> newlib should be equivalent to "standard cross-building".

But Joel has newlib in his source tree, so won't it get built by
default?  That's what he wants to avoid.

(I say this without having tested it.)

Ian

Re: Proposal: Improving patch tracking and review using Rietveld

[Joseph S. Myers]

On Wed, 26 Jan 2011, Diego Novillo wrote:

> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided
> the submitter added gcc-patches to the CC list).

 appears to be a 
patch sent using this system where it failed to include the patch in the 
message to gcc-patches.

-- 
Joseph S. Myers
jos...@codesourcery.com