public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
[not found] <bug-29335-4@http.gcc.gnu.org/bugzilla/>
@ 2014-02-16 10:00 ` jackie.rosen at hushmail dot com
0 siblings, 0 replies; 41+ messages in thread
From: jackie.rosen at hushmail dot com @ 2014-02-16 10:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (38 preceding siblings ...)
2007-01-20 0:33 ` ghazi at gcc dot gnu dot org
@ 2007-01-31 15:06 ` ghazi at gcc dot gnu dot org
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2007-01-31 15:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (37 preceding siblings ...)
2006-12-26 19:13 ` ghazi at gcc dot gnu dot org
@ 2007-01-20 0:33 ` ghazi at gcc dot gnu dot org
2007-01-31 15:06 ` ghazi at gcc dot gnu dot org
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2007-01-20 0:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (36 preceding siblings ...)
2006-12-26 19:03 ` ghazi at gcc dot gnu dot org
@ 2006-12-26 19:13 ` ghazi at gcc dot gnu dot org
2007-01-20 0:33 ` ghazi at gcc dot gnu dot org
2007-01-31 15:06 ` ghazi at gcc dot gnu dot org
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-12-26 19:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (35 preceding siblings ...)
2006-12-18 14:54 ` ghazi at gcc dot gnu dot org
@ 2006-12-26 19:03 ` ghazi at gcc dot gnu dot org
2006-12-26 19:13 ` ghazi at gcc dot gnu dot org
` (2 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-12-26 19:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (34 preceding siblings ...)
2006-11-30 19:45 ` chaoyingfu at gcc dot gnu dot org
@ 2006-12-18 14:54 ` ghazi at gcc dot gnu dot org
2006-12-26 19:03 ` ghazi at gcc dot gnu dot org
` (3 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-12-18 14:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (33 preceding siblings ...)
2006-11-07 2:46 ` ghazi at gcc dot gnu dot org
@ 2006-11-30 19:45 ` chaoyingfu at gcc dot gnu dot org
2006-12-18 14:54 ` ghazi at gcc dot gnu dot org
` (4 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: chaoyingfu at gcc dot gnu dot org @ 2006-11-30 19:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (32 preceding siblings ...)
2006-11-05 23:27 ` vincent at vinc17 dot org
@ 2006-11-07 2:46 ` ghazi at gcc dot gnu dot org
2006-11-30 19:45 ` chaoyingfu at gcc dot gnu dot org
` (5 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-11-07 2:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (31 preceding siblings ...)
2006-11-02 22:44 ` ghazi at gcc dot gnu dot org
@ 2006-11-05 23:27 ` vincent at vinc17 dot org
2006-11-07 2:46 ` ghazi at gcc dot gnu dot org
` (6 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-11-05 23:27 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (30 preceding siblings ...)
2006-11-02 15:57 ` vincent at vinc17 dot org
@ 2006-11-02 22:44 ` ghazi at gcc dot gnu dot org
2006-11-05 23:27 ` vincent at vinc17 dot org
` (7 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-11-02 22:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (29 preceding siblings ...)
2006-11-02 14:41 ` ghazi at gcc dot gnu dot org
@ 2006-11-02 15:57 ` vincent at vinc17 dot org
2006-11-02 22:44 ` ghazi at gcc dot gnu dot org
` (8 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-11-02 15:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (28 preceding siblings ...)
2006-11-02 3:21 ` ghazi at gcc dot gnu dot org
@ 2006-11-02 14:41 ` ghazi at gcc dot gnu dot org
2006-11-02 15:57 ` vincent at vinc17 dot org
` (9 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-11-02 14:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (27 preceding siblings ...)
2006-10-31 22:15 ` vincent at vinc17 dot org
@ 2006-11-02 3:21 ` ghazi at gcc dot gnu dot org
2006-11-02 14:41 ` ghazi at gcc dot gnu dot org
` (10 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-11-02 3:21 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (26 preceding siblings ...)
2006-10-31 20:09 ` ghazi at gcc dot gnu dot org
@ 2006-10-31 22:15 ` vincent at vinc17 dot org
2006-11-02 3:21 ` ghazi at gcc dot gnu dot org
` (11 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-10-31 22:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (25 preceding siblings ...)
2006-10-31 9:55 ` vincent at vinc17 dot org
@ 2006-10-31 20:09 ` ghazi at gcc dot gnu dot org
2006-10-31 22:15 ` vincent at vinc17 dot org
` (12 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-31 20:09 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (24 preceding siblings ...)
2006-10-31 3:14 ` ghazi at gcc dot gnu dot org
@ 2006-10-31 9:55 ` vincent at vinc17 dot org
2006-10-31 20:09 ` ghazi at gcc dot gnu dot org
` (13 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-10-31 9:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (23 preceding siblings ...)
2006-10-30 20:22 ` ghazi at gcc dot gnu dot org
@ 2006-10-31 3:14 ` ghazi at gcc dot gnu dot org
2006-10-31 9:55 ` vincent at vinc17 dot org
` (14 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-31 3:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (22 preceding siblings ...)
2006-10-29 2:02 ` ghazi at gcc dot gnu dot org
@ 2006-10-30 20:22 ` ghazi at gcc dot gnu dot org
2006-10-31 3:14 ` ghazi at gcc dot gnu dot org
` (15 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-30 20:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (21 preceding siblings ...)
2006-10-28 16:58 ` vincent at vinc17 dot org
@ 2006-10-29 2:02 ` ghazi at gcc dot gnu dot org
2006-10-30 20:22 ` ghazi at gcc dot gnu dot org
` (16 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-29 2:02 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (20 preceding siblings ...)
2006-10-28 16:04 ` ghazi at gcc dot gnu dot org
@ 2006-10-28 16:58 ` vincent at vinc17 dot org
2006-10-29 2:02 ` ghazi at gcc dot gnu dot org
` (17 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-10-28 16:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (19 preceding siblings ...)
2006-10-28 14:06 ` vincent at vinc17 dot org
@ 2006-10-28 16:04 ` ghazi at gcc dot gnu dot org
2006-10-28 16:58 ` vincent at vinc17 dot org
` (18 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-28 16:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (18 preceding siblings ...)
2006-10-28 13:29 ` ghazi at gcc dot gnu dot org
@ 2006-10-28 14:06 ` vincent at vinc17 dot org
2006-10-28 16:04 ` ghazi at gcc dot gnu dot org
` (19 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-10-28 14:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (17 preceding siblings ...)
2006-10-28 9:07 ` vincent at vinc17 dot org
@ 2006-10-28 13:29 ` ghazi at gcc dot gnu dot org
2006-10-28 14:06 ` vincent at vinc17 dot org
` (20 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-28 13:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (16 preceding siblings ...)
2006-10-28 3:48 ` sgk at troutmask dot apl dot washington dot edu
@ 2006-10-28 9:07 ` vincent at vinc17 dot org
2006-10-28 13:29 ` ghazi at gcc dot gnu dot org
` (21 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: vincent at vinc17 dot org @ 2006-10-28 9:07 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (15 preceding siblings ...)
2006-10-28 3:20 ` ghazi at gcc dot gnu dot org
@ 2006-10-28 3:48 ` sgk at troutmask dot apl dot washington dot edu
2006-10-28 9:07 ` vincent at vinc17 dot org
` (22 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2006-10-28 3:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (14 preceding siblings ...)
2006-10-25 20:44 ` ghazi at gcc dot gnu dot org
@ 2006-10-28 3:20 ` ghazi at gcc dot gnu dot org
2006-10-28 3:48 ` sgk at troutmask dot apl dot washington dot edu
` (23 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-28 3:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (13 preceding siblings ...)
2006-10-24 17:45 ` ghazi at gcc dot gnu dot org
@ 2006-10-25 20:44 ` ghazi at gcc dot gnu dot org
2006-10-28 3:20 ` ghazi at gcc dot gnu dot org
` (24 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-25 20:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (12 preceding siblings ...)
2006-10-23 20:25 ` ghazi at gcc dot gnu dot org
@ 2006-10-24 17:45 ` ghazi at gcc dot gnu dot org
2006-10-25 20:44 ` ghazi at gcc dot gnu dot org
` (25 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-24 17:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (11 preceding siblings ...)
2006-10-20 15:54 ` ghazi at gcc dot gnu dot org
@ 2006-10-23 20:25 ` ghazi at gcc dot gnu dot org
2006-10-24 17:45 ` ghazi at gcc dot gnu dot org
` (26 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-23 20:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (10 preceding siblings ...)
2006-10-14 16:14 ` ghazi at gcc dot gnu dot org
@ 2006-10-20 15:54 ` ghazi at gcc dot gnu dot org
2006-10-23 20:25 ` ghazi at gcc dot gnu dot org
` (27 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-20 15:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (9 preceding siblings ...)
2006-10-14 16:12 ` ghazi at gcc dot gnu dot org
@ 2006-10-14 16:14 ` ghazi at gcc dot gnu dot org
2006-10-20 15:54 ` ghazi at gcc dot gnu dot org
` (28 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-14 16:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (8 preceding siblings ...)
2006-10-09 17:16 ` ghazi at gcc dot gnu dot org
@ 2006-10-14 16:12 ` ghazi at gcc dot gnu dot org
2006-10-14 16:14 ` ghazi at gcc dot gnu dot org
` (29 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-14 16:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (7 preceding siblings ...)
2006-10-07 14:08 ` ghazi at gcc dot gnu dot org
@ 2006-10-09 17:16 ` ghazi at gcc dot gnu dot org
2006-10-14 16:12 ` ghazi at gcc dot gnu dot org
` (30 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-09 17:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (6 preceding siblings ...)
2006-10-07 2:05 ` ghazi at gcc dot gnu dot org
@ 2006-10-07 14:08 ` ghazi at gcc dot gnu dot org
2006-10-09 17:16 ` ghazi at gcc dot gnu dot org
` (31 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-07 14:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (5 preceding siblings ...)
2006-10-06 17:03 ` kargl at gcc dot gnu dot org
@ 2006-10-07 2:05 ` ghazi at gcc dot gnu dot org
2006-10-07 14:08 ` ghazi at gcc dot gnu dot org
` (32 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-07 2:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (4 preceding siblings ...)
2006-10-06 15:36 ` ghazi at gcc dot gnu dot org
@ 2006-10-06 17:03 ` kargl at gcc dot gnu dot org
2006-10-07 2:05 ` ghazi at gcc dot gnu dot org
` (33 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: kargl at gcc dot gnu dot org @ 2006-10-06 17:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (3 preceding siblings ...)
2006-10-06 14:40 ` kargl at gcc dot gnu dot org
@ 2006-10-06 15:36 ` ghazi at gcc dot gnu dot org
2006-10-06 17:03 ` kargl at gcc dot gnu dot org
` (34 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-06 15:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
` (2 preceding siblings ...)
2006-10-06 13:25 ` ghazi at gcc dot gnu dot org
@ 2006-10-06 14:40 ` kargl at gcc dot gnu dot org
2006-10-06 15:36 ` ghazi at gcc dot gnu dot org
` (35 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: kargl at gcc dot gnu dot org @ 2006-10-06 14:40 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
2006-10-05 5:11 ` [Bug middle-end/29335] " pinskia at gcc dot gnu dot org
2006-10-05 17:54 ` kargl at gcc dot gnu dot org
@ 2006-10-06 13:25 ` ghazi at gcc dot gnu dot org
2006-10-06 14:40 ` kargl at gcc dot gnu dot org
` (36 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: ghazi at gcc dot gnu dot org @ 2006-10-06 13:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
2006-10-05 5:11 ` [Bug middle-end/29335] " pinskia at gcc dot gnu dot org
@ 2006-10-05 17:54 ` kargl at gcc dot gnu dot org
2006-10-06 13:25 ` ghazi at gcc dot gnu dot org
` (37 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: kargl at gcc dot gnu dot org @ 2006-10-05 17:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
* [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
@ 2006-10-05 5:11 ` pinskia at gcc dot gnu dot org
2006-10-05 17:54 ` kargl at gcc dot gnu dot org
` (38 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-10-05 5:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2014-02-16 10:00 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-29335-4@http.gcc.gnu.org/bugzilla/>
2014-02-16 10:00 ` [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time jackie.rosen at hushmail dot com
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
2006-10-05 5:11 ` [Bug middle-end/29335] " pinskia at gcc dot gnu dot org
2006-10-05 17:54 ` kargl at gcc dot gnu dot org
2006-10-06 13:25 ` ghazi at gcc dot gnu dot org
2006-10-06 14:40 ` kargl at gcc dot gnu dot org
2006-10-06 15:36 ` ghazi at gcc dot gnu dot org
2006-10-06 17:03 ` kargl at gcc dot gnu dot org
2006-10-07 2:05 ` ghazi at gcc dot gnu dot org
2006-10-07 14:08 ` ghazi at gcc dot gnu dot org
2006-10-09 17:16 ` ghazi at gcc dot gnu dot org
2006-10-14 16:12 ` ghazi at gcc dot gnu dot org
2006-10-14 16:14 ` ghazi at gcc dot gnu dot org
2006-10-20 15:54 ` ghazi at gcc dot gnu dot org
2006-10-23 20:25 ` ghazi at gcc dot gnu dot org
2006-10-24 17:45 ` ghazi at gcc dot gnu dot org
2006-10-25 20:44 ` ghazi at gcc dot gnu dot org
2006-10-28 3:20 ` ghazi at gcc dot gnu dot org
2006-10-28 3:48 ` sgk at troutmask dot apl dot washington dot edu
2006-10-28 9:07 ` vincent at vinc17 dot org
2006-10-28 13:29 ` ghazi at gcc dot gnu dot org
2006-10-28 14:06 ` vincent at vinc17 dot org
2006-10-28 16:04 ` ghazi at gcc dot gnu dot org
2006-10-28 16:58 ` vincent at vinc17 dot org
2006-10-29 2:02 ` ghazi at gcc dot gnu dot org
2006-10-30 20:22 ` ghazi at gcc dot gnu dot org
2006-10-31 3:14 ` ghazi at gcc dot gnu dot org
2006-10-31 9:55 ` vincent at vinc17 dot org
2006-10-31 20:09 ` ghazi at gcc dot gnu dot org
2006-10-31 22:15 ` vincent at vinc17 dot org
2006-11-02 3:21 ` ghazi at gcc dot gnu dot org
2006-11-02 14:41 ` ghazi at gcc dot gnu dot org
2006-11-02 15:57 ` vincent at vinc17 dot org
2006-11-02 22:44 ` ghazi at gcc dot gnu dot org
2006-11-05 23:27 ` vincent at vinc17 dot org
2006-11-07 2:46 ` ghazi at gcc dot gnu dot org
2006-11-30 19:45 ` chaoyingfu at gcc dot gnu dot org
2006-12-18 14:54 ` ghazi at gcc dot gnu dot org
2006-12-26 19:03 ` ghazi at gcc dot gnu dot org
2006-12-26 19:13 ` ghazi at gcc dot gnu dot org
2007-01-20 0:33 ` ghazi at gcc dot gnu dot org
2007-01-31 15:06 ` ghazi at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).