[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-07-29 06:33 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver at kam dot mff dot cuni dot cz writes: rakdver Probably the problem is that -maltivec does not rakdver imply -mabi=altivec, or some similar omission. -maltivec does not imply -mabi=altivec, which is intended. The Bugzilla PR says the target is powerpc64-linux, which implicitly should enable -mabi=altivec. If this is some other target, then the BOOT_CFLAGS should include -mabi=altivec. it's on ppc-linux. Nevertheless, it is suspicious that we allow a fairly natural combination of flags (-O2 -maltivec -ftree-vectorize) to cause misscompilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-07-29 07:16 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver Probably the problem is that -maltivec does not rakdver imply -mabi=altivec, or some similar omission. -maltivec does not imply -mabi=altivec, which is intended. The Bugzilla PR says the target is powerpc64-linux, which implicitly should enable -mabi=altivec. If this is some other target, then the BOOT_CFLAGS should include -mabi=altivec. it's on ppc-linux. I mean, I did the testing on ppc-linux; it is possible that there is another misscompilation on ppc64-linux, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-29 08:10 --- (In reply to comment #5) I have had a quick look and the cause of failures are quite different. Could you please attach the files /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/gfortran.sum and /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/gfortran.log to this PR (possibly compressed, if they're too large)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #5 from dominiq at lps dot ens dot fr 2007-07-29 08:01 --- If you were expecting to be kept buzzy, you'll be glad! The summary is: === gfortran Summary for unix/-fdefault-integer-8//-m32 === # of expected passes18575 # of unexpected failures750 # of expected failures 7 # of untested testcases 39 # of unsupported tests 44 === gfortran Summary for unix/-fdefault-integer-8//-m64 === # of expected passes18708 # of unexpected failures659 # of unexpected successes 1 # of expected failures 6 # of untested testcases 39 # of unsupported tests 28 === gfortran Summary === # of expected passes37283 # of unexpected failures1409 # of unexpected successes 1 # of expected failures 13 # of untested testcases 78 # of unsupported tests 72 /opt/gcc/darwin_buildl/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070727 (experimental) I have had a quick look and the cause of failures are quite different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-29 08:59 --- Created an attachment (id=13996) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13996action=view) log and sum files for the tests with -fdefault-integer-8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-07-29 08:39 --- I think I understand what's wrong with my patch now: The stream initialized with init_error_stream was never flushed. I think I'll go with a naked write() call, which is a) simpler b) more robust. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-29 09:24 --- Considering the number of failures to analyse, I think there is need to avoid duplicate efforts. What is the best way to proceed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-07-29 09:47 --- (In reply to comment #8) Considering the number of failures to analyse, I think there is need to avoid duplicate efforts. What is the best way to proceed? I've started a x86_64-linux testsuite with -fdefault-integer-8, so that we can split problems due to endianness from other problems. We'll then see how many fall into each category. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 10:01 --- Subject: Bug 32879 Author: dfranke Date: Sun Jul 29 10:01:27 2007 New Revision: 127037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127037 Log: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32879 * intrinsic.texi (IRAND, RAND, RANDOM_NUMBER): Document algorithm used for random number generator. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:
--- Comment #4 from doko at gcc dot gnu dot org 2007-07-29 10:10 --- Subject: Bug 32929 Author: doko Date: Sun Jul 29 10:09:54 2007 New Revision: 127038 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127038 Log: 2007-07-29 H.J. Lu [EMAIL PROTECTED] PR libgcj/32929 * aclocal.m4: Regenerated. * configure: Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/aclocal.m4 trunk/libjava/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32929
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-29 10:49 --- Subject: Bug 32879 Author: dfranke Date: Sun Jul 29 10:49:11 2007 New Revision: 127042 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127042 Log: 2007-07-29 Daniel Franke [EMAIL PROTECTED] Backport from trunk: 2007-07-29 Daniel Franke [EMAIL PROTECTED] * invoke.texi: Removed -w from option summary. 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32879 * intrinsic.texi (IRAND, RAND, RANDOM_NUMBER): Document algorithm used for random number generator. 2007-07-13 Daniel Franke [EMAIL PROTECTED] * invoke.texi: Unified upper- and lower-case in menus. (-w, -W): Removed, documented by gcc. * intrinsic.texi: Unified Class-section entries, added subroutine/function warning where appropiate. 2007-05-01 Daniel Franke [EMAIL PROTECTED] * intrinsic.texi (MVBITS): Changed class to elemental subroutine. (RANDOM_NUMBER): Changed class to subroutine. (HUGE, TINY): Changed class to inquiry function. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi branches/gcc-4_2-branch/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-29 10:50 --- Documented in 4.2 and trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-29 11:09 --- The following test cases fail only with -m64, but not, or differently, with -m32. FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os execution test FAIL: gfortran.dg/c_assoc.f90 -O0 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O1 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O2 (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/c_assoc.f90 -Os (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O0 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O0 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O1 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O1 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O2 (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O2 (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/forall_4.f90 -Os (internal compiler error) FAIL: gfortran.dg/forall_4.f90 -Os (test for excess errors) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (internal compiler error) FAIL: gfortran.dg/where_operator_assign_2.f90 -O (test for excess errors) FAIL: gfortran.dg/vect/vect-2.f90 -O scan-tree-dump-times Alignment of access forced using peeling 3 XPASS: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times Vectorizing an unaligned access 2 FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Vectorizing an unaligned access 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #12 from dominiq at lps dot ens dot fr 2007-07-29 11:11 --- Created an attachment (id=13998) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13998action=view) test case failing with -m32, but not, or differently, with -m64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-29 11:21 --- (In reply to comment #7) (In reply to comment #3) This is OK to commit. FX, In developing the testcase, I found out that this version of the patch is wrong - change 'f=0' to 'f=42' to see what I mean (look at the last line). The loop should be unity based and then it works fine. I will commit after regtesting. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-29 11:08 --- Created an attachment (id=13997) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13997action=view) Failures on PPC Darwin8 common to -m32 and -m64 I attached the reduced list of the test cases failing with -m32 or -m64. I have kept the first instance only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-07-29 11:19 --- From your testresults, Dominique, I see the following testcases ICE: gfortran.dg/altreturn_5.f90 gfortran.dg/associated_2.f90 gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/forall_4.f90 gfortran.dg/pointer_function_actual_1.f90 gfortran.dg/ret_pointer_1.f90 gfortran.dg/where_operator_assign_2.f90 gfortran.fortran-torture/compile/pr32417.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 We know about gfortran.fortran-torture/compile/pr32417.f90 (PR 32527, a tree-optimization bug). My x86_64-linux with -m32 -fdefault-integer-8 revealed the following ICES: gfortran.dg/altreturn_5.f90 gfortran.dg/pointer_function_actual_1.f90 gfortran.fortran-torture/compile/pr32417.f90 gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 So, I'm going to investigate and report altreturn_5.f90, pointer_function_actual_1.f90 and intrinsic_set_exponent.f90. If you could please find some time to report the other ones: gfortran.dg/associated_2.f90 gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/forall_4.f90 gfortran.dg/ret_pointer_1.f90 gfortran.dg/where_operator_assign_2.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 I think beginning with ICEs is a worthly choice. The way to track them down is to reduce the testcase to its bare minimum, note the exact error message and obtain a gdb backtrace. If you need help with the latest step, we can arrange an IRC meeting so that I can help you (send me a private mail). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-29 11:44 --- I have already started to investigate gfortran.dg/forall_4.f90. With -m32 it does not ICE but abort due to the line forall (i=1:n, .not. s(i)) a(i) = i the '.not.' seems to be the problem (the corresonding output is '1 2 3 4'). With -m64 I got the ICE. The following gdb session gives: (gdb) run -fdefault-integer-8 -m64 forall_4_db.f90 Starting program: /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 -fdefault-integer-8 -m64 forall_4_db.f90 Reading symbols for shared libraries ..++++. done foot MAIN__ w t forall_4_db.f90: In function 'MAIN__': forall_4_db.f90:39: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:706 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. (gdb) backtrace No stack. As a side question, this PR has open some kind of Pandora box in which some failures are directly related to this PR, but probably many others are not. Would not it be wise to open a meta bug for -fdefault-integer-8 and different PR for unrelated failures? For instance, it seems that forall_4 could be a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #18 from dje at watson dot ibm dot com 2007-07-29 11:57 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC rakdver at kam dot mff dot cuni dot cz writes: it's on ppc-linux. rakdver I mean, I did the testing on ppc-linux; it is possible that there is rakdver another misscompilation on ppc64-linux, though. The target in the PR says powerpc64-linux, which is what confused Andrew and me. There is a valid mode of Altivec programming using builtins and asms that does not require the Altivec ABI. That is what -maltivec supports. I suspect that -ftree-vectorize should enable -mabi=altivec by default on PowerPC. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-29 12:21 --- gfortran.dg/associated_2.f90 gfortran.fortran-torture/execute/intrinsic_associated.f90 gfortran.fortran-torture/execute/intrinsic_associated_2.f90 ICE with the same kind of error (cannot get any backtrace): associated_2_db.f90: In function 'test1': associated_2_db.f90:21: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 intrinsic_associated(_2)?_db.f90: In function 'MAIN__': intrinsic_associated(_2)?_db.f90:15: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libstdc++/32908] Miss lexicographical_compare random access override
-- pcarlini at suse dot de changed: What|Removed |Added CC|rakdver at kam dot mff dot | |cuni dot cz | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-29 12:28:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #16 from dominiq at lps dot ens dot fr 2007-07-29 12:33 --- gfortran.dg/bounds_check_5.f90 gfortran.dg/char_associated_1.f90 gfortran.dg/der_array_1.f90 gfortran.dg/ret_pointer_1.f90 ICE as associated_2_db: bounds_check_5_db.f90:16: internal compiler error: in simplify_subreg, at simplify-rtx.c:4683 gfortran.dg/where_operator_assign_2.f90 ICE with -m64 and the output aborts with -m32, as forall_4.f90: where_operator_assign_2_db.f90:86: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:707 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-07-29 12:44 --- (In reply to comment #14) Program exited with code 04. (gdb) backtrace No stack. You need to backtrace f951 (which is the compiler proper) instead of gfortran (which is only the driver). Use gfortran -v instead of gfortran in your normal compile command, and it will tell you what options f951 is invoked with (there usually are a lot of those). Then, run this f951 command-line under gdb, and you will have backtrace. If the ICE is not due to a segfault, but rather to a failed GCC assertion in the source, you might want to set a breakpoint on fancy_abort and get a backtrace when this function is called. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #18 from dominiq at lps dot ens dot fr 2007-07-29 12:59 --- You need to backtrace f951 Yes indeed: I did gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 I have also noticed that I don't have any entry for today in~/Library/Logs/CrashReporter/, while I have some from running the testsuite (in OSX the backtraces are usually recorded in this subdirectory). Something wierd here. The situation does depend on the version of gfortran I am using (native build or through Fink). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32881] PURE attribute escapes from contained procedure
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 13:01 --- This is accepted: $ cat pr32881.f90 program foo integer :: i = 42 print *, bar() contains pure integer function bar () bar = i end function end program -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #20 from dominiq at lps dot ens dot fr 2007-07-29 13:26 --- And did you set a breakpoint on fancy_abort? If it has to be done explicitely, the answer is no. Doing it I get: (gdb) break fancy_abort Breakpoint 1 at 0xbf4ec: file ../../gcc-4.3-20070727/gcc/diagnostic.c, line 655. (gdb) run -fdefault-integer-8 -m64 forall_4_db.f90 Starting program: /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 -fdefault-integer-8 -m64 forall_4_db.f90 Reading symbols for shared libraries ..++++. done foot MAIN__ w t Breakpoint 1, fancy_abort (file=0x6e168c ../../gcc-4.3-20070727/gcc/emit-rtl.c, line=706, function=0x71682c gen_rtx_SUBREG) at ../../gcc-4.3-20070727/gcc/diagnostic.c:655 655 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) backtrace #0 fancy_abort (file=0x6e168c ../../gcc-4.3-20070727/gcc/emit-rtl.c, line=706, function=0x71682c gen_rtx_SUBREG) at ../../gcc-4.3-20070727/gcc/diagnostic.c:655 #1 0x002035c8 in gen_rtx_SUBREG (mode=SImode, reg=0x436c73d0, offset=0) at ../../gcc-4.3-20070727/gcc/emit-rtl.c:706 #2 0x00289b58 in expand_binop (mode=QImode, binoptab=0x4362c800, op0=0x436c73d0, op1=0x4360dbc0, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN) at ../../gcc-4.3-20070727/gcc/optabs.c:1531 #3 0x0021d824 in expand_expr_real_1 (exp=0x436b66a0, target=0x0, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:8803 #4 0x0022c2ec in expand_expr_real (exp=0x436b66a0, target=0x0, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6902 #5 0x00220b38 in expand_expr_real_1 (exp=0x436d0280, target=0x436c73b0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:7960 #6 0x0022c2ec in expand_expr_real (exp=0x436d0280, target=0x436c73b0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6902 #7 0x00232cec in store_expr (exp=0x436d0280, target=0x436d2100, call_param_p=0, nontemporal=208 'Ð') at ../../gcc-4.3-20070727/gcc/expr.c:4456 #8 0x00234ca0 in expand_assignment (to=0x436b1000, from=0x436b66a0, nontemporal=0 '\0') at ../../gcc-4.3-20070727/gcc/expr.c:4308 #9 0x0021afc8 in expand_expr_real_1 (exp=0x436b0200, target=0x436b1000, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:8921 #10 0x0022c450 in expand_expr_real (exp=0x436b0200, target=0x4360dbb0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc-4.3-20070727/gcc/expr.c:6896 #11 0x004b1488 in expand_expr_stmt (exp=0x436b0200) at ../../gcc-4.3-20070727/gcc/expr.h:503 #12 0x004e57c8 in expand_gimple_basic_block (bb=0x436bcdc0) at ../../gcc-4.3-20070727/gcc/cfgexpand.c:1614 #13 0x004e69dc in tree_expand_cfg () at ../../gcc-4.3-20070727/gcc/cfgexpand.c:1921 #14 0x00291b90 in execute_one_pass (pass=0x80cd00) at ../../gcc-4.3-20070727/gcc/passes.c:1124 #15 0x00291db0 in execute_pass_list (pass=0x80cd00) at ../../gcc-4.3-20070727/gcc/passes.c:1177 #16 0x002ee27c in tree_rest_of_compilation (fndecl=0x43695880) at ../../gcc-4.3-20070727/gcc/tree-optimize.c:405 #17 0x001a02c4 in cgraph_expand_function (node=0x4360bd00) at ../../gcc-4.3-20070727/gcc/cgraphunit.c:1072 #18 0x001a1900 in cgraph_assemble_pending_functions () at ../../gcc-4.3-20070727/gcc/cgraphunit.c:435 #19 0x001a1ddc in cgraph_finalize_function (decl=0x43695880, nested=0 '\0') at ../../gcc-4.3-20070727/gcc/cgraphunit.c:552 #20 0x00094998 in gfc_generate_function_code (ns=0x436aaba0) at ../../gcc-4.3-20070727/gcc/fortran/trans-decl.c:3407 #21 0x00050a8c in gfc_parse_file () at ../../gcc-4.3-20070727/gcc/fortran/parse.c:3287 #22 0x000774a4 in gfc_be_parse_file (set_yydebug=7214732) at ../../gcc-4.3-20070727/gcc/fortran/f95-lang.c:301 #23 0x0011cefc in toplev_main (argc=8365508, argv=0x431070b0) at ../../gcc-4.3-20070727/gcc/toplev.c:1043 #24 0x2330 in _start () #25 0x2034 in start () The old dog has learnt a new trick!-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug libfortran/32770] -fdefault-integer-8 and the library
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-07-29 13:11 --- (In reply to comment #18) gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951 And did you set a breakpoint on fancy_abort? ICE can be due either to GCC catching a segfault signal (in which case, GDB intercepts the signal first and you can ask for a backtrace) or to a failed internal consistency check (in which case, fancy_abort() is called, prints the error message, and GCC ends without crashing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-29 14:18 --- Subject: Bug 32906 Author: dfranke Date: Sun Jul 29 14:17:59 2007 New Revision: 127043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127043 Log: gcc/fortran: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32906 * resolve.c (resolve_fl_parameter): Check for constant shape arrays, adjusted error message. gcc/testsuite: 2007-07-29 Daniel Franke [EMAIL PROTECTED] PR fortran/32906 * gfortran.dg/shape_1.f90: Adjust error message. * gfortran.dg/parameter_array_ref_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_ref_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/shape_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 --- Thanks for the report! Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.1 4.3.0 |4.1.2 4.2.1 Known to work||4.3.0 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32906] Error: Parameter array ... cannot be automatic or assumed shape
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 --- Closing, take II. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32906
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:45 --- Fixed on trunk with correction to be unity rather than zero based. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
--- Comment #21 from tkoenig at gcc dot gnu dot org 2007-07-29 14:57 --- As a side question, this PR has open some kind of Pandora box in which some failures are directly related to this PR, but probably many others are not. Would not it be wise to open a meta bug for -fdefault-integer-8 and different PR for unrelated failures? Definitely. Let's make this one the meta-bug and hang the individual bugs off it. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |meta-bug Summary|-fdefault-integer-8 and the |[Meta-bug] -fdefault- |library |integer-8 issues http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 --- Subject: Bug 31211 Author: pault Date: Sun Jul 29 14:44:03 2007 New Revision: 127044 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044 Log: 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * trans-expr.c (gfc_conv_expr_reference): Add block for case of scalar pointer functions so that NULL result is correctly handled. PR fortran/32682 *trans-array.c (gfc_trans_array_constructor): On detecting a multi-dimensional parameter array, set the loop limits. 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * gfortran.dg/actual_pointer_function_1.f90: New test. PR fortran/32682 * gfortran.dg/scalarize_parameter_array_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 --- Subject: Bug 32682 Author: pault Date: Sun Jul 29 14:44:03 2007 New Revision: 127044 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044 Log: 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * trans-expr.c (gfc_conv_expr_reference): Add block for case of scalar pointer functions so that NULL result is correctly handled. PR fortran/32682 *trans-array.c (gfc_trans_array_constructor): On detecting a multi-dimensional parameter array, set the loop limits. 2007-07-29 Paul Thomas [EMAIL PROTECTED] PR fortran/31211 * gfortran.dg/actual_pointer_function_1.f90: New test. PR fortran/32682 * gfortran.dg/scalarize_parameter_array_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 trunk/gcc/testsuite/gfortran.dg/scalarize_parameter_array_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/31211] wrong code generated for pointer returning function as actual argument
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:47 --- Fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
[Bug libstdc++/32908] Miss lexicographical_compare random access override
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-29 15:14 --- I would be curious to hear from Zdenek: is there something that could be done in the loop optimizer dealing generally with this common patterns? Not at the moment. It would be possible to implement this optimization, but most likely it would not be very useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libstdc++/32908] Miss lexicographical_compare random access override
--- Comment #3 from pcarlini at suse dot de 2007-07-29 15:21 --- Ok, Zdenek, thanks a lot anyway... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #8 from jb at gcc dot gnu dot org 2007-07-29 15:58 --- I had a look at your patch, and one thing which looks worrying is the use of sprintf all over the place. That's just a recipe for buffer overflows, especially when combined with %s formatting. I think Tobi's suggestion to use libiberty dyn-string is good. (In reply to comment #6) There are also a few other issues with the incomplete patch. vsnprintf can be replaced by __builtin_vsnprintf on systems where it isn't available. Doesn't the compiler automatically take care of using builtin_vsnprintf? (In reply to comment #7) I think I understand what's wrong with my patch now: The stream initialized with init_error_stream was never flushed. I think I'll go with a naked write() call, which is a) simpler b) more robust. This will mess up the indices in unix_stream, no? I suppose you could get around that by flushing before writing, but that's the cardinal sin writing an I/O library: Never, ever, ever flush to fix a bug. And yes, we have committed this sin in multiple places in libgfortran. :( More generally, see PR25561 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug target/32871] Bad optimasation - Gcc is pushing to many registers
--- Comment #1 from info at umfragen-service dot de 2007-07-29 16:12
---
Konsole:
=
[EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make
begin
* Individual makefile for AvrLiveCD
* Avr-Gcc version:
avr-gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* ---
avr-size -d main.elf -t
avr-size: 'main.elf': No such file
0 0 0 0 0 (TOTALS)
Compiling: main.c
avr-gcc -c -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L
/usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst
-I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o
main.o
main.c:32:2: warning: no newline at end of file
Linking: main.elf
avr-gcc -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L
/usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.o
-I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.elf.d main.o
--output main.elf -Wl,-Map=main.map,--cref
Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags .eeprom=alloc,load \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
avr-objcopy: there are no sections to be copied!
avr-objcopy: --change-section-lma .eeprom=0x never used
make: [main.eep] Error 1 (ignored)
Creating Extended Listing: main.lss
avr-objdump -h -S main.elf main.lss
Creating Symbol Table: main.sym
avr-nm -n main.elf main.sym
avr-size -d main.elf -t
textdata bss dec hex filename
228 0 0 228 e4 main.elf
228 0 0 228 e4 (TOTALS)
end
[EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make main.i
avr-gcc -E -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L
/usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst
-I/usr/local/bin/avr/include/ -std=gnu99 main.c -o main.i
main.c:32:2: warning: no newline at end of file
[EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make main.s
avr-gcc -S -mmcu=attiny26 -I. -g -DF_CPU=100UL -I -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -L
/usr/local/bin/lib/gcc/avr/4.1.1 -Wa,-adhlns=main.lst
-I/usr/local/bin/avr/include/ -std=gnu99 -MD -MP -MF .dep/main.s.d main.c -o
main.s
main.c:32:2: warning: no newline at end of file
[EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht#
===
main.c
===
//General Avrincludes
#include avr/io.h
long foo(long a, long b, long c, uint8_t d){
if(d){
return a+b;
}else{
return a-c;
}
}
long foo_rec(long a){
if(a==4){
return foo_rec(a-1)+2;
}
return 1;
}
long foo_rec2(long a, long b){
if(!b){
return foo_rec2(a+2,b+4);
}else{
return a+b+4;
}
}
int main(void){
return 0;
}
The preprocessed file:
# 1 main.c
# 1 /mnt/sda1_removable/avr/gcc_schlecht//
# 1 built-in
# 1 command line
# 1 main.c
# 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/io.h 1 3
# 87 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/io.h 3
# 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/sfr_defs.h 1 3
# 126 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/avr/sfr_defs.h 3
# 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/inttypes.h 1 3
# 37 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/inttypes.h 3
# 1 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 1 3
# 121 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));
typedef int int64_t __attribute__((__mode__(__DI__)));
typedef unsigned int uint64_t __attribute__((__mode__(__DI__)));
# 142 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3
typedef int16_t intptr_t;
typedef uint16_t uintptr_t;
# 159 /usr/local/lib/gcc/avr/4.1.2/../../../../avr/include/stdint.h 3
typedef int8_t int_least8_t;
typedef uint8_t uint_least8_t;
typedef int16_t
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-07-29 16:33 --- Created an attachment (id=13999) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13999action=view) Patch (current status) This patch is currently bootstrapping on my machine. Let's see how it works. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #13995|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/32931] New: FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64
I think the following is different enough from PR32770 to justify a new PR. As reported, gfortran.dg/forall_4.f90 and gfortran.dg/where_operator_assign_2.f90 give an ICE when compiled on darwin8 with both -fdefault-integer-8 and -m64 (see PR32770#20) fo a backtrace. The following reduced codes yield the same ICE: integer, parameter :: n = 4 integer :: i, a(n) logical :: s(n) s = .True. a = 0 forall (i=1:n, .not. s(i)) a(i) = i if (any (a .ne. (/1,0,0,4/))) call abort () end and module global type :: a integer :: b integer :: c end type a interface assignment(=) module procedure a_to_a end interface interface operator(.ne.) module procedure a_ne_a end interface type(a) :: x(4), y(4), z(4), u(4, 4) logical :: l1(4), t = .true., f= .false. contains !** elemental subroutine a_to_a (m, n) type(a), intent(in) :: n type(a), intent(out) :: m m%b = n%b + 1 m%c = n%c end subroutine a_to_a !** elemental logical function a_ne_a (m, n) type(a), intent(in) :: n type(a), intent(in) :: m a_ne_a = (m%b .ne. n%b) .or. (m%c .ne. n%c) end function a_ne_a !** elemental function foo (m) type(a) :: foo type(a), intent(in) :: m foo%b = 0 foo%c = m%c end function foo end module global !** program test use global x = (/a (0, 1),a (0, 2),a (0, 3),a (0, 4)/) y = x z = x l1 = (/t, f, f, t/) call test_where_3 if (any (y .ne. (/a (1, 0),a (1, 2),a (1, 3),a (1, 0)/))) call abort () ! y = x ! call test_where_forall_1 ! if (any (u(4, :) .ne. (/a (1, 4),a (2, 2),a (2, 3),a (1, 4)/))) call abort () contains !** subroutine test_where_3! Test a simple WHERE with a function assignment where (.not. l1) y = foo (x) end subroutine test_where_3 !** ! subroutine test_where_forall_1 ! Test a WHERE in a FORALL block !forall (i = 1:4) ! where (.not. l1) !u(i, :) = x ! elsewhere !u(i, :) = a(0, i) ! endwhere !end forall ! end subroutine test_where_forall_1 !** end program test The commented FORALL also gives the same ICE. However the simplified version of the last code: program test integer :: x(4), y(4), z(4), u(4, 4) logical :: l1(4), t = .true., f= .false. x = (/ 1, 2, 3, 4/) l1 = (/t, f, f, t/) y = 0 where (.not. l1) y = x if (any (y .ne. (/0, 2, 3, 0/))) call abort () end program test compiles and pass. Note also that the problem is also present in gcc 4.2.1. -- Summary: FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug web/32927] Online installation instructions only for mainline
--- Comment #2 from ammonton at cc dot helsinki dot fi 2007-07-29 17:53 --- The INSTALL directory only has a README saying the instructions are generated from gcc/doc/install.texi and the install.texi2html script in that directory complains about a missing file gcc-vers.texi which I gather is generated when building the compiler. If you need instructions on how to install the installation instructions something is wrong, IMO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
[Bug testsuite/32932] New: ssp-2.c fails when previous gcc-4.3 installation is visible
/usr/local/gcc43/lib/gcc/i686-pc-cygwin/4.3.0/../../../libssp.a(ssp.o):ssp.c:(.t ext+0x190): multiple definition of `___stack_chk_fail'^M /cygdrive/c/Temp/ccrBTHWE.o:ssp-2.c:(.text+0x0): first defined here^M collect2: ld returned 1 exit status^M function declaration in testsuite conflicts with function present in libssp.a of previous installation of gcc 4.3 -- Summary: ssp-2.c fails when previous gcc-4.3 installation is visible Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #27 from tprince at computer dot org 2007-07-29 18:00 --- same failure for gcc-4.3 mainline on i686-pc-cygwin -- tprince at computer dot org changed: What|Removed |Added CC||tprince at computer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #10 from patchapp at dberlin dot org 2007-07-29 18:55 --- Subject: Bug number PR 32858 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-07/msg02070.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/32931] FORALL and WHERE give an ICE with -fdefault-integer-8 and -m64
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-29 19:35 --- Note that the ICEs with -m64 diasppear with -O3, but then both tests fail to execute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01 --- Subject: Bug 32858 Author: tkoenig Date: Sun Jul 29 20:01:45 2007 New Revision: 127049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049 Log: 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * configure.ac: Added checks for presence of stdio.h and stdarg.h. Test presence of vsnprintf(). * configure: Regenerated. * config.h.in: Regenerated. * libgfortran.h: Include stdio.h. Add printf attribute to prototype of runtime_error. Remove prototype for st_sprintf. Add prototype for st_vprintf. * runtime/main.c (store_exec_path): Replace st_sprintf by sprintf. * runtime/error.c (st_sprintf): Remove. (runtime_error): Rewrite as a variadic function. Call st_vprintf(). * intrinsics/pack_generic.c: Output extents of LHS and RHS for bounds error. * io/open.c (new_unit): Replace st_sprintf by sprintf. * io/list_read.c (convert_integer): Likewise. (parse_repeat): Likewise. (read_logical): Likewise. (read_character): Likewise. (parse_real): Likewise. (read_real): Likewise. (check_type): Likewise. (nml_parse_qualifyer): Likewise. (nml_read_obj): Likewise. (nml_get_ojb_data): Likewise. * io/unix.c (init_error_stream): Remove. (tempfile): Replace st_sprintf by sprintf. (st_vprintf): New function. (st_printf): Rewrite to call st_vprintf. * io/transfer.c (require_type): Replace st_sprintf by sprintf. * io/format.c (format_error): Likewise. * io/write.c (nml_write_obj): Likewise. 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * gfortran.dg/pack_bounds_1.f90: Adjust to new error message. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pack_bounds_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/io/format.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01 --- Subject: Bug 30814 Author: tkoenig Date: Sun Jul 29 20:01:45 2007 New Revision: 127049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049 Log: 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * configure.ac: Added checks for presence of stdio.h and stdarg.h. Test presence of vsnprintf(). * configure: Regenerated. * config.h.in: Regenerated. * libgfortran.h: Include stdio.h. Add printf attribute to prototype of runtime_error. Remove prototype for st_sprintf. Add prototype for st_vprintf. * runtime/main.c (store_exec_path): Replace st_sprintf by sprintf. * runtime/error.c (st_sprintf): Remove. (runtime_error): Rewrite as a variadic function. Call st_vprintf(). * intrinsics/pack_generic.c: Output extents of LHS and RHS for bounds error. * io/open.c (new_unit): Replace st_sprintf by sprintf. * io/list_read.c (convert_integer): Likewise. (parse_repeat): Likewise. (read_logical): Likewise. (read_character): Likewise. (parse_real): Likewise. (read_real): Likewise. (check_type): Likewise. (nml_parse_qualifyer): Likewise. (nml_read_obj): Likewise. (nml_get_ojb_data): Likewise. * io/unix.c (init_error_stream): Remove. (tempfile): Replace st_sprintf by sprintf. (st_vprintf): New function. (st_printf): Rewrite to call st_vprintf. * io/transfer.c (require_type): Replace st_sprintf by sprintf. * io/format.c (format_error): Likewise. * io/write.c (nml_write_obj): Likewise. 2007-07-29 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32858 PR libfortran/30814 * gfortran.dg/pack_bounds_1.f90: Adjust to new error message. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pack_bounds_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/io/format.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug testsuite/32932] ssp-2.c fails when previous gcc-4.3 installation is visible
--- Comment #1 from tprince at computer dot org 2007-07-29 20:15 --- This test is reported failing also by anonymous testers of powerpc-apple-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug middle-end/23845] missed strength reduction costs performance
--- Comment #5 from tprince at computer dot org 2007-07-29 20:57 --- No longer relevant, due to changes in gfortran. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug testsuite/31340] testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
--- Comment #2 from tprince at computer dot org 2007-07-29 20:54 --- The suggested function name change is in mainline, and this resolves the bug. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #8 from tprince at computer dot org 2007-07-29 21:02 --- The patch discussed here was incorporated in mainline, and the failure was last reported 20070420. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug libgcj/30071] make install fails for libjava
--- Comment #6 from andreast at gcc dot gnu dot org 2007-07-29 21:24 --- install-binPROGRAMS: install-toolexeclibLTLIBRARIES 'overwrites' the install-binPROGRAMS generated by automake. So this is a no go. I helped myself with this one: Index: Makefile.am === --- Makefile.am (revision 126962) +++ Makefile.am (working copy) @@ -440,7 +440,7 @@ $(extra_headers) $(srcdir)/java/lang/Object.h $(srcdir)/java/lang/Class.h: @: -install-exec-hook: install-toolexeclibLTLIBRARIES install-libexecsubPROGRAMS +install-exec-hook: install-binPROGRAMS install-toolexeclibLTLIBRARIES install-libexecsubPROGRAMS ## Support for libgcj_bc: dummy shared library used only at link-time. if USE_LIBGCJ_BC ## Install libgcj_bc dummy lib in the target directory. We also need to delete This one is similar to the one Rainer posted and it might not work if one is doing a parallel install. I'll do a test on my farm and see how it behaves on different architectures. Tom mentioned on IRC that it would be a 'go' for the time being. But one has to file a bug on automake. (1.9.6 used here). Will do so. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-29 20:00:01 |2007-07-29 21:24:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30071
[Bug tree-optimization/32919] [4.3 Regression] SSA corruption because of abnormal edges and PRE
--- Comment #3 from drow at gcc dot gnu dot org 2007-07-29 21:34 --- Damn, I couldn't find this bug when I searched for it Saturday morning, so I spent all day reducing the testcase... -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32919
[Bug fortran/31609] module that calls a contained function with an ENTRY point
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-07-29 23:23 --- The patch applied in Comment #11 fixes the original test case. The modified test case in Comment #8 is still broken. pr31609-2.f90: In function master.0.j: pr31609-2.f90:10: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:452 I am going to have to leave this to others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31609
[Bug fortran/32933] New: ICE in simplify_subreg with -fdefault-integer-8
Simplification of the ICE with nan_1.f90: $ !cat cat nan_6.f90 program test real :: a if (min(a, 3.0, 2.0) /= 2.0) call abort end program test $ gfortran -fdefault-integer-8 nan_6.f90 nan_6.f90: In function 'MAIN__': nan_6.f90:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This goes away if -ffast-math is specified, so it looks as if the call to __builtin_isnan is causing the trouble. -- Summary: ICE in simplify_subreg with -fdefault-integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 32770 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug middle-end/21137] Convert (a 2) 1 != 0 into a 4 != 0
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug c++/32934] New: No warning when creating a non const derived funtion from a const virtual funciton
Maybe this isn't a bug, but I can't see why this shouldn't at least be a
warning since it changes the output of the program...
==C++ Source with B.print not const
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual ~A(){};
};
class B : public A {
public:
virtual char * print() { return B\n;}
virtual ~B(){};
};
int main ()
{
B b;
A a = b;
std::cout a.print() b.print();
}
[EMAIL PROTECTED]:~/working$ g++ -Wall -o gcc_bug gcc_bug.cpp
[EMAIL PROTECTED]:~/working$ ./gcc_bug
A
B
=C++ Source with B.print const=
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual ~A(){};
};
class B : public A {
public:
virtual char * print() const { return B\n;}
virtual ~B(){};
};
int main ()
{
B b;
A a = b;
std::cout a.print() b.print();
}
[EMAIL PROTECTED]:~/working$ g++ -Wall -o gcc_bug gcc_bug.cpp
[EMAIL PROTECTED]:~/working$ ./gcc_bug
B
B
What am I missing?
Andrew
--
Summary: No warning when creating a non const derived funtion
from a const virtual funciton
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: CyrusOmega at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32934
[Bug c++/32934] No warning when creating a non const derived funtion from a const virtual funciton
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-30 02:19 ---
Well it is valid as B::print hides A::print.
Try doing:
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual ~A(){};
};
class B : public A {
public:
virtual char * print() { return B\n;}
using A::print;
virtual ~B(){};
};
int main ()
{
B b;
A a = b;
const B b1 = b;
std::cout a.print() b1.print();
}
Which shows that b1.print will call A::print. If you don't include using
A::print, then A::print wil be hidden in B.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32934
