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] var_decl 0xf33ea0 __gcov_var)
(symbol_ref:DI (pic base) [flags 0x600] [0 S8
A8])) -1 (expr_list:REG_DEAD (reg:DI 173)
(expr_list:REG_EQUAL (symbol_ref:DI (__gcov_var) [flags 0x200]
var_decl 0xf33ea0 __gcov_var)
(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]
var_decl 0xf33ea0 __gcov_var)
(symbol_ref:DI (pic base) [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 http://gcc.gnu.org/bugs.html 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: VM/Back-end
Mike wrote:
I want GCC to compile c/c++ code into VM instructions. Looking at GJC
as a reference, I didn't see a Java machine back-end MD file. Java
isn't a back-end in gcc/config.
AFAIK, gcj can compile JVM code (ie javac-compiled .class bytecode
files) but don't produce them.
There exist a CIL backend in some branch.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
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
[RFC] missing return warnings
Hi,
I am looking into what parts of frontend stil depends on frontend inline
decision (ie DECL_INLINE now ignored by middle end). All these uses
strike wrong, given that inlining decisions are independent on it.
These divergences for example requires us to enable expensive
-finline-functions for --profile-generate even though we really want it
only for --profile-use (where it is a lot cheaper given that profile
blocks unnecesary inlining).
For C++ there are number of cases I need to go through dealing with
attempts to not instantiate non-inline methods that won't be needed.
My plan is to make instantiation unconditional and measure effect on our
C++ benchmarks.
For C it seems to be single case for return warning:
/* PR c++/4872 */
/* { dg-do compile } */
/* { dg-options -Wreturn-type } */
static inline int f() {} /* { dg-warning return missing return } */
In this case we produce missing return warning from frontend.
This however is not truly consistent - if I make the function used, we
actually get two warnings - one from frontend, one from middle end
(that is CFG aware and does not merely check for presence of return
statement in function). If I remove the inline keyword, we lose the
warning since C frontend does not expect that we can now optimize out
static functions for a while.
The code in question is:
Index: c-decl.c
===
*** c-decl.c(revision 128161)
--- c-decl.c(working copy)
*** finish_function (void)
*** 6752,6776
finish_fname_decls ();
- /* Complain if there's just no return statement. */
- if (warn_return_type
-TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
-!current_function_returns_value !current_function_returns_null
- /* Don't complain if we are no-return. */
-!current_function_returns_abnormally
- /* Don't warn for main(). */
-!MAIN_NAME_P (DECL_NAME (fndecl))
- /* Or if they didn't actually specify a return type. */
-!C_FUNCTION_IMPLICIT_INT (fndecl)
- /* Normally, with -Wreturn-type, flow will complain. Unless we're an
-inline function, as we might never be compiled separately. */
-DECL_INLINE (fndecl))
- {
- warning (OPT_Wreturn_type,
- no return statement in function returning non-void);
- TREE_NO_WARNING (fndecl) = 1;
- }
-
/* Store the end of the function, so that we get good line number
info for the epilogue. */
cfun-function_end_locus = input_location;
--- 6725,6730
I wonder what we want to do here - I guess we can either make the
warning unconditional and declare it as two indpendent things or we can
just drop the feature since user will get properly warned on every
function he actually uses.
What would be preferred solution here?
Similarly there is equivalent C++ frotned code.
Honza
Re: GCC make errors
I have installed the latest binutils (2.9.1) available from the GNU ftp site so I cannot understand why this is occuring. Are there some sort of parameter options I need to enter or do I need to reinstall the binutils with parameter options? Regards, - Original Message - From: Richard Guenther [EMAIL PROTECTED] To: mandeep singh bhambra [EMAIL PROTECTED] Subject: Re: GCC make errors Date: Wed, 5 Sep 2007 13:57:29 +0200 On 9/5/07, mandeep singh bhambra [EMAIL PROTECTED] wrote: Hi, In response to the march options, I tried to use both -march=athlon-xp -g -O2 and -march=i686 -g -O2 but it does not like it. It still gives the error message about the 386 commands. When i use the ./configure command the march option is accepted as part of using gcc as it displays the following: checking for gcc... (cached) gcc checking whether the C compiler (gcc -march=athlon-xp -g -O2 ) works... yes checking whether the C compiler (gcc -march=athlon-xp -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc... (cached) gcc checking whether the C compiler (gcc -march=i686 -g -O2 ) works... yes checking whether the C compiler (gcc -march=i686 -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes Can you please outline what I can do to eliminate the error message or which version of binutils i can install. Thanks, Mani - Original Message - From: Tim Prince [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: GCC make errors Date: Fri, 10 Aug 2007 02:07:44 -0700 [EMAIL PROTECTED] wrote: Hi, I wanted update my GCC compiler to 4.2.1 to install an updated version of C libraries (glibc) and it is giving me errors while it is making the build. I type ./configure which works fine but when I type make it runs fine until it starts to give errors which are as follows: /tmp/ccacyMlE.s: Assembler messages: /tmp/ccacyMlE.s:72: Error: no such 386 instruction: `stmxcsr' /tmp/ccacyMlE.s:90: Error: no such 386 instruction: `ldmxcsr' /tmp/ccacyMlE.s:119: Error: no such 386 instruction: `fxsave' Your binutils version is obviously too old. Richard. -- We've Got Your Name @ www.mail.com!!! Get a FREE E-mail Account Today - Choose From 100+ Domains
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. The testcase was indeed previously not inlined at all. Shall we add -fno-strict-overflow to the testcase then? Honza 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
Bootstrap failure under Irix
Hi! I am seeing the folowing bootstrap failure under SGI Irix: bash /USER/philippe/Irix/Gcc_Sources/gcc/../move-if-change tmp-codes.h insn-codes.h echo timestamp s-codes gcc -c -g -fkeep-inline-functions -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 -fno-common -DHAVE_CONFIG_H -I. -I. -I/USER/philippe/Irix/Gcc_Sources/gcc -I/USER/philippe/Irix/Gcc_Sources/gcc/. -I/USER/philippe/Irix/Gcc_Sources/gcc/../include -I./../intl -I/USER/philippe/Irix/Gcc_Sources/gcc/../libcpp/include -I/USER/philippe/Irix/Gmp/include -I/USER/philippe/Irix/Mpfr/include -I/USER/philippe/Irix/Gcc_Sources/gcc/../libdecnumber -I/USER/philippe/Irix/Gcc_Sources/gcc/../libdecnumber/dpd -I../libdecnumberinsn-emit.c -o insn-emit.o /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function 'gen_fixuns_truncdfsi2': /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2808: error: too few arguments to function 'real_2expN' /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function 'gen_fixuns_truncdfdi2': /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2853: error: too few arguments to function 'real_2expN' /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function 'gen_fixuns_truncsfsi2': /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2895: error: too few arguments to function 'real_2expN' /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function 'gen_fixuns_truncsfdi2': /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2937: error: too few arguments to function 'real_2expN' make[3]: *** [insn-emit.o] Error 1 make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make: *** [bootstrap] Error 2 My last attempt at wa succesful with : '4.3.0 20070823 (experimental) [trunk revision 127728]' (I haven't tried in between). Can anyone suggest anything? Thanks! Philippe
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
Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'
Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a bootstrap failure: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o ../../gcc/gcc/ada/trans.c: In function `convert_with_check': ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN' make[3]: *** [ada/trans.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 -- Cheers, /ChJ
Bootstrap failure under Linux
Hi! I am getting the following bootstrap failure under Linux (Linux pinguin7 2.6.5-7.104-bigsmp #1 SMP Wed Jul 28 16:42:13 UTC 2004 i686 i686 i386 GNU/Linux). make[2]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc' make DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=i686-pc-linux-gnu bindir=/usr1/MICRESS/Philippe/Tools/Gcc/bin datadir=/usr1/MICRESS/Philippe/Tools/Gcc/share exec_prefix=/usr1/MICRESS/Philippe/Tools/Gcc includedir=/usr1/MICRESS/Philippe/Tools/Gcc/include datarootdir=/usr1/MICRESS/Philippe/Tools/Gcc/share docdir=/usr1/MICRESS/Philippe/Tools/Gcc/share/doc infodir=/usr1/MICRESS/Philippe/Tools/Gcc/info pdfdir=/usr1/MICRESS/Philippe/Tools/Gcc/share/doc htmldir=/usr1/MICRESS/Philippe/Tools/Gcc/yes libdir=/usr1/MICRESS/Philippe/Tools/Gcc/lib libexecdir=/usr1/MICRESS/Philippe/Tools/Gcc/libexec lispdir= localstatedir=/usr1/MICRESS/Philippe/Tools/Gcc/var mandir=/usr1/MICRESS/Philippe/Tools/Gcc/man oldincludedir=/usr/include prefix=/usr1/MICRESS/Philippe/Tools/Gcc sbindir=/usr1/MICRESS/Philippe/Tools/Gcc/sbin sharedstatedir=/usr1/MICRESS/Philippe/Tools/Gcc/com sysconfdir=/usr1/MICRESS/Philippe/Tools/Gcc/etc tooldir=/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu build_tooldir=/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu target_alias=i686-pc-linux-gnu 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 LEX=flex M4=m4 MAKE=make RUNTEST=runtest RUNTESTFLAGS= SHELL=/bin/sh YACC=bison -y `echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'` AR_FLAGS=rc `echo 'BOOT_ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'` BOOT_CFLAGS=-g -O2 -fomit-frame-pointer BOOT_LDFLAGS= CFLAGS=-g -O2 CXXFLAGS=-g -O2 LDFLAGS= LIBCFLAGS=-g -O2 LIBCXXFLAGS=-g -O2 -fno-implicit-templates STAGE1_CFLAGS=-g -fkeep-inline-functions STAGE1_CHECKING=--enable-checking=yes,types STAGE1_LANGUAGES=c STAGE2_CFLAGS=-g -O2 -fomit-frame-pointer STAGE3_CFLAGS=-g -O2 -fomit-frame-pointer STAGE4_CFLAGS=-g -O2 -fomit-frame-pointer GNATBIND=no GNATMAKE=no AR_FOR_TARGET=ar AS_FOR_TARGET=as CC_FOR_TARGET=/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/xgcc -B/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include CFLAGS_FOR_TARGET=-O2 -g -O2 CPPFLAGS_FOR_TARGET= CXX_FOR_TARGET=g++ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE DLLTOOL_FOR_TARGET=dlltool GCJ_FOR_TARGET=-B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include GFORTRAN_FOR_TARGET=/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/gfortran -B/usr1/MICRESS/Philippe/Compilation/Gcc/./gcc/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/bin/ -B/usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/lib/ -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/include -isystem /usr1/MICRESS/Philippe/Tools/Gcc/i686-pc-linux-gnu/sys-include LD_FOR_TARGET=ld LIPO_FOR_TARGET=lipo LDFLAGS_FOR_TARGET= LIBCFLAGS_FOR_TARGET=-O2 -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 `echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'` LEAN=false CONFIG_SHELL=/bin/sh MAKEINFO=/WORK/BLUE1_USER/philippe/Irix/Gcc_Sources/missing makeinfo --split-size=500 --split-size=500 compare make[2]: Entering directory `/usr1/MICRESS/Philippe/Compilation/Gcc' make[3]: Entering directory `/usr1/MICRESS/Philippe/Compilation/Gcc' rm -f stage_current make[3]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./cfgloopmanip.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/usr1/MICRESS/Philippe/Compilation/Gcc' make: *** [bootstrap] Error 2 Is anyone else seeing that? Thanks! Philippe
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/5/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. Richard.
Re: GCC make errors
On 9/6/07, mandeep singh bhambra [EMAIL PROTECTED] wrote: I have installed the latest binutils (2.9.1) available from the GNU ftp site so I cannot understand why this is occuring. Are there some sort of parameter options I need to enter or do I need to reinstall the binutils with parameter options? 2.9.1 is from the stone-age, 2.18 is current. Richard.
Re: GCC 4.3.0 Status Report (2007-09-04)
There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. As much as I like the idea, wasn't get_non_trapping considered unsafe? Paolo
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/6/07, Paolo Bonzini [EMAIL PROTECTED] wrote: There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. As much as I like the idea, wasn't get_non_trapping considered unsafe? Only if you tried to preserve this information across passes. This updated patch computes this information just for the local transformation. Richard.
Re: GCC 4.3.0 Status Report (2007-09-04)
On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. The patches to make the new -Wconversion work with decimal float types are still pending review. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html Unfortunately, even if I could skip sleep for one night to get some extra time, I won't have the means needed to test them, update them to current trunk or commit them before Sep 10th. Perhaps in two or three weeks I could... By the way, have the patches for FixedPointArithmetic added Wconversion support? I guess that will make the patches above to not apply cleanly anymore. Cheers, Manuel.
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: [RFC] missing return warnings
On 06/09/07, Jan Hubicka [EMAIL PROTECTED] wrote:
I wonder what we want to do here - I guess we can either make the
warning unconditional and declare it as two indpendent things or we can
just drop the feature since user will get properly warned on every
function he actually uses.
What would be preferred solution here?
My preferred solution would be that TREE_NO_WARNING did actually
prevent to emit a duplicate warning.
tree-cfg.c (execute_warn_function_return)
--
/* If we see return; in some basic block, then we do reach the end
without returning a value. */
else if (warn_return_type
!TREE_NO_WARNING (cfun-decl)
EDGE_COUNT (EXIT_BLOCK_PTR-preds) 0
!VOID_TYPE_P (TREE_TYPE (TREE_TYPE (cfun-decl
{
FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR-preds)
{
tree last = last_stmt (e-src);
if (TREE_CODE (last) == RETURN_EXPR
TREE_OPERAND (last, 0) == NULL
!TREE_NO_WARNING (last))
{
#ifdef USE_MAPPED_LOCATION
location = EXPR_LOCATION (last);
if (location == UNKNOWN_LOCATION)
location = cfun-function_end_locus;
warning (0, %Hcontrol reaches end of non-void function,
location);
#else
locus = EXPR_LOCUS (last);
if (!locus)
locus = cfun-function_end_locus;
warning (0, %Hcontrol reaches end of non-void function, locus);
#endif
TREE_NO_WARNING (cfun-decl) = 1;
break;
}
}
}
Why is that not so? That would also prevent the whole loop from being
executed at all. Do cfun-decl and fndecl point to different things?
If that is difficult then not getting a warning about a function that
is not used does not seem so tragic as long as the middle-end warns
for every case that the front-end would warn (assuming the function is
used). The warning in the middle-end does not depend on optimization
being enabled, does it?
Cheers,
Manuel.
Re: GCC 4.3.0 Status Report (2007-09-04)
Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I am still planning to do some retuning of inliner (our inline limits wasn't revisited for inclusion of SSA optimizers). I am now waiting on Diego to decide on http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00318.html that makes the metrics looks quite significandly different. Then I will run few tests on our C++/SPEC tester in hope that we can now significandly cut some of the limits previously pushed up by the tests with large abstraction (DLV/Tramp3d) and speedup compilation/reduce binaries. It will probably take more than 2 days, but I hope it is acceptable for early stage3. I will be on conference from 10th to 16th, but I expect to be able to do the benchmarking needed. Honza
Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'
Christian Joensson wrote: Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a bootstrap failure: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o ../../gcc/gcc/ada/trans.c: In function `convert_with_check': ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN' make[3]: *** [ada/trans.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 It looks like this is due to this change, not my modification to trans.c: 2007-09-05 Janis Johnson [EMAIL PROTECTED] * optabs.c (expand_float): Convert unsigned integer as signed only if it provides sufficient accuracy; add mode argument to real_2expN. (expand_fix): Fix comment typos; extend binary float into mode wider than destination for converion to unsigned integer; add mode argument to real_2expN. * real.c (real_2expN): Add mode argument to special-case decimal float values. * real.h (real_2expN): Ditto. * fixed-value.c (check_real_for_fixed_mode): Add mode argument to real_2expN. (fixed_from_string): Ditto. (fixed_to_decimal): Ditto. (fixed_convert_from_real): Ditto. (real_convert_from_fixed): Ditto. * config/rs6000/rs6000.md (FP): Include DD and TD modes. * config/rs6000/dfp.md (extendddtd2, a3, addtd3, subdd3, subtd3, muldd3, multd3, divdd3, divtd3, cmpdd_internal1, cmptd_internal1, floatditd2, ftruncdd2, fixdddi2, ftrunctd2, fixddi2): New. -Sandra
Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'
2007/9/6, Sandra Loosemore [EMAIL PROTECTED]: Christian Joensson wrote: Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a bootstrap failure: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/ada/trans.c -o ada/trans.o ../../gcc/gcc/ada/trans.c: In function `convert_with_check': ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN' make[3]: *** [ada/trans.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 It looks like this is due to this change, not my modification to trans.c: 2007-09-05 Janis Johnson [EMAIL PROTECTED] * optabs.c (expand_float): Convert unsigned integer as signed only if it provides sufficient accuracy; add mode argument to real_2expN. (expand_fix): Fix comment typos; extend binary float into mode wider than destination for converion to unsigned integer; add mode argument to real_2expN. * real.c (real_2expN): Add mode argument to special-case decimal float values. * real.h (real_2expN): Ditto. * fixed-value.c (check_real_for_fixed_mode): Add mode argument to real_2expN. (fixed_from_string): Ditto. (fixed_to_decimal): Ditto. (fixed_convert_from_real): Ditto. (real_convert_from_fixed): Ditto. * config/rs6000/rs6000.md (FP): Include DD and TD modes. * config/rs6000/dfp.md (extendddtd2, a3, addtd3, subdd3, subtd3, muldd3, multd3, divdd3, divtd3, cmpdd_internal1, cmptd_internal1, floatditd2, ftruncdd2, fixdddi2, ftrunctd2, fixddi2): New. sorry, I didn't look (at all) what was in your commit, I simply looked at it and saw that you were the last one on it... btw, still fails at Thu Sep 6 13:05:57 UTC 2007 (revision 128182). this is on Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages: binutils 20060817-1 2.17.50 20060817 bison2.3-1 2.3 cygwin 1.5.24-2 (rev. 1.46 of newlib's stdio.h) dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc 3.4.4-3 gcc-ada 3.4.4-3 gcc-g++ 3.4.4-3 gmp 4.2.1-1 make 3.81-1 mpfr 2.2.1-1 tcltk20060202-1 8.4 w32api 3.10-1 -- Cheers, /ChJ
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote: We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I still plan to submit the loop distribution pass. Sebastian
Re: GCC make errors
mandeep singh bhambra wrote: I have installed the latest binutils (2.9.1) available from the GNU ftp site so I cannot understand why this is occuring. Are there some sort of parameter options I need to enter or do I need to reinstall the binutils with parameter options? On my laptop, with absolutely no attention to updating binutils, I get [EMAIL PROTECTED]:~ ld --version GNU ld (GNU Binutils) 2.17.50.20070726-4 (SUSE Linux) If you keep both an old and a new binutils installed in separate directories, it's difficult to assure use of the new one, unless you reconfigure your gcc --with-ld so that gcc's implicit use of ld will take the new one.
Re: Register allocation issues
Matt Lee writes: Matt The problem is, that though the loads can be optimized by pipelining Matt them. The register allocator has created a dependency by using only r3 Matt and r4, instead of using the other volatiles. GCC's register allocator currently is designed to minimize the number of hard registers. As Ian mentioned, -frename-registers tries to perform register renaming with available registers after register allocation. As they say, Your Mileage May Vary. David
RE: Register allocation issues
On 05 September 2007 23:47, Matt Lee wrote:
Registers r3 to r12 are volatiles. However, for the C code below,
struct foo {
int a[4];
} ;
struct foo p, q;
void func ()
{
memcpy (p, q, sizeof (struct foo));
}
I am getting a instruction sequence for func() such as,
load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8
The problem is, that though the loads can be optimized by pipelining
them. The register allocator has created a dependency by using only r3
and r4, instead of using the other volatiles.
Does your backend define a movdi pattern?
cheers,
DaveK
--
Can't think of a witty .sigline today
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. Yep, it does fix the problem. Honza TIA Dominique
warnings in GCC source?
Hello All,
In most of GCC source code, it is perfectly normal to expect that no
warnings should appear, even if the sources are compiled with -Wall or
more. Actually the GCC bootstrap process seems to require this.
However, I see some occasions where warnings might be quite difficult to
avoid:
1: DLSYM: This probably should concern the plugin branch (or
experiment): the POSIX way of getting a routine inside a plug-in is
dlsym (or which happens to return a pointer, which has to be cast to a
function pointer somewhere. This cast will get a warning at a certain
level, like
warning: ISO C forbids conversion of object pointer to function
pointer type
This warning cannot be easily avoided. IIRC, some future POSIX standard
is expected to provide a dlfsym variant to dlsym.
2. generated code: when some C files are generated, it may be hard to
avoid some warnings, typically a generated C function might have unused
arguments (which might be not very easy to detect at generation stage).
So is there an easy way to have some acceptable warnings in GCC?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
ARM miscompilation of __moddi3 on trunk
This simple test case:
#include stdio.h
int ten = 10;
int main()
{
printf (%lld\n, 92233720368547758LL % ten);
return 0;
}
returns
0
because (afaics) __moddi3 is miscompiled.
Breakpoint 4, __moddi3 (u=92233720368547758, v=10)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:923
(gdb) fin
Run till exit from #0 __moddi3 (u=value optimized out, v=92233718306963466)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:919
0x8474 in main () at ppp.c:7
Value returned is $3 = 0
Recompiling libgcc with -O0 fixes the problem:
(gdb)
(gdb) fin
Run till exit from #0 __moddi3 (u=92233720368547758, v=10)
at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:879
0x84a4 in main () at ppp.c:7
Value returned is $4 = 8
And recompiling just _moddi3.o fixes it again.
Target: arm-linux-gnueabi
Configured with: /home/aph/gcc/trunk/configure --with-system-zlib
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--disable-multilib --disable-static arm-linux-gnueabi --disable-bootstrap
--disable-sjlj-exceptions --prefix=/home/aph/gcc/install
build_alias=arm-linux-gnueabi host_alias=arm-linux-gnueabi
target_alias=arm-linux-gnueabi --enable-languages=c,c++,java --no-create
--no-recursion
Andrew.
RE: warnings in GCC source?
On 06 September 2007 16:55, Basile STARYNKEVITCH wrote: 2. generated code: when some C files are generated, it may be hard to avoid some warnings, typically a generated C function might have unused arguments (which might be not very easy to detect at generation stage). Generate __attribute__ ((unused)) on all parameters/variables, regardless. cheers, DaveK -- Can't think of a witty .sigline today
Re: warnings in GCC source?
Basile STARYNKEVITCH [EMAIL PROTECTED] writes: So is there an easy way to have some acceptable warnings in GCC? See gcc/Makefile.in, look for -Wno-error. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Is stmt_ann()-references_memory equal to !ZERO_SSA_OPERANDS (stmt, (SSA_OP_VUSE | SSA_OP_VIRTUAL_DEFS)?
$subject? During early optimization the !ZERO_SSA_OPERANDS check doesn't say the truth (well it does, but only in some sense) while the references_memory flag seems to be updated ok. There is one case, for calls, where we set references_memory unconditionally even if we later might not add any virtual operands at all. So, is it ok to replace those checks by checking the variable annotation instead? Thanks, Richard.
Re: Is stmt_ann()-references_memory equal to !ZERO_SSA_OPERANDS (stmt, (SSA_OP_VUSE | SSA_OP_VIRTUAL_DEFS)?
On 9/6/07, Richard Guenther [EMAIL PROTECTED] wrote: $subject? It is not. You can have a statement that references memory and have no virtual operands at all (volatile or totally pruned VOPs for instance). Also, the very first alias analysis pass will find statements with no VOPs but with memory references. stmt_references_memory_p() must work regardless. So, is it ok to replace those checks by checking the variable annotation instead? What variable annotation? This is a statement annotation.
can't reinterpret_cast to/from the same type
hello,
i don't know if it's a bug, please clarify:
rc.cpp:
--8--
void f()
{
int x = 0;
int y = reinterpret_castint(x);
}
--8--
gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
gcc -c rc.cpp:
rc.cpp: In function ‘void f()’:
rc.cpp:4: error: invalid cast from type ‘int’ to type ‘int’
i suspected that one could cast from int to int.
google hasn't found any relevant pages for 'gcc reinterpret cast bug'
regards, peter
[lto] project: adding --with-libelf to configure
The LTO driver requires libelf and currently grovels around in the system directories looking for it, which may not always be the right place to find it. (This bit me when building LTO on our new Linux machines, which do not have libelf installed.) The Right Thing would be to add a --with-libelf flag to configure so we wouldn't have to assume it's always installed in one particular place. A small LTO project would be for someone to add a --with-libelf to configure. I'm not an expert at configury; would somebody else like to take a whack at this? -Nathan
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Kaveh R. GHAZI wrote: (Sorry, first one bounced from gcc@ because it was over 400k) Hi Jan, On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2 complaining several times about rtl sharing. I've included four .i files for modules that ICEed during stage2, and the cc1 invocations below. Would you please take a look? Jan proposed the below patch. I successfully tested it and I'm testing now. Regards, Andreas Index: reorg.c === --- reorg.c (revision 128181) +++ reorg.c (working copy) @@ -3991,6 +3991,9 @@ if (GET_CODE (pat) == SEQUENCE) insn = XVECEXP (pat, 0, 0); } + if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE + INSN_P (XEXP (PATTERN (insn), 0))) + delete_insn (insn); if (!JUMP_P (insn)) continue;
RE: GCC 4.3.0 Status Report (2007-09-04)
Manuel López-Ibáñez wrote: On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. The patches to make the new -Wconversion work with decimal float types are still pending review. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html Unfortunately, even if I could skip sleep for one night to get some extra time, I won't have the means needed to test them, update them to current trunk or commit them before Sep 10th. Perhaps in two or three weeks I could... By the way, have the patches for FixedPointArithmetic added Wconversion support? I guess that will make the patches above to not apply cleanly anymore. Not yet. After I get the remaining patches (7, 8, 9, 10) checked in, I will see how much work is needed to support Wconversion for fixed-point types. Thanks! Regards, Chao-ying
Re: Bootstrap failure under Irix
On Thu, 2007-09-06 at 09:47 +0200, Philippe Schaffnit wrote: Hi! I am seeing the folowing bootstrap failure under SGI Irix: /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md: In function 'gen_fixuns_truncdfsi2': /USER/philippe/Irix/Gcc_Sources/gcc/config/mips/mips.md:2808: error: too few arguments to function 'real_2expN' My last attempt at wa succesful with : '4.3.0 20070823 (experimental) [trunk revision 127728]' (I haven't tried in between). Can anyone suggest anything? I broke this, and reverted the patch (and two other patches that cleaned up after it) in r128193. Janis
Re: Bootstrap broken: ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN'
On Thu, 2007-09-06 at 15:32 +0200, Christian Joensson wrote: 2007/9/6, Sandra Loosemore [EMAIL PROTECTED]: Christian Joensson wrote: Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a bootstrap failure: ../../gcc/gcc/ada/trans.c: In function `convert_with_check': ../../gcc/gcc/ada/trans.c:5896: error: too few arguments to function `real_2expN' It looks like this is due to this change, not my modification to trans.c: 2007-09-05 Janis Johnson [EMAIL PROTECTED] I've reverted this patch, and two cleanup patches, in r128193. Janis
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
(Sorry, first one bounced from gcc@ because it was over 400k)
Hi Jan,
On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing. I've included four .i files
for modules that ICEed during stage2, and the cc1 invocations below.
Would you please take a look?
Hi,
I already have fix for this just waiting for Andreas Tobler to verify
that it does what expected. If you could give it a try, it would be
nice.
The problem is
/* Called when INSN is being moved from a location near the target of a jump.
We leave a marker of the form (use (INSN)) immediately in front
of WHERE for mark_target_live_regs. These markers will be deleted when
reorg finishes.
We used to try to update the live status of registers if WHERE is at
the start of a basic block, but that can't work since we may remove a
BARRIER in relax_delay_slots. */
static void
update_block (rtx insn, rtx where)
{
/* Ignore if this was in a delay slot and it came from the target of
a branch. */
if (INSN_FROM_TARGET_P (insn))
return;
emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);
/* INSN might be making a value live in a block where it didn't use to
be. So recompute liveness information for this block. */
incr_ticks_for_insn (insn);
}
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+ INSN_P (XEXP (PATTERN (insn), 0)))
+ delete_insn (insn);
if (!JUMP_P (insn))
continue;
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Hi,
I already have fix for this just waiting for Andreas Tobler to verify
that it does what expected. If you could give it a try, it would be
nice.
The problem is
/* Called when INSN is being moved from a location near the target of a jump.
We leave a marker of the form (use (INSN)) immediately in front
of WHERE for mark_target_live_regs. These markers will be deleted when
reorg finishes.
We used to try to update the live status of registers if WHERE is at
the start of a basic block, but that can't work since we may remove a
BARRIER in relax_delay_slots. */
static void
update_block (rtx insn, rtx where)
{
/* Ignore if this was in a delay slot and it came from the target of
a branch. */
if (INSN_FROM_TARGET_P (insn))
return;
emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);
/* INSN might be making a value live in a block where it didn't use to
be. So recompute liveness information for this block. */
incr_ticks_for_insn (insn);
}
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
Honza
Since patch seems to work for Andreas, would it be OK?
* recog.c (dbr_schedule): Remove placeholder USE insns
previously inserted by update_block.
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+INSN_P (XEXP (PATTERN (insn), 0)))
+ delete_insn (insn);
if (!JUMP_P (insn))
continue;
RE: GCC 4.3.0 Status Report (2007-09-04)
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote: We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I still plan to submit a patch for the x86 target cost model tuning. Harsha
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Ian
Re: Register allocation issues
On 9/6/07, David Edelsohn [EMAIL PROTECTED] wrote: Matt Lee writes: Matt The problem is, that though the loads can be optimized by pipelining Matt them. The register allocator has created a dependency by using only r3 Matt and r4, instead of using the other volatiles. GCC's register allocator currently is designed to minimize the number of hard registers. As Ian mentioned, -frename-registers tries to perform register renaming with available registers after register allocation. As they say, Your Mileage May Vary. There is no point trying to minimize usage of volatile hard registers, is there? They are precisely there to be used up as much as needed. The function is a leaf procedure as well, so there are no other considerations. Lastly, architectures like PPC do make use of more registers (without -frename-registers), so there has to be something in the PPC back-end that allows for the liberal use or in mine that prevents such. -- thanks, Matt
Re: Register allocation issues
On 9/6/07, Dave Korn [EMAIL PROTECTED] wrote:
On 05 September 2007 23:47, Matt Lee wrote:
Registers r3 to r12 are volatiles. However, for the C code below,
struct foo {
int a[4];
} ;
struct foo p, q;
void func ()
{
memcpy (p, q, sizeof (struct foo));
}
I am getting a instruction sequence for func() such as,
load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8
The problem is, that though the loads can be optimized by pipelining
them. The register allocator has created a dependency by using only r3
and r4, instead of using the other volatiles.
Does your backend define a movdi pattern?
Yes it does. But in this case, these are word-by-word moves from
memory to memory and make use of only movsi.
--
thanks,
Matt
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
I must admit I have no idea what those placeholders are good for...
Honza
Ian
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
Ah, it's from the calls to fill_simple_delay_slots in
make_return_insns. The Delete any USE insns loop needs to move
below that.
I must admit I have no idea what those placeholders are good for...
They tell mark_target_live_regs that the registers used by the insn
which was moved are live.
Ian
Re: Register allocation issues
Matt Lee writes: Date: Thu, 06 Sep 2007 15:02:52 -0400 From: David Edelsohn [EMAIL PROTECTED] Matt There is no point trying to minimize usage of volatile hard registers, Matt is there? They are precisely there to be used up as much as needed. Matt The function is a leaf procedure as well, so there are no other Matt considerations. Lastly, architectures like PPC do make use of more Matt registers (without -frename-registers), so there has to be something Matt in the PPC back-end that allows for the liberal use or in mine that Matt prevents such. GCC RA mostly is tuned for IA-32 with very few registers. The rs6000 port defines the movmemsi pattern calling expand_block_move() which generates many intermediate pseudos. David
Re: Register allocation issues
load r3, q + 0 load r4, q + 4 store r3, p + 0 store r4, p + 4 load r3, q + 4 load r4, q + 8 store r3, p + 4 store r4, p + 8 These last four lines should be load r3, q + 8 load r4, q + 12 store r3, p + 8 store r4, p + 12 Did you just typo it or do you have a bigger problem? The problems might even be connected, who knows :-) Segher
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't
need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
Ah, it's from the calls to fill_simple_delay_slots in
make_return_insns. The Delete any USE insns loop needs to move
below that.
I must admit I have no idea what those placeholders are good for...
They tell mark_target_live_regs that the registers used by the insn
which was moved are live.
Ah, I see.
The attached patch seems to work on my testcase too.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3863,17 +3863,6 @@ dbr_schedule (rtx first)
relax_delay_slots (first);
}
- /* Delete any USE insns made by update_block; subsequent passes don't need
- them or know how to deal with them. */
- for (insn = first; insn; insn = next)
-{
- next = NEXT_INSN (insn);
-
- if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
- INSN_P (XEXP (PATTERN (insn), 0)))
- next = delete_related_insns (insn);
-}
-
/* If we made an end of function label, indicate that it is now
safe to delete it by undoing our prior adjustment to LABEL_NUSES.
If it is now unused, delete it. */
@@ -3885,6 +3874,17 @@ dbr_schedule (rtx first)
make_return_insns (first);
#endif
+ /* Delete any USE insns made by update_block; subsequent passes don't need
+ them or know how to deal with them. */
+ for (insn = first; insn; insn = next)
+{
+ next = NEXT_INSN (insn);
+
+ if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+ INSN_P (XEXP (PATTERN (insn), 0)))
+ next = delete_related_insns (insn);
+}
+
obstack_free (unfilled_slots_obstack, unfilled_firstobj);
/* It is not clear why the line below is needed, but it does seem to be. */
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes: The attached patch seems to work on my testcase too. This patch is OK if it passes testing and gets a ChangeLog entry. Thanks. Ian
Re: Register allocation issues
On 9/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matt Lee writes: Date: Thu, 06 Sep 2007 15:02:52 -0400 From: David Edelsohn [EMAIL PROTECTED] Matt There is no point trying to minimize usage of volatile hard registers, Matt is there? They are precisely there to be used up as much as needed. Matt The function is a leaf procedure as well, so there are no other Matt considerations. Lastly, architectures like PPC do make use of more Matt registers (without -frename-registers), so there has to be something Matt in the PPC back-end that allows for the liberal use or in mine that Matt prevents such. GCC RA mostly is tuned for IA-32 with very few registers. The rs6000 port defines the movmemsi pattern calling expand_block_move() which generates many intermediate pseudos. So does mine. My generated RTL has all the right looking RTL with a unique pseudo for each load/store pair. If you see the dump in the original email from the .lreg files, the problem is that these pseudos get bound to only 2 out of 10 candidate volatile registers. -- thanks, Matt
Re: Register allocation issues
On 9/6/07, Segher Boessenkool [EMAIL PROTECTED] wrote: load r3, q + 0 load r4, q + 4 store r3, p + 0 store r4, p + 4 load r3, q + 4 load r4, q + 8 store r3, p + 4 store r4, p + 8 These last four lines should be load r3, q + 8 load r4, q + 12 store r3, p + 8 store r4, p + 12 Did you just typo it or do you have a bigger problem? The problems might even be connected, who knows :-) Sorry, that was a typo.
Re: [RFC] missing return warnings
Jan Hubicka wrote:
For C++ there are number of cases I need to go through dealing with
attempts to not instantiate non-inline methods that won't be needed.
I'm not sure exactly what cases you're referring to, but please be
careful. For example, changing if/when we instantiate template
functions, or if/when we generate bodies for implicitly defined
constructors, destructors, or assignment operators would be a semantic
change, and contrary to the standard.
For C it seems to be single case for return warning:
/* PR c++/4872 */
/* { dg-do compile } */
/* { dg-options -Wreturn-type } */
static inline int f() {} /* { dg-warning return missing return } */
In this case we produce missing return warning from frontend.
This however is not truly consistent - if I make the function used, we
actually get two warnings - one from frontend, one from middle end
(that is CFG aware and does not merely check for presence of return
statement in function).
As you know, I don't like the middle end issuing warnings at all. So,
you'll not be surprised that I think we should warn about this function
independent of optimization. People want these warnings to tell them
about possible bugs in their software, not just the ones that affect
them in their current configuration, depending on how much optimization
applies, etc. If we want the middle end to warn about this kind of
case, we should make sure that it does so for all functions, used or not.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: [RFC] missing return warnings
Jan Hubicka wrote: I am basically trying to avoid need for DECL_INLINE (while keeping DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is now doing all the job himself to figure out what is or isn't needed. That certainly makes sense to me. With the noreturn warning made unconditional: ... With the noreturn warning disabled completely: ... So it seems to be all about those warnings now. OK, that sounds pretty encouraging. Thansk, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] missing return warnings
Jan Hubicka wrote:
For C++ there are number of cases I need to go through dealing with
attempts to not instantiate non-inline methods that won't be needed.
I'm not sure exactly what cases you're referring to, but please be
careful. For example, changing if/when we instantiate template
functions, or if/when we generate bodies for implicitly defined
constructors, destructors, or assignment operators would be a semantic
change, and contrary to the standard.
I am basically trying to avoid need for DECL_INLINE (while keeping
DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is
now doing all the job himself to figure out what is or isn't needed.
There seems to be whole a lot of legacy code that is now wrong and/or
unnecesary (such as code preventing optimization of stack assignments on
inlinable functions to aid inliner or a lot of code assuming that only
inlinable functions are deferred).
We still should care about DECL_DECLARED_INLINE, if it affects semantics
of standard, but I would hope the output from frontends to actually not
depend on -finline-functions flag if possible. I am experimenting with
the attached patch, it adds few failures:
With the noreturn warning made unconditional:
g++.dg/warn/pr23075.C (test for excess errors)
g++.old-deja/g++.brendan/crash52.C (test for excess errors)
g++.old-deja/g++.jason/report.C (test for excess errors)
gcc.dg/20040206-1.c (test for warnings, line 10)
gcc.dg/20040206-1.c (test for excess errors)
gcc.dg/pr23075.c (test for warnings, line 14)
gcc.dg/pr23075.c (test for excess errors)
gcc.dg/return-type-1.c (test for excess errors)
gcc.dg/return-type-1.c warning for falling off end of non-void function
(test for warnings, line 9)
gcc.dg/return-type-3.c (test for excess errors)
gcc.dg/return-type-3.c warning for falling off end of non-void function
(test for warnings, line 14)
With the noreturn warning disabled completely:
g++.dg/warn/noreturn-2.C (test for warnings, line 4)
g++.old-deja/g++.bugs/900205_03.C (test for errors, line 29)
g++.old-deja/g++.bugs/900205_03.C (test for errors, line 32)
g++.old-deja/g++.law/operators17.C (test for warnings, line 11)
gcc.dg/Wreturn-type.c (test for excess errors)
gcc.dg/Wreturn-type.c missing return (test for warnings, line 5)
So it seems to be all about those warnings now.
For C it seems to be single case for return warning:
/* PR c++/4872 */
/* { dg-do compile } */
/* { dg-options -Wreturn-type } */
static inline int f() {} /* { dg-warning return missing return } */
In this case we produce missing return warning from frontend.
This however is not truly consistent - if I make the function used, we
actually get two warnings - one from frontend, one from middle end
(that is CFG aware and does not merely check for presence of return
statement in function).
As you know, I don't like the middle end issuing warnings at all. So,
you'll not be surprised that I think we should warn about this function
independent of optimization. People want these warnings to tell them
about possible bugs in their software, not just the ones that affect
them in their current configuration, depending on how much optimization
applies, etc. If we want the middle end to warn about this kind of
case, we should make sure that it does so for all functions, used or not.
Yep, I agree that the warnings should generally come from frontends.
And in fact I was
Re: [RFC] missing return warnings
Jan Hubicka wrote: I am basically trying to avoid need for DECL_INLINE (while keeping DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is now doing all the job himself to figure out what is or isn't needed. That certainly makes sense to me. With the noreturn warning made unconditional: ... With the noreturn warning disabled completely: ... So it seems to be all about those warnings now. OK, that sounds pretty encouraging. One problem that I am concerned about is that C++ frontend is actually trying to avoid instantiating some stuff that it knows will not be needed if not inlined. I would kill this logic, but I hope this is the case where the feature is not worth the maintenance cost. I've applied the patch for C++ nightly testing, for tramp3d, the difference seems to be in wash. I will do some proofreading tomorrow and send updated patch. Honza Thansk, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] missing return warnings
Jan Hubicka wrote: One problem that I am concerned about is that C++ frontend is actually trying to avoid instantiating some stuff that it knows will not be needed if not inlined. I would kill this logic, but I hope this is the case where the feature is not worth the maintenance cost. We need to be careful about terms. Instantiating means substituting actual arguments into a template definition to get an actual definition. There's also generating definitions for implicitly-declared class member functions; that doesn't have a great term in the standard, but we can call it defining implicit functions. Which one of these situations are you concerned about? I guess, in a way, it doesn't matter which one. In both cases, the standard says when you must do it. So, we can't change that. I suspect that the code that you're looking at may have just been a front-end optimization. For example, at least at one point, it made GCC a lot slower to have very long instantiation chains: f needs gint, gint needs hint, etc. It was better to instantiate things one at a time than to have a deep stack. But, if hint was inline, then we needed to make sure its body was available when gint was being instantiated so that we could inline it. Now, that's probably no longer true. We can probably always avoid the deep stack, and just let cgraph handle it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GC work status, any comments?
Hello, I've spent last two months at Google quietly working on the boehm-gc branch from my last year's SoC project - http://gcc.gnu.org/wiki/Garbage_collection_tuning . To recap, I've integrated Boehm's GC into GCC proper, adjusted gengtype and GGC support files to generate typed GC allocators for every GTY type, and added type tag to every GC allocated object. However, as I was trying to make Boehm's GC use exact type layout information, I was running into increasingly difficult issues with every type converted. So then I stopped and scavenged the branch for immediately useful stuff, almost all of which I have submitted to the mainline by now. So my question is, what do you want to see done next? It seems that continuing working with Boehm's GC will be not that productive. I'm thinking about bringing over to the mainline the typed GC allocator infrastructure, so that every ggc_alloc becomes, e.g. ggc_alloc_rtx_def, ggc_alloc_cleared_tree_node and so on for every GTY'ed type. In the first step they would be simple wrappers around ggc_alloc - I would not add the type tag byte to the allocated objects and that would wait until explicit marker stack, the first user of them. Immediate benefits of this change would be somewhat better type safety and protection from GC misuses with non-GTY types (use pool or obstack instead). Alternatives are bringing over type tag overhead to the mainline as well, or starting working on explicit marker stack on the top of ggc-page. Any comments? -- Laurynas
Bootstrap broke today on mipsel-linux.
With revision 128207 Configured: ../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install --target=mipsel-linux --build=mipsel-linux --host=mipsel-linux --with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1 --disable-java-awt --without-x --enable-__cxa_atexit --disable-jvmpi I used to work: http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00234.html /home/ddaney/gccsvn/trunk-build/./gcc/xgcc -shared-libgcc -B/home/ddaney/gccsvn/trunk-build/./gcc -nostdinc++ -L/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/src -L/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/src/.libs -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/lib/ -isystem /home/ddaney/gccsvn/trunk-install/mipsel-linux/include -isystem /home/ddaney/gccsvn/trunk-install/mipsel-linux/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -D_GNU_SOURCE -I/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/mipsel-linux -I/home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include -I/home/ddaney/gccsvn/trunk/libstdc++-v3/libsupc++ -O2 -g /home/ddaney/gccsvn/trunk/libstdc++-v3/include/precompiled/extc++.h -o mipsel-linux/bits/extc++.h.gch/O2g.gch In file included from /home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:344, from /home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:53, from /home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/priority_queue.hpp:51, from /home/ddaney/gccsvn/trunk/libstdc++-v3/include/precompiled/extc++.h:63: /home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp: In member function 'void pb_ds::detail::binary_heap_Value_Type, Cmp_Fn, Allocator::insert_entry(typename __gnu_cxx::__conditional_typepb_ds::detail::binary_heap_Value_Type, Cmp_Fn, Allocator::simple_value, Value_Type, typename Allocator::rebindValue_Type::other::pointer::__type)': /home/ddaney/gccsvn/trunk-build/mipsel-linux/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp:94: internal compiler error: tree check: expected integer_cst, have scope_ref in tree_int_cst_sgn, at tree.c:4974 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
On Thu, 6 Sep 2007, Jan Hubicka wrote: Hi, I already have fix for this just waiting for Andreas Tobler to verify that it does what expected. If you could give it a try, it would be nice. Honza Index: reorg.c === --- reorg.c (revision 128145) +++ reorg.c (working copy) @@ -3991,6 +3991,9 @@ dbr_schedule (rtx first) if (GET_CODE (pat) == SEQUENCE) insn = XVECEXP (pat, 0, 0); } + if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE +INSN_P (XEXP (PATTERN (insn), 0))) + delete_insn (insn); if (!JUMP_P (insn)) continue; FWIW, this patch fixes the problem. Test results here: http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00313.html I'll try again with your updated version tonight. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
[Bug c++/19163] __attribute__((aligned)) not working in template
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-15 21:09:09 |2007-09-06 06:11:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19163
[Bug c++/19163] __attribute__((aligned)) not working in template
--- Comment #11 from mark at codesourcery dot com 2007-09-06 06:16 --- Subject: Re: __attribute__((aligned)) not working in template jason at gcc dot gnu dot org wrote: --- Comment #10 from jason at gcc dot gnu dot org 2007-09-06 05:50 --- Vague references: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00247.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743 Seems like Mark and/or Nathan have/had state on this that they haven't shared with the lists. I don't think so, but I'm not quite sure I understand. Anyhow, I'm sure I don't have any uncontributed patches for this, and I don't think Nathan has either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19163
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #7 from DHConsultancy at skynet dot be 2007-09-06 07:45 --- Subject: Re: gfortran crt2.o not found under Vista It works! Thank you very much for this quick response! Daniel fxcoudert at gcc dot gnu dot org wrote: --- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-05 15:58 --- Daniel, Can you try the updated binaries at http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe ? They are built with the patch in comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug c++/19163] __attribute__((aligned)) not working in template
--- Comment #12 from nathan at codesourcery dot com 2007-09-06 08:15 --- Subject: Re: __attribute__((aligned)) not working in template mark at codesourcery dot com wrote: I don't think so, but I'm not quite sure I understand. Anyhow, I'm sure I don't have any uncontributed patches for this, and I don't think Nathan has either. I do not. I remember looking at it, but didn't get anywhere. nathan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19163
[Bug tree-optimization/33319] New: ICE with vectorization in
when the testcase g++.dg/tree-ssa/pr27549.C is compiled with -ftree-vectorize it ICEs with: Unable to coalesce ssa_names 141 and 280 which are marked as MUST COALESCE. s$b_141(ab) and s$b_280(ab) /Develop/mainline-dn/gcc/gcc/testsuite/g++.dg/tree-ssa/pr27549.C: In function âconst char* foo()â: /Develop/mainline-dn/gcc/gcc/testsuite/g++.dg/tree-ssa/pr27549.C:72: internal compiler error: SSA corruption The testcase is vectorized using versioning-for-aliasing, although it is known at compile time that there is a dependence for sure, so there's no point in testing this at runtime (as pointed out here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01211.html). With --param vect-max-version-for-alias-checks=0 the testcase doesn't get vectorized and doesn't ICE. So, Disabling versioning-for-aliasing when it's redundant (like in the above case) would avoid the ICE, but we should probably figure out what is really causing the ICE. (this is how the testcase is compiled: /Develop/mainline-dn/build1/gcc/testsuite/g++/../../g++ -B/Develop/mainline-dn/build1/gcc/testsuite/g++/../../ /Develop/mainline-dn/gcc/gcc/testsuite/g++.dg/tree-ssa/pr27549.C -nostdinc++ -I/Develop/mainline-dn/build1/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/Develop/mainline-dn/build1/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/Develop/mainline-dn/gcc/libstdc++-v3/libsupc++ -I/Develop/mainline-dn/gcc/libstdc++-v3/include/backward -I/Develop/mainline-dn/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -S -m64 -O2 -ftree-vectorize -maltivec -fdump-tree-vect-details -o pr27549.s) -- Summary: ICE with vectorization in Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-09-06 08:45 --- Subject: Bug 33306 Author: rsandifo Date: Thu Sep 6 08:45:16 2007 New Revision: 128179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128179 Log: gcc/ PR middle-end/33306 * optabs.c (avoid_expensive_constant): Do nothing if MODE is VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #7 from rsandifo at gcc dot gnu dot org 2007-09-06 08:45 --- Serge, thanks for testing. Patch now installed on mainline. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug tree-optimization/33320] New: ICE with vectorization in the testsuite during dataref analysis
When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with vectorization it ICes when the dataref analysis called from vectorizer: /home/dorit/mainline/build2/gcc/xgcc -B/home/dorit/mainline/build2/gcc/ /home/dorit/mainline/gcc/gcc/testsuite/gcc.dg/tree-ssa/predcom-3.c -O2 -fpredictive-commoning -fdump-tree-pcom-details -fno-show-column -S -O2 -ftree-vectorize -fdump-tree-vect-details -o predcom-3.s /home/dorit/mainline/gcc/gcc/testsuite/gcc.dg/tree-ssa/predcom-3.c: In function âtestâ: /home/dorit/mainline/gcc/gcc/testsuite/gcc.dg/tree-ssa/predcom-3.c:7: internal compiler error: Segmentation fault -- Summary: ICE with vectorization in the testsuite during dataref analysis Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org GCC build triplet: i386-linux GCC host triplet: i386-linux GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33320
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2007-09-06 08:56 --- Wouldn't it be an option to simply bail out early (i.e., after the error checks) in case of size == 0 ? E.g., like this: 62 63 rrank = srank + 1; 64 if (rrank GFC_MAX_DIMENSIONS) 65 runtime_error (return rank too large in spread()); 66 67 if (*along rrank) 68 runtime_error (dim outside of rank in spread()); if (size == 0) return Or do we actually have to set something on return ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-06 09:06 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-06 09:06 --- Subject: Bug 33302 Author: rguenth Date: Thu Sep 6 09:05:58 2007 New Revision: 128180 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128180 Log: 2007-09-06 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/33302 * tree-ssa-dse.c (tree_ssa_dse): Connect infinite loops to the exit block before doing the post-dominator walk. * domwalk.c (walk_dominator_tree): The exit block is interesting even if it is not reachable. * gcc.dg/tree-ssa/ssa-dse-11.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/domwalk.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug middle-end/33321] New: gcc manpage contains @option-Wstrict-overflow=1
I don't know how it should look like, but the following looks very strange in the manpage: @option-Wstrict-overflow=1 invoke.texi contains: @table @option @item -Wstrict-overflow=1 ... -- Summary: gcc manpage contains @option-Wstrict-overflow=1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33321
[Bug target/33281] gfortran crt2.o not found under Vista
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||09/msg00447.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-09-04 06:17:29 |2007-09-06 09:56:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug c++/33322] New: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971
when compiling attached file, i'm getting the following ICE: [EMAIL PROTECTED]:~/workspace/nova_ladspa$ gcc-4.2 -o filters.os -c -fPIC -DNDEBUG -Inova/source filters.cpp filters.cpp: In instantiation of âconst unsigned int unnamed::filter_basetrue::freq_portâ: filters.cpp:277: instantiated from âvoidunnamed::filter_baselow::setport(long unsigned int, LADSPA_Data*) [with bool low = true]â filters.cpp:491: instantiated from here filters.cpp:246: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.2/README.Bugs. gcc version: [EMAIL PROTECTED]:~/workspace/nova_ladspa$ gcc-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --disable-werror --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.1 (Debian 4.2.1-3) this is related to the anonymous namespace, that is used -- Summary: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim at klingt dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33322
[Bug c++/33322] internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971
--- Comment #1 from tim at klingt dot org 2007-09-06 10:11 --- Created an attachment (id=14163) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14163action=view) compressed preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33322
Man page.
Hiya. I am an OpenBSD user. I was looking at the online man page for GCC(1) and notice the Author section seems to contain a uri that does not work. Quote: AUTHOR See the Info entry for gcc, or http://gcc.gnu.org/online- docs/gcc/Contributors.html, for contributors to GCC. http://www.openbsd.org/cgi-bin/man.cgi?query=gccsektion=1 As hyphens in uri's are not uncommon I assumed the page had been moved and went to your site. It seems, however, that the uri has suffered in the formatting process. I had a look at the FreeBSD online man pages and notice a similar thing: AUTHOR See the Info entry for gcc, or http://gcc.gnu.org/onlinedocs/gcc/Con- tributors.html, for contributors to GCC. http://www.freebsd.org/cgi/man.cgi?query=gccapropos=0sektion=0manpath=FreeBSD+6.2-RELEASEformat=html From memory, the man pages do not have hyperlinks so users might spot the hyphen as not part of the address. To avoid confusion, perhaps the uri could begin on a new line. Apparently this is the intended page: http://gcc.gnu.org/onlinedocs/gcc/Contributors.html Best wishes, David Walker
[Bug middle-end/33321] gcc manpage contains @option-Wstrict-overflow=1
--- Comment #1 from joseph at codesourcery dot com 2007-09-06 10:40 --- Subject: Re: New: gcc manpage contains @option-Wstrict-overflow=1 On Thu, 6 Sep 2007, burnus at gcc dot gnu dot org wrote: invoke.texi contains: @table @option @item -Wstrict-overflow=1 It should use @table @gcctabopt instead of @table @option (whether this fixes this problem, I don't know). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33321
[Bug c++/33322] internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971
--- Comment #2 from tim at klingt dot org 2007-09-06 11:07 --- ah, forgot to mention ... gcc-4.1 can compile the code: [EMAIL PROTECTED]:~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33322
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #10 from wouter dot vermaelen at scarlet dot be 2007-09-06 11:48 --- I'm sorry, but can you recheck? The testcase at the top of this bug report still generates the same asm code for me. -- wouter dot vermaelen at scarlet dot be changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32
--- Comment #3 from patchapp at dberlin dot org 2007-09-06 11:55 --- Subject: Bug number PR libstdc++/33203 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00310.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #10 from patchapp at dberlin dot org 2007-09-06 11:55 --- Subject: Bug number PR31564 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00319.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #8 from patchapp at dberlin dot org 2007-09-06 11:55 --- Subject: Bug number PR33241 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00322.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #9 from patchapp at dberlin dot org 2007-09-06 11:57 --- Subject: Bug number PR 33298 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00394.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #3 from patchapp at dberlin dot org 2007-09-06 11:57 --- Subject: Bug number PR33297 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00400.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-09-06 12:13
---
The extra store you still see is caused by -ftracer duplicating it.
Optimizations
after that don't catch that (because of the intervening possibly aliasing loads
I guess):
(insn 25 24 27 4 t.ii:3 (set (mem/s:SI (reg/f:DI 102) [4 variable.D.2014.a+0
S4 A64])
(reg:SI 75)) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 75)
(expr_list:REG_EQUAL (plus:SI (mem/s:SI (reg/f:DI 102) [4
variable.D.2014.a+0 S4 A64])
(const_int 4 [0x4]))
(nil
(insn 27 25 28 4 t.ii:18 (set (reg:DI 78 [ variable.addr ])
(zero_extend:DI (mem/s:SI (reg/f:DI 101) [4 variable.addr+0 S4
A64]))) 120 {zero_extendsidi2_rex64} (nil))
...
(insn 96 95 97 4 t.ii:3 (parallel [
(set (reg:SI 83)
(plus:SI (reg:SI 76 [ variable.D.2014.a ])
(const_int 6 [0x6])))
(clobber (reg:CC 17 flags))
]) 235 {*addsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 84 [ variable.D.2014.a ])
(nil
(insn 97 96 98 4 t.ii:3 (set (mem/s:SI (reg/f:DI 102) [4 variable.D.2014.a+0
S4 A64])
(reg:SI 83)) 47 {*movsi_1} (expr_list:REG_EQUAL (plus:SI (mem/s:SI
(reg/f:DI 102) [4 variable.D.2014.a+0 S4 A64])
(const_int 2 [0x2]))
(expr_list:REG_DEAD (reg:SI 83)
(nil
If you build without -ftracer or without -fforce-addr it works (but won't
combine the add on one path). But.. -ftracer was supposed to be moved
to the tree level...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt (for vista)
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-06 12:25 --- (In reply to comment #0) The problem is that the mode parameter is sometimes set to X_OK (system.h, equals 1). X_OK is only defined in system.h if it's not defined by system includes. On mingw, X_OK happens to be defined by io.h. The solution I think is to define X_OK as 0 on the MingW Windows platform. When the mode is 0 msvcrt's _access tests for existence. Which is pretty close to the execute right check. The mingw developers have modified their include files to work around this case, and you can get the old behaviour (X_OK is ignored) by compiling with -D__USE_MINGW_ACCESS (see PR33281). I intend to commit a patch that makes us build the compiler with -D__USE_MINGW_ACCESS, thus removing the problem. I thus intend to close that PR. Zack, if you think we shouldn't use access() at all, do you want to keep this PR open and change its title to reflect this desired change? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org, zackw at panix dot com Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #3 from brett dot albertson at stratech dot com 2007-09-06 13:03 --- (In reply to comment #2) Something changed and it is now working for me, but this did exist on mainline for at least some period of time. Rainer, are you still seeing this behavior? Brett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2007-09-06 13:25 --- Subject: Re: [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 brett dot albertson at stratech dot com writes: Something changed and it is now working for me, but this did exist on mainline for at least some period of time. Rainer, are you still seeing this behavior? I haven't tried a newer tree ( 20070903) yet. A difference might be that Art uses GNU ld (he doesn't state so, though) while Brett and I use Sun ld. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug c++/33323] New: configure with --disable-shared, g++ can't create shared library.
I build gcc with ./configure --disable-shared on x86_64. But I can't create shared library with g++, because libstdc++.a is not build with -fPIC. -- Summary: configure with --disable-shared, g++ can't create shared library. Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cnstar9988 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33323
[Bug c++/33323] configure with --disable-shared, g++ can't create shared library.
--- Comment #1 from cnstar9988 at gmail dot com 2007-09-06 13:30 --- ./configure --disable-shared Because I don't want to dynamic linked with libstdc++.so. I wan't static linked with libstdc++.a. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33323
[Bug middle-end/33318] [4.3 Regression] fortran/expr.c:305: internal compiler error: internal consistency failure
--- Comment #2 from danglin at gcc dot gnu dot org 2007-09-06 13:30 --- No, cc1 is hanging in stage2. I did a core dump: Program terminated with signal 3, Quit. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Reading symbols from /usr/lib/pa20_64/dld.sl...done. Loaded symbols for /usr/lib/pa20_64/dld.sl Reading symbols from /usr/lib/pa20_64/libc.2...done. Loaded symbols for /lib/pa20_64/libc.2 Reading symbols from /usr/lib/pa20_64/libdl.1...done. Loaded symbols for /usr/lib/pa20_64/libdl.1 Reading symbols from /opt/graphics/OpenGL/lib/pa20_64/libogltls.sl...done. Loaded symbols for /opt/graphics/OpenGL/lib/pa20_64/libogltls.sl #0 0x4042cc00 in verify_rtl_sharing () at ../../gcc/gcc/emit-rtl.c:2382 2382if (INSN_P (p)) Breakpoint 1 at 0x403c94d4: file ../../gcc/gcc/diagnostic.c, line 655. Breakpoint 2 at 0x403c92b4: file ../../gcc/gcc/diagnostic.c, line 599. Breakpoint 3 at 0xc018662c Breakpoint 4 at 0xc01dea88 (gdb) bt #0 0x4042cc00 in verify_rtl_sharing () at ../../gcc/gcc/emit-rtl.c:2382 #1 0x40d881bc in cse_insn (insn=0x83fffd3f4320, libcall_insn=0x0) at ../../gcc/gcc/cse.c:4681 #2 0x40d8ee6c in cse_extended_basic_block ( ebb_data=0x83fffdff3390) at ../../gcc/gcc/cse.c:6113 #3 0x40d8f9e4 in cse_main (f=0x83fffbd18100, nregs=10964) at ../../gcc/gcc/cse.c:6296 #4 0x40d922ac in rest_of_handle_cse () at ../../gcc/gcc/cse.c:7031 #5 0x406e5e08 in execute_one_pass (pass=0x80015520) at ../../gcc/gcc/passes.c:1110 #6 0x406e6130 in execute_pass_list (pass=0x80015520) at ../../gcc/gcc/passes.c:1163 #7 0x406e6174 in execute_pass_list (pass=0x80012a18) at ../../gcc/gcc/passes.c:1164 #8 0x40914cb0 in tree_rest_of_compilation (fndecl=0x83fffd30d800) at ../../gcc/gcc/tree-optimize.c:404 #9 0x4023a24c in c_expand_body (fndecl=0x7) at ../../gcc/gcc/c-common.c:4586 #10 0x40c3f698 in cgraph_expand_function (node=0x83fffcc92200) at ../../gcc/gcc/cgraphunit.c:1077 #11 0x40c3fa60 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1146 ---Type return to continue, or q return to quit--- #12 0x40c406a8 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1353 #13 0x4019d2bc in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8080 #14 0x40833588 in compile_file () at ../../gcc/gcc/toplev.c:1058 #15 0x40837044 in do_compile () at ../../gcc/gcc/toplev.c:2229 #16 0x40837160 in toplev_main (argc=43, argv=0x83fffdff2278) at ../../gcc/gcc/toplev.c:2261 #17 0x402a9380 in main (argc=458752, argv=0x923afafafaf) at ../../gcc/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
[Bug c++/33323] configure with --disable-shared, g++ can't create shared library.
--- Comment #2 from pluto at agmk dot net 2007-09-06 13:45 --- you must use the --with-pic option which is currently broken ;) see PR28811. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33323
qhull segfault if compiled with -O2
Hi. I compiled qhull [1] with the following versions: gcc (GCC) 4.2.1 gcc (GCC) 4.3.0 20070906 (experimental) When compiled with -O it works: qhull/src$ make CFLAGS=-O -j /dev/null; ./rbox 5 | ./qhull /dev/null but if I qhull/src$ touch qset.c and recompile it with -O2 then qhull segfaults: qhull/src$ make CFLAGS=-O2 -j /dev/null; ./rbox 5 | ./qhull Segmentation fault If I touch the file again and recompile with -O2, but with an older version of gcc gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52) it works again. [1] http://www.qhull.org/download/qhull-2003.1.tar.gz [2] sha1 of qset.c is cb61179b8dee6b36a8cdc4cba0a6fcc6383e1771 Yes, I read `What we do not want' section, but it seems a single file will be of no use. The bug repeats on different versions of Linux (both 2.4 and 2.6). -- Regards, ASK
[Bug tree-optimization/32821] tree-if-conv:combine_blocks with -ftree-dump-tree-all-details fails on ICE in compilation: segfault
--- Comment #5 from ubizjak at gmail dot com 2007-09-06 14:21 --- I'll take this PR. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-06 14:21:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32821
[Bug middle-end/33318] [4.3 Regression] fortran/expr.c:305: internal compiler error: internal consistency failure
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-06 15:10 --- Subject: Bug 33318 Author: hubicka Date: Thu Sep 6 15:10:28 2007 New Revision: 128187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128187 Log: PR target/33318 * cse.c (fold_rtx): Avoid invalid sharing. Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
--- Comment #2 from pcarlini at suse dot de 2007-09-06 15:39 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-06 15:42 --- Subject: Bug 33281 Author: fxcoudert Date: Thu Sep 6 15:42:02 2007 New Revision: 128188 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128188 Log: PR target/33281 * configure.ac: Use config/mh-mingw on mingw. * configure: Regenerate. * config/mh-mingw: New host makefile fragment. Added: trunk/config/mh-mingw Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-06 15:47 --- Fix committed to mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #19 from daney at gcc dot gnu dot org 2007-09-06 16:00 --- On the trunk (with the patch) there are no regressions with a full bootstrap all default languages on mipsel-linux. The test cases passes also. I say: Commit it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/32586] [4.3 Regression] New VN misses FRE opportunities
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-06 16:05 --- Subject: Bug 32586 Author: rguenth Date: Thu Sep 6 16:05:32 2007 New Revision: 128189 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128189 Log: 2007-09-06 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/32586 * tree-ssa-sccvn.c (simplify_binary_expression): Avoid folding if nothing changed. (simplify_unary_expression): New function. Do tree combining on conversion like codes. (try_to_simplify): Call it. * builtins.c (fold_builtin_cexp): Fold the built expressions. * fold-const.c (fold_unary): Test result of get_callee_fndecl(). * g++.dg/tree-ssa/pr27090.C: Remove XFAILs. * gcc.dg/tree-ssa/ssa-fre-1.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-3.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-5.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-4.c: Likewise, remove scan for now obsolete simplification. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr27090.C trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-5.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32586
[Bug tree-optimization/32586] [4.3 Regression] New VN misses FRE opportunities
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-06 16:06 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32586
