On Mar 8, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> I wouldn't. automake has a much better solution for this that doesn't
>> introduce any such delays.
> Well, yes, but tell me how to make it play nice with all our generated
> header files.
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 7, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
>
>> (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.
>
> I wouldn't. auto
On Mar 7, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> (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.
I wouldn't. automake has a much better solution for this that doesn't
Giovanni Bajo wrote:
>
> It looks like the general consensus is that we should not use fold() anymore
> in the frontends (I consider gimplify part of middle-end already, as it is
> mostly language-independent). I know Java people also are trying to remove
> usage of fold() since it produces simpli
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Maybe cpplib could even be hacked to have a mode where (when
> generating dependencies) it silently permits #include of an
> non-existing file, considers it a dependency in the current
> directory, and just keeps going? I have insufficient cpplib taste
Tom Tromey <[EMAIL PROTECTED]> writes:
> Automake also doesn't do a separate "make depend" step. Dependencies
> are computed as a side effect of compilation.
I would take this approach if there were a sensible way to deal with
the generated sources.
> Computed headers are dealt with somewhat cl
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.
> > 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
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
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
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
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
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
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
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
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
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 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 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 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.
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
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 +
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
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
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:
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,
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
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)) =
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
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))
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 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
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
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: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
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
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
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
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
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
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
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
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: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
(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
> "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
"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
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:
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
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
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
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
> 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:
>> 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
> 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:
>> 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
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'
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
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 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
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
> > 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 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
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
DJ Delorie wrote:
> Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
Lucky guy! ;)
Paolo.
> (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
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
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
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
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
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, 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)
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 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
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
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
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
Maybe you can add gdc to your GCC front-ends listing
(http://home.earthlink.net/~dvdfrdmn/d/).
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
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
> 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
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
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
[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
-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
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'
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
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
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
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
(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
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.
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
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
> "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
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?
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.
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
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
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
1 - 100 of 106 matches
Mail list logo
