[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #12 from joseph at codesourcery dot com 2008-06-24 12:36
---
Subject: Re: pulls in allegedly unneeded floatingpoint
exception access funcs
On Tue, 24 Jun 2008, aldot at gcc dot gnu dot org wrote:
> libdecnumber hunk could look like this:
libdecnumber's configure.ac is for the host, not the target. As such, it
needs to remain in sync with gcc's. I'm pretty sure it's deliberate that
it still needs to select a format even with --disable-decimal-float.
The logic selecting for the target is in libgcc/configure.ac. That's the
only place disabling without might make sense (and if an explicit
--enable-decimal-float={yes,bid,dpd} is given without , give an
error). The only reason this really makes sense is that you can
legitimately have both glibc and uClibc multilibs, some with and
some without, and libgcc's configure is run once for each multilib.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #11 from aldot at gcc dot gnu dot org 2008-06-24 11:21 --- libdecnumber hunk could look like this: Index: libdecnumber/configure.ac === --- libdecnumber/configure.ac (revision 137059) +++ libdecnumber/configure.ac (working copy) @@ -49,6 +49,7 @@ ACX_PROG_CC_WARNINGS_ARE_ERRORS([manual] # Checks for header files. AC_CHECK_HEADERS(ctype.h stddef.h string.h stdio.h) +AC_CHECK_HEADER([fenv.h],[],[libdecnumber_cv_fenv=no]) GCC_HEADER_STDINT(gstdint.h) # Checks for typedefs, structures, and compiler characteristics. @@ -99,10 +100,13 @@ Valid choices are 'yes', 'bid', 'dpd', a esac ]) +if test x$libdecnumber_cv_fenv = xno; then + enable_decimal_float=no +elif test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then # x86's use BID format instead of DPD # In theory --enable-decimal-float=no should not compile anything # For the sake of simplicity, just use the default format in this directory -if test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then + case $target in i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=bid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #10 from aldot at gcc dot gnu dot org 2008-06-24 11:19 --- (In reply to comment #9) > DFP needs floating point exception support. If your C library doesn't > support it, you can disable DFP. libdecnumber's configury should thus check whether fenv.h is available or not and default to no if no fenv.h was found. Looks like the enable_decimal_float handling is duplicated both in gcc/configure.ac as well as libdecnumber/configure.ac. Is there a reason for this duplication or is it pure oversight? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #9 from hjl dot tools at gmail dot com 2008-03-14 01:17 --- DFP needs floating point exception support. If your C library doesn't support it, you can disable DFP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-19 21:38 ---
>From FSFChangelog.10:
Mon Feb 12 20:42:11 1996 Randy Smith <[EMAIL PROTECTED]>
* i386/x-osfrose (XCFLAGS{,_NODEBUG}): Remove $(SHLIB).
(XCFLAGS): New variable.
(libdir, mandir, bindir): Delete.
* i386/t-osf: New file.
* i860/paragon.h (STARTFILE_SPEC): Make gcc find crt0.o, not loader.
(LIB_SPEC): Remove /usr/lib.
* Makefile.in (TCFLAGS): New variable.
(GCC_CFLAGS): Add $(TCFLAGS).
(LIBGCC2_CFLAGS): Add -D for __GCC_FLOAT_NOT_NEEDED.
(libgcc1-test): Remove -nostdlib.
(float.h-cross): Don't give error #ifdef __GCC_FLOAT_NOT_NEEDED.
* enquire.c: Define __GCC_FLOAT_NOT_NEEEDED.
* configure (i[3456]86-*-osfrose): Add t-osf as tmake_file.
Nowadays we compile libgcc with it (for the very same reasons, i suspect):
[from gcc/Makefile.in]
# Options to use when compiling libgcc2.a.
#
LIBGCC2_DEBUG_CFLAGS = -g
LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS)
\
$(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \
$(INHIBIT_LIBC_CFLAGS)
Current trunk still fails of you don't have a fenv.h or none of the respective
functions provided in fenv.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #7 from ubizjak at gmail dot com 2008-01-18 11:54 --- Sorry, wrong PR number in the ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-18 09:56 --- Subject: Bug 34484 Author: uros Date: Fri Jan 18 09:55:15 2008 New Revision: 131626 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131626 Log: PR debug/34484 * dwarf2out.c (dwarf2out_switch_text_section): Do not guard with DWARF2_DEBUGGING_INFO. (dwarf2out_note_section_used): Ditto. Add prototype. (have_multiple_function_sections, text_section_used, cold_text_section_used, *cold_text_sections): Move declarations before their uses. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #5 from hjl at lucon dot org 2007-12-27 16:56 --- Any update on this? -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #4 from hjl at lucon dot org 2007-12-15 22:05 --- Where is __GCC_FLOAT_NOT_NEEDED documented? Is this a supported gcc macro? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-15 20:22 --- Even then you have to have some kind of fp support for GCC to work correctly. Even if it is soft fp. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i386-pc-linux-uclibc|*-pc-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #2 from aldot at gcc dot gnu dot org 2007-12-15 20:15 --- IIRC i initially experienced this not on i386 but with mips or arm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-15 20:07 --- Note it is unusual to disable fp support for x86. So really I think it is a bug that you can disable it. Actually I think we should declare this as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i386-pc-linux-gnu |i386-pc-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target GCC target triplet||i386-pc-linux-gnu Summary|[4.3 Regression] pulls in |pulls in allegedly unneeded |allegedly unneeded |floatingpoint exception |floatingpoint exception |access funcs |access funcs| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
