Hi Robert,
> >>Well if you tell me there are people about there implementing cpow
> >>with log and exp, that's enough for me to decide that Ada should
> >>continue to stay away (the Ada RM has accuracy requirements that
> >>would preclude a broken implementation of this kind) :-)
> >
> >
> > the
Mark Mitchell wrote:
Zack Weinberg wrote:
So, in other words,
if (current_function_stdarg)
data->last_named = true;
Actually, no:
data->last_named = !TREE_CHAIN (parm);
(This is the last "named" parameter iff it's the last parameter.)
yes, this is essentially the patch I am testing. AFAIC
On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
> That is a rather weak argument. What is the type of the argument if
> it were possible?
float obviously. You follow the standard promotion/type resolution
rules you already handle for operators like +. Done correctly,
min/max a
On 2005-03-07 17:09:46 +0100, Duncan Sands wrote:
> Mathematically speaking zero^zero is undefined, so it should be NaN.
[...]
Mathematically, this is just about conventions. But the main problem
here is that the power function is overloaded. For instance, you can
use pow() to compute x^i, where i
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>>> IMO, if these are C++-only, it's relatively easy to deprecate these
>>> extension -- but I'd like to hear from Jason and Nathan, and also the
>>> user community before we do that. Of all the extensions we've had, this
>>> one really hasn't been that
> On the one hand, as said above, there is no way of defining 0^0
> using continuity, but on the other hand, many important properties
> remain satisfied if we choose 0^0 = 1 (which is frequently
> adopted, as a convention, by mathematicians). Kahan suggests to
> choose 0^0 = 1.
On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
> The problem is x^0.0 (real exponent), not x^0 (integer exponent).
Well, mathematically, you can distinguish these two functions:
powrr: RxR -> R (not defined on (0,0) in particular)
and
powrz: RxZ -> R (where powint(0,0) = 1)
and even oth
Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
I don't know how efficient or accurate the current implementation
is (we are in the process of redoing our math routi
Hi,
On this page:
http://gcc.gnu.org/install/specific.html
there's a link to:
#*-*-solaris2*
but it doesn't work. Instead from what I can undersatnd it should be:
#g_t*-*-solaris2*
Regards,
Dimitri
Olivier Galibert <[EMAIL PROTECTED]> writes:
| On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
| > That is a rather weak argument. What is the type of the argument if
| > it were possible?
|
| float obviously. You follow the standard promotion/type resolution
| rules you alrea
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >>> IMO, if these are C++-only, it's relatively easy to deprecate these
| >>> extension -- but I'd like to hear from Jason and Nathan, and also the
| >>> user community before we do that. Of all the ext
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> Because the example was just an example. In real code, "3" is probably a
>> variable of integer type, and "4.0f" is probably a variable of floating
>> point type.
>
> Which we have not seen yet, for the purpose of assessing the purpoted
> usefulness i
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
| > The problem is x^0.0 (real exponent), not x^0 (integer exponent).
|
| Well, mathematically, you can distinguish these two functions:
|
| powrr: RxR -> R (not defined on (0,0) in particular)
|
|
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >> Because the example was just an example. In real code, "3" is probably a
| >> variable of integer type, and "4.0f" is probably a variable of floating
| >> point type.
| >
| > Which we have not seen ye
I have successfully built GCC-3.4.3 on the alpha-unknown-linux-gnu platform.
The specific OS is gentoo linux 2004.3 on the ev56 alpha platform.
My glibc is version 2.3.2.
The specific version portage emerged is "gcc version 3.4.3-20050110 (Gentoo
Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Because the example was just an example. In real code, "3" is probably
a
variable of integer type, and "4.0f" is probably a variable of floating
point type.
>>>
>>> Which we have not seen yet, for the purpose of assessing the purpoted
>>>
Giovanni Bajo wrote:
... which do not handle promotions. So you do not consider useful to have a
min/max operator with promotion (so that it would work exactly like any
other operator) just because there is a cheap version without promotion. And
my statement that min() and max() are not exact repla
This is PR debug/19769. [4.0/4.1 Regression] GCC produces wrong
dwarf2 output that breaks gdb
Because of this regression it has been impossible to debug any gcj
compiled program for several weeks now. gdb dies the instand libgcj
is loaded.
Can some C++ wizard please look at this and come up wit
On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | Well, mathematically, you can distinguish these two functions:
> |
> | powrr: RxR -> R (not defined on (0,0) in particular)
> |
> | and
> |
> | powrz: RxZ -> R (where powint(0,0) = 1)
> |
On Wed, 9 Mar 2005 18:48:06 +0100, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> ... which do not handle promotions. So you do not consider useful to have a
> min/max operator with promotion (so that it would work exactly like any
> other operator) just because there is a cheap version without promot
General
===
As per previous announcements, please do not place a target milestone
on bugs that are not part of the release criteria. For example, since
neither Ada nor Java are part of the release criteria, bugs that
affect only those languages should never have a target milestone.
(It's go
On Wednesday 09 March 2005 23:51, Mark Mitchell wrote:
> The remaining 1.1 projects include:
>
> * Autovectorization Enhancements (some parts)
Not seen yet.
> * SMS Improvements
Part 1 of n (n unknown) submitted and unreviewed so far:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00681.html
> *
On Wed, Mar 09, 2005 at 02:51:52PM -0800, Mark Mitchell wrote:
> As per previous announcements, please do not place a target milestone
> on bugs that are not part of the release criteria.
Hmm, see below.
> 4.0 Status
> ==
> In order to help us hit the April 15th target for GCC 4.0, plea
On Mar 9, 2005, at 6:15 PM, Greg Schafer wrote:
This is rather critical, yet a bugmaster saw fit to remove the 4.0.0
target
milestone on this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
Any chance of making this one a high priority?
Of course this is a glibc bug and not really a gcc
Mark Mitchell wrote:
* Structure Aliasing Part I
Submitted today. I've started reading it over.
Diego.
Snapshot gcc-3.3-20050309 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050309
You'll
I was looking at PR 19893 (gcc.dg/vect/vect-76 fails on ia64-hpux) and I
think it is caused by a non-platform specific bug, though it may not
cause vect-76 to fail on other platforms. I was hoping someone might be
able to help me understand what is going on.
Here is a cut down test case (with no
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | Well, mathematically, you can distinguish these two functions:
| > |
| > | powrr: RxR -> R (not defined on (0,0) in particular)
| > |
| > |
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Since there is no exact replacements
And that statement is false; and you do know that.
-- Gaby
On Wed, Mar 09, 2005 at 06:18:58PM -0500, Andrew Pinski wrote:
> On Mar 9, 2005, at 6:15 PM, Greg Schafer wrote:
>
> >This is rather critical, yet a bugmaster saw fit to remove the 4.0.0
> >target
> >milestone on this bug:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
> >
> >Any chan
On the page, http://gcc.gnu.org/gcc-4.0/changes.html, the link
http://www.nedprod.com/programs/gccvisibility.html (near the end of the
document) contains
``DOMAIN HOLDING PAGE
This is a holding page for a domain registered by Total Registrations on
behalf of a customer. At this present time
Is there a good way of creating an assembler comments directly from RTL?
I want to be able to add debugging/explanation strings to assembler listing
(GAS). Unfortunately I want to do this from RTL prologue and epilogue (and
thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where it would be easy
> Is there a good way of creating an assembler comments directly from RTL?
>
> I want to be able to add debugging/explanation strings to assembler
> listing (GAS). Unfortunately I want to do this from RTL prologue and
> epilogue (and thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where
> it woul
Steve Ellcey wrote:
I was looking at PR 19893 (gcc.dg/vect/vect-76 fails on ia64-hpux) and I
think it is caused by a non-platform specific bug, though it may not
cause vect-76 to fail on other platforms. I was hoping someone might be
able to help me understand what is going on.
Here is a cut down
> From: James E Wilson
> Sent: Tuesday, March 08, 2005 6:59 PM
[...]
>
> Try re-reading the docs. -fkeep-static-consts is the default. The
> purpose of this is that we don't perform this optimization at -O0
> normally, but if you use -fno-keep-static-consts, then we do. So this
> option can
35 matches
Mail list logo
