Daniel Berlin wrote:
> There is no guarantee that your bug will or won't be fixed for a
> certain release, etc, unless *you* start submitting the patches to
> fix it.
Actually, there's no guarantee that even if you submit patches to fix
a bug that it will be fixed in any official release.
On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote:
> I am hoping that the steering committee will order a through research on
> the bug.
Kevin, what you don't seem to understand is that the SC can't order
anyone to do anything. The SC has no employees, doesn't sign paychecks.
GCC is
On Aug 28, 2005, at 3:48 PM, Kevin McBride wrote:
Please take notice that I am appealing my bug (number 23605) to the
steering committee of GCC on the basis that it is a legimate
bug/enhancement in need of a through research.
Ok, so go research it, collect data, and then report your findings
On Sun, Aug 28, 2005 at 04:29:56PM -0700, Ian Lance Taylor wrote:
> In the meantime, I think there may be a bug here, in that memset is
> open coded for the i386 at -O0. That doesn't make sense to me; e.g.,
> it prevents setting a breakpoing on memset.
This, IMO, has nothing to do with i386. If
On Mon, 2005-08-29 at 01:33 -0400, Kevin McBride wrote:
> Joe Buck wrote:
> > I've looked at the bug in bugzilla; it's not marked as invalid, though
> > I tend to agree with Andrew and Ian's comments in the log.
>
> I set the bug back to unconfirmed after I noticed that, in my opinion,
> there ca
Joe Buck wrote:
I've looked at the bug in bugzilla; it's not marked as invalid, though
I tend to agree with Andrew and Ian's comments in the log.
I set the bug back to unconfirmed after I noticed that, in my opinion,
there can be more optimization done.
In any case, the SC doesn't get invol
On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote:
> Please take notice that I am appealing my bug (number 23605) to the
> steering committee of GCC on the basis that it is a legimate
> bug/enhancement in need of a through research. I believe that Andrew
> Pinski is trying to keep the
Kevin McBride <[EMAIL PROTECTED]> writes:
> Please take notice that I am appealing my bug (number 23605) to the
> steering committee of GCC on the basis that it is a legimate
> bug/enhancement in need of a through research. I believe that Andrew
> Pinski is trying to keep the research from occuri
On Sun, 2005-08-28 at 18:48 -0400, Kevin McBride wrote:
> Everyone,
>
> Please take notice that I am appealing my bug (number 23605) to the
> steering committee of GCC on the basis that it is a legimate
> bug/enhancement in need of a through research.
The Steering committee really doesn't get i
/23605] memset() Optimization on x86-32 bit
Date: 28 Aug 2005 22:21:15 -
From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
--- Additional Comments From pinskia at gcc dot gnu dot org
2005
Kevin McBride <[EMAIL PROTECTED]> writes:
> If you look closely, you can see that %edi can be automatically loaded
> directly without problems, and that (%eax) can be directly loaded into
> (%esp). Is this behavior intentional (for bugs I don't know about in
> earlier processors) or could this op
I have a bit of a disagreement with the optimization toward memset()
calls. In one of my libraries, libteklti, I have a function named
ucharempty(), which frees a uchar_t (unique character structure) from
memory. If the user elects to have the memory erased prior to calling
free(), memset() is s
12 matches
Mail list logo