Re: Freescale 68HC11/68HC12 port

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 publ

Re: Proposal: Improving patch tracking and review using Rietveld

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 p

Re: Proposal: Improving patch tracking and review using Rietveld

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 a

Re: Proposal: Improving patch tracking and review using Rietveld

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 p

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

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

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

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 in

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

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 block

Re: Proposal: Improving patch tracking and review using Rietveld

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/). Dif

Re: Proposal: Improving patch tracking and review using Rietveld

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 close

Re: Proposal: Improving patch tracking and review using Rietveld

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 im

Re: Proposal: Improving patch tracking and review using Rietveld

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

Re: Proposal: Improving patch tracking and review using Rietveld

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 proble

Re: Proposal: Improving patch tracking and review using Rietveld

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

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 proble

Gcc Plugin and AST/variable question

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

Turi acis un ausis valjaa

Latus interneta (online) var pelnit sekojot saitei: http://www.labanauda.lv Siiks izklaasts un video!

Online cash metode tiem, kas pelna interneta

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

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 tha

Building Secondary Languages After Newlib is Installed

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 ins

libgo multilib issues.

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 i

Re: Plugin that parse tree

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

Re: libgo multilib issues.

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 Make

Re: libgo multilib issues.

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 buil

Re: Plugin that parse tree

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 r

Re: Bugzilla permissions

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 s

Re: libgo multilib issues.

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/Makefi

Re: libgo multilib issues.

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 thin

Re: libgo multilib issues.

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 lib

Re: libgo multilib issues.

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 m

Re: libgo multilib issues.

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

gcc-4.5-20110127 is now available

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

Target deprecations for 4.6

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 y

Re: Building Secondary Languages After Newlib is Installed

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

Re: Target deprecations for 4.6

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 re

Re: Building Secondary Languages After Newlib is Installed

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? > > Theoretical

Re: Proposal: Improving patch tracking and review using Rietveld

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