Re: gnat_rm.texi and makeinfo 5.1
pr61505 Dominique
Re: build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set
> I've been looking for a smoking gun, but did not find one. Interestingly > this only happens in stage3 on i386-unknown-freebsd10.0 where clang is the > bootstrap compiler: ... Same thing here on x86_64-apple-darwin13 at r212373 configured with $ ../p_work/configure --prefix=/opt/gcc/gcc4.10p-212373 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 My bootstrap compiler is gcc r211652. With it I have successfully boostrapped r212366 configured with $ ../work/configure --prefix=/opt/gcc/gcc4.10w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 Dominique
Re: build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set
See also https://gcc.gnu.org/ml/gcc-regression/2014-07/ Dominique
Re: [BUILDROBOT] Ada broken
This was caused by r215794 and seems fixed at r215833. Dominique
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> ...
> Can you please test it on Darwin (or whatever other target has similar
> issues with bootstrapping libcc1)?
>
> 2014-12-05 Jakub Jelinek
> ...
The patch does not work for x86_64-apple-darwin14.0.0. However the following
patch does:
--- ../_clean/Makefile.in 2014-11-26 23:09:14.0 +0100
+++ Makefile.in 2014-12-05 17:22:54.0 +0100
@@ -31389,7 +31389,7 @@ configure-libcc1:
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
test ! -f $(HOST_SUBDIR)/libcc1/Makefile || exit 0; \
$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libcc1 ; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
echo Configuring in $(HOST_SUBDIR)/libcc1; \
cd "$(HOST_SUBDIR)/libcc1" || exit 1; \
case $(srcdir) in \
@@ -31422,7 +31422,7 @@ all-libcc1: configure-libcc1
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/libcc1 && \
$(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
$(STAGE1_FLAGS_TO_PASS) \
$(TARGET-libcc1))
@@ -31440,7 +31440,7 @@ check-libcc1:
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/libcc1 && \
$(MAKE) $(FLAGS_TO_PASS) check)
@@ -31455,7 +31455,7 @@ install-libcc1: installdirs
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/libcc1 && \
$(MAKE) $(FLAGS_TO_PASS) install)
@@ -31470,7 +31470,7 @@ install-strip-libcc1: installdirs
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
(cd $(HOST_SUBDIR)/libcc1 && \
$(MAKE) $(FLAGS_TO_PASS) install-strip)
@@ -31489,7 +31489,7 @@ info-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31515,7 +31515,7 @@ dvi-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31541,7 +31541,7 @@ pdf-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31567,7 +31567,7 @@ html-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31593,7 +31593,7 @@ TAGS-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31620,7 +31620,7 @@ install-info-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31647,7 +31647,7 @@ install-pdf-libcc1: \
@[ -f ./libcc1/Makefile ] || exit 0; \
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
+ $(POSTSTAGE1_HOST_EXPORTS) \
for flag in $(EXTRA_HOST_FLAGS) ; do \
eval `echo "$$flag" | sed -e "s|^\([^=]*\)=\(.*\)|\1='\2'; export
\1|"`; \
done; \
@@ -31674,7 +31674,7 @@ install-html-libcc1: \
@[ -f ./libcc1/Make
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> As I've tried to explain, that is IMHO wrong though. > If what you are after is the -B stuff too, then perhaps: > ... Sorry but it does not work: true DO=all multi-do # make make[4]: Leaving directory '/opt/gcc/build_w/libbacktrace' make[3]: Leaving directory '/opt/gcc/build_w/libbacktrace' make[3]: Entering directory '/opt/gcc/build_w/libcpp' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/opt/gcc/build_w/libcpp' make[3]: Entering directory '/opt/gcc/build_w/libdecnumber' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/opt/gcc/build_w/libdecnumber' make[3]: Entering directory '/opt/gcc/build_w/gcc' make[3]: Leaving directory '/opt/gcc/build_w/gcc' Checking multilib configuration for libgcc... make[3]: Entering directory '/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libgcc' make[3]: *** No rule to make target ' -B$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs'. Stop. make[3]: Leaving directory '/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libgcc' Makefile:14905: recipe for target 'all-stage1-target-libgcc' failed make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory '/opt/gcc/build_w' Makefile:21193: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/opt/gcc/build_w' Makefile:910: recipe for target 'all' failed make: *** [all] Error 2 Dominique
Re: GCC 4.8.4 Status Report (2014-12-05)
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407. Would it be possible to apply the patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932 before 4.8.4 is released? Results with the patch are posted at https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02096.html. TIA Dominique
Re: 10% runtime regression in rnflow Polyhedron benchmark
Hi Uros, > Recent patch introduced 10% runtime regression on x86_64 targets in > rnflow Polyhedron benchmark [1]. Did somebody alread bisected to the > offending patch? I see it since some time. It is on my TODO list to open a new PR. You can suppress the slowdown with -fno-tree-loop-if-convert. I think I have already done the bissection, but right now I am chasing another problem and I'll need a couple hours to get to it. Cheers, Dominique
Questions about the dg-do directive
These questions are motivated by the comments #4 to #15 of pr54407.
The bottom line is that
{ dg-do compile targets1 }
{ dg-do run targets2 }
behaves as
{dg-do run { targets1 targets2 } }
while
{ dg-do run targets1 }
{ dg-do compile targets2 }
as
{ dg-do compile { targets1 targets2 } }
(1) Is the above correct?
(2) If yes, is it a (undocumented) feature or a bug?
While looking at the gcc.dg files, I have seen several instances of
these constructs. While most of them lacks any target, then the
first line is probably ignored, the tests gcc.dg/vect/vect-(82|83)_64.c
use it in:
/* { dg-do run { target { { powerpc*-*-* && lp64 } && powerpc_altivec_ok } } }
*/
/* { dg-do compile { target { { powerpc*-*-* && ilp32 } && powerpc_altivec_ok }
} } */
They do not seem to work as designed: the tests are not run on
powerpc-apple-darwin9
with -m64.
(3) What should be done for that?
One way of doing a { dg-do run targets1 } and { dg-do compile targets2 } would
be to use the trick in gcc.dg/attr-weakref*, i.e., to duplicate the test, one
file to run and the other to only compile.
(4) Does it exists a better solution?
TIA
Dominique
Re: Questions about the dg-do directive
Thanks for the quick answer.
> That's just the way it works, so I suppose you could call it a feature.
So the answer to (1) is yes and to (2) it is a poorly documented feature.
May be the restriction to one dg-do directive should be added to
http://gcc.gnu.org/wiki/HowToPrepareATestcase .
In gcc/testsuite/* I have found 27 instances of such double directives
most of the in the powerpc tests (gcc.target/powerpc/altivec*).
I can provide a list if it helps.
> ... We have much better ways in
> local test directives to skip and xfail tests for different targets.
Could you elaborate please? AFAIU skip or xfail do not allow to do
what was intended in the gcc.target/powerpc/altivec* cases for instance:
run for powerpc*-*-* && vmx_hw and compile for
powerpc*-*-* && { ! vmx_hw }.
Dominique
building gcc4-4.3.0-20061104/11 failure on OSX 10.3
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
> Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
> odcctools 590-20060413 using a modified Fink script (working
> with the previous snapshot) failed with:
> ...
Since the problem is still there in gcc4-4.3.0-2006 and I did not get
any answer, I tried the following:
(1) I replaced gcc/config/darwin.h by the file from gcc4-4.3.0-20061028,
and the build was done without obvious problem.
(2) Using the gcc/config/darwin.h from gcc4-4.3.0-2006, I replaced:
#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
by
#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
Then the original failure:
> strip: object: .//libgcc_s.1.dylib.tmp malformed object (unknown load
> command 8)
disappeared (along with the other messages such as:
> ranlib: file: ./libgcc.a(_trampoline.o) has no symbols
> ...
> /sw/lib/odcctools/bin/nm: no name list
> ...
> /sw/lib/odcctools/bin/ld: warning libgcc/./ppc64-fp_s.o could not
> understand DWARF debug information
> /sw/lib/odcctools/bin/ld: warning libgcc/./darwin-64_s.o could not
> understand DWARF debug information
> ...
However the build failed with:
> ...
> Configuring stage 2 in ./intl
> configure: creating cache ./config.cache
> checking whether make sets $(MAKE)... yes
> checking for a BSD-compatible install... /sw/bin/ginstall -c
> checking whether NLS is requested... yes
> checking for msgfmt... /sw/bin/msgfmt
> checking for gmsgfmt... /sw/bin/msgfmt
> checking for xgettext... /sw/bin/xgettext
> checking for msgmerge... /sw/bin/msgmerge
> checking for powerpc-apple-darwin7-gcc...
> /sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/xgcc
> -B/sw/src/fink.build/gcc4-4.3.0-20061115/darwin_objdir/./prev-gcc/
> -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> make[2]: *** [configure-stage2-intl] Error 77
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
> checking for C compiler default output file name... ### execution of
> /var/tmp/tmp.1.iDjVLN failed, exit code 2
Using
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}"
instead of
#define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}" \
" %{pthread:-D_REENTRANT}"
or removing
#define NO_IMPLICIT_EXTERN_C
did not help (same failure).
Any idea about what's wrong with the new gcc/config/darwin.h when used
with OSX 10.3?
TIA
Dominique d'Humieres
Re: building gcc4-4.3.0-20061104/11 failure on OSX 10.3
Thanks for the answers. > Please remove your changes from your tree, re-pull the current > mainline and try building again. See my posting test results posting > in http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00708.html for > details on how I got those results. You don't have to apply the > referenced patch, as I already checked it into mainline. I am not really maintaining a tree. Usually I download the weekly snapshot (due tomorrow) and do the buils through a modified Fink script. If I have a problem, I look if I can solve it by small changes in the script. If the problem comes from the snapshot itself, I cry for help and without answer I do what I did, i.e. try some patches, but I do my best to avoid that. Unless there is an emergency I do not foresee, I'll try with the 20061118 snapshot in which the patch should be included (I have seen it in CVS). > You can run as -v to see what version of cctools you have. Apple Computer, Inc. version cctools-590.36~obj, GNU assembler version 1.38 Note that I have also [karma] f90/bug% /sw/lib/odcctools-10.4/bin/ld -v Apple Computer, Inc. version odcctools-622.3od15 (copied from my 10.4 laptop) though I never used it under 10.3. The Fink script use several --with-xx to look at the tools (ld, as, nm, libtool, ...) in a separate directory. I have added a few more without solving the problem. It seems that the with-* mechanism is not fully implemented since there is a hardcoded /usr/bin/libtool in gcc/config/darwin.h and a default (from path) nm in libstdc++-v3/scripts/make_exports.pl. I don't know if there are other instances for other commands (I grepped 'strip' in the hierarchy, but had too many outputs to really use them). > Let me know if that works for you. I should have an answer by next Monday. > > Mike was considering simply declaring that GCC 4.3 won't work on > > Mac OS 10.3. > > No, not really. I'll declare that using things older than 10.3.9 are > gonna be hard, as the required cctools package was built for 10.3.9, > however, if one gets the sources for cctools and builds them on older > releases, one might be able to go back father. I don't think I care > enough to do that much work. I am under 10.3.9 and I think the requirement to have it + cctools-590.36 is reasonable. > > 10.3 is quite old now, and there will be very few users by the time > > that 4.3 is released. > > I tested it out on mainline and it works just fine (now). :-) I'ld prefer you wait until the 10.5 release, before declaring GCC 4.3 won't work on OSX 10.3. Thanks Dominique
Re: building gcc4-4.3.0-20061104/11 failure on OSX 10.3
> Let me know if that works for you.
After applying the Andrew Pinski's patch for pr29879, the build of snapshot
20061118 went without problem on OSX 10.3.9. So your patch fixes the
problem I have reported. Thanks a lot.
If I may abuse of the situation, I am using the following patches:
Index: gcc/config/rs6000/darwin7.h
===
--- gcc4/gcc/config/rs6000/darwin7.h(revision 112376)
+++ gcc4/gcc/config/rs6000/darwin7.h(working copy)
@@ -29,3 +29,1 @@
-#define LIB_SPEC "%{!static:\
- %:version-compare(!< 10.3 mmacosx-version-min= -lmx)\
- -lSystem}"
+#define LIB_SPEC "%{!static:-lSystem -lmx}"
this is required to avoid a lot of warnings with ld, as discussed in
a thread around 21/08/2005, and
Index: gcc/config/i386/darwin-libgcc.10.4.ver
===
--- gcc4/gcc/config/i386/darwin-libgcc.10.4.ver (revision 112376)
+++ gcc4/gcc/config/i386/darwin-libgcc.10.4.ver (working copy)
@@ -7,6 +7,7 @@
__Unwind_GetDataRelBase
__Unwind_GetGR
__Unwind_GetIP
+__Unwind_GetIPInfo
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
===
--- gcc4/gcc/config/rs6000/darwin-libgcc.10.4.ver (revision 112376)
+++ gcc4/gcc/config/rs6000/darwin-libgcc.10.4.ver (working copy)
@@ -7,6 +7,7 @@
__Unwind_GetDataRelBase
__Unwind_GetGR
__Unwind_GetIP
+__Unwind_GetIPInfo
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
which have been put sometime ago in darwin-libgcc.10.5.ver. Is there any
good reason why such patches are not applied in the distributions. If no,
could they be included?
TIA
Dominique
failed to compile gcc-4.3-20061209/gcc/varasm.c on OSX 10.3
On OSX 1Â0.3 updating to gcc-4.3-20061209 failed with: ... cc1: warnings being treated as errors ../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches': ../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'long int' ../../gcc-4.3-20061209/gcc/varasm.c:6275: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'long int' ../../gcc-4.3-20061209/gcc/varasm.c:6283: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'long int' ../../gcc-4.3-20061209/gcc/varasm.c:6302: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'long int' make[3]: *** [varasm.o] Error 1 ... Any idea around about the cause and/or the way to fix it? TIA Dominique
building gcc4-4.3.0-20061223 on OSX 10.3 failed
Building gcc4-4.3.0-20061223 on OSX 10.3 failed with: ... gcc -g -fkeep-inline-functions -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-powerpc-apple-darwin7/libiberty/libiberty.a ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _integer_nonzerop _integer_zerop make[3]: *** [build/genconstants] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Re: building gcc4-4.3.0-20061223 on OSX 10.3 failed
> This was seen on a few platforms. I think it's due to zdenek's patch. It seems that 'integer_zerop' and 'integer_nonzerop' are defined in gcc/tree.c and as far as I can tell the file is not compiled before the error. Any idea why? TIA Dominique
Re: Running GCC tests on installed compiler
Thanks to Steve Ellcey for having asked the question I did not care (dare) to ask and to those who answered. > So please use contrib/test_installed This script seems quite outdated: it tests g77 and not gfortran, even with the latest 4.3.0 snapshot (20070112). As I was primarily interested in the gfortran tests, I replaced g77 by gfortran everywhere (keeping the different capitalizations) and it worked. The script also ignores java tests. I looked again to the manual (http://gcc.gnu.org/install/test.html) and did not find this script documented anywhere. Am I missing something or is this a place where the manual can be improved? Note that I am installing gcc on Mac OSX/PPC through a fink script that does not keep the building directory, so my choices are either to make further changes to the script to include the appropriate "make check" (this will increase both the building time by several hours and the risk of failure after several hours) or to do a postinstall check (my choice, unless someone offers a better solution). Cheers Dominique
Re: Running GCC tests on installed compiler
Gerald,
> > This script seems quite outdated: it tests g77 and not gfortran, even
> > with the latest 4.3.0 snapshot (20070112). ...
>
> Would you mind submitting this as a patch?
--- gcc-4.3-20070120/contrib/test_installed Fri Jul 11 08:05:01 2003
+++ gcc-4.3-20070119/contrib/test_installed Sat Jan 13 17:53:01 2007
@@ -16,12 +16,12 @@
# will be appended to the srcdir.
# You may specify where the binaries to be tested should be picked up
-# from. If you specify --prefix=/some/dir, gcc, g++ and g77 will be
+# from. If you specify --prefix=/some/dir, gcc, g++ and gfortran will be
# looked for at /some/dir/bin. Each one may be overridden by
# specifying --with-gcc=/pathname/to/gcc, --with-g++=/pathname/to/g++
-# and --with-g77=/pathname/to/g77. If you specify --without-gcc,
-# --without-g++ or --without-g77, the test for the specified program
-# will be skipped. By default, gcc, g++ and g77 will be searched in
+# and --with-gfortran=/pathname/to/gfortran. If you specify --without-gcc,
+# --without-g++ or --without-gfortran, the test for the specified program
+# will be skipped. By default, gcc, g++ and gfortran will be searched in
# the PATH.
# An additional argument may specify --tmpdir=/some/dir; by default,
@@ -50,16 +50,16 @@
--prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
- --with-g77=*) G77_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
+ --with-gfortran=*) GFORTRAN_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`;
shift;;
--without-gcc) GCC_UNDER_TEST=no; shift;;
--without-g++) GXX_UNDER_TEST=no; shift;;
- --without-g77) G77_UNDER_TEST=no; shift;;
+ --without-gfortran) GFORTRAN_UNDER_TEST=no; shift;;
--without-objc) OBJC_UNDER_TEST=no; shift;;
--tmpdir=*) tmpdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--help) cat <<\EOF
-Runs the testsuite for an installed version of gcc/g++/g77/objc
+Runs the testsuite for an installed version of gcc/g++/gfortran/objc
Copyright (C) 1998 Free Software Foundation
by Alexandre Oliva <[EMAIL PROTECTED]>
@@ -71,13 +71,13 @@
--srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
[deduced from shell-script pathname]
---prefix=/some/diruse gcc, g++ and g77 from /some/dir/bin [PATH]
+--prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin
[PATH]
--with-gcc=/some/dir/bin/gcc use specified gcc program [gcc]
--with-g++=/some/dir/bin/g++ use specified g++ program [g++]
---with-g77=/some/dir/bin/g77 use specified g77 program [g77]
+--with-gfortran=/some/dir/bin/gfortran use specified gfortran program
[gfortran]
--without-gcc do not run gcc testsuite
--without-g++ do not run g++ testsuite
---without-g77 do not run g77 testsuite
+--without-gfortrando not run gfortran testsuite
--without-objcdo not run objc testsuite
--tmpdir=/some/dircreate temporaries and leave failed programs
@@ -109,13 +109,13 @@
set CXXFLAGS ""
set GCC_UNDER_TEST "${GCC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
set GXX_UNDER_TEST "${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
-set G77_UNDER_TEST "${G77_UNDER_TEST-${prefix}${prefix+/bin/}g77}"
+set GFORTRAN_UNDER_TEST
"${GFORTRAN_UNDER_TEST-${prefix}${prefix+/bin/}gfortran}"
set OBJC_UNDER_TEST "${OBJC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
EOF
test x"${GCC_UNDER_TEST}" = x"no" || runtest --tool gcc ${1+"$@"}
test x"${GXX_UNDER_TEST}" = x"no" || runtest --tool g++ ${1+"$@"}
-test x"${G77_UNDER_TEST}" = x"no" || runtest --tool g77 ${1+"$@"}
+test x"${GFORTRAN_UNDER_TEST}" = x"no" || runtest --tool gfortran ${1+"$@"}
test x"${OBJC_UNDER_TEST}" = x"no" || runtest --tool objc ${1+"$@"}
exit 0
If this is OK along with no copyright assignment, I can submit a PR.
The copyright should probably extended to 2007. I think also than one
should notify Alexandre Oliva.
> I do not know whether you have a copyright assignment on file, but
> perhaps it is simply enough that we can take it even without one.
I haven't any copyright assignment unless there is a global one with the
french CNRS (Centre National de la Recherche Scientifique), but if one is
required to replace g77 by gfortran we are really living in a sad world!
> > I looked again to the manual (http://gcc.gnu.org/install/test.html) and
> > did not find this script documented anywhere. Am I missing something
> > or is this a place where the manual can be improved?
>
> The latter, I believe. Do you think you could provide a patch against
> gcc/doc/install.texi? ;-) I'll be happy to work with you on this if
> contributing to GCC is an option for you.
This part is trickier. First I'll have to learn the basics of texi, since
I have never used it. Second I am afraid to be writing challenged. Third
I
Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
On powerpc-apple-darwin8, I killed jc1 after it took over 37:29.81 at: ... echo ../../../../gcc-4.3-work/libjava/classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F*.class> gnu/javax/swing/text/html/parser/HTML_401F.list /bin/sh ./libtool --tag=GCJ --mode=compile /opt/gcc/darwin_buildw/gcc/gcj -B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/ -B/opt/gcc/darwin_buildw/gcc/ -fclasspath= -fbootclasspath=../../../../gcc-4.3-work/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -o gnu/javax/swing/text/html/parser/HTML_401F.lo -fsource-filename=/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj -B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/ -B/opt/gcc/darwin_buildw/gcc/ -fclasspath= -fbootclasspath=../../../../gcc-4.3-work/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -fsource-filename=/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list -fno-common -o gnu/javax/swing/text/html/parser/.libs/HTML_401F.o Was I pessimistic or is there a bug? TIA Dominique
Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
David, > ... I would give it a couple of hours before calling it broken. You are right, a small "couple" of hours is need for the three stages: slightly less than two hours on my machine (1.8Ghz G5). I never noticed that this part was so long and I was too eager to do something else with the CPU. Sorry for the noise. Thanks for the answer. Dominique
Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
There is something I don't understand: why the problem shows only (mainly) in jc1? If a similar increase had happened in gfortran, I (and others) would have seen it. Dominique
Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
A full bootstrap took 12h 38' on my machine (1.8Ghz G5) minus probably ~1h diverted for other tasks. Although I did not measured accurately this time before, it could be my fastest one. Most of the improvement from my original post comes from gnu/javax/swing/text/html/parser/HTML_401F.deps, for which the compile time went from over 100 minutes to below 10 (twice due to multilib). For all the other pieces of code the saving (if any) was clearly well below a factor 2. Does anyone understand what is so special to jc1 and HTML_401F in order to explain this order of magnitude? Dominique
Broken regression testing on Intel Darwin9
At revision 130629 regtesting on Intel Darwin9 gives a dozen The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. then stop to do anything untill I kill it. I did not see that with revision 130589. What is the meaning of the message? and what could I do? TIA Dominique
10 to 20% speedup with -m64 on Intel Core2Duo
Some time ago I had a look at pr30388 and got the following results: g77 -O2 g95 -O2 gfc -O2 gfc -m64 -O2 MFLOPS: 10631061 8581129 ref. g77-19% +6% Since the evening is quite calm I decided to check if this speedup with -m64 is generic or not and I got the following timings for the Polyhedron test suite: Date & Time : 27 Dec 2007 22:24:03 Test Name : pbharness Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 4.27 50712 13.10 2 0.0420 aermod100.72 1200712 30.19 2 0.0066 air 6.68 73204 9.37 2 0.0267 capacita 3.92 64520 56.49 2 0.0628 channel 2.43 42752 2.29 2 0.0437 doduc 14.42 179504 48.66 2 0.0021 fatigue 5.69 76696 11.17 5 0.3700 gas_dyn 6.32 700392 10.24 5 0.7605 induct 12.79 160672 66.27 2 0.0053 linpk 1.53 38400 27.54 2 0. mdbx 3.77 68856 15.16 2 0.0099 nf 11.69 112312 31.63 2 0.0174 protein 10.71 110048 46.78 2 0.0064 rnflow 10.95 163144 37.28 2 0.0268 test_fpu 10.08 150080 12.72 2 0.0314 tfft 1.37 30488 2.79 2 0.1074 Geometric Mean Execution Time = 18.20 seconds Date & Time : 27 Dec 2007 22:44:36 Test Name : pbharness Compile Command : gfc %n.f90 -O3 -ffast-math -funroll-loops -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 4.48 46532 16.88 2 0.0207 aermod104.92 1288460 37.09 2 0.0081 air 6.67 80956 11.36 5 0.0849 capacita 3.79 68332 62.40 2 0.0048 channel 2.65 50780 2.51 4 0.1828 doduc 14.27 183264 57.41 2 0.0009 fatigue 6.11 84564 14.02 2 0.0642 gas_dyn 5.93 699872 12.01 5 0.2754 induct 11.83 160132 73.59 2 0.0177 linpk 1.67 46512 27.57 2 0.0145 mdbx 3.84 72672 16.78 2 0.0149 nf 16.73 157220 31.86 2 0.0016 protein 11.62 113868 54.90 2 0.0337 rnflow 11.87 187316 45.56 2 0.0889 test_fpu 11.38 182544 14.56 2 0.0653 tfft 1.44 34420 3.03 5 0.2973 Geometric Mean Execution Time = 20.86 seconds Polyhedron Benchmark Validator Copyright (C) Polyhedron Software Ltd - 2004 - All rights reserved The results have been obtain on an Intel Core2Duo 2.16Ghz with 2Gb of RAM under Darwin9.1 with gfortran 4.3 at revision 131206. Is this 10 to 20% speedup with -m64 expected? and how generic is it? In the assembly code of the inner loop of the test case in PR30388, the main differences I can see are at the level of the addressing: %eax, %ebp, ... in 32 bit mode and %rn, ... in 64 bit mode. TIA Dominique
Re: omp_get_num_procs() not working on macintosh?
> Perhaps Darwin doesn't define _SC_NPROCESSORS_ONLN It is defined on Darwin9: [ibook-dhum] f90/bug% grep _SC_NPROCESSORS_ONLN /usr/include/* /usr/include/unistd.h:#define _SC_NPROCESSORS_ONLN58 but apparently not for Darwin8. Dominique
Re: Darwin long double issue (PR25477): any news or plans?
> The issue is trivial enough to fix, if people want to fix it. > Essentially, the various builtins need to have different linkage names, > not just _sin. Those who kow how to fix it don't want to fix it, and those who want to fix it don't how to fix it! Would it be possible to break this vicious circle? Dominique
Re: [PATCH] Add PAREN_EXPR
> I would vote for -ffast-math to disable it. Please don't. I think parentheses should be obeyed in FORTRAN. -ffast-math groups several useful optimization for usual codes and I don't see why users should have to remember their names if they want to keep mandatory parentheses. Now I also think one should think twice (at least!) before introducing a new option (some day I'll rant against their number). Dominique
Re: Bootstrap failure on powerpc64-linux
This is PR373, see http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html for a fix. Dominique
Re: Lots of new test failures on trunk due to unrecognizable insn
See my comments in PR33009. Dominique d'Humieres
Bootstrap failure due to a typo in gcc/fwprop.c
While rebuilding gcc I got the following failure: /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4-work/gcc/fwprop.c -o fwprop.o cc1: warnings being treated as errors ../../gcc-4.4-work/gcc/fwprop.c:234: error: comma at end of enumerator list make[3]: *** [fwprop.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 This is due to revision 133828 and fixed by the following patch: --- ../_gcc_clean/gcc/fwprop.c 2008-04-02 12:12:57.0 +0200 +++ gcc/fwprop.c2008-04-02 13:44:07.0 +0200 @@ -231,7 +231,7 @@ PR_HANDLE_MEM is set when the source of the propagation was not another MEM. Then, it is safe not to treat non-read-only MEMs as ``opaque'' objects. */ - PR_HANDLE_MEM = 2, + PR_HANDLE_MEM = 2 }; Dominique
Bootstrap failure on i686-apple-darwin9
At revision 134333, boostrap fails on i686-apple-darwin9 at stage 1 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4-work/gcc/explow.c -o explow.o ../../gcc-4.4-work/gcc/except.c: In function 'dw2_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3382: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3388: error: 'struct eh_status' has no member named 'call_site_data' ../../gcc-4.4-work/gcc/except.c: In function 'sjlj_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3398: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3404: error: 'struct eh_status' has no member named 'call_site_data' make[3]: *** [except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Re: Bootstrap failure on i686-apple-darwin9
> Does this help? Thanks for tha answer, but now I have: ... ../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags': ../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member named 'epilogue_delay_list' make[3]: *** [except.o] Error 1 ... Dominique
Re: Bootstrap failure on i686-apple-darwin9
Jan, The second patch worked (now building libgfortran). Thanks Dominique
No rule to make target `df-byte-scan.c' at rev. 134523
At revision 134523, bootstraping fails on i686-apple-darwin9 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4-work/gcc/dummy-checksum.c -o dummy-checksum.o make[3]: *** No rule to make target `df-byte-scan.c', needed by `df-byte-scan.o'. Stop. make[3]: *** Waiting for unfinished jobs /bin/sh ../../gcc-4.4-work/gcc/../move-if-change tmp-mlib.h multilib.h echo timestamp > s-mlib make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Is the following "dg" syntax correct?
Is the following syntax correct?
/* { dg-require-effective-target ilp32 && dfp } */
It appears in gcc/testsuite/gcc.target/i386/pr32000-2.c and
gcc/testsuite/gcc.target/i386/stackalign/return-3.c.
TIA
Dominique
Re: Is the following "dg" syntax correct?
> but nothing complains and it seems to work fine. The tests gcc.target/i386/pr32000-2.c and return-3.c are run (and fail) on i686-apple-darwin9 which does not support decimal floating point. So I think the dg-require is not properly enforced. Dominique
Re: PR 44149 can be considered fixed, as of 4.6.1
Toon, > Perhaps some kind soul with access to bugzilla can close this one. Done, Dominique
Revision 180821 breaks bootstrap
Revision 180821 breaks bootstrap on x86_64-apple-darwin10: ../../work/gcc/collect2.c: In function 'int main(int, char**)': ../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr' [-Werror=unused-variable] cc1plus: all warnings being treated as errors Note that I did not find any entry for this revision in gcc-patc...@gcc.gnu.org. TIA Dominique
Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"
> Just to make sure nobody is midled by th subject of your message: > your bootstrap problem obviously has nothing to do with the warning itself. > The latter has been discussed already on these mailing lists, is absolutely > bening. I have open pr51094 for this bootstrap failure. Note that it is due to r181279 (r181278 is a date bump). Cheers, Dominique
Re: [PATCH, testsuite]: Do not run simulate-thread on alpha*-*-linux*
Hi Uros, Is your patch dealing with gcc.dg/simulate-thread/atomic-other-* running for ever without timeout? If yes, I have seen the same problem on powerpc-apple-darwin9. Could you add powerpc*-apple-darwin* to your patch? TIA Dominique
Re: [PATCH, testsuite]: Do not run simulate-thread on alpha*-*-linux*
For the record, Jakub's comment on IRC: > with older gdb you simply had to find the stwcx > or whatever SC insn is, put a breakpoint after > it and continue instead of single stepping Dominique
Re: weird optimization in sin+cos, x86 backend
While I fail to see how the "correct value" of cos(4.47460300787e+182)+sin(4.47460300787e+182) can be defined in the 'double' world, cos^2(x)+sin^2(x)=1 and sin(2*x)=2*sin(x)*cos(x) seems to be verified (at least for this value) even if the actual values of sin and cos depends on the optimisation level. Note that sqrt(2.0)*sin(4.47460300787e+182+pi/4) gives a diffeent value for the sum. Cheers, Dominique
Re: [testsuite] darwin leftover .dSYM dirs in the testsuite ?
Hi Bernhard,
Thanks for the "Not a patch!". I have started to play with it.
In order to get something working I had to add
rename standard_file ""
rename saved-standard_file standard_file
at the end of the proc remove-build-dir, otherwise I had only errors
ERROR: gcc.c-torture/compile/2105-2.c -O3 -g : error executing dg-final:
can't rename to "saved-standard_file": command already exists
I don't have any idea of the impact of this kludge on the time
taken by the test (I'll try to figure out that later).
AFAICT the number of *.dSYM directories for gcc is reduced from
over 1400 to less than 270, not too bad, but not perfect;-)
This may due to several errors I see. They are of two classes:
...
ERROR: gcc.dg/20040813-1.c: error executing dg-final: scan-assembler: too many
arguments
ERROR: gcc.dg/20060410.c: error executing dg-final: scan-assembler: too many
arguments
...
ERROR: c-c++-common/gomp/atomic-12.c: error executing dg-final: wrong # args:
should be "cleanup-tree-dump suffix"
ERROR: c-c++-common/gomp/atomic-13.c: error executing dg-final: wrong # args:
should be "cleanup-tree-dump suffix"
...
and
...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
ERROR: tcl error sourcing
/opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
while executing
"error "torture-init: torture_without_loops is not empty as expected""
invoked from within
"if [info exists torture_without_loops] {
error "torture-init: torture_without_loops is not empty as expected"
}"
(procedure "torture-init" line 4)
invoked from within
"torture-init"
(file "/opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp" line 48)
invoked from within
"source /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
...
Although my Tcl is a little bit rusty, I think I can debug the first kind of
errors.
The second kind will require to understand why torture_without_loops is not
empty, hence some of the dejagnu machinery.
Before starting debugging, I wonder if it would not be simpler to execute a
"rm -rf *.sYM" in the *.lof directories at the end of each test class (gcc,
g++, ...).
Cheers,
Dominique
Re: RFC: -Wall by default
> >> We do have regular requests for this, so it is not just out of thin > >> air. > > > > Perhaps, but I think that changing the default like this is far too > > invasive. ?GCC should do what it's told, if a user asks for warnings, > > give them, if they don't, then don't. > > It is hard to define "what it is told" means -- we are already in gray > zone. > > > I suspect changing the default like this will generate a flood of > > complaints. > > Really? Such as what? At least me!-(how many "regular requests" compared to the number of gcc users?). > If we get floods of complaints, that can only that -Wall too many > false positives; > but I don't think it does. We have been careful over the years to > watch for that effect. [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.c | wc -l 1060 [macbook] gcc/work% grep ATTRIBUTE_UNUSED gcc/*.h | wc -l 21 Doesn't that count as "false positives"? While -Wunused can help to spot some "copy&paste" errors, most of the time the warning just reflects some harmless sloppyness. IMO only the warnings in C that are likely errors should be the default as it is in gfortran (don't ask for examples of such warnings for C, I am quasi-illiterate). Dominique PS -Wall is a simple enough option to be remembered by all users who need it (if they don't use it, they don't want it).
Re: GNU MPC 1.0 release candidate
Test on x86_64-apple-darwin10 GMP: include 5.0.4, lib 5.0.4 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.8.0 PASS: tget_version === All 64 tests passed === Dominique
Re: complete_unrolli / complete_unroll
IIRC another code that is "improved" by complete_unrolli is the polyhedron test induct.f90. However it gives worse results for some variants (see pr34265: induct_v2/3). > Can't we use graphite to re-roll loops? ... Is doing and undoing always some kind of work? Cheers Dominique
Re: What is -gtoggle useful for?
Diego, > In fact, it'd be nice to hide some other flags, but that's another problem. Absolutely, I think the user flags should be well separated from the developer ones. Cheers Dominique
Re: Call for testers: MPC 0.7 prerelease tarball
Kaveh, mpc-0.7-dev passed the 45 tests on i686-apple-darwin9 when compiled with gcc version 4.0.1 (Apple Inc. build 5493). Cheers Dominique
Re: Anyone for slush?
> Should we perhaps, again? I'm having trouble fixing one bootstrap-breaking > bug because of a second one that's piled in on top of it right now; how is it > for other targets? Bad for darwin!-(bootstrap failing since at least r151822, see pr41405). If you add pr41407+others, a slush should be applied untill the whole mess is sorted out. Just my 1c of advice. Cheers Dominique
Re: the Right place to change a target default for a common compiler flag?
Iain, I am currently bootstrapping on i686-apple-darwin9 with the current patch: diff -uN /opt/gcc/_gcc_clean/config/mh-intel-darwin /opt/gcc/gcc-4.5-work/config/mh-intel-darwin --- /opt/gcc/_gcc_clean/config/mh-intel-darwin 1970-01-01 01:00:00.0 +0100 +++ /opt/gcc/gcc-4.5-work/config/mh-intel-darwin2009-09-23 13:47:12.0 +0200 @@ -0,0 +1,3 @@ +# Set strict-dwarf for Darwin + +BOOT_CFLAGS += -gstrict-dwarf diff -uN /opt/gcc/_gcc_clean/config/mh-ppc-darwin /opt/gcc/gcc-4.5-work/config/mh-ppc-darwin --- /opt/gcc/_gcc_clean/config/mh-ppc-darwin2008-02-25 11:00:23.0 +0100 +++ /opt/gcc/gcc-4.5-work/config/mh-ppc-darwin 2009-09-23 12:07:12.0 +0200 @@ -2,4 +2,4 @@ # position-independent-code -- the usual default on Darwin. This fix speeds # compiles by 3-5%. -BOOT_CFLAGS += -mdynamic-no-pic +BOOT_CFLAGS += -mdynamic-no-pic -gstrict-dwarf --- /opt/gcc/_gcc_clean/configure 2009-09-22 20:04:27.0 +0200 +++ /opt/gcc/gcc-4.5-work/configure 2009-09-23 13:50:29.0 +0200 @@ -3655,6 +3655,12 @@ powerpc-*-darwin*) host_makefile_frag="config/mh-ppc-darwin" ;; + i[3456789]86-*-darwin*) +host_makefile_frag="config/mh-intel-darwin" +;; + x86_64-*-darwin[912]*) +host_makefile_frag="config/mh-intel-darwin" +;; powerpc-*-aix*) host_makefile_frag="config/mh-ppc-aix" ;; I am currently at stage 3 and I see -gstrict-dwarf in the log file. I don't know if it is the Right place, but it seems to work so far. Cheers, Dominique
Re: the Right place to change a target default for a common compiler flag?
With the previous patch, bootstrap failed when building libgomp: -gstrict-dwarf was not passed during the configure stage. So it is not sufficient to pass it to BOOT_CFLAGS. Would repeating the trick for CFLAGS_FOR_TARGET have a chance to work? Dominique
Re: further help on dwarf2 debug
With revision 152076 on i686-apple-darwin9 bootstrapped as described in comment#61 of pr41405, I get: [ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose-asm -gno-strict-dwarf simplistic.c [ibook-dhum] bug/debug% dwarfdump --debug-frame simplistic.o -- File: simplistic.o (i386) -- .debug_frame contents: 0x: CIE length: 0x0010 CIE_id: 0x version: 0x01 augmentation: "" code_align: 1 data_align: -4 ra_register: 0x08 DW_CFA_def_cfa (esp, 4) DW_CFA_offset (eip, 0) DW_CFA_nop DW_CFA_nop Instructions: Init State: CFA=esp+4 eip=[esp+4] 0x0014: FDE length: 0x0028 CIE_pointer: 0x start_addr: 0x testfunc range_size: 0x0012 (end_addr = 0x0012) Instructions: 0x: CFA=esp+4 eip=[esp+4] DW_CFA_advance_loc4 (1) DW_CFA_def_cfa_offset (8) DW_CFA_offset (ebp, -8) 0x0001: CFA=esp+8 ebp=[esp] eip=[esp+8] DW_CFA_advance_loc4 (2) DW_CFA_def_cfa_register (ebp) 0x0003: CFA=ebp+8 ebp=[ebp] eip=[ebp+8] DW_CFA_advance_loc4 (14) DW_CFA_restore (ebp) DW_CFA_def_cfa (esp, 4) DW_CFA_nop DW_CFA_nop DW_CFA_nop 0x0011: CFA=esp+4 ebp=[esp-4] eip=[esp+4] (same result with -gstrict-dwarf). Following Jakub Jelinek's advice (sorry I cannot find the post) I have tried the tests in gcc/testsuite/gcc.dg/guality/, but did not get any failure. Cheers, Dominique
Re: GCC freezing for a Multiply Chain
I wonder if this is not pr41043. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043 Dominique
Questions about "Handle constant exponents." in gcc/builtins.c
In the block "Handle constant exponents." in gcc/builtins.c, the condition !optimize_size has been replaced with optimize_insn_for_speed_p () between gcc 4.3 and 4.4, but I have not been able to find when and why. Does anybody remembers the when and why? This change make the optimization sensitive to PR40106 and unless it has compeling reasons it should be reverted in this piece of code. My second question is why using optimize_size? I think it would be better to define an upper bound instead of POWI_MAX_MULTS that depends on the kind of optimisation. I cannot see any situation in which sqrt(a) would not be better that pow(a,0.5) for speed, size, and accuracy. TIA Dominique
Re: Questions about "Handle constant exponents." in gcc/builtins.c
May I remind my original question: > In the block "Handle constant exponents." in gcc/builtins.c, the condition > !optimize_size has been replaced with optimize_insn_for_speed_p () between > gcc 4.3 and 4.4, but I have not been able to find when and why. > Does anybody remembers the when and why? This change has been commited by someone and should have been approved by someone else. TIA Dominique
Re: Questions about "Handle constant exponents." in gcc/builtins.c
> Google is your friend... Thanks Jack. As you can see in comment #46 of pr40106, I have found my own way. In my previous attempts I have made two mistakes: (1) I tried to use the search engine of the gcc mailing lists that kept parsing optimize_insn_for_speed_p as if the _ were spaces. (2) I did not realized that the history in only kept in trunk. > svn blame is your friend, ... When I report a pr I am not interested at all to blame anything or anybody, only to see the pr fixed ASAP;-) Cheers, Dominique PS For the ongoing discussion about the equivalence between sqrt(x) and pow(x, 0.5), I'll only say that some influent people should learn some basic math!
Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee
With revision 156618, grepping the assembly of gcc/testsuite/gcc.dg/matrix/transpose-1.c for gcov_indirect, I get movq___gcov_indirect_call_callee(%rip), %rcx movq___gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler movq$0, ___gcov_indirect_call_callee(%rip) movq___gcov_indirect_call_callee(%rip), %rcx movq___gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler movq$0, ___gcov_indirect_call_callee(%rip) movq___gcov_indirect_call_callee(%rip), %rcx movq___gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler movq$0, ___gcov_indirect_call_callee(%rip) .lcomm ___gcov_indirect_call_callee,8,3 .lcomm ___gcov_indirect_call_counters,8,3 With revision 157836, I get leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi call___gcov_indirect_call_profiler leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi What is the origin of the "_emutls_v." "decoration"? Dominique
Question about perl while bootstrapping gcc
Hi! I use to build gcc with a command line such as make -j2 >& somelogfile & I recently found that if I logout, the build fails with perl: no user 501 Is this a bug or a feature? In the former case I'll open a PR. In the later is it documented somewhere that you should not logout while building gcc? If yes, is it possible to have a pointer? TIA Dominique
Loops no longer vectorized
Hi, I just noticed today that (implicit) loops of the kind xmin = minval(nodes(1,inductor_number(1:number_of_nodes))) (lines 5057 to 5062 of the polyhedron test induct.f90) are no longer vectorized (the change occurred between revisions 158215 and 158921). With -ftree-vectorizer-verbose=6, I got induct.f90:5057: note: not vectorized: data ref analysis failed D.6088_872 = (*D.4001_143)[D.6087_871]; induct.f90:5057: note: Alignment of access forced using peeling. induct.f90:5057: note: Vectorizing an unaligned access. induct.f90:5057: note: vect_model_load_cost: unaligned supported by hardware. induct.f90:5057: note: vect_model_load_cost: inside_cost = 2, outside_cost = 0 . induct.f90:5057: note: vect_model_simple_cost: inside_cost = 2, outside_cost = 0 . induct.f90:5057: note: vect_model_store_cost: inside_cost = 2, outside_cost = 0 . induct.f90:5057: note: cost model: prologue peel iters set to vf/2. induct.f90:5057: note: cost model: epilogue peel iters set to vf/2 because peeling for alignment is unknown . induct.f90:5057: note: Cost model analysis: Vector inside of loop cost: 6 Vector outside of loop cost: 20 Scalar iteration cost: 3 Scalar outside cost: 7 prologue iterations: 2 epilogue iterations: 2 Calculated minimum iters for profitability: 5 induct.f90:5057: note: Profitability threshold = 4 induct.f90:5057: note: Profitability threshold is 4 loop iterations. induct.f90:5057: note: LOOP VECTORIZED. and now: induct.f90:5057: note: not vectorized: data ref analysis failed D.6017_848 = (*D.4001_131)[D.6016_847]; Is this known/expected or should I open a new PR? Cheers Dominique
Re: Loops no longer vectorized
Ira, Thanks for the answer. > The loop that got vectorized in the older revision is another loop > associated with the same source code line: Upon further investigation this loops is likely related to a temporary that have been removed in recent versions. Using the older revision with -Warray-temporaries gives: ... induct.f90:5057.30: xmin = minval(nodes(1,inductor_number(1:number_of_nodes))) 1 Warning: Creating array temporary at (1) ... not present in more recent revisions. Dominique
problem building gcc4-4.3.0-20070209
While building the gcc4-4.3.0-20070209 snapshot, I got the error ... checking for correct version of gmp.h... no configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+. ... I am using the same script that worked last week and I have gmp 4.2.1 and mpfr 2.2.1 since several builds. I am using a Mac OSX 10.3.9. Can someone give me a pointer the change(s) that might explain the breakage. TIA Dominique
Re: problem building gcc4-4.3.0-20070209
Daniel,
Thanks for the answer.
> You need to show us your configure arguments to be sure. I bet
> you're specifying just --host.
You are right, the configure I am using since some time is:
ConfigureParams: --prefix=%p/lib/gcc4 --disable-multilib
--enable-languages=c,c++,fortran,objc,java
--infodir='${prefix}/share/info' --with-gmp=%p --with-included-gettext
--host=%m-apple-darwin`uname -r|cut -f1 -d.`
--with-as=%p/lib/odcctools/bin/as --with-ld=%p/lib/odcctools/bin/ld
--with-nm=%p/lib/odcctools/bin/nm --with-ar=%p/lib/odcctools/bin/ar
--with-strip=%p/lib/odcctools/bin/strip
--with-ranlib=%p/lib/odcctools/bin/ranlib
(several --with are probably not necessary), so the breakage seems related to
some
changes made during the last week. I won't have much time to look at the
problem right now. Would something like
--build=%m-apple-darwin`uname -r|cut -f1 -d.`
work?
TIA
Dominique
Re: problem building gcc4-4.3.0-20070209
I have written: > Would something like > --build=%m-apple-darwin`uname -r|cut -f1 -d.` > work? Apparently it works. Thanks Dominique
Re: problem building gcc4-4.3.0-20070209
The discussion is becoming to technical for me. Let me just say that adding --build=%m-apple-darwin`uname -r|cut -f1 -d.` to config allowed me to build gcc without further glitch. I guess it will do no harm to keep this addition even if it becomes no longer necessary. Thanks for the help Dominique
What is the value of TARGET_C99_FUNCTIONS on Darwin?
Following the discussions for PR30969, PR30980, and PR31161, it appears that TARGET_C99_FUNCTIONS is not set on OSX 10.3.9 nor OSX 10.4.9. Is this in line with the comment /* Old versions of Mac OS/Darwin don't have C99 functions available. */ in gcc/config/rs6000/darwin.h? and #undef TARGET_C99_FUNCTIONS #define TARGET_C99_FUNCTIONS\ (TARGET_64BIT \ || strverscmp (darwin_macosx_version_min, "10.3") >= 0) TIA Dominique
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
Mike,
Thanks for the answer, but I understand very little of it.
> The above can be read as:
>
> If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
> otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
> is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so good.
we are targeting means that flag:
> -mmacosx-version-min=version
> The earliest version of MacOS X that this executable will
> run on is version.
> Typical values of version include 10.1, 10.2, and 10.3.9.
>
> The default for this option is to make choices that seem
> to be most useful.
Is this under the user control and how?
> though, the exact default for this flag is changing (has change, is
> going to change).
I noticed that!
> For example, if you tell it,
How could I? I would be interested by 10.3.9 (possibly 10.4.9).
> you are going to generate code for 10.1, then, TARGET_C99_FUNCTIONS is false.
>
> We used to default to 10.1, in later versions, we default it this way:
>
> #define DARWIN_MINVERSION_SPEC \
>"%{m64:%{fgnu-runtime:10.4; \
> ,objective-c|,objc-cpp-output:10.5; \
> ,objective-c++|,objective-c++-cpp-output:10.5; \
> :10.4}; \
> shared-libgcc:10.3;\
> :10.1}"
>
> for ppc, and x86 defaults it this way:
>
> /* Determine a minimum version based on compiler options. */
> #define DARWIN_MINVERSION_SPEC \
> "%{!m64|fgnu-runtime:10.4; \
> ,objective-c|,objc-cpp-output:10.5; \
> ,objective-c++|,objective-c++-cpp-output:10.5; \
> :10.4}"
This is a part I cannot decipher.
Dominique
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
Eric, Thanks for the explanations. > The idea, I believe, is that the default will be the system that you > are currently on. It would be nice, but it is not the way it seems to work (at least for gcc, for g++ and gfortran it may, but I am not sure). For instance I have a version of 4.3.0 on 10.4. Without -mmacosx-version-min=10.4 I get [pbook] test/tests% gcc-4 failure_v2.c failure_v2.c: In function 'main': failure_v2.c:15: sorry, unimplemented: no way to expand a call to 'cexpi' i.e. __builtin_cexpi does not exist, with the option the program compiles. So it seems to work. On 10.3.9 I get: /sw/lib/odcctools/bin/ld: warning unknown -macosx_version_min parameter value: 10.3.9 ignored (using 10.1) with Apple Computer, Inc. version odcctools-590.36od13. Is there a way to set -mmacosx-version-min when building gcc, g++, gfortran, ...? If these compilers are build with the default setting (10.1?) do they obey the -macosx_version_min if, for instance, cexpi fallback to cexp? These questions are motivated by PR31249 in which I report that optimizing the computation of cos(x) and sin(x) by cexpi(x) gives worse results on OSX. Dominique
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
> The new method will be that the default will be the system that you are > currently on. It's not the default now. How new is new? As far as I can tell, it did not work for the 20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and friends which do not pass for the 20070316 snapshot, it is far from obvious that it is working. Is there a direct way to check it? TIA Dominique
Re: What is the value of TARGET_C99_FUNCTIONS on Darwin?
> It's not yet checked in :) So, I'll wait!-) Dominique
Re: Running GCC tests on installed compiler
Gerald,
Thanks (late) for the patch. I have some new questions:
(1) I get the following errors:
ERROR: can't read "HOSTCC": no such variable
while executing
"remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd""
invoked from within
"set status [remote_exec host "$HOSTCC $HOSTCFLAGS $generator_cmd"]"
(file
"/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
line 93)
invoked from within
"source
/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
from
ERROR: tcl error sourcing
/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp.
ERROR: tcl error sourcing
/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/g++.dg/compat/struct-layout-1.exp.
ERROR: tcl error sourcing
/Users/dominiq/test/gcc-4.3-20070316/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp.
I guess that the environment variables HOSTCC and HOSTCFLAGS should be
set within the script, but I have no idea about their expected values.
(2) Presently the test is for gcc, g++, gfortran, and objc. Looking at
http://gcc.gnu.org/ml/gcc-testresults/, I see that most tests are also
for libffi, libgomp, libjava, and libstdc++. Would it be difficult
to add them?
TIA
Dominique
Building gcc4-4.3.0-20070331 fails on PPC Darwin7
Building gcc4-4.3.0-20070331 fails on PPC Darwin7 with: ... /sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -I../../gcc-4.3-20070331/libcpp -I. -I../../gcc-4.3-20070331/libcpp/../include -I./../intl -I../../gcc-4.3-20070331/libcpp/include -g -O2 -mdynamic-no-pic -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../gcc-4.3-20070331/libcpp -I. -I../../gcc-4.3-20070331/libcpp/../include -I./../intl -I../../gcc-4.3-20070331/libcpp/include -c -o directives.o -MT directives.o -MMD -MP -MF .deps/directives.Po ../../gcc-4.3-20070331/libcpp/directives.c cc1: warnings being treated as errors ../../gcc-4.3-20070331/libcpp/directives.c: In function 'lex_macro_node_from_str': ../../gcc-4.3-20070331/libcpp/directives.c:2086: error: pointer targets in initialization differ in signedness make[3]: *** [directives.o] Error 1 make[2]: *** [all-stage2-libcpp] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Re: Building gcc4-4.3.0-20070331 fails on PPC Darwin7
> Re-update and build again, should work now I think. Yes, the problem is now fixed, thanks. Dominique
gcc regression on Darwin
While regtesting my build of the 20070330 snapshot (Darwin7), I got a lot (~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ..., gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found that this has started on 20070325 for Darwin8: http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html Note that the errors are all of the following kind: output is: /var/tmp//cceFaqh1.s:2000:non-relocatable subtraction expression, "L006$pb" minus "LSJR191" /var/tmp//cceFaqh1.s:2000:symbol: "LSJR191" can't be undefined in a subtraction expression ... I tried to see if this regression has been reported, but found nothing. Did I miss something or should I fill a PR? If yes what would be the best format? TIA Dominique
Re: Call to arms: testsuite failures on various targets
> * powerpc-apple-darwin8.5.0: gfortran.dg/edit_real_1.f90 I don't see these failures on my weekly snapshot build on OSX 10.3.9 (nor in a month old build on OSX 10.4.8 or 9, cannot remember). Could it be related to 10.4.5 gcc failures gcc.dg/torture/builtin-pow-mpfr-1.c and gcc.dg/torture/builtin-sin-mpfr-1.c I don't see either with my builds? > Note2: I also omitted a couple of gfortran.dg/secnds.f failures; this > testcase should be reworked see that too now and then. I have also done the following experiment with large_real_kind_2.F90: (1) compiled with -S (2) edited large_real_kind_2.s to add $LDBL128 where appropriate (e.g., .indirect_symbol _expl$LDBL128) (3) assembled the result (4) linked the object and the executable passed the tests. So it should not be too difficult for someone who knows what to do to fix this part of the problem. Making large_real_kind_form_io_2.f90 to works will probably requires more work because, as far as I understand the problem, the corresponding changes have to be done in libgfortran. I don't have the knowledge, nor the time, to do the change myself, but I can test patches. Dominique
libffi failures on powerpc-apple-darwin7.9.0
I managed to regtest libffi and got the following summary: === libffi tests === Running target unix FAIL: libffi.call/cls_align_longdouble.c -O0 -W -Wall output pattern test, is 12 7.29112e-304 191 0 1.98612e-309 0: 12 7.29114e-304 191 FAIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test FAIL: libffi.call/cls_align_longdouble.c -O2 output pattern test, is 12 7.29112e-304 143 0 1.98612e-309 0: 12 -1.38837e-231 143 FAIL: libffi.call/nested_struct5.c -O2 execution test FAIL: libffi.call/cls_align_longdouble.c -O3 output pattern test, is 12 7.29112e-304 143 0 1.98612e-309 0: 12 -1.38837e-231 143 FAIL: libffi.call/nested_struct5.c -O3 execution test FAIL: libffi.call/cls_align_longdouble.c -Os output pattern test, is 12 7.29112e-304 143 0 1.98612e-309 0: 12 -1.38837e-231 143 FAIL: libffi.call/nested_struct5.c -Os execution test === libffi Summary === # of expected passes1084 # of unexpected failures8 # of unsupported tests 8 Is this something expected or is there yet another bug in OSX 10.3.9? TIA Dominique PS These results were obtained after some terrible hack of libffi/testsuite/lib/libffi-dg.exp. Is there someone around able to help me to do a cleaner post-install regtest?
building gcc4-4.3.0-20070518 failed
building snapshot gcc4-4.3.0-2007051 failed with: ... # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh ../../../gcc-4.3-20070519/libgcc/../mkinstalldirs . /sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.3.0-20070519/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin7/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin7/include -isystem /sw/lib/gcc4/powerpc-apple-darwin7/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -install_name /sw/lib/gcc4/lib/libgcc_s`if test . = ppc64 ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -O2 -mdynamic-no-pic -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o darwin-fallback_s.o emutls_s.o -lc /sw/lib/odcctools/bin/ld: warning -dylib_install_name /sw/lib/gcc4/lib/libgcc_s.1.dylib not found in segment address table LD_SEG_ADDR_TABLE /sw/var/lib/fink/prebound/seg_addr_table /sw/lib/odcctools/bin/ld: _enable_execute_stack_s.o has local relocation entries in non-writable section (__TEXT,__text) collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage2-target-libgcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 ### execution of /var/tmp/tmp.1.cQ7m20 failed, exit code 2 Is this related to the fact that the last regression testing on Darwin is: Results for 4.3.0 20070514 (experimental) testsuite on powerpc64-apple-darwin8.8.0 (unless I missed something)? TIA Dominique
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
Sorry, but I have just realized that I have forgotten to give the OS: OSX 10.3.9, PPC. Also the last week snapshot built without problem. TIA Dominique
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
Comparing the log of successful and failed builds I have found that the failed one contains -mdynamic-no-pic which does not appear in the previous build. According Apple's doc this should be used in "application", but it should not appear when building libraries (at least it is my understanding). I suspect the origin of the problem comes from 2007-05-16 Paolo Bonzini <[EMAIL PROTECTED]> * Makefile.def (bootstrap_stage): Replace stage_make_flags with stage_cflags. * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS, POSTSTAGE1_FLAGS_TO_PASS): Remove CFLAGS/LIBCFLAGS. (configure-stage[+id+]-[+prefix+][+module+], all-stage[+id+]-[+prefix+][+module+]): Pass it from [+stage_cflags+]. * Makefile.in: Regenerate. but there are too many changes to allow me to go further. BTW I also noticed the nicety ... -O2 -O2 -g -O2 ... -g -O2 ... (was ... -O2 -O2 -g -O2 ... -O2 -g -O2 ...) TIA Dominique
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
> In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in I used the files from trunk revision 124627 and the build went fine. I'll try to find some time to fill a PR Dominique
Re: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
> Thanks, You're welcome! This is PR32009. Cheers Dominique
compiling: gcc4-4.3.0-20070525 failed
On OSX 10.3.9 compiling gcc4-4.3.0-20070525 failed with: ... /bin/sh ./libtool --tag=GCJ --mode=compile /sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc-4.3-20070526/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o java/lang/Class.lo -fsource-filename=../../../gcc-4.3-20070526/libjava/java/lang/Class.java ../../../gcc-4.3-20070526/libjava/classpath/lib/java/lang/Class.class libtool: compile: /sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc-4.3-20070526/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=../../../gcc-4.3-20070526/libjava/java/lang/Class.java ../../../gcc-4.3-20070526/libjava/classpath/lib/java/lang/Class.class libtool: compile: mv -f "Class.o" "java/lang/.libs/Class.o" libtool: compile: /sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc-4.3-20070526/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=../../../gcc-4.3-20070526/libjava/java/lang/Class.java ../../../gcc-4.3-20070526/libjava/classpath/lib/java/lang/Class.class >/dev/null 2>&1 libtool: compile: mv -f "Class.o" "java/lang/Class.o" echo ../../../gcc-4.3-20070526/libjava/classpath/lib/java/lang/PosixProcess*.class > java/process-Posix.list /bin/sh ./libtool --tag=GCJ --mode=compile /sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc-4.3-20070526/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o java/process-Posix.lo -fsource-filename=/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/classpath/lib/classes -MT java/process-Posix.lo -MD -MP -MF java/process-Posix.deps @java/process-Posix.list libtool: compile: /sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/gcj -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/gcc/ -fclasspath= -fbootclasspath=../../../gcc-4.3-20070526/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/sw/src/fink.build/gcc4-4.3.0-20070526/darwin_objdir/powerpc-apple-darwin7/libjava/classpath/lib/classes -MT java/process-Posix.lo -MD -MP -MF java/process-Posix.deps @java/process-Posix.list libtool: compile: mv -f "process-Posix.o" "java/.libs/process-Posix.o" mv: ne peut 'evaluer `process-Posix.o': No such file or directory make[3]: *** [java/process-Posix.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-target-libjava] Error 2 make: *** [all] Error 2 TIA Dominique PS I applied the Andrew Pinski' patch #125087 in the hope to be on the safe side.
Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time of the polyhedron test suite increased by 35% compared to the previous snapshot and by 41% compared to the Apr 13 one: compile execute 06/15 06/08 04/13 06/13 06/08 04/13 ac 6.098 4.169 3.754 141.335 141.271 140.479 aermod 266.403 205.639 196.447 92.75693.58390.632 air 14.77311.92511.541 40.14941.53339.399 capacita 7.332 5.542 5.154 175.615 176.229 177.222 channel 4.289 2.519 2.279 15.66415.94715.732 doduc 37.70028.04026.679 68.59968.89568.195 fatigue 12.843 8.733 8.293 23.76624.79523.061 gas_dyn 11.856 8.168 7.598 53.94253.92952.100 induct 36.87823.67122.445 72.24773.03169.283 linpk2.419 1.979 1.910 33.48933.84433.446 mdbx 9.052 7.036 6.716 32.54232.54332.985 nf 5.412 3.629 3.357 51.42451.40458.494 protein 20.09713.16213.063 70.82570.11370.896 rnflow 19.81214.37014.196 76.93677.41976.371 test_fpu17.09812.03411.396 37.33637.32437.697 tfft 2.530 1.938 1.779 16.65316.83116.581 total 474.592 352.554 336.6071003.278 1008.691 1002.573 without any noticable effects on the execution time. Does anyone can explain it (and suggest a fix)? TIA Dominique
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
> I did not see this change. What flags are you using? gfortran -w -O3 -ffast-math -funroll-loops Dominique
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
Exctracted from http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt: date compile execute 070608 106.29 628.74 070615 117.43 629.73 070620 105.95 616.99 So these tests show a ~10% increase of the compilation time from 070612 to 070618. I have forgotten to mention that my timings were done on a 1.8Ghz G5 with 512k of cache. My observation is that when something goes wrong on the x86 family it is several time worse on the PPC. This is particularly important when cache misses are involved. So I'll wait for the next snapshot and report what I see. Cheers Dominique
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
> Maybe you can identify the single most increase for ppc? The ranking is: compile 06/15 06/08% channel 4.289 2.519 70 induct 36.87823.671 56 protein 20.09713.162 53 nf 5.412 3.629 49 fatigue 12.843 8.733 47 ac 6.098 4.169 46 gas_dyn 11.856 8.168 45 test_fpu17.09812.034 42 rnflow 19.81214.370 38 doduc 37.70028.040 34 capacita 7.332 5.542 32 aermod 266.403 205.639 30 tfft 2.530 1.938 31 mdbx 9.052 7.036 28 air 14.77311.925 24 linpk2.419 1.979 22 % = 100*(t0615/t0608-1) So the worst increase is for channel (ironically this has always been the strongest gfortran result!), but all tests show an increase above 20%. Dominique
FAIL: gcc.dg/pragma-darwin.c
The test FAIL: gcc.dg/pragma-darwin.c fails with
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 17)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 18)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 19)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 67)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 68)
FAIL: gcc.dg/pragma-darwin.c (test for excess errors)
(see http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00621.html)
Apparently gcc 4.3 emits only warnings while the test expects errors:
...
#pragma options 23 /* { dg-error "malformed '#pragma options'" } */
#pragma options align /* { dg-error "malformed '#pragma options'" } */
#pragma options align natural /* { dg-error "malformed '#pragma options'" } */
#pragma options align=45 /* { dg-error "malformed '#pragma options'" } */
#pragma options align=foo /* { dg-error "malformed '#pragma options align" } */
...
#pragma unused /* { dg-error "missing '.' after '#pragma unused" } */
#pragma unused (a /* { dg-error "missing '.' after '#pragma unused" } */
...
TIA
Dominique
Re: Severe increase in compilation time with 4.3.0 20070615 on powerpc-apple-darwin7
> Btw, is this a compiler with checking enabled? As fas as I can tell, yes. > If so try comparing numbers with --enable-checking=release. I am more interested to compare times rather than get the lowest possible number. The following update of the timings shows that the compile time is worsening without positive impact on the execution time: compile execute 07/13 06/15 06/08 04/13 07/13 06/15 06/08 04/13 ac 6.101 6.098 4.169 3.754 141.067 141.335 141.271 140.479 aermod 280.850 266.403 205.639 196.447 93.91492.756 93.58390.632 air 15.82314.77311.92511.541 41.59840.149 41.53339.399 capacita 7.545 7.332 5.542 5.154 177.666 175.615 176.229 177.222 channel 4.224 4.289 2.519 2.279 15.71315.664 15.94715.732 doduc 38.83437.70028.04026.679 68.60468.599 68.89568.195 fatigue 14.89712.843 8.733 8.293 24.45923.766 24.79523.061 gas_dyn 11.89311.856 8.168 7.598 54.01853.942 53.92952.100 induct 37.13136.87823.67122.445 71.68072.247 73.03169.283 linpk2.389 2.419 1.979 1.910 33.43533.489 33.84433.446 mdbx 9.428 9.052 7.036 6.716 32.56632.542 32.54332.985 nf 5.409 5.412 3.629 3.357 57.32851.424 51.40458.494 protein 20.16720.09713.16213.063 72.80970.825 70.11370.896 rnflow 19.95819.81214.37014.196 77.14976.936 77.41976.371 test_fpu17.48317.09812.03411.396 37.14637.336 37.32437.697 tfft 2.513 2.530 1.938 1.779 16.60216.653 16.83116.581 total 494.645 474.592 352.554 336.6071015.754 1003.278 1008.691 1002.573 I have done the following comparison of the compile time for induct.f90 with -ftime-report. Half of the ~15s is coming from 'loop analysis' (7s) and 'expand' account for 1s. Assuming that the lines starting by 'df' were introduced by the 'dataflow' patch, it can explain directly at most a few seconds. Does anybody understand why 'loop analysis' takes so much time on Darwin7? TIA Dominique gcc version 4.3.0 20070713 (experimental) [karma] lin/source% time gfortran -ftime-report -O3 -ffast-math -funroll-loops induct.f90 Execution times (seconds) loop analysis : 7.56 (21%) usr 0.19 ( 6%) sys 7.80 (19%) wall 1192 kB ( 2%) ggc tree STMT verifier: 4.80 (13%) usr 0.62 (19%) sys 5.34 (13%) wall 2 kB ( 0%) ggc tree SSA verifier : 3.70 (10%) usr 0.07 ( 2%) sys 3.87 (10%) wall 26 kB ( 0%) ggc expand: 1.99 ( 6%) usr 0.18 ( 6%) sys 2.21 ( 5%) wall 4996 kB (10%) ggc tree operand scan : 0.96 ( 3%) usr 0.56 (17%) sys 1.50 ( 4%) wall 2180 kB ( 4%) ggc global alloc : 0.79 ( 2%) usr 0.08 ( 2%) sys 0.85 ( 2%) wall 1065 kB ( 2%) ggc scheduling: 0.73 ( 2%) usr 0.06 ( 2%) sys 0.81 ( 2%) wall 285 kB ( 1%) ggc tree PRE : 0.72 ( 2%) usr 0.04 ( 1%) sys 0.78 ( 2%) wall 2445 kB ( 5%) ggc rename registers : 0.69 ( 2%) usr 0.02 ( 1%) sys 0.73 ( 2%) wall 257 kB ( 1%) ggc CSE : 0.66 ( 2%) usr 0.06 ( 2%) sys 0.67 ( 2%) wall 264 kB ( 1%) ggc scheduling 2 : 0.62 ( 2%) usr 0.01 ( 0%) sys 0.63 ( 2%) wall 60 kB ( 0%) ggc CFG verifier : 0.62 ( 2%) usr 0.04 ( 1%) sys 0.48 ( 1%) wall 0 kB ( 0%) ggc df live regs : 0.61 ( 2%) usr 0.00 ( 0%) sys 0.68 ( 2%) wall 0 kB ( 0%) ggc parser: 0.54 ( 2%) usr 0.08 ( 2%) sys 0.86 ( 2%) wall 3631 kB ( 7%) ggc garbage collection: 0.49 ( 1%) usr 0.05 ( 2%) sys 0.56 ( 1%) wall 0 kB ( 0%) ggc if-conversion : 0.44 ( 1%) usr 0.00 ( 0%) sys 0.45 ( 1%) wall 61 kB ( 0%) ggc combiner : 0.43 ( 1%) usr 0.00 ( 0%) sys 0.49 ( 1%) wall 912 kB ( 2%) ggc local alloc : 0.41 ( 1%) usr 0.01 ( 0%) sys 0.44 ( 1%) wall 752 kB ( 2%) ggc tree iv optimization : 0.40 ( 1%) usr 0.07 ( 2%) sys 0.43 ( 1%) wall 7302 kB (15%) ggc reload CSE regs : 0.32 ( 1%) usr 0.00 ( 0%) sys 0.33 ( 1%) wall 941 kB ( 2%) ggc forward prop : 0.32 ( 1%) usr 0.03 ( 1%) sys 0.37 ( 1%) wall 550 kB ( 1%) ggc alias analysis: 0.31 ( 1%) usr 0.00 ( 0%) sys 0.40 ( 1%) wall 1398 kB ( 3%) ggc dead code elimination : 0.30 ( 1%) usr 0.01 ( 0%) sys 0.30 ( 1%) wall 1 kB ( 0%) ggc tree VRP : 0.29 (
vect failures at -m64 on darwin
Jack Howarth has reported vect failures at -m64 on darwin with gfortran: http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html I see the same kind of failures with gcc 4.3.0 revision 127178: FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vectorization not profitable 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vectorized 1 loops 0 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vectorization not profitable 1 FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Vectorizing an unaligned access 2 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-44.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Alignment of access forced using peeling 3 FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times Alignment of access forced using peeling 3 FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 4 FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 2 A quick look at the *.vect files show that there is no lines with "peeling". Is this a bug in the build or in the testsuite? Dominique
Build failure on Darwin, revision 127998
After an update to revision 127998 (from 127986), make failed with: make[3]: Nothing to be done for `all'. true "AR_FLAGS=rc" "CC_FOR_BUILD=/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/sw/bin/ginstall -c" "INSTALL_DATA=/sw/bin/ginstall -c -m 644" "INSTALL_PROGRAM=/sw/bin/ginstall -c" "INSTALL_SCRIPT=/sw/bin/ginstall -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/opt/gcc/gcc4.3w" "infodir=/opt/gcc/gcc4.3w/share/info" "libdir=/opt/gcc/gcc4.3w/lib" "prefix=/opt/gcc/gcc4.3w" "tooldir=/opt/gcc/gcc4.3w/powerpc-apple-darwin8" "AR=ar" "AS=as" "CC=/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/" "CXX=g++" "LD=ld" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all'. build/gengtype ../../gcc-4.3-work/gcc gtyp-input.list echo timestamp > s-gtype /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.3-work/gcc -I../../gcc-4.3-work/gcc/build -I../../gcc-4.3-work/gcc/../include -I../../gcc-4.3-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.3-work/gcc/../libdecnumber -I../../gcc-4.3-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -o build/rtl.o ../../gcc-4.3-work/gcc/rtl.c /var/tmp//cc5X0jZP.s:765:non-relocatable subtraction expression, "___FUNCTION__.13184" minus "L006$pb" /var/tmp//cc5X0jZP.s:765:symbol: "___FUNCTION__.13184" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:763:non-relocatable subtraction expression, "___FUNCTION__.13184" minus "L006$pb" /var/tmp//cc5X0jZP.s:763:symbol: "___FUNCTION__.13184" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:511:non-relocatable subtraction expression, "___FUNCTION__.13132" minus "L004$pb" /var/tmp//cc5X0jZP.s:511:symbol: "___FUNCTION__.13132" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:509:non-relocatable subtraction expression, "___FUNCTION__.13132" minus "L004$pb" /var/tmp//cc5X0jZP.s:509:symbol: "___FUNCTION__.13132" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:239:non-relocatable subtraction expression, "___FUNCTION__.13259" minus "L003$pb" /var/tmp//cc5X0jZP.s:239:symbol: "___FUNCTION__.13259" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:237:non-relocatable subtraction expression, "___FUNCTION__.13259" minus "L003$pb" /var/tmp//cc5X0jZP.s:237:symbol: "___FUNCTION__.13259" can't be undefined in a subtraction expression make[3]: *** [build/rtl.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Any idea? TIA Dominique
Build failure on Darwin, revision 127998 (solved)
Following http://gcc.gnu.org/ml/gcc/2007-08/msg00544.html I have updated to revision 128003 and tried 'make bootstrap', then 'configure' + 'make bootstrap' without success (the same kind of failure in libgcc). I the tried a fresh install: new directory, configure, and make, and it worked. So now I have a few questions: (1) is there a simpler (cheaper) way to solve this kind of problems (deleting some files, directories, ...)? (2) is there a way to detect this kind of problem from the update result? Thanks for the help. Dominique
Re: bootstrap failing on ppc linux
Same thing here on Darwin: /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3-work/gcc -I../../gcc-4.3-work/gcc/. -I../../gcc-4.3-work/gcc/../include -I../../gcc-4.3-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.3-work/gcc/../libdecnumber -I../../gcc-4.3-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include ../../gcc-4.3-work/gcc/tree-ssa-structalias.c -o tree-ssa-structalias.o ../../gcc-4.3-work/gcc/tree-ssa-structalias.c: In function 'get_constraint_exp_from_ssa_var': ../../gcc-4.3-work/gcc/tree-ssa-structalias.c:5627: internal compiler error: tree check: expected ssa_name, have result_decl in eliminate_tail_call, at tree-tailcall.c:803 This is on the third pass (it compiles fine once with gcc and once with /opt/gcc/darwin_buildw/./prev-gcc/xgcc). I was using a simple make for revision 128092 after a successful build of revision 12806x. Dominique
Re: bootstrap failing on ppc linux (fixed)
Build succeeded with revision 128101. Thanks. Dominique
Bootstrap broken at stage1
Since yesterday ~16h GMT boostraping is broken on Darwin8 at stage1:
...
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/powerpc-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/powerpc-apple-darwin8/sys-include -g -fkeep-inline-functions
-m64 -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../../.././gcc -I../../../../gcc-4.3-work/libgcc
-I../../../../gcc-4.3-work/libgcc/. -I../../../../gcc-4.3-work/libgcc/../gcc
-I../../../../gcc-4.3-work/libgcc/../include -DHAVE_CC_TLS -o _gcov.o -MT
_gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c
../../../../gcc-4.3-work/libgcc/../gcc/libgcov.c
../../../../gcc-4.3-work/libgcc/../gcc/gcov-io.c: In function
'gcov_write_words':
../../../../gcc-4.3-work/libgcc/../gcc/gcov-io.c:242: error: invalid rtl
sharing found in the insn
(insn 126 125 127 5 (set (reg/f:DI 172)
(mem/u/c:DI (lo_sum:DI (reg:DI 173)
(const:DI (minus:DI (symbol_ref:DI
("&L___gcov_var$non_lazy_ptr") [flags 0x400] )
(symbol_ref:DI ("") [flags 0x600] [0 S8
A8])) -1 (expr_list:REG_DEAD (reg:DI 173)
(expr_list:REG_EQUAL (symbol_ref:DI ("__gcov_var") [flags 0x200]
)
(nil
../../../../gcc-4.3-work/libgcc/../gcc/gcov-io.c:242: error: shared rtx
(const:DI (minus:DI (symbol_ref:DI ("&L___gcov_var$non_lazy_ptr") [flags 0x400]
)
(symbol_ref:DI ("") [flags 0x600])))
../../../../gcc-4.3-work/libgcc/../gcc/gcov-io.c:242: internal compiler error:
internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
{standard input}:802:non-relocatable subtraction expression,
"L___gcov_var$non_lazy_ptr" minus "L005$pb"
{standard input}:802:symbol: "L___gcov_var$non_lazy_ptr" can't be undefined in
a subtraction expression
...
TIA
Dominique
Re: Someone has caused regressions in gfortran
> Sadly, the testsuite regressions don't seems to be fixed. I will try to > figure out tomorrow why the function is still being inlined. The test case gfortran.dg/do_3.F90 pass with -fno-strict-overflow (see http://gcc.gnu.org/ml/fortran/2007-09/msg00116.html). I have posted at http://gcc.gnu.org/ml/fortran/2007-09/msg00107.html a reduced test case without inlining issues showing a similar breakage. If someone can show that before the recent failure the functions were not inlined, I think the failure would be fully explained. Otherwise it will require further investigation. As far as I can tell without -fno-strict-overflow the executable reduces to a call abort at the level of if (i /= final) call abort as if final = huge(to)+1_1 giving an overflow, the comparison is assuming to always fail. I remember a lot of traffic on the gcc mailing list a couple months ago about this kind of optimization and the reasons behind -fno-strict-overflow, but I dont have the time right now to look deeper. Dominique
Re: Someone has caused regressions in gfortran
> The testcase was indeed previously not inlined at all. Shall we add > -fno-strict-overflow to the testcase then? This what I would do, but I am not qualified to make the call. In addition my working setup is totally broken right now (at stage1). Could you do the addition to the testcase and run the gfortran testsuite? From the result it would be easier to reach a conclusion. TIA Dominique
Re: Someone has caused regressions in gfortran (c_char_tests_red.f03)
I have done some investigation about the recent failure of
gfortran.dg/c_char_tests.f03. First the failure disappears
with -fno-inline or -fno-inline-functions:
[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline c_char_driver_db.c
[karma] f90/bug% a.out
[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline-functions
c_char_driver_db.c
[karma] f90/bug% a.out
Second, if I remove the line sub0();
in c_char_driver.c, the test succeeds, so the C driver can be reduced to:
[karma] f90/bug% cat c_char_driver_red.c
void sub0(void);
int main(int argc, char **argv)
{
char my_char = 'y';
sub0();
return 0;
}
with the same behavior. Now the stange part: if I try the following reduced
code:
! { dg-do run }
! { dg-additional-sources c_char_driver.c }
! Verify that character dummy arguments for bind(c) procedures can work both
! by-value and by-reference when called by either C or Fortran.
! PR fortran/32732
module c_char_tests
use, intrinsic :: iso_c_binding, only: c_char
implicit none
contains
subroutine param_test(my_char) bind(c)
character(c_char), value :: my_char
call sub1(my_char)
end subroutine param_test
subroutine sub0() bind(c)
call param_test('y')
end subroutine sub0
subroutine sub1(my_char_ref) bind(c)
character(c_char) :: my_char_ref
if(my_char_ref /= c_char_'y') call abort()
end subroutine sub1
end module c_char_tests
! { dg-final { cleanup-modules "c_char_tests" } }
I get:
[karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions
c_char_driver_red.c
[karma] f90/bug% a.out
Abort
[karma] f90/bug% gfc c_char_tests_red.f03 -O3 -fno-inline-functions -fno-inline
c_char_driver_red.c
[karma] f90/bug% a.out
Wierd, isn't it?
So if one wants an immediate clean test suite, add -fno-inline-functions.
Now clearly the new version of GCC inlines more than the previous one,
with two failing cases. The first one (do_3) is a very borderline one,
testing folding after integer overflows and I think the addition of
-fno-strict-overflow is enough. In my opinion, the second case requires
further investigation, but I don't think it would be a good idea to
try to prevent the new inlining (unless we discover that it open
another Pandora box).
Cheers
Dominique
Re: Someone has caused regressions in gfortran (c_char_tests_red.f03, now PR33330)
In comment #7 of PR0, Richard Guenther asked the following question I cannot answer: > Btw, is it mandated by the fortran standard to pass a scalar as array > reference? Does anyone knows the answer? or should it be asked on comp.lang.fortran? TIA Dominique
Re: [patch] restore bootstrap on ppc darwin
At revision 128228, the patch enables me to go from stage1 to stage3, but
bootstrap
still fails with:
libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
-B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
-fbootclasspath=../../../../gcc-4.3-work/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c
-fsource-filename=/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/classpath/lib/classes
-MT gnu/javax/imageio/jpeg.lo -MD -MP -MF gnu/javax/imageio/jpeg.deps
@gnu/javax/imageio/jpeg.list -fno-common -o gnu/javax/imageio/.libs/jpeg.o
/var/tmp//ccFhkZpcjx: In class 'gnu.javax.imageio.jpeg.DCT':
/var/tmp//ccFhkZpcjx: In method
'gnu.javax.imageio.jpeg.DCT.slow_idct(double[][])':
/var/tmp//ccFhkZpcjx:0: error: invalid rtl sharing found in the insn
(insn 475 474 476 37
../../../../../../gcc-4.3-work/libjava/classpath/gnu/javax/imageio/jpeg/DCT.java:119
(set (reg:SI 338)
(mem/c/i:SI (plus:DI (reg/f:DI 113 sfp)
(const_int 128 [0x80])) [19 S4 A32])) 328 {*movsi_internal1}
(expr_list:REG_EQUAL (fix:SI (reg/v:DF 147 [ D.1723 ]))
(nil)))
/var/tmp//ccFhkZpcjx:0: error: shared rtx
(mem/c/i:SI (plus:DI (reg/f:DI 113 sfp)
(const_int 128 [0x80])) [19 S4 A32])
/var/tmp//ccFhkZpcjx:0: internal compiler error: internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[5]: *** [gnu/javax/imageio/jpeg.lo] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libjava] Error 2
make: *** [all] Error 2
Yet another insn error!-(
TIA
Dominique
PS I'll be without internet connection from 2:00pm GMT to Monday evening
(GMT+2),
son don't expect answer from me within this time frame.
Re: Someone has caused regressions in gfortran (c_char_tests_red.f03, now PR33330)
This is now PR0 handled by Richard Guenther. Dominique
Boostrap failure on i686-apple-darwin9 at revision 139725
Boostrap fails on i686-apple-darwin9 at revision 139725 with: ... mkdir -p ./i686-apple-darwin9/bits/stdc++.h.gch /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -Winvalid-pch -x c++-header -g -O2 -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include -I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -O0 -g /opt/gcc/gcc-4.4-work/libstdc++-v3/include/precompiled/stdc++.h -o i686-apple-darwin9/bits/stdc++.h.gch/O0g.gch In file included from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr.h:165, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/ext/atomicity.h:39, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/basic_string.h:46, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/string:58, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bitset:54, from /opt/gcc/gcc-4.4-work/libstdc++-v3/include/precompiled/stdc++.h:67: /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h: In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const __gthread_time_t*)': /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:776: error: 'pthread_mutex_timedlock' was not declared in this scope make[4]: *** [i686-apple-darwin9/bits/stdc++.h.gch/O0g.gch] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 ... This seems related to revision 139704 Jump to revision: Author: paolo Date: Thu Aug 28 09:20:57 2008 UTC (11 hours, 3 minutes ago) Log Message: 2008-08-28 Chris Fairles <[EMAIL PROTECTED]> * gthr-posix.h (__gthread_create, __gthread_join, __gthread_detach, __gthread_mutex_timed_lock, __gthread_recursive_mutex_timed_lock, __gthread_cond_signal, __gthread_cond_timedwait, __gthread_cond_timedwait_recursive): New functions. * gthr-posix.c (pthread_mutex_timedlock, pthread_cond_timedwait): Likewise. * gthr.h: Comment on defining __GTHREADS_CXX0X macro in conforming thread interfaces. TIA Dominique
