Re: libgcc sparc-rtems config on gcc head
Joel,
>> That's what my patch does. It would be good if Joel could test on
>> i386-rtems before comitting (as I will on Solaris/SPARC and x86, of
>> course).
>>
> i386-rtems builds fine after moving the files.
>
> From my perspective, you can commit.
Thanks for the confirmation. I've run i386-pc-solaris2.{8, 11} and
sparc-sun-solaris2.{8, 11} bootstraps overnight. Solaris 8 builds
crt[in].o, while they are included on Solaris 11 and thus skipped in
libgcc. They completed without regressions (with the exception of
Solaris 8/SPARC where jc1 ICEs at one point, but that's unrelated).
I've now committed the patch.
The rules are generic and have been integrated into libgcc/Makefile.in,
but only used unless CUSTOM_CRTIN is set in a target fragment.
>>> s/unless/if/ I presume? config/t-sol2 has the rules though so
>>> config/t-rtems
>> No, if a t-* fragment sets CUSTOM_CRTIN, it's expected to provide its
>> own crt[in].o rules, just like the existing CUSTOM_CRTSTUFF does. If
>> crt[in].o is not included in extra_parts, the generic rules are
>> unused/harmless.
>>
>>> could just copy them, at least for now.
>> True, but that's the sort of copy-and-paste programming I'd like to
>> reduce with this series of patches.
>>
> Thank you. Avoiding cut and paste makes it easier
> for targets like RTEMS where we really do try to rely
> as much as possible on sharing. :)
Right, and it's less likely to miss new features...
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[GCC steering committee] Epiphany port maintainership
I propose myself as maintainer of the Epiphany port. This port is currently being submitted / reviewed on the gcc-patches mailing list.
Re: Dependent Labels Question
On Thu, 3 Nov 2011, Iyer, Balaji V wrote: > Is it possible to make sure that the "LABELX" occurs right > after the "Call some_function" instruction (and the instruction > scheduler moves the label with the call INSN)? I insert the > label right after the call is expanded and LABELX is being moved > above the Call instruction by the schedule_insns function. Is emitting the label in port-specific code together with the call insn (trigged by a punctuation like "%&" for i386) not an option? brgds, H-P
libgcc/static-object.mk weird error on powerpc-rtems
Hi, I am testing powerpc-rtems on the head and have gotten a weird error compiling libgcc. It is definitely a regression from 4.6. I have no idea who might be the best person to help resolve this. /home2/joel/build/b-powerpc-gcc/powerpc-rtems4.11/libgcc [joel@rtbf64a libgcc]$ make /users/joel/test-gcc/gcc-svn/libgcc/static-object.mk:18: *** Unsupported file type: . Stop. Playing with the error message, it looks like the "$o" in the message is empty. What can I pass along to help get this debugged? Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Bootstrap Failure Question
Hello Everyone, I am getting a bootstrap failure right now when I try to build GCC. Here is the output. Can someone please tell me how to fix this? Is this something I have modified? I just configured using the following command (../gcc/configure -prefix=). I haven't modified any of the .o files mentioned in the error. Any help is greatly appreciated! Also, please CC me when you respond. Thanks, Balaji V. Iyer. make[2]: Leaving directory `/home/ME/gcc-source/gcc-4.7/b-gcc' make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH" "TARGET_SUBDIR=x86_64-unknown-linux-gnu" "bindir=/home/ME/gcc-source/gcc-4.7/install/bin" "datadir=/home/ME/gcc-source/gcc-4.7/install/share" "exec_prefix=/home/ME/gcc-source/gcc-4.7/install" "includedir=/home/ME/gcc-source/gcc-4.7/install/include" "datarootdir=/home/ME/gcc-source/gcc-4.7/install/share" "docdir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" "infodir=/home/ME/gcc-source/gcc-4.7/install/share/info" "pdfdir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" "htmldir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" "libdir=/home/ME/gcc-source/gcc-4.7/install/lib" "libexecdir=/home/ME/gcc-source/gcc-4.7/install/libexec" "lispdir=" "localstatedir=/home/ME/gcc-source/gcc-4.7/install/var" "mandir=/home/ME/gcc-source/gcc-4.7/install/share/man" "oldincludedir=/usr/include" "prefix=/home/ME/gcc-source/gcc-4.7/install" "sbindir=/home/ME/gcc-source/gcc-4.7/install/sbin" "sharedstatedir=/home/ME/gcc-source/gcc-4.7/install/com" "sysconfdir=/home/ME/gcc-source/gcc-4.7/install/etc" "tooldir=/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu" "build_tooldir=/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu" "target_alias=x86_64-unknown-linux-gnu" "AWK=gawk" "BISON=bison" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/bin/sed" "SHELL=/bin/bash" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c,c++,lto" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/xgcc -B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" "CFLAGS_FOR_TARGET=-g -O2" "CPPFLAGS_FOR_TARGET=" "CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=dlltool" "FLAGS_FOR_TARGET=-B/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/bin/ -B/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/lib/ -isystem /home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/include -isystem /home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/sys-include" "GCJ_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/gcj -B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" "GFORTRAN_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/gfortran -B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" "GOC_FOR_TARGET=" "GOCFLAGS_FOR_TARGET=-O2 -g" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_CXXFLAGS=-g -fkeep-inline-functions" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-g -O2 -gtoggle" "STAGE2_CXXFLAGS=-g -O2 -gtoggle" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g -O2" "STAGE3_CXXFLAGS=-g -O2" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-g -O2" "STAGE4_CXXFLAGS=-g -O2" "STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-g -O2 -gtoggle -fprofile-generate" "STAGEprofile_CXXFLAGS=-g -O2 -gtoggle -fprofile-generate" "STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-g -O2 -fprofile-use" "STAGEfeedback_CXXFLAGS=-g -O2 -fprofile-use" "STAGEfeedback_TFLAGS=" "CXX_FOR_TARGET= $r/./gcc/g++ -B$r/./gcc/ -nostdinc++ `if test -f $r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then /bin/bash $r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src -L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs" "TFLAGS=" "CONFIG_SHELL=/bin/bash" "MAKEINFO=makeinfo --split-size=500 --split-size=500" compare make[2]: Entering directory `/home/ME/gcc-source/gcc-4.7/b-gcc' make[3]: Entering directory
Re: Bootstrap Failure Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/11 12:34, Iyer, Balaji V wrote: > Hello Everyone, I am getting a bootstrap failure right now when I > try to build GCC. Here is the output. Can someone please tell me > how to fix this? Is this something I have modified? I just > configured using the following command (../gcc/configure > -prefix=). I haven't modified any of the .o files > mentioned in the error. Typically a comparison failure means GCC has mis-compiled itself. You have to figure out why. I typically start with a small test which is compiled differently by the stage1 and stage2 compilers. Then I figure out where they diverge in their behavior (say at a pass level). Then I figure out where they first diverge at a function within a pass. That's usually the function that is being mis-compiled. Sometimes you can make some educated guesses based recent changes and comparing how something was compiled before/after the change. In all these are some of the most annoying bugs to tackle. jeff > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOtDHBAAoJEBRtltQi2kC7L20H/1SCJSyusm+MG3oL3SIS2AWz ahbGFPnIQO0jPi7KGGuH0Cb1ynk1yvHlyLGOoLMAxvRU4zzoKVpXfg7PD966C8Ad m7Lak7kTlyX6i+rB4+CIAsAA24u0Q1vzvnyzW4gEYk7v1dvvee1nqEMR5p/DbfUU iXei/L+tZJ4Vq5lf/+0B8Zz7+P10KmU1VydAlFS9OeK2QKuESXUADUiVZtrWZXsB ClzXOqm6F9Zq/HpK/Va5SGeiYy3sXGzFIzYUnV/RlZcExWH7kPTgbkLXky/D4lKS CyTzXsfo5mvqZuIp7HtOXGrSZPl2/w2Y1KF0LlQntkJKVR81sic/KG2CfeAVGPA= =5ZYe -END PGP SIGNATURE-
[C++11] Reclaiming fixed-point suffixes for user-defined literals.
Greetings, Now that C++11 user-defined literals are in trunk I was thinking about reclaiming some of the numeric suffixes that are currently recognized by gcc in the preprocessor. The C++11 spec stipulates that any suffix that is recognized by the implementation is not allowable as a user-defined literal suffix in c++. This prevents C++ from hijacking 123LL, 1.234L, etc. On the other hand, there are several numeric literal suffixes that are recognized and used as gnu extensions. One class of suffixes stands out in this connection: fixed-point literals. These end in 'k' or 'r' and can optionally be unsigned by starting with 'u' and optionally have a size 'h', 'l', 'll'. The difference for these suffixes is that fixed-point literals are explicitly rejected by the c++ front end. Attempts to use such literals: int i= 1.23k; results in 'error: fixed-point types not supported in C++'. So I ask the question: Should I make a simple change to libcpp to allow fixed-point literal suffixes to pass to the user-defined literal code in c++11 mode? Thanks, Ed Smith-Rowland P.S. There are other suffixes that might be reclaimed as well such as 'i', 'I', 'j', 'J' for complex integral or floating point imaginary numbers and others. These might be more difficult or impossible to reclaim for C++11 because these might be allowed and used in gnu-C++ and it might break existing code.
sparc-rtems 4.6 vs 4.7
Hi, Thanks to Eric Botcazou, David Miller, and Ranier Orth, sparc-rtems is testable again. It appears to be approximately the same as the 4.6 results but I would appreciate a double check from a sparc maintainer. Since it looks like a lot of the failures in both cases are lto, vect and stack-align tests, I suspect that of the ~3100 tests that were added, we have a number of new tests that won't work on when compiling specifically for an erc32 (-mcpu=cypress). Insight appreciated. Thanks. = 4.6.1 20110329 http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00203.html === gcc Summary === # of expected passes68033 # of unexpected failures714 # of expected failures227 # of unresolved testcases128 # of unsupported tests1237 === g++ Summary === # of expected passes25343 # of unexpected failures97 # of unexpected successes1 # of expected failures161 # of unsupported tests446 = 4.7.0 20111104 http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00440.html === gcc Summary === # of expected passes71190 # of unexpected failures940 # of expected failures286 # of unresolved testcases49 # of unsupported tests1693 === g++ Summary === # of expected passes26704 # of unexpected failures72 # of unexpected successes1 # of expected failures153 # of unsupported tests457 = -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
RE: Bootstrap Failure Question
Thanks Jeff for your help! So, are the errors confined to these files? Or could it be anywhere? Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/i386-common.o differs gcc/bitmap.o differs libiberty/timeval-utils.o differs libiberty/pic/timeval-utils.o differs Is there anything else I can do to pin-point the problem? (like maybe gdb a certain file or pass a certain flag to get some debug info) Thanks, Balaji V. Iyer. -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Friday, November 04, 2011 2:41 PM To: Iyer, Balaji V Cc: 'gcc@gcc.gnu.org' Subject: Re: Bootstrap Failure Question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/11 12:34, Iyer, Balaji V wrote: > Hello Everyone, I am getting a bootstrap failure right now when I try > to build GCC. Here is the output. Can someone please tell me how to > fix this? Is this something I have modified? I just configured using > the following command (../gcc/configure -prefix=). I > haven't modified any of the .o files mentioned in the error. Typically a comparison failure means GCC has mis-compiled itself. You have to figure out why. I typically start with a small test which is compiled differently by the stage1 and stage2 compilers. Then I figure out where they diverge in their behavior (say at a pass level). Then I figure out where they first diverge at a function within a pass. That's usually the function that is being mis-compiled. Sometimes you can make some educated guesses based recent changes and comparing how something was compiled before/after the change. In all these are some of the most annoying bugs to tackle. jeff > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOtDHBAAoJEBRtltQi2kC7L20H/1SCJSyusm+MG3oL3SIS2AWz ahbGFPnIQO0jPi7KGGuH0Cb1ynk1yvHlyLGOoLMAxvRU4zzoKVpXfg7PD966C8Ad m7Lak7kTlyX6i+rB4+CIAsAA24u0Q1vzvnyzW4gEYk7v1dvvee1nqEMR5p/DbfUU iXei/L+tZJ4Vq5lf/+0B8Zz7+P10KmU1VydAlFS9OeK2QKuESXUADUiVZtrWZXsB ClzXOqm6F9Zq/HpK/Va5SGeiYy3sXGzFIzYUnV/RlZcExWH7kPTgbkLXky/D4lKS CyTzXsfo5mvqZuIp7HtOXGrSZPl2/w2Y1KF0LlQntkJKVR81sic/KG2CfeAVGPA= =5ZYe -END PGP SIGNATURE-
Re: Dependent Labels Question
On 11/04/11 15:37, Hans-Peter Nilsson wrote: > On Thu, 3 Nov 2011, Iyer, Balaji V wrote: >> Is it possible to make sure that the "LABELX" occurs right >> after the "Call some_function" instruction (and the instruction >> scheduler moves the label with the call INSN)? I insert the >> label right after the call is expanded and LABELX is being moved >> above the Call instruction by the schedule_insns function. > > Is emitting the label in port-specific code together with the > call insn (trigged by a punctuation like "%&" for i386) not an > option? Some ports do that kind of thing. You must also define the cannot_copy_insn_p hook to make sure that only one of these labels gets emitted. In general however you don't want to do this since it prevents optimizations. Bernd
Re: sparc-rtems 4.6 vs 4.7
> Since it looks like a lot of the failures > in both cases are lto, vect and stack-align > tests, I suspect that of the ~3100 tests > that were added, we have a number of new > tests that won't work on when compiling > specifically for an erc32 (-mcpu=cypress). The results can hardly be analyzed, there are too many failures, although they probably come from a small number of problems. You should consider looking into the gazillions of execution failures, determining why they fail (they pass on Solaris or Linux) and submit patches to XFAIL/SKIP them for sparc-rtems. -- Eric Botcazou
Failure to bootstrap trunk with --enable-threads=posix on cygwin since r180767
On cygwin, I get the following failure when trying to boostrap current Fri Nov 4 19:36:52 UTC 2011 (revision 180977) gcc trunk: /bin/sh ../../../gcc/libgcc/../mkinstalldirs . ln -s -f libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir ./shlib; else true; fi && /usr/local/src/objdir/./gcc/xgcc -B/usr/local/src/objdir/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include-O2 -I../../../gcc/libgcc/../winsup/w32api/include -I../../../gcc/libgcc/../winsup/include -I../../../gcc/libgcc/../winsup/cygwin/include -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -pthread -shared -nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.dll.a.tmp -o ./shlib/cyggcc_s-1.dll.tmp -g -O2 -B./ _chkstk_s.o _chkstk_ms_s.o _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 _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 _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o tf-signs_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o -Wl,-lpthread -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 && if [ -f ./shlib/cyggcc_s-1.dll ]; then mv -f ./shlib/cyggcc_s-1.dll ./shlib/cyggcc_s-1.dll.backup; else true; fi && mv ./shlib/cyggcc_s-1.dll.tmp ./shlib/cyggcc_s-1.dll && mv ./shlib/libgcc_s.dll.a.tmp ./shlib/libgcc_s.dll.a xgcc: error: unrecognized command line option ‘-pthread’ make[3]: *** [libgcc_s.dll] Error 1 make[3]: Leaving directory `/usr/local/src/objdir/i686-pc-cygwin/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/usr/local/src/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/objdir' make: *** [all] Error 2 This is with gcc configured as Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: i686-pc-cygwin Configured with: ../gcc/configure --prefix=/usr --exec-prefix=/usr --bindir=/usrfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usnable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++,fortran,jble-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-threadRGET=gcc-4 CXX_FOR_TARGET=g++-4 Thread model: posix gcc version 4.7.0 2004 (experimental) [trunk revision 180977] (GCC) Note the --enable-threads=posix. Backing off to revision 180766 does not yield this problem, while 180767 has the problem. -- Cheers, /ChJ
gcc-4.6-20111104 is now available
Snapshot gcc-4.6-2004 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-2004/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 180991 You'll find: gcc-4.6-20111104.tar.bz2 Complete GCC MD5=938b905a30881e90c2a2c31d7f997f76 SHA1=6d2c1e1d7da8a10095a2ad5da13b67b25d3647bf Diffs from 4.6-20111028 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
--enable-werror-always fails function.o for any non-pic target
For example, rx-elf...
gcc/function.c: In function 'thread_prologue_and_epilogue_insns':
gcc/regs.h:322:34: error: array subscript is above array bounds
[-Werror=array-bounds]
function.c has this:
if (pic_offset_table_rtx)
add_to_hard_reg_set (&set_up_by_prologue, Pmode,
PIC_OFFSET_TABLE_REGNUM);
Which ends up here:
static inline unsigned int
end_hard_regno (enum machine_mode mode, unsigned int regno)
{
return regno + hard_regno_nregs[regno][(int) mode];
}
but if PIC_OFFSET_TABLE_REGNUM isn't defined by the target, you get:
#ifndef PIC_OFFSET_TABLE_REGNUM
#define PIC_OFFSET_TABLE_REGNUM INVALID_REGNUM
#endif
which is ~0 and *always* out of range.
Does this warrant another excpetion to -Werror in Makefile.in ? Or is
there another way to get past this these days?
Index: Makefile.in
===
--- Makefile.in (revision 180992)
+++ Makefile.in (working copy)
@@ -195,12 +195,14 @@ GCC_WARN_CXXFLAGS = $(LOOSE_WARN) $($(@D
# flex output may yield harmless "no previous prototype" warnings
build/gengtype-lex.o-warn = -Wno-error
gengtype-lex.o-warn = -Wno-error
# mips-tfile.c contains -Wcast-qual warnings.
mips-tfile.o-warn = -Wno-error
expmed.o-warn = -Wno-error
+# non-PIC targets always get an array-bounds error in
thread_prologue_and_epilogue_insns
+function.o-warn = -Wno-error
# All warnings have to be shut off in stage1 if the compiler used then
# isn't gcc; configure determines that. WARN_CFLAGS will be either
# $(GCC_WARN_CFLAGS), or nothing. Similarly, WARN_CXXFLAGS will be
# either $(GCC_WARN_CXXFLAGS), or nothing.
WARN_CFLAGS = @warn_cflags@
Re: --enable-werror-always fails function.o for any non-pic target
DJ Delorie writes:
> gcc/function.c: In function 'thread_prologue_and_epilogue_insns':
> gcc/regs.h:322:34: error: array subscript is above array bounds
> [-Werror=array-bounds]
>
> function.c has this:
>
> if (pic_offset_table_rtx)
> add_to_hard_reg_set (&set_up_by_prologue, Pmode,
>PIC_OFFSET_TABLE_REGNUM);
>
> Which ends up here:
>
> static inline unsigned int
> end_hard_regno (enum machine_mode mode, unsigned int regno)
> {
> return regno + hard_regno_nregs[regno][(int) mode];
> }
>
> but if PIC_OFFSET_TABLE_REGNUM isn't defined by the target, you get:
>
> #ifndef PIC_OFFSET_TABLE_REGNUM
> #define PIC_OFFSET_TABLE_REGNUM INVALID_REGNUM
> #endif
>
> which is ~0 and *always* out of range.
But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then
pic_offset_table_rtx should be NULL_RTX. See init_emit_regs in
emit-rtl.c. So I think there must be something else going on here.
Ian
Re: --enable-werror-always fails function.o for any non-pic target
> > if (pic_offset_table_rtx) > > add_to_hard_reg_set (&set_up_by_prologue, Pmode, > > PIC_OFFSET_TABLE_REGNUM); > > But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then > pic_offset_table_rtx should be NULL_RTX. It is, but is gcc smart enough to know that causal relationship?
Re: --enable-werror-always fails function.o for any non-pic target
DJ Delorie writes: >> > if (pic_offset_table_rtx) >> >add_to_hard_reg_set (&set_up_by_prologue, Pmode, >> > PIC_OFFSET_TABLE_REGNUM); >> >> But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then >> pic_offset_table_rtx should be NULL_RTX. > > It is, but is gcc smart enough to know that causal relationship? Oh, I see what you mean, sorry. Does it help if we change if (pic_offset_table_rtx) to if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) ? Ian
Re: --enable-werror-always fails function.o for any non-pic target
> Does it help if we change > if (pic_offset_table_rtx) > to > if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) That seems to work.
Re: --enable-werror-always fails function.o for any non-pic target
On Fri, Nov 4, 2011 at 6:01 PM, DJ Delorie wrote: > >> > if (pic_offset_table_rtx) >> > add_to_hard_reg_set (&set_up_by_prologue, Pmode, >> > PIC_OFFSET_TABLE_REGNUM); >> >> But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then >> pic_offset_table_rtx should be NULL_RTX. > > It is, but is gcc smart enough to know that causal relationship? No because the setting of pic_offset_table_rtx is in emit-rtl.c. Maybe it is just better to do: if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) add_to_hard_reg_set (&set_up_by_prologue, Pmode, PIC_OFFSET_TABLE_REGNUM); in function.c. Thanks, Andrew Pinski
Re: serious libgcc regression added recently
From: Jakub Jelinek
Date: Thu, 3 Nov 2011 09:22:51 +0100
> I think much better would be to handle sparc*/s390*/powerpc* differently
> here, just using #ifdef __LP64__ test. i?86/x86_64 is different because
> of the third weirdo multilib option.
I just tested and committed the following, it seemed to make no sense
to keep the case statement there and now the host_address should be
available to anyone who wants to make use of it in config.host
[PATCH] Tweak libgcc configure test for 64-bit.
libgcc/
* configure.ac: Test for 64-bit addresses on !x86 using __LP64__.
* configure: Rebuild.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181000
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgcc/ChangeLog|5 +
libgcc/configure| 15 +--
libgcc/configure.ac | 15 +--
3 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index ec06a09..d3f091e 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2011-11-04 David S. Miller
+
+ * configure.ac: Test for 64-bit addresses on !x86 using __LP64__.
+ * configure: Rebuild.
+
2011-11-04 Andreas Krebbel
* config/s390/t-crtstuff: Add -fPIC to CRTSTUFF_T_CFLAGS_S
diff --git a/libgcc/configure b/libgcc/configure
index 0f18037..1895a76 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4609,21 +4609,16 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_cfi" >&5
$as_echo "$libgcc_cv_cfi" >&6; }
-# Check 32bit or 64bit for x86 and sparc.
-case ${host} in
-i?86*-*-* | x86_64*-*-* | sparc*-*-*)
- cat > conftest.c < conftest.c < conftest.c < conftest.c <
Re: --enable-werror-always fails function.o for any non-pic target
DJ Delorie writes: >> Does it help if we change >> if (pic_offset_table_rtx) >> to >> if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) > > That seems to work. That patch is fine if it bootstraps. Ian
predicate forward references (Was: Re: RFA: Add Epiphany port)
Quoting Richard Henderson :
(define_predicate "call_address_operand"
(match_code "symbol_ref,const,reg")
{
return (symbolic_operand (op, mode) || (GET_CODE (op) == REG));
})
Nit.
(define_predicate "call_address_operand"
(ior (match_code "reg")
(match_operand 0 "symbolic_operand")))
It doesn't like the predicates in their original order this way - it
complains:
../../srcw/gcc/config/epiphany/predicates.md:25: reference to unknown
predicate 'symbolic_operand'
Is there a way to have a predicate forward declaration?
Re: predicate forward references (Was: Re: RFA: Add Epiphany port)
On 11/04/2011 09:01 PM, Joern Rennecke wrote: > Is there a way to have a predicate forward declaration? No, sadly. Something for a future enhancement in the genfoo. r~
