On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
> sprintf(dest, "%d", arg1); -> a new function that does the same thing,
> but without the overhead of parsing the format string. Like itoa on some
> platforms. We could inline it as well. That would allow further
> optimizations, if for example the co
fafa wrote:
I tried to build gcc from the latest snapshot (gcc-4.3-20071005),
but I undefined the symbol "__GTHREAD_HAS_COND"
which is desribed in libstdc++-v3\ChangeLog as follows:
...
[!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks.
...
But libstdc++-v3\libsupc++\guard.c
On Tue, Oct 09, 2007 at 09:46:35PM +0100, Heikki Linnakangas wrote:
> Essentially,
>
> sprintf(dest, "%d-%d-%d", a, b, c);
>
> is transformed into:
>
> dest += sprintf_prim_d(dest, a);
> *(dest++) = '-';
> dest += sprintf_prim_d(dest, b);
> *(dest++) = '-';
> dest += sprintf_prim_d(dest, c);
>
Denys Vlasenko <[EMAIL PROTECTED]> writes:
> /* Fast path for "...%s...%s...%s..." */
> while (p[1] == 's') {
That does not handle multibyte characters.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key finge
Denys Vlasenko wrote:
> On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
>> but it does beat glibc (5.20s) by a wide margin.
>> However, preparsing the format string in gcc still beats the linux
>> version hands down (0.82s).
>
> You preparse "%d-%d-%d"? Into what?
Essentially,
sprin
On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
> The new linux code is slightly but not much faster than the old one
> (3.04s vs 3.16s),
Test on my machine (three runs)
$ time ./sprintf-linux
./sprintf-linux 10-70-110
user0m2.018s
user0m2.024s
user0m1.997s
$ time ./sprin
Denys Vlasenko wrote:
> On Monday 08 October 2007 16:08, Heikki Linnakangas wrote:
>> Denys Vlasenko wrote:
>>> In linux kernel, decimal conversion in vsprintf() is optimized
>>> with custom conversion code. x3 faster, and no, it's not written in
>>> assembly.
>> Interesting. I copy-pasted the cod
David Daney wrote:
> Mark Mitchell wrote:
> v v
>> GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13
>> 2007)
>> |\
>> v v
>> GCC 4.3 Stage 2
Mark Mitchell wrote:
v v
GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13 2007)
|\
v v
GCC 4.3 Stage 2 GCC 4.2.1
The GCC 4.2 branch is now open for checkins, under the usual
regressions-only rules. (Release announcement coming shortly.)
This patch is the mechanical web-site required in the wake of the
4.2.2 release.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Index: index.html
===
Please send comments on these web pages [...] to our developer mailing
list at [EMAIL PROTECTED] or gcc@gcc.gnu.org
To complicate the harvesting of e-mail addresses from the web archives
of the GCC mailing lists, some simple transformations are done on the
e-mail addresses.
Please, could you
On Mon, Oct 08, 2007 at 02:50:06PM -0700, Janis Johnson wrote:
>
> Might this be related to http://gcc.gnu.org/PR33645?
Possibly. We think that we saw a problem rebuilding one of
the math functions in libgcc2 at -O2 with unit-at-a-time
disabled, that resulted in a compilation failure. Since
that
On 10/9/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Yes
> we do not create subvars for non-named memory locations. IE random
> pointer dereferences.
>
> This is mainly because it would require a lot of time and memory in
> the compiler.
>
> It was done because most optimizers rely solely on vde
On 10/9/07, Pranav Bhandarkar <[EMAIL PROTECTED]> wrote:
> Hi,
> consider the following code,
>
> struct x { int a; int b; int c; int d; int e[120];};
> struct x *a, *b;
> void foo ( )
> {
> *a = *b;
> }
>
> Now for the stmt int the function foo a memcpy will be generated.
> However, this can b
Hi Ian,
sorry for the late response. I was on vacation for the last two
weeks. (Btw. thats also the reason for the S/390 daily build system
being down over the last days. It is back online now.)
> > The lengthy part is necessary to have attribute getter functions which
> > allow to specify the
Bootstrap on i386-linux has been broken for a week now, from what I
can see. I have reported it as PR33679
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679), but AFAIK noone
has reproduced it, as most people now build for i686-linux. Could
someone please spare a cycle to confirm this problem? I c
Hi,
consider the following code,
struct x { int a; int b; int c; int d; int e[120];};
struct x *a, *b;
void foo ( )
{
*a = *b;
}
Now for the stmt int the function foo a memcpy will be generated.
However, this can be tail call optimized. My aim is to identify such
opportunities in find_tail_ca
17 matches
Mail list logo
