Re: Results for 2.16.91 20051124 testsuite on sparc-unknown-linux-gnu
On 11/24/05, Dharmesh Vyas <[EMAIL PROTECTED]> wrote: > Hello all, > > I have been seeing these kinds of results shown over here. I have just > started using binutils. I have created a parser in Java which analyses > these logs and generates some results and shows no. of test cases > passed/executed and failed. If needed i can submit it on this forum. > Let me know your views on the same. > > Thanks > Dharmesh. > > On 11/24/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > > Aurora SPARC Linux release 2.0b2 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: > > > > binutils-2.15.92.0.2-5.sparc > > bison-1.875c-2.sparc > > dejagnu-1.4.4-2.noarch > > expect-5.42.1-1.sparc > > gcc-3.4.2-6.fc3.sparc > > gcc4-4.0.0-0.8sparc.sparc > > glibc-2.3.3-99.sparcv9 > > glibc-devel-2.3.3-99.sparc > > glibc-headers-2.3.3-99.sparc > > glibc-kernheaders-2.6-20sparc.sparc > > gmp-4.1.4-3sparc.sparc > > gmp-devel-4.1.4-3sparc.sparc > > kernel-2.6.13-1.1603sp8.sparc64 > > package kernel-devel is not installed > > package kernel-smp is not installed > > libgcc-3.4.2-6.fc3.sparc > > libstdc++-3.4.2-6.fc3.sparc > > libstdc++-devel-3.4.2-6.fc3.sparc > > make-3.80-5.sparc > > nptl-devel-2.3.3-99.sparcv9 > > tcl-8.4.7-2.sparc > > > > LAST_UPDATED: Thu Nov 24 07:18:05 UTC 2005 > > > > Native configuration is sparc-unknown-linux-gnu > > > > === binutils tests === > > > > > > Running target unix > > > > === binutils Summary === > > > > # of expected passes35 > > === gas tests === > > > > > > Running target unix > > > > === gas Summary === > > > > # of expected passes117 > > # of expected failures 1 > > === ld tests === > > > > > > Running target unix > > > > === ld Summary === > > > > # of expected passes263 > > # of expected failures 5 > > > > version: 2.16.91 20051124 > > Platform: sparc-unknown-linux-gnu > > configure flags: sparc-linux --enable-__cxa_atexit --enable-shared > > --enable-64-bit-bfd > > > > > -- > Trials keep you Strong, > Sorrow keeps you Human, > Failure keeps you Humble, > Success keeps you Glowing... > But only God keeps you going. > > "Walking with a friend in dark is better than walking alone in the Light" > Dharam. > You may want to make this proposition to the GCC community also. -- Cheers, /ChJ
Re: Default arguments and FUNCTION_TYPEs
Nathan Sidwell <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | | > Assuming the extension was gone, do you see a reason we not move the | > default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use | > TREE_VEC instead of TREE_LIST to hold the parameter-type list? | | you could probably use a VEC(tree), which I think would be even better :) Thanks! -- Gaby
problems bootstrapping gcc-4.0-20051117 on i386-pc-solaris2.10
Hi, I'm having a lot of problems bootstrapping this compiler on said target. What I did so far: from the build dir (which I located in the extracted source dir) ../configure --srcdir=.. --enable-languages="c c++" --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld however this fails to select '/usr/sfw/bin/gas' as the assembler; per configure output is says: ... checking for i386-pc-solaris2.10-as... no checking for as... as ... So I set the environment variable 'AS' to point to gas: export AS='/usr/sfw/bin/gas'; removed the build dir and started over. This gave: ... checking for i386-pc-solaris2.10-as... /usr/sfw/bin/gas ... after which I continued with: make -j5 bootstrap At that point it starts building, but fails with an assembler error: /usr/local/src/gcc-4.0-20051117/gcc/config/i386/gmon-sol2.c:406: warning: control reaches end of non-void function /usr/local/src/gcc-4.0-20051117/gcc/config/i386/gmon-sol2.c: At top level: /usr/local/src/gcc-4.0-20051117/gcc/config/i386/gmon-sol2.c:58: warning: 'sccsid' defined but not used Fixing headers into /usr/local/src/gcc-4.0-20051117/build/gcc/include for i386-pc-solaris2.10 target Assembler: "", line 1 : Illegal flag (-) make[2]: *** [gmon.o] Error 1 make[2]: *** Waiting for unfinished jobs using truss I find that it is actually using /usr/ccs/bin/as ?!? luckyily it stats a few paths before happening on /usr/ccs/bin/as, so what I did is to symlink /usr/sfw/bin/gas to one of the other paths (ln -s /usr/sfw/bin/gas /usr/local/i386-pc-solaris2.10/bin/as) and restart all over again. This get me further along, however not quite there. Now it fails to configure libstd++ with the following error: checking for exception model to use... configure: error: unable to detect exception model make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/usr/local/src/gcc-4.0-20051117/build' make: *** [bootstrap] Error 2 I'm sure I'm doing something horribly wrong here, can somebody point me to the way of a working compiler? Kind regards, Peter Zijlstra
Re: Default arguments and FUNCTION_TYPEs
Nathan Sidwell <[EMAIL PROTECTED]> wrote: >>> In the C++ front end, default arguments are recorded in >>> FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are >>> the reasons for that? >> >> >> There used to be an extension that allowed default arguments on >> function pointer types. We agreed to kill it, although I don't know >> if it was actually removed. If that's been done, there's no longer >> any reason. > > I took it out the back and shot it. > > The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I > don't think they exist until the function is defined. I heard once that there was some long-term project of storing function declarations (without corresponding definitions) in a more memory-efficient memory representation. Moving default parameters within PARM_DECL seems a little backward in this respect. And if your memory is right, requiring to build PARM_DECLs just to store default arguments would be even worse. I understand this has to be done in a separate pass: I was just bringing up the issue so that, if possibile, we could find some place which does not conflict with that project. Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Nathan Sidwell <[EMAIL PROTECTED]> wrote: | | >>> In the C++ front end, default arguments are recorded in | >>> FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are | >>> the reasons for that? | >> | >> | >> There used to be an extension that allowed default arguments on | >> function pointer types. We agreed to kill it, although I don't know | >> if it was actually removed. If that's been done, there's no longer | >> any reason. | > | > I took it out the back and shot it. | > | > The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I | > don't think they exist until the function is defined. | | | I heard once that there was some long-term project of storing function | declarations (without corresponding definitions) in a more memory-efficient | memory representation. Moving default parameters within PARM_DECL seems a | little backward in this respect. And if your memory is right, requiring to | build PARM_DECLs just to store default arguments would be even worse. I don't see why, it is backward -- we still need to build the PARM_DECLs default arguments or not. Anyway, I'm in the middle of coding that suggestion, so I would appreciate a better concrete representation. -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: [...] | | > The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I | | > don't think they exist until the function is defined. | | | | | | I heard once that there was some long-term project of storing function | | declarations (without corresponding definitions) in a more memory-efficient | | memory representation. Moving default parameters within PARM_DECL seems a | | little backward in this respect. And if your memory is right, requiring to | | build PARM_DECLs just to store default arguments would be even worse. | | I don't see why, it is backward -- we still need to build the | PARM_DECLs default arguments or not. Consider PR c++/17395. My guess is that is partly because we do not build the PARM_DECLs (and their associated scope) early enough. -- Gaby
Re: Creating a partial mirror of the repository with SVK
On Wed, 2005-11-23 at 21:13, Ludovic Brenta wrote: > I've read the wiki page that explains how to mirror GCC's repository > using SVK, and I would like to pick up just the parts I need so I can > keep the size of the mirror below 4 Gb due to limited disk space. > > Specifically, I need just a few branches: gcc_3_4_branch, > gcc_4_0_branch, gcc_4_1_branch, and trunk. Also I only want to build > with --enable-languages=c,c++,ada. In particular I'd like not to > mirror java, gfortran, objc, or treelang. > > Is this possible? How? > I don't think so. AFAICT you can mirror only subtrees of the repository. Thus you can mirror trunk, or a single branch without problems, but you can't mirror a subset of the branches (or all the branches and not the tags). You might be able to mirror each branch independently, but that means you won't get any benefit of the common code between branches/trunk. Effectively you would have N independent mirrors of subsets of the repository. If the number of branches is small that might still be better than mirroring the entire repository, but you probably loose the ability to merge across the mirrors. R.
Re: overcoming info build failures
Hello! > Mark Mitchell's @file documentation change adds a @set directive to > gcc-vers.texi in the build directory, but that file only depends on > DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using > the new make rule. Just deleting it will remedy the problem. Another problem is in the fact that value references in @include commands are expanded only from texinfo version 4.4 and newer. This means, that version 4.4 or higher of texinfo is _required_ to build the documentation. Interested people could check texinfo's ChangeLog.46 for the changeset: 2003-01-12<[EMAIL PROTECTED]> ... * makeinfo/cmds.c (handle_include): call text_expansion on the filename, so @value constructs are expanded. * doc/texinfo.txi (verbatiminclude, Using Include Files): mention @value expansion. ... Using texinfo 4.2, bootstrap fails with: if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --no-split -I . -I ../../gcc-svn/trunk/gcc/doc \ -I ../../gcc-svn/trunk/gcc/doc/include -o doc/gcc.info ../../gcc-svn/trunk/gcc/doc/gcc.texi; \ fi ../../gcc-svn/trunk/gcc/doc/invoke.texi:1057: @include [EMAIL PROTECTED]/../libiberty/at-file.texi': No such file or directory. makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to preserve. gmake[2]: *** [doc/gcc.info] Error 2 Attached (untested) diff should update the required version of texinfo. Uros. build.diff Description: Binary data
should _GNU_SOURCE be used in libiberty if glibc is present?
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Coping the test that enables _GNU_SOURCE from gcc/configure.ac to
libiberty/configure.ac results in HAVE_DECL_ASPRINTF being defined as 1. I
am not sure where in libiberty/configure.ac should the test be added (if it
should). Is the attached patch correct? If so, I will submit a formal patch
to gcc-patches.
I am currently bootstraping the trunk with the patch applied.
Thanks,
Rafael
Index: libiberty/configure.ac
===
--- libiberty/configure.ac (revision 107446)
+++ libiberty/configure.ac (working copy)
@@ -227,6 +227,21 @@ AC_SUBST_FILE(host_makefile_frag)
# It's OK to check for header files. Although the compiler may not be
# able to link anything, it had better be able to at least compile
# something.
+
+AC_MSG_CHECKING(for GNU C library)
+AC_CACHE_VAL(gcc_cv_glibc,
+[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
+ [[#include ]], [[
+#if ! (defined __GLIBC__ || defined __GNU_LIBRARY__)
+#error Not a GNU C library system
+#endif]])],
+ [gcc_cv_glibc=yes],
+ [gcc_cv_glibc=no])])
+AC_MSG_RESULT($gcc_cv_glibc)
+if test $gcc_cv_glibc = yes; then
+ AC_DEFINE(_GNU_SOURCE, 1, [Always define this when using the GNU C Library])
+fi
+
AC_CHECK_HEADERS(sys/file.h sys/param.h limits.h stdlib.h malloc.h string.h unistd.h strings.h sys/time.h time.h sys/resource.h sys/stat.h sys/mman.h fcntl.h alloca.h sys/pstat.h sys/sysmp.h sys/sysinfo.h machine/hal_sysinfo.h sys/table.h sys/sysctl.h sys/systemcfg.h stdint.h stdio_ext.h)
AC_HEADER_SYS_WAIT
AC_HEADER_TIME
Index: libiberty/configure
===
--- libiberty/configure (revision 107446)
+++ libiberty/configure (working copy)
@@ -3594,6 +3594,71 @@ host_makefile_frag=${frag}
# able to link anything, it had better be able to at least compile
# something.
+echo "$as_me:$LINENO: checking for GNU C library" >&5
+echo $ECHO_N "checking for GNU C library... $ECHO_C" >&6
+if test "${gcc_cv_glibc+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+#include
+int
+main ()
+{
+
+#if ! (defined __GLIBC__ || defined __GNU_LIBRARY__)
+#error Not a GNU C library system
+#endif
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ gcc_cv_glibc=yes
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+gcc_cv_glibc=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+
+echo "$as_me:$LINENO: result: $gcc_cv_glibc" >&5
+echo "${ECHO_T}$gcc_cv_glibc" >&6
+if test $gcc_cv_glibc = yes; then
+
+cat >>confdefs.h <<\_ACEOF
+#define _GNU_SOURCE 1
+_ACEOF
+
+fi
+
+
@@ -6424,18 +6489,24 @@ else
ac_cv_func_fork_works=cross
else
cat >conftest.$ac_ext <<_ACEOF
-/* By Ruediger Kuhlmann. */
- #include
- #if HAVE_UNISTD_H
- # include
- #endif
- /* Some systems only have a dummy stub for fork() */
- int main ()
- {
- if (fork() < 0)
- exit (1);
- exit (0);
- }
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+$ac_includes_default
+int
+main ()
+{
+
+ /* By Ruediger Kuhlmann. */
+ if (fork() < 0)
+ exit (1);
+ exit (0);
+
+ ;
+ return 0;
+}
_ACEOF
rm -f conftest$ac_exeext
if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
pgpNR8WIn5qoA.pgp
Description: PGP signature
Re: overcoming info build failures
On 11/24/05, Uros Bizjak <[EMAIL PROTECTED]> wrote: > Hello! > > > Mark Mitchell's @file documentation change adds a @set directive to > > gcc-vers.texi in the build directory, but that file only depends on > > DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using > > the new make rule. Just deleting it will remedy the problem. > > Another problem is in the fact that value references in @include commands are > expanded only from texinfo version 4.4 and newer. This means, that version 4.4 > or higher of texinfo is _required_ to build the documentation. > > Interested people could check texinfo's ChangeLog.46 for the changeset: > > 2003-01-12<[EMAIL PROTECTED]> > >... > >* makeinfo/cmds.c (handle_include): call text_expansion on the >filename, so @value constructs are expanded. > >* doc/texinfo.txi (verbatiminclude, Using Include Files): mention >@value expansion. > >... > > Using texinfo 4.2, bootstrap fails with: > > if [ xinfo = xinfo ]; then \ >makeinfo --split-size=500 --split-size=500 --no-split -I . -I > ../../gcc-svn/trunk/gcc/doc \ >-I ../../gcc-svn/trunk/gcc/doc/include -o doc/gcc.info > ../../gcc-svn/trunk/gcc/doc/gcc.texi; \ > fi > ../../gcc-svn/trunk/gcc/doc/invoke.texi:1057: @include > [EMAIL PROTECTED]/../libiberty/at-file.texi': No such file or directory. > makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to > preserve. > gmake[2]: *** [doc/gcc.info] Error 2 > > Attached (untested) diff should update the required version of texinfo. > sigh, so this is the cause of my build failures -- Cheers, /ChJ
Re: overcoming info build failures
On Thu, 24 Nov 2005, Uros Bizjak wrote: > Attached (untested) diff should update the required version of texinfo. It also need updating everywhere in install.texi that mentions a required Texinfo version. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> template struct X { };
>
>void fu(int a, X) { } // #1
I gave a look to PR 17395 and you are probably right. This testcase requires
us to build PARM_DECLs even for function declarations. That's really too
bad.
You should though measure memory usage for large C++ testcases when building
PARM_DECLs immediately. If they raise too much, that's a serious regression.
--
Giovanni Bajo
mips-irix6.5 and complex.h
Hi, I am stuck with PR libfortran/22097 because currently, the libgfortran configury isn't clever enough to get cabsl (among others) right on mips-irix6.5. config.h has #define HAVE_CABSF 1 and /* #undef HAVE_COMPLEX_H */ while the correct definition of cabsl is provided in complex.h. Can someone who knows mips-irix or has experience with such broken C99 complex implementations give some help? The problem I have is comment #9 from PR 22097. Thanks, FX
Re: should _GNU_SOURCE be used in libiberty if glibc is present?
Rafael Ávila de Espíndola wrote:
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Another long-staying bug in the libiberty configure system is that it
claims newlib missing 'asprintf()', 'strdup()' and 'vasprintf()' and
therefore tries to produce these although one has used the
'--with-newlib' in the GCC configure ! AFAIK, only those functions
which are missing from the C library, should be built into libiberty.
The result from this has been the GCC build crashing with the clashing
newlib headers prototypes and the function reimplementations in
libiberty. Sometimes I even made diffs for the fixes in 'configure.ac':
*** configure.ac.orig 2004-01-10 04:17:41.0 +0200
--- configure.ac2005-05-02 18:36:18.0 +0300
***
*** 265,280
# newlib provide and which ones we will be expected to provide.
if test "x${with_newlib}" = "xyes"; then
- AC_LIBOBJ([asprintf])
AC_LIBOBJ([basename])
AC_LIBOBJ([insque])
AC_LIBOBJ([random])
- AC_LIBOBJ([strdup])
- AC_LIBOBJ([vasprintf])
for f in $funcs; do
case "$f" in
! asprintf | basename | insque | random | strdup | vasprintf)
;;
*)
n=HAVE_`echo $f | tr 'abcdefghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
--- 265,277
# newlib provide and which ones we will be expected to provide.
if test "x${with_newlib}" = "xyes"; then
AC_LIBOBJ([basename])
AC_LIBOBJ([insque])
AC_LIBOBJ([random])
for f in $funcs; do
case "$f" in
! basename | insque | random)
;;
*)
n=HAVE_`echo $f | tr 'abcdefghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
Re: should _GNU_SOURCE be used in libiberty if glibc is present?
If we do this, then anyone else testing for asprintf needs the same logic. If libiberty uses a more naive test, it would provide substitutes for other modules that are also naive.
Re: Build using --with-gmp and shared libraries
This patch makes --with-gmp and --with-mpfr similar to --with-as and others, where you don't need to have the as program in your PATH if explicitly specified. I now understood what you are looking for. A good solution would be to use the macros AC_LIB_LINKFLAGS and friends, which were first written for the AM_GETTEXT macro. These provide a good way to find gmp and friends, and to optionally add -R or -Wl,-rpath options to the command line (this is controlled by configure switches --enable-rpath and --disable-rpath). The macro is used like AC_LIB_LINKFLAGS(gmp) AC_LIB_LINKFLAGS(mpfr) and it will set LIBGMP, LTLIBGMP, INCGMP, and similar variables for mpfr. The disadvantage is that the variable names have to be changed throughout, and that --with-* option is --with-libgmp and --with-libmpfr. If you really need to support --with-gmp-dir and --with-mpfr-dir, you can set the cache variables ac_cv_libgmp_libs ac_cv_libgmp_ltlibs (will be equal to the above) ac_cv_libgmp_cppflags the same way you set gmpinc and gmplibs in this snippet: gmpinc="$gmpinc -I$with_gmp_dir" if test -f "$with_gmp_dir/.libs/libgmp.a"; then gmplibs="$gmplibs $with_gmp_dir/.libs/libgmp.a" elif test -f "$with_gmp_dir/_libs/libgmp.a"; then gmplibs="$gmplibs $with_gmp_dir/_libs/libgmp.a" fi Sorry for wasting your time for months and not proposing this solution. OTOH I think that stage 1 is a good time to do this. Paolo
Re: Default arguments and FUNCTION_TYPEs
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| > template struct X { };
| >
| >void fu(int a, X) { } // #1
|
| I gave a look to PR 17395 and you are probably right. This testcase requires
| us to build PARM_DECLs even for function declarations. That's really too
| bad.
I guess we don't need to implement the language, we can be very fast :-)
|
| You should though measure memory usage for large C++ testcases when building
| PARM_DECLs immediately. If they raise too much, that's a serious regression.
Once I'm finished, I'll post the patch and I would probably ask you
help in the testing department and suggest better concrete
solution. That PR needs to be fixed.
-- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > Once I'm finished, I'll post the patch and I would probably ask you > help in the testing department and suggest better concrete > solution. That PR needs to be fixed. Fixing a PR introducing a regression is not a proper fix for any bug, *especially* for a bug which is not a regression itself. Given that it never worked before, there are no GCC users depending on it. Of course, it'd be good to fix it, but must be done in the proper way. I'm glad to help with testing if I have time. -- Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | | > Once I'm finished, I'll post the patch and I would probably ask you | > help in the testing department and suggest better concrete | > solution. That PR needs to be fixed. | | | Fixing a PR introducing a regression is not a proper fix for any bug, | *especially* for a bug which is not a regression itself. Thanks for the lecture. Not just because this is not a regression does not mean it does not need fixing. | Given that it never | worked before, there are no GCC users depending on it. The reporter of the PR is a GCC user who is trying to move working codes from other compilers to GCC. | Of course, it'd be | good to fix it, but must be done in the proper way. | | I'm glad to help with testing if I have time. Indeed. I see. -- Gaby
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: >> Fixing a PR introducing a regression is not a proper fix for any bug, >> *especially* for a bug which is not a regression itself. > > Thanks for the lecture. > > Not just because this is not a regression does not mean it does not > need fixing. I just warned you that finding a proper fix might be harder than you had expected. But I should just shut up and let you waste your time. In fact, I'm wasting mine with you as always. -- Giovanni Bajo
Re: Default arguments and FUNCTION_TYPEs
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | | >> Fixing a PR introducing a regression is not a proper fix for any bug, | >> *especially* for a bug which is not a regression itself. | > | > Thanks for the lecture. | > | > Not just because this is not a regression does not mean it does not | > need fixing. | | I just warned you that finding a proper fix might be harder than you had | expected. I think I anticipated that. What I do not quite understand is your apparant insisting of not fixing the bug (that people did run inito), inventing reason that no GCC user could have faced it. | But I should just shut up and let you waste your time. you wasted more of my time than I'm wasting on this PR. Did you suggest any *concrete* representation, you would have made less noise. -- Gaby
Re: should _GNU_SOURCE be used in libiberty if glibc is present?
> I am currently bootstraping the trunk with the patch applied. bootstraped and tested... > Thanks, > Rafael
Re: Register Allocation
In http://gcc.gnu.org/ml/gcc/2005-11/msg01163.html, Ian Lance Taylor wrote: Either way, register elimination can cause addresses which were valid to become invalid, typically because valid offsets from the frame pointer become invalid offsets from the stack pointer. So that needs to be cleaned up somewhere. This is not just about some requiring some cleanup somewhere. Register elimination and stack slot allocation determine the exact addresses that are used, which in turn determine what reload inheritance is possible for address reloads that are for stack slots which are close together on the stack. Getting this right is essential to avoid performance degradation on some platforms. These targets typically use LEGITIMIZE_RELOAD_ADDRESS to split out-of-range addresses into a normal form with a base address load and a memory access using this base with a small offset. On the other hand, the hard register spills appear to offer a new opportunity: we have talked about shrink-wrapping code in the past, but have never implemented this in gcc. I think that register saves/restores can be considered special cases of hard register spills. In order to do this efficiently, there would have to be some interface with the target to exploit insn sequences that can save/restore multiple registers more efficiently in bulk, .e.g load/store multiple, or auto-increment use on targets that are otherwise ACCUMULATE_OUTGOING_ARGS. On the other hand, these techniques can also help when we need to spill multiple hard registers around a tight loop.
gcc-4.0-20051124 is now available
Snapshot gcc-4.0-20051124 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051124/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 107471 You'll find: gcc-4.0-20051124.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051124.tar.bz2 C front end and core compiler gcc-ada-4.0-20051124.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051124.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051124.tar.bz2 C++ front end and runtime gcc-java-4.0-20051124.tar.bz2 Java front end and runtime gcc-objc-4.0-20051124.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051124.tar.bz2The GCC testsuite Diffs from 4.0-20051117 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: svn speed traversing slow filesystems
Kaveh R. Ghazi wrote: > On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote: > > Hi Dan, > > > > (BTW, sorry for the reposted messages.) > > > > While I was waiting for some svn commands to finish (cleanup, > > update) on my solaris2.7 box, which has a slow filesystem, I > > happened to run truss -p out of curiosity to see what was > > taking so long. Turns out that svn does many file operations on > > long pathnames. I recall that gnu find and other gnu utilities that > > do directory traversal got jumbo speedups by changing to the > > directory and running the file ops on "./filename" without long path > > prefixes. > > > > Could a future svn version get the same speedup? > > Actually, i just removed the need for most stat calls during update > in 1.4. Thanks Dan, that's great, but for the remaining i/o calls, it really does matter if you use long/paths/with/lots/of/slashes rather than chdir and ./filenames instead. I believe other recursive gnu utils besides gnufind like "rm -r" or "mkdir -p" etc were modified to use the chdir mechanism also because the benefit was so great. Yes that's fine, but we can't do this in SVN. We do the real work in libraries that are supposed to be thread-safe. The cwd is per-process on POSIX systems, as far as I know. No, please don't say we can do it "just for the command-line client." As Dan pointed out, there are better ways of speeding things up. -- Brane
Re: Thoughts on LLVM and LTO
I've been quietly watching the conversation, largely as an interested user as opposed to a GCC developer. One of my concerns lies with: GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here -- perhaps simple one, perhaps not. The line is very straight, but adding two more segments make me wonder if we're complicating the plumbing. How will this effect compiler speed? How will debugging information flow accurately through the process? And will we be making it even more difficult to isolate problems? Already, we have people who understand frontends, and others who know GIMPLE initimately, and still overs who focus on RTL generation. Is adding two additional passes going to further fragment expertise? I understand Rafael's comment, as quoted here: > In a first stage nothing will be done with the LLVM representation > except convert it back to GIMPLE. This will make sure that all > necessary information (including debug) can pass through the LLVM. The > conversion will also receive very good testing with this. Does this mean that the "LLVM pass" will initially invoked only via an option, and that a normal compile will continue the current path until LLVM is fully tested and accepted? Just questions; if they are stupid, please be gentle. ;) -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com
LEGITIMIZE_RELOAD_ADDRESS vs address_reloaded
Hi Ulrich,
In http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01557.html, you
changed the return value of find_reloads_address to be tristate, in the
process modifying the meaning of a win from LEGITIMIZE_RELOAD_ADDRESS.
Prior to your change, a win meant that LEGITIMIZE_RELOAD_ADDRESS had
guaranteed that the address would match one of the extra memory
constraints if it didn't match some other constraint. After this
change, a win meant that the address as a whole might need further
reloads. This has caused me a little trouble, because I can't find a
way of telling reload to leave the address alone.
Perhaps I ought to explain the problem I'm trying to solve. In pr24997,
we see reload trying to fix an altivec address that looks like
((rb+ri)+const)&-16
When this whole expression is put into a register, we get an ICE because
no ppc insn matches a complex expression like this. I figured I could
help reload a little by stripping off the AND and returning
(rb+const)+ri from LEGITIMIZE_RELOAD_ADDRESS, requesting a reload into a
base reg for (rb+const). (*) After this had been reloaded, the address
would be rb2+ri, which is a valid indexed address. This works in so far
as the ICE is cured and GCC generates valid code. However, we don't use
an indexed address. Instead, we get an indirect address due to
find_reloads not matching constraints for the insn, and further
reloading rb2+ri into another base reg.
Now, I don't really fault your change to the constraint matching because
it certainly seemed fragile before, and there is no way to distinguish
between alternates. I don't advocate changing things back the way they
were, because targets may have changed their LEGITIMIZE_RELOAD_ADDRESS
according to the new semantics. What I'd like from you or other reload
experts is an indication of the right way to fix this problem. ;-)
I can see the following options:
a) Before matching constraints in find_reloads, substitute dummy regs
for any reloads that have been identified. I'm not sure how much work
is involved in doing this, or whether it is even possible. It sounds
like this would be the best solution technically, as then the output
of LEGITIMIZE_RELOAD_ADDRESS is properly checked.
b) Modify LEGITIMIZE_RELOAD_ADDRESS to return a constraint letter that
the address is guaranteed to match after reloading. A bit of mechanical
work changing all targets.
c) Modify the ppc 'Z' constraint to match the indexed address reload
generates. This would rely on the pattern we generate in
LEGITIMIZE_RELOAD_ADDRESS never being generated elsewhere.
d) Hacks like the patch below, that effectively perform the reload
substitution with a dummy reg. I fear this isn't proper, even though it
seems to work..
(*) This is exactly what code in find_reloads_address does on
encoutering invalid indexed address. The trouble is that its
transformation isn't valid until the reloads are done, and we check
constraints before doing the substitutions. :-(
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 107416)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -3354,19 +3360,68 @@ rs6000_legitimize_reload_address (rtx x,
/* Reload an offset address wrapped by an AND that represents the
masking of the lower bits. Strip the outer AND and let reload
- convert the offset address into an indirect address. */
+ convert the offset address into an indirect address. Do the
+ same for indexed addresses with an offset. */
if (TARGET_ALTIVEC
&& ALTIVEC_VECTOR_MODE (mode)
&& GET_CODE (x) == AND
- && GET_CODE (XEXP (x, 0)) == PLUS
- && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
- && GET_CODE (XEXP (XEXP (x, 0), 1)) == CONST_INT
&& GET_CODE (XEXP (x, 1)) == CONST_INT
&& INTVAL (XEXP (x, 1)) == -16)
{
- x = XEXP (x, 0);
- *win = 1;
- return x;
+ rtx ad = XEXP (x, 0);
+ if (GET_CODE (ad) == PLUS
+ && GET_CODE (XEXP (ad, 1)) == CONST_INT)
+ {
+ if (GET_CODE (XEXP (ad, 0)) == REG)
+ {
+ x = ad;
+ *win = 1;
+ return x;
+ }
+ else if (GET_CODE (XEXP (ad, 0)) == PLUS
+ && GET_CODE (XEXP (XEXP (ad, 0), 0)) == REG
+ && GET_CODE (XEXP (XEXP (ad, 0), 1)) == REG)
+ {
+#if 1
+ rtx rb = XEXP (XEXP (ad, 0), 0);
+ rtx ri = XEXP (XEXP (ad, 0), 1);
+ rtx c = XEXP (ad, 1);
+
+ /* Use an indexed address as in the original instruction,
+but reload rb+c part. Generate the final form of the
+address here, so that we match Z constraint. Use r1
+as the base reg. It will be replaced with the actual
+reload reg later. */
+ x = gen_rtx_PLUS (GET_MODE (ad),
+
