I'd appreciate it if y'all would do the following sequence of commands
on your favorite machine:
srcdir=/path/to/gcc/source/tree/
$srcdir/configure
make all-libcpp configure-gcc
cd gcc
make config.h tm.h
time ../libcpp/makedepend -I. -I$srcdir/gcc -I$srcdir/libcpp/include \
-I$srcdir/include
the sqlite c api has the following function (and several like it):
int sqlite_exec_printf(sqlite*,
char *sql,
int (*)(void*,int,char**,char**),
void*,
char **errmsg,
and report (a) the numbers reported by the "time" command, (b) what
sort of machine this is and how old, and (c) whether or not you would
be willing to trade that much additional delay in an edit-compile-debug
cycle for not having to write dependencies manually anymore.
Linux P4 3.4 GHz: real0
real0m18.740s
user0m0.010s
sys 0m0.020s
i686-pc-mingw32
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
1.4GHz Pentium 4 768MB RAM
I have no preference regarding makedepend.
Aaron W. LaFramboise
Alan Modra wrote:
These are most likey 64-bit address constant loads. On ppc32, a 32-bit
address constant can be calculated in at most 2 instructions. A 64-bit
address takes up to 5 instructions to calculate in-line, or a TOC memory
load.
One general principle at work here is that there is no rul
On Mon, 7 Mar 2005, kevin lyda wrote:
>...) __attribute__((format(
> __printf_extend__("Q", char *, "q", char *),
> 2, 6)));
>
> is there any interest in this? if i was to come up with a patch that
> ac
Zack Weinberg wrote:
(a) the numbers reported by the "time" command,
real0m10.129s
user0m4.387s
sys 0m0.726s
(b) what sort of machine this is and how old, and
i686-pc-linux-gnu, P4 3GHz (about a year old).
(c) whether or not you would be willing to trade that much additional
delay in an
Zack Weinberg wrote:
>
> and report (a) the numbers reported by the "time" command,
real0m7.819s
user0m4.442s
sys 0m0.513s
> (b) what sort of machine this is and how old, and
x86_64-unknown-linux-gnu, AMD Athlon(tm) 64 Processor 3700+
> (c) whether or not you would be willing to
Hi everyone,
why the result is (0,0) instead of (1,0)?!? It seems to me that only the
latter is consistent with the C99 requirements for real power (F.9.4.4)
- that is 1.0 - and, on the other hand, according to G.6.4.1 and note
318, cpow behavior in "special cases" is rather implementation depen
Paolo Carlini wrote:
Hi everyone,
why the result is (0,0) instead of (1,0)?!?
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked by a
strange issue I'm seeing in the C++ library), even "worse", so to speak...
Paolo.
Paolo Carlini wrote:
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked by a
strange issue I'm seeing in the C++ library), even "worse", so to speak...
Paolo.
Well it certainly seems the right result in this case to me. Does the
standard really require the wrong result here?
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes:
Ranjit> After your patch for PR c++/19733, there have been tonnes
Ranjit> of warnings during a libjava build complaining about "class
Ranjit> Foo has virtual functions but non-virtual destructor".
Ranjit> Therefore, can you please supp
Robert Dewar writes:
> Paolo Carlini wrote:
>
> > Actually, sorry, __builtin_cpow returns (nan, nan) (got
> > sidetracked by a strange issue I'm seeing in the C++ library),
> > even "worse", so to speak...
>
> Well it certainly seems the right result in this case to me. Does
> the standar
Robert Dewar wrote:
Paolo Carlini wrote:
Actually, sorry, __builtin_cpow returns (nan, nan) (got sidetracked
by a strange issue I'm seeing in the C++ library), even "worse", so
to speak...
Paolo.
Well it certainly seems the right result in this case to me. Does the
standard really require the wr
Andrew Haley wrote:
F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
Indeed. My point, basically, is that consistency appear to require the
very same behavior for *complex* zero^zero.
Paolo.
(a) the numbers reported by the "time" command
real0m49.88s
user0m11.57s
sys 0m3.77s
(b) what sort of machine this is and how old
IBM pseries POWER4 1.1GHz, AIX 5.2.0.0
David
Paolo Carlini wrote:
Andrew Haley wrote:
F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
Indeed. My point, basically, is that consistency appear to require the
very same behavior for *complex* zero^zero.
I am not sure, it looks like the standard is deliberately vague here,
and is not
Hi Alex and Mark,
On 7 Mar 2005, mark at codesourcery dot com wrote:
> Yes, I understand. You still need to take it up with Roger, though.
My apologies to both of you for being curiously/annoyingly silent on
this is issue. I've been getting up to speed on the internals of the
C++ parser, in or
On Mon, 07 Mar 2005 00:07:30 -0800, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> (a) the numbers reported by the "time" command,
real0m15.369s
user0m7.305s
sys 0m1.033s
(source over NFS)
> (b) what sort of machine this is and how old, and
4xItanium2 1.3GHz, Debian unstable. Two ye
On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote:
> Paolo Carlini wrote:
> > Andrew Haley wrote:
> >
> >> F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
> >>
> >>
> > Indeed. My point, basically, is that consistency appear to require the
> > very same behavior for *complex* zer
Roger Sayle wrote:
For example, I believe that Alex's proposed solution to PR c++/19199
isn't an appropriate fix. It's perfectly reasonable for fold to convert
a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
front-end all three of these tree nodes are valid lvalues. Hence it'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan Sands wrote:
| On Mon, 2005-03-07 at 10:51 -0500, Robert Dewar wrote:
|
|>Paolo Carlini wrote:
|>
|>>Andrew Haley wrote:
|>>
|>>
|>>>F9.4.4 requires pow (x, 0) to return 1 for any x, even NaN.
|>>>
|>>>
|>>
|>>Indeed. My point, basically, is that
[EMAIL PROTECTED]: 12.154user 1.073system 0m15.372selapsed 86.05%CPU
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely
Hi Chris,
> | Mathematically speaking zero^zero is undefined, so it should be NaN.
> | This already clear for real numbers: consider x^0 where x decreases
> | to zero. This is always 1, so you could deduce that 0^0 should be 1.
> | However, consider 0^x where x decreases to zero. This is always
Hello,
I have a question about the different behaviour of the Linux and Solaris
versions of gcc (3.4.x and 4.0.x) regarding static linking of libgcc. I do
the static linking by adding the libgcc.a library. The Linux versions link
libgcc statically, as do the Solaris versions. But then the Solaris
> I have a question about the different behaviour of the Linux and Solaris
> versions of gcc (3.4.x and 4.0.x) regarding static linking of libgcc. I do
> the static linking by adding the libgcc.a library.
Ideally you should not. Use -shared-libgcc or -static-libgcc instead.
> The Linux versions
On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> For example, I believe that Alex's proposed solution to PR c++/19199
> isn't an appropriate fix. It's perfectly reasonable for fold to convert
> a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> front-end all three of
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > For example, I believe that Alex's proposed solution to PR c++/19199
> > isn't an appropriate fix. It's perfectly reasonable for fold to convert
> > a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> > front-end
Maybe you can add gdc to your GCC front-ends listing
(http://home.earthlink.net/~dvdfrdmn/d/).
Okay - at the moment my entire system is compiled with 3.4 (latest on
gentoo's portage - 3.4.3.20050110) This included important libraries
such as glibc, and many other system libraries.
When gcc 4.0 is released on gentoo's portage (which should be very
shortly following the offical release on gc
Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> If the parser can't be used to provide useful context, we could
>> potentially postpone the calling of "fold" for C++ COND_EXPRs during
>> parsing, but call "fold" on COND_EXPRs while lowering to gimple, where
>> we'll always know whether we're expecting
Giovanni Bajo wrote:
But how are you proposing to handle the fact that the C++ FE needs to fold
constant expressions (in the ISO C++ sense of 'constant expressions)? For
instance, we need to fold "1+1" into "2" much before gimplification. Should
a part of fold() be extracted and duplicated in the C
On Mar 7, 2005, at 12:40, Giovanni Bajo wrote:\
But how are you proposing to handle the fact that the C++ FE needs to
fold
constant expressions (in the ISO C++ sense of 'constant expressions)?
For
instance, we need to fold "1+1" into "2" much before gimplification.
Should
a part of fold() be ext
It looks like the general consensus is that we should not use fold()
anymore in the frontends
I haven't seen that and certainly don't agree with it. The earlier we can
get rid of junk trees, the better. There is no point in having separate
code in a front end to fold "1+1" nor a point i
On Mon, Mar 07, 2005 at 12:07:30AM -0800, Zack Weinberg wrote:
> ... report (a) the numbers reported by the "time" command,
real1m25.959s
user0m6.070s
sys 0m2.820s
(b) what
> sort of machine this is and how old,
dual 2.175 GHz Xeon with 2GB memory, about three years old
> and (c)
Roger Sayle wrote:
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
I thought you were the person who introduced changes to fold that caused
it to generate these expressions when the GNU source extensio
On Mon, 7 Mar 2005, Richard Kenner wrote:
> What I thought we agreed on was *only* that if a language has rules about
> what *must* be a constant, we should not be depending on fold to be part
> of the enforcement for those rules.
A language has rules about what must be a constant. It has rules
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > I truly hope you're not trying to suggest that it was me that introduced
> > the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
>
> I thought you were the person who introduced changes to fold that caused
> it t
Roger Sayle wrote:
On Mon, 7 Mar 2005, Mark Mitchell wrote:
Roger Sayle wrote:
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
I thought you were the person who introduced changes to fold that caused
it
But folding during parsing and semantic analysis, beyond that required
by the language standard, is hobbled by such matters as needing to
preserve language-specific lvalue-nature - for example, needing to
keep a COND_EXPR in a form which the C++ front end understands as a
lvalue
> (a) the numbers reported by the "time" command,
> (b) what sort of machine this is and how old,
Thinkpad 600 (RHL 9 i386, PII 266MHz) 192Mb (7 yrs old)
real0m46.115s
user0m40.080s
sys 0m3.930s
Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
real0m4.344s
user0m3.875s
sys
DJ Delorie wrote:
> Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
Lucky guy! ;)
Paolo.
On Monday 07 March 2005 19:49, Mark Mitchell wrote:
> The way I think about this is that G++ has long supported the GNU
> min/max expression extension -- and it's long been broken. Over the
> years, I've fielded several bug reports about that extension, and we've
> gradually cleaned it up, but mos
Steven Bosscher wrote:
On Monday 07 March 2005 19:49, Mark Mitchell wrote:
The way I think about this is that G++ has long supported the GNU
min/max expression extension -- and it's long been broken. Over the
years, I've fielded several bug reports about that extension, and we've
gradually cleaned
> > Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
>
> Lucky guy! ;)
Oops, I mean 2GHz :-P
(I have another new machine that's a P4 3GHz)
Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> The way I think about this is that G++ has long supported the GNU
>> min/max expression extension -- and it's long been broken. Over the
>> years, I've fielded several bug reports about that extension, and we've
>> gradually cleaned it up, but mostly
On Mar 7, 2005, at 2:13 PM, Giovanni Bajo wrote:
Well, that sounds largely impossible. Can you point exactly which bug
are
you talking of? I know for a fact that the extension itself has always
worked for basic rvalue usage, with basic types. Instead, I would not
be
surprised if some more complex
On Mon, Mar 07, 2005 at 08:02:40PM +0100, Steven Bosscher wrote:
> [ min/max expr ]
> So, maybe the extension is not used very much. Perhaps it should be
> removed?
Then we'll just get RMS pissed off at the SC again; he hates it when we
remove his extensions. (We've sometimes done so anyway, but
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Monday 07 March 2005 19:49, Mark Mitchell wrote:
> >
> > > The way I think about this is that G++ has long supported the GNU
> > > min/max expression extension -- and it's long been broken. Over the
> > > years, I've fielde
Joseph S. Myers wrote:
I'd be happy to see it (deprecated and then) removed, but I think we'd need
buy-in from the C front end maintainers. As extensions go, it's actually not
that bad; the semantics are relatively well defined.
The min/max expression extension is C++ only, the C front end doesn'
DJ Delorie <[EMAIL PROTECTED]> writes:
>> and (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependencies manually anymore.
>
> Are there any compromise solutions?
Lots.
The program as it currently exists i
> probably the sanest thing is to go with the automake-like approach of
> one .d file per .c file, which then can be annotated without having to
> write logic to parse a big dependency file and update it in place.
The problem with .d files is that there's no good automatic way to
deal with header
DJ Delorie <[EMAIL PROTECTED]> writes:
>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
>
> The problem with .d files is that ther
> That script doesn't really parse the file at all, it just scans for
> #include lines, and it processes each header only once no matter how
> many files reference it. Which has got to be faster than what
> cpplib is doing.
Right, I figured you could run it once just to see how *much* faster
it
DJ Delorie <[EMAIL PROTECTED]> writes:
>> That script doesn't really parse the file at all, it just scans for
>> #include lines, and it processes each header only once no matter how
>> many files reference it. Which has got to be faster than what
>> cpplib is doing.
>
> Right, I figured you could
Zack Weinberg <[EMAIL PROTECTED]> writes:
> It is from 2x to 7x faster, depending on whether the filesystem cache
> is primed. There doesn't seem to be any way to get it to read
> multiple include directories, so the results are not entirely
> accurate, but that's a fixable problem.
^^ I meant to
As noted in PR 14316, collect2 doesn't build on Windows due to the use
of vfork. There have been at least two patches to address this, one
of them from me, one from Zack.
My patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01445.html
Zack had some comments:
http://gcc.gnu.org/m
On Mon, Mar 07, 2005 at 11:49:05AM -0800, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> >>I'd be happy to see it (deprecated and then) removed, but I think we'd
> >>need
> >>buy-in from the C front end maintainers. As extensions go, it's actually
> >>not
> >>that bad; the semantics are rela
Ian Lance Taylor wrote:
As noted in PR 14316, collect2 doesn't build on Windows due to the use
of vfork. There have been at least two patches to address this, one
of them from me, one from Zack.
My patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01445.html
Zack had some comments:
"E. Weddington" <[EMAIL PROTECTED]> writes:
> Thanks for taking a look at this again. A solution is badly needed.
> Would this be targeted for 4.0, perhaps?
No promises from me on that front. Let's get it into mainline first.
After it is working on mainline, it would be reasonable to propose
mo
> "DJ" == DJ Delorie <[EMAIL PROTECTED]> writes:
>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
DJ> The problem with .d fil
(a)
real0m5.171s
user0m4.346s
sys 0m0.518s
(b)
Athlon64 3000+ (2.0 GHz s754), 1GB RAM, 200 GB disk, SuSE Linux 9.2
8 month old. Today's Paris street price about 500 euros w/o taxes
(c)
automatic seems better
Laurent
On Mon, 2005-03-07 at 00:07 -0800, Zack Weinberg wrote:
> I'd appr
On 2005-03-07, at 17:09, Duncan Sands wrote:
Mathematically speaking zero^zero is undefined, so it should be NaN.
I don't see the implication here. Thus this certain is no
"mathematical" speak.
This already clear for real numbers: consider x^0 where x decreases
to zero. This is always 1, so you
On 2005-03-07, at 17:31, Duncan Sands wrote:
I would agree with Paolo that the most imporant point is arguably
consistency, and it looks like that is pow(0.0,0.0)=1
just so long as everyone understands that they are upholding the
standard, not mathematics, then that is fine by me :)
All the best,
D
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| Mathematically speaking zero^zero is undefined, so it should be NaN.
| This already clear for real numbers: consider x^0 where x decreases
| to zero. This is always 1, so you could deduce that 0^0 should be 1.
| However, consider 0^x where x decrea
Well, i'm studying mathematics and as i know so far 0^0 is always 1 (for
real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Duncan Sands wrote:
On Mon, 2005-03-07 at 10:51 -0500, Rob
Marcin Dalecki wrote:
There is no reason here and you presented no reasoning. But still there
is a
*convenient* extension of the definition domain for the power of
function for the
zero exponent.
The trouble is that there are *two* possible convenient extensions.
However, the one chosen by the C
Marcin Dalecki wrote:
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| Mathematically speaking zero^zero is undefined, so it should be NaN.
| This already clear for real numbers: consider x^0 where x decreases
| to zero. This is always 1, so you could deduce that 0^0 should be 1.
| However, consi
Robert Dewar wrote:
However, the one chosen by the C standard has indeed become pretty
prevalent (the Ada RM for instance specifies that 0**0 = 1 (applies
to complex case as well).
Interesting, thanks. The problem is, since the C standard is admittedly
rather vague in this area, some implementation
Paolo Carlini wrote:
Interesting, thanks. The problem is, since the C standard is admittedly
rather vague in this area, some implementation of the C library simply
implement the basic formula (i.e., cexp(c*clog(z))) and don't deal *at all*
with special cases. This leads *naturally* to (nan, nan).
I
On 2005-03-08, at 01:11, Robert Dewar wrote:
Marcin Dalecki wrote:
There is no reason here and you presented no reasoning. But still
there is a
*convenient* extension of the definition domain for the power of
function for the
zero exponent.
The trouble is that there are *two* possible convenient
On 2005-03-08, at 01:14, Robert Dewar wrote:
Marcin Dalecki wrote:
On 2005-03-07, at 17:16, Chris Jefferson wrote:
| This is why there is no reasonable
| mathematical value for 0^0.
|
That is true.
It's not true because it's neither true nor false. It's a not well
formulated statement. (Mathematica
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual continued
The complex case can be derived from this (0^(0+ib) = 0^0*0^ib = 1 =
0^a*0^(i*0) ).
Well, i kno
On 2005-03-08, at 01:21, Robert Dewar wrote:
Paolo Carlini wrote:
Interesting, thanks. The problem is, since the C standard is
admittedly
rather vague in this area, some implementation of the C library simply
implement the basic formula (i.e., cexp(c*clog(z))) and don't deal
*at all*
with special
On 2005-03-08, at 01:47, Ronny Peine wrote:
Hi again,
a small proof.
How cute.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual
continued
The complex case can be derived from thi
Hi,
Marcin Dalecki wrote:
On 2005-03-08, at 01:47, Ronny Peine wrote:
Hi again,
a small proof.
How cute.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
0^0 = lim A->0, A>0 (exp(0*ln(A)) = 1 if exp(X*ln(A)) is continual
continued
The complex c
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
> Hi again,
>
> a small proof.
>
> if A and X are real numbers and A>0 then
>
> A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
> 0^0 = lim A->0, A>0 (exp(0*ln(A))
Marcin Dalecki wrote:
It's not a matter of reason it's a matter of definition. Thus the
statement "This is why there is no reasonable mathematical value for 0^0
is neither true nor false", has the same sense as saying that... well
for example:
"rose bears fly very high". Just a random alliteration
Joe Buck wrote:
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
0^0 = lim A->0, A>0 (exp(0*ln(A)) =
Ronny Peine wrote:
I don't think it's hidden. The former definiton is absolutely right.
Yes, but the argument by limits is specious, and indeed as already
shown in this thread, can lead to one of two answers. Just because
a function approaches the value X at point Y does not mean it has
the value X
Ronny Peine wrote:
Joe Buck wrote:
On Tue, Mar 08, 2005 at 01:47:13AM +0100, Ronny Peine wrote:
Hi again,
a small proof.
if A and X are real numbers and A>0 then
A^X := exp(X*ln(A)) (Definition in analytical mathematics).
That is an incomplete definition, as 0^X is well-defined.
0^0 = lim A->0,
On 2005-03-08, at 02:01, Robert Dewar wrote:
Yes, and usually by definition in mathematics 0**0 is outside the
domain
of the exponentiation operator.
Usually the domain of the function in question with possible extensions
there of is given explicitly where such a function is in use.
"There is no r
Ronny Peine wrote:
Sorry for this, maybe i should sleep :) (It's 2 o'clock here)
But as i know of 0^0 is defined as 1 in every lecture i had so far.
Were these math classes, or CS classes.
Generally when you have a situation like this, where the value of
the function is different depending on how y
Well, these were math lectures (Analysis 1,2 and 3, Function Theory,
Numerical Mathematics and so on). In every lectures it was defined as 1
and in most cases mathematical expressions are mostly tried to transform
in equivalent calculations for the FPU (even though associativity is for
example
Hi again,
a small example often used in mathematics and electronic engineering:
the geometric row ("Reihe" in german, i don't know the correct
expression in english):
sum from k=0 to +unlimited q^k = 1/(1-q) if |q|<1.
this is also correct for q=0 where the sum gives q^0+q^1+q^2+...= 1 + 0
+ 0 +
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
"A number of real expressions are sometimes implemented as INVALID
by mistake, or declared Undefined by illconsidered
language standards; a few examples are ...
0.0**0.0 = inf**0.0 = NaN**0.0 = 1.0, no
On 2005-03-08, at 02:55, Ronny Peine wrote:
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
Lot's of opinions few hard arguments... I see there.
I wouldn't consider the above mentioned paper authoritative in any way.
On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> to specify a reference to the first operand is returned for values
> comparing equal.
NOT true. And the docs explicitly say so.
r~
On Tue, 8 Mar 2005 03:24:35 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
>
> On 2005-03-08, at 02:55, Ronny Peine wrote:
>
> > Maybe i found something:
> >
> > http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> > page 9 says:
>
> Lot's of opinions few hard arguments... I see there
On 2005-03-08, at 04:07, David Starner wrote:
On Tue, 8 Mar 2005 03:24:35 +0100, Marcin Dalecki <[EMAIL PROTECTED]>
wrote:
On 2005-03-08, at 02:55, Ronny Peine wrote:
Maybe i found something:
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
page 9 says:
Lot's of opinions few hard argume
On Mon, 7 Mar 2005, Richard Henderson wrote:
> On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> > For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> > to specify a reference to the first operand is returned for values
> > comparing equal.
>
> NOT true. And the docs explic
I don't think this has to be perfect to be a big win over what we've got.
The worst slowdown anybody is reporting with Zack's simple-minded
approach is on the order of a minute. That's on slow machines, where a
GCC bootstrap will take hours. So, I'm not worried about the time *at
all*. I'd be
Richard Kenner wrote:
I think the confusion may be in what is being called "parsing and
semantic analysis" as opposed to "the front end". I agree that fold
is probably not appropriate to be called during the former, but the latter
includes the act of building the GENERIC tree and I see absolutely
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote:
> We do need a story for generated headers. I'd be happy with explicit
> dependencies in the Makefiles indicating what source files depend on
> what generated headers. We'd still be able to get rid of 99% of the
> dependencies in o
Kazu Hirata wrote:
Hi,
Here is a preliminary result for fold_buildN from my personal tree. I
compiled cc1-i files with ./cc1 -quiet -O2 -fomit-frame-pointer
-fmem-report -o /dev/null. I used --enable-gather-detailed-mem-stats
to see how many nodes and bytes we are allocating for trees. (Thanks
H
Daniel Jacobowitz wrote:
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote:
We do need a story for generated headers. I'd be happy with explicit
dependencies in the Makefiles indicating what source files depend on
what generated headers. We'd still be able to get rid of 99% of the
On Tue, 8 Mar 2005 04:18:44 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> Are we a bit too obedient today? Look I was talking about the paper
> presented
> above not about the author there of.
Since we're getting personal, you've been terse, hostile and
dismissive this entire thread, and it h
On 2005-03-08, at 05:06, David Starner wrote:
The author's opinion comes from experience in the field. When someone
with a lot of experience talks, wise people listen, if they don't
agree in the end. I see no reason to casually dismiss that article.
My point is that there are really few hard argume
> > I compiled unexec.c from Emacs 21.3 with -O2, and I got the error
> > from GNU as on line 1498:
> >
> > Fatal error: C_EFCN symbol out of scope
> >
> > I'm on the x86. This only happens if all three of the following
> > are satisfied
> >
> > 1) -gcoff debugging information is being generate
Jonathan Wakely wrote:
Sorry for the late reply. It does indeed fix the problem I saw with 4.0
on FreeBSD, but I'm now seeing this with 3.4.4 20050228 too, so I think
it's a regression introduced in the last 6 weeks or so.
Is the same fix safe to apply to 3.4?
Yes, it should also be safe for gcc-3.
1 - 100 of 106 matches
Mail list logo
