[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #38 from krebbel at gcc dot gnu dot org 2010-09-06 07:49 --- (In reply to comment #33) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00375.html Thanks for fixing it. And sorry for not testing it thoroughly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #39 from hjl at gcc dot gnu dot org 2010-09-06 14:54 --- Subject: Bug 45524 Author: hjl Date: Mon Sep 6 14:52:54 2010 New Revision: 163921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163921 Log: Don't set enable_decimal_float to dpd if DFP is disabled. config/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * dfp.m4: Don't set enable_decimal_float to dpd if DFP is disabled. Set default_decimal_float. gcc/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure.ac (enable_decimal_float): Set to $default_decimal_float. * configure: Regenerated. libdecnumber/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure.ac (enable_decimal_float): Set to $default_decimal_float. * configure: Regenerated. libgcc/ 2010-09-06 H.J. Lu hongjiu...@intel.com PR target/45524 * configure: Regenerated. Modified: trunk/config/ChangeLog trunk/config/dfp.m4 trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/libdecnumber/ChangeLog trunk/libdecnumber/configure trunk/libdecnumber/configure.ac trunk/libgcc/ChangeLog trunk/libgcc/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #40 from hjl dot tools at gmail dot com 2010-09-06 17:10 --- *** Bug 45561 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #41 from hjl dot tools at gmail dot com 2010-09-06 17:18 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #35 from hjl dot tools at gmail dot com 2010-09-05 15:58 --- *** Bug 45547 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #36 from dominiq at lps dot ens dot fr 2010-09-05 21:39 --- I confirm that the patch in comment #28 fixes this pr. However using the tip in comment #22, I get [macbook] gcc/p_build% grep -r decimal_ */config.log gcc/config.log:enable_decimal_float='dpd' libdecnumber/config.log:enable_decimal_float='dpd' prev-gcc/config.log:enable_decimal_float='dpd' prev-libdecnumber/config.log:enable_decimal_float='dpd' stage1-gcc/config.log:enable_decimal_float='dpd' stage1-libdecnumber/config.log:enable_decimal_float='dpd' Is there a better way to know if decimal_float has been installed or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #37 from hjl dot tools at gmail dot com 2010-09-05 22:27 --- (In reply to comment #36) I confirm that the patch in comment #28 fixes this pr. However using the tip in comment #22, I get [macbook] gcc/p_build% grep -r decimal_ */config.log gcc/config.log:enable_decimal_float='dpd' libdecnumber/config.log:enable_decimal_float='dpd' prev-gcc/config.log:enable_decimal_float='dpd' prev-libdecnumber/config.log:enable_decimal_float='dpd' stage1-gcc/config.log:enable_decimal_float='dpd' stage1-libdecnumber/config.log:enable_decimal_float='dpd' This how DFP is implemented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #15 from bonzini at gnu dot org 2010-09-04 09:08 --- Please revert the patch in both gcc and src. It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Sorry for the spotty review. :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #16 from dominiq at lps dot ens dot fr 2010-09-04 10:16 --- Could someone check that revisions 163815 and 163816 are not exposing a more serious latent bug: I have configured gcc with --enable-decimal-float=no and --disable-decimal-float without disabling -decimal-float. Are these options working on linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #17 from joseph at codesourcery dot com 2010-09-04 11:05 --- Subject: Re: r163815/r163816 produces new regressions on x86_64-apple-darwin10 On Sat, 4 Sep 2010, bonzini at gnu dot org wrote: Please revert the patch in both gcc and src. It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Sorry for the spotty review. :/ Since the differences are generally deliberate, what's actually wanted is a macro that preserves them. The basic information of which targets support DFP by default / at all and what the default format is on each target should be in a single place. The information about whether $target or $host is relevant, and about what the configuration variables should be set to if DFP is disabled, should be passed as arguments to the macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #18 from dominiq at lps dot ens dot fr 2010-09-04 11:51 --- See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #19 from davek at gcc dot gnu dot org 2010-09-04 11:54 --- (In reply to comment #18) See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. Yep, it's all the same kind of undefined symbol problems as in Jack's original description of the bug. I configured using plain --enable-decimal-float, I imagine that explicitly specifying --enable-decimal-float=bid would help. (Shall give it a try.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #20 from davek at gcc dot gnu dot org 2010-09-04 11:57 --- (In reply to comment #19) (In reply to comment #18) See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a non-darwin platform. Yep, it's all the same kind of undefined symbol problems as in Jack's original description of the bug. Note however that it's before the revision where this patch was applied, and wouldn't have shown up without my explictly adding the --enable option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-09-04 13:08 --- Index: gcc/configure.ac === --- gcc/configure.ac(revision 163853) +++ gcc/configure.ac(working copy) @@ -608,10 +608,6 @@ # Enable C extension for decimal float if target supports it. GCC_AC_ENABLE_DECIMAL_FLOAT([$target]) -dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi` -AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp, -[Define to 1 to enable decimal float extension to C.]) - bid=`if test $enable_decimal_float = bid; then echo 1; else echo 0; fi` AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_BID_FORMAT, $bid, [Define to 1 to specify that we are using the BID decimal floating Index: config/dfp.m4 === --- config/dfp.m4 (revision 163853) +++ config/dfp.m4 (working copy) @@ -30,6 +30,10 @@ esac ]) + dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi` + AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp, + [Define to 1 to enable decimal float extension to C.]) + # x86's use BID format instead of DPD case x$enable_decimal_float in xyes) @@ -50,4 +54,4 @@ esac AC_SUBST(enable_decimal_float) -]) \ No newline at end of file +]) which restore the original code sequencing, eliminates the decimal float failures on x86_64-apple-darwin10. However, I don't know what this does to linux due to the remaining differences being omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-09-04 13:39 --- I should note that one probe I am using to monitor how this builds is what grep decimal_float config.log reports in the gcc, libdecnumber and libgcc build directories. Pre-r163815/r163816, on darwin this was.. enable_decimal_float='dpd' for gcc and libdecnumber but... decimal_float='no' enable_decimal_float='no' in the libgcc build directory. With the patch in comment 21, this is changed to... decimal_float='no' enable_decimal_float='dpd' Note that this compares to what we got in libgcc with r163815/r163816 of... decimal_float='yes' enable_decimal_float='dpd' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-09-04 14:26 --- The patch in comment 21 seems to work on x86_64-unknown-linux-gnu for a stock build. Iin the libgcc build directory before and after the patch, I get... decimal_float='yes' enable_decimal_float='bid' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-09-04 14:38 --- Created an attachment (id=21695) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21695action=view) Move definition of ENABLE_DECIMAL_FLOAT to 1 into config/dfp.m4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-04 15:13 --- Created an attachment (id=21696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21696action=view) A patch Please try this one. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #21695|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-04 15:14:04 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #26 from hjl dot tools at gmail dot com 2010-09-04 15:19 --- Created an attachment (id=21697) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21697action=view) A regenerated patch I really don't like autconf cache. -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #21696|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2010-09-04 15:44 --- Both patches fail on a x86_64-apple-darwin10 bootstrap with.. make[3]: *** No rule to make target `../../gcc-4.6-20100904/gcc/../libdecnumber/no/decimal32.h', needed by `dfp.o'. Stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #28 from hjl dot tools at gmail dot com 2010-09-04 16:07 --- Created an attachment (id=21698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698action=view) A new patch Try this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-09-04 16:32 --- (In reply to comment #28) Created an attachment (id=21698) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21698action=view) [edit] A new patch Try this one. This bootstraps. Regtesting next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #30 from bonzini at gnu dot org 2010-09-04 16:41 --- It's clear that the way to go is to first write small patch to smooth out the nuances you pointed out, and then introduce the new macro in a way that doesn't change the semantics. Since the differences are generally deliberate, what's actually wanted is a macro that preserves them. Sure, I meant leaving the differences in semantics to the single configure scripts. This is what H.J.'s patch does more or less, and I like it. I'm not sure whether the patches remove the need for the other patch in comment #21 though. Jack, can you post what you are exactly testing (without the regenerated files, which are unnecessary)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #31 from howarth at nitro dot med dot uc dot edu 2010-09-04 16:58 --- (In reply to comment #30) I'm not sure whether the patches remove the need for the other patch in comment #21 though. Jack, can you post what you are exactly testing (without the regenerated files, which are unnecessary)? Testing H.J.'s gcc-pr45524-3.patch as it is the first in his series which bootstraps on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-09-04 18:12 --- I can confirm that gcc-pr45524-3.patch bootstraps and eliminates the regressions caused by r163815/r163816 on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #33 from hjl dot tools at gmail dot com 2010-09-05 03:22 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00375.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||09/msg00375.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2010-09-05 04:57 --- Regression result for gcc-pr45524-3.patch on x86_64-apple-darwin10. http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00410.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:53 --- Created an attachment (id=21688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21688action=view) gcc/config.log from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:54 --- Created an attachment (id=21689) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21689action=view) gcc/autohost.h from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:56 --- Added gcc/config.log and gcc/autohost.h files from a build on x86_64-apple-darwin10 configured with... ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-checking=yes --enable-languages=c --enable-lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-09-03 20:06 --- Looking at a build previous to r163815/r163816, I find that config.log has... enable_decimal_float='no' in the libgcc build subdirectories, but config.log shows... enable_decimal_float='dpd' everywhere else in the build tree. Now after r163815/r163816, enable_decimal_float='dpd' appears in config.log of the libgcc subdirectory as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-03 21:58 --- Okay the problem is that pre-r163815/r163816, we had in gcc/configure.ac... # x86's use BID format instead of DPD case x$enable_decimal_float in xyes) case $target in i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=bid ;; *) enable_decimal_float=dpd ;; esac ;; xno) # ENABLE_DECIMAL_FLOAT is set to 0. But we have to have proper # dependency on libdecnumber. enable_decimal_float=dpd ;; esac whereas in libgcc/configure.ac, we had a special case of just... # x86's use BID format instead of DPD if test x$enable_decimal_float = xyes; then case $host in i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=bid ;; *) enable_decimal_float=dpd ;; esac fi that did nothing in the case of enable_decimal_float=no. Our problem is that dfp.m4 is too coarse of a solution as it forces the same test to be used everywhere... # x86's use BID format instead of DPD case x$enable_decimal_float in xyes) case $target in i?86*-*-* | x86_64*-*-*) enable_decimal_float=bid ;; *) enable_decimal_float=dpd ;; esac ;; xno) # ENABLE_DECIMAL_FLOAT is set to 0. But we have to have proper # dependency on libdecnumber. enable_decimal_float=dpd ;; esac and invalidly sets enable_decimal_float=dpd for libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-09-03 22:12 --- Of course this bug impacts all non-linux targets so it should be a P1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-04 00:02 --- Apparently the configure option '--enable-decimal-float=no' is not even working: [macbook] f90/bug% gfc -v Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.4.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.6w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-decimal-float=no Thread model: posix gcc version 4.6.0 20100903 (experimental) [trunk revision 163847p4] (GCC) [macbook] gcc/build_w% grep -r enable_decimal_float */config.log gcc/config.log:enable_decimal_float='dpd' libdecnumber/config.log:enable_decimal_float='dpd' prev-gcc/config.log:enable_decimal_float='dpd' prev-libdecnumber/config.log:enable_decimal_float='dpd' stage1-gcc/config.log:enable_decimal_float='dpd' stage1-libdecnumber/config.log:enable_decimal_float='dpd' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-09-04 01:26 --- Reverting and regenerating libgcc/configure.ac is insufficient to eliminate the failures. I will try reverting both libgcc/configure.ac and libdecnumber/configure.ac next. I suspect the changes in r163815/r163816 are misguided in that it wasn't appreciated how the behavior of dfp.m4 had to be modulated for each location. This being the case, the advantage of merging these configure.ac code into a single m4 file seems nullified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-09-04
02:09 ---
To make clearer the subtleties being lost in a single dfp.m4 file, here are the
diffs of the lines replaced out of configure.ac from each location (gcc, libgcc
and libdecnumber).
--- gcc 2010-09-03 22:04:53.0 -0400
+++ libgcc 2010-09-03 22:01:16.0 -0400
@@ -11,34 +11,26 @@
esac
],
[
- case $target in
+ case $host in
powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*)
enable_decimal_float=yes
;;
*)
- AC_MSG_WARN(decimal float is not supported for this target, ignored)
enable_decimal_float=no
;;
esac
])
+
# x86's use BID format instead of DPD
-case x$enable_decimal_float in
- xyes)
-case $target in
- i?86*-*-linux* | x86_64*-*-linux*)
-enable_decimal_float=bid
-;;
- *)
-enable_decimal_float=dpd
-;;
-esac
-;;
- xno)
-# ENABLE_DECIMAL_FLOAT is set to 0. But we have to have proper
-# dependency on libdecnumber.
-enable_decimal_float=dpd
-;;
-esac
+if test x$enable_decimal_float = xyes; then
+ case $host in
+i?86*-*-linux* | x86_64*-*-linux*)
+ enable_decimal_float=bid
+ ;;
+*)
+ enable_decimal_float=dpd
+ ;;
+ esac
+fi
AC_SUBST(enable_decimal_float)
-
--- gcc 2010-09-03 22:04:53.0 -0400
+++ libdecnumber2010-09-03 21:59:43.0 -0400
@@ -1,3 +1,6 @@
+# Default decimal format
+# If you change the defaults here, be sure to change them in the GCC directory
also
+AC_MSG_CHECKING([for decimal floating point])
AC_ARG_ENABLE(decimal-float,
[ --enable-decimal-float={no,yes,bid,dpd}
enable decimal float extension to C. Selecting 'bid'
@@ -16,29 +19,22 @@
enable_decimal_float=yes
;;
*)
- AC_MSG_WARN(decimal float is not supported for this target, ignored)
enable_decimal_float=no
;;
esac
])
-# x86's use BID format instead of DPD
-case x$enable_decimal_float in
- xyes)
-case $target in
- i?86*-*-linux* | x86_64*-*-linux*)
-enable_decimal_float=bid
-;;
- *)
-enable_decimal_float=dpd
-;;
-esac
-;;
- xno)
-# ENABLE_DECIMAL_FLOAT is set to 0. But we have to have proper
-# dependency on libdecnumber.
-enable_decimal_float=dpd
-;;
-esac
-AC_SUBST(enable_decimal_float)
+# 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
+ ;;
+*)
+ enable_decimal_float=dpd
+ ;;
+ esac
+fi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-04 02:13 --- (In reply to comment #9) --- gcc 2010-09-03 22:04:53.0 -0400 +++ libgcc 2010-09-03 22:01:16.0 -0400 @@ -11,34 +11,26 @@ esac ], [ - case $target in + case $host in This is correct as libgcc is a target library so the host there is what we originally had as the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-09-04 02:27 --- I am not worried about $host vs $target but rather the nuances in the xno case for x$enable_decimal_float in the original code. For gcc/configure.ac, this sets... enable_decimal_float=dpd but that case is not handled in gcc/configure.ac. Likewise comparing gcc/configure.ac to libdecnumber.ac,that case is also ignored but there also is a wrapping test around the entire case statement of... if test x$enable_decimal_float = xyes -o x$enable_decimal_float = xno; then these subtleties have not been extended into dfp.m4 nor has the underlying reason for them been addressed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-09-04 02:28 --- (In reply to comment #11) but that case is not handled in gcc/configure.ac. Likewise comparing but that case is not handled in libgcc/configure.ac. Likewise comparing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-09-04 03:39 --- Reverting both libgcc/configure.ac and libdecnumber/configure.ac and regenerating these files is insufficient as well to eliminate the regressions on darwin. Looking at the remaining changes in gcc/configure.ac it is obvious way this change badly breaks non-linux targets. http://gcc.gnu.org/viewcvs/trunk/gcc/configure.ac?r1=163815r2=163814pathrev=163815 The author cut out two sections from gcc/configure.ac and pasted them together in dfp.m4. The intervening section... dfp=`if test $enable_decimal_float != no; then echo 1; else echo 0; fi` AC_DEFINE_UNQUOTED(ENABLE_DECIMAL_FLOAT, $dfp, [Define to 1 to enable decimal float extension to C.]) is now moved to the end, breaking the original logic. This is without even considering the other subtleties in the same code from libgcc/configure.ac and libdecnumber/configure.ac that has been simply ignored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-09-04 05:21 --- The original patch introduce this minor variations in the code copied for dfp.m4 in the gcc/configure.ac, libgcc/configure.ac and libdecnumber.ac is found here... http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01608.html and committed here... http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00776.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
