[Bug fortran/31163] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #3 from patchapp at dberlin dot org 2007-03-14 06:35 --- Subject: Bug number PR31163 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-03/msg00898.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-14 06:08 --- I can't get my last testcase in comment #12 working. Roger this was caused by your folding of VIEW_CONVERT_EXPR patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug middle-end/19774] VLA's vs SjLj EH unwind
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-14 06:06 --- *** Bug 30196 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Tringi at Mx-3 dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19774
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-14 06:06 --- *** This bug has been marked as a duplicate of 19774 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-03-14 05:57 --- This is a duplicate of PR 19774 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #11 from spark at gcc dot gnu dot org 2007-03-14 05:48 --- Subject: Bug 30590 Author: spark Date: Wed Mar 14 05:48:35 2007 New Revision: 122909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122909 Log: 2007-03-13 Seongbae Park <[EMAIL PROTECTED]> PR tree-optimization/30590 * tree-nrv.c (tree_nrv): Check for the partial update of the return value. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #8 from brooks at gcc dot gnu dot org 2007-03-14 04:47 --- Those last two commits should have gone to PR 30933. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30933] intrinsic: EXIT
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-14 04:47 --- The "above commit" is obviously missing; I typoed the PR number when making it. Here's the info: Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-14 04:45 --- The above commit fixes the documentation to document that only default integer arguments are allowed. I left the argument name as "STATUS", because "COUNT" seems absurd and in this case I think it's clear that we want to fix the implementation. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #5 from brooks at gcc dot gnu dot org 2007-03-14 04:43 --- The above commits fix the erroneous argument name in the documentation; it is now documented to be "NAME". In addition, the "STATUS" argument is now documented to only allow default integers (which can be int_4 or int_8 depending on the -fdefault-integer-kind argument). If the decision is made to call this variable "PATH" instead, the documentation will now need to be changed to match. The argument name for the function version is still "A"; this needs to be fixed. I'm removing the "documentation" keyword to reflect that the documentation is corrected, but leaving this open because of the other parts that are not yet fixed. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Keywords|documentation | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30953] intrinsic: CTIME
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-14 04:40 --- Fixed by the above commits on 4.2 and trunk. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30953] intrinsic: CTIME
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30953 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #4 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30953] intrinsic: CTIME
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30953 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-14 04:19 --- Furthermore, the function form of CHDIR erroneously has "A" as the argument name. (Actually, all three of the names involved for this artgument are erroneous compared to the G77 documentation, which gives the variable name as "DIR"!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #10 from aoliva at gcc dot gnu dot org 2007-03-14 04:09 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #17 from patchapp at dberlin dot org 2007-03-14 03:45 --- Subject: Bug number PR31052 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-03/msg00892.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug tree-optimization/31169] New: Bootstrap comparison error at revision 122821
make[3]: Leaving directory `/test/gnu/gcc/objdir' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./build/genautomata.o differs ./pointer-set.o differs ./cfgexpand.o differs ./cfglayout.o differs ./builtins.o differs ./cfgloopanal.o differs ./cfgloopmanip.o differs ./cse.o differs ./cselib.o differs ./combine.o differs ./df-core.o differs ./df-scan.o differs ./gcse.o differs ./gimplify.o differs ./global.o differs ./graph.o differs ./jump.o differs ./lambda-mat.o differs ./langhooks.o differs ./lambda-code.o differs ./loop-invariant.o differs ./lower-subreg.o differs ./omega.o differs ./postreload.o differs ./real.o differs ./recog.o differs ./regmove.o differs ./regclass.o differs ./regrename.o differs ./reload.o differs ./reload1.o differs ./rtlanal.o differs ./see.o differs ./sched-rgn.o differs ./simplify-rtx.o differs ./stmt.o differs ./struct-equiv.o differs ./tree-complex.o differs ./tree-cfg.o differs ./tree-data-ref.o differs ./tree-eh.o differs ./tree-pretty-print.o differs ./tree-ssa-coalesce.o differs ./tree-ssa-dom.o differs ./tree-ssa-live.o differs ./tree-ssa-loop-im.o differs ./tree-ssa-loop-niter.o differs ./tree-ssa-loop-ivopts.o differs ./tree-ssa-phiopt.o differs ./tree-ssa-pre.o differs ./tree-ssa.o differs ./tree-vect-analyze.o differs ./tree-vectorizer.o differs ./tree-vect-transform.o differs ./cgraphunit.o differs ./gccspec.o differs ./gcc.o differs ./c-decl.o differs ./final.o differs ./modulo-sched.o differs ./passes.o differs ./ipa-inline.o differs ./gcov.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/test/gnu/gcc/objdir' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/test/gnu/gcc/objdir' -bash-2.05b$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disable-nls --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --enable-threads=posix --with-mpfr=/opt/gnu/gcc/gcc-4.3.0 --with-gmp=/opt/gnu/gcc/gcc-4.3.0 --disable-libmudflap --enable-languages=c Thread model: posix gcc version 4.3.0 20070311 (experimental) -- Summary: Bootstrap comparison error at revision 122821 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32-bit) GCC host triplet: hppa*-*-* (32-bit) GCC target triplet: hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-14 02:46 --- _Now_ this is fixed on 4.2 and trunk. :) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #10 from brooks at gcc dot gnu dot org 2007-03-14 02:45 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:45:14 2007 New Revision: 122903 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122903 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct "REAL" to "REAL(*)". (EXP): Add index entry for CEXP. (INT): Correct argument name to "A". (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #9 from brooks at gcc dot gnu dot org 2007-03-14 02:43 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:43:27 2007 New Revision: 122902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122902 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct "REAL" to "REAL(*)". (EXP): Add index entry for CEXP. (INT): Correct argument name to "A". (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug bootstrap/29741] Fails to build bootstrap under solaris 10, i386
--- Comment #2 from ted dot keller at goodrich dot com 2007-03-14 02:37 --- Check out http://forum.java.sun.com/thread.jspa?threadID=5077618 Describes problem and resolution. You need to install the gcc and gas from the solaris 10 distribution prior to building a new gcc compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29741
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #9 from aoliva at gcc dot gnu dot org 2007-03-14 01:45 --- Subject: Bug 31127 Author: aoliva Date: Wed Mar 14 01:45:39 2007 New Revision: 122900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122900 Log: gcc/ChangeLog: PR middle-end/31127 * cse.c (cse_find_path): Do not bail out if a basic block that we already visited now becomes part of a path that starts at a different basic block. Just disallow this, to make sure we visit each basic block at most once. gcc/testsuite/ChangeLog: PR middle-end/31127 * gcc.dg/pr31127.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr31127.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug testsuite/31168] New: FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/xxx/gnu/gc c/objdir/gcc/testsuite/g++/../../ /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64- 2.C -nostdinc++ -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/include /hppa1.1-hp-hpux10.20 -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/in clude -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/xxx/gnu/gcc/gcc/libstdc++-v3/ include/backward -I/xxx/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length =0 -O2-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs -L/xxx/gnu/g cc/objdir/hppa1.1-hp-hpux10.20/./libiberty -lm -o ./ia64-2.exe(timeout = 600) /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported output is: /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported FAIL: g++.dg/eh/ia64-2.C (test for excess errors) Excess errors: /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported -- Summary: FAIL: g++.dg/eh/ia64-2.C (test for excess errors) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31168
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-03-14 00:42 --- I have a patch which fixes after my patch for PR 30132. The way I fixed it is an all front-end fix: Index: typeck.c === --- typeck.c(revision 122880) +++ typeck.c(working copy) @@ -4060,6 +4060,14 @@ build_address (tree t) if (error_operand_p (t) || !cxx_mark_addressable (t)) return error_mark_node; + if (TREE_CODE (t) == COND_EXPR) +{ + tree ptrtype = build_pointer_type (TREE_TYPE (t)); + return build3 (COND_EXPR, ptrtype, TREE_OPERAND (t, 0), +build_address (TREE_OPERAND (t, 1)), +build_address (TREE_OPERAND (t, 2))); +} + addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t); return addr; Create a new COND_EXPR for when we want to create an address of a COND_EXPR, by this point, we should have errored out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #16 from rakdver at gcc dot gnu dot org 2007-03-14 00:39 --- Subject: Bug 26900 Author: rakdver Date: Wed Mar 14 00:38:34 2007 New Revision: 122896 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122896 Log: PR tree-optimization/30730 PR tree-optimization/26900 * tree-ssa-loop-niter.c: Include gmp.h. (bounds): New type. (mpz_set_double_int, get_type_bounds, mpz_to_double_int, split_to_var_and_offset, determine_value_range, bound_difference_of_offsetted_base, refine_bounds_using_guard, bound_difference, bounds_add, bounds_negate, number_of_iterations_ne_max, dump_affine_iv): New functions. (number_of_iterations_ne, number_of_iterations_lt_to_ne, assert_loop_rolls_lt, assert_loop_rolls_le): Use bounds on the difference of initial and final value of control iv to validate results. (number_of_iterations_cond): Add loop parameter. Determine bounds on the difference of the extremes of the control iv. Add dumps. (expand_simple_operations): Handle phi nodes. (simplify_using_initial_conditions): Do not record used conditions. (number_of_iterations_exit): Pass loop to number_of_iterations_cond. Do not set additional_info. (implies_nonnegative_p, implies_ge_p): Removed. (derive_constant_upper_bound): Do not use parameter `additional'. (record_estimate): Parameter `additional' removed. Parameter `i_bound' added. Do not call derive_constant_upper_bound. (record_nonwrapping_iv): Use derive_constant_upper_bound to bound the number of iterations estimate. (estimate_numbers_of_iterations_loop): Pass the estimate from the number of iterations analysis to record_estimate. * tree.h (multiple_of_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): Removed. (scev_const_prop): Do not check expression_expensive_p. * fold-const.c (multiple_of_p): Exported. * double-int.c (double_int_mask): Exported. * double-int.h (double_int_mask): Declare. * tree-flow.h (struct tree_niter_desc): Removed additional_info field. Added max field. * gcc.dg/tree-ssa/loop-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-14 00:39 --- Subject: Bug 30730 Author: rakdver Date: Wed Mar 14 00:38:34 2007 New Revision: 122896 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122896 Log: PR tree-optimization/30730 PR tree-optimization/26900 * tree-ssa-loop-niter.c: Include gmp.h. (bounds): New type. (mpz_set_double_int, get_type_bounds, mpz_to_double_int, split_to_var_and_offset, determine_value_range, bound_difference_of_offsetted_base, refine_bounds_using_guard, bound_difference, bounds_add, bounds_negate, number_of_iterations_ne_max, dump_affine_iv): New functions. (number_of_iterations_ne, number_of_iterations_lt_to_ne, assert_loop_rolls_lt, assert_loop_rolls_le): Use bounds on the difference of initial and final value of control iv to validate results. (number_of_iterations_cond): Add loop parameter. Determine bounds on the difference of the extremes of the control iv. Add dumps. (expand_simple_operations): Handle phi nodes. (simplify_using_initial_conditions): Do not record used conditions. (number_of_iterations_exit): Pass loop to number_of_iterations_cond. Do not set additional_info. (implies_nonnegative_p, implies_ge_p): Removed. (derive_constant_upper_bound): Do not use parameter `additional'. (record_estimate): Parameter `additional' removed. Parameter `i_bound' added. Do not call derive_constant_upper_bound. (record_nonwrapping_iv): Use derive_constant_upper_bound to bound the number of iterations estimate. (estimate_numbers_of_iterations_loop): Pass the estimate from the number of iterations analysis to record_estimate. * tree.h (multiple_of_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): Removed. (scev_const_prop): Do not check expression_expensive_p. * fold-const.c (multiple_of_p): Exported. * double-int.c (double_int_mask): Exported. * double-int.h (double_int_mask): Declare. * tree-flow.h (struct tree_niter_desc): Removed additional_info field. Added max field. * gcc.dg/tree-ssa/loop-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #4 from danglin at gcc dot gnu dot org 2007-03-14 00:17 --- Fixed by change on 4.1, 4.2 and trunk. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #3 from danglin at gcc dot gnu dot org 2007-03-14 00:06 --- Subject: Bug 31123 Author: danglin Date: Wed Mar 14 00:06:26 2007 New Revision: 122891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122891 Log: PR target/31123 * pa.md (vdepi_ior): Don't allow zero length deposit. Likewise for two unamed patterns. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #2 from jconner at apple dot com 2007-03-13 23:55 --- I have a patch for this that I'm testing right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-13 23:51 --- Subject: Bug 30899 Author: mmitchel Date: Tue Mar 13 23:51:07 2007 New Revision: 122890 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122890 Log: PR bootstrap/30899 * Make-lang.in (doc/g++.1): Use $< to specify the location from which to copy. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug driver/12448] -MT / -MQ don't behave as documented.
--- Comment #11 from tromey at gcc dot gnu dot org 2007-03-13 23:50 --- Subject: Bug 12448 Author: tromey Date: Tue Mar 13 23:50:42 2007 New Revision: 122889 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122889 Log: 2007-03-13 David Taylor <[EMAIL PROTECTED]> PR driver/12448: * gcc.c (cpp_unique_options): If -MT or -MQ is seen, don't pass default -MQ. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-13 23:50 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-03-13 23:49 --- Subject: Bug 30899 Author: mmitchel Date: Tue Mar 13 23:48:49 2007 New Revision: 122888 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122888 Log: PR bootstrap/30899 * Make-lang.in (doc/g++.1): Use $< to specify the location from which to copy. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug inline-asm/28686] ebp from clobber list used as operand
--- Comment #8 from spark at gcc dot gnu dot org 2007-03-13 23:43 --- I believe all issues are fixed at this point, except for the extra error message of "can't find a register". But since it's accompanied with a proper error message, I don't think this is a problem anymore. $gcc -fPIC -fomit-frame-pointer -O2 -S t.c && grep DEBUG t.s #DEBUG %0=(%esp), clobber: %ebp, ... $gcc -DNBEFORE=1 -fPIC -fomit-frame-pointer -O2 -S t.c && grep DEBUG t.s #DEBUG %0=(%esp), clobber: %ebp, ... $gcc-O1 -S t.c $@ && grep DEBUG t.s t.c: In function 'test_function': t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' t.c:15: error: 'asm' operand has impossible constraints $gcc -O1 -fPIC -S t.c $@ && grep DEBUG t.s t.c: In function 'test_function': t.c:20: error: bp cannot be used in asm here t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' t.c:15: error: 'asm' operand has impossible constraints $gcc -fPIC -O0 -S t.c && grep DEBUG t.s t.c: In function 'test_function': t.c:20: error: bp cannot be used in asm here $gcc -fPIC -O0 -S t.c -fomit-frame-pointer && grep DEBUG t.s #DEBUG %0=12(%esp), clobber: %ebp, ... -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-13 23:24 --- Subject: Bug 31123 Author: danglin Date: Tue Mar 13 23:23:54 2007 New Revision: 122887 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122887 Log: PR target/31123 Fix ChangeLog entry. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-13 23:21 --- Subject: Bug 31123 Author: danglin Date: Tue Mar 13 23:21:40 2007 New Revision: 122886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122886 Log: PR target/31123 * pa.md (vdepi_ior): Don't allow zero length deposit. Likewise for two unamed patterns. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug c++/30988] [4.1/4.2/4.3 Regression] Incorrect "no return statement" warning with __attribute__ ((noreturn)) and __FUNCTION__
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-13 22:57 --- This is somewhat complicated. The extra type cast causes different code paths to be taken. In particular, in finish_call_expr() in cp/semantics.c: if (processing_template_decl) { if (type_dependent_expression_p (fn) || any_type_dependent_arguments_p (args)) { result = build_nt_call_list (fn, args); KOENIG_LOOKUP_P (result) = koenig_p; return result; } if (!BASELINK_P (fn) && TREE_CODE (fn) != PSEUDO_DTOR_EXPR && TREE_TYPE (fn) != unknown_type_node) fn = build_non_dependent_expr (fn); args = build_non_dependent_args (orig_args); With the type cast, build_over_call() is called eventually which checks TREE_THIS_VOLATILE() for the callee function decl and mark the current function (i.e. caller A::g) as returns_abnormally. The lack of the type cast triggers any_type_dependent_arguments_p(args) above, leading to build_nt_call_list() which doesn't do this marking of the returns_abnormally. Now, not being familiar with the c++ frontend, I'm not sure where exactly we should do the checking of TREE_THIS_VOLATILE() for the callee decl. The following patch seems to fix the problem (though I can't even tell whether this is the right approach): diff -r 15a559a8fcf0 gcc/cp/semantics.c --- a/gcc/cp/semantics.cMon Mar 12 15:38:22 2007 -0700 +++ b/gcc/cp/semantics.cTue Mar 13 15:48:45 2007 -0700 @@ -1816,6 +1816,10 @@ finish_call_expr (tree fn, tree args, bo || any_type_dependent_arguments_p (args)) { result = build_nt_call_list (fn, args); + + if (fn && TREE_THIS_VOLATILE (fn) && cfun) + current_function_returns_abnormally = 1; + KOENIG_LOOKUP_P (result) = koenig_p; return result; } -- spark at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-13 22:35 --- unsigned is never promoted, it always stays unsigned. So -0x8000 == 0x8000 :). Try adding ULL (or UL) if you want an unsigned long long (unsigned long) constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #3 from schwab at suse dot de 2007-03-13 22:35 --- (In reply to comment #2) > So 0x8000 is unsigned because does not fit on an int type. That's OK. If > negating it gives an unsigned int of the same value, then, how do you explain > that the following code prints "n1 = -2147483648" You print it as a signed integer. > It works because the expression should not be unsigned. The value is converted to signed int by printf. > The unary - operator can (and should) apply again the promotion rules, and > should choose int. Integer promotion is only performed on types smaller than int. > The unary - operator can (and should) apply again the promotion rules, and > should choose int. The operand is unsigned int, so there is no promotion. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #2 from roberto dot gordo at gmail dot com 2007-03-13 22:27 --- I do not agree at all. Please, read. So 0x8000 is unsigned because does not fit on an int type. That's OK. If negating it gives an unsigned int of the same value, then, how do you explain that the following code prints "n1 = -2147483648" int n1; n1 = -0x8000; printf("n1 = %d\n", n1); It works because the expression should not be unsigned. This is a quotation from ISO/IEC 9899:1999 standard: "The result of the unary - operator is the negative of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type." and... "Several operators convert operand values from one type to another automatically [...] If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions." The unary - operator can (and should) apply again the promotion rules, and should choose int. So the expression -0x8000 shall promote to a signed integer type in which it fits, which happens to be an int (on c99 and c90). And as you can see, gcc works correcly here, just as the standard says. But if fails when the lvalue is long long instead of int, as here: long long n1; n1 = -0x8000; In case we have an int expression at the right, it should be converted as long long without problems. In case we have a long long at the right, it should also work without problems (at least for c99). And if we have an unsigned int at the right, as you said, it should have not worked with an int and it is a bug by itself in the way I understand the standard. -- roberto dot gordo at gmail dot com changed: What|Removed |Added CC||roberto dot gordo at gmail ||dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-13 22:16 --- Another testcase but it is not fixed by my patch as I did not fix the other side: int main(void) { double b = 234.0; long long c; double d = b; __builtin_memcpy(&c, &b, sizeof(double)); long long e = c; if (__builtin_memcmp (&e, &d, sizeof(double)) != 0) __builtin_abort (); return 0; } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker GCC target triplet|hppa64-hp-hpux11.00,|FLOAT_WORDS_BIG_ENDIAN |powerpc64-linux-gnu |targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-13 22:00 --- Confirmed. C testcase: typedef int int32_t; int32_t round32hi(const __int128_t arg) { const int SHIFT = 96; const int mshift = 96; const __int128_t M = (~(__int128_t)0)<>1; const __int128_t Mlo = ((__int128_t)(~M))>>1; __int128_t vv = arg & M; if( (arg & (L1)) // hi bit of discard set && ( (arg & Mlo) // and ( any other bits of discard set || (arg & L) ) ) // or lo bit of keep set ) vv += L; return (int32_t)(vv>>SHIFT); } -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 22:00:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-13 21:48 --- pr23237.c on powerpc-linux-gnu at -O3 and above ICEs the same way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i586-suse-linux, i386- | |unknown-freebsd5.4,s390-ibm-| |linux,s390x-ib | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #15 from mark at codesourcery dot com 2007-03-13 21:46 --- Subject: Re: [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890 pinskia at gcc dot gnu dot org wrote: > --- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 > --- > (In reply to comment #13) >> I think this patch causes the regression reported in PR 31165. copy_node is >> incorrect as it will even copy decls, I think copy_node should be replaced >> with >> unshare_expr instead. > > A quick run with that change, fixes 31165. Thanks for that testing. That patch is pre-approved. If you don't want to handle it, let me know, and I will do it. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 --- A quick patch which I am testing right now: Index: cp/call.c === --- cp/call.c (revision 122871) +++ cp/call.c (working copy) @@ -4671,7 +4671,7 @@ VAR_DECL. We can avoid the copy for constants, since they are never modified in place. */ if (!CONSTANT_CLASS_P (arg)) - arg = copy_node (arg); + arg = unshare_expr (arg); arg = convert_for_initialization (0, type, arg, LOOKUP_NORMAL, "default argument", fn, parmnum); arg = convert_for_arg_passing (type, arg); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 --- (In reply to comment #13) > I think this patch causes the regression reported in PR 31165. copy_node is > incorrect as it will even copy decls, I think copy_node should be replaced > with > unshare_expr instead. A quick run with that change, fixes 31165. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-13 21:36 --- I think this only shows up with section anchors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-13 21:35 --- Reduced testcase: class string { char *ptr; int len; int sz; }; class cset { } _cset_init; string an_empty_string; void f(string& = an_empty_string); void h (void ) { f(); } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 21:35:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c/31167] New: ICE wnen using __int128_t on x86_64
The source below is meant to return an int32_t that is the result of "rounding" the upper 32 bits of an __int128_t, where rounding pays attention to the bits that have been discarded and the low bit of what is kept. Since it's an ICE, the details are probably irrelevant. [EMAIL PROTECTED] cat brokengcc.cxx #include int32_t round32hi(const __int128_t &arg){ const int SHIFT = 96; const int mshift = 96; const __int128_t M = (~__int128_t(0))<>1; const __int128_t Mlo = __int128_t(~M)>>1; __int128_t vv = arg & M; if( (arg & (L1)) // hi bit of discard set && ( (arg & Mlo) // and ( any other bits of discard set || (arg & L) ) ) // or lo bit of keep set ) vv += L; return int32_t(vv>>SHIFT); } [EMAIL PROTECTED] gcc -v -c -O brokengcc.cxx Reading specs from /proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/specs Target: x86_64-unknown-linux-gnu Configured with: /state/partition1/tmp/tmpwsa5nr/gcc-4.1.2/configure --enable-languages=c,c++,fortran --prefix=/proj/desres/root/Linux/x86_64/gcc/4.1.2 Thread model: posix gcc version 4.1.2 /proj/desres/root/Linux/x86_64/gcc/4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE brokengcc.cxx -quiet -dumpbase brokengcc.cxx -mtune=k8 -auxbase brokengcc -O -version -o /scratch/tmp/ccer1yVv.s ignoring nonexistent directory "/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2 /proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu /proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward /usr/local/include /proj/desres/root/Linux/x86_64/gcc/4.1.2/include /proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/include /usr/include End of search list. GNU C++ version 4.1.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9975ef1eec7edce53d85d34b86837808 brokengcc.cxx: In function 'int32_t round32hi(const __int128_t&)': brokengcc.cxx:16: error: unrecognizable insn: (insn 92 91 50 3 (parallel [ (set (reg:DI 38 r9 [ vv+8 ]) (plus:DI (plus:DI (ltu:DI (reg:CC 17 flags) (const_int 0 [0x0])) (reg:DI 38 r9 [ vv+8 ])) (const_int 4294967296 [0x1]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) brokengcc.cxx:16: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] -- Summary: ICE wnen using __int128_t on x86_64 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot salmon at deshaw dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
-- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-25 20:11:47 |2007-03-13 21:26:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-13 21:11 --- Reducing, I think this was introduced by the patch which fixed PR 30108. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||30108 Severity|normal |blocker Component|target |c++ GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|powerpc-*-linux-gnu | Summary| Error: symbol |[4.2/4.3 Regression] Error: |`an_empty_string' is already|symbol `an_empty_string' is |defined |already defined Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-13 21:07 --- I think this patch causes the regression reported in PR 31165. copy_node is incorrect as it will even copy decls, I think copy_node should be replaced with unshare_expr instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #1 from schwab at suse dot de 2007-03-13 20:22 --- 0x8000 is of type unsigned int, negating it gives an unsigned int of the same value, converted to long long still gives the same positive value. On the other hand 2147483648 is of type long long (in C99) because it does not fit in long, and gives -2147483648 as long long when negated. C90 does not have long long, so 2147483648 is undefined behaviour, and GCC chooses unsigned long since it fits there. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-03-13 20:12 --- (In reply to comment #10) > Thomas, it's a bit kludgy, but why not add a constant expression = 1, if dim > is > not present? Hi Paul, unless I'm mistaken, this would also change the rank of the function to 0, which FX explained is wrong. Do you have any idea what I cold do to turn this into an array? All the "interesting" gfc_conv_intrinsic_* functions have the "if (se->ss)" statement on top. Cheers, Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-13 20:10 --- That looks reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug target/31165] Error: symbol `an_empty_string' is already defined
--- Comment #1 from raj dot khem at gmail dot com 2007-03-13 19:59 --- Created an attachment (id=13203) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13203&action=view) testcase This is the preprocessed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c/31166] New: Integer hex constant does not follow promoting rules
Forgive me if this is reported/fixed already; after many consecutive hours of debugging I currently do not have the courage to search through the list of bugs. Please, try this code (tested on 32bit GNU/Linux), compiled with: gcc -std=c99 -Wall -Wextra -o wtf wtf.c #include int main(void) { int n1, n2; long long n3, n4; n1 = -0x8000; n2 = -2147483648; n3 = -0x8000; n4 = -2147483648; printf("n1 = %d\n", n1); printf("n2 = %d\n", n2); printf("n3 = %lld\n", n3); printf("n4 = %lld\n", n4); return 0; } It consists of two int variables and two long long variables, all of them set to the same value (-2147483648 == 0x8000). This is what I get: n1 = -2147483648 n2 = -2147483648 n3 = 2147483648 n4 = -2147483648 What happened to n3? It appears that hex constants are not promoted to long long the same way as decimal ones. AFAIK, this behavoir does not match C99 (neither C90). When compiling without -std=c99, gcc gives this warning: warning: this decimal constant is unsigned only in ISO C90 I think that gcc is trying to say that the constant does not fit on an int (nor a long) and it is promoted to unsigned, as it is stated by ISO C90. But yes, it should fit on an int, because -2147483648 >= INT_MIN in this architecture. Anyway, it is even more funny, because the warning is only for n2 and n4 (decimal constants) but not for n1 nor n4 (hex constants). This is the output without -std=c99: n1 = -2147483648 n2 = -2147483648 n3 = 2147483648 n4 = 2147483648 Tested with these versions of gcc: 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) 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 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) -- Summary: Integer hex constant does not follow promoting rules Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roberto dot gordo at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug target/31165] New: Error: symbol `an_empty_string' is already defined
While compiling groff with latest snapshot from GCC 4.2 branch. I am getting this error with the attached preprocessed file with optimization turned on (O2, O1 ,Os are ones I tried). At -O0 it works ok The error from assembler /tmp/ccOeOEGl.s: Assembler messages: /tmp/ccOeOEGl.s:5826: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5830: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5834: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5838: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5842: Error: symbol `an_empty_string' is already defined -- Summary: Error: symbol `an_empty_string' is already defined Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
--- Comment #1 from steven at gcc dot gnu dot org 2007-03-13 18:55 --- I believe this is the proper fix: Index: cfglayout.c === --- cfglayout.c (revision 122858) +++ cfglayout.c (working copy) @@ -697,7 +697,6 @@ fixup_reorder_chain (void) #ifdef ENABLE_CHECKING verify_insn_chain (); #endif - delete_dead_jumptables (); /* Now add jumps and labels as needed to match the blocks new outgoing edges. */ @@ -1193,6 +1192,9 @@ cfg_layout_finalize (void) fixup_fallthru_exit_predecessor (); fixup_reorder_chain (); + rebuild_jump_labels (get_insns ()); + delete_dead_jumptables (); + #ifdef ENABLE_CHECKING verify_insn_chain (); #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|build failure with --enable-|[4.2/4.3 Regression] build |generated-files-in-srcdir |failure with --enable- ||generated-files-in-srcdir Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #9 from spark at gcc dot gnu dot org 2007-03-13 18:29 --- How does this one look ? If it looks reasonable, I'll start the testing with the mainline. Index: tree-nrv.c === --- tree-nrv.c (revision 122871) +++ tree-nrv.c (working copy) @@ -163,6 +163,14 @@ tree_nrv (void) result_type)) return 0; } + else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT) + { + tree addr = get_base_address (GIMPLE_STMT_OPERAND (stmt, 0)); + /* If there's any MODIFY of component of RESULT, + then bail out. */ + if (addr && addr == result) + return 0; + } } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-13 17:54 --- And this duplicate doesn't add any useful information on top of what was entered into the novell bugzilla. Nobody here is going to wade through boost to understand what is going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 17:47:31 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-13 16:52 --- Use get_base_address (GIMPLE_STMT_OPERAND (stmt, 0)) == result. (Verify if get_base_address does not return NULL, if it's the result_decl, otherwise replicate the loop therein). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #2 from dave dot neary at wengo dot com 2007-03-13 16:50 --- Additional bug tracker entries have been created against Ubuntu: https://launchpad.net/ubuntu/+source/gcc-4.1/+bug/75724 and OpenSuse: https://bugzilla.novell.com/show_bug.cgi?id=228524 And against Boost: http://sourceforge.net/tracker/index.php?func=detail&aid=1679990&group_id=7586&atid=107586 Dave. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #1 from dave dot neary at wengo dot com 2007-03-13 16:49 --- Created an attachment (id=13202) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13202&action=view) Test case to show problem with Boost and GCC 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c++/31164] New: Problem with GCC 4.1 and Boost signals
Hi, There is a problem when using slots & trackable from Boost with GCC 4.1 - I don't know whether this is a GCC problem or a Boost problem, but it affects us (OpenWengo) on both Fedora Core and Feisty, since both distribute gcc 4.1. I'm attaching a test case - the expected output is: create A fire SGN A create B fire SGN A B delete A fire SGN B delete B fire SGN exit This doesn't happen :) What actually happens is that you get jibberish after "fire SGN" once you have deleted A, since the correct signal slot isn't selected. I'll attach the test case straight away. -- Summary: Problem with GCC 4.1 and Boost signals Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot neary at wengo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- Comment #6 from law at redhat dot com 2007-03-13 16:33 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE with computed goto and constants On Mon, 2007-03-12 at 23:46 +, spark at gcc dot gnu dot org wrote: > > --- Comment #4 from spark at gcc dot gnu dot org 2007-03-12 23:46 --- > This little patch below seems to get around the problem, > though I'm not really sure this is sufficient or not. FWIW, ADDR_EXPR needs to be handled as well. Otherwise you'll get testsuite regressions. New test cycle running now :-) jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug c/16351] NULL dereference warnings
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-13 16:22 --- *** Bug 30368 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||lidaobing at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
[Bug c/30368] missing warning for dereferencing null pointer
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-13 16:22 --- and as such, this is a duplicate of bug 16351. *** This bug has been marked as a duplicate of 16351 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at redhat dot com | AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-25 05:09:36 |2007-03-13 16:16:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-13 16:15 --- tree-nrv code doesn't see: : .type = 0; because it only looks at GIMPLE_MODIFY with the operand 0 as the return value. In this case, there's GIMPLE_MODIFY of the component of the return value hence not all modification to the return value. The following patch seems to get around the problem: Index: tree-nrv.c === --- tree-nrv.c (revision 122871) +++ tree-nrv.c (working copy) @@ -163,6 +163,12 @@ tree_nrv (void) result_type)) return 0; } + else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT + && TREE_CODE (GIMPLE_STMT_OPERAND (stmt, 0)) == COMPONENT_REF + && TREE_OPERAND (GIMPLE_STMT_OPERAND (stmt, 0), 0) == result) + /* If there's any MODIFY of component of RESULT, + then bail out. */ + return 0; } } I'm not sure this is sufficient - can there be any other gimple statement combination that modifies only part of RESULT ? -- spark at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c/30368] missing warning for dereferencing null pointer
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-13 16:12 --- So the conclusion is that we should emit a warning for the undefinedness. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 16:12:46 date|| Summary|wrong result|missing warning for ||dereferencing null pointer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-13 16:12 --- Created an attachment (id=13201) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13201&action=view) patch which I need to retest and fix the last regression -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
[Bug c/29062] unclear diagnostic for declaration after label
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-13 16:05 --- I think this is confirmed, we can try to do better. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 16:05:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug fortran/31162] missing warning for real do-loops with implicit typed variables
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-13 14:58:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-13 14:48 --- > The ICE you get in PR30969 shows that TARGET_C99_FUNCTIONS is _not_ set: Is there a way to test it once the building directory is gone? In gcc/config/rs6000/darwin.h I read: ... /* Old versions of Mac OS/Darwin don't have C99 functions available. */ #undef TARGET_C99_FUNCTIONS #define TARGET_C99_FUNCTIONS\ (TARGET_64BIT \ || strverscmp (darwin_macosx_version_min, "10.3") >= 0) ... I assumed that TARGET_C99_FUNCTIONS is set for 10.3 and above, but I may have overlooked something else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/31163] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-13 14:33 --- Andrew wrote: -- it is obvious from the tree dump, what is going on: static struct foo_type f_a = {}; f_a.mv.data = 0B; So save is done correctly but allocatables in the derived type is not. Even at the end of the function: { int4 D.965; _gfortran_deallocate (f_a.mv.data, &D.965); f_a.mv.data = 0B; } So it deallocates it. - And I wrote: - It seems to be related to allocatable components as if I change them to pointers (incl. =>NULL initialization and allocated -> associated), it works. Pointer: static struct foo_type f_a = {.mv={.data=0B}}; Allocatable: static struct foo_type f_a = {}; f_a.mv.data = 0B; That is: The 0B initialization happens always. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-03-13 14:33:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug fortran/31163] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #1 from sfilippone at uniroma2 dot it 2007-03-13 14:25 --- Created an attachment (id=13200) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13200&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug fortran/31163] New: SAVEd derived types with ALLOCATABLE components don't work
The output from the attached code looks wrong, as if the derived type components are not SAVEd. -output- [EMAIL PROTECTED] bugtest]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3-20070302/configure --prefix=/usr/local/gcc43 --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-gmp-lib=/home/travel/GCC/BUILDS/gmp/lib/ --with-gmp=/home/travel/GCC/BUILDS/gmp Thread model: posix gcc version 4.3.0 20070302 (experimental) [EMAIL PROTECTED] bugtest]$ ./savebug After first call0 After second call0 - output with Intel fortran - [EMAIL PROTECTED] bugtest]$ ifort -o savebug savebug.f90 [EMAIL PROTECTED] bugtest]$ ./savebug After first call0 After second call 10 -- Summary: SAVEd derived types with ALLOCATABLE components don't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug fortran/31162] New: missing warning for real do-loops with implicit typed variables
real r do r=1.0,2.0 print*,r enddo end gives legacy.f:2.10: do r=1.0,2.0 1 Warning: Obsolete: REAL DO loop iterator at (1) which is ok, however do r=1.0,2.0 print*,r enddo end compiles without warning! the same for implicit real(a-z) do r=1.0,2.0 print*,r enddo end Additionally: It seems this warning is tied to -std=legacy, perhaps it would make more sense to tie it to -Wsurprising as it was the case for g77. -- Summary: missing warning for real do-loops with implicit typed variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-13 13:53 --- With a cross compiler to powerpc-apple-darwin7 I now get for the testcase: gcc> ./cc1 -quiet t.i t.i: In function 'main': t.i:13: warning: incompatible implicit declaration of built-in function 'printf' t.i:12: sorry, unimplemented: no way to expand a call to 'cexpi' no idea if that's better ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-13 13:39 --- Created an attachment (id=13199) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13199&action=view) patch for a better error Can you check if the attached patch gives a more reasonable error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #7 from krebbel at gcc dot gnu dot org 2007-03-13 13:26 --- ICE can be observed on s390 and s390x as well. http://gcc.gnu.org/ml/gcc/2007-03/msg00357.html -- krebbel at gcc dot gnu dot org changed: What|Removed |Added CC||krebbel at gcc dot gnu dot ||org Last reconfirmed|2007-03-11 10:15:23 |2007-03-13 13:26:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-13 13:26 --- Now, 2007-02-05 Roger Sayle <[EMAIL PROTECTED]> * fold-const.c (fold_unary) : Test for availability of BUILT_IN_COS before simplifying REAL_PART(CEXPI)) to COS. : Likewise, check for availability of BUILT_IN_SIN. * builtins.c (fold_builtin_sincos): Check for TARGET_C99_FUNCTIONS before canonicalizing sincos to cexpi. (fold_builtin_cexp): Likewise, for canonicalizing cexp to cexpi. is too conservative in the sense that we can expand __builtin_cexpi if either TARGET_HAS_SINCOS or TARGET_C99_FUNCTIONS. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-13 13:22 --- Because if TARGET_C99_FUNCTIONS is set we can expand __builtin_cexpi by using cexp(). The ICE you get in PR30969 shows that TARGET_C99_FUNCTIONS is _not_ set: /* We can expand via the C99 cexp function. */ gcc_assert (TARGET_C99_FUNCTIONS); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #10 from dominiq at lps dot ens dot fr 2007-03-13 12:56 --- The problem seems to come from a broken/unavailable __builtin_cexpi, see PR31161. My understanding is that __builtin_cexpi and __builtin_sincos are twin objects(?). Now I see in gcc/tree-ssa-math-opts.c: ... static bool gate_cse_sincos (void) { /* Make sure we have either sincos or cexp. */ return (TARGET_HAS_SINCOS || TARGET_C99_FUNCTIONS) && optimize; } struct tree_opt_pass pass_cse_sincos = { "sincos", /* name */ gate_cse_sincos, /* gate */ execute_cse_sincos, /* execute */ NULL, /* sub */ NULL, /* next */ 0,/* static_pass_number */ 0,/* tv_id */ PROP_ssa, /* properties_required */ 0,/* properties_provided */ 0,/* properties_destroyed */ 0,/* todo_flags_start */ TODO_dump_func | TODO_update_ssa | TODO_verify_ssa | TODO_verify_stmts,/* todo_flags_finish */ 0 /* letter */ }; ... And TARGET_C99_FUNCTIONS is set to 1 on Darwin -> gate_cse_sincos returns true even if TARGET_HAS_SINCOS is 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #43 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-13 12:33 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I think I now understand: I thought the problem we were discussing was > how to obtain correctness (which seems to be easy using local checks) > while in fact you were talking about how to optimize away unnecessary > validity checks (as compared to normal checks). Yes, I was talking about both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #23 from martin dot jansa at mk dot cvut dot cz 2007-03-13 11:45 --- (In reply to comment #22) > This is a bug in the gentoo distro ask them to fix how they do multilib. > so results are (with gcc-4.3) #include_next - doesn't work #include - doesn't work #include - doesn't work #include "/usr/include/stdio.h" - works #include "/usr/include/gentoo-multilib/amd64/stdio.h" - works when /usr/include/stdio.h works then it shouldn't be distro multilib bug, should it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-13 10:58 --- Subject: Re: __builtin_cexpi is broken on Darwin > you should not use __builtin_cexpi if neither sincos nor cexp is available. Yes indeed, but an ICE is certainly not the best way to say it! Now I have tested __builtin_cexpi, not because I want to use it, but because it is used by the optimizer with a wrong result I would like to see fixed ASAP. Note that __builtin_cexp is available on Darwin and seems to work: #include #include int main() { __complex__ double x; __real__ x = -1.0; __imag__ x = 0.0; __complex__ double t = __builtin_clog(x); double tmp = 0.5 * (__imag__ t); x = __builtin_cexp(0.5*t); printf("%g %g\n", (__real__ x), (__imag__ x)); printf("%g %g\n", cos(tmp), sin(tmp)); } gives with gcc and with or without optimization: 6.12323e-17 1 6.12323e-17 1 while when compiled with g++ -O1, it gives: 6.12323e-17 1 -1 1.22465e-16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-13 10:30 --- It's a target issue. Darwin is broken that it doesn't set TARGET_C99_FUNCTIONS but still appears to have cexp. Your testcase is also invalid for this reason, you should not use __builtin_cexpi if neither sincos nor cexp is available. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #42 from baldrick at free dot fr 2007-03-13 10:30 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > > It is not possible for a pointer value to be uninitialized. The language > > requires all pointers to be default initialized to null. > > I mean the thing that pointer points to! I think I now understand: I thought the problem we were discussing was how to obtain correctness (which seems to be easy using local checks) while in fact you were talking about how to optimize away unnecessary validity checks (as compared to normal checks). My current plan for that in LLVM is to implement validity checks using a builtin_nop intrinsic. Multiple successive validity checks will be eliminated as redundant because builtin_nop is a pure function. That leaves the question of how to teach the optimizers that an object is valid in the various cases where the front-end for some reason knows this. In such cases I'm thinking that you can issue an assert instruction saying so, eg if type T has range 10..20 and at some point the front-end knows that x (of type T) is valid, it can issue: assert(builtin_nop(x)>=10 && builtin_nop(x)<=20); The dataflow and predicate analysis needed to exploit this can hopefully be left to the optimizers, in particular to IPO (which LLVM is rather good at). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31157] [4.2/4.3 Regression] Bitfield is not promoted
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-13 10:26 --- This has been fixed on the branch by the patch for PR30274. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30274 Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to work||4.1.2 Resolution||FIXED Summary|Bitfield is not promoted|[4.2/4.3 Regression] ||Bitfield is not promoted Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157
[Bug c++/31158] wrong line number in warning: overflow in implicit constant conversion
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
[Bug target/31152] -(x>y) generates wrong code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-13 10:20 --- It works for me on x86_64 and i686 with 4.0.0, 4.1.0 and 4.1.2. So this looks like a target issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152