I think that a VM such as this should also be able to implement some basic
atomic operations such as atomic add and/or compare and swap.
On 11/22/05, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Piotr Wyderski wrote:
> > I am working on a portable low-level library of atomic operations,
>
> Like the existing libatomic-ops package?
>
> > Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
> > Is this a GCC bug? I've f
On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
>
> In principle the combiner could make sure that the same number and
> type of volatile memory references occur both before and after the
> combination, and reject it if not.
It would also have to ensure that the volatile memory operation wa
Hi All,
I'm pretty new in porting and understunding GCC. I am trying to port gcc
4.02 to the DLX procesor by using dlx port for gcc 2.7.3.
Now I have the following problem:
. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-DL_muldi3 -c ../../gcc/libgcc2.c -o
Giovanni Bajo wrote:
> Manu Abraham wrote:
>
>> When one does a
>>
>> typedef uint8_t array[10];
>>
>> what does really happen ?
>
> This question does not concern the development of the GCC compiler in any
> way
??? Unless, surely, the answer wanted was something along the lines of:
`Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I checked, that the 32-bit libraries were built. That's ok!
cd
/disk1/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/gcc-4.1-20051112/gcc-4.1-20051112/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
ls -l lib* gives:
- -rw-r--r-- 1 em tecosim 7
Hi!
I just did a bootstrap build of gcc 4.0.2 on an Intel P4 and here is
the feedback according to http://gcc.gnu.org/install/finalinstall.html :
compile/gcc-4.0.2> ./config.guess
i686-pc-linux-gnu
compile/gcc4> /opt/gcc4/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured wit
Dear GCC help pages maintainers,
I recently encountered a statement like this one
__attribute__((__mode__(__DI__)))
in a micro kernel source file.
As I'm not so skilled with this kind of C/C++ syntax I tried to read the
manual about the keywords involved in that expression. Despite I found
in
Hello!
I built an environment for my 68020 board using gcc-4.0.2 and
newlib-1.13.0. Everything seems good, but the exception handling is not
working.
If I throw anything, the program exits.
Do I need to call any initializer functions to make it work?
Can anybody explain me how the catchpoint is fo
Richard Earnshaw wrote:
> On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
>
>>
>> In principle the combiner could make sure that the same number and
>> type of volatile memory references occur both before and after the
>> combination, and reject it if not.
>
> It would also have to ensure t
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| I installed the two patches below, in lign with your status report
| and plans for 3.4.5 and 3.4.6.
Thanks.
-- Gaby
On Tue, 2005-11-22 at 15:33, Dave Korn wrote:
> Richard Earnshaw wrote:
> > On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
> >
> >>
> >> In principle the combiner could make sure that the same number and
> >> type of volatile memory references occur both before and after the
> >> combinatio
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Fri, 28 Oct 2005, Daniel Berlin wrote:
|
| > contrib/ scripts have been updated in the new repository
|
| I've merged the gcc_update change to 4.0 branch, 3.4 branch and
Did you mean that gcc_release on those branches is now using SVN?
That do
Ok, here is my script (note I am in a directory with only the
script below when I execute the script below):
CC=cc /export/home/src/net/gnu/gcc-4.0.2/configure
gmake bootstrap>make_err 2>&1
I get the exact same errors (at least as far as I see).
Also, I had actually looked at the two links belo
On Tue, 2005-11-22 at 16:51 +0100, Gabriel Dos Reis wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
> | On Fri, 28 Oct 2005, Daniel Berlin wrote:
> |
> | > contrib/ scripts have been updated in the new repository
> |
> | I've merged the gcc_update change to 4.0 branch, 3.4 branch and
>
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| There's a lot to be learned (for me at least) about using svk. At some
| point I will update the wiki with useful bits, but I don't have many
| just yet. For instance, two open questions while I was writing this:
|
| - how to make svk ref
Richard Earnshaw wrote:
AFAICT it is probably safe to do the combination provided (in addition
to the normal restrictions on combine) that:
I think this is a bad idea in practice, since volatile will be used
to describe memory mapped devices, and combining can completely
mess up the access. Ye
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Tue, 2005-11-22 at 16:51 +0100, Gabriel Dos Reis wrote:
| > "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| >
| > | On Fri, 28 Oct 2005, Daniel Berlin wrote:
| > |
| > | > contrib/ scripts have been updated in the new repository
| > |
| > | I've me
On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
> At the moment, my attempts to commit patches (based on SVK) have met
> failures and generated lot of frustration.
Sorry, I can't help you. Hopefully someone else can, or you should try
on the svk list.
>(2) Is it normal that
> AFAICT it is probably safe to do the combination provided (in addition
> to the normal restrictions on combine) that:
I think this is a bad idea in practice, since volatile will be used
to describe memory mapped devices, and combining can completely
mess up the access. Yes, i
First off, regardless of what direction we choose to go, I think we are in
a great position. Finally, GCC will have all the obvious and standard
technology that one reads in textbooks. Not long ago, GCC didn't even
build a flowgraph, and now here we are deciding what IPA technology we
want t
>Merging back to mirror source svn://gcc.gnu.org/svn/gcc.
You need to use svn+ssh:// . svn:// is anonymous readonly access.
Paul
On Tue, 2005-11-22 at 17:07 +0100, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | There's a lot to be learned (for me at least) about using svk. At some
> | point I will update the wiki with useful bits, but I don't have many
> | just yet. For instance,
On Tue, Nov 22, 2005 at 11:20:02AM -0500, Diego Novillo wrote:
> If we choose LLVM, I have more questions than ideas, take these thoughts as
> very preliminary based on incomplete information:
>
> The initial impression I get is that LLVM involves starting from scratch.
> I don't quite agree th
> The initial impression I get is that LLVM involves starting from scratch.
> I don't quite agree that this is necessary. One of the engineering
> challenges we need to tackle is the requirement of keeping a fully
> functional compiler *while* we improve its architecture.
I don't think that it inv
>
> GVM, TU combination and all the associated slimming down of our IR
> data
> structures will be quite a bit of work. This is also needed for
> other
> projects
>
I believe it is more work than porting improvements to LLVM and making
LLVM usable.
Significantly more work.
>
> We would keep
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees)
On Mon, Nov 21, 2005 at 08:34:40PM +0100, Gabriel Dos Reis wrote:
> The tarballs for GCC-3.4.5 pre-release are available at
>
>ftp://gcc.gnu.org:/pub/gcc/prerelease-3.4.5-20051121/
>
> Please download and test them.
Looks good on RHEL 3 (i686-pc-linux-gnu). Test results are at
http://gcc
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Tue, 2005-11-22 at 17:07 +0100, Gabriel Dos Reis wrote:
| > Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | There's a lot to be learned (for me at least) about using svk. At some
| > | point I will update the wiki with useful
On Tue, 2005-11-22 at 17:58 +0100, Steven Bosscher wrote:
> On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> > The initial impression I get is that LLVM involves starting from scratch.
>
> I thought it would basically "only" replace the GIMPLE parts of the
> compiler. That is,
>
> FE
> Ok, here is my script (note I am in a directory with only the
> script below when I execute the script below):
>
> CC=cc /export/home/src/net/gnu/gcc-4.0.2/configure
> gmake bootstrap>make_err 2>&1
>
> I get the exact same errors (at least as far as I see).
The target libiberty is not supposed t
On Tue, 22 Nov 2005, Gabriel Dos Reis wrote:
> | I've merged the gcc_update change to 4.0 branch, 3.4 branch and
>
> Did you mean that gcc_release on those branches is now using SVN?
> That does not seem to be the case.
It's gcc_update I merged, not gcc_release.
The main pre-SVN differences be
I put:
printenv CC
echo $CC
which cc
in the script and only got output for the which cmd as /opt/SUNWspro/bin/cc.
I even reran the script with CC not set, just to make sure. Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Botcazou
Sent: Tue
Daniel Berlin wrote:
2. It natively supports Alpha, Sparc, IA64, X86, and PowerPC. An
LLVM->RTL converter is not that hard, which simply removes the entire
argument anyway.
I see the phrase "doing X is not that hard" in response to many
questions about this proposal. Now, I'm arguing the diff
> First off, regardless of what direction we choose to go, I think we
> are in a great position. Finally, GCC will have all the obvious and
> standard technology that one reads in textbooks. Not long ago, GCC
> didn't even build a flowgraph, and now here we are deciding what IPA
> technology we
> I put:
>
> printenv CC
> echo $CC
> which cc
>
> in the script and only got output for the which cmd as
> /opt/SUNWspro/bin/cc. I even reran the script with CC not set, just to make
> sure. Thanks!
Hum... let's try the basic checks then:
- what is your configure shell?
- what is your version of
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
[...]
| I'd actually like to make this a requirement, regardless of the option
| chosen.
Amen.
-- Gaby
configure shell: /bin/sh
gnu make: GNU Make 3.80
Although I had #!/bin/sh at the beginning, it was taking my
SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
and I am rebuilding it right now. Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECT
Richard Kenner wrote:
The issue is that we currently don't combine if volatile is anywhere in
sight, whether or not we'd be affecting that access. Just because you have
something volatile on the LHS doesn't mean we can't combine into the RHS. A
good example are addressing modes: if we have a ME
On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> Benjamin Kosnik <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd actually like to make this a requirement, regardless of the option
> | chosen.
>
> Amen.
>
Uh, IPA of any sort is generally not about speed.
It's fine to say compile ti
On Tue, Nov 22, 2005 at 01:47:12PM -0500, Daniel Berlin wrote:
> Uh, IPA of any sort is generally not about speed.
Except that we're talking about replacing all the tree optimizations
all of the time with llvm, which affects -O1. Or at least I thought
that was the suggestion...
r~
On Tue, 2005-11-22 at 10:49 -0800, Richard Henderson wrote:
> On Tue, Nov 22, 2005 at 01:47:12PM -0500, Daniel Berlin wrote:
> > Uh, IPA of any sort is generally not about speed.
>
> Except that we're talking about replacing all the tree optimizations
> all of the time with llvm, which affects -O1
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
| > Benjamin Kosnik <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | I'd actually like to make this a requirement, regardless of the option
| > | chosen.
| >
| > Amen.
| >
|
| Uh, IPA of
Robert Dewar wrote:
> Richard Kenner wrote:
>
>> The issue is that we currently don't combine if volatile is anywhere in
>> sight, whether or not we'd be affecting that access. Just because you
>> have something volatile on the LHS doesn't mean we can't combine into
>> the RHS. A good example are
On Tue, 2005-11-22 at 19:57 +0100, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> | > Benjamin Kosnik <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> | > | I'd actually like to make this a requirement,
On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote:
> I thought it would basically "only" replace the GIMPLE parts of the
> compiler. That is,
>
> FE--> GENERIC --> LLVM--> RTL --> asm
> (trees) (trees)
This is certainly the only way to avoid lo
> Which is why i said "It's fine to say compile time performance of the
> middle end portions ew may replace should be same or better".
>
> And if you were to look right now, it's actually significantly better in
> some cases :(
Can you prove this assertion?
Here is some data:
http://people.red
Dave Korn wrote:
Robert Dewar wrote:
Isn't it pretty much implied by point 1, "Not more than one volatile memory
ref appears in the instructions being considered"?
No, that allows a volatile reference to be combined with something else.
I think this is a mistake, because people often th
> Okay, but you need to understand that reasonable bounds for compiling
> the entire program at once are usually 3x-7x more (and in the worst
> case, even wore) than doing it seperately.
>
> That is the case with completely state of the art algorithms,
> implementation techniques, etc.
>
> It's
On Thu, 2005-11-17 at 11:53 -0500, Andrew MacLeod wrote:
> I have been contemplating building a GCC register allocator from scratch
> for some time. To that end, I have put together a bit of a document
> given a high level overview of the various components I think would
> benefit GCC, and a rough
> I'd have actually guessed they could
> have something functional, if not 100% robust, in 6 months given
> 2 or 3 people on the project.
The question is the width of the gap between functional and
usable. A number of people on this thread have implied that GCC's data
structures will need
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
| > Okay, but you need to understand that reasonable bounds for compiling
| > the entire program at once are usually 3x-7x more (and in the worst
| > case, even wore) than doing it seperately.
| >
| > That is the case with completely state of the art al
Ok, just recompiled with the shell as /bin/ksh and CC not defined
and got the same errors as last time? Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas B. Jones
Sent: Tuesday, November 22, 2005 1:36 PM
To: gcc@gcc.gnu.org
Subject: RE: com
> Although I had #!/bin/sh at the beginning, it was taking my
> SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
> and I am rebuilding it right now. Thanks!
Could you post the config.log file of the target libiberty?
--
Eric Botcazou
It is 4325 lines, should I just email it to you instead
of the whole group? Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Botcazou
Sent: Tuesday, November 22, 2005 3:00 PM
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Subject: Re: compiling gcc
>
> > Which is why i said "It's fine to say compile time performance of the
> > middle end portions ew may replace should be same or better".
> >
> > And if you were to look right now, it's actually significantly better in
> > some cases :(
>
> Can you prove this assertion?
>
> Here is some dat
On Tue, 2005-11-22 at 13:21 -0600, Benjamin Kosnik wrote:
> > Okay, but you need to understand that reasonable bounds for compiling
> > the entire program at once are usually 3x-7x more (and in the worst
> > case, even wore) than doing it seperately.
> >
> > That is the case with completely state
On Tue, 2005-11-22 at 05:44, Rainer Emrich wrote:
> I compared this to an earlier build and I'm sure that the wrong library
> search path is used in this case. It should be:
> Any hints?
It is curious that it got the include options right (-D/-I) but not the
library options (-B/-L).
The option mu
> It is 4325 lines, should I just email it to you instead
> of the whole group?
Yes, compressed.
--
Eric Botcazou
Jan Hubicka wrote:
I should note that comparison to ICC is not quite fair since it lacks
Opteron tunning...
I think you may be comparing oranges to tangerines -- not as bad as
apples and oranges, but still potentially an invalid comparison.
In my experience the extra registers of the Opteron
On its' way. Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Botcazou
Sent: Tuesday, November 22, 2005 3:22 PM
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Subject: Re: compiling gcc-4.0.2 on solaris 9
> It is 4325 lines, should I just email i
On Tue, 2005-11-22 at 01:53, Richard Guenther wrote:
> Like f.i. as I proposed in
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html
> maybe you could comment on that approach. Sofar the feedback was negative,
> so I didn't yet work further on it.
I fell behind on gcc-patches reading a whi
Robert Dewar wrote:
> Dave Korn wrote:
>> Robert Dewar wrote:
>>
>
>> Isn't it pretty much implied by point 1, "Not more than one volatile
>> memory ref appears in the instructions being considered"?
>
> No, that allows a volatile reference to be combined with something else.
Ah, I misunder
> Jan Hubicka wrote:
> >I should note that comparison to ICC is not quite fair since it lacks
> >Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an invalid comparison.
>
> In my experience the extra registers
On Tuesday 22 November 2005 20:26, Peter Bergner wrote:
> Insn Annotations [page(s) 17-18]:
> * I like the idea of easy access to the register usage info
> provided by the insn annotations. RTL isn't really setup
> for making that easy.
But it is if you use df.c. Really, it is.
On Tuesday 22 November 2005 21:18, Scott Robert Ladd wrote:
> Jan Hubicka wrote:
> > I should note that comparison to ICC is not quite fair since it lacks
> > Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an in
On Tuesday 22 November 2005 19:17, Benjamin Kosnik wrote:
> What about compile-time performance?
>
> I'd actually like to make this a requirement, regardless of the option
> chosen.
Amen.
Maybe we should pick a baseline compiler, and require that all
compile time comparisons are made wrt. that ba
On Tuesday 22 November 2005 20:21, Benjamin Kosnik wrote:
> Tree-SSA managed to add new technology to the compiler without major
> slowdowns.
You must be looking at different timings than I do.
GCC 4.1 is on average almost 40% slower than GCC 3.3.
Gr.
Steven
On Tuesday 22 November 2005 20:06, Richard Henderson wrote:
> > The GVM plan could take years to get to that point...
>
> Could, but probably won't. I'd have actually guessed they could
> have something functional, if not 100% robust, in 6 months given
> 2 or 3 people on the project.
Yes. But wo
On Tue, 22 Nov 2005, Daniel Jacobowitz wrote:
The initial impression I get is that LLVM involves starting from scratch.
I don't quite agree that this is necessary. One of the engineering
challenges we need to tackle is the requirement of keeping a fully
functional compiler *while* we improve its
> > Tree-SSA managed to add new technology to the compiler without major
> > slowdowns.
>
> You must be looking at different timings than I do.
>
> GCC 4.1 is on average almost 40% slower than GCC 3.3.
That's not true for GCC 4.0.
--
Eric Botcazou
On Tue, 22 Nov 2005, Steven Bosscher wrote:
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM
Snapshot gcc-3.4-20051122 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051122/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
In http://gcc.gnu.org/onlinedocs/, the Current development / User-
Level Documentation link to GNAT User's Guide is broken.
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Another minor nit is performance. Judging by SPEC, LLVM has some
performance problems. It's very good for floating point (a 9%
advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in
integer code. I'm sure that is fixable and I only have da
On Tue, 22 Nov 2005, Richard Henderson wrote:
On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote:
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees) (trees)
This is certain
On Tuesday 22 November 2005 23:32, Eric Botcazou wrote:
> > > Tree-SSA managed to add new technology to the compiler without major
> > > slowdowns.
> >
> > You must be looking at different timings than I do.
> >
> > GCC 4.1 is on average almost 40% slower than GCC 3.3.
>
> That's not true for GCC 4
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Which is why i said "It's fine to say compile time performance of the
middle end portions ew may replace should be same or better".
And if you were to look right now, it's actually significantly better in
some cases :(
http://people.redhat.com/dnovill
On Tue, 2005-11-22 at 22:56 +0100, an unknown sender wrote:
> On Tuesday 22 November 2005 20:26, Peter Bergner wrote:
> > Insn Annotations [page(s) 17-18]:
> > * I like the idea of easy access to the register usage info
> > provided by the insn annotations. RTL isn't really setup
> >
On Tue, 22 Nov 2005, Simon Wright wrote:
> In http://gcc.gnu.org/onlinedocs/, the Current development / User-Level
> Documentation link to GNAT User's Guide is broken.
This is a known issue with the subversion conversion of update_web_docs.
I have given my conjectured cause as being that the SV
Hi,
What kind of things did you want to put in doc/c-tree.texi under the
section "Trees" when you wrote
@c-
@c Trees
@c-
@node Macros and Functions
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
This is a patch vs the Apple branch as of a few weeks ago. The diff is in
gcc.patch.txt, the new files are included in the tarball.
Note, there are not enough caveats in the world to include w
> True, but GCC 4.0 produces code that is hardly better than what
> GCC 3.3 makes of it, and 4.0 is still significantly slower.
Maybe compared to your "hammer" branch. On SPARC, FSF 3.4 is definitely
better than FSF 3.3 and 4.0 not worse than 3.4.
> Just not as much as GCC 4.1 (something like 1
Chris,
You will need to address two, potentially bigger, issues: license and
implementation language. You will need to get University of Illinois and
past/present LLVM developers to assign the copyright over to the FSF.
Yes, you've claimed it's easy, but it needs to be done. Otherwise, we a
> If you're seeing the difference between the tip of 4.0 and mainline,
> perhaps something is going wrong with the 4.0 configure check, such
> that this feature isn't being enabled?
My snapshot of branch-4.0 pre-dates the change you described.
> > Should I static link with a newer glibc (I'm assu
> Diego Novillo writes:
Diego> Over the last couple of years, there have been some half hearted
attempts
Diego> at suggesting C++ as a new implementation language for GCC. I would
Diego> personally love to see us move to C++, but so far that has not happened.
C++ is not an issue
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
>>(2) Is it normal that "svk push" takes more than 5 minutes to complete?
>>If so, that does not match the speed argument I've seen for the
>>move to SVN.
> SVN is
On Tue, Nov 22, 2005 at 06:42:11PM -0500, David Edelsohn wrote:
> > Diego Novillo writes:
>
> Diego> Over the last couple of years, there have been some half hearted
> attempts
> Diego> at suggesting C++ as a new implementation language for GCC. I would
> Diego> personally love to see us m
On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
> I will work with the GCC SC and FSF on that issue once the licensing
> issue is addressed and we know LLVM is a viable option.
>
What purpose would that serve? I'm not concerned about the SC, initially.
It's the development community at
Russ Allbery <[EMAIL PROTECTED]> writes:
| Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| > On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
|
| >>(2) Is it normal that "svk push" takes more than 5 minutes to complete?
| >>If so, that does not match the speed argumen
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
|
| > I will work with the GCC SC and FSF on that issue once the licensing
| > issue is addressed and we know LLVM is a viable option.
| >
| What purpose would that serve? I'm not concerned about
Diego Novillo wrote:
On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
I will work with the GCC SC and FSF on that issue once the licensing
issue is addressed and we know LLVM is a viable option.
What purpose would that serve? I'm not concerned about the SC, initially.
It's the deve
> > > Diego Novillo writes:
> Over the last couple of years, there have been some half hearted attempts
> at suggesting C++ as a new implementation language for GCC. I would
> personally love to see us move to C++, but so far that has not happened.
On Tue, Nov 22, 2005 at 06:42:11PM -0
Steven Bosscher wrote:
It obviously doesn't do that. ICC uses that larger register file, too,
for x86-64.
The Intel compiler can be set to compile for multiple processors,
keeping different versions of the same function in an executable and
picking which code to run based on the processor in u
On Tue, 23 Nov 2005, Gabriel Dos Reis wrote:
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
| > I will work with the GCC SC and FSF on that issue once the licensing
| > issue is addressed and we know LLVM is a viable option.
| >
| What purpose
On Tue, 22 Nov 2005, Diego Novillo wrote:
You will need to address two, potentially bigger, issues: license and
implementation language.
Over the last couple of years, there have been some half hearted attempts
at suggesting C++ as a new implementation language for GCC. I would
personally lov
Chris Lattner <[EMAIL PROTECTED]> writes:
| On Tue, 23 Nov 2005, Gabriel Dos Reis wrote:
| > Diego Novillo <[EMAIL PROTECTED]> writes:
| > | On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
| > | > I will work with the GCC SC and FSF on that issue once the licensing
| > | > issue is addres
I would like to discuss my plans for merging the dfp-branch, which is
nearing completion. I have been merging all of our infrastructure and
non-specific patches into the trunk for the last couple of days. I'm
at a stage where I can't do any more without introducing the DFP
changes.
I have been t
On Wed, 2005-11-23 at 00:58 +0100, Gabriel Dos Reis wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>
> | Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> | > On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
> |
> | >>(2) Is it normal that "svk push" takes more than 5 minute
Gabriel Dos Reis wrote:
> Hi,
>
> What kind of things did you want to put in doc/c-tree.texi under the
> section "Trees" when you wrote
>
> @c-
> @c Trees
> @c--
1 - 100 of 104 matches
Mail list logo
