http://x-oyox.nm.ru Here that you asked taht. fshnl
Lijuan Hai wrote:
>
> I have a plan to convert UCN to alphabet instead of UTF8 in
> GCC-4.2.0, and already handled it in libcpp.
I would like to offer advice, but I don't understand what you are
trying to do. You say you want to "convert UCN[s] to [an] alphabet
instead of UTF8" but that doesn't m
Hi all,
I have a plan to convert UCN to alphabet instead of UTF8 in
GCC-4.2.0, and already handled it in libcpp. But I encountered a
problem when compiling the code like following:
---cut---
1: #define str(t) #t
2: int foo()
3: {
4:char* cc = str(\u1234);
5:
On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on my TODO list to code up the crypto
> > unit support for Niagara-2 in the kernel, th
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 09:23:47 -0800 (PST)
>
>
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on my TODO list to code up the crypto
> > unit suppor
On Fri, 7 Dec 2007, Ross Ridge wrote:
> Boris Boesler writes:
> > Ok, so what have I to do to write a back-end where all addresses are
> > given in bits? Memory is addressed in bits, not bytes. So I set:
> >
> > #define BITS_PER_UNIT 1
> > #define UNITS_PER_WORD 32
>
> I don't know if it's useful
Some interesting stats from the highly packed gcc repo. The long chain
lengths very quickly tail off. Over 60% of the objects have a chain
length of 20 or less. If anyone wants the full list let me know. I
also have included a few other interesting points, the git default
depth of 50, my initia
On 12/7/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
>
> > > >> Is SHA a significant portion of the compute during these repacks?
> > > >> I should run oprofile...
> > > > SHA1 is almost totally insignificant on x86. It hardly shows up. But
On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> > >> Is SHA a significant portion of the compute during these repacks?
> > >> I should run oprofile...
> > > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > > we have a good optimized version there.
> > > zlib tend
On Dec 7, 2007, at 2:14 PM, Jakub Narebski wrote:
Giovanni Bajo <[EMAIL PROTECTED]> writes:
On 12/7/2007 6:23 PM, Linus Torvalds wrote:
Is SHA a significant portion of the compute during these repacks?
I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. Bu
Snapshot gcc-4.3-20071207 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071207/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Boris Boesler <[EMAIL PROTECTED]> writes:
> Ok, so what have I to do to write a back-end where all addresses
> are given in bits?
That's kind of an extreme case. But it sounds like you are following
the right approach.
> Without these changes the compiler stops with internal error
> mesages
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> On 12/7/2007 6:23 PM, Linus Torvalds wrote:
>
> >> Is SHA a significant portion of the compute during these repacks?
> >> I should run oprofile...
> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > we have a good optimized vers
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
| > But random suggestions based on something you read in school are useless
|
| You're wrong. My suggestions are not based from school and are not useless.
| My suggestions are based from university, books, papers and internet
What is the difference?
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there,
Do we? vfork should block the parent until the child calls execve or
exit.
Andreas
On 12/7/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Attached is the patch that allows to save dependence info obtained on tree
> level by data-reference analysis for usage on RTL level (for RTL memory
> disambiguation and dependence graph construction for modulo scheduling).
> It hel
On 12/7/2007 6:23 PM, Linus Torvalds wrote:
Is SHA a significant portion of the compute during these repacks?
I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. But we
have a good optimized version there.
zlib tends to be a lot more noticeable (especia
Boris Boesler writes:
> Ok, so what have I to do to write a back-end where all addresses are
> given in bits? Memory is addressed in bits, not bytes. So I set:
>
> #define BITS_PER_UNIT 1
> #define UNITS_PER_WORD 32
I don't know if it's useful to define the size of a byte to be less than
8-bits, e
Dave Korn writes:
> Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there, and I don't know how to do a critical section using
> pthreads/posix.
A simple solution would be to call for
On Fri, 7 Dec 2007, Jon Smirl wrote:
> On 12/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Thu, 6 Dec 2007, Jon Smirl wrote:
> > > >
> > > > time git blame -C gcc/regclass.c > /dev/null
> > >
> > > [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
Am 05.12.2007 um 22:32 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I assume that GCC internals assume that memory can be byte (8 bits)
addressed - for historical reasons.
No. gcc internals assume that memory can be addressed in units of
size BITS_PER_UNIT. The de
On 2007/12/7, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 07 December 2007 18:09, J.C. Pizarro wrote:
>
> > You're wrong. My suggestions are not based from school and are not useless.
>
> Now /you're/ wrong: your suggestions *are* useless. You suggested using
> inter-process communications to try
"Dave Korn" <[EMAIL PROTECTED]> writes:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems. The code should be changed to call
> > execve instead. Unfortunately there is no standard execvpe function.
> > Fortunately gcc never uses the variant
On 12/7/07 1:09 PM, J.C. Pizarro wrote:
Do you permit me a question for you?
"Are important the suggestions?"
J.C.Pizarro
JC,
The problem that many of us have with your responses is that they are
almost always content-free. You do not seem to grasp the basic
principles of the issue
On 07 December 2007 18:09, J.C. Pizarro wrote:
> You're wrong. My suggestions are not based from school and are not useless.
Now /you're/ wrong: your suggestions *are* useless. You suggested using
inter-process communications to try and resolve a potential data-access race
condition between mu
J.C. Pizarro writes:
> You're wrong. My suggestions are not based from school and are not useless.
> My suggestions are based from university, books, papers and internet, and
> i did put those by a same reason, my freedom.
You have the freedom to make useless postings to this list, just as we
2007/12/7, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
> > On 07 December 2007 17:24, J.C. Pizarro wrote:
> >
> > > You can do a critical section mainly between processes
> >
> > Thanks for your well-meaning attempt to help, but you don't under
On Dec 7, 2007 8:28 AM, Emmanuel Fleury <[EMAIL PROTECTED]> wrote:
> Is anyone planning to go at CC'08 or COCV'08 ?
I was planning, but my paper at ESOP'08 was rejected, so I won't go there ;-)
Sebastian
On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
> On 07 December 2007 17:24, J.C. Pizarro wrote:
>
> > You can do a critical section mainly between processes
>
> Thanks for your well-meaning attempt to help, but you don't understand what
> we're talking about, and sending a generic
On 07 December 2007 17:24, J.C. Pizarro wrote:
> You can do a critical section mainly between processes
Thanks for your well-meaning attempt to help, but you don't understand what
we're talking about, and sending a generic list of synchronisation techniques
without regard to their relevance or
On 2007/12/07, "Dave Korn" <[EMAIL PROTECTED]> wrote:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems. The code should be changed to call
> > execve instead. Unfortunately there is no standard execvpe function.
> > Fortunately gcc never use
On Fri, 7 Dec 2007, David Miller wrote:
>
> Also I could end up being performance limited by SHA, it's not very
> well tuned on Sparc. It's been on my TODO list to code up the crypto
> unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> the userland interfaces to take advan
On 07 December 2007 16:59, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Note the several calls to dup2() and close(), which seem to me to be
>> "calls [to] any other function", and the setting of environ, which seem to
>> me to be modification of "any data other than a
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Note the several calls to dup2() and close(), which seem to me to be "calls
> [to] any other function", and the setting of environ, which seem to me to be
> modification of "any data other than a variable of type pid_t used to store
> the return value fr
Here is a minute tidbit.
When I click on the Modula-3 link:
http://www.m3.org/
it rolls over to:
http://www.igencorp.com/igencorp/
Ii looks like they moved to:
http://www.modula3.org/
Ed Smith-Rowland
On Dec 7, 2007 3:42 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> A powerful tool can do better things that old generators-based tools
> (as autotools).
>
--- cut ---
>
> * Later: (with the powerful tool that had cached many predefined variables in
Insisting on highlighting your proposal as "po
Hey all,
This is what posix says about vfork:
http://www.opengroup.org/onlinepubs/95399/functions/vfork.html
"The vfork() function shall be equivalent to fork(), except that the behavior
is undefined if the process created by vfork() either modifies any data other
than a variable of ty
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Harvey Harrison wrote:
> >
> > I've updated the public mirror repo with the very-packed version.
>
> Side note: it might be interesting to compare timings for
> history-intensive stuff with and without this kind of very
On Thu, 6 Dec 2007, Harvey Harrison wrote:
>
> I've updated the public mirror repo with the very-packed version.
Side note: it might be interesting to compare timings for
history-intensive stuff with and without this kind of very-packed
situation.
The very density of a smaller pack-file migh
On 2007/12/7, Jakub Narebski <[EMAIL PROTECTED]> wrote:
> Andreas Ericsson wrote:
> > Jakub Narebski wrote:
> > >
> > > Although there was some talk about whether giw should use autotools,
> > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > > instead of its own handmade Ma
Hi all,
Is anyone planning to go at CC'08 or COCV'08 ?
http://www.sable.mcgill.ca/~hendren/CC2008/
http://www.complang.tuwien.ac.at/cocv2008/cocv2008.html
The're held within the ETAPS'08 joint conferences:
http://etaps08.mit.bme.hu/
Regards
--
Emmanuel Fleury
Associate Professor, | Ro
Andreas Ericsson wrote:
> Jakub Narebski wrote:
> >
> > Although there was some talk about whether giw should use autotools,
> > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > instead of its own handmade Makefile...
> >
>
> To tell the truth, I'd be much happier if every
From: "Jon Smirl" <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 02:10:49 -0500
> On 12/7/07, Jeff King <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> >
> > # and test multithreaded large depth/window repacking
> > cd test
> > git config pack.threads 4
>
Jakub Narebski wrote:
Although there was some talk about whether giw should use autotools,
or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
instead of its own handmade Makefile...
To tell the truth, I'd be much happier if everything like that got
put in a header file or som
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> The autotools ( automake + libtool + autoconf + ... ) generate many big
> files that they have been slowing the building's computation and growing
> enormously their cvs/svn/git/hg repositories because of generated files.
[cut]
And this is relevant for
45 matches
Mail list logo
