Re: Some regressions from the dataflow merge
On Wed, 13 Jun 2007, Kenneth Zadeck wrote: > Richard Guenther wrote: > > On Tue, 12 Jun 2007, Richard Guenther wrote: > > > > > >> On ia64 SPEC2000 I see fma3d and applu now miscompare. > >> > > > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: > > > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o > > zscal.o-fprofile-use -O2 -ffast-math zscal.f > > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> > > fdo_make_pass2.err | tee fdo_make_pass2.out': > > zgemm.f: In function 'zgemm': > > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > Likewise for 176.gcc: > > > > combine.c: In function 'simplify_comparison': > > combine.c:9697: internal compiler error: in remove_insn, at > > emit-rtl.c:3597 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > specmake: *** [combine.o] Error 1 > > > > Richard. > > > Richard, > > did these two regression go away? We committed a change to gcse that > should have fixed this bug. These two are gone now. The ia64 miscompares still are there. Richard.
Bootstrap failure on trunk
Hi, between r125680 and r125703 bootstrap is broken on trunk for at least i686-pc-liunx-gnu. checking whether gcc supports -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings... no configure: error: unknown check category release,yes make[2]: *** [configure-stage1-gcc] Error 1 make[2]: Leaving directory `/home/xtv/gcc-devel/out' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/xtv/gcc-devel/out' make: *** [bootstrap] Error 2 According to ChangeLog the configure-Scripts have been regenerated, maybe this is the reason for the failure.. 2007-06-14 Paolo Bonzini <[EMAIL PROTECTED]> * acinclude.m4 (gcc_AC_CHECK_PROG_VER): Remove. * aclocal.m4: Regenerate. * configure.ac: Use ACX_PROG_CC_WARNING_OPTS, ACX_PROG_CC_WARNINGS_ARE_ERRORS, ACX_PROG_CC_WARNING_ALMOST_PEDANTIC, ACX_CHECK_PROG_VER. * configure: Regenerate. Best regards, Thomas
Ian Taylor appoined non-algorithmic GWP
I am pleased to announce that the GCC Steering Committee has appointed Ian Taylor as non-algorithmic Blanket/Global Write Privileges maintainer. Please join me in congratulating Ian on his new role. Please update your listings in the MAINTAINERS file. Happy hacking! David
Diego Novillo appointed middle-end maintainer and non-algorithmic GWP
I am pleased to announce that the GCC Steering Committee has promoted Diego Novillo to middle-end maintainer and appointed him non-algorithmic Blanket/Global Write Privileges maintainer. Please join me in congratulating Diego on his new role. Please update your listings in the MAINTAINERS file. Happy hacking! David
r125698 breaks bootstrap on trunk for i686-pc-linux-gnu
Hi *, binary search revealed that r125698 breaks bootstrap on trunk for i686-pc-linux-gnu. Best regards, Thomas
[PATCH] Fix breakage
Sorry, I committed the wrong version of the patch.
2007-06-14 Paolo Bonzini <[EMAIL PROTECTED]>
* configure.ac: Fix earlier checkin.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revision 125700)
+++ configure.ac(working copy)
@@ -358,7 +358,7 @@ else
ac_checking_flags=release
fi])
IFS="${IFS=}"; ac_save_IFS="$IFS"; IFS="$IFS,"
-for check in release,$ac_checking_flags
+for check in release $ac_checking_flags
do
case $check in
# these set all the flags to specific states
Re: Diego Novillo appointed middle-end maintainer and non-algorithmic GWP
On 6/14/07 6:37 AM, David Edelsohn wrote: > Please update your listings in the MAINTAINERS file. Thanks. Committed. * MAINTAINERS: Add self as middle-end maintainer and non-algorithmic global write maintainer. Index: MAINTAINERS === --- MAINTAINERS (revision 125706) +++ MAINTAINERS (working copy) @@ -192,6 +192,7 @@ testsuite Janis Johnson [EMAIL PROTECTED] middle-end Roger Sayle [EMAIL PROTECTED] middle-end Ian Lance Taylor[EMAIL PROTECTED] +middle-end Diego Novillo [EMAIL PROTECTED] tree-ssa Diego Novillo [EMAIL PROTECTED] tree-ssa Andrew MacLeod [EMAIL PROTECTED] PREDaniel Berlin [EMAIL PROTECTED] @@ -221,6 +222,7 @@ loop optimizer Daniel Berlin [EMAIL PROTECTED] middle-end Richard Guenther[EMAIL PROTECTED] libcpp Tom Tromey [EMAIL PROTECTED] +blanket write Diego Novillo [EMAIL PROTECTED] Note that individuals who maintain parts of the compiler as non-algorithmic maintainers need approval to check in algorithmic changes or changes
Re: maybe configure.ac problem ?
Basile STARYNKEVITCH wrote:
Hello all,
While trying to compile the trunk gcc (svn rev 125703) on my
Debian/Sid/AMD64, I got the following problem,
Sorry for the noise. This is being discussed on the gcc-patch list.
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00940.html
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00958.html
Regards with my apologies!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
maybe configure.ac problem ?
Hello all,
While trying to compile the trunk gcc (svn rev 125703) on my
Debian/Sid/AMD64, I got the following problem, which happens even when
configuring in an empty build directory _Obj/
cd /usr/src/Lang/gcc-trunk/_Obj
/usr/src/Lang/gcc-trunk/configure '--disable-multilib'
'--program-suffix=-snap' '--enable-maintainer-mode'
'--enable-languages=c,c++'
checking size of long long... 8
checking for __int64... no
checking whether gcc supports -W... yes
checking whether gcc supports -Wall... yes
checking whether gcc supports -Wwrite-strings... yes
checking whether gcc supports -Wstrict-prototypes... yes
checking whether gcc supports -Wmissing-prototypes... yes
checking whether gcc supports -Wc++-compat... yes
checking whether gcc supports -Wold-style-definition... yes
checking whether gcc supports -Wmissing-format-attribute... yes
checking whether gcc supports -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings... no
configure: error: unknown check category release,yes
make[2]: *** [configure-stage1-gcc] Error 1
make[2]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make: *** [all] Error 2
This could be related to the IFS setting in gcc/configure.ac near line 360
my bash version is GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu)
my autoconf version is autoconf (GNU Autoconf) 2.61
Am I the only one to experiment this?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
How to submit Intel BID library patch?
We are ready to submit a patch for Intel BID library. We have 3 small patches and a 2.4MB bz2 tar file for Intel BID library itself. I can 1. Send a 2.4MB bz2 tar file to gcc-patches. 2. Create a bid branch in svn. 3. Put it on kernel.org. Which one is preferred? With Intel BID library, we got 2 failures in unmodified DFP tests, fe-convert-1.c and fe-convert-2.c, due to different exceptions in Intel BID library vs. libdecnumber. The differences are 1. When the input value is larger than the max value that fits in the destination format, it means overflow. In this case the IEEE 754R draft specifies that both overflow and inexact exceptions should be signaled. These are CONVERT (101, d64, d32, 10.00e96DD, FE_INEXACT) CONVERT (111, d128, d32, 10.00e96DL, FE_INEXACT) CONVERT (121, d128, d64, 10.00E384DL, FE_INEXACT) in testsuite/gcc.dg/dfp/fe-convert-1.c. Libdecnumber doesn't signal overflow and Intel BID library does. We believe Intel BID library is correct. 2. For CONVERT (100, d, d32, 1.0e96, 0) CONVERT (102, d, d32, -1.0e96, 0) in testsuite/gcc.dg/dfp/fe-convert-2.c. They expect the conversion results to be exact. This is not correct. The input value 1.0e96 (or -1.0e96) is assigned the double precision value d. But this is not representable exactly as a double precision value, so what we store in d is an approximation of 1.0e96. The hex value for 1e96 is 0x77d9d58b62cd8a5162e7f4a779f5080f1c46d01ae478b23be1178e81 which does not fit in the 53-bit significand of a double. So when the value stored in x, the value in x is really 149861653971908893017010268485438462151574892930611988399099305815384459015356416 This is close to 10^96, but not exactly 10^96. So the conversion of this double to _Decimal32 is inexact (the result is indeed 10^96). Intel BID library will signal FE_INEXACT in both cases. Also Intel BID library passes those tests: #if 0 /* These should result in fp exceptions but don't. */ CONVERT (xxx, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT) CONVERT (xxx, d, d32, 0.00048828125, FE_INEXACT) /* exact power of 2 */ #endif in testsuite/gcc.dg/dfp/fe-convert-2.c. I'd like to enable them at least for Intel BID library. I am enclosing the DFP testsuite modifications here. Should I condition all those changes based on __DECIMAL_BID_FORMAT__? H.J. 2007-06-14 H.J. Lu <[EMAIL PROTECTED]> * gcc.dg/dfp/fe-convert-1.c: Expect FE_OVERFLOW when converting from 10.00e96DD to _Decimal32, from 10.00e96DL to _Decimal32 and from 10.00E384DL to _Decimal64. * gcc.dg/dfp/fe-convert-2.c: Expect FE_INEXACT when converting from 1.0e96 and -1.0e96 to _Decimal32. Enable testing for converting from 1.0e-96 and 0.00048828125 to _Decimal32 when BID is used. --- gcc/testsuite/gcc.dg/dfp/fe-convert-1.c.dfp-test2007-05-25 17:42:57.0 -0700 +++ gcc/testsuite/gcc.dg/dfp/fe-convert-1.c 2007-06-13 22:47:36.0 -0700 @@ -14,13 +14,13 @@ volatile _Decimal128 d128; is too large or the result can't hold the full precision. */ CONVERT (100, d64, d32, 9.99e96DD, 0) -CONVERT (101, d64, d32, 10.00e96DD, FE_INEXACT) +CONVERT (101, d64, d32, 10.00e96DD, FE_INEXACT|FE_OVERFLOW) CONVERT (102, d64, d32, 1.111DD, FE_INEXACT) CONVERT (110, d128, d32, 9.99e96DL, 0) -CONVERT (111, d128, d32, 10.00e96DL, FE_INEXACT) +CONVERT (111, d128, d32, 10.00e96DL, FE_INEXACT|FE_OVERFLOW) CONVERT (112, d128, d32, 1.111DL, FE_INEXACT) CONVERT (120, d128, d64, 9.999E384DL, 0) -CONVERT (121, d128, d64, 10.00E384DL, FE_INEXACT) +CONVERT (121, d128, d64, 10.00E384DL, FE_INEXACT|FE_OVERFLOW) CONVERT (122, d128, d64, 1.DL, FE_INEXACT) int --- gcc/testsuite/gcc.dg/dfp/fe-convert-2.c.dfp-test2007-05-25 17:42:57.0 -0700 +++ gcc/testsuite/gcc.dg/dfp/fe-convert-2.c 2007-06-13 22:47:36.0 -0700 @@ -9,15 +9,15 @@ volatile _Decimal32 d32; volatile double d; -CONVERT (100, d, d32, 1.0e96, 0) +CONVERT (100, d, d32, 1.0e96, FE_INEXACT) CONVERT (101, d, d32, 1.0e97, FE_OVERFLOW|FE_INEXACT) -CONVERT (102, d, d32, -1.0e96, 0) +CONVERT (102, d, d32, -1.0e96, FE_INEXACT) CONVERT (103, d, d32, -1.0e97, FE_OVERFLOW|FE_INEXACT) -#if 0 -/* These should result in fp exceptions but don't. */ -CONVERT (xxx, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT) -CONVERT (xxx, d, d32, 0.00048828125, FE_INEXACT) /* exact power of 2 */ +#ifdef __DECIMAL_BID_FORMAT__ +/* These only result in fp exceptions with BID. DPD doesn't work. */ +CONVERT (104, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT) +CONVERT (105, d, d32, 0.00048828125, FE_INEXACT) /* exact power of 2 */ #endif int @@ -27,6 +27,10 @@ main () convert_101 (); convert_102 (); convert_103 (); +#ifdef __DECIMAL_BID_FORMAT__ + convert_104 (); + convert_105 (); +#endif if (failcnt != 0) abort ();
Re: Ian Taylor appoined non-algorithmic GWP
David Edelsohn <[EMAIL PROTECTED]> writes: > I am pleased to announce that the GCC Steering Committee has > appointed Ian Taylor as non-algorithmic Blanket/Global Write Privileges > maintainer. > > Please join me in congratulating Ian on his > new role. Please update your listings in the MAINTAINERS file. Thanks! Updated as follows. Ian 2007-06-14 Ian Lance Taylor <[EMAIL PROTECTED]> * MAINTAINERS: Add myself as non-algorithmic global write maintainer. Index: MAINTAINERS === --- MAINTAINERS (revision 125712) +++ MAINTAINERS (working copy) @@ -223,6 +223,7 @@ loop optimizer Daniel Berlin [EMAIL PROTECTED] middle-end Richard Guenther[EMAIL PROTECTED] libcpp Tom Tromey [EMAIL PROTECTED] blanket write Diego Novillo [EMAIL PROTECTED] +blanket write Ian Lance Taylor[EMAIL PROTECTED] Note that individuals who maintain parts of the compiler as non-algorithmic maintainers need approval to check in algorithmic changes or changes
Re: Some regressions from the dataflow merge
On 6/14/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On Wed, 13 Jun 2007, Kenneth Zadeck wrote: > Richard Guenther wrote: > > On Tue, 12 Jun 2007, Richard Guenther wrote: > > > > > >> On ia64 SPEC2000 I see fma3d and applu now miscompare. > >> > > > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: > > > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o > > zscal.o-fprofile-use -O2 -ffast-math zscal.f > > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> > > fdo_make_pass2.err | tee fdo_make_pass2.out': > > zgemm.f: In function 'zgemm': > > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > Likewise for 176.gcc: > > > > combine.c: In function 'simplify_comparison': > > combine.c:9697: internal compiler error: in remove_insn, at > > emit-rtl.c:3597 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > specmake: *** [combine.o] Error 1 > > > > Richard. > > > Richard, > > did these two regression go away? We committed a change to gcse that > should have fixed this bug. These two are gone now. The ia64 miscompares still are there. I'm looking at it. It is either a scheduler problem, or some other problem downstream triggered by the scheduler. However, I'm having hard time adding fine-grained dbg_cnt to our scheduler - do you know who might be interested in adding insn level dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :( -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Please fork soft-fp from libc
Hello! There was no response from libc maintainers about changing the type of soft-fp compares into CMPtype. This type should be defined to mode(word) or at least we should be able to redefine it outside the soft-fp, in target dependent sfp-target.h. As this is major obstacle in further development (complex numbers) and even in the usability of software FP as part of gcclib (TFmode compares return wrong values), I propose that we fork soft-fp from libc. Soft-fp already diverged from libc by inclusing TImode and TFmode conversions. Otherwise, I propose that we disable TFmode support on x86_64 due to above problems with compares. Thanks for considering this, Uros.
Re: Merge PTR_PLUS branch?
Andrew Pinski wrote: > If you could review the C++ front-end changes, that would be nice. Would you please point me at a URL for those changes? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Please fork soft-fp from libc
On Thu, 14 Jun 2007, Uros Bizjak wrote: > There was no response from libc maintainers about changing the type of soft-fp > compares into CMPtype. This type should be defined to mode(word) or at least Take that matter with the glibc maintainers directly to RMS. > we should be able to redefine it outside the soft-fp, in target dependent > sfp-target.h. As this is major obstacle in further development (complex > numbers) and even in the usability of software FP as part of gcclib (TFmode > compares return wrong values), I propose that we fork soft-fp from libc. Take that proposal directly to RMS. Forking shared files is not a matter for the gcc list. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Please fork soft-fp from libc
On Thu, Jun 14, 2007 at 06:10:52PM +0200, Uros Bizjak wrote: > There was no response from libc maintainers about changing the type of > soft-fp compares into CMPtype. This type should be defined to mode(word) > or at least we should be able to redefine it outside the soft-fp, in > target dependent sfp-target.h. As this is major obstacle in further > development (complex numbers) and even in the usability of software FP > as part of gcclib (TFmode compares return wrong values), I propose that > we fork soft-fp from libc. Soft-fp already diverged from libc by > inclusing TImode and TFmode conversions. > > Otherwise, I propose that we disable TFmode support on x86_64 due to > above problems with compares. The FSF has objected in the past to any discussions of forking glibc. RMS would (I believe) argue that what you're talking about is a glibc bug and glibc should fix it, we shouldn't fork the routine to work around it. After all, the FSF point of view is that GCC and glibc are both part of the GNU project, despite the fact that from the GCC point of value, glibc is only one possible C library, has older and newer versions, etc. Also, we can't take a file from one FSF project and fork it in another without FSF permission, particularly if it involves a license change but even in other cases (because of the way they keep track of assignments). Some think that this is an unnecessary PITA, but that's one of the things we signed up for when we remerged egcs with the FSF, I'm afraid. The SC could discuss this with RMS, but I think your second suggestion might be wise in the short term if there isn't some other workaround. Maybe we can just have RMS annoy the glibc folks until they accept a patch to fix it. But then we have the problem of all those old glibc's that are already out there. So maybe a fork is best after all, and RMS needs to be talked into it. Sigh.
RFA: (dataflow?) testsuite regression since last week
I'm still seeing two testsuite regressions for Xtensa compared to last
Friday:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with "internal compiler error: in get_biv_step,
at loop-iv.c:792". Neither the Xtensa port nor the loop-iv.c code has
changed since last week in a way that obviously affects this. I'm
suspecting it is somehow related to the dataflow merge, but I don't see any
obvious connections there, either.
I'm not very familiar with loop-iv.c so I would appreciate help
figuring out how to fix this.
Here is what appears to be happening for 930921-1.c. The test program is:
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) >> 32) >> 1;
}
main ()
{
unsigned i;
for (i = 0; i < 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
At -O3, function f is inlined into main and "x * 0xAAAB" is recognized as
a DImode induction variable. I'm pretty sure the problem is related
to the lack of an adddi3 pattern in xtensa.md. We rely on optabs.c to
expand DImode addition. If I dump the RTL file, the induction
variable increment looks like:
;; ivtmp$55 = ivtmp$55 + 0x0aaab
(insn 26 25 27 930921-1.c:4 (set (reg:DI 50)
(mem/u/c/i:DI (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [2 S8 A64])) -1
(expr_list:REG_EQUAL (const_double -1431655765 [0xaaab] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
(nil)))
(insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil))
(insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)
(subreg:SI (reg:DI 50) 4))) -1 (nil))
(insn 29 28 30 930921-1.c:4 (set (reg:SI 52)
(const_int 1 [0x1])) -1 (nil))
(jump_insn 30 29 31 930921-1.c:4 (set (pc)
(if_then_else (ltu (subreg:SI (reg:DI 51) 4)
(subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4))
(label_ref 32)
(pc))) -1 (nil))
(insn 31 30 32 930921-1.c:4 (set (reg:SI 52)
(const_int 0 [0x0])) -1 (nil))
(code_label 32 31 33 6 "" [0 uses])
(insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0)
(subreg:SI (reg:DI 50) 0))) -1 (nil))
(insn 34 33 35 930921-1.c:4 (set (reg:SI 53)
(plus:SI (reg:SI 52)
(subreg:SI (reg:DI 51) 0))) -1 (nil))
(insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(reg:SI 53)) -1 (nil))
(insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ])
(reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ])
(reg:DI 50))
(nil)))
The failing assertion in get_biv_step() is:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
The outer_mode is DImode; the inner_mode is SImode; and extend is
UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations
involved here. Is this code intended to work for DImode IVs when
the machine doesn't directly support DImode operations? I don't know
if the problem is in this loop-iv.c code or whether it ought not
recognize the DImode induction variable in the first place.
Help?
Re: How to submit Intel BID library patch?
On Thu, 2007-06-14 at 06:30 -0700, H. J. Lu wrote: > With Intel BID library, we got 2 failures in unmodified DFP tests, > fe-convert-1.c and fe-convert-2.c, due to different exceptions > in Intel BID library vs. libdecnumber. The differences are Go ahead and make those test changes. Janis
Re: Please fork soft-fp from libc
On 6/14/07, Joe Buck <[EMAIL PROTECTED]> wrote: On Thu, Jun 14, 2007 at 06:10:52PM +0200, Uros Bizjak wrote: > There was no response from libc maintainers about changing the type of > soft-fp compares into CMPtype. This type should be defined to mode(word) > or at least we should be able to redefine it outside the soft-fp, in > target dependent sfp-target.h. As this is major obstacle in further > development (complex numbers) and even in the usability of software FP > as part of gcclib (TFmode compares return wrong values), I propose that > we fork soft-fp from libc. Soft-fp already diverged from libc by > inclusing TImode and TFmode conversions. > > Otherwise, I propose that we disable TFmode support on x86_64 due to > above problems with compares. The FSF has objected in the past to any discussions of forking glibc. RMS would (I believe) argue that what you're talking about is a glibc bug and glibc should fix it, we shouldn't fork the routine to work around it. After all, the FSF point of view is that GCC and glibc are both part of the GNU project, despite the fact that from the GCC point of value, glibc is only one possible C library, has older and newer versions, etc. Also, we can't take a file from one FSF project and fork it in another without FSF permission, particularly if it involves a license change but even in other cases (because of the way they keep track of assignments). Some think that this is an unnecessary PITA, but that's one of the things we signed up for when we remerged egcs with the FSF, I'm afraid. The SC could discuss this with RMS, but I think your second suggestion might be wise in the short term if there isn't some other workaround. Maybe we can just have RMS annoy the glibc folks until they accept a patch to fix it. But then we have the problem of all those old glibc's that are already out there. So maybe a fork is best after all, and RMS needs to be talked into it. Sigh. Reminds me of forking glibc libm and the libgcc-math discussion that's still on hold from RMS side. Richard.
Re: How to submit Intel BID library patch?
On Thu, Jun 14, 2007 at 10:13:49AM -0700, Janis Johnson wrote: > On Thu, 2007-06-14 at 06:30 -0700, H. J. Lu wrote: > > > With Intel BID library, we got 2 failures in unmodified DFP tests, > > fe-convert-1.c and fe-convert-2.c, due to different exceptions > > in Intel BID library vs. libdecnumber. The differences are > > Go ahead and make those test changes. > I checked in those changes. Those tests will fail with the current libdecnumber. Intel BID library patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00981.html will need this patch to support Intel BID library and all DFP tests should pass with BID. H.J. --- 2007-06-14 H.J. Lu <[EMAIL PROTECTED]> * gcc.dg/dfp/dfp-round.h (FE_DEC_TONEAREST): Redfined for BID. (FE_DEC_DOWNWARD): Likewise. (FE_DEC_UPWARD): Likewise. (FE_DEC_TOWARDZERO): Likewise. (FE_DEC_TONEARESTFROMZERO): Likewise. --- gcc/testsuite/gcc.dg/dfp/dfp-round.h.dfp-test 2007-05-25 17:42:57.0 -0700 +++ gcc/testsuite/gcc.dg/dfp/dfp-round.h2007-06-13 22:47:36.0 -0700 @@ -2,11 +2,19 @@ pass on the rounding mode to decNumber, but later it can be replaced with Official Stuff. */ +#ifdef __DECIMAL_BID_FORMAT__ +#define FE_DEC_TONEAREST 0 +#define FE_DEC_DOWNWARD 1 +#define FE_DEC_UPWARD 2 +#define FE_DEC_TOWARDZERO 3 +#define FE_DEC_TONEARESTFROMZERO 4 +#else #define FE_DEC_DOWNWARD 0 #define FE_DEC_TONEAREST 1 #define FE_DEC_TONEARESTFROMZERO 2 #define FE_DEC_TOWARDZERO 3 #define FE_DEC_UPWARD 4 +#endif extern void __dfp_set_round (int); #define DFP_SETROUND(M) __dfp_set_round(M)
Re: Please fork soft-fp from libc
On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
> The FSF has objected in the past to any discussions of forking glibc. RMS
> would (I believe) argue that what you're talking about is a glibc bug and
> glibc should fix it, we shouldn't fork the routine to work around it.
It can hardly be considered a glibc bug when GCC changed this incompatibly
a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
all architectures glibc cares about).
That said, as none of the routines in question
({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
use glibc soft-fp code, I guess using CMPtype in those routines doesn't
hurt. I believe --without-fp ppc support in ports is 32-bit only as well
and therefore doesn't care either.
But certainly it must not be defined to int __attribute__ ((mode (word))),
because Andreas Krebbel is actively trying to get rid of that attribute.
Each sfp-machine.h can define CMPtype instead.
Jakub
Re: Please fork soft-fp from libc
Jakub Jelinek wrote:
On Thu, Jun 14, 2007 at 09:36:46AM -0700, Joe Buck wrote:
The FSF has objected in the past to any discussions of forking glibc. RMS
would (I believe) argue that what you're talking about is a glibc bug and
glibc should fix it, we shouldn't fork the routine to work around it.
It can hardly be considered a glibc bug when GCC changed this incompatibly
a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
all architectures glibc cares about).
That said, as none of the routines in question
({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
use glibc soft-fp code, I guess using CMPtype in those routines doesn't
hurt. I believe --without-fp ppc support in ports is 32-bit only as well
and therefore doesn't care either.
But certainly it must not be defined to int __attribute__ ((mode (word))),
because Andreas Krebbel is actively trying to get rid of that attribute.
Each sfp-machine.h can define CMPtype instead.
I belive that by changing mentioned typedef line of soft-fp.h into
#ifndef CMPtype
#define CMPtype int
#endif
would satisfy everybody. Is this acceptable for glibc?
Thanks,
Uros.
Re: Please fork soft-fp from libc
On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote:
> > It can hardly be considered a glibc bug when GCC changed this incompatibly
> > a year ago, up to GCC 4.1.x inclusive __eqtf2 etc. used SItype (i.e. int on
> > all architectures glibc cares about).
> >
> > That said, as none of the routines in question
> > ({eq,ge,le,unord}[sdxt]f2) are actually used by sparc32/sparc64/alpha that
> > use glibc soft-fp code,
Could anyone explain why this change was made? It seems like SItype
would be sufficient everywhere, and I can't see any obvious reason it
would be slower.
--
Daniel Jacobowitz
CodeSourcery
Re: Please fork soft-fp from libc
On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote: > I belive that by changing mentioned typedef line of soft-fp.h into > > #ifndef CMPtype > #define CMPtype int > #endif > > would satisfy everybody. Is this acceptable for glibc? Yes. Though, please use CMPtype not only for return types of the functions, but also for the type of r variables. Jakub
Re: Please fork soft-fp from libc
Jakub Jelinek wrote: On Thu, Jun 14, 2007 at 08:07:32PM +0200, Uros Bizjak wrote: I belive that by changing mentioned typedef line of soft-fp.h into #ifndef CMPtype #define CMPtype int #endif would satisfy everybody. Is this acceptable for glibc? Yes. Though, please use CMPtype not only for return types of the functions, but also for the type of r variables. Thanks. I have changed the patch as requested, and it was just sent to [EMAIL PROTECTED] Thanks again for your help to resolve this problem, Uros.
Re: Please fork soft-fp from libc
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > It seems like SItype would be sufficient everywhere, and I can't see > any obvious reason it would be slower. What about 16-bit targets?
Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"
(Because this concerns policy rather than code, I've cc'ed it to the main gcc list rather than the patches list.) FX Coudert wrote: I noticed in MAINTAINERS that there is a new category of "Non- Autopoiesis Maintainers" (I certainly missed the original announcement), for maintainers who cannot approve their own patches (except trivial ones). There is a FIXME in the file that says that Fortran maintainers should be added to this category, and it is indeed true, since we decided to work under this kind of rule (which, I think, is a very positive thing). So, I moved us all in that category, except Paul Brook who is one of the original authors for the front-end (unfortunately, Steven B. left GCC development recently). There _was_ no official announcement, save this note under a subject heading of "[PATCH]: Minor cleanups after the dataflow merge": http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00723.html I'm not entirely sure that I agree with formalizing this for the Fortran maintainers in bulk, at least without discussion. My understanding (and it's entirely possible that I've missed something) was that this wasn't so much a formal rule as a general custom -- and, being a custom rather than a formal rule, unobjectionable to break when appropriate. I have no objection to this as a custom for GFortran, certainly -- I think it's a very good idea, and as a custom I very much support it. However, there have historically been reasonable exceptions to it. In particular, I've committed several documentation patches without review, and I have seen a few small patches submitted by maintainers for comments rather than a formal review and then committed when there were no dissenting comments. My understanding at the time was that these were entirely acceptable things to do; is this still true, or no? Mostly what I want is some discussion about what we expect this to mean as a formal rule, and how strictly we're expecting to interpret it. For values of "we" meaning both the GFortran maintainers, and the wider GCC maintainer community. (I think I'd also like to register a very small polite complaint about the introduction of a new category of maintainers without any sort of announcement or discussion on the gcc@ list, at least insofar as I could find by searching on "autopoiesis" in the archives.) Also, I took this opportunity to change the label of the front-end in that file from "fortran 95" to "Fortran", to be more consistent with our decision to not mention the 95 standard in the compiler description and use the capitalized Fortran spelling. I also reordered our names into alphabetical order. This, I entirely agree with; it had been mildly bugging me for a while. - Brooks
Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"
On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote: > > I have no objection to this as a custom for GFortran, certainly -- I > think it's a very good idea, and as a custom I very much support it. > However, there have historically been reasonable exceptions to it. In > particular, I've committed several documentation patches without review, > and I have seen a few small patches submitted by maintainers for > comments rather than a formal review and then committed when there were > no dissenting comments. My understanding at the time was that these > were entirely acceptable things to do; is this still true, or no? > As the Fortran maintainer the pre-approved your doc patches (and Daniel's patches) I feel I should comment. The gfortran docs were in such a mess that neither you nor Danial could possibly commit a change that would make the docs worse. Well, I guess you could have, but your previous involvement in the mailing list suggested otherwise. My other objective (besides better docs) was to lure you into the realm of bug fixer and developer. It appears that I succeed. :-) I haven't looked at the guidelines for this new category in that I doubt it will change the day-to-day interaction of the gfortran developers. In general, we ask for reviews when necessary and commit obvious fixes as they arise. In my 4+ years of hacking on gfortran, I cannot recall a single dispute among the developers. Sure, there's been disagreement, but not dispute. PS: The 4 year anniversity of my first commit is coming up: 2003-06-24 Steven G. Kargl <[EMAIL PROTECTED]>` -- Steve
Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"
At 09:40 PM 6/14/2007, Steve Kargl wrote: On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote: > I have no objection to this as a custom for GFortran, certainly -- I > think it's a very good idea, and as a custom I very much support it. > However, there have historically been reasonable exceptions to it. In > particular, I've committed several documentation patches without review, > and I have seen a few small patches submitted by maintainers for > comments rather than a formal review and then committed when there were > no dissenting comments. My understanding at the time was that these > were entirely acceptable things to do; is this still true, or no? As the Fortran maintainer the pre-approved your doc patches (and Daniel's patches) I feel I should comment. The gfortran docs were in such a mess that neither you nor Danial could possibly commit a change that would make the docs worse. Well, I guess you could have, but your previous involvement in the mailing list suggested otherwise. Indeed -- but my impression was that, when I became a maintainer, that explicit pre-approval was no longer needed. Perhaps I misunderstood? Though I guess it does amount to the same thing in practice -- if you hadn't encouraged me to commit documentation patches without troubling people for reviews of each one, then I would have assumed once I became a maintainer that I should continue to request reviews of the documentation patches I proposed, and would have done so. I haven't looked at the guidelines for this new category in that I doubt it will change the day-to-day interaction of the gfortran developers. In general, we ask for reviews when necessary and commit obvious fixes as they arise. In my 4+ years of hacking on gfortran, I cannot recall a single dispute among the developers. Sure, there's been disagreement, but not dispute. Oh, definitely. That's sort of why I wanted to comment on this; insofar as this is documenting the status quo, that's a good thing, but I wanted to make sure that it wasn't setting up a situation where people in the rest of the GCC community would expect us to follow more rigid rules than we actually do. - Brooks
Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"
On Thu, Jun 14, 2007 at 10:28:58PM -0700, Brooks Moses wrote: > At 09:40 PM 6/14/2007, Steve Kargl wrote: > >On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote: > >> I have no objection to this as a custom for GFortran, certainly -- I > >> think it's a very good idea, and as a custom I very much support it. > >> However, there have historically been reasonable exceptions to it. In > >> particular, I've committed several documentation patches without review, > >> and I have seen a few small patches submitted by maintainers for > >> comments rather than a formal review and then committed when there were > >> no dissenting comments. My understanding at the time was that these > >> were entirely acceptable things to do; is this still true, or no? > > > >As the Fortran maintainer the pre-approved your doc patches (and > >Daniel's patches) I feel I should comment. The gfortran docs > >were in such a mess that neither you nor Danial could possibly > >commit a change that would make the docs worse. Well, I guess > >you could have, but your previous involvement in the mailing list > >suggested otherwise. > > Indeed -- but my impression was that, when I became a maintainer, that > explicit pre-approval was no longer needed. Perhaps I misunderstood? > You did not misunderstand. You are on your own with respect to doc patches. For the people that I've encourage to become more active in gfortran development, the process is simple. 1) person sends good bug reports (dominique is in this phase) 2) person sends small, trivial, patches (no assignment is needed) 3) person sends big patches, so encourage copyright assignment. Commit the patches for person (Christopher Rickett is here). 4) More patches come, seek write-after-approval (Chris will be here after ISO C binding is committed). 5) more patches come and comments on the patches of others. A maintainer approves patches (Asher and DanielD are here) 6) more patches comes. bestow maintainership. -- Steve
Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"
Mostly what I want is some discussion about what we expect this to mean as a formal rule, and how strictly we're expecting to interpret it. For values of "we" meaning both the GFortran maintainers, and the wider GCC maintainer community. I agree with your intrepretation of this rule exactly as you stated it, and as it is stated on http://gcc.gnu.org/fortran/ : approval of non-obvious patches is required as a rule, but the scope of "obvious" can be extended at times, and it's also possible to send a patch asking if anyone has comments, saying that you plan on committing it on a given date. I did change the Fortran maintainers from the standard category to this new one because it seemed close to what we currently do. To come to the heart of the issue, I don't think it will be intepreted to our disadvantage by the GCC community. From the past, it seemed that the steering committee and release managers have kept to a simple line: the Fortran maintainers have a system that works, even though it's not completely the same as the usual GCC maintainership. If it works well, let's keep it that way. [1] I feel that we have a wide margin to make our decisions. After all, IIRC, the "mostly non-autopoiesis" system that we have is something we came up with, not the steering committee. In short: I understand your point of view, and I think we have been given enough liberty for Fortran choices in the past not to worry about this MAINTAINERS category not 100% describing our policy. FX [1] I'm sorry if I'm misunderstanding the policy that is applied to us; and I want to note that I'm only speaking about maintainership, not the development and branches rules, for which we're going slowly toward the standard GCC practices.
