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 in
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
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
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
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
> > i
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]
>
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/20
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 dir
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 he
> 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 p
>
> 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 sit
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
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
-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
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.
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
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. Mos
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/maintaine
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
> >>
--- 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"
> > >
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/7
[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));
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)
> >
> 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)
>
24 matches
Mail list logo
