[Bug target/29560] Poor optimization for character shifts on Atmel AVR
--- Comment #2 from r dot leitgeb at x-pin dot com 2006-10-24 07:31 --- Here's an excerpt of the assembly code obtained with -Os -S with some comments from me: setpin: /* prologue: frame size=0 */ /* prologue end (size=0) */ mov r20,r24 clr r21 cpi r22,lo8(1)<--- The compare is done byte wide brne .L2 in r18,53-0x20 ldi r24,lo8(1)<--- Here we load 1 sixteen bit wide ldi r25,hi8(1) rjmp 2f 1: lsl r24 <--- Here we shift 1 sixteen bit wide rol r25 2: dec r20 brpl 1b or r18,r24<--- r25 is not used. Why would we compute it ? rjmp .L6 .L2: in r18,53-0x20 Cheers Rudi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06 --- Subject: Bug 29321 Author: fxcoudert Date: Tue Oct 24 08:05:55 2006 New Revision: 117996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996 Log: A bunch of backports: PR fortran/29284 PR fortran/29321 PR fortran/29322 * trans-expr.c (gfc_conv_function_call): Check the expression and the formal symbol are present when testing the actual argument. PR fortran/25091 PR fortran/25092 * resolve.c (resolve_entries): It is an error if the entries of an array-valued function do not have the same shape. PR fortran/29284 * gfortran.dg/optional_assumed_charlen_1.f90: New test. PR fortran/29321 PR fortran/29322 * gfortran.dg/missing_optional_dummy_2.f90: New test. PR fortran/25091 PR fortran/25092 * gfortran.dg/entry_array_specs_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06 --- Subject: Bug 29284 Author: fxcoudert Date: Tue Oct 24 08:05:55 2006 New Revision: 117996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996 Log: A bunch of backports: PR fortran/29284 PR fortran/29321 PR fortran/29322 * trans-expr.c (gfc_conv_function_call): Check the expression and the formal symbol are present when testing the actual argument. PR fortran/25091 PR fortran/25092 * resolve.c (resolve_entries): It is an error if the entries of an array-valued function do not have the same shape. PR fortran/29284 * gfortran.dg/optional_assumed_charlen_1.f90: New test. PR fortran/29321 PR fortran/29322 * gfortran.dg/missing_optional_dummy_2.f90: New test. PR fortran/25091 PR fortran/25092 * gfortran.dg/entry_array_specs_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug fortran/29322] [4.1/4.2 Regression] ICE with character optional arg
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06 --- Subject: Bug 29322 Author: fxcoudert Date: Tue Oct 24 08:05:55 2006 New Revision: 117996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996 Log: A bunch of backports: PR fortran/29284 PR fortran/29321 PR fortran/29322 * trans-expr.c (gfc_conv_function_call): Check the expression and the formal symbol are present when testing the actual argument. PR fortran/25091 PR fortran/25092 * resolve.c (resolve_entries): It is an error if the entries of an array-valued function do not have the same shape. PR fortran/29284 * gfortran.dg/optional_assumed_charlen_1.f90: New test. PR fortran/29321 PR fortran/29322 * gfortran.dg/missing_optional_dummy_2.f90: New test. PR fortran/25091 PR fortran/25092 * gfortran.dg/entry_array_specs_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29322
[Bug fortran/25091] Results do not conform at different entries
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06 --- Subject: Bug 25091 Author: fxcoudert Date: Tue Oct 24 08:05:55 2006 New Revision: 117996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996 Log: A bunch of backports: PR fortran/29284 PR fortran/29321 PR fortran/29322 * trans-expr.c (gfc_conv_function_call): Check the expression and the formal symbol are present when testing the actual argument. PR fortran/25091 PR fortran/25092 * resolve.c (resolve_entries): It is an error if the entries of an array-valued function do not have the same shape. PR fortran/29284 * gfortran.dg/optional_assumed_charlen_1.f90: New test. PR fortran/29321 PR fortran/29322 * gfortran.dg/missing_optional_dummy_2.f90: New test. PR fortran/25091 PR fortran/25092 * gfortran.dg/entry_array_specs_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25091
[Bug fortran/25092] Result lengths different at different entries
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-24 08:06 --- Subject: Bug 25092 Author: fxcoudert Date: Tue Oct 24 08:05:55 2006 New Revision: 117996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117996 Log: A bunch of backports: PR fortran/29284 PR fortran/29321 PR fortran/29322 * trans-expr.c (gfc_conv_function_call): Check the expression and the formal symbol are present when testing the actual argument. PR fortran/25091 PR fortran/25092 * resolve.c (resolve_entries): It is an error if the entries of an array-valued function do not have the same shape. PR fortran/29284 * gfortran.dg/optional_assumed_charlen_1.f90: New test. PR fortran/29321 PR fortran/29322 * gfortran.dg/missing_optional_dummy_2.f90: New test. PR fortran/25091 PR fortran/25092 * gfortran.dg/entry_array_specs_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 - copied unchanged from r117413, trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25092
[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-24 08:12 --- Subject: Bug 29567 Author: rguenth Date: Tue Oct 24 08:12:04 2006 New Revision: 117997 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117997 Log: 2006-10-24 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/29567 * tree-vrp.c (register_edge_assert_for_1): Fix wrong logic for TRUTH_NOT_EXPR. Clarify comments. * gfortran.fortran-torture/compile/vrp_1.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/vrp_1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug target/29255] [4.2/4.3 regression] ICE on valid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29255
[Bug middle-end/29301] [4.2/4.3 Regression] ICE in check_cfg, at haifa-sched .c:4657 while compiling openssl
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29301
[Bug target/29206] [4.2/4.3 regression] gcj-dbtool segfaults
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug target/29472] [4.0/4.1/4.2/4.3 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug target/29474] [4.1/4.2/4.3 Regression] reload_cse_simplify_operands, at postreload.c:393 on m68k with -O -fPIC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
[Bug other/29049] possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-10-24 08:19 --- This works for me and many many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-24 08:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #7 from h dot b dot furuseth at usit dot uio dot no 2006-10-24 08:20 --- Subject: Re: Issues with -Wchar-subscripts gdr at integrable-solutions dot net writes: > The absence of warning in C is OK -- literal characters have type int > in C. Yes, but see previous comments. > The warning in C++ is arguably bogus because the value of the > character '%' is known at compile-time, consequently the warning > is unwarranted (unless it really is negative). unwarranted unless it _could_ be negative on some host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #17 from nathan at gcc dot gnu dot org 2006-10-24 08:38 --- Subject: Bug 20647 Author: nathan Date: Tue Oct 24 08:38:26 2006 New Revision: 117999 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117999 Log: cp/ PR c++/20647 * rtti.c (tinfo_base_init): The type info string is always global. testsuite/ PR c++/20647 * g++.dg/abi/rtti3.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/abi/rtti3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/rtti.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #18 from nathan at gcc dot gnu dot org 2006-10-24 08:38 --- fixed on mainline, 4.1 & 4.2 -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-24 09:15 --- Subject: Bug 28796 Author: rguenth Date: Tue Oct 24 09:15:07 2006 New Revision: 118001 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001 Log: 2006-10-24 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28796 * builtins.c (fold_builtin_classify): Use HONOR_INFINITIES and HONOR_NANS instead of MODE_HAS_INFINITIES and MODE_HAS_NANS for deciding optimizations in consistency with fold-const.c (fold_builtin_unordered_cmp): Likewise. * gcc.dg/pr28796-1.c: New testcase. * gcc.dg/pr28796-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr28796-1.c trunk/gcc/testsuite/gcc.dg/pr28796-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-24 09:19 --- This is now nearly fixed. What is remaining is that specifying the -mno-ieee-fp target option does not set flag_finite_math_only, but I am not sure if it should so. This causes [ollmia:/tmp] iano% gcc main3.c -Wall -mno-ieee-fp ; ./a.out __FINITE_MATH_ONLY__ = 0 __builtin_isunordered(nan,nan) = 1 __builtin_isnan(nan) = 1 (nan != nan) = 0 to be still inconsistent. I would rather deprecate -mno-ieee-fp than doing this. Or do both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-10-24 09:23 --- Ah well, this seems to be documented as such: -mieee-fp -mno-ieee-fp Control whether or not the compiler uses IEEE floating point comparisons. These handle correctly the case where the result of a comparison is unordered. so it really only affects FP comparisons. Closing as fixed, we can open another bug if the above is really a problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||wrong-code Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-24 09:48 --- Adjust target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug c++/8781] Pessimization of C++ (functional) code
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-10-24 12:16 --- Still bogus at the tree level as in comment #11, but fixed by RTL optimizers: _Z1xv: .LFB5: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: subl$24, %esp .LCFI2: movl$_Z1fv, -4(%ebp) leal-8(%ebp), %eax movl%eax, -8(%ebp) call_Z1fv leave ret the above is from mainline, with 4.1.1 I get .LCFI2: movl$_Z1fv, -4(%ebp) leal-8(%ebp), %eax movl%eax, -8(%ebp) call*%eax so there's an indirect call left. 3.4.6 is the last I can reproduce the completely bogus asm. So, fixed in 4.2? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
[Bug fortran/29578] New: inquire(...) returns formatted=="YES" for unreadable and unformatted files
Inquire returns for formatted "YES" for the following cases: - not opened file, which is not readable. How should gfortran know? - opened or unopend, finite-size unformatted file. This is clearly wrong. Test program attached -- Summary: inquire(...) returns formatted=="YES" for unreadable and unformatted files Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug fortran/29578] inquire(...) returns formatted=="YES" for unreadable and unformatted files
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-24 12:27 --- Created an attachment (id=12482) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12482&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-24 12:34 --- We now get : # param_2 = V_MAY_DEF ; param.f1 = 0; # param_6 = V_MAY_DEF ; # SFT.0_7 = V_MAY_DEF ; # NONLOCAL.6_8 = V_MAY_DEF ; # NONLOCAL.12_13 = V_MAY_DEF ; # NONLOCAL.18_16 = V_MAY_DEF ; # NONLOCAL.24_19 = V_MAY_DEF ; # NONLOCAL.30_22 = V_MAY_DEF ; # NONLOCAL.36_25 = V_MAY_DEF ; __builtin_memcpy (&local, ¶m, 9); # VUSE ; D.2668_4 = local.f1; if (D.2668_4 != 0) goto ; else goto ; :; # param_9 = V_MAY_DEF ; # SFT.0_10 = V_MAY_DEF ; # NONLOCAL.6_11 = V_MAY_DEF ; # NONLOCAL.12_14 = V_MAY_DEF ; # NONLOCAL.18_17 = V_MAY_DEF ; # NONLOCAL.24_20 = V_MAY_DEF ; # NONLOCAL.30_23 = V_MAY_DEF ; # NONLOCAL.36_26 = V_MAY_DEF ; link_error (); :; return; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-09 04:36:34 |2006-10-24 12:34:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13954
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-24 12:55 --- This PR is only about a non-optimal tree-representation for __builtin_sincos. See also http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01151.html for an alternative and some discussion. (The other patch was rejected, I believe further discussion is necessary here. For reference: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01571.html ) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |03/msg01571.html| Keywords|patch | Last reconfirmed|2005-12-09 04:25:17 |2006-10-24 12:55:11 date|| Summary|sincos expansion is |sincos tree representation |suboptimal |causes extra addressable ||vars http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:07 --- We should at least fold b->bit = () (unsigned char) ((signed char) b->bit | 1); to b->bit = () ((signed char) b->bit | 1); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-24 13:14 --- Tree if-conversion is now converting one jump. Andrew, I guess you are not working on this anymore? ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-09-03 21:50:23 |2006-10-24 13:14:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
[Bug c++/29579] New: gcc uses sil register in inline asm statement in 32bit mode
The below referenced preprocessed code cannot be compiled due to invalid asm statements: ... Making thread-io.o /tmp/cc1rd17V.s: Assembler messages: /tmp/cc1rd17V.s:788: Error: bad register name `%sil' /tmp/cc1rd17V.s:829: Error: bad register name `%sil' make[2]: *** [thread-io.o] Error 1$ http://os.inf.tu-dresden.de/~adam/thread-io.i $ /usr/local/gcc/4.1/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc/4.1 --enable-__cxa_atexit Thread model: posix gcc version 4.1.2 20061022 (prerelease) -- Summary: gcc uses sil register in inline asm statement in 32bit mode Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: adam at os dot inf dot tu-dresden dot de 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=29579
[Bug c++/29579] gcc uses sil register in inline asm statement in 32bit mode
--- Comment #1 from adam at os dot inf dot tu-dresden dot de 2006-10-24 13:23 --- Created an attachment (id=12483) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12483&action=view) preprocessed files which cannot be compiled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29579
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-24 13:28 --- With more registers (x86_64) the stack moves are gone, but: (!) [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> ./xgcc -B. -O2 -o t t.c -mfpmath=387 [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> /usr/bin/time ./t Start? Stop! Result = 0.00, 0.00, 1.00 5.31user 0.00system 0:05.32elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+135minor)pagefaults 0swaps [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> ./xgcc -B. -O2 -o t t.c [EMAIL PROTECTED]:/abuild/rguenther/trunk-g/gcc> /usr/bin/time ./t Start? Stop! Result = 0.00, 0.00, 1.00 9.96user 0.05system 0:10.06elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+135minor)pagefaults 0swaps that is almost twice as fast with 387 math than with SSE math on x86_64! The inner loop is .L7: movaps %xmm3, %xmm6 movaps %xmm1, %xmm5 movaps %xmm0, %xmm4 .L2: movaps %xmm2, %xmm3 mulss %xmm6, %xmm2 movaps %xmm7, %xmm0 addl$1, %eax mulss %xmm4, %xmm3 movaps %xmm7, %xmm1 mulss %xmm5, %xmm0 cmpl$10, %eax mulss %xmm6, %xmm1 movaps %xmm4, %xmm7 subss %xmm0, %xmm3 movaps %xmm8, %xmm0 mulss %xmm4, %xmm0 subss %xmm0, %xmm1 movaps %xmm8, %xmm0 movaps %xmm6, %xmm8 mulss %xmm5, %xmm0 subss %xmm2, %xmm0 movaps %xmm5, %xmm2 jne .L7 vs. .L7: fxch%st(3) fxch%st(2) .L2: fld %st(2) addl$1, %eax cmpl$10, %eax fmul%st(1), %st flds76(%rsp) fmul%st(5), %st fsubrp %st, %st(1) flds76(%rsp) fmul%st(3), %st flds72(%rsp) fmul%st(3), %st fsubrp %st, %st(1) flds72(%rsp) fmul%st(6), %st fxch%st(5) fmul%st(4), %st fsubrp %st, %st(5) fxch%st(2) fstps 76(%rsp) fxch%st(2) fstps 72(%rsp) jne .L7 (testing done on AMD Athlon fam 15 model 35 stepping 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug fortran/29578] inquire(...) returns formatted=="YES" for unreadable and unformatted files
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-24 13:31 --- I'm actually not any more sure what is meant by "formatted" in inquire(). The Fortran 2003 standard says: "The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FORMATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether or not FORMATTED is included in the set of allowed forms for the file." What makes an UNFORMATTED file allowed for FORMATTED access? Currently, the check is (libgfortran/io/unix.c; inquire_formatted): Empty string/file does not exist: "UNKNOWN" Directory: "NO" Regular file, block device, character device, pipe: "YES". Is "YES" what one would expect for a binary file? Ifort writes "NO" if one has open()ed an unformatted file [and simply "UNKNOWN" otherwise]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug middle-end/29478] [4.2/4.3 Regression] optmization generates warning for casts
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-10-24 13:50 --- (In reply to comment #8) > Hmm, This is one of the language hooks which really need to go away > for LTO as I understand it. Also I the real problem comes from the > inliner or the gimplifier (I am betting the gimplifier) removing the > cast as it is useless in our type system. How is LTO supposed to handle argument passing for inlining? As I see it, we have basically two choices: 1.: We pass a actual parameter with a type and a value of that type, to a formal parameter of a possibly different type. This can require conversions, which would have to be either done by frontend hooks (this is the way the intra-module inlining works at the moment), or by some frontend-independent mechanism that the frontends anticipate when they generate the parameter encodings for the call site. 2.: We pass an actual parameter as bit pattern in registers and/or a stack slot. The inliner will have to figure out where its formal parameter is coming in, and will need to re-build abstractions that the optimizers can work with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-24 13:56 --- So, where do we want to go? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #21 from rakdver at gcc dot gnu dot org 2006-10-24 13:58 --- (In reply to comment #20) > So, where do we want to go? > Unless the basic patch is approved (which did not happen so far, despite of several pings), I do not know. I will try to resend the patch, perhaps that will help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug libgomp/29494] [4.2/4.3 Regression] libgomp build fails with missing pthread_mutexattr_settype
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-24 13:59 --- Subject: Bug 29494 Author: ebotcazou Date: Tue Oct 24 13:59:06 2006 New Revision: 118004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118004 Log: PR libgomp/29494 * configure.tgt: Use posix95 configuration for Solaris 2.5.1 and 2.6. * config/posix95: New directory. * config/posix95/omp-lock.h: New file. * config/posix95/lock.c: Likewise. Added: trunk/libgomp/config/posix95/ trunk/libgomp/config/posix95/lock.c trunk/libgomp/config/posix95/omp-lock.h Modified: trunk/libgomp/ChangeLog trunk/libgomp/configure.tgt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug libgomp/29494] [4.2/4.3 Regression] libgomp build fails with missing pthread_mutexattr_settype
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-10-24 13:59 --- Subject: Bug 29494 Author: ebotcazou Date: Tue Oct 24 13:59:39 2006 New Revision: 118005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118005 Log: PR libgomp/29494 * configure.tgt: Use posix95 configuration for Solaris 2.5.1 and 2.6. * config/posix95: New directory. * config/posix95/omp-lock.h: New file. * config/posix95/lock.c: Likewise. Added: branches/gcc-4_2-branch/libgomp/config/posix95/ branches/gcc-4_2-branch/libgomp/config/posix95/lock.c branches/gcc-4_2-branch/libgomp/config/posix95/omp-lock.h Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/configure.tgt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug libgomp/29494] [4.2/4.3 Regression] libgomp build fails with missing pthread_mutexattr_settype
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-10-24 14:01 --- Fixed everywhere. My latest results on SPARC/Solaris 2.6 are: === libgomp tests === Running target unix WARNING: program timed out. FAIL: libgomp.c/appendix-a/a.18.1.c execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O0 execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O1 execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O2 execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O3 -g execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -Os execution test === libgomp Summary === # of expected passes1285 # of unexpected failures9 # of unsupported tests 118 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
[Bug c++/29579] gcc uses sil register in inline asm statement in 32bit mode
--- Comment #2 from adam at os dot inf dot tu-dresden dot de 2006-10-24 14:04 --- The problem happens with 4.0 and 4.1 but not with 4.2 or trunk (all 20061022 versions). -O2 is needed. Does not happen with -O1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29579
[Bug fortran/23232] DATA implied DO variables
--- Comment #6 from happydeer at gmail dot com 2006-10-24 14:05 --- Fortran runtime error: Bad real number in item 1 of list input My READ statement is: READ(2,*)(JM(I,IQ),IQ=0,MQ) JM(I,IQ) got from an input file. JM(I,IQ) defined :DOUBLE PRECISION JM(NSDMAX,0:MQ),JB(0:LMAX,0:MB) I don't know if this is enough? -- happydeer at gmail dot com changed: What|Removed |Added CC||happydeer at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug tree-optimization/23928] Exceptions require an excessive amount of compile-time memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-24 14:10 --- Fixed in 4.2. Numbers are reasonable now: [EMAIL PROTECTED]:/space/rguenther/tramp3d> /usr/bin/time ~/bin/maxmem.sh ./install/bin/g++ -O2 -S -o /dev/null tramp3d-v4.cpp -Dleafify=flatten total: 903456 kB 159.28user 5.17system 2:44.37elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (1major+387189minor)pagefaults 0swaps [EMAIL PROTECTED]:/space/rguenther/tramp3d> /usr/bin/time ~/bin/maxmem.sh ./install/bin/g++ -O2 -S -o /dev/null tramp3d-v4.cpp -Dleafify=flatten -fno-exceptions total: 871928 kB 135.61user 3.35system 2:18.78elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+299059minor)pagefaults 0swaps -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23928
[Bug fortran/29580] New: integer -2147483648 out of range: bug or feature?
In the gfortran version of 20060914 it was still legal to use the integer value -2147483648 for 4 byte (kind=4) integers. In the gfortran version of 20061023 this seems no longer possible, I get the compilation error: Error: Integer too big for its kind at (1) Does this mean the integer numbers have changed from asymmetric to symmetric definition? If so, is there a commandline switch to choose between the two? I do know that the -fno-range-check option suppresses this error (and the sample code below works correct with it), but I really don't understand why this number should be out of range, so I believe this is a bug. This sample code demonstrates the issue: program bla integer :: i i=-2147483648 print *,"i=",i end program bla -- Summary: integer -2147483648 out of range: bug or feature? Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #22 from dberlin at gcc dot gnu dot org 2006-10-24 14:23 --- (In reply to comment #19) > So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the > loop > is not in do-while form, and we won't hoist the loop header copies until the > loads are PREd. As to comment #13, if we are able to "clean" the two > innermost > loops > of a nest that is already a good improvement. Though from all the experiments > it looks like it is advisable to write do-while loops with hoisted loop header > copies manually rather than for loops. > So the PRE fixes i've got should help here, i think. Maybe not. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-24 14:47 --- It is not a bug. "i = - 2147483648" is a unary minus operation on the number 2147483648. This number overflows the range. If you want the most negative number for an integer use "i = - huge(i) - 1". I've already pointed you the to the commit that fixed range checking. There is a very long email in the fortran@ mailing list that explains the problem and why it was fixed. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #2 from kloedej at knmi dot nl 2006-10-24 15:04 --- In my simple view as a physicist the minus sign is an integral part of the number and not an operation on it, but then I didn't have a formal computer science education. As a gfortran programmer you have a choice here I would say. Just note that you can expect a lot of complaints about this behaviour, since all other compilers that I regularly use (ifort, g95, pgf90) accept -2147483648 as a proper 4 byte integer constant without any warnings. Also note that I was not able to find the mail you refer to on the gfortran mailing list. Searching on -2147483648 yields nothing, and there is way to much noise to find it by browsing through the list. best regards, Jos de Kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug middle-end/26899] Fold does not fold (i0 > i1 + 1) || (i1 < i0 - 1)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-24 15:07 --- Actually folding (i0 > i1 + 1) || (i1 < i0 - 1) is not possible, but I have a patch that is able to fold (i0 < i1 + 1) || (i1 > i0 - 1) to i1 >= i0. The original one is not possible due to overflow issues. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-24 15:07:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26899
[Bug tree-optimization/29581] New: Latent bug in 4.1/4.2/4.3 lambda-code.c
SUBROUTINE FOO (K)
INTEGER I, J, K, A(5,5), B
COMMON A
A(1,1) = 1
10 B = 0
DO 30 I = 1, K
DO 20 J = 1, K
B = B + A(I,J)
20 CONTINUE
A(I,I) = A(I,I) * 2
30 CONTINUE
IF (B.GE.3) RETURN
GO TO 10
END SUBROUTINE
PROGRAM BAR
CALL FOO (2)
END
is miscompiled on redhat/gcc-4_1-branch, with -O2 -ftree-loop-linear,
I believe on all arches, tested at least ppc -m32 and x86_64 -m64.
Unfortunately, I couldn't reproduce this on gcc-4_1-branch nor on the
trunk, because the statements coming from earlier passes
are slightly different, though IMHO valid in all 3 cases while what
-ftree-loop-linear creates is clearly invalid. I believe it is a latent
bug in lambda-code.c (see below), although I don't have any testcases
that would prove it on non-vendor branches.
All vars used in foo are int4, the body in *.empty is on
redhat/gcc-4_1-branch:
:
__BLNK__.a[0] = 1;
D.684_14 = *k_13;
goto ();
__label_10:;
:;
if (D.684_14 > 0) goto ; else goto __label_10;
:;
# b_5 = PHI <0(3), b_37(8)>;
# i_1 = PHI <1(3), i_28(8)>;
:;
pretmp.29_7 = i_1 + -6;
# j_9 = PHI <1(4), j_35(6)>;
# b_6 = PHI ;
:;
D.697_29 = j_9 * 5;
D.698_30 = pretmp.29_7;
D.699_31 = pretmp.29_7 + D.697_29;
D.700_32 = __BLNK__.a[D.699_31];
b_33 = D.700_32 + b_6;
j_35 = j_9 + 1;
if (j_9 == D.684_14) goto ; else goto ;
:;
goto ();
# b_37 = PHI ;
:;
D.701_18 = i_1 * 5;
D.702_19 = pretmp.29_7;
D.703_20 = pretmp.29_7 + D.701_18;
D.704_24 = __BLNK__.a[D.703_20];
D.705_25 = D.704_24 * 2;
__BLNK__.a[D.703_20] = D.705_25;
if (i_1 == D.684_14) goto ; else goto ;
:;
i_28 = i_1 + 1;
goto ();
# b_8 = PHI ;
:;
if (b_8 > 2) goto __return_foo; else goto __label_10;
__return_foo:;
return;
On gcc-4_1-branch the difference is just that pretmp.29_7 doesn't
exist, all users of that have i_1 + -6 instead. On the trunk,
pretmp var is only used in the innermost loop (L3..L30) and after
L8 label it instead uses i_1 * 6 + -6. Now, -ftree-loop-linear
on the above determines the L3..L30 loop isn't perfectly
nested in L25..L31 but can_convert_to_perfect_nest says it can
be converted to perfect nest, because the pretmp.9_7 = i_1 + -6;
satisfies:
/* If the IV is simple, it can be duplicated. */
if (!automatically_generated_chrec_p (scev))
{
tree step = evolution_part_in_loop_num (scev, loop->num);
if (step && step != chrec_dont_know
&& TREE_CODE (step) == INTEGER_CST)
continue;
}
-ftree-loop-linear then changes the loops, so that the b computation
is done using 2 nested loops and the *2 multiplication in a separate
loop. Unfortunately, it doesn't compute the start of the loop
correctly, above, the first __BLKN__.a[] that is multiplied by 2 is
pretmp.29_7 + i_1 * 5 = i_1 * 6 - 6 where i_1 starts at 1,
but after the transformation it is perfectiv.32_12 * 5 + perfectiv.32_12:
...
# perfectiv.32_12 = PHI <1(11), perfectiv.32_39(14)>;
:;
:
uboundvar.33_40 = D.684_14 + 1;
perfectiv.32_39 = perfectiv.32_12 + 1;
D.701_18 = perfectiv.32_12 * 5;
D.702_19 = perfectiv.32_12;
D.703_20 = perfectiv.32_12 + D.701_18;
D.704_24 = __BLNK__.a[D.703_20];
D.705_25 = D.704_24 * 2;
__BLNK__.a[D.703_20] = D.705_25;
if (uboundvar.33_40 >= perfectiv.32_39) goto ; else goto ;
:;
goto ();
can_convert_to_perfect_nest only looks at evolution part of the scev:
if (TREE_CODE (stmt) == MODIFY_EXPR)
{
use_operand_p use_a, use_b;
imm_use_iterator imm_iter;
ssa_op_iter op_iter, op_iter1;
tree op0 = TREE_OPERAND (stmt, 0);
tree scev = instantiate_parameters
(loop, analyze_scalar_evolution (loop, op0));
/* If the IV is simple, it can be duplicated. */
if (!automatically_generated_chrec_p (scev))
{
tree step = evolution_part_in_loop_num (scev, loop->num);
if (step && step != chrec_dont_know
&& TREE_CODE (step) == INTEGER_CST)
continue;
}
and replace_uses_equiv_to_x_with_y happily replaces vars with the perfectiv
if the evolution part of the scev is constant and equal to the loop step:
static void
replace_uses_equiv_to_x_with_y (struct loop *loop, tree stmt, tree x,
int xstep, tree y)
{
ssa_op_iter iter;
use_operand_p use_p;
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
{
tree use = USE_FROM_PTR (use_p);
tree step = NULL_TREE;
tree scev = instantiate_parameters (loop,
analyze_scalar_evolution (loop,
use));
if (scev != NULL_TREE && scev != chrec
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-24 15:25 --- (In reply to comment #2) > In my simple view as a physicist the minus sign is an integral part of the > number and not an operation on it, but then I didn't have a formal computer > science education. As a gfortran programmer you have a choice here I would > say. > You'll find that I'm a physicist, too. I have no formal CS training other than reading books and the Fortran standard. It does not matter if you consider the minus a part of the number. It is a unary minus operation according to the Fortran Standard, and that is how gfortran implements its behavior. You are relying on nonportable processor dependent behavior. I've told you how to make your code portable. It is up to you to use the advice or ignore it. BTW, http://gcc.gnu.org/ml/fortran/2006-08/msg00371.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug c++/29582] New: Parameter pushed to stack too soon
Given class COtherClass having methods
class COtherClass
{
...
inline COtherClass(unsigned int uiParam1, const char *pszParam2, const
char *pszParam3, unsigned long ulParam4, const char *pszParam5)
{...}
~COtherClass();
COtherClass &Method1();
COtherClass &Method2(unsigned long long &ullParam);
COtherClass &operator ()(const char *pszParam1, const void *pvParam2);
COtherClass &operator ()(const char *pszParam1, unsigned long long
ullParam2) { ... }
};
For code
struct CHostClass
{
public:
unsigned long long m_ullProblemField;
const void *m_pvPointerField;
const char *m_szSzField;
~CHostClass()
{
COtherClass(5, m_szSzField, NULL, 0,
"ImmString1").Method1().Method2(m_ullProblemField)("ImmString2",
m_pvPointerField)("ImmString3", m_ullProblemField);
}
};
GCC generated the following assembler text (debug build)
mov0x8(%ebp),%eax // CHostClass::this
pushl 0x4(%eax) // HI(CHostClass::m_ullProblemField)
pushl (%eax) // LO(CHostClass::m_ullProblemField)
push $0x81f10f9 // "ImmString3"
sub$0x8,%esp
mov0x8(%ebp),%eax // CHostClass::this
pushl 0x8(%eax) // CHostClass::m_pvPointerField
push $0x81f0e3a // "ImmString2"
sub$0xc,%esp
pushl 0x8(%ebp) // CHostClass::this <=> offset CHostClass::m_ullProblemField
sub$0xc,%esp
push $0x81f1104 // "ImmString1"
push $0x0 // 0
push $0x0 // NULL
mov0x8(%ebp),%eax // CHostClass::this
pushl 0xc(%eax) // CHostClass::m_szSzField
push $0x5 // 5
lea0xf4e8(%ebp),%eax // storage for COtherClass instance
push %eax
call 0x804e61c // COtherClass::COtherClass constructor
add$0x24,%esp // 6*4 params + 12 reserve made with "sub $0xc,%esp"
lea0xf4e8(%ebp),%eax // instance of COtherClass
push %eax
call 0x818e68e // COtherClass::Method1
add$0x4,%esp // 1 param
push %eax // instance of COtherClass
call 0x8190384 // COtherClass::Method2
add$0x14,%esp // 2*4 params + 12 reserve made with "sub $0xc,%esp"
push %eax // instance of COtherClass
call 0x818e85c // COtherClass::operator()(const char *, const void *)
add$0x14,%esp // 3*4 params + 8 reserve made with "sub $0x8,%esp"
push %eax // instance of COtherClass
call 0x804f322 // COtherClass::operator()(const char *, unsigned long long)
add$0x10,%esp // 2*4 + 1*8 params
sub$0xc,%esp
lea0xf4e8(%ebp),%eax // instance of COtherClass
push %eax
call 0x818e610 // COtherClass::~COtherClass
add$0x10,%esp // 1*4 params + 12 reserve made with "sub $0xc,%esp"
The problem is that the value of m_ullProblemField is pushed to stack at the
very beginning of code while it is modified later during invocation of
COtherClass::Method2. COtherClass::operator (const char *, unsigned long long)
should receive modified value of field but it receives initial one.
--
Summary: Parameter pushed to stack too soon
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-24 15:57 --- You should note that C has the same issue really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug c++/29582] Parameter pushed to stack too soon
--- Comment #1 from schwab at suse dot de 2006-10-24 16:02 --- The evaluation order of function arguments is not specified. If you depend on side effects to be carried out at a specific point you must make sure there is a sequence point at the appropriate place. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/29582] Parameter pushed to stack too soon
--- Comment #2 from oder at eleks dot lviv dot ua 2006-10-24 16:09 --- (In reply to comment #1) > The evaluation order of function arguments is not specified. If you depend on > side effects to be carried out at a specific point you must make sure there is > a sequence point at the appropriate place. These are not the arguments of a single function. Given example is the sequence of method invocations for a class instance. Modification of lvalue occurs in 2nd method invocation and it is supposed to be passed to 4th method invocation. -- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/29579] gcc uses sil register in inline asm statement in 32bit mode
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-24 16:14 --- *** This bug has been marked as a duplicate of 10153 *** -- 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=29579
[Bug inline-asm/10153] [3.3/3.4 regression] selection of %dil or %sil on ia32 by valid C source
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-24 16:14 --- *** Bug 29579 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||adam at os dot inf dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10153
[Bug rtl-optimization/29583] New: reorg.c checks insns for delay slots in the wrong order sometimes
fill_simple_delay_slots, in reorg.c, scans backwards for instructions to put in delay slots. It fills the slots in reverse order, i.e. if it finds an instruction A it first puts it in slot 1, if it finds a second one B then A is bumped down to slot 2, and B in slot 1; etc. However, the check eligible_for_delay is called with a slots_filled count, so insn A is checked for slot 1 and insn B is checked for slot 2, even though they end up in slots in the opposite order. Solving this in a fully general fashion is probably a real pain, since when we're picking an insn we don't know how many more will be placed in the list. However, if the restrictions on delay slots are ordered so that any instruction that can go in slot 1 can go in slot 2, but not vice-versa, then we can check all of the new insns against slot 1, and then before inserting we can check that the old slot 1 is eligible for slot 2, old slot 2 for slot 3, etc. I have a patch that does this, and it solved the problem for the VLIW processor I was working with. Another possibility would simply be abort the whole backwards scan once a single slot is filled, and continue with the other (forward) scans, which seem to work correctly. The epilogue delay slot code likely has a similar problem, but that calls a processor specific hook anyway, so the problem can be dealt with there. -- Summary: reorg.c checks insns for delay slots in the wrong order sometimes Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ersmith at hfx dot eastlink dot ca GCC host triplet: any GCC target triplet: any processor with more than one delay slot, not all identical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29583
[Bug rtl-optimization/29583] reorg.c checks insns for delay slots in the wrong order sometimes
--- Comment #1 from ersmith at hfx dot eastlink dot ca 2006-10-24 16:30 --- Created an attachment (id=12484) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12484&action=view) proposed patch to fix delay slot scheduling problems Here is my proposed patch. It checks the existing insns to make sure they can go in the next delay slots before inserting the new one; it also makes sure the new insn is checked against the correct slot. On processors where there are insns that can go in delay slot 1 but not slot 0 the patch is suboptimal, since everything gets tried against slot 0 first; OTOH the existing code is wrong, so suboptimal is an improvement :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29583
[Bug fortran/29393] Vector subscript rejected
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-10-24 17:01 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 17:01:30 2006 New Revision: 118008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118008 Log: fortran/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. Testsuite/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug c/29584] New: internal compiler error on optimization
Internal compiler error when optimization is enabled(not -O0): arm-linux-uclibcgnueabi-gcc -O1 -c test.c include/asm/arch/io.h: In function 'imu_dev_init': include/asm/arch/io.h:43: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error on optimization Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: k dot shutemov at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: arm-linux-uclibcgnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug c/29584] internal compiler error on optimization
--- Comment #1 from k dot shutemov at gmail dot com 2006-10-24 17:17 --- Created an attachment (id=12485) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12485&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #14 from ghazi at gcc dot gnu dot org 2006-10-24 17:44 --- Subject: Bug 29335 Author: ghazi Date: Tue Oct 24 17:44:36 2006 New Revision: 118009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118009 Log: PR middle-end/29335 * builtins.c (fold_builtin_sin, fold_builtin_atan): Remove. (do_mpfr_arg1): Add `min', `max' and `inclusive' arguments. Update all callers. (BUILT_IN_SIN, BUILT_IN_ATAN): Handle in main switch. (BUILT_IN_ASIN, BUILT_IN_ACOS, BUILT_IN_ATAN, BUILT_IN_ASINH, BUILT_IN_ACOSH, BUILT_IN_ATANH, BUILT_IN_SINH, BUILT_IN_COSH, BUILT_IN_TANH): Calculate compile-time arguments using MPFR. testsuite: * gcc.dg/torture/builtin-math-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug middle-end/29584] internal compiler error on optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-10-24 18:31 --- (In reply to comment #13) > We now get > > : > # param_2 = V_MAY_DEF ; > param.f1 = 0; > # param_6 = V_MAY_DEF ; > # SFT.0_7 = V_MAY_DEF ; > # NONLOCAL.6_8 = V_MAY_DEF ; > # NONLOCAL.12_13 = V_MAY_DEF ; > # NONLOCAL.18_16 = V_MAY_DEF ; > # NONLOCAL.24_19 = V_MAY_DEF ; > # NONLOCAL.30_22 = V_MAY_DEF ; > # NONLOCAL.36_25 = V_MAY_DEF ; > __builtin_memcpy (&local, ¶m, 9); > # VUSE ; > D.2668_4 = local.f1; > if (D.2668_4 != 0) goto ; else goto ; > > :; > # param_9 = V_MAY_DEF ; > # SFT.0_10 = V_MAY_DEF ; > # NONLOCAL.6_11 = V_MAY_DEF ; > # NONLOCAL.12_14 = V_MAY_DEF ; > # NONLOCAL.18_17 = V_MAY_DEF ; > # NONLOCAL.24_20 = V_MAY_DEF ; > # NONLOCAL.30_23 = V_MAY_DEF ; > # NONLOCAL.36_26 = V_MAY_DEF ; > link_error (); > > :; > return; > Uh, there should only ever be one non-local var per function, and referenced vars should be reset at the end of each function so why do you have multiple NONLOCAL's here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13954
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #2 from tbm at gcc dot gnu dot org 2006-10-24 18:56 --- This also happens on amd64. Segfaults with 4.0 and 4.1, works with 3.4 and 4.2. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|arm-linux-uclibcgnueabi | Last reconfirmed|-00-00 00:00:00 |2006-10-24 18:56:28 date|| Summary|internal compiler error on |[4.0/4.1 Regression] |optimization|internal compiler error on ||optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #3 from tbm at gcc dot gnu dot org 2006-10-24 18:56 --- Created an attachment (id=12486) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12486&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #4 from tbm at gcc dot gnu dot org 2006-10-24 19:02 --- (gdb) where #0 expand_case (exp=Variable "exp" is not available. ) at /home/tbm/scratch/gcc-4.1/gcc/stmt.c:2106 #1 0x00533ee7 in expand_expr_real_1 (exp=Variable "exp" is not available. ) at /home/tbm/scratch/gcc-4.1/gcc/expr.c:8491 #2 0x005377b9 in expand_expr_real (exp=0x2b984c15, target=0x2b984bf72400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /home/tbm/scratch/gcc-4.1/gcc/expr.c:6530 #3 0x006c3e49 in expand_expr_stmt (exp=0x2b984c15) at expr.h:493 #4 0x006e9d80 in expand_gimple_basic_block (bb=0x2b984c140280, dump_file=Variable "dump_file" is not available. ) at /home/tbm/scratch/gcc-4.1/gcc/cfgexpand.c:1367 #5 0x006eac8d in tree_expand_cfg () at /home/tbm/scratch/gcc-4.1/gcc/cfgexpand.c:1626 #6 0x006e7516 in execute_one_pass (pass=0xa31780) at /home/tbm/scratch/gcc-4.1/gcc/passes.c:827 #7 0x006e760c in execute_pass_list (pass=0xa31780) at /home/tbm/scratch/gcc-4.1/gcc/passes.c:859 #8 0x0045d77a in tree_rest_of_compilation (fndecl=0x2b984c120e00) at /home/tbm/scratch/gcc-4.1/gcc/tree-optimize.c:419 #9 0x0040a628 in c_expand_body (fndecl=0x2b984c120e00) at /home/tbm/scratch/gcc-4.1/gcc/c-decl.c:6692 #10 0x007249c2 in cgraph_expand_function (node=0x2b984c1394d0) at /home/tbm/scratch/gcc-4.1/gcc/cgraphunit.c:1058 #11 0x007257ac in cgraph_optimize () at /home/tbm/scratch/gcc-4.1/gcc/cgraphunit.c:1124 #12 0x004100d2 in c_write_global_declarations () at /home/tbm/scratch/gcc-4.1/gcc/c-decl.c:7700 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-10-24 19:03 --- Sorry for missing that bug. The proposed patch is OK -- thanks for catching this. As to the general problem, I think you're right that we need to further constrain the range of accepted offsets. However, DISP_IN_RANGE is not the right solution, we can do a lot better. I think the right fix would be to accept any offset in the +- 2 GB range (*not* 4 GB) as today. Since we restrict executable / shared object sizes to 2 GB right now, the delta between the symbol and the pc is in the range +- 2GB. Adding an offset in the +- 2 GB range will result in a total delta in the +- 4 GB range -- which is just what larl allows. The +- 2 GB range is also big enough to accept any (reasonable) offset on a 31-bit system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug middle-end/29584] [4.0/4.1 Regression] internal compiler error on optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-24 19:04 --- 0x8000UL ... (0x8000UL + 0x3a00UL - 1): I think this is a case of an overflow. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29584
[Bug tree-optimization/29585] New: [4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
This didn't happen with 4.2 20061015. It happens with mainline but I cannot check the 4.2 branch right now. (sid)978:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c pasmo-asm.cc pasmo-asm.cc:77: warning: 'Asm::In' has a field 'Asm::In::nullout' whose type uses the anonymous namespace (sid)979:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O pasmo-asm.cc pasmo-asm.cc:77: warning: 'Asm::In' has a field 'Asm::In::nullout' whose type uses the anonymous namespace pasmo-asm.cc: In constructor '::Nullostream::Nullostream()': pasmo-asm.cc:64: internal compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug tree-optimization/29585] [4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #1 from tbm at cyrius dot com 2006-10-24 19:12 --- Created an attachment (id=12487) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12487&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug preprocessor/29586] New: [4.1 Regression] CPP doesn't handle ticks in #warning
$ cat blah.c #warning (that's not C?) $ gcc-4.1 -c -o blah.o blah.c blah.c:1:2: warning: #warning (that's not C?) $ gcc-4.3-HEAD -c -o blah.o blah.c blah.c:1:2: warning: #warning (thatblah.c:1:15: warning: missing terminating ' character 's not C?) Fails with: gcc version 4.3.0 20061024 (experimental) gcc version 4.2.0 20060922 (experimental) Works with: gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) -- Summary: [4.1 Regression] CPP doesn't handle ticks in #warning Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29586
[Bug preprocessor/29586] [4.1 Regression] CPP doesn't handle ticks in #warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-24 20:26 --- No this is not valid and in fact was rejected in GCC before 3.4.0. In fact this is undefined behavior at compile time. SEE PR 12743 for more discussion about this. *** This bug has been marked as a duplicate of 14634 *** -- 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=29586
[Bug preprocessor/14634] Unterminated literals not diagnosed
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-24 20:26 --- *** Bug 29586 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14634
[Bug fortran/29393] Vector subscript rejected
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-10-24 20:40 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 20:40:19 2006 New Revision: 118010 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118010 Log: fortran/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. testsuite/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug preprocessor/14634] Unterminated literals not diagnosed
--- Comment #12 from aldot at gcc dot gnu dot org 2006-10-24 20:41 --- (In reply to comment #11) > *** Bug 29586 has been marked as a duplicate of this bug. *** > Fair enough. Still pr29586 seems to be a diagnostic bug since the warning is mangled: $ cat blah.c #warning (that's not C?) $ gcc-4.3 -c -o blah.o blah.c blah.c:1:2: warning: #warning (thatblah.c:1:15: warning: missing terminating ' character 's not C?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14634
[Bug fortran/29393] Vector subscript rejected
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-10-24 20:45 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 20:45:29 2006 New Revision: 118011 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118011 Log: fortran/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. testsuite/ 2006-10-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29393] Vector subscript rejected
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-24 22:51 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug java/29587] New: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
/mnt/gnu/gcc/objdir/gcc/gcj -B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ -fclasspath= -fbootclasspath=/mnt/gnu/gcc/objdir/hpp a2.0w-hp-hpux11.11/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fboot strap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c @org-omg .list -o org-omg.o >/dev/null 2>&1 jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes make[3]: *** [gnu-xml.lo] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/mnt/gnu/gcc/objdir' make: *** [bootstrap] Error 2 Mon Oct 23 22:23:06 EDT 2006 -- Summary: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587
[Bug preprocessor/29588] New: /usr/local/include should not be in the default include path
Because /usr/local/include is in the default include path, the include path and the library path are not consistent. The consequence is that (unless the user has modified the search paths with environment variables or switches) when some version of a library is installed in /usr (e.g., provided by the system) and another version of the library is installed in /usr/local (e.g., installed by the admin with configure, make, make install), the header file will be taken from /usr/local/include and the library will be taken from /usr/lib, but they do not correspond to the same version. For instance, this problem can be seen when GMP 4.1.4 is installed in /usr (as in Debian/stable) and the user installs GMP 4.2.1 (the latest version) in /usr/local (with configure, make, make install), as the gmp.h from GMP 4.2.1 is not compatible with the GMP library version 4.1.4. In short, gcc should make sure that include and library search paths are consistent *by default*. If the user wants a different search path, he can still modifie C_INCLUDE_PATH, LIBRARY_PATH and LD_LIBRARY_PATH (for instance) altogether. -- Summary: /usr/local/include should not be in the default include path Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent at vinc17 dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29588
[Bug rtl-optimization/29589] New: incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
We add an optimization phase in GCC, and our changes trigger GCC generates
incorrect code during the combine phase. GCC incorrectly combine three
instructions into two intructions:
from:
insn_1set (SI reg_a) (plus:SI (SI: reg_b) (const_int -1))
insn_2set (SI reg_c) (ashiftrt:SI (SI: reg_a) (const_int 31))
insn_3set (SI reg_d) (ior:SI (SI: reg_c) (const_int C))
into
insn_1set (SI reg_a) (plus:SI (SI: reg_b) (const_int -1))
insn_2set (SI reg_c) (ashiftrt:SI (SI: reg_a) (const_int 31))
where the third instruction has been deleted incorrectly.
The buggy code is in simplify_logical (rtx x) in combine.c:
/* If OP0 is (ashiftrt (plus ...) C), it might actually be
a (sign_extend (plus ...)). If so, OP1 is a CONST_INT, and the PLUS
does not affect any of the bits in OP1, it can really be done
as a PLUS and we can associate. We do this by seeing if OP1
can be safely shifted left C bits. */
if (GET_CODE (op1) == CONST_INT && GET_CODE (op0) == ASHIFTRT
&& GET_CODE (XEXP (op0, 0)) == PLUS
&& GET_CODE (XEXP (XEXP (op0, 0), 1)) == CONST_INT
&& GET_CODE (XEXP (op0, 1)) == CONST_INT
&& INTVAL (XEXP (op0, 1)) < HOST_BITS_PER_WIDE_INT)
{
int count = INTVAL (XEXP (op0, 1));
HOST_WIDE_INT mask = INTVAL (op1) << count;
if (mask >> count == INTVAL (op1)
&& (mask & nonzero_bits (XEXP (op0, 0), mode)) == 0)
{
SUBST (XEXP (XEXP (op0, 0), 1),
GEN_INT (INTVAL (XEXP (XEXP (op0, 0), 1)) | mask));
return op0;
}
}
...
Where x =
(ior:SI (ashiftrt:SI (plus:SI (reg:SI 127)
(const_int -1 [0x]))
(const_int 31 [0x1f]))
(const_int 60 [0x3c]))
After the simplification:
x = op0 =
(ashiftrt:SI (plus:SI (reg:SI 127)
(const_int -1 [0x]))
(const_int 31 [0x1f]))
We think the buggy code is this line:
...
(mask & nonzero_bits (XEXP (op0, 0), mode)) == 0
where nonzero_bits returns 0x.
We think may be what wanted is:
...
(INTVAL (op1) & nonzero_bits (XEXP (op0, 0), mode)) == 0
With this patch, the optimization for this case is undoable and should just be
disabled.
The following is the source code and rtl dumps before combine (test.c.26.life1)
and after combine phase (test.c.27.combine).
The option we uses: gcc -O3 -fno-inline (+with our optimization changes)
The instructions to be combined are in foo() in test.c.26.life1:
...
(insn 51 50 52 0 (set (reg:SI 128)
(plus:SI (reg:SI 127)
(const_int -1 [0x]))) 39 {*addsi3_internal1}
(insn_l
ist:REG_DEP_TRUE 50 (nil))
(expr_list:REG_DEAD (reg:SI 127)
(nil)))
(insn 52 51 54 0 (set (reg:SI 129)
(ashiftrt:SI (reg:SI 128)
(const_int 31 [0x1f]))) 134 {ashrsi3_no_power}
(insn_list:REG_DEP_TR
UE 51 (nil))
(expr_list:REG_DEAD (reg:SI 128)
(nil)))
(insn 54 52 26 0 (set (reg/v:SI 119 [ b ])
(ior:SI (reg:SI 129)
(const_int 60 [0x3c]))) 85 {*boolsi3_internal1}
(insn_list:REG_DEP_T
RUE 52 (nil))
(expr_list:REG_DEAD (reg:SI 129)
(nil)))
...
--- source code ---
extern void abort (void);
extern void exit (int);
_Bool a;
int foo ()
{
int b;
if (a) goto L1; else goto L0;
L0:
b = -1; goto L2;
L1:
b = 0x3c;
L2:
return b;
}
int main(int argc, char **argv)
{
a = 1;
if (foo() != 0x3c)
abort();
exit(0);
}
rtl-dump: test.c.26.life1
;; Function foo (foo)
try_optimize_cfg iteration 1
try_optimize_cfg iteration 1
(note 2 0 6 NOTE_INSN_DELETED)
(note 6 2 9 NOTE_INSN_FUNCTION_BEG)
;; Start of basic block 0, registers live: 1 [1] 2 [2] 31 [31] 67 [ap] 109
[vrsa
ve] 110 [vscr] 113 [sfp]
(note 9 6 11 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 11 9 12 0 (use (symbol_ref:DI ("a") )) -1
(nil)
(nil))
(insn 12 11 13 0 (set (reg/f:DI 121 [ A8 ])
(zero_extend:DI (mem/u/c:SI (plus:DI (reg:DI 2 2)
(const:DI (minus:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2])
(symbol_ref:DI ("*.LCTOC1") [5 S8 A64]))) 2
{*ze
ro_extendsidi2_internal1} (nil)
(expr_list:REG_DEAD (reg:DI 2 2)
(expr_list:REG_EQUAL (symbol_ref:DI ("a") )
(nil
(insn 13 12 14 0 (set (reg:QI 123 [ a ])
(mem/c/i:QI (reg/f:DI 121 [ A8 ]) [3 a+0 S1 A8])) 257 {*movqi_internal}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg/f:DI 121 [ A8 ])
(nil)))
(insn 14 13 50 0 (set (reg:SI 122 [ a ])
(zero_extend:SI (reg:QI 123 [ a ]))) 20 {*rs6000.md:474}
(insn_list:REG_
DEP_TRUE 13 (nil))
(expr_list:REG_DEAD (reg:QI 123 [ a ])
[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
--- Comment #1 from dje at transmeta dot com 2006-10-25 02:23 --- Re: "We think may be what wanted is:" ... That's just off the cuff speculation. The curious things are: - op1 is shifted outside the mode of the operation (0x3c << 31) (HOST_WIDE_INT is 64 bits) and this value is the value AND'd with the result of nonzero_bits. - nonzero_bits returns bits that may be one, not bits that are one, so it's not clear this optimization is valid regardless of anything else -- dje at transmeta dot com changed: What|Removed |Added Summary|incorrect conversion of (ior|incorrect conversion of (ior |(ashiftrt (plus ...))) in |(ashiftrt (plus ...))) in |combine.c |combine.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29589
[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
--- Comment #2 from dje at transmeta dot com 2006-10-25 02:41 --- Thinking about it some more, disregard this (I think): - nonzero_bits returns bits that may be one, not bits that are one, so it's not clear this optimization is valid regardless of anything else I _think_ this is the culprit, though it's not worded very well: - op1 is shifted outside the mode of the operation (0x3c << 31) (HOST_WIDE_INT is 64 bits) and this value is the value AND'd with the result of nonzero_bits. I think that's what you want, but "We do this by seeing if OP1 can be safely shifted left C bits" doesn't take into account the mode of the operation. Just guessing though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29589
[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-25 03:07 --- Revision 1.169 / (download) - annotate - [select for diffs] , Fri May 6 16:42:40 1994 UTC (12 years, 5 months ago) by kenner Branch: MAIN Changes since 1.168: +123 -91 lines Diff to previous 1.168 (colored) (simplify_rtx, case MULT): Don't convert MULT to shift here. (simplify_logical, case IOR): Convert back to PLUS if valid and it will combine with another PLUS. (extract_left_shift): New function. (make_compound_operation, case ASHIFTRT): Simplify by calling it. (force_to_mode): Don't ignore if X is a SUBREG. (force_to_mode, case AND): Try to turn unchecked bits on instead of just off and see which is cheaper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29589
[Bug preprocessor/29588] /usr/local/include should not be in the default include path
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 03:08 --- Actually it is a bug that the library is not picking up and not a GCC bug. The library path is consistent with GCC's include path by default unless you messed up something. So this sounds like a bug in your installation. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29588
[Bug tree-optimization/29585] [4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-25 04:55 ---
Here is a more reduced (and cleaned up) testcase:
class ios_base{};
struct basic_ostream : virtual ios_base{};
namespace
{
struct Nullostream : basic_ostream{};
}
class In
{
In ();
Nullostream nullout;
};
In::In (){}
This is an interaction between aliasing and anonymous namespaces.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|normal |blocker
Keywords||ice-on-valid-code
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug tree-optimization/29585] [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking Summary|[4.3 Regression] tree check:|[4.2/4.3 Regression] tree |expected ssa_name, have |check: expected ssa_name, |var_decl in is_old_name, at |have var_decl in |tree-into-ssa.c:558 |is_old_name, at tree-into- ||ssa.c:558 Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug tree-optimization/29585] [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-25 05:09 --- Confirmed. -- 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 |2006-10-25 05:09:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug fortran/29563] Internal read loses data.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-25 05:17 --- I have isolated the problem in list_read.c and am working on a patch. It will be a day or two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug tree-optimization/29585] [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 --- _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream # _ZTI13basic_ostream = V_MAY_DEF <_ZTI13basic_ostream_16>; # _ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF <_ZTIN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE_17>; # _ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream = V_MAY_DEF <_ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream>; # _ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE = V_MAY_DEF <_ZTSN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE>; # _ZTVN10__cxxabiv120__si_class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv120__si_class_type_infoE>; # _ZTI8ios_base = V_MAY_DEF <_ZTI8ios_base>; # _ZTS13basic_ostream = V_MAY_DEF <_ZTS13basic_ostream>; # _ZTVN10__cxxabiv121__vmi_class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv121__vmi_class_type_infoE>; # _ZTS8ios_base = V_MAY_DEF <_ZTS8ios_base>; # _ZTVN10__cxxabiv117__class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv117__class_type_infoE>; # SFT.5 = V_MAY_DEF ; # SFT.6 = V_MAY_DEF ; # SFT.7 = V_MAY_DEF ; # SFT.8 = V_MAY_DEF ; # SFT.9 = V_MAY_DEF ; # NONLOCAL.15 = V_MAY_DEF ; this_9->_vptr.basic_ostream = iftmp.1_13; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug middle-end/29519] [4.2/4.3 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #9 from daney at gcc dot gnu dot org 2006-10-25 05:49 --- Subject: Bug 29519 Author: daney Date: Wed Oct 25 05:49:43 2006 New Revision: 118023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118023 Log: PR middle-end/29519 * rtlanal.c (nonzero_address_p): Remove check for values wrapping. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
