Re: Patch pinging
On 8 June 2010 05:42, Basile Starynkevitch wrote: > On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote: >> On 06/07/10 14:31, Ian Lance Taylor wrote: >> > The gcc project currently has a problem: when people who are not >> > regular gcc developers send in a patch, those patches often get >> > dropped. They get dropped because they do not get reviewed, and they >> > get dropped because after review they do not get committed. This >> > discourages new developers and it means that the gcc project does not >> > move as fast as it could. >> > >> > >> So perhaps the thing to do is somehow separate patches from regular >> contributors and irregular contributors. A relatively easy way to do >> this would be for a regular contributor to include a keyword in their >> message to gcc-patches to mark the thread as not needing 3rd party >> tracking/pings. > > > I am not sure what does that mean in practice. I am only a write after > approval contributor, so I cannot formally approve any patch (except > perhaps to my MELT branch). However, I definitely can follow some > patches (and I even do have an intern, Jeremie Salvucci, who did all the > legal framework and wants to become a GCC contributor). > > It seems that perhaps you are suggesting a status in between reviewers & > W.A.A. contributors. No, I think you misunderstood. The keyword would only indicate that the patch author does not need anyone to commit it for them. That doesn't change the approval process. It would tell NightStrike there is no need to track the patch.
gc-improv code merged to mainline, trunk is still frozen
Hi all, I've committed the gc-improv code to trunk. The testsuite is still running, however bootstrap went fine on x86_64/linux. Due to nature of the changes, any problems should show up as bootstrap compile errors and on x86_64/linux I don't expect them. The problems are more (although IMHO not much) likely to crop up in other backends, where I did testing on the branch on the compile farm a couple of months ago and in the backends where I could only verify that cross-compiler still builds. So feel free now to try to bootstrap and regtest the trunk on your favorite architecture to see if anything breaks. Thanks! -- Laurynas
Re: Patch pinging
> Reading gcc-cvs, or ChangeLogs, or other things like that is just way > too much time. What about writing a small script that parses the main ChangeLogs? They are supposed to be uniformly formatted. And ping messages shouldn't contain all the junk of previous messages, just the ChangeLog (and optionally the URL). -- Eric Botcazou
Re: Patch pinging
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote: On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote: So perhaps the thing to do is somehow separate patches from regular contributors and irregular contributors. A relatively easy way to do this would be for a regular contributor to include a keyword in their message to gcc-patches to mark the thread as not needing 3rd party tracking/pings. It seems that perhaps you are suggesting a status in between reviewers& W.A.A. contributors. I don't understand. WAA rights definitely allow you to shepherd and commit patches from people without svn access, even for patches you can't approve. Paolo
Re: Patch pinging
On 8 June 2010 07:43, Chiheng Xu wrote: > On Tue, Jun 8, 2010 at 9:14 AM, Ben White wrote: >> Would a modestly modified copy of Bugzilla be workable for that something? >> I.E. Patchzilla? > > Think about mercurial or git. Every one can commit on his/her own > local repository, and "publish" his/her repository. Every one can > pull other people's changes into his/her own repository, and can > selectively merge interesting/valuable changes. Every patch have it's > own branch. So called "approved patches" will be those patches whose > branches have been merged. Then, you only need to think whether or not > merge the branches the patches reside. > > If you use mercurial or git, every change will not be lost, every one > can review and selectively merge any branch on his/her convenience. That would only make matters worse in GCC, because reviewers are not generally interested on spending time merging anyone's else changes. What we are discussion here is a way to not lose track of the work of sporadic contributors so they don't feel ignored by the GCC project. Cheers, Manuel.
Re: Patch pinging
On 8 June 2010 10:43, Paolo Bonzini wrote: > On 06/08/2010 06:42 AM, Basile Starynkevitch wrote: >> >> On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote: >>> >>> So perhaps the thing to do is somehow separate patches from regular >>> contributors and irregular contributors. A relatively easy way to do >>> this would be for a regular contributor to include a keyword in their >>> message to gcc-patches to mark the thread as not needing 3rd party >>> tracking/pings. >> >> It seems that perhaps you are suggesting a status in between reviewers& >> W.A.A. contributors. > > I don't understand. WAA rights definitely allow you to shepherd and commit > patches from people without svn access, even for patches you can't approve. And basile (and other WAA contributors), this would a nice contribution. Asking people that do not appear to have access to svn whether you want to commit their patches for them. And keeping them in the loop (by showing them the commit) soy they feel within the community and not outside of it. Cheers, Manuel.
Re: Patch pinging
On 8 June 2010 11:17, Manuel López-Ibáñez wrote: > On 8 June 2010 10:43, Paolo Bonzini wrote: >> On 06/08/2010 06:42 AM, Basile Starynkevitch wrote: >>> >>> On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote: So perhaps the thing to do is somehow separate patches from regular contributors and irregular contributors. A relatively easy way to do this would be for a regular contributor to include a keyword in their message to gcc-patches to mark the thread as not needing 3rd party tracking/pings. >>> >>> It seems that perhaps you are suggesting a status in between reviewers& >>> W.A.A. contributors. >> >> I don't understand. WAA rights definitely allow you to shepherd and commit >> patches from people without svn access, even for patches you can't approve. > > And basile (and other WAA contributors), this would a nice > contribution. Asking people that do not appear to have access to svn > whether you want to commit their patches for them. And keeping them in It should say: "whether they want you to commit their patches for them." Cheers, Manuel.
Pseudo frame pointer register in assembly code
Hi,
We have been implementing GCC port for a new target.
The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
I am using the following macros in header file to eliminate the pseudo
arg pointer and frame pointer.
However, there are some instances of frame pointer in the assembly code.
Currently, I have modified "GO_IF_LEGITIMATE_ADDRESS" in C file to
eliminate these register references in assembly code. However, there
are still some references found.
Please let me know if there is anything else to be defined to remove
these pseudo instances.
The following chunk of code is used in header file to eliminate pseudo
registers.
===
#define FRAME_POINTER_REQUIRED 0
#define ELIMINABLE_REGS \
{{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
#define CAN_ELIMINATE(FROM, TO) (1)
#define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET)\
{ \
if ((FROM) == FRAME_POINTER_REGNUM) \
(OFFSET) = ( STACK_POINTER_OFFSET \
+ crtl->outgoing_args_size ); \
else if ((FROM) == ARG_POINTER_REGNUM)\
(OFFSET) = ( STACK_POINTER_OFFSET \
+ xxx_compute_frame_size (get_frame_size (), \
(long long *)0, (int*)0)); \
else \
gcc_unreachable (); \
}
===
Thanks & Regards,
Naveen.H.S
Re: gc-improv code merged to mainline, trunk is still frozen
On x86_64/linux, the merge does not cause any new testsuite regressions, except the fact that two new testcases were added during the freeze: gfortran.dg/proc_ptr_27.f90 g++.dg/cpp0x/decltype23.C So now I am more or less done with testing, and I am waiting for any complaints :) -- Laurynas
Re: Patch pinging
On 7 June 2010 22:43, Ian Lance Taylor wrote: > > The patch tracker (http://gcc.gnu.org/wiki/GCC_Patch_Tracking) is not > currently operating. > > Would anybody like to volunteer to get it working again? I'm not volunteering, but I might look into it one day. I already have too little spare time for my libstdc++ (and C++ committee) commitments, so it won't be soon. If dberlin doesn't still have the code, it shouldn't be too hard to reimplement, assuming the same model is desirable. Since I wouldn't fancy setting up a mailbox, a script which periodically crawls the gcc-patches archive might suffice. Finding :ADDPATCH xxx: messages would be easy. :REVIEWMAIL: messages include the In-Reply-To in the form of an comment in the HTML, the last such comment seems to be the direct ancestor. :REVIEWURL url: mails would obviously work, the url identifies the message in the archive. :REVIEWID id: messages would work too, as the id is known to the patch tracker. It wouldn't need a database, a structured file of some sort would do, and a CGI script which parsed that could produce an HTML page for viewing. Just a simple matter of programming ;)
RE: externally_visible and resoultion file
Hi,
Sorry for coming back to this issue after a while. I am still puzzled
by this. The following are two test files:
a.c
#include
#include
extern int foo(int);
void bar()
{
printf("bar\n");
}
extern int src[], dst[];
int vv;
int main()
{
int ret;
vv = 12;
ret = foo(20);
memcpy(dst, src, 100);
return ret + 3;
}
b.c
#include
int src[100];
int dst[100];
extern int vv;
extern void bar();
int foo(int c)
{
printf("Hello world: %d\n", c);
bar();
return 1000 + vv;
}
I compiled with following steps
~/work/install-x86/bin/gcc -flto a.c -O2 -c
~/work/install-x86/bin/gcc b.c -O2 -c
ar cru libb.a b.o
~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin -o f
-fwhole-program -save-temps
Since you both mentioned that resolution file is not used to replace
externally_visible attribute yet,
I expect there will be link errors regarding both vv and bar. Somehow, GCC
doesn't complain at all.
However, looking at generated assembly code, GCC produces wrong code for
calling bar, and vv is
linked correctly though.
00400510 :
400510: 48 83 ec 08 sub$0x8,%rsp
400514: 89 fe mov%edi,%esi
400516: 31 c0 xor%eax,%eax
400518: bf 1c 06 40 00 mov$0x40061c,%edi
40051d: e8 56 01 00 00 callq 400678
400522: 31 c0 xor%eax,%eax
400524: e8 d7 fa bf ff callq 0 <__fini_array_end>
< should call bar.
400529: 8b 05 a1 17 00 00 mov0x17a1(%rip),%eax#
401cd0
40052f: 48 83 c4 08 add$0x8,%rsp
400533: 05 e8 03 00 00 add$0x3e8,%eax
400538: c3 retq
400539: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
Is this a bug? GCC should issue warning/error here. Why is vv linked
correctly?
Shouldn't it be treated as static with -fwhile-program and without
externally_visible?
My trunk is 160104 by the way.
Thanks,
Bingfeng
> -Original Message-
> From: Jan Hubicka [mailto:hubi...@ucw.cz]
> Sent: 27 May 2010 09:04
> To: Richard Guenther
> Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: externally_visible and resoultion file
>
> > On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei
> wrote:
> > > Hi, Richard,
> > > With resolution file generated by GOLD (or I am going to hack gnu
> LD), is
> > > externally_visible attribute still needed to annotate those symbols
> accessed
> > > from non-LTO objects when compiling with -fwhole-program.
> >
> > Yes it is. We do not parse the complete resolution file but only the
> > entries we'll end up reading .o files with LTO information for.
> >
> > > In theory, it shouldn't be needed since LTO has all information.
> But what
> > > about current implementation. I checked relevant source files and
> can't
> > > get immediate clue.
> >
> > The current implementation has no idea of the external references
> > (though it's probably not too hard to implement).
>
> Yep, this is also one of my TODO list items...
>
> Honza
> >
> > Richard.
Re: externally_visible and resoultion file
On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei wrote:
> Hi,
> Sorry for coming back to this issue after a while. I am still puzzled
> by this. The following are two test files:
>
> a.c
>
> #include
> #include
> extern int foo(int);
> void bar()
> {
> printf("bar\n");
> }
> extern int src[], dst[];
> int vv;
> int main()
> {
> int ret;
> vv = 12;
> ret = foo(20);
> memcpy(dst, src, 100);
> return ret + 3;
> }
>
> b.c
> #include
> int src[100];
> int dst[100];
> extern int vv;
> extern void bar();
> int foo(int c)
> {
> printf("Hello world: %d\n", c);
> bar();
> return 1000 + vv;
> }
>
> I compiled with following steps
> ~/work/install-x86/bin/gcc -flto a.c -O2 -c
> ~/work/install-x86/bin/gcc b.c -O2 -c
> ar cru libb.a b.o
> ~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin -o f
> -fwhole-program -save-temps
>
> Since you both mentioned that resolution file is not used to replace
> externally_visible attribute yet,
> I expect there will be link errors regarding both vv and bar. Somehow,
> GCC doesn't complain at all.
> However, looking at generated assembly code, GCC produces wrong code for
> calling bar, and vv is
> linked correctly though.
>
> 00400510 :
> 400510: 48 83 ec 08 sub $0x8,%rsp
> 400514: 89 fe mov %edi,%esi
> 400516: 31 c0 xor %eax,%eax
> 400518: bf 1c 06 40 00 mov $0x40061c,%edi
> 40051d: e8 56 01 00 00 callq 400678
> 400522: 31 c0 xor %eax,%eax
> 400524: e8 d7 fa bf ff callq 0 <__fini_array_end>
> < should call bar.
> 400529: 8b 05 a1 17 00 00 mov 0x17a1(%rip),%eax #
> 401cd0
> 40052f: 48 83 c4 08 add $0x8,%rsp
> 400533: 05 e8 03 00 00 add $0x3e8,%eax
> 400538: c3 retq
> 400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
>
> Is this a bug? GCC should issue warning/error here. Why is vv linked
> correctly?
> Shouldn't it be treated as static with -fwhile-program and without
> externally_visible?
bar should be indeed eliminated which is what I see with not
using the linker plugin.
If you use the linker-plugin I see in the .optimized dump that
the were eliminated. But it seems that gold picks them up
from the original objects which seem to be retained somehow.
I guess this is a bug in the linker-plugin.
Richard.
> My trunk is 160104 by the way.
plugin_is_GPL_compatible mangling
I'm currently working on an update of the patch for PR42843, and I wonder
what best to do about the symbol plugin_is_GPL_compatible.
Although gcc doesn't currently mangle global variables, a future version of
gcc - or any other build compiler - might add mangling.
If I add:
#ifdef __cplusplus
extern "C" {
#endif
extern int plugin_is_GPL_compatible;
#ifdef __cplusplus
}
#endif
in gcc-plugin.h, then that potential problem is avoided.
However, it would mean that plugin_is_GPL_compatible would have to be declared
as type int - we currently say in the documentation that the type doesn't
matter. So we'd have to change the documentation to reflect this, then.
Also, the type we suggest in the documentation is int, but some people
might have choosen a different type to be on the safe side not to use GFDL
code (pasted from the manual) together with GPL code, or to safe space -
should we worry about the backwards compatibility issue there?
Re: plugin_is_GPL_compatible mangling
On Tue, Jun 08, 2010 at 09:48:15AM -0400, Joern Rennecke wrote:
> I'm currently working on an update of the patch for PR42843, and I wonder
> what best to do about the symbol plugin_is_GPL_compatible.
>
> extern int plugin_is_GPL_compatible;
>
> However, it would mean that plugin_is_GPL_compatible would have to be declared
> as type int - we currently say in the documentation that the type doesn't
> matter. So we'd have to change the documentation to reflect this, then.
> Also, the type we suggest in the documentation is int, but some people
> might have choosen a different type to be on the safe side not to use GFDL
> code (pasted from the manual) together with GPL code, or to safe space -
> should we worry about the backwards compatibility issue there?
I strongly believe your proposal is good, and we should *not* worry
about backwards compatibility:
* plugins are supposed to be free software, preferably GPLv3, so
people can patch & recompile them, especially since your requirement
is easy!
* plugins are not supposed to even be source compatible from one
version (e.g. 4.5) of GCC to the next (e.g. 4.6).
* some plugins might be source (but not binary) compatible from a
minor version (e.g. 4.5.0) to the next (e.g. 4.5.1).
* very few plugins exist in practice today, and some of them already
declared plugin_is_GPL_compatible as an int. We could even change
the name to GCC_plugin_is_GPL_compatible if you want. Whatever we
do, we should document that.
I hope your patch will be approved.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
RE: externally_visible and resoultion file
Thanks. But why "v" is linked correctly here? Shouldn't it
be treated as static with -fwhole-program?
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 08 June 2010 14:10
> To: Bingfeng Mei
> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant
> Subject: Re: externally_visible and resoultion file
>
> On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei wrote:
> > Hi,
> > Sorry for coming back to this issue after a while. I am still puzzled
> > by this. The following are two test files:
> >
> > a.c
> >
> > #include
> > #include
> > extern int foo(int);
> > void bar()
> > {
> > printf("bar\n");
> > }
> > extern int src[], dst[];
> > int vv;
> > int main()
> > {
> > int ret;
> > vv = 12;
> > ret = foo(20);
> > memcpy(dst, src, 100);
> > return ret + 3;
> > }
> >
> > b.c
> > #include
> > int src[100];
> > int dst[100];
> > extern int vv;
> > extern void bar();
> > int foo(int c)
> > {
> > printf("Hello world: %d\n", c);
> > bar();
> > return 1000 + vv;
> > }
> >
> > I compiled with following steps
> > ~/work/install-x86/bin/gcc -flto a.c -O2 -c
> > ~/work/install-x86/bin/gcc b.c -O2 -c
> > ar cru libb.a b.o
> > ~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin
> -o f -fwhole-program -save-temps
> >
> > Since you both mentioned that resolution file is not used to replace
> externally_visible attribute yet,
> > I expect there will be link errors regarding both vv and bar.
> Somehow, GCC doesn't complain at all.
> > However, looking at generated assembly code, GCC produces wrong code
> for calling bar, and vv is
> > linked correctly though.
> >
> > 00400510 :
> > 400510: 48 83 ec 08 sub $0x8,%rsp
> > 400514: 89 fe mov %edi,%esi
> > 400516: 31 c0 xor %eax,%eax
> > 400518: bf 1c 06 40 00 mov $0x40061c,%edi
> > 40051d: e8 56 01 00 00 callq 400678
> > 400522: 31 c0 xor %eax,%eax
> > 400524: e8 d7 fa bf ff callq 0
> <__fini_array_end> < should call bar.
> > 400529: 8b 05 a1 17 00
> 00 mov 0x17a1(%rip),%eax # 401cd0
> > 40052f: 48 83 c4 08 add $0x8,%rsp
> > 400533: 05 e8 03 00 00 add $0x3e8,%eax
> > 400538: c3 retq
> > 400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> >
> > Is this a bug? GCC should issue warning/error here. Why is vv
> linked correctly?
> > Shouldn't it be treated as static with -fwhile-program and without
> externally_visible?
>
> bar should be indeed eliminated which is what I see with not
> using the linker plugin.
>
> If you use the linker-plugin I see in the .optimized dump that
> the were eliminated. But it seems that gold picks them up
> from the original objects which seem to be retained somehow.
>
> I guess this is a bug in the linker-plugin.
>
> Richard.
>
> > My trunk is 160104 by the way.
Re: externally_visible and resoultion file
On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei wrote: > Thanks. But why "v" is linked correctly here? Shouldn't it > be treated as static with -fwhole-program? Works for me without the linker plugin as well: > gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B > /abuild/rguenther/trunk-g/gcc t2.o: In function `foo': t2.c:(.text+0x15): undefined reference to `bar' t2.c:(.text+0x1b): undefined reference to `vv' collect2: ld returned 1 exit status Richard.
Re: gc-improv code merged to mainline, trunk is still frozen
Quoting Laurynas Biveinis : I forgot in my previous e-mail the actual diff and the ChangeLogs of the gc-improv merge, attaching now. Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
RE: externally_visible and resoultion file
Yes, this is also what I saw without plugin. I just wonder why "v" is linked with plugin if resolution file is not used to eliminate need of externally_visible attribute here. Thanks, Bingfeng > -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: 08 June 2010 15:18 > To: Bingfeng Mei > Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant > Subject: Re: externally_visible and resoultion file > > On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei wrote: > > Thanks. But why "v" is linked correctly here? Shouldn't it > > be treated as static with -fwhole-program? > > Works for me without the linker plugin as well: > > > gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B > /abuild/rguenther/trunk-g/gcc > t2.o: In function `foo': > t2.c:(.text+0x15): undefined reference to `bar' > t2.c:(.text+0x1b): undefined reference to `vv' > collect2: ld returned 1 exit status > > Richard.
Re: externally_visible and resoultion file
On Tue, Jun 8, 2010 at 4:22 PM, Bingfeng Mei wrote: > Yes, this is also what I saw without plugin. I just wonder why "v" > is linked with plugin if resolution file is not used to eliminate need > of externally_visible attribute here. Probably because of the same linker-plugin bug that causes bar to be resolved. Richard. > Thanks, > Bingfeng > >> -Original Message- >> From: Richard Guenther [mailto:richard.guent...@gmail.com] >> Sent: 08 June 2010 15:18 >> To: Bingfeng Mei >> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant >> Subject: Re: externally_visible and resoultion file >> >> On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei wrote: >> > Thanks. But why "v" is linked correctly here? Shouldn't it >> > be treated as static with -fwhole-program? >> >> Works for me without the linker plugin as well: >> >> > gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B >> /abuild/rguenther/trunk-g/gcc >> t2.o: In function `foo': >> t2.c:(.text+0x15): undefined reference to `bar' >> t2.c:(.text+0x1b): undefined reference to `vv' >> collect2: ld returned 1 exit status >> >> Richard. > > >
Re: Patch pinging
On Tue, Jun 8, 2010 at 3:53 AM, Eric Botcazou wrote: >> Reading gcc-cvs, or ChangeLogs, or other things like that is just way >> too much time. > > What about writing a small script that parses the main ChangeLogs? They are > supposed to be uniformly formatted. And ping messages shouldn't contain all > the junk of previous messages, just the ChangeLog (and optionally the URL). > > -- > Eric Botcazou > Are you volunteering to write that small script?
Re: plugin_is_GPL_compatible mangling
Joern Rennecke wrote:
> #ifdef __cplusplus
> extern "C" {
> #endif
> extern int plugin_is_GPL_compatible;
> #ifdef __cplusplus
> }
> #endif
I think that's a good idea; I don't think that at this point we've made
any plugin compatibility guarantees. (In the future, I think we should
-- but only when we have a much more structured plug-in API.)
> Also, the type we suggest in the documentation is int, but some people
> might have choosen a different type to be on the safe side not to use GFDL
> code (pasted from the manual) together with GPL code
"extern int foo" is not something that is going to be covered by
copyright; there's no expression in something like that. I don't think
anybody should be worried.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: Patch pinging
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini wrote: > On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote: >> Perhaps NightStrike can fine-tune his approach. > By the way, I wonder how many contributors can even think taking > seriously a message coming from "NightStrike". Not me, for sure... > > Paolo. > That's just being mean. This is 2010. People use aliases. Would it make you happier if my alias was Neil Samson instead of NightStrike? Is it any more "real"? Look, you don't want me to be here... fine. I get it. Enough is enough already. Technical disagreements are one thing. Personal attacks on me are just juvenile.
Re: gc-improv code merged to mainline, trunk is still frozen
2010/6/8 Joern Rennecke : > Quoting Laurynas Biveinis : > >> I forgot in my previous e-mail the actual diff and the ChangeLogs of >> the gc-improv merge, attaching now. > > Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.' I have noticed it before the actual commit, the committed version is OK: 2010-06-08 Laurynas Biveinis * typeck2.c (abstract_virtuals_error): Use typed GC allocation. ... -- Laurynas
Successful build
I first installed gcc 4.5.0 on my Powerpc dual 970 machine with no configuration options. That was successful, but the long long feature was not enabled. Then I re-installed gcc 4.5.0 with this gcc v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-apple-darwin9.8.0/4.5.0/l to-wrapper Target: powerpc-apple-darwin9.8.0 Configured with: ../gcc-4.5.0/configure --with-cpu-64=970 --with-tune-64=970 --enable-long-long --enable-languages=c,c++,fortran,java Thread model: posix gcc version 4.5.0 (GCC) The output from config.guess: powerpc-apple-darwin9.8.0 I also let GCC install gmp 4.3.2, mpc 0.8.1 and mpfr-2.3.1 (patched) I had previously installed gmp 5.0.1 with the other two listed above. When I ran configure for gcc 4.5.0, it stopped and told me I had the wrong version of gmp/mpc/mpfr installed (it never said which one). So I stepped back to the previous version of GMP, unstalled all three from /usr/local/include/ and /usr/local/lib/, then had GCC install them; I notice it did not use the same directories. How do I configure GMP 5.0.1 or any of the others to upgrade the installed versions? Regarding your installation notes for powerpc-darwin, I¹d already installed Xcode on my machine. Definitely needed on a mac to install anything that's not mac ready. I had no luck installing ppl 0.10.2 It kept telling me I had the wrong version of gmp for both of the versions I tried, even when I tried to have gcc install it. FYI, I¹ll only have this machine for another six months or so before it¹s upgraded. -- William L. Maynard william.l.mayn...@nasa.gov NASA Goddard Space Flight CenterBuilding 33, Room E224 Code 554301-614-6234 8800 Greenbelt Road 301-614-6819 (FAX) Greenbelt, MD 20771
Re: Patch pinging
On 06/08/10 09:01, NightStrike wrote: On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini wrote: On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote: Perhaps NightStrike can fine-tune his approach. By the way, I wonder how many contributors can even think taking seriously a message coming from "NightStrike". Not me, for sure... Paolo. That's just being mean. This is 2010. People use aliases. Would it make you happier if my alias was Neil Samson instead of NightStrike? Is it any more "real"? Look, you don't want me to be here... fine. I get it. Enough is enough already. Technical disagreements are one thing. Personal attacks on me are just juvenile. I don't see this as a personal attack. Like Paolo, I'm a lot more likely to read a message from someone with a real name, or at least a name that sounds real. Jeff
Experimental Patchwork setup
Hi all, Jeremy has set up a Patchwork instance for us at http://patchwork.ozlabs.org/project/gcc/list/ . It is feeding from gcc-patches; the plan is to make it automatically recognise what patches went into the tree, probably by snooping the gcc-cvs list. You can also manually change patch status, if you're an admin; who is admin currently has to be configured manually, plan is to make everyone with an email @gcc.gnu.org admin automatically. In the meantime, if you want to play with it, tell me and I'll get you added. There aren't many patches in the system yet, so we'll need to let it run for a few weeks at least for it to prove its worth. Any feedback is very welcome. Go play with it :-) Segher
Re: Patch pinging
On Tue, Jun 8, 2010 at 11:21 AM, Jeff Law wrote: > On 06/08/10 09:01, NightStrike wrote: >> >> On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini >> wrote: >> >>> >>> On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote: >>> Perhaps NightStrike can fine-tune his approach. >>> >>> By the way, I wonder how many contributors can even think taking >>> seriously a message coming from "NightStrike". Not me, for sure... >>> >>> Paolo. >>> >>> >> >> That's just being mean. This is 2010. People use aliases. Would it >> make you happier if my alias was Neil Samson instead of NightStrike? >> Is it any more "real"? >> >> Look, you don't want me to be here... fine. I get it. Enough is >> enough already. Technical disagreements are one thing. Personal >> attacks on me are just juvenile. >> > > I don't see this as a personal attack. > > Like Paolo, I'm a lot more likely to read a message from someone with a real > name, or at least a name that sounds real. Maybe not a personal attack, but it certainly could have been expressed in a less offensive way. I think the offered service might help improve responsiveness of the GCC Community to patches. Maybe we should create a generic "GCC Patch Ping" account. Constructive suggestions would be much more helpful in this thread. David
Re: Patch pinging
On Mon, Jun 7, 2010 at 10:43 PM, Chiheng Xu wrote: > On Tue, Jun 8, 2010 at 9:14 AM, Ben White wrote: >> Would a modestly modified copy of Bugzilla be workable for that something? >> I.E. Patchzilla? > > Think about mercurial or git. Every one can commit on his/her own > local repository, and "publish" his/her repository. Every one can > pull other people's changes into his/her own repository, and can > selectively merge interesting/valuable changes. Every patch have it's > own branch. So called "approved patches" will be those patches whose > branches have been merged. Then, you only need to think whether or not > merge the branches the patches reside. > > If you use mercurial or git, every change will not be lost, every one > can review and selectively merge any branch on his/her convenience. > git is an excellent tool to create and share patches. Maybe we should have an open gcc git mirror with gitweb and every contributor can create his/her own branches and publish them. -- H.J.
Re: Patch pinging
On 8 June 2010 17:42, H.J. Lu wrote: > > git is an excellent tool to create and share patches. Maybe we should > have an open gcc git mirror with gitweb and every contributor can create > his/her own branches and publish them. http://gcc.gnu.org/wiki/GitMirror I don't see how such a thing solves the issue of patches from first-time contributors being ignored. Cheers, Manuel.
Variadic functions
Hi,
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue. Please see below for the
original. Any tips would be greatly appreciated.
/Jonas
Forwarded Message
From: jonas at southpole dot se
To: ucl...@uclibc.org
Subject: Variadic functions
Date: Tue, 08 Jun 2010 09:22:28 +0200
Hi,
I am working on the OPENRISC32 (or32) architecture port of uClibc and
have run into a bit of conundrum that I was hoping someone could help me
understand a bit better. Please bear with me...
--
The preconditions:
i) The declaration of xdrproc_t is variadic:
typedef bool_t (*xdrproc_t) (XDR *, void *, ...);
ii) In libc/inet/rpc/xdr.c the functions choices->proc, which of type
xdrproc_t is called:
return (*(choices->proc)) (xdrs, unp, LASTUNSIGNED);
iii) choices->proc may be dereferenced to the function
"xdr_accepted_reply" which is defined in libc/inet/rpc/rpc_prot.c as:
bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }
---
Now, the problem:
i) As xdr_accepted_reply is not defined as variadic, the function is
compiled to find the parameters in registers r3 and r4.
ii) As choices->proc is variadic (according to the declaration), the
compiler puts the first parameter in a register and the second on on the
stack.
This, of course, becomes problematic!!!
---
Workaround:
i) By redefining xdr_accepted_reply to be variadic, the compiler makes
the function look for paramter 1 in a register and paramter 2 on the
stack, thus matching what it does for the function call. Like this...
bool_t
xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar, ...) { ... }
Questions:
i) Is my compiler broken? If so, is there somewhere in GCC that
specifically handles register/stack parameter passing for variadic
functions??? (GCC 4.2, patched for or32)
ii) What is the correct compiler behaviour variadic
declarations/definitions? Should xdr_accepted_reply not be variadic
since it is used in such a context? Note that there are several
functions that are cast to xdrproc_t and none of them are defined as
variadic...
iii) Any advice on how to proceed... I know I need to patch something,
but I'm not sure if it's GCC,binutils, or uClibc.
Thanks for bearing with me on this. Regards,
Jonas
Re: Patch pinging
On 06/08/2010 05:42 PM, H.J. Lu wrote: >> Think about mercurial or git. Every one can commit on his/her own >> local repository, and "publish" his/her repository. [...] > > git is an excellent tool to create and share patches. Maybe we should > have an open gcc git mirror with gitweb and every contributor can create > his/her own branches and publish them. Well, we do: Goto http://repo.or.cz/w/official-gcc.git and click on "fork". I do like Git, but Git seems to make mostly sense if you have a small project on which you are working. If you have only a small patch (or a collection of small and unrelated patches), it won't help much. Additionally, I do not think that pulling from a branch will happen - rather that one creates patches from an (published or unpublished) git repository and submits them like normal. Thus, I do not think it helps with patch reviewing/tracking, though I believe it helps with developing patches. Tobias, who happily uses his private GCC git repository, which does not diverge much from the git master.
Re: Patch pinging
> Are you volunteering to write that small script? If nothing better comes out, why not, but resurrecting the Patch Tracker seems to be a more appealing idea. -- Eric Botcazou
Re: Patch pinging
On Tue, 2010-06-08 at 09:21 -0600, Jeff Law wrote:
> >
> > Look, you don't want me to be here... fine. I get it. Enough is
> > enough already. Technical disagreements are one thing. Personal
> > attacks on me are just juvenile.
> >
> I don't see this as a personal attack.
>
> Like Paolo, I'm a lot more likely to read a message from someone with a
> real name, or at least a name that sounds real.
I also agree with Paolo, and I am not sure you could entirely hide your
true (legal) identity.
To commit code to GCC, you need to have signed some legal document with
FSF (e.g. a copyright transfer or disclaimer). I am not a lawyer, but I
would guess that for that document you'll need to reveal who you are.
Therefore, what is the point of hiding your name on this list? AFAIU,
someone (at least at FSF or at Codesourcery or at the organization
responsible of gcc.gnu.org subversion server) legally needs to know who
you are, and which legal document covers your contributions to GCC.
There is no personal attack involved.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
On 06/08/2010 08:40 PM, Basile Starynkevitch wrote: > There is no personal attack involved. For sure. Sorry if my quick remark could be interpreted in another way. Paolo.
Re: Patch pinging
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
> >>
> >> I don't understand. WAA rights definitely allow you to shepherd and commit
> >> patches from people without svn access, even for patches you can't approve.
> >
> > And basile (and other WAA contributors), this would a nice
> > contribution. Asking people that do not appear to have access to svn
> > whether you want to commit their patches for them. And keeping them in
>
> It should say: "whether they want you to commit their patches for them."
I thought that for legal reasons, WAA contributors should not commit
code which is not theirs, or on which they did not see the legal
copyright transfer or disclaimer form for the FSF.
Since such legal documents are not public, that restriction means in
practice that I could only reasonably commit only code that either I
have written, or that someone covered by the same legal documents than I
am, have written. For me Basile, the only person in that case I can
think of today is Jeremie Salvucci (my intern) and possibly Marc
Duranton (who started worked at CEA LIST, my employer).
So I don't understand how can I svn-commit code which I don't have
written (or which has not been written by a near colleague covered by
the same legal documents).
Could someone explain what exactly are the rules for committing code?
I probably am understanding them too restrictively.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
On 06/08/2010 09:21 PM, Basile Starynkevitch wrote: On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote: I don't understand. WAA rights definitely allow you to shepherd and commit patches from people without svn access, even for patches you can't approve. And basile (and other WAA contributors), this would a nice contribution. Asking people that do not appear to have access to svn whether you want to commit their patches for them. And keeping them in It should say: "whether they want you to commit their patches for them." I thought that for legal reasons, WAA contributors should not commit code which is not theirs, or on which they did not see the legal copyright transfer or disclaimer form for the FSF. You can either ask someone to look up the copyright status or commit patches that are trivial. The copyright status of a person is usually clear from the mailing list; if you're particularly interested in a patch and you cannot figure out their status you can ask on-list or off-list. Here are a few of the people with access to the copyright list: me, Ian, Benjamin Koznik, David Edelsohn, Andreas Schwab, Joseph Myers, Ralf Wildenhues. This is not a complete list, just people that I remember. So I don't understand how can I svn-commit code which I don't have written (or which has not been written by a near colleague covered by the same legal documents). Or which has not been written by someone whose patches already got in the tree, so that you can already trust him/her. BTW, several companies have a company-wide copyright assignment too. The only one I can name that may need some help with commits is Mozilla. Paolo
Re: Pseudo frame pointer register in assembly code
"Naveen H. S" writes:
> The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
> I am using the following macros in header file to eliminate the pseudo
> arg pointer and frame pointer.
> However, there are some instances of frame pointer in the assembly code.
> #define ELIMINABLE_REGS \
> {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
> {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
> {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
In gcc, some functions must have a frame pointer. E.g., a function
which calls alloca or allocates a dynamically sized array. So you can
not always eliminate the frame pointer in favor of the stack pointer.
You can address this in one of two ways. First, you can simply make
FRAME_POINTER_REGNUM be a hard register. Second, you can define a
hard register HARD_FRAME_POINTER_REGNUM. Either way, it should not be
a fixed register. In the latter case, have an elimination from
FRAME_POINTER_REGNUM to HARD_FRAME_POINTER_REGNUM. See the docs for
HARD_FRAME_POINTER_REGNUM and look at the backends which use it.
Ian
Re: Experimental Patchwork setup
"Segher Boessenkool" writes: > Jeremy has set up a Patchwork instance for us at > >http://patchwork.ozlabs.org/project/gcc/list/ . > > It is feeding from gcc-patches; the plan is to make it > automatically recognise what patches went into the tree, > probably by snooping the gcc-cvs list. > > You can also manually change patch status, if you're an > admin; who is admin currently has to be configured manually, > plan is to make everyone with an email @gcc.gnu.org admin > automatically. In the meantime, if you want to play with > it, tell me and I'll get you added. > > There aren't many patches in the system yet, so we'll need > to let it run for a few weeks at least for it to prove its > worth. > > Any feedback is very welcome. Go play with it :-) This is quite interesting, thanks for setting it up. I can see already that to be useful for gcc today it will need some curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1) committed; 2) on a branch. This one http://patchwork.ozlabs.org/patch/54958/ is committed to trunk. Are there ways that we can adjust our e-mail messages to make this work better? Ian
Re: Variadic functions
Jonas Bonn writes:
> I am forwarding to you a mail that I sent to the uClibc mailing list as
> I think it is actually a compiler issue. Please see below for the
> original. Any tips would be greatly appreciated.
This message would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org. Please take any followups to gcc-help.
Thanks.
> i) The declaration of xdrproc_t is variadic:
>
> typedef bool_t (*xdrproc_t) (XDR *, void *, ...);
>
> ii) In libc/inet/rpc/xdr.c the functions choices->proc, which of type
> xdrproc_t is called:
>
> return (*(choices->proc)) (xdrs, unp, LASTUNSIGNED);
>
> iii) choices->proc may be dereferenced to the function
> "xdr_accepted_reply" which is defined in libc/inet/rpc/rpc_prot.c as:
>
> bool_t
> xdr_accepted_reply (XDR *xdrs, struct accepted_reply *ar) { ... }
Casting a function pointer to a different type and then calling it is
undefined behaviour in C/C++. The standard does not guarantee that
this program will work.
> i) Is my compiler broken? If so, is there somewhere in GCC that
> specifically handles register/stack parameter passing for variadic
> functions??? (GCC 4.2, patched for or32)
This problem does not indicate that your program is broken. Calling
variadic functions is handled specially in the backend. I am not
familiar with the or32 backend, but that is where the code would be.
> ii) What is the correct compiler behaviour variadic
> declarations/definitions? Should xdr_accepted_reply not be variadic
> since it is used in such a context? Note that there are several
> functions that are cast to xdrproc_t and none of them are defined as
> variadic...
That is broken. You can not casually cast function pointers to
different types. You especially can not cast them between variadic
and non-variadic.
> iii) Any advice on how to proceed... I know I need to patch something,
> but I'm not sure if it's GCC,binutils, or uClibc.
You need to patch the source code. It sounds like that source code is
in uClibc.
Ian
Re: Experimental Patchwork setup
>> It is feeding from gcc-patches; the plan is to make it >> automatically recognise what patches went into the tree, >> probably by snooping the gcc-cvs list. > This is quite interesting, thanks for setting it up. All kudos go to Jeremy, I merely try to push people :-) > I can see already that to be useful for gcc today it will need some > curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1) > committed; 2) on a branch. This one > http://patchwork.ozlabs.org/patch/54958/ is committed to trunk. Are > there ways that we can adjust our e-mail messages to make this work > better? [I changed those patches to "accepted" state]. The plan is to make it recognise the patches that went in (by taking a hash over the whole patch). This will probably catch most. Maybe it'll work better to take the ChangeLog instead, we'll see. Some manual work will always be needed; I think this is better than annoying everyone all the time with extra procedural stuff. When (if) it automatically recognises patches that went in, we can start experimenting with automatically pinging old patches. The goal is to be useful while not being annoying, being bureaucratic, taking up much valuable time from anyone. Segher
Re: Patch pinging
On 08/06/2010 20:31, Paolo Bonzini wrote: > Here are a few of the people with access to the copyright list: me, Ian, > Benjamin Koznik, David Edelsohn, Andreas Schwab, Joseph Myers, Ralf > Wildenhues. This is not a complete list, just people that I remember. I also have access and am happy to be asked to check the list to help get a patch cleared. cheers, DaveK
gcc-4.4-20100608 is now available
Snapshot gcc-4.4-20100608 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100608/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 160447 You'll find: gcc-4.4-20100608.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100608.tar.bz2 C front end and core compiler gcc-ada-4.4-20100608.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100608.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100608.tar.bz2 C++ front end and runtime gcc-java-4.4-20100608.tar.bz2 Java front end and runtime gcc-objc-4.4-20100608.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100608.tar.bz2The GCC testsuite Diffs from 4.4-20100601 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Re: Patch pinging
On 6/8/10, NightStrike wrote: > Are you volunteering to write that small script? DUnno, are you volunteering to write that small script? You're the only one here actually volunteering a forwardgoing commitment of their time here to improve GCC's development in this way, it seems (and mostly just getting vilified for it, for using a bizarre camelcase name!) What I expected to happen was that you would start doing whta you envision should happen by hand, and would then get so bored at doing it that out of laziness you'd automate it somehow. :) Still, we'll see... M
Re: Experimental Patchwork setup
Hi Ian, > I can see already that to be useful for gcc today it will need some > curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1) > committed; 2) on a branch. This one > http://patchwork.ozlabs.org/patch/54958/ is committed to trunk. There are a number of ways to keep the patch states up-to-date: 1) You can get the maintainers/committers to manually update the states. Simplest solution, but will add work to the folks who are already busy. 2) Use the command-line patchwork client to update patch state when a patch is committed. People have done this with a git post-commit hook to update the state of the patch in patchwork; I'm not sure if svn has something equivalent. 3) Batch-process the commit logs every once in a while. This can be done by anyone who is a patchwork admin for the project. The second two rely on the patchwork hash of the patch. When a patch comes in, patchwork calculates a hash of the diff (minus a few things likely to change, like line numbers). The command-line client can reference patches by this hash, and so you don't need to keep any patchwork metadata in the changes. > Are there ways that we can adjust our e-mail messages to make this work > better? As a design principle of patchwork, I've tried to avoid having to add patchwork metadata to the changes - after all, once the patch has gone in, the patchwork stuff is no longer relevant, and I don't want it polluting anyone's changelog... There is one header you can add to emails: X-Patchwork-Hint: ignore - this will tell patchwork to ignore the patch completely. I use this when sending a "this is the stuff I'm merging for the next release" email, as all of the patches have already been through the list. Cheers, Jeremy
Re: Patch pinging
On Tue, Jun 8, 2010 at 11:55 PM, Tobias Burnus wrote: > On 06/08/2010 05:42 PM, H.J. Lu wrote: >>> Think about mercurial or git. Every one can commit on his/her own >>> local repository, and "publish" his/her repository. [...] >> >> git is an excellent tool to create and share patches. Maybe we should >> have an open gcc git mirror with gitweb and every contributor can create >> his/her own branches and publish them. > > Well, we do: Goto http://repo.or.cz/w/official-gcc.git and click on "fork". > > I do like Git, but Git seems to make mostly sense if you have a small > project on which you are working. If you have only a small patch (or a > collection of small and unrelated patches), it won't help much. > > Additionally, I do not think that pulling from a branch will happen - > rather that one creates patches from an (published or unpublished) git > repository and submits them like normal. > > Thus, I do not think it helps with patch reviewing/tracking, though I > believe it helps with developing patches. > > Tobias, > who happily uses his private GCC git repository, which does not diverge > much from the git master. > The philosophy behind DVCS(mercurial or git) is that, any software project is an evolution tree, like the one of the lives of Planet Earth. This evolution tree has a root, which is the UCA(Ultimate Common Ancestor) of all lives. For the lives of Planet Earth, UCA may be some kind of ancient micro-organism. For a software, UCA would be the revision zero. Everyone can make change to any revision, do some minor improvement, to let the evolution tree to branch and grow. Everyone can merge other people's valuable branch/change in his/her own branch, this is like bi-sex reproduction. Everyone can make his/her branch more perfect to gain some survival advantage. The changes that will be in the final releases is those whose branches have been merged into trunk. Everyone strive to let his/her branch be merged, otherwise his/her branch will die. If someone's branch are rejected, he/she can try to redo his change, maybe from an newer trunk revision. When his/her changes meet some criteria, he/she can ask someone to review his branches and selectively merge. The died branch are never lost, it is stored in the repositories persistently, and can revive at any time. If someone's branch diverge far from the trunk, it may be very hard to merge. So branches from a relatively newer trunk revision and have not too many changes will be desirable. In this method, you only need to note the branch(and its URL) to review, instead of attach the patches. By the way, I found mercurial are easier to learn and use. -- Chiheng Xu Wuhan,China
Re: Patch pinging
On Tue, Jun 8, 2010 at 7:03 PM, Martin Guy wrote: > On 6/8/10, NightStrike wrote: >> Are you volunteering to write that small script? > > DUnno, are you volunteering to write that small script? Sorry, no :( > You're the only one here actually volunteering a forwardgoing > commitment of their time here to improve GCC's development in this > way, it seems (and mostly just getting vilified for it, for using a > bizarre camelcase name!) Thanks for noticing :) > What I expected to happen was that you would start doing whta you > envision should happen by hand, and would then get so bored at doing > it that out of laziness you'd automate it somehow. :) I was thinking of ways to make it a little easier. What I proposed was really not all that time consuming, though. > Still, we'll see... Apparently not :(
Re: Experimental Patchwork setup
On 06/08/2010 10:37 PM, Ian Lance Taylor wrote: Are there ways that we can adjust our e-mail messages to make this work better? Two things: 1) we should make the [bracket] prefixes more standard for patches destined to feature branches; 2) we should likely not send multiple patches in one email as attachments. Another point about (1): I believe patchwork should *not* track most of the branch patches, and the commit detection shouldn't care about release branch commits, only trunk. This is because those are 99% of the time for trunk too, and whether the patches went on the release branches is effectively already tracked via bugzilla. Paolo
