Re: help interpreting gcc 4.1.1 optimisation bug
> The correct version is I think,
>
> void longcpy(long* _dst, long* _src, unsigned _numwords)
> {
> asm volatile (
> "cld \n\t"
> "rep \n\t"
> "movsl \n\t"
> // Outputs (read/write)
> : "=S" (_src), "=D" (_dst), "=c" (_numwords)
> // Inputs - specify same registers as outputs
> : "0" (_src), "1" (_dst), "2" (_numwords)
> // Clobbers: direction flag, so "cc", and "memory"
> : "cc", "memory"
> );
> }
I did not re-check with GCC-4.1.1, but I noticed problems with this
kind of "memory" clobber: when the source you are copying from is
not in memory but (is a structure) in the stack. I have to say that
I tend to use a form without "volatile" after the asm (one of the
result has to be used then).
The usual symtom is that the memcopy is done, but the *content* of the
source structure is not updated *before* the memcopy: nothing in your
asm says that the content of your pointer has to be up-to-date.
The "memory" says that main memory will be changed, not that it will be
used, and if you are memcopy-ing from a structure in stack - for instance
a structure which fit in a register - you may have problems.
That is why IHMO it is better to do type copying by directly copying
structure (mostly when using -fstrict-aliasing) instead of using
memcpy() - like: struct {int a,b,c } x, y = {0,1,1}; x = y;
The main disadvantage of the type copying is the relatively bad code
that previous compiler can generate for it, and that bug may appear
(correct me if I am wrong) because by not calling an external function
called memcpy() you are again not forcing the external memory to be
updated - but it should be quicker for exactly the same reason.
I did not really experiment with __builtin_memcpy(), is it treated
specially or like a standard function call; I do not know if:
int globint;
int fct (short *a, short *b) {
globint = 3;
__builtin_memcpy(a, b, sizeof(*a));
if (globint == 3)
return 1;
else
return 0;
}
Is the test present or optimised away like in:
int globint;
int fct (short *a, short *b) {
globint = 3;
*a = *b;
if (globint == 3)
return 1;
else
return 0;
}
Etienne.
__
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible
contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
Re: help interpreting gcc 4.1.1 optimisation bug
Etienne Lorrain writes:
> > The correct version is I think,
> >
> > void longcpy(long* _dst, long* _src, unsigned _numwords)
> > {
> > asm volatile (
> > "cld \n\t"
> > "rep \n\t"
> > "movsl \n\t"
> >// Outputs (read/write)
> > : "=S" (_src), "=D" (_dst), "=c" (_numwords)
> >// Inputs - specify same registers as outputs
> > : "0" (_src), "1" (_dst), "2" (_numwords)
> >// Clobbers: direction flag, so "cc", and "memory"
> > : "cc", "memory"
> > );
> > }
>
> I did not re-check with GCC-4.1.1, but I noticed problems with this
> kind of "memory" clobber: when the source you are copying from is
> not in memory but (is a structure) in the stack. I have to say that
> I tend to use a form without "volatile" after the asm (one of the
> result has to be used then).
>
> The usual symtom is that the memcopy is done, but the *content* of the
> source structure is not updated *before* the memcopy: nothing in your
> asm says that the content of your pointer has to be up-to-date.
>
> The "memory" says that main memory will be changed, not that it will be
> used, and if you are memcopy-ing from a structure in stack - for instance
> a structure which fit in a register - you may have problems.
Why, exactly? the structure has its address taken, and therefore at
the point at which the asm is invoked it'll be in memory. For sure,
if you fail to use volatile the compiler may decide that the asm can
be deleted. So use volatile: that's what it's for.
If the compiler fails to write a struct to memory before the asm is
executed, that's a bug in the compiler.
> I did not really experiment with __builtin_memcpy(), is it treated
> specially or like a standard function call
It's treated specially.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> On Tue, Jun 13, 2006 at 12:01:39PM +0100, Andrew Haley wrote:
> >
> > All you've got here is an inline asm version of
> >
> > inline void longcpy(long* _dst, long* _src, unsigned _numwords)
> > {
> > __builtin_memcpy (_dst, _src, _numwords * sizeof (long));
> > }
> >
> > which gcc will optimize if it can.
> >
> > These days, "rep movs" is not as advantageous as it once was, and you
> > may get better performance by allowing gcc to choose how to do memory
> > copies.
>
> Actually, I knew this, but I was using longcpy as a bellwether
> of many more complex inline-asm functions in a c++ big integer
> library.
OK. I'm used to seeing random bits of inline asm that might have made
sense Once Upon A Time but now only serve to slow down a program!
> I've just finished a trawl through the entire library, fixing a Good
> Many Things which I now know (thanks to you guys) could really confuse
> the optimiser.
That's great.
Andrew.
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Ian Lance Taylor wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > >> It can also tell you who to copy on a ping email to make sure it >> actually goes to a maintainer. >> the interface is under construction, but "okay" for casual use. >> http://www.dberlin.org/patches/patches/maintainer_list/745 would be the >> one for this patch. > > I'm on that list, but I can't approve this patch. It needs approval > from a build system maintainer, not a middle-end maintainer. The maintenance area was listed by the submitter as " build and middle-end" hence the reason the middle end maintainers are listed.
RE : Re: help interpreting gcc 4.1.1 optimisation bug
--- Andrew Haley <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain writes:
> > > The correct version is I think,
> > >
> > > void longcpy(long* _dst, long* _src, unsigned _numwords)
> > > {
> > > asm volatile (
> > > "cld \n\t"
> > > "rep \n\t"
> > > "movsl \n\t"
> > > // Outputs (read/write)
> > > : "=S" (_src), "=D" (_dst), "=c" (_numwords)
> > > // Inputs - specify same registers as outputs
> > > : "0" (_src), "1" (_dst), "2" (_numwords)
> > > // Clobbers: direction flag, so "cc", and "memory"
> > > : "cc", "memory"
> > > );
> > > }
> >
> > I did not re-check with GCC-4.1.1, but I noticed problems with this
> > kind of "memory" clobber: when the source you are copying from is
> > not in memory but (is a structure) in the stack. I have to say that
> > I tend to use a form without "volatile" after the asm (one of the
> > result has to be used then).
> >
> > The usual symtom is that the memcopy is done, but the *content* of the
> > source structure is not updated *before* the memcopy: nothing in your
> > asm says that the content of your pointer has to be up-to-date.
> >
> > The "memory" says that main memory will be changed, not that it will be
> > used, and if you are memcopy-ing from a structure in stack - for instance
> > a structure which fit in a register - you may have problems.
>
> Why, exactly? the structure has its address taken, and therefore at
> the point at which the asm is invoked it'll be in memory.
Well, first I am not sure it is still happening with GCC-4.1.1, and two I
never got a reasonnable test case else you would have seen a bug report.
The last time I noticed it was when I had to modify my file xms.h from:
extern inline unsigned short
_XMS_move_memory (farptr entrypoint, XMS_EMM *emm_struct,
unsigned char *error)
{
unsigned short status;
asm volatile (" lcallw *%a4 # XMS entry point, _XMS_move_memory "
: "=a" (status), "=b" (*error)
: "a" (0x0B00), "S" (emm_struct) /* %ds:%si */,
"pr" (&entrypoint)
);
if (status == 0x0001)
return 0; /* OK */
else
return 1; /* failed */
}
to:
extern inline unsigned short
_XMS_move_memory (farptr entrypoint, XMS_EMM *emm_struct,
unsigned char *error)
{
unsigned short status;
asm volatile (" lcallw *%a4 # XMS entry point, _XMS_move_memory "
: "=a" (status), "=b" (*error)
: "a" (0x0B00), "S" (emm_struct) /* %ds:%si */,
"pr" (&entrypoint), "m" (*emm_struct)
);
if (status == 0x0001)
return 0; /* OK */
else
return 1; /* failed */
}
With the first version Gujin (at sourceforge) does not work, with the second
it does work - that function is inline in another big function so the assembler
is not easy to read. emm_struct is a resonnably complex structure in the stack.
I had to do this in few other include files with "m"(*ptr) or "X"(*ptr) for the
same project in v1.4.
> For sure,
> if you fail to use volatile the compiler may decide that the asm can
> be deleted. So use volatile: that's what it's for.
I do not want the asm to be deleted when it is used, but in some case the
compiler
sees that I am not using the result and so I want GCC to delete the asm.
Consider:
inline void longcpy(long* _dst, long* _src, unsigned _numwords);
inline void fct (long array[3], int doit)
{
long safe_copy[3];
longcpy(safe_copy, array, 3);
if (!doit)
return; /* safe_copy not used at all, remove the variable and the asm() */
;
}
void fct2(void) { fct (x, 0); }
> If the compiler fails to write a struct to memory before the asm is
> executed, that's a bug in the compiler.
It you just said GCC that the pointer is read I am not sure it is assuming
that the content of this pointer is read - I may be wrong.
Etienne.
__
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible
contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Daniel Berlin <[EMAIL PROTECTED]> writes: > >> It can also tell you who to copy on a ping email to make sure it > >> actually goes to a maintainer. > >> the interface is under construction, but "okay" for casual use. > >> http://www.dberlin.org/patches/patches/maintainer_list/745 would be the > >> one for this patch. > > > > I'm on that list, but I can't approve this patch. It needs approval > > from a build system maintainer, not a middle-end maintainer. > > The maintenance area was listed by the submitter as " build and > middle-end" > > > hence the reason the middle end maintainers are listed. Yeah, I did see that. I guess that naturally leads to the next question: how do I edit that field? There ought to be some nice little AJAX editor to let me adjust all the fields, assuming of course that I have a valid SSL enabled login. Maybe you could work on that this afternoon if you have a free hour. Ian
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Ian Lance Taylor wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > It can also tell you who to copy on a ping email to make sure it actually goes to a maintainer. the interface is under construction, but "okay" for casual use. http://www.dberlin.org/patches/patches/maintainer_list/745 would be the one for this patch. >>> I'm on that list, but I can't approve this patch. It needs approval >>> from a build system maintainer, not a middle-end maintainer. >> The maintenance area was listed by the submitter as "build and >> middle-end" >> >> >> hence the reason the middle end maintainers are listed. > > Yeah, I did see that. I guess that naturally leads to the next > question: how do I edit that field? There ought to be some nice > little AJAX editor to let me adjust all the fields, assuming of course > that I have a valid SSL enabled login. Maybe you could work on that > this afternoon if you have a free hour. I'm already ahead of you. For the moment, i'm just going to add an edit button. I have to read up on the in-place editor API before i can just make it editable. Anyway, the editor will only adjust the maintenance and url fields. The rest is auto-grabbed from the url. > > Ian >
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Daniel Berlin wrote on 06/13/06 23:24: > Does anyone believe this would help make sure patches stop dropping > through the cracks? > Not really. Technical solutions to social problems rarely work. Patch review is mostly a social problem. I am frequently part of the problem, unfortunately. Mostly this is a time constraint problem, there are only so many hours in a working day. I don't really have a good idea on how to address the core problem, other than to encourage adding more maintainers. A couple of Summits ago I think we discussed the idea of having secondary maintainers: folks who may not feel fully confident about an area, but may want to chime in with an initial review which the primary maintainer could then use to help with the final review. That doesn't mean that the patch queue is a bad idea. On the contrary, but if a patch is destined to fall through the cracks, no amount of technical infrastructure will prevent it from doing so.
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
On 6/14/06, Diego Novillo <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote on 06/13/06 23:24: > Does anyone believe this would help make sure patches stop dropping > through the cracks? > Not really. Technical solutions to social problems rarely work. Patch review is mostly a social problem. I am frequently part of the problem, unfortunately. Mostly this is a time constraint problem, there are only so many hours in a working day. I don't really have a good idea on how to address the core problem, other than to encourage adding more maintainers. A couple of Summits ago I think we discussed the idea of having secondary maintainers: folks who may not feel fully confident about an area, but may want to chime in with an initial review which the primary maintainer could then use to help with the final review. That doesn't mean that the patch queue is a bad idea. On the contrary, but if a patch is destined to fall through the cracks, no amount of technical infrastructure will prevent it from doing so. Some time ago I invented the obvious-because-nobody-cares rule under which you can apply a patch as obvious if nobody objected after two weeks. At least this is a workaround for the social problem (and creates another). ;) Richard.
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Diego Novillo <[EMAIL PROTECTED]> writes: > Daniel Berlin wrote on 06/13/06 23:24: > > > Does anyone believe this would help make sure patches stop dropping > > through the cracks? > > > Not really. Technical solutions to social problems rarely work. Patch > review is mostly a social problem. I am frequently part of the problem, > unfortunately. Mostly this is a time constraint problem, there are only > so many hours in a working day. You are of course correct in general. However, I believe there are specific cases in which generating reminder messages would help. The gcc-patches mailing list is a busy one. It's easy for people to miss a patch. It's also easy for people to assume that a patch to a particular area will be handled by a maintainer who tends to focus on that area. I think a reminder message that some patch is still outstanding could be helpful to catch these sorts of cases. Ian
DLLs for GCC/Windows (Was: Re: Cross-compilation and Shared Libraries)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent wrote: > > As far as I know, shared libstdc++ for mingw/cygwin has never worked, > you always get static no matter what you do, regardless of > --enable-shared or native/cross. I don't know if this is because of the > archaic version of libtool that's in the tree, or some other reason. It > sure would be nice to get a shared libstdc++ one of these days without > having to resort to hacks like manually linking together all the .o > files in the build tree. The libtool in the GCC tree seems to need --enable-win32-dll to build DLLs for Windows runtimes, which it would use only if the library defines AC_PROVIDE_AC_LIBTOOL_WIN32_DLL - I defined: AC_DEFUN([AC_PROVIDE_AC_LIBTOOL_WIN32_DLL],[]) in libstdc++-v3's configure.ac and regenerated configure. libtool also wants ld_shlibs to be set to "yes" and this I achieved by putting "ld_shlibs=yes" under the case label for "mingw*" in ltcf-cxx.sh. With these kludges, GCC tries to build libstdc++ as a DLL, but fails with undefined references to a whole bunch of stuff (crossed-native build on Linux). I'll investigate this issue later. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkEYkYb1hx2wRS48RApEfAJ9yCJPA5Pjk9+FjFQ8Y1nU27l6nHgCfZeKV YX+VfsdJE6ipkZvj8wgew8U= =XrJZ -END PGP SIGNATURE-
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
On Jun 13, 2006, at 8:24 PM, Daniel Berlin wrote: Past the above, I have no better ideas for getting patches reviewed other than appointing more maintainers. I'd welcome the issue be addressed by the SC. I'd favor more timely reviews. Maybe auto approval for a patch that sits for more than a week? :-)
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
On Jun 13, 2006, at 8:24 PM, Daniel Berlin wrote: > >Past the above, I have no better ideas for getting patches reviewed > >other than appointing more maintainers. On Wed, Jun 14, 2006 at 11:34:33AM -0700, Mike Stump wrote: > I'd welcome the issue be addressed by the SC. I'd favor more timely > reviews. Maybe auto approval for a patch that sits for more than a > week? :-) I see your smilie, Mike, but GCC would rapidly decay into a pile of random bytes, unable to build itself, much less anything else, under such a policy. The SC mainly has negative power, it can't make people do work. There have been a number of proposals that basically amount to threatening the patch reviewers with negative consequences, but I'm not for that. Certainly we can talk about mechanisms to help the reviewers, or try to recruit new help. I know it's frustrating for people when their hard work doesn't get reviewed for long periods of time. But GCC is a mature compiler, it's stable, and while it has bugs and could be better, I'm not sure I *want* GCC to start changing much more rapidly than it changes today. Bugs will be fixed, yes. New features will be introduced, yes. But will the quality level be maintained? That's the whole reason we insist on patch review, so any process that speeds it up has to guarantee that will still get a decent review of all patches (other than the truly obvious ones).
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
> > On Jun 13, 2006, at 8:24 PM, Daniel Berlin wrote: > > Past the above, I have no better ideas for getting patches reviewed > > other than appointing more maintainers. > > I'd welcome the issue be addressed by the SC. I'd favor more timely > reviews. Maybe auto approval for a patch that sits for more than a > week? :-) Auto approving is the wrong approach except in the case where the patch is small, even then questionable. Maybe a system where you can trade reviews for patches. Like if you want a patch to be reviewed and you make a promise to also do another patch for the review. Yes this might not always work but it might help the current situation. -- Pinski
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
> But GCC is a mature compiler, it's stable, and while it has bugs and could > be better, I'm not sure I *want* GCC to start changing much more rapidly > than it changes today. Bugs will be fixed, yes. New features will be > introduced, yes. But will the quality level be maintained? You can't put new features and bug fixes in the same basket. They can even be viewed as steering the compiler in opposite directions quality-wise. If you don't want to increase the patches-per-day ratio, the only solution is to prioritize bug fixes over new features. For example we could introduce secondary maintainers with approval rights for bug fixes only or something along these lines. -- Eric Botcazou
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Joe Buck <[EMAIL PROTECTED]> writes: > The SC mainly has negative power, it can't make people do work. > There have been a number of proposals that basically amount to threatening > the patch reviewers with negative consequences, but I'm not for that. > Certainly we can talk about mechanisms to help the reviewers, or try > to recruit new help. Yeah, we need positive feedback, not negative feedback. I think that every approved review (as tracked by some program, e.g., Danny's patch queue e-mail reader) the approver should get a gooble. And, just to make it more fun, the submitter should get one also. Whoever has the most goobles in any month gets to be Gcc Poobah of the Month. Whoever has the most in a year gets to be Gcc Grand Poobah for the next year. If we find a sponsor, or we all chip in a dollar, then the Gcc Grand Poobah can get a T-shirt and a funny hat. This may sound kind of dumb, but, hey, in an insular community people can care about the most trivial of things, even if they don't take them seriously. E.g., Slashdot Karma. Or, this may sound extremely dumb, in which case, never mind. Ian
what motivates people to submit patches anyway?
Not off topic, in response to thread about Goobles, and the contest to collect Goobles towards the purely symbolic end of becoming GCC Grand Poobah -- does this person get their own parking space? E-mail for [EMAIL PROTECTED] forwarded to them during thge duration of their reign? i think if direct benefits were engineered somehow -- even symbolicly, which they are, but more explicitly symbolicly -- there might be more better patches. Until someone comes up with a way to organize open-source projects as revenue generators -- even if only as t-shirt stores, with revenues from the t-shirts shared according to a decaying contribution share model -- an easy way to divide up the pie, no matter how small -- apathy will continue to reign. speaking very generally here, all volunteer-staffed best-efforts software projects share these kinds of problems.
sh-elf build failure on mainline]
The build fails with:
/mnt/scratch/nightly/2006-06-14/sh-elf/./gcc/xgcc
-B/mnt/scratch/nightly/2006-06-14/sh-elf/./gcc/ -nostdinc
-B/mnt/scratch/nightly/2006-06-14/sh-elf/sh-elf/newlib/ -isystem
/mnt/scratch/nightly/2006-06-14/sh-elf/sh-elf/newlib/targ-include
-isystem /mnt/scratch/nightly/2006-06-14/srcw/newlib/libc/include
-B/usr/local/sh-elf/bin/ -B/usr/local/sh-elf/lib/ -isystem
/usr/local/sh-elf/include -isystem /usr/local/sh-elf/sys-include
-L/mnt/scratch/nightly/2006-06-14/sh-elf/./ld -DHAVE_CONFIG_H
-I/mnt/scratch/nightly/2006-06-14/srcw/boehm-gc/include -fexceptions
-Iinclude -I././targ-include -I.//libc/include -O2 -g -O2 -fexceptions
-Iinclude -I././targ-include -I.//libc/include -c
../../../srcw/boehm-gc/allchblk.c -o allchblk.o
In file included from
/mnt/scratch/nightly/2006-06-14/srcw/boehm-gc/include/private/gc_priv.h:70,
from ../../../srcw/boehm-gc/allchblk.c:19:
/mnt/scratch/nightly/2006-06-14/srcw/boehm-gc/include/private/gcconfig.h:462:
error: expected identifier or '(' before '--' token
make[2]: *** [allchblk.lo] Error 1
make[2]: Leaving directory
`/mnt/scratch/nightly/2006-06-14/sh-elf/sh-elf/boehm-gc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/mnt/scratch/nightly/2006-06-14/sh-elf/sh-elf/boehm-gc'
make: *** [all-target-boehm-gc] Error 2
The attached patch alows the build to proceed past this obstacle,
although I don't know how patches to this files are supposed to be
handled, or if the build will eventually succeed.
Or why we need to cross-build boehm-gc for the target of a C / C++ /
objc cross compiler in the first place. We didn't one or two weeks ago.
2006-06-14 J"orn Rennecke <[EMAIL PROTECTED]>
* gcconfig.h (SH): Test for embedded target.
Index: gcconfig.h
===
/usr/bin/diff -p -d -F^( -u -L gcconfig.h (revision 114639) -L gcconfig.h
(working copy) .svn/text-base/gcconfig.h.svn-base gcconfig.h
--- gcconfig.h (revision 114639)
+++ gcconfig.h (working copy)
@@ -420,6 +420,20 @@
# define NOSYS
# define mach_type_known
# endif
+/* Embedded SH uses a leading _ for user labels. */
+# if defined (__GNUC__) && defined(__sh__) && !defined(__SH5__)
+# define CHECK_LABEL_PREFIX(X) CHECK_LABEL_PREFIX1(X)
+# define CHECK_LABEL_PREFIX1(X) \
+ CHECK_LABEL_PREFIX2(CHECK_LABEL_PREFIX_NUM##X)
+# define CHECK_LABEL_PREFIX2(X) X
+# define CHECK_LABEL_PREFIX_NUM 0
+# define CHECK_LABEL_PREFIX_NUM_ 1
+# if CHECK_LABEL_PREFIX(__USER_LABEL_PREFIX__)
+# define SH
+# define NOSYS
+# define mach_type_known
+# endif
+# endif
/* Ivan Demakov */
# if defined(__WATCOMC__) && defined(__386__)
# define I386
@@ -1888,6 +1902,16 @@
# define USE_GENERIC_PUSH_REGS
# define DYNAMIC_LOADING
# endif
+# ifdef NOSYS
+ extern char _etext[];
+# define DATASTART ((ptr_t)(&_etext))
+ extern char _end[];
+# define DATAEND (_end)
+# define OS_TYPE "NOSYS"
+ extern char stack[];
+# define STACKBOTTOM ((ptr_t)stack)
+# define USE_GENERIC_PUSH_REGS
+# endif
# endif
# ifdef SH4
Re: what motivates people to submit patches anyway?
On Wed, Jun 14, 2006 at 03:56:55PM -0500, David Nicol wrote: > Not off topic, in response to thread about Goobles, and the contest to > collect > Goobles towards the purely symbolic end of becoming GCC Grand Poobah -- does > this person get their own parking space? E-mail for [EMAIL PROTECTED] > forwarded to > them during thge duration of their reign? > > i think if direct benefits were engineered somehow -- even symbolicly, > which they are, > but more explicitly symbolicly -- there might be more better patches. It appears that you don't realize that many of the principal GCC developers do GCC development work as part of their paid job, either full-time or on a consulting basis. Most are still volunteers in the sense that they take on tasks that go beyond what they are directly being paid for, but they are in a position to spend a lot of time on GCC development and still put food on the table. The same is true of many Linux kernel developers.
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
On Wed, Jun 14, 2006 at 10:16:38PM +0200, Eric Botcazou wrote: > > But GCC is a mature compiler, it's stable, and while it has bugs and could > > be better, I'm not sure I *want* GCC to start changing much more rapidly > > than it changes today. Bugs will be fixed, yes. New features will be > > introduced, yes. But will the quality level be maintained? > > You can't put new features and bug fixes in the same basket. They can even > be > viewed as steering the compiler in opposite directions quality-wise. If you > don't want to increase the patches-per-day ratio, the only solution is to > prioritize bug fixes over new features. For example we could introduce > secondary maintainers with approval rights for bug fixes only or something > along these lines. That might make sense. I'm not saying I don't want to increase the patches-per-day ratio, particularly with respect to getting bug fixes in. However, bug fixes carry their own risk: I had a project where we found that one out of five fixes to critical bugs introduced another critical bug, though the number was so high because the project required critical bugs reported by customers to be fixed under severe time pressure so GCC would not see so high a ratio. Sometimes you need time to check whether a bug fix is really correct, or if it just patches over a symptom.
RE: Where is the egg?
On Sun, 11 Jun 2006, Stephan T. Lavavej wrote: > Of course, my dark lord. ^ I think this is a first for me. :-) > These are pngcrushed versions with linear dimensions between 50% and 80% > of the 200-pixel-high original. Thanks! I put these into our wwwdocs CVS in a new directory called htdocs/img. And updated the main page. "The eck is beck!" Gerald
Re: Some C++0x experiments
Mike Stump escreveu: > On Jun 9, 2006, at 6:31 PM, Pedro Lamarão wrote: >> Currently I have implemented in g++ the "Static Assertions" and the >> "Right Angle Brackets" C++0x features in g++. Those are the simplest >> ones that got into the working draft > >> Any feedback is welcome! > > Well, I hope that you are able to do up the paperwork to contribute the > changes and to contribute them. From what I read in contribute.html I believe I should need a personal assignment and an employer disclaimer. I'm willing, and I think my employer won't mind. How should I proceed? -- Pedro Lamarão
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
On Jun 14, 2006, at 11:51 AM, Joe Buck wrote: There have been a number of proposals that basically amount to threatening the patch reviewers with negative consequences, but I'm not for that. I too think that would be the wrong direction to go. I'm not sure I *want* GCC to start changing much more rapidly than it changes today. But, is change alone the basis to drive decisions? I hope not. gcc has always been driven by users. Fewer users, less change. More users, more change. I think there are ways to manage it and still keep the quality up. But will the quality level be maintained? Yes, we ensure the observable quality in part by the testsuite, this gets us a generally monotonic baseline and from the user's perspective, this is an important part of quality. This helps us scale in terms of the change load. I think there are other opportunities to help scale that have a beneficial impact on quality. For example, would be nice to have a batch tester that would bootstrap and regression test on 2-5 platforms for all patch submitters post approval but pre-checkin. If any regressions, dump all patches and move on to the next set, repeat as fast as possible. If they all pass the entire regression suite, all languages, then put them all in. In this fashion, at all points, for all the tested platforms, there could never be any regressions. This lends to stability for the developers in general and edges the quality up. This also can lesson the testing burden on individual contributers and free them of that task more often. That's the whole reason we insist on patch review, so any process that speeds it up has to guarantee that will still get a decent review of all patches (other than the truly obvious ones). When the patches are to fix regressions and bugs in the compiler, one can argue that quality isn't served by not fixing the problem. By making the process more efficient, we enable more bugs to be fixed and we further encourage more people to send in patches to fix more bugs, more often. I feel being responsive to patch submitters is being responsive to users, and being responsive to users it one way to get more users and a better reputation. More users, means in part, more testers and more diversity in testing. Discouraging patch submitters, and in the end that discourages users, and that results in less testing and less diverse code. I'm not advocating a free for all, but I do think we need to ensure that there are enough maintainers to ensure timely reviews. I'd argue that 1 month indicates that we don't have enough reviewer bandwidth. I'd argue that 10 months indicates the same thing, only more. The SC could ask for volunteers to be patch reviewers in areas where we have a backlog. If the existing maintainers don't want the help, this can motivate them to never have a backlog.
Re: {Spam?} Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
You can't put new features and bug fixes in the same basket. They can even be viewed as steering the compiler in opposite directions quality-wise. If you don't want to increase the patches-per-day ratio, the only solution is to prioritize bug fixes over new features. For example we could introduce secondary maintainers with approval rights for bug fixes only or something along these lines. I agree wholeheartedly. There could be tweaks like s/approval/review/ (in the sense that they cannot approve their own fixes) or restricting these reviewers to regressions. But in general I think it's a very good starting point! Paolo
