[Bug middle-end/29335] New: transcendental functions with constant arguments should be resolved at compile-time

[Bug middle-end/29335] New: transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

We should use GMP/MPFR from inside builtins.c to resolve things like e.g.
cos(0.12345) at compile-time.

Need to figure out:

1.  Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.

2.  Whether we should include GMP/MPFR in the svn archive like we do for intl
and zlib.

3.  Whether GMP/MPFR works on all the platforms/configurations that GCC
supports.  Are we ready to require a GMP/MPFR port for every port of GCC?

4.  If we don't do #2 and there is no system GMP/MPFR or the system lib is too
old, or if we trip over #3 and can't have GMP/MPFR, then what?  Do we require
the user to go get/port it, or silently eliminate this optimization during the
build process?


-- 
           Summary: transcendental functions with constant arguments should
                    be resolved at compile-time
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ghazi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-05 05:11 -------
Confirmed.
> 3.  Whether GMP/MPFR works on all the platforms/configurations that GCC
> supports.  Are we ready to require a GMP/MPFR port for every port of GCC?
As far as I know there is GMP port to all hosts that support GCC and nobody has
complained they cannot use gfortran because GMP was not ported yet.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
   Last reconfirmed|0000-00-00 00:00:00         |2006-10-05 05:11:01
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2006-10-05 17:54 -------
(In reply to comment #0)
> 
> 1.  Whether a certain minimum version of GMP/MPFR is required to avoid known
> bugs, etc.

See my recent patch to toplevel configure.in.  THe minimum required 
versions should be gmp-4.1.x and mpfr-2.2.0.

> 2.  Whether we should include GMP/MPFR in the svn archive like we do for intl
> and zlib.

I think that gmp and mpfr would need to be imported into GCC.  If you read the
gmp webpage, it often contains warnings about using newer versions of GCC to 
gmp because of bugs.

> 3.  Whether GMP/MPFR works on all the platforms/configurations that GCC
> supports.  Are we ready to require a GMP/MPFR port for every port of GCC?
> 
> 4.  If we don't do #2 and there is no system GMP/MPFR or the system lib is too
> old, or if we trip over #3 and can't have GMP/MPFR, then what?  Do we require
> the user to go get/port it, or silently eliminate this optimization during the
> build process?

I could be mistaken, but I believe one can configure gmp for a generic library
that does not use any machine (ie., cpu) specific assembly.

If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #3 from ghazi at gcc dot gnu dot org  2006-10-06 13:25 -------
(In reply to comment #2)
> (In reply to comment #0)
> > 
> > 1.  Whether a certain minimum version of GMP/MPFR is required to avoid known
> > bugs, etc.
> See my recent patch to toplevel configure.in.  THe minimum required 
> versions should be gmp-4.1.x and mpfr-2.2.0.

I see that, but when configure detects the "broken" mpfr, it just prints out a
message and proceeds happily.  It doesn't disable anything. (???)

> If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
> that you take a look to see what gmp/mpfr can do.

I looked through those and read through the mpfr docs so I think I have a good
idea of what mpfr can do.  My main area of concern right now is converting
between gcc's REAL_VALUE_TYPE and mpfr_t.  I found gfc_conv_mpfr_to_tree() in
trans-const.c which uses a string as an intermediate type, is that the most
efficient way to convert?  Also where is the function that does the reverse,
i.e. tree or REAL_VALUE_TYPE to mpfr_t?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2006-10-06 14:40 -------
(In reply to comment #3)
> (In reply to comment #2)
>> (In reply to comment #0)
>>> 
>>> 1.  Whether a certain minimum version of GMP/MPFR is required to
>>> avoid known bugs, etc.
>> See my recent patch to toplevel configure.in.  THe minimum required 
>> versions should be gmp-4.1.x and mpfr-2.2.0.
> 
> I see that, but when configure detects the "broken" mpfr, it just prints
> out a message and proceeds happily.  It doesn't disable anything. (???)

It's simply a warning to a user that there are known problems with the
version of MPFR on the system.  gfortran will work correctly with the
buggy mpfr with the exception of some corner cases and PRs that I've
fixed using newer features.  In particular, there are problems with
the old hackish way that gfortran handled subnormal numbers.  gfortran
also uses functions that are in 2.2.0 that are not available in some
of the older versions.

See simplify.c(gfc_simplify_nearest).

>> If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
>> that you take a look to see what gmp/mpfr can do.
> 
> I looked through those and read through the mpfr docs so I think I have a good
> idea of what mpfr can do.  My main area of concern right now is converting
> between gcc's REAL_VALUE_TYPE and mpfr_t.  I found gfc_conv_mpfr_to_tree() in
> trans-const.c which uses a string as an intermediate type, is that the most
> efficient way to convert?

I didn't write that function, and so I have experimented with a replacement.
There is mpfr_get_ld(), which converts to a long double.  If the data type
never exceeds the properties of long double, then one may be able to
use mpfr_get_ld() and then fold_convert() the result to the proper type.

> Also where is the function that does the reverse,
> i.e. tree or REAL_VALUE_TYPE to mpfr_t?

gfortran doesn't have a need of going in the opposite direction.
gmp/mpfr are used in the frontend for the internal representation
of data types.  By the time gfortran reaches the functions in
trans-*.c, it has done all the constant folding and manipulation
of the data types that it can.  The trans-*.c functions simply
convert gfortran's black and red trees into the tree-ssa form.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #5 from ghazi at gcc dot gnu dot org  2006-10-06 15:36 -------
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> >> (In reply to comment #0)
> >>> 
> > idea of what mpfr can do.  My main area of concern right now is converting
> > between gcc's REAL_VALUE_TYPE and mpfr_t.  I found gfc_conv_mpfr_to_tree() in
> > trans-const.c which uses a string as an intermediate type, is that the most
> > efficient way to convert?
> I didn't write that function, and so I have experimented with a replacement.
> There is mpfr_get_ld(), which converts to a long double.  If the data type
> never exceeds the properties of long double, then one may be able to
> use mpfr_get_ld() and then fold_convert() the result to the proper type.

I think using long double defeats the whole purpose of using mpfr.  We're
supposed to avoid relying on the properties of the host's floating point for
cross-compilers where the target format is different.  Otherwise I could simply
call out to e.g. cosl() on the host and avoid the whole mpfr thing (okay okay,
assuming cosl() and the rest of c99 math functions exist... which they don't
always, but my point about target long double remains.)

I was hoping there was an easy was to extract the exponent and mantissa from
one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that
preserves everything clean in both directions.


> > Also where is the function that does the reverse,
> > i.e. tree or REAL_VALUE_TYPE to mpfr_t?
> gfortran doesn't have a need of going in the opposite direction.
> gmp/mpfr are used in the frontend for the internal representation
> of data types.  By the time gfortran reaches the functions in
> trans-*.c, it has done all the constant folding and manipulation
> of the data types that it can.  The trans-*.c functions simply
> convert gfortran's black and red trees into the tree-ssa form.

Okay I hacked up something in the other direction using strings again.  If
someone comes up with something better, then great.  But it's not strictly
necessary.  I can put the two conversion functions into real.[ch].


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2006-10-06 17:03 -------
> > There is mpfr_get_ld(), which converts to a long double.  If the data type
> > never exceeds the properties of long double, then one may be able to
> > use mpfr_get_ld() and then fold_convert() the result to the proper type.
> 
> I think using long double defeats the whole purpose of using mpfr.

It appears you misread what I wrote (or meant to write).  "If the data
type never exceeds the properties of long double"  applies to a cross
compiler as well where "data type" is on the target and "long double"
is on the host.  

>  We're
> supposed to avoid relying on the properties of the host's floating point for
> cross-compilers where the target format is different.

The host's long double is simply an intermediate representation of the
value.  It is the responsibility of the fold_convert to get the right
target representation.  This is no different than using strings as the
intermediate.

> I was hoping there was an easy was to extract the exponent and mantissa from
> one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that
> preserves everything clean in both directions.

See trans-intrinsics.c (prepare_arg_info), although I'm get ready to submit
a patch that removes that function.

> > > Also where is the function that does the reverse,
> > > i.e. tree or REAL_VALUE_TYPE to mpfr_t?
> > gfortran doesn't have a need of going in the opposite direction.
> > gmp/mpfr are used in the frontend for the internal representation
> > of data types.  By the time gfortran reaches the functions in
> > trans-*.c, it has done all the constant folding and manipulation
> > of the data types that it can.  The trans-*.c functions simply
> > convert gfortran's black and red trees into the tree-ssa form.
> 
> Okay I hacked up something in the other direction using strings again.  If
> someone comes up with something better, then great.  But it's not strictly
> necessary.  I can put the two conversion functions into real.[ch].

I would be interested in seeing the functions because gfortran currently
can't constant fold a TRANSFER() of the form

real, parameter :: x = transfer(1234,x)

This is a bitwise copy of the integer 1234 into x.  In gfortran 1235 is
a gmp mpz_t type and x is an mpfr mpfr_t type.  Emulating the bitwise 
copy will require strings manipulations. 


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #7 from ghazi at gcc dot gnu dot org  2006-10-07 02:04 -------
(In reply to comment #6)
> > > There is mpfr_get_ld(), which converts to a long double.  If the data type
> > > never exceeds the properties of long double, then one may be able to
> > > use mpfr_get_ld() and then fold_convert() the result to the proper type.
> > 
> > I think using long double defeats the whole purpose of using mpfr.
> It appears you misread what I wrote (or meant to write).  "If the data
> type never exceeds the properties of long double"  applies to a cross
> compiler as well where "data type" is on the target and "long double"
> is on the host.  
> >  We're
> > supposed to avoid relying on the properties of the host's floating point for
> > cross-compilers where the target format is different.
> The host's long double is simply an intermediate representation of the
> value.  It is the responsibility of the fold_convert to get the right
> target representation.  This is no different than using strings as the
> intermediate.

I want the optimization to work always, not just in certain host/target
combinations.  So I'll use strings, no big deal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #8 from ghazi at gcc dot gnu dot org  2006-10-07 14:07 -------
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00360.html

Need to decide whether we're including GMP/MPFR in GCC repo or we need
configure goo to detect if we have it.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2006-
                   |                            |10/msg00360.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #9 from ghazi at gcc dot gnu dot org  2006-10-09 17:16 -------
I decided to explore including GMP/MPFR in the GCC tree.  Dependency PR 29405
opened to track that enhancement.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |29405


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #10 from ghazi at gcc dot gnu dot org  2006-10-14 16:12 -------
No longer relying on PR29405.  Instead we'll force the person building GCC to
acquire GMP/MPFR themselves.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|29405                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #11 from ghazi at gcc dot gnu dot org  2006-10-14 16:13 -------
Updated patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00757.html


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
                   |patches/2006-               |patches/2006-
                   |10/msg00360.html            |10/msg00757.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #12 from ghazi at gcc dot gnu dot org  2006-10-20 15:53 -------
Third patch revision posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01039.html


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
                   |patches/2006-               |patches/2006-
                   |10/msg00757.html            |10/msg01039.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #13 from ghazi at gcc dot gnu dot org  2006-10-23 20:25 -------
Subject: Bug 29335

Author: ghazi
Date: Mon Oct 23 20:24:55 2006
New Revision: 117983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117983
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_sin, fold_builtin_cos,
        fold_builtin_tan): Fold all constant arguments.  Take a "type"
        argument as necessary.
        (do_mpfr_arg1): New.
        * real.c, real.h (real_from_mpfr, mpfr_from_real): New.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/real.c
    trunk/gcc/real.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #14 from ghazi at gcc dot gnu dot org  2006-10-24 17:44 -------
Subject: Bug 29335

Author: ghazi
Date: Tue Oct 24 17:44:36 2006
New Revision: 118009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118009
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_sin, fold_builtin_atan): Remove.
        (do_mpfr_arg1): Add `min', `max' and `inclusive' arguments.
        Update all callers.
        (BUILT_IN_SIN, BUILT_IN_ATAN): Handle in main switch.
        (BUILT_IN_ASIN, BUILT_IN_ACOS, BUILT_IN_ATAN, BUILT_IN_ASINH,
        BUILT_IN_ACOSH, BUILT_IN_ATANH, BUILT_IN_SINH, BUILT_IN_COSH,
        BUILT_IN_TANH): Calculate compile-time arguments using MPFR.

testsuite:
        * gcc.dg/torture/builtin-math-3.c: New test.



Added:
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #15 from ghazi at gcc dot gnu dot org  2006-10-25 20:44 -------
Subject: Bug 29335

Author: ghazi
Date: Wed Oct 25 20:44:09 2006
New Revision: 118042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118042
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_cbrt, fold_builtin_logarithm):
        Calculate compile-time constants using MPFR.
        (fold_builtin_1): Likewise handle BUILT_IN_ERF, BUILT_IN_ERFC,
        BUILT_IN_EXPM1 and BUILT_IN_LOG1P.

testsuite:
        * gcc.dg/torture/builtin-math-2.c (TESTIT): Use new helper macro.
        Add checks for log, log2, log10 and log1p.

        * gcc.dg/torture/builtin-math-3.c: Add checks for -0.0 everywhere
        we already test 0.0.  Add checks for expm1, log, log2, log10,
        log1p, cbrt, erf and erfc.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #16 from ghazi at gcc dot gnu dot org  2006-10-28 03:20 -------
I'm getting wierd NaN results when I hook up __builtin_lgamma to mpfr_lngamma. 
I can expose the problem using a standlone C program calling mpfr like so. 
Results are first, C testcase is second.  Now I know lgamma/mpfr_lngamma are
both documented to barf on negative integers.  But as you can see, I'm passing
x.5 in every case.  Seems like any time "x" is an even number I get a NaN.  I
wonder if this is a bug in mpfr, or my mistake?  (I tried mpfr-2.2.0 with and
without the cumulative patch.  I got the problem in both cases.)  Can anyone
else reproduce this?

lgamma(-4.50) = -2.813084
mpfr_lngamma(-4.50) = @NaN@

lgamma(-3.50) = -1.309007
mpfr_lngamma(-3.50) = -1.3090066849930420

lgamma(-2.50) = -0.056244
mpfr_lngamma(-2.50) = @NaN@

lgamma(-1.50) = 0.860047
mpfr_lngamma(-1.50) = 8.6004701537648098e-1

lgamma(-0.50) = 1.265512
mpfr_lngamma(-0.50) = @NaN@



#include <stdio.h>
#include <math.h>
#include <gmp.h>
#include <mpfr.h>

#define TESTIT(X) do { \
  printf ("lgamma(%.2f) = %f\n", (X), gamma(X)); \
  mpfr_set_d(m, (X), GMP_RNDN); \
  mpfr_lngamma(m, m, GMP_RNDN); \
  printf ("mpfr_lngamma(%.2f) = ", (X)); \
  mpfr_out_str (stdout, 10, 0, m, GMP_RNDN); \
  putc ('\n', stdout); \
  putc ('\n', stdout); \
} while (0)

int main()
{
  mpfr_t m;
  mpfr_init2(m, 53);

  TESTIT(-4.5);
  TESTIT(-3.5);
  TESTIT(-2.5);
  TESTIT(-1.5);
  TESTIT(-0.5);

  mpfr_clear(m);
  return 0;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #17 from sgk at troutmask dot apl dot washington dot edu  2006-10-28 03:48 -------
Subject: Re:  transcendental functions with constant arguments should be
resolved at compile-time

On Sat, Oct 28, 2006 at 03:20:11AM -0000, ghazi at gcc dot gnu dot org wrote:
> 
> 
> ------- Comment #16 from ghazi at gcc dot gnu dot org  2006-10-28 03:20 -------
> I'm getting wierd NaN results when I hook up __builtin_lgamma to mpfr_lngamma. 
> I can expose the problem using a standlone C program calling mpfr like so. 
> Results are first, C testcase is second.  Now I know lgamma/mpfr_lngamma are
> both documented to barf on negative integers.  But as you can see, I'm passing
> x.5 in every case.  Seems like any time "x" is an even number I get a NaN.  I
> wonder if this is a bug in mpfr, or my mistake?  (I tried mpfr-2.2.0 with and
> without the cumulative patch.  I got the problem in both cases.)  Can anyone
> else reproduce this?
> 
> lgamma(-4.50) = -2.813084
> mpfr_lngamma(-4.50) = @NaN@
> 

Yes, I can reproduce the NaN.  In fact, any negative value 
gives a NaN.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #18 from vincent at vinc17 dot org  2006-10-28 09:07 -------
(In reply to comment #17)
> Yes, I can reproduce the NaN.  In fact, any negative value 
> gives a NaN.

Not any negative value, but in lngamma.c:

  /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */

probably because the gamma value is negative. This is because MPFR defines
lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I
wonder if this should be regarded as a bug or if a new function (say,
mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0). Do
other standards (other languages) define such a function, either as
log(gamma(x)) or as log|gamma(x)|?

Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite
loop in the 2.2 branch. This problem is now detected in the trunk, and until
this is completely fixed, a NaN is returned with the MPFR erange flag set. This
should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will
come several days after that).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #19 from ghazi at gcc dot gnu dot org  2006-10-28 13:28 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Yes, I can reproduce the NaN.  In fact, any negative value 
> > gives a NaN.
> Not any negative value, but in lngamma.c:
>   /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */
> probably because the gamma value is negative. This is because MPFR defines
> lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I
> wonder if this should be regarded as a bug or if a new function (say,
> mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0).

The documenation in MPFR says:
 -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
     Set ROP to the value of the Gamma function on OP, and its
     logarithm respectively, rounded in the direction RND.  When OP is
     a negative integer, NaN is returned.

It only talked about negative integers, and I glossed over the fact that it
left out the absolute value that C does.  So it was pilot error, but I think a
clarification would help.  Many times in the docs MPFR takes pains to follow
the C99 standard, e.g. the inputs to atan2 or pow.  Where you deviate from it
should also be noted. 

Or you could consider it a bug and fix it. :-)

Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right?


> Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite
> loop in the 2.2 branch. This problem is now detected in the trunk, and until
> this is completely fixed, a NaN is returned with the MPFR erange flag set. This
> should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will
> come several days after that).

If it returns NaN for now that's fine since GCC avoids any transformation that
returns NaN or Inf.

Glad to hear a new version is coming out.  If you make a prerelease tarball
available somewhere I'd like to try it with mainline GCC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #20 from vincent at vinc17 dot org  2006-10-28 14:05 -------
(In reply to comment #19)
> The documenation in MPFR says:
>  -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
>      Set ROP to the value of the Gamma function on OP, and its
>      logarithm respectively, rounded in the direction RND.  When OP is
>      a negative integer, NaN is returned.
> 
> It only talked about negative integers,

AFAIK, this was mainly for Gamma(negative integer). But this is also true for
lngamma(negative integer). But the point is that if gamma(x) is negative, then
lngamma(x) is NaN since the logarithm of a negative value is NaN. But that's
why the C standard defines lgamma as log|gamma(x)| instead of log(gamma(x)).

> and I glossed over the fact that it
> left out the absolute value that C does.  So it was pilot error, but I think a
> clarification would help.  Many times in the docs MPFR takes pains to follow
> the C99 standard, e.g. the inputs to atan2 or pow.  Where you deviate from it
> should also be noted.

I agree. And I think that none of the MPFR developers were aware of this
problem (I didn't notice the difference when I was looking for C functions that
were missing in MPFR). I posted a mail about that on the MPFR mailing-list.

> Or you could consider it a bug and fix it. :-)

I think this is the best solution, in particular because this would change only
NaN values.

> Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right?

Probably not a good idea, because I think that mpfr_gamma may overflow, though
the final result may be in the double-precision range.

> Glad to hear a new version is coming out.  If you make a prerelease tarball
> available somewhere I'd like to try it with mainline GCC.

OK, I hope I won't forget to announce it in the gcc dev mailing-list.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #21 from ghazi at gcc dot gnu dot org  2006-10-28 16:03 -------
(In reply to comment #20)
> I agree. And I think that none of the MPFR developers were aware of this
> problem (I didn't notice the difference when I was looking for C functions
> that were missing in MPFR). 

Since you mentioned C functions missing in MPFR, what are your plans for the
Bessel functions?  I'd like to hook up builtins j0/j1/jn/y0/y1/yn.  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #22 from vincent at vinc17 dot org  2006-10-28 16:58 -------
(In reply to comment #21)
> Since you mentioned C functions missing in MPFR, what are your plans for the
> Bessel functions?  I'd like to hook up builtins j0/j1/jn/y0/y1/yn.  Thanks.

They're in the TODO, but there are no plans yet to implement them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #23 from ghazi at gcc dot gnu dot org  2006-10-29 02:02 -------
Subject: Bug 29335

Author: ghazi
Date: Sun Oct 29 02:02:10 2006
New Revision: 118129

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118129
Log:
        PR middle-end/29335
        * builtins.c (do_mpfr_arg2, fold_builtin_hypot): New.
        (fold_builtin_pow): Evaluate constant arguments at compile-time
        using MPFR.
        (fold_builtin_1): Handle BUILT_IN_ATAN2 and BUILT_IN_HYPOT.
        (do_mpfr_ckconv): New helper function.
        (do_mpfr_arg1): Use do_mpfr_ckconv.
        (do_mpfr_arg2): New.

testsuite:
        * gcc.dg/builtins-20.c: Add tests for hypot.
        * gcc.dg/torture/builtin-math-2.c (TESTIT2): New.  Add tests for
        two-argument builtins.
        * gcc.dg/torture/builtin-math-3.c (TESTIT_R): Renamed from
        TESTIT2.  Update all callers.
        (TESTIT2, TESTIT2_R): New helper macros.
        Add testcases for pow, hypot and atan2.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/builtins-20.c
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #24 from ghazi at gcc dot gnu dot org  2006-10-30 20:22 -------
Subject: Bug 29335

Author: ghazi
Date: Mon Oct 30 20:21:59 2006
New Revision: 118200

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118200
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_1): Evaluate tgamma using MPFR.

testsuite:
        * gcc.dg/torture/builtin-math-2.c: Add tgamma tests.
        * gcc.dg/torture/builtin-math-3.c: Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #25 from ghazi at gcc dot gnu dot org  2006-10-31 03:14 -------
(In reply to comment #18)
> (In reply to comment #17)
> This is because MPFR defines
> lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I
> wonder if this should be regarded as a bug or if a new function (say,
> mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0). Do
> other standards (other languages) define such a function, either as
> log(gamma(x)) or as log|gamma(x)|?

As I think about it more, I'm leaning toward having a new function mpfr_lgamma.
 This is because if we want this mpfr function to mimic the behavior of lgamma,
we need some mechanism to retrieve the value of "signgam".  So maybe the
interface you suggested at the bottom of this link would be best where we
retrieve an int* from mpfr_lgamma to determine "signgam":
http://sympa.loria.fr/wwsympa/arc/mpfr/2006-10/msg00033.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #26 from vincent at vinc17 dot org  2006-10-31 09:54 -------
(In reply to comment #25)
> As I think about it more, I'm leaning toward having a new function mpfr_lgamma.
>  This is because if we want this mpfr function to mimic the behavior of lgamma,
> we need some mechanism to retrieve the value of "signgam".  So maybe the
> interface you suggested at the bottom of this link would be best where we
> retrieve an int* from mpfr_lgamma to determine "signgam":
> http://sympa.loria.fr/wwsympa/arc/mpfr/2006-10/msg00033.html

Yes, it's true that it is useful to have this value. But determining it
separately is quite easy, without taking a noticeable additional time in
average.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #27 from ghazi at gcc dot gnu dot org  2006-10-31 20:08 -------
(In reply to comment #26)
> Yes, it's true that it is useful to have this value. But determining it
> separately is quite easy, without taking a noticeable additional time in
> average.

It's likely that I'll end up doing it, so would you please tell me how?
Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #28 from vincent at vinc17 dot org  2006-10-31 22:15 -------
(In reply to comment #27)
> It's likely that I'll end up doing it, so would you please tell me how?

According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
[iff] x < 0 && remainder(floor(x), 2) != 0. But if x is a non-positive integer,
the sign of gamma(x) isn't defined. Handle these cases first.

The test x < 0 is easy to do. In MPFR, you can compute floor(x) (or trunc(x))
with the precision min(PREC(x),max(EXP(x),MPFR_PREC_MIN)), but then, there's no
direct function to decide whether the result is even or odd (I thought we added
this, but this isn't the case). The solution can be to divide x by 2 (this is
exact, except in case of underflow) and call mpfr_frac directly. If the result
is between -0.5 and 0, then gamma(x) is negative. If the result is between -1
and -0.5, then gamma(x) is positive. So, a 2-bit precision for mpfr_frac should
be sufficient (as -0.5 is representable in this precision), but choose a
directed rounding (not GMP_RNDN) for that. Then you can just do a comparison
with -0.5; the case of equality with -0.5 depends on the chosen rounding (if
you obtain -0.5, then it is an inexact result since x is not an integer). For
instance, if you choose GMP_RNDZ, then a result > -0.5 means that gamma(x) is
negative, and a result <= -0.5 means that gamma(x) is positive.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #29 from ghazi at gcc dot gnu dot org  2006-11-02 03:21 -------
Subject: Bug 29335

Author: ghazi
Date: Thu Nov  2 03:20:49 2006
New Revision: 118409

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118409
Log:
        PR middle-end/29335
        * builtins.c (do_mpfr_sincos): New.
        (fold_builtin_1): Use it to fold builtin sincos.

testsuite:
        * gcc.dg/torture/builtin-math-3.c: Fix semicolons.
        (TESTIT_2P, TESTIT_2P_R): New macros.  Test sincos.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #30 from ghazi at gcc dot gnu dot org  2006-11-02 14:41 -------
(In reply to comment #28)
> (In reply to comment #27)
> > It's likely that I'll end up doing it, so would you please tell me how?
> According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
> [iff] x < 0 && remainder(floor(x), 2) != 0. But if x is a non-positive integer,
> the sign of gamma(x) isn't defined. Handle these cases first.
> The test x < 0 is easy to do. In MPFR, you can compute floor(x) (or trunc(x))
> with the precision min(PREC(x),max(EXP(x),MPFR_PREC_MIN)), but then, there's no
> direct function to decide whether the result is even or odd (I thought we added
> this, but this isn't the case). The solution can be to divide x by 2 (this is
> exact, except in case of underflow) and call mpfr_frac directly. If the result
> is between -0.5 and 0, then gamma(x) is negative. If the result is between -1
> and -0.5, then gamma(x) is positive. So, a 2-bit precision for mpfr_frac should
> be sufficient (as -0.5 is representable in this precision), but choose a
> directed rounding (not GMP_RNDN) for that. Then you can just do a comparison
> with -0.5; the case of equality with -0.5 depends on the chosen rounding (if
> you obtain -0.5, then it is an inexact result since x is not an integer). For
> instance, if you choose GMP_RNDZ, then a result > -0.5 means that gamma(x) is
> negative, and a result <= -0.5 means that gamma(x) is positive.

Vincent, thank you for the detailed instructions.  I also read your two
possible solutions posted here:
http://sympa.loria.fr/wwsympa/arc/mpfr/2006-10/msg00036.html

I could be satisfied with either solution from that message.  However in the
case of choice 1, I feel the calculation of signgam should be provided from a
function call in the library rather than forcing each user to write a routine
to calculate it.  IMHO, I'd rather leave the math to the mathematicians. :-) 
E.g. you could add a function mpfr_signgam() that figures out the value for the
user and thereby leave the interface for mpfr_lngamma() unchanged.  Choice 2
also solves the issue by providing the int* parameter.

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #31 from vincent at vinc17 dot org  2006-11-02 15:57 -------
(In reply to comment #30)

So, I don't think a mpfr_signgam alone would really be useful. So, I think that
choice 2 would be better.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #32 from ghazi at gcc dot gnu dot org  2006-11-02 22:44 -------
(In reply to comment #31)
> (In reply to comment #30)
> So, I don't think a mpfr_signgam alone would really be useful. So, I think that
> choice 2 would be better.

Okay, sounds fine.  Would this make it into 2.2.1 or 2.3?  And do you have any
very rough timeframe for each release so I can plan accordingly for gcc?
Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[vincent at vinc17 dot org]

------- Comment #33 from vincent at vinc17 dot org  2006-11-05 23:27 -------
(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #30)
> > So, I don't think a mpfr_signgam alone would really be useful. So, I think that
> > choice 2 would be better.
> 
> Okay, sounds fine.  Would this make it into 2.2.1 or 2.3?

For compatibility reasons (i.e. the 2.2.x versions must have the same
interface), this can only be in 2.3.0.

> And do you have any very rough timeframe for each release so I can plan
> accordingly for gcc?

A pre-release of 2.2.1 should be there soon; there are still bugs being fixed
(they will be ported to the 2.2 branch once this is complete).

I don't know about 2.3.0; probably in a few months, because there currently
aren't many differences from the 2.2 branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #34 from ghazi at gcc dot gnu dot org  2006-11-07 02:46 -------
(In reply to comment #33)
> > Okay, sounds fine.  Would this make it into 2.2.1 or 2.3?
> For compatibility reasons (i.e. the 2.2.x versions must have the same
> interface), this can only be in 2.3.0.
> > And do you have any very rough timeframe for each release so I can plan
> > accordingly for gcc?
> A pre-release of 2.2.1 should be there soon; there are still bugs being fixed
> (they will be ported to the 2.2 branch once this is complete).
> I don't know about 2.3.0; probably in a few months, because there currently
> aren't many differences from the 2.2 branch.

Well, maybe if the Bessel functions were added to 2.3.0 it would be
sufficiently different from 2.2.x to warrent a release.  See comment#22.  :-)


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-  |
                   |patches/2006-               |
                   |10/msg01039.html            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[chaoyingfu at gcc dot gnu dot org]

------- Comment #35 from chaoyingfu at gcc dot gnu dot org  2006-11-30 19:44 -------
Subject: Bug 29335

Author: chaoyingfu
Date: Thu Nov 30 19:43:57 2006
New Revision: 119376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119376
Log:
Merged revisions 118384-118452 via svnmerge from 
svn+ssh://chaoyingfu@sources.redhat.com/svn/gcc/trunk

........
  r118384 | sje | 2006-11-01 08:25:17 -0800 (Wed, 01 Nov 2006) | 2 lines

        * tests/base/sys/socket.h: Update.
........
  r118385 | dgregor | 2006-11-01 08:27:23 -0800 (Wed, 01 Nov 2006) | 8 lines

  2006-11-01    Douglas Gregor <doug.gregor@gmail.com>

        * include/cpplib.h (enum c_lang): Add CLK_GNUCXX0X and CLK_CXX0X
        for experimental C++0x mode.
        * init.c (lang_defaults): Add defaults for C++0x modes. C++0x has
        adopted the preprocessor changes introduced in C99.
........
  r118386 | dgregor | 2006-11-01 08:29:06 -0800 (Wed, 01 Nov 2006) | 14 lines

  2006-11-01    Douglas Gregor <doug.gregor@gmail.com>

        * c-common.c (flag_cpp0x): New.
        * c-common.h (flag_cpp0x): New.
        * c-cppbuiltin.c (c_cpp_builtins): If C++0x extensions are
        supported, define __GXX_EXPERIMENTAL_CPP0X__.
        * c-opts.c (set_std_cxx0x): New.
        (c_common_handle_option): Handle -std=c++0x, -std=gnu++0x.
        * c.opt (std=c++0x): Document.
        (std=gnu++0x): Ditto.
        * doc/cpp.texi: Document __GXX_EXPERIMENTAL_CPP0X__.
        * doc/invoke.texi: Document -std=c++0x, -std=gnu++0x.

........
  r118389 | dgregor | 2006-11-01 09:13:27 -0800 (Wed, 01 Nov 2006) | 14 lines

  2006-11-01    Douglas Gregor <doug.gregor@gmail.com>

        * c-common.c (flag_cpp0x): New.
        * c-common.h (flag_cpp0x): New.
        * c-cppbuiltin.c (c_cpp_builtins): If C++0x extensions are
        supported, define __GXX_EXPERIMENTAL_CPP0X__.
        * c-opts.c (set_std_cxx0x): New.
        (c_common_handle_option): Handle -std=c++0x, -std=gnu++0x.
        * c.opt (std=c++0x): Document.
        (std=gnu++0x): Ditto.
        * doc/cpp.texi: Document __GXX_EXPERIMENTAL_CPP0X__.
        * doc/invoke.texi: Document -std=c++0x, -std=gnu++0x.
........
  r118391 | kseitz | 2006-11-01 10:20:19 -0800 (Wed, 01 Nov 2006) | 8 lines

          * gnu/gcj/jvmti/Location.java: New file.
          * gnu/gcj/jvmti/BreakpointManager.java: New file.
          * jvmti.cc (_Jv_JVMTI_SetBreakpoint): New function.
          (_Jv_JVMTI_ClearBreakpoint): New function.
          (_Jv_JVMTI_Interface): Define SetBreakpoint and ClearBreakpoint.
          * sources.am: Regenerated.
          * Makefile.in: Regenerated.
........
  r118392 | vprus | 2006-11-01 11:01:36 -0800 (Wed, 01 Nov 2006) | 6 lines

  2006-11-01  Chris Johns <chris@contemporary.net.au>

          PR bootstrap/28400
          * Makefile.in (install-driver): Use exeext when installing
          $target-gcc-$version.
........
  r118393 | nemet | 2006-11-01 11:19:28 -0800 (Wed, 01 Nov 2006) | 5 lines

        * tree-pretty-print.c (dump_generic_node) <INTEGER_CST>: Use
        HOST_WIDE_INT_PRINT to print high and low parts.  Use
        HOST_BITS_PER_WIDE_INT for the width of HOST_WIDE_INT.  When
        printing a hexadecimal number prefix it with 0x.
........
  r118394 | nemet | 2006-11-01 11:22:02 -0800 (Wed, 01 Nov 2006) | 5 lines

        * gcc.dg/fold-mod-1.c: Match the leading 0x for the
        hexadecimal value.
        * gcc.dg/tree-prof/val-prof-2.c: Likewise.
        * gcc.dg/pr14796-2.c: Likewise.
........
  r118396 | bergner | 2006-11-01 12:47:53 -0800 (Wed, 01 Nov 2006) | 67 lines

        * doc/invoke.texi: Add cpu_type power6x
        (RS/6000 and PowerPC Options): Add -mmfpgpr.
        * config.gcc: Add cpu_type power6x.
        * configure.ac: Add test for mf{t,f}gpr instructions.
        (HAVE_AS_MFPGPR): New.
        * config.in: Regenerate.
        * configure: Regenerate.
        * config/rs6000/aix52.h (ASM_CPU_SPEC): Add power6x.
        * config/rs6000/rs6000.md (define_attr "type"): Add insert_dword,
        shift,trap,var_shift_rotate,cntlz,exts, var_delayed_compare, mffgpr
        and mftgpr attributes.
        (define_attr "cpu"): Add power6.
        Change instruction sequences to use new attributes.
        (floatsidf2,fix_truncdfsi2): use TARGET_MFPGPR.
        (fix_truncdfsi2_mfpgpr): New.
        (floatsidf_ppc64_mfpgpr): New.
        (floatsidf_ppc64): Added !TARGET_MFPGPR condition.
        (movdf_hardfloat64_mfpgpr,movdi_mfpgpr): New.
        (movdf_hardfloat64): Added !TARGET_MFPGPR condition.
        (movdi_internal64): Added !TARGET_MFPGPR and related conditions.
        (fix_truncdfsi2): Use gpc_reg_operand constraint.
        * config/rs6000/{6xx.md,power4.md,8540.md,603.md,mpc.md,
        7xx.md,rios2.md,7450.md,440.md,rios1.md,rs64.md,power5.md,40x.md}:
        Add descriptions for insert_dword, shift,trap,var_shift_rotate,
        cntlz,exts and var_delayed_compare.
        * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
        _ARCH_PWR6X, if features enabled.
        * config/rs6000/rs6000.opt (mmfpgpr): New.
        * config/rs6000/rs6000.c (rs6000_align_branch_targets): New variable.
        (cached_can_issue_more): New variable.
        (processor_costs): Add power6_cost.
        (rs6000_sched_init): New function.
        (is_dispatch_slot_restricted): Deleted.
        (set_to_load_agen): New function.
        (is_load_insn,is_store_insn): New functions.
        (adjacent_mem_locations): New function.
        (insn_must_be_first_in_group): New function.
        (insn_must_be_last_in_group): New function.
        (rs6000_sched_reorder): New function.
        (rs6000_sched_reorder2): New function.
        (TARGET_SCHED_INIT,TARGET_SCHED_REORDER,
        TARGET_SCHED_REORDER2): Define.
        (processor_target_table): Use PROCESSOR_POWER6 for power6.
        Add power6x. Add MASK_MFPGPR for power6x.
        (POWERPC_MASKS): Add MASK_MFPGPR.
        (rs6000_override_options): Set rs6000_always_hint to false
        for power6.  Set rs6000_align_branch_targets. Replace
        rs6000_sched_groups check with rs6000_align_branch_targets.
        Use PROCESSOR_POWER6.
        (last_scheduled_insn): New variable.
        (load_store_pendulum): New variable.
        (rs6000_variable_issue): Set last_scheduled_insn and
        cached_can_issue_more.
        (rs6000_adjust_cost): Add power6 cost adjustments.
        (rs6000_adjust_priority): Replace is_dispatch_slot_restricted
        with insn_must_be_first_in_group. Add power6 priority adjustments.
        (rs6000_issue_rate): Add CPU_POWER6.
        (insn_terminates_group_p): Use insn_must_be_{first,last}_in_group.
        * config/rs6000/rs6000.h (processor_type): Add PROCESSOR_POWER6.
        (TARGET_MFPGPR): New.
        (SECONDARY_MEMORY_NEEDED): Use TARGET_MFPGPR.
        (ASM_CPU_SPEC): Add power6x.
        (SECONDARY_MEMORY_NEEDED): Added mode!=DFmode and mode!=DImode
        conditions.
        * config/rs6000/power6.md: New file.
........
  r118403 | gccadmin | 2006-11-01 16:17:55 -0800 (Wed, 01 Nov 2006) | 1 line

  Daily bump.
........
  r118405 | sayle | 2006-11-01 16:56:38 -0800 (Wed, 01 Nov 2006) | 11 lines


        * configure.ac (HAVE_AS_IX86_DIFF_SECT_DELTA): New test to determine
        whether the assembler supports taking the difference of symbols in
        different sections.  On x86/Solaris, GAS does but Solaris as doesn't.
        * configure: Regenerate.
        * config.in: Regenerate.
        * config/i386/sol2-10.h (JUMP_TABLES_IN_TEXT_SECTION): Define if
        the assembler doesn't support taking the difference of symbols in
        different sections, i.e. we're using the native solaris assembler.
........
  r118408 | sayle | 2006-11-01 18:37:38 -0800 (Wed, 01 Nov 2006) | 5 lines


        * config/darwin.h (CPP_SPEC): Handle -pthread, transforming
        it into -D_REENTRANT.
........
  r118409 | ghazi | 2006-11-01 19:20:49 -0800 (Wed, 01 Nov 2006) | 9 lines

        PR middle-end/29335
        * builtins.c (do_mpfr_sincos): New.
        (fold_builtin_1): Use it to fold builtin sincos.

  testsuite:
        * gcc.dg/torture/builtin-math-3.c: Fix semicolons.
        (TESTIT_2P, TESTIT_2P_R): New macros.  Test sincos.
........
  r118419 | kseitz | 2006-11-02 08:59:04 -0800 (Thu, 02 Nov 2006) | 3 lines

          * jvmti.cc (_Jv_JVMTI_GetLineNumberTable): New function.
          (_Jv_JVMTI_Interface): Define GetLineNumberTable.
........
  r118420 | kseitz | 2006-11-02 09:01:01 -0800 (Thu, 02 Nov 2006) | 2 lines

          * gnu/classpath/jdwp/natVMMethod.cc (getLineTable): Implement.
........
  r118422 | ebotcazou | 2006-11-02 10:40:54 -0800 (Thu, 02 Nov 2006) | 6 lines

        PR other/29639
        * except.c (switch_to_exception_section): Do not cache the section
        if named sections are supported and HAVE_LD_EH_GC_SECTIONS is defined
        and flag_function_sections is set.
........
  r118424 | andreast | 2006-11-02 12:03:40 -0800 (Thu, 02 Nov 2006) | 5 lines

  2006-11-02  Andreas Tobler  <a.tobler@schweiz.org>

        * objc-act.c (objc_finish_file): Remove ifdef clause for OBJCPLUS and
        content where we called cp_finish_file.
........
  r118425 | pbrook | 2006-11-02 12:18:42 -0800 (Thu, 02 Nov 2006) | 9 lines

  2006-11-02  Paul Brook  <paul@codesourcery.com>

        gcc/
        * config/arm/arm.c (arm_elf_asm_constructor): Remove ATTRIBUTE_UNUSED
        from priority argument.  Use different section for non-default
        priority.
        * config/arm/elf.h: Remove definition of SUPPORTS_INIT_PRIORITY.
........
  r118426 | ebotcazou | 2006-11-02 12:43:19 -0800 (Thu, 02 Nov 2006) | 5 lines

        * doc/install.texi (sparc-sun-solaris2*): Update GMP/MPFR build
        instructions.
        (sparc64-sun-solaris2*): Likewise.
........
  r118431 | mrs | 2006-11-02 13:06:40 -0800 (Thu, 02 Nov 2006) | 2 lines

        * g++.old-deja/g++.abi/align.C: Enable for darwin.
........
  r118433 | mrs | 2006-11-02 14:01:36 -0800 (Thu, 02 Nov 2006) | 2 lines

        * obj-c++.dg/const-str-9.mm: Don't run on 64-bit.
........
  r118435 | kkojima | 2006-11-02 14:57:13 -0800 (Thu, 02 Nov 2006) | 20 lines

        PR target/27405
        * config/sh/sh.md (cmp{eq,gt,gtu}{si,di}_media): Remove.
        (cmpsi{eq,gt,gtu}{si,di}_media): Rename to
        cmp{eq,gt,gtu}{si,di}_media.
        (*cmpne0si_media): Remove.
        (*movsicc_umin): Adjust gen_cmp*_media call.
        (unordered): Change the mode of unordered and operands[1] to
        SImode.
        (seq): Adjust gen_cmp*_media calls.  Make the mode of
        a temporary result of compare SImode if needed.  If the mode
        of operands[0] is DImode, extend the temporary result to DImode.
        (slt, sle, sgt, sge, sgtu, sltu, sleu, sgue, sne): Likewise.
        (sunorderd): Change the mode of match_operand and unorderd to
        SImode.
        (cmpeq{sf,df}_media): Remove.
        (cmpsieq{sf,df}_media): Rename to cmpeq{sf,df}_media.
        (cmp{gt,ge,un}{sf,df}_media): Change the mode of match_operand
        and compare operation to SImode.
........
  r118442 | gccadmin | 2006-11-02 16:17:46 -0800 (Thu, 02 Nov 2006) | 1 line

  Daily bump.
........
  r118444 | bje | 2006-11-02 16:56:35 -0800 (Thu, 02 Nov 2006) | 3 lines

        * tree-ssa.c (warn_uninit): Use expand_location variables for
        locus and declaration locus.
........
  r118445 | pbrook | 2006-11-02 16:59:32 -0800 (Thu, 02 Nov 2006) | 15 lines

  2006-11-02  Carlos O'Donell  <carlos@codesourcery.com>

        gcc/
        * config/arm/linux-elf.h (NEED_INDICATE_EXEC_STACK): Define as 1.
        * arm.c (arm_file_end): If NEED_INDICATE_EXEC_STACK call 
        file_end_indicate_exec_stack. 
        * arm.h [!NEED_INDICATE_EXEC_STACK] (NEED_INIDCATE_EXEC_STACK): 
        Define as 0.
        * lib1funcs.asm [__ELF__ && __linux__]: Emit .note.GNU-stack section
        for a non-executable stack.
        * crti.asm: Likewise.
        * crtn.asm: Likewise.
        * libunwind.S: Likewise. 
........
  r118447 | brooks | 2006-11-02 17:06:26 -0800 (Thu, 02 Nov 2006) | 3 lines

  * doc/invoke.texi: Fix mfp-trap-mode typo.
........
  r118448 | pinskia | 2006-11-02 17:27:39 -0800 (Thu, 02 Nov 2006) | 8 lines

  2006-11-02  Andrew Pinski  <andrew_pinski@playstation.sony.com>

          * doc/md.texi (RS6000 constraints): Document H, Z, a, t, and W
          constraints.
........
  r118449 | geoffk | 2006-11-02 19:11:50 -0800 (Thu, 02 Nov 2006) | 9 lines

        * inclhack.def (glibc_c99_inline_1): New.
        * inclhack.def (glibc_c99_inline_2): New.
        * inclhack.def (glibc_c99_inline_3): New.
        * inclhack.def (glibc_c99_inline_4): New.
        * fixincl.x: Regenerate.
        * tests/base/bits/string2.h: New.
        * tests/base/sys/sysmacros.h: New.
        * tests/base/sys/stat.h: Update.
........
  r118450 | brooks | 2006-11-02 21:07:59 -0800 (Thu, 02 Nov 2006) | 5 lines

  * fortran/error.c (show_locus): Remove "In file" from error messages.
  * testsuite/lib/gfortran-dg.exp (gfortran-dg-test): Remove expected "In file"
from error 
  messages.
........
  r118451 | gary | 2006-11-03 02:16:04 -0800 (Fri, 03 Nov 2006) | 24 lines

  2006-11-03  Gary Benson  <gbenson@redhat.com>

        * java/net/InetAddress.java: Removed.
        * java/net/natInetAddressNoNet.cc: Likewise.
        * java/net/natInetAddressPosix.cc: Likewise.
        * java/net/natInetAddressWin32.cc: Likewise.
        * java/net/VMInetAddress.java (getLocalHostname,
        lookupInaddrAny, getHostByAddr, getHostByName,
        aton): Replace glue methods with native ones.
        * java/net/natVMInetAddressNoNet.cc: New file.
        * java/net/natVMInetAddressPosix.cc: Likewise.
        * java/net/natVMInetAddressWin32.cc: Likewise.
        * Makefile.am, configure.ac: Reflect the above.
        * sources.am, Makefile.in, configure: Rebuilt.

        * java/net/natVMNetworkInterfaceWin32.cc
        (winsock2GetRealNetworkInterfaces): Create InetAddress
        objects using InetAddress.getByAddress.
        * gnu/java/net/natPlainSocketImplWin32.cc
        (accept, getOption): Likewise.
        * gnu/java/net/natPlainDatagramSocketImplWin32.cc
        (peekData, receive, getOption): Likewise.
........
  r118452 | gary | 2006-11-03 02:16:30 -0800 (Fri, 03 Nov 2006) | 10 lines

  2006-11-03  Gary Benson  <gbenson@redhat.com>

        * java/net/Inet4Address.java
        (FAMILY): Renamed to AF_INET.
        (<init>, writeReplace): Reflect the above.
        * java/net/Inet6Address.java
        (FAMILY): Renamed to AF_INET6.
        (<init>): Reflect the above.    
........

Removed:
    branches/fixed-point/libjava/java/net/InetAddress.java
    branches/fixed-point/libjava/java/net/natInetAddressNoNet.cc
    branches/fixed-point/libjava/java/net/natInetAddressPosix.cc
    branches/fixed-point/libjava/java/net/natInetAddressWin32.cc
Modified:
    branches/fixed-point/   (props changed)
    branches/fixed-point/fixincludes/ChangeLog
    branches/fixed-point/fixincludes/fixincl.x
    branches/fixed-point/fixincludes/inclhack.def
    branches/fixed-point/fixincludes/tests/base/sys/socket.h
    branches/fixed-point/fixincludes/tests/base/sys/stat.h
    branches/fixed-point/gcc/ChangeLog
    branches/fixed-point/gcc/DATESTAMP
    branches/fixed-point/gcc/Makefile.in
    branches/fixed-point/gcc/builtins.c
    branches/fixed-point/gcc/c-common.c
    branches/fixed-point/gcc/c-common.h
    branches/fixed-point/gcc/c-cppbuiltin.c
    branches/fixed-point/gcc/c-opts.c
    branches/fixed-point/gcc/c.opt
    branches/fixed-point/gcc/config.gcc
    branches/fixed-point/gcc/config.in
    branches/fixed-point/gcc/config/arm/arm.c
    branches/fixed-point/gcc/config/arm/arm.h
    branches/fixed-point/gcc/config/arm/crti.asm
    branches/fixed-point/gcc/config/arm/crtn.asm
    branches/fixed-point/gcc/config/arm/elf.h
    branches/fixed-point/gcc/config/arm/lib1funcs.asm
    branches/fixed-point/gcc/config/arm/libunwind.S
    branches/fixed-point/gcc/config/arm/linux-elf.h
    branches/fixed-point/gcc/config/darwin.h
    branches/fixed-point/gcc/config/i386/sol2-10.h
    branches/fixed-point/gcc/config/rs6000/40x.md
    branches/fixed-point/gcc/config/rs6000/440.md
    branches/fixed-point/gcc/config/rs6000/603.md
    branches/fixed-point/gcc/config/rs6000/6xx.md
    branches/fixed-point/gcc/config/rs6000/7450.md
    branches/fixed-point/gcc/config/rs6000/7xx.md
    branches/fixed-point/gcc/config/rs6000/8540.md
    branches/fixed-point/gcc/config/rs6000/aix52.h
    branches/fixed-point/gcc/config/rs6000/linux64.h
    branches/fixed-point/gcc/config/rs6000/mpc.md
    branches/fixed-point/gcc/config/rs6000/power4.md
    branches/fixed-point/gcc/config/rs6000/power5.md
    branches/fixed-point/gcc/config/rs6000/rios1.md
    branches/fixed-point/gcc/config/rs6000/rios2.md
    branches/fixed-point/gcc/config/rs6000/rs6000-c.c
    branches/fixed-point/gcc/config/rs6000/rs6000.c
    branches/fixed-point/gcc/config/rs6000/rs6000.h
    branches/fixed-point/gcc/config/rs6000/rs6000.md
    branches/fixed-point/gcc/config/rs6000/rs6000.opt
    branches/fixed-point/gcc/config/rs6000/rs64.md
    branches/fixed-point/gcc/config/sh/sh.md
    branches/fixed-point/gcc/configure
    branches/fixed-point/gcc/configure.ac
    branches/fixed-point/gcc/doc/cpp.texi
    branches/fixed-point/gcc/doc/install.texi
    branches/fixed-point/gcc/doc/invoke.texi
    branches/fixed-point/gcc/doc/md.texi
    branches/fixed-point/gcc/except.c
    branches/fixed-point/gcc/fortran/ChangeLog
    branches/fixed-point/gcc/fortran/error.c
    branches/fixed-point/gcc/objc/ChangeLog
    branches/fixed-point/gcc/objc/objc-act.c
    branches/fixed-point/gcc/testsuite/ChangeLog
    branches/fixed-point/gcc/testsuite/g++.old-deja/g++.abi/align.C
    branches/fixed-point/gcc/testsuite/gcc.dg/fold-mod-1.c
    branches/fixed-point/gcc/testsuite/gcc.dg/pr14796-2.c
    branches/fixed-point/gcc/testsuite/gcc.dg/torture/builtin-math-3.c
    branches/fixed-point/gcc/testsuite/gcc.dg/tree-prof/val-prof-2.c
    branches/fixed-point/gcc/testsuite/lib/gfortran-dg.exp
    branches/fixed-point/gcc/testsuite/obj-c++.dg/const-str-9.mm
    branches/fixed-point/gcc/tree-pretty-print.c
    branches/fixed-point/gcc/tree-ssa.c
    branches/fixed-point/libcpp/ChangeLog
    branches/fixed-point/libcpp/include/cpplib.h
    branches/fixed-point/libcpp/init.c
    branches/fixed-point/libjava/ChangeLog
    branches/fixed-point/libjava/Makefile.am
    branches/fixed-point/libjava/Makefile.in
    branches/fixed-point/libjava/classpath/ChangeLog.gcj
    branches/fixed-point/libjava/classpath/java/net/Inet4Address.java
    branches/fixed-point/libjava/classpath/java/net/Inet6Address.java
    branches/fixed-point/libjava/configure
    branches/fixed-point/libjava/configure.ac
    branches/fixed-point/libjava/gnu/classpath/jdwp/natVMMethod.cc
   
branches/fixed-point/libjava/gnu/java/net/natPlainDatagramSocketImplWin32.cc
    branches/fixed-point/libjava/gnu/java/net/natPlainSocketImplWin32.cc
    branches/fixed-point/libjava/java/net/VMInetAddress.java
    branches/fixed-point/libjava/java/net/natVMNetworkInterfaceWin32.cc
    branches/fixed-point/libjava/jvmti.cc
    branches/fixed-point/libjava/sources.am

Propchange: branches/fixed-point/
            ('svnmerge-integrated' modified)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #35 from ghazi at gcc dot gnu dot org  2006-12-18 14:53 -------
Mine, obviously.  

Almost done, targetted to gcc-4.3.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ghazi at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
      Known to work|                            |4.3.0
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #36 from ghazi at gcc dot gnu dot org  2006-12-26 19:03 -------
Subject: Bug 29335

Author: ghazi
Date: Tue Dec 26 19:03:17 2006
New Revision: 120211

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120211
Log:
        PR middle-end/29335
        * builtins.c (do_mpfr_arg1, do_mpfr_arg2, do_mpfr_arg3,
        do_mpfr_sincos): Ensure target base equals two.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #37 from ghazi at gcc dot gnu dot org  2006-12-26 19:13 -------
Done.

Remaining functions (Bessel & lgamma) await implementation in MPFR and marked
for PR30250 & PR30251.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #38 from ghazi at gcc dot gnu dot org  2007-01-20 00:33 -------
Subject: Bug 29335

Author: ghazi
Date: Sat Jan 20 00:33:00 2007
New Revision: 120993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120993
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_1): Handle builtin fdim.

testsuite:
        * gcc.dg/torture/builtin-math-3.c: Test fdim.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

------- Comment #39 from ghazi at gcc dot gnu dot org  2007-01-31 15:06 -------
Subject: Bug 29335

Author: ghazi
Date: Wed Jan 31 15:06:19 2007
New Revision: 121423

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121423
Log:
        PR middle-end/29335
        * builtins.c (fold_builtin_sqrt): Use MPFR for constant args.

testsuite:
        * gcc.dg/torture/builtin-math-2.c: Add sqrt cases.
        * gcc.dg/torture/builtin-math-3.c: Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c
    trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #40 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Marked for reference. Resolved as fixed @bugzilla.