ments in c++ code generation were as a result of
tree-ssa,
you only get with 4.x.
I wouldn't recommend it. One has to adapt gradually to the patience
required to
use the later compiler editions.
➧ Marcin Dalecki ❖
ehind a familar
sounding version
number.
∎ Marcin Dalecki ∎
Wiadomość napisana w dniu 2007-01-31, o godz12:50, przez Andrew Haley:
Benjamin Kosnik writes:
I am somewhat concerned with the response of the java maintainers
(and others) that it's OK to require >512MB to bootstrap gcc with
java, or that make times "WORKSFORME."
Well, I didn't say that,
Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump:
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
One thing that would certainly help as a foundation for possible
further improvement in performance in this area would be to have
xgcc contain all the front ends directly
Wiadomość napisana w dniu 2007-01-24, o godz23:26, przez Andrew
Pinski:
On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki
<[EMAIL PROTECTED]> said:
That's largely because individual tests in the test suite are too
long, which in turn is because the tests are testing co
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump:
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and
you think the infrastructure around it isn't crap on the order of
100?
Standard answer, tri
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump:
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and
you think the infrastructure around it isn't crap on the order of
100?
Standard answer, tri
http:///tx.technion.ac.il/~mveksler
∎ Marcin Dalecki ∎
la, that
actually pertains to a request for a #pragma STDC_C99 implementation.
That was a code path example. I'm not going to start about the data.
The polymorphism by preprocessor macro/GTY fun of some(all?) crucial
data types
makes me think that the whole MFC stuff looks sleek and elegant...
∎ Marcin Dalecki ∎
Wiadomość napisana w dniu 2007-01-24, o godz04:32, przez Andrew Pinski:
It's "too good" to be usable. The time required for a full test suite
run can be measured by days not hours.
Days, only for slow machines. For our PS3 toolchain (which is really
two sperate compilers), it takes 6 hours
Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
For 4, you should probably spend some time figuring out why bugs are
being introduced into the code in the first place. Is test coverage
not good enough?
It's "too good" to be usable. The time required for a full test su
Wiadomość napisana w dniu 2007-01-24, o godz01:48, przez David Daney:
I missed the discussion on IRC, but neither of those front-ends are
release blockers.
I cannot speak for ADA, but I am not aware that the Java front-end
has caused any release delays recently. I am sure you will correct
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already
crossed the 1 year barrier.
For 4.3 we have already added quite a bit of infrastructure
e:
$ flex --version
flex version 2.5.4
$ uname -a
Darwin xxx 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT
2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc
∎ Marcin Dalecki ∎
ectly instead.
(My final goal is of course something in the way of #pragma STDC
CX_LIMITED_RANGE)...
Marcin Dalecki
take
not look a bit more like in the multiplication case?
Marcin Dalecki
On 2006-12-21, at 23:42, Robert Dewar wrote:
Marcin Dalecki wrote:
Of course I didn't think about a substitute for ==. Not! However I
think
that checks for |x-y| < epsilion, could be really given a
significant speed edge
if done in a single go in hardware.
One thing to ponder
On 2006-12-21, at 23:17, Robert Dewar wrote:
> Marcin Dalecki:
Well actually it wouldn't "save the world". However adding an
op-code implementing: x eqeps y <=> |x - y| < epsilion, would be
indeed helpful.
Maybe some m-f has already patented it, and that'
dered silly?
No that's not sufficient. And a few bit's of precision are really not
the
center-point of numerical stability of the overall calculation.
Please look up
as an example a numerical phenomenon which is usually called
"cancelation" to see
immediately why.
Marcin Dalecki
7;t think in terms of infinite arithmetics
when programming.
And I hold up that the difference between finite and infinite is
actually quite a fundamental
concept. However quite a lot of people expect the floating
arithmetics rouding to give them
well behaved results.
Marcin Dalecki
using natural
numbers, which don't include negatives,
with integers. However it's a quite common mistake to forget how
"bad" floats "model" real numbers.
This corroborates the validity of the analogy with IEEE real
arithmetic.
And wrong assumptions lead to wrong conclusions.
Marcin Dalecki
float isn't! Thus this argument by analogy simply isn't valid.
Marcin Dalecki
STAGE0_CFLAGS instead
of BOOT_CFLAGS,
because the stages are actually enumerated in a sequence anyway.
Marcin Dalecki
rary files for communication.
And 80% of it comes from the severe overuse of the notion of shared
libraries on linux systems.
Marcin Dalecki
tsn't true. The compiler would be fine having many
threads handling a
lot of data between them in a pipelined way. In fact it already does
just that,
however without using the opportunity for paralell execution.
Marcin Dalecki
x27;d need even more hunks.
Or, so that is just an off the cuff proposal to get the discussion
started.
Thoughts?
Will use C++ help or hurt compiler parallelism? Does it really matter?
It should be helpfull, because it seriously helps in keeping the
semantical scope
of data items at bay.
Marcin Dalecki
On 2006-10-31, at 01:59, Daniel Berlin wrote:
On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
On 2006-10-30, at 21:37, Daniel Berlin wrote:
> Honestly, I don't know any mac people who *don't* use either
fink or
> macports to install unix software when possible,
On 2006-10-30, at 21:37, Daniel Berlin wrote:
Honestly, I don't know any mac people who *don't* use either fink or
macports to install unix software when possible, because pretty much
everything has required some small patch or another.
I guess you are joking?
Marcin Dalecki
On 2006-10-18, at 12:15, Steven Bosscher wrote:
On 10/18/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
Looking at rs6000.opt I have found that the above command line switch
variable is defined TWICE:
msched-prolog
Target Report Var(TARGET_SCHED_PROLOG) Init(1)
Schedule the start and
course to be wrong.
Marcin Dalecki
Looking at the function expand_omp_parallel in omp-low.c I have found
the following line of code:
bsi_insert_after (&si, t, TSI_SAME_STMT);
Shouldn't this bee
bsi_insert_after (&si, t, BSI_SAME_STMT);
instead?
Marcin Dalecki
On 2006-02-22, at 05:41, Ian Lance Taylor wrote:
Marcin Dalecki <[EMAIL PROTECTED]> writes:
Looking at the regor.c code I came across the function
try_merge_delay_insns().
There around the line 1488 we will find the following code:
merged_insns = gen_rtx_INSN_LIST (
therefore that the value REG_DEP_TRUE should be assed as
first argument
to gen_rtx_INSN_LIST there. I think only the fact that the code in
question
isn't likely to trigger didn't make this occur immediately as a bug.
Is this analysis correct?
Marcin Dalecki
On 2006-02-18, at 15:23, Joern Rennecke wrote:
In http://gcc.gnu.org/ml/gcc/2006-02/msg00357.html, you wrote:
In fact the "gamer" benchmarks you are dissing are quite well
reflecting the
very kind
of coding excessively found in GCC itself. Some observations suggest
the you should aim at th
On 2006-02-17, at 23:43, Joern RENNECKE wrote:
Has anybody done timings for gcc bootstrap / cross builds and
regtests with modern multi-core processors? I wonder what a
sensible modern configuration would be for gcc development, but the
the multimedia and games benchmarks I found on the w
I think is should read as NE_EXPR insead...
tree dummy_cond = build2 (NE_EXPR, boolean_type_node,
integer_zero_node, integer_zero_node);
Marcin Dalecki
The following removal of global default_conversion inside the C++
frontend:
2006-01-25 Volker Reichelt <[EMAIL PROTECTED]>
(default_conversion): Likewise.
Is junk due to the fact that it gets used for example in rs6000/rs6000.c
The results in *actual* build failure on Darwin/PowerPC
The following:
2006-01-23 Volker Reichelt <[EMAIL PROTECTED]>
* cp-tree.h (do_poplevel): Remove prototype.
* semantics.c (do_poplevel): Add prototype. Make static.
Is a plain mistake due to:
../.././gcc/objcp/objcp-decl.c: In function 'tree_node*
objcp_end_compound_stmt(t
On 2006-01-23, at 21:36, Zack Weinberg wrote:
Also, if you have access to valgrind (I can't remember if it works
on x86-64 yet?)
you could run both programs under it and report what it says, since
this seems
to be a bad-memory-access issue.
Inside genautomata.c there is a function gen_re
On 2006-01-22, at 17:08, Daniel Jacobowitz wrote:
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int
abing this option is going to crash the compiler miserable.
Looking at the use of flag_brnach_target_load_optmize2 I think all of
the
associated code should be simply deleted.
Marcin Dalecki
On 2006-01-22, at 04:35, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
On 2006-01-22, at 04:17, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
Looking at gcc/toplev.h and gcc/toplev.c I have found the following
two variants of the same
function once in the header and once in the definition fine.
extern inline int
floor_log2 (unsigned HOST_WIDE_INT x)
{
return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
}
and again the
On 2006-01-16, at 20:35, DJ Delorie wrote:
No it isn't. The results should still be the same.
You aren't considering call ABI or PIC issues. Natives might have
different call-saved registers, or global fixed register (like the TLS
pointers), that affect optimization in different ways than
On 2006-01-16, at 19:18, DJ Delorie wrote:
A cross compiler and a native compiler targeting the same CPU chip,
that's a different story.
No it isn't. The results should still be the same.
On 2006-01-16, at 18:38, Daniel Jacobowitz wrote:
As a heavy debugger of cross compilers I strongly disagree with this
sentiment. Host dependencies of any sort are a bug.
Amen to that. Independence from the host is paramount to
guarantee *reproducibility* of results over any on trivial time
More like "(cd gcc; make gnatlib_and_tools)", i.e. the current
directory
is the same.
That matters?
$(PWD)
On 2006-01-16, at 15:24, Richard Kenner wrote:
The point of --disable-bootstrap is to disable bootstrapping.
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
The most important of these is libgcc and the crt startup
files, which
On 2006-01-16, at 14:37, Richard Kenner wrote:
So the stage1 compiler is built as a 32-bit object, from the
second
stage on they're built as 64-bit objects.
Very bad idea! I don't think we should support that.
Yeep. That's not a bootstrap. It's cross compilation.
Except that host tools (fastjar mostly) are made with the *new* GCC
rather than the old one.
And the reason is what? I don't see even any theoretical merit in the
whole staging thing:
1. Bugs can theoretically cancel them self out.
2. The compiler isn't stressing himself more then the targ
On 2006-01-13, at 23:59, Richard Kenner wrote:
Remind me why it's a good idea to force me to mess with
bootstrapping
at all, when all I want is to build a copy of the compiler that
I can
use for debugging problems?
Well install.texi explains in full lenght the wonders of the b
FWIW I personally think this toplevel bootstrap thing is a step
backward, now
typing "make" triggers such a complex machinery that nobody seems
to able to
understand what it does.
Please forgive my ginorace but I didn't consider the autoconf/
automake/gnumake mechanism
to be entierly trasp
I just took a closer look at this host OS configuration macro
variable and it's usage.
It turns out that the variable is only used in gcc/gcc.c under the guide
of the verbose flag to confuse the corresponding notice output with
what is actually used
by the compiler driver. The threading model
I have been looking closer at the following C front-end global
variables:
current_function_returns_value
current_function_returns_null
current_function_returns_abnormally
Which are declared in c-decl.c. They are basically used as a way to
communicate with c-typeck.c.
All have to be in
On 2005-10-20, at 16:57, Richard Kenner wrote:
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of
literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If no
On 2005-10-20, at 11:45, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
This is not the case. This is only due t
On 2005-10-13, at 03:26, Mike Stump wrote:
On Oct 12, 2005, at 5:55 PM, Marcin Dalecki wrote:
On 2005-10-12, at 04:42, Daniel Berlin wrote:
Checkouts will be about 30% slower with svn, just because it has to
write more data out to disk because of the working copy
Yes. Indeed. One
On 2005-10-12, at 04:42, Daniel Berlin wrote:
Checkouts will be about 30% slower with svn, just because it has to
write more data out to disk because of the working copy
Yes. Indeed. One suggestions comes immediately to my mind. Why don't
you provide some kind of COW (Copy on Write)? Or may
On 2005-10-03, at 06:05, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcin Dalecki wrote:
|
| On 2005-10-03, at 00:26, Andrew Pinski wrote:
|
|>
|> This perl script works just fine for me on powerpc-darwin7.9.0
I don't
|> see why are we pipi
On 2005-10-03, at 00:26, Andrew Pinski wrote:
This perl script works just fine for me on powerpc-darwin7.9.0 I
don't
see why are we piping the output to nm when it should be piping nm's
output to c++filt.
Also this perl script works fine on powerpc-darwin7.4.0 also.
Turns out it was rpm
On 2005-10-03, at 00:49, Shantonu Sen wrote:
You're making a lot of terrible assumptions and drawing several
incorrect conclusions. xnu-792 is not the same as "darwin7.9.2",
and no configure script in the last 6 years should be detecting a
Mac OS X system as "ppc-apple-darwin" (it should b
On 2005-10-03, at 00:42, Marcin Dalecki wrote:
I'm not quite sure if this is correct since guessing the GCC
version interpretation here I would expect this to came out as:
ppc-apple-darwin7.9.2
aka: Tiger darwin 10.4.2
Trying to find out where the actual name mangling occured I
On 2005-10-03, at 00:26, Andrew Pinski wrote:
6) Is this whining reporting significant information, for the
person that wants to fix the bug?
Well on the system in question ppc-apple-darwin-7.8.0 the perl script
in question simply doesn't work. Since there doesn't appear to be
much in the wa
On 2005-10-02, at 23:45, Paolo Bonzini wrote:
2) Why do you think that symbol versioning is exclusive to glibc?
I don't. I look at the the results of it.
3) You can of course think that glibc is evil, but how is it related?
Oh no... I got just immersed by the GLIBCXX prefixing over there
During a build attempt of gcc-20051001 and more secnt on darwin 10.8
I have discovered that apparently for some unknown reason
make_exports.pl get's called during th libstdc++ build and fails
miserably:
> libstdc++-symbol.explist || (rm -f libstdc++-symbol.explist ;
exit 1)
nm -P .libs/b
On 2005-08-25, at 13:57, Paolo Bonzini wrote:
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that.
man xargs?
On 2005-08-10, at 19:05, Mark Mitchell wrote:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it
will just look where it would normally look, and all will be well.
install host != build host
Most of the time
On 2005-06-29, at 03:21, Diego Novillo wrote:
On Wed, Jun 29, 2005 at 03:13:45AM +0200, Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| You did not read anything even vaguely saying that in what
I wrote.
and you, did you?
Folks, can you take this offline? It's
On 2005-06-19, at 17:59, Vincent Lefevre wrote:
On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
Also I think GCC is not the one who is defining it either. It is
glibc who is defining that so complain to them instead.
Thanks for the information (I'm a bit surprised because these are gcc
On 2005-06-15, at 13:50, Scott Robert Ladd wrote:
Perhaps my understanding of math isn't as elite as yours, but I do
know
that "worser" isn't a word. ;)
Please bear with me. English is my 3th foreign language.
Only the following options would make sense:
1. An option to declare 100% IEEE
On 2005-06-15, at 06:19, R Hill wrote:
Marcin Dalecki wrote:
[snip]
If you don't have anything constructive to contribute to the
discussion then feel free to not participate. If you have
objections then voice them appropriately or risk them being
dismissed as bullshit ba
On 2005-06-14, at 19:29, Russell Shaw wrote:
The original bug was about testing the equality of doubles. I think
that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum
precision
specified in the compiler
On 2005-06-14, at 16:32, Scott Robert Ladd wrote:
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more
formal.
-ffp-correct
Please define corre
On 2005-06-09, at 00:57, Daniel Kegel wrote:
Can somebody suggest a place to start looking for
why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
exceptions from apps built by fc3's gcc-3.4?
The C++ program
#include
void foo() throw (int) {
std::cout << "In foo()" << std::endl;
On 2005-05-31, at 19:14, Dave Korn wrote:
Speak up now, or we're going to send the firing squad.
Just don't let them use x87 intrinsics to calculate the line of
fire, or
we'd all better run!
Some remarkable time ago I was exposed to a 12 bit "RISC" CPU with
two banks
of 4k ferrite
On 2005-05-27, at 15:36, Olivier Galibert wrote:
Floating point values represent intervals,
This is mathematically wrong. The basic concept is that the
calculations domain as given by floating point numbers is used
to *model* the real number calculus. Certain constrains apply of course.
But th
On 2005-05-26, at 22:39, Gabriel Dos Reis wrote:
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote:
| > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
| >
| >>static const double range = PI; // * 2.0;
| >>static const double incr = PI / 100.0;
On 2005-05-27, at 00:00, Gabriel Dos Reis wrote:
Yeah, the problem with people who work only with angles is that they
tend to forget that sin (and friends) are defined as functions on
*numbers*,
The problem with people who work only with angles is that they are
without sin.
On 2005-05-26, at 21:34, Scott Robert Ladd wrote:
For many practical problems, the world can be considered flat. And
I do
plenty of spherical geometry (GPS navigation) without requiring the
sin
of 2**90. ;)
Yes right. I guess your second name is ignorance.
On 2005-05-25, at 08:06, Christoph Hellwig wrote:
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
I'm not sure what the above may imply for your ongoing
discussion, tough...
Well, if I were running the show, the 'clock' would only start
running
when it was consensus amo
On 2005-05-24, at 18:06, Diego Novillo wrote:
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.) are willing to help quickly reviewing patches we can
have this done for this week (assuming mainlin
On 2005-05-24, at 06:00, Andrew Pinski wrote:
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND MAK
On 2005-05-24, at 09:09, Zack Weinberg wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
On 2005-05-23, at 08:15, Gabriel Dos Reis wrote:
Sixth, there is a real "mess" about name spaces. It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions. However, all the C coding standards
I've read so far usually suggest
t
On 2005-05-16, at 22:03, Mark Mitchell wrote:
Georg Bauhaus wrote:
On Mac OX X 10.2, the results are slightly discomforting,
even though I do get a compiler with
--enable-languages=c,ada,f77,c++,objc.
gcc summary has
# of unexpected failures1080
First, I would suggest disabling Ada, in ord
On 2005-05-19, at 15:18, Mike Hearn wrote:
On Wed, 18 May 2005 17:26:30 +0200, Marcin Dalecki wrote:
Like building on the system you are targeting?
Like cross building for the target system?
No, like messing around with headers and linkers and compilers, so
if you
are targetting Linux/x86 your
On 2005-05-18, at 14:36, Mike Hearn wrote:
On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
If I build main with C1, and libf.so with C2, and execute the
program so
that it uses C2's libgcc_s.so.1, it works.
Out of interest, what happens if you build main with C2 and libf
with C1?
T
On 2005-05-17, at 11:29, Richard Earnshaw wrote:
On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
No, I just don't build gfortran as a cross. There are many reasons
why this is a bad idea anyway.
Such as?
The dependence on external packages which don't cross compile well
for example.
On 2005-05-17, at 11:14, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
On Tuesday 17 May 2005 03:16, Joe Buck wrote:
How is it helpful to not follow the rules when posting patches
Quite simple:
* I wasn't aware about this fortran specific patch posting policy. I
ne
On 2005-05-06, at 18:14, Andrew Haley wrote:
Rutger Ovidius writes:
Friday, May 6, 2005, 8:06:49 AM, you wrote:
AH> But Java isn't compatible with static linking. Java is, by
its very
AH> nature, a dynamic language, where classes invoke and even
generate
AH> other classes on the fly. There is
On 2005-05-06, at 04:04, Sam Lauber wrote:
There are a few diffciulties here, particularly with addressing the
open stack in an efficient way.
This problem is probably going to get a little off-topic for this
group, and it may be better to discuss this on comp.lang.forth.
I wasn't asking about the
On 2005-04-28, at 16:26, Lars Segerlund wrote:
I have never done any 'memory profiling' but I think it might be time
to give it a
shot, does anybody have any hints on how to go about something like
this ?
The main performance problem for GCC as I see it is structural. GCC is
emulating
the conc
On 2005-04-28, at 12:03, Dave Korn wrote:
Original Message
From: Marcin Dalecki
Sent: 28 April 2005 02:58
On 2005-04-27, at 22:54, Karel Gardas wrote:
Total Physical Source Lines of Code (SLOC)= 2,456,727
Development Effort Estimate, Person-Years (Person-Months) = 725.95
On 2005-04-22, at 16:30, Lars Sonchocky-Helldorf wrote:
James E Wilson <[EMAIL PROTECTED]> wrote:
Andrew Pinski wrote:
Does anyone read the installation instructions?
Yes, but not everyone. And even people that read the docs can miss
the info if they can't figure out which part of the docs they a
On 2005-04-27, at 22:54, Karel Gardas wrote:
Total Physical Source Lines of Code (SLOC)= 2,456,727
Development Effort Estimate, Person-Years (Person-Months) = 725.95
(8,711.36)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)
On 2005-04-28, at 01:35, Joe Buck wrote:
I will agree with you on this point, but more than half of the time
to bootstrap consists of the time to build the Java library, and
speeding
that up is a losing battle, as Sun keeps adding new stuff that
libgjc/classpath is then expected to clone, and the
On 2005-04-28, at 03:06, Peter Barada wrote:
Well, yes. 1 second/file is still slow! I want "make" to complete
instantaneously! Don't you?
Actually I want it to complete before I even start, but I don't want
to get too greedy. :)
What's really sad is that for cross-compilation of the toolchain,
1 - 100 of 151 matches
Mail list logo
