[Bug tree-optimization/37690] New: typo in the example for -floop-strip-mine
I believe there is an off-by-one typo in the examples for -floop-strip-mine and -floop-block, see the attached patch. -- Summary: typo in the example for -floop-strip-mine Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kasal at ucw dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690
[Bug tree-optimization/37690] typo in the example for -floop-strip-mine
--- Comment #1 from kasal at ucw dot cz 2008-10-01 07:57 --- Created an attachment (id=16437) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16437action=view) patch for the typos -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #8 from bonzini at gnu dot org 2008-10-01 08:01 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01990.html Ok. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #5 from dodji at gcc dot gnu dot org 2008-10-01 09:31 --- Created an attachment (id=16438) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16438action=view) Second version of the patch @Jakub: Please find attached a second version of the patch that should address your comments. Thanks. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #16393|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch causes other problems
This test case:
/* t1.c */
int i[0];
int k;
void testi (void)
{
i[0] = 0;
}
void testk (void)
{
k = 0;
}
int main (void)
{
return 0;
}
now fails with
t1.c:(.text+0x5): undefined reference to `_i'
The assembler code is
.file t1.c
.text
.p2align 4,,15
.globl _testi
.def_testi; .scl2; .type 32; .endef
_testi:
pushl %ebp
movl%esp, %ebp
movl$0, _i
popl%ebp
ret
.p2align 4,,15
.globl _testk
.def_testk; .scl2; .type 32; .endef
_testk:
pushl %ebp
movl%esp, %ebp
movl$0, _k
popl%ebp
ret
.def___main;.scl2; .type 32; .endef
.p2align 4,,15
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
call___main
xorl%eax, %eax
movl%ebp, %esp
popl%ebp
ret
.bss
.balign 4
.comm _i, 0 size of i[0]
.balign 4
.comm _k, 4
I suspect we need to add this bit, or similar, back in
- rounded = size ? size : 1;
- rounded += (BIGGEST_ALIGNMENT / BITS_PER_UNIT) - 1;
- rounded = (rounded / (BIGGEST_ALIGNMENT / BITS_PER_UNIT)
-* (BIGGEST_ALIGNMENT / BITS_PER_UNIT));
and output rounded rather than size.
Testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug c/37689] [4.4 Regression] ICE compiling newlib
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 10:52 --- Dup of PR37285? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37689
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 10:54 --- Preprocessed source? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code Summary|Building of CPU2000's bzip2 |[4.4 Regression] Building of |with peak flags with - |CPU2000's bzip2 with peak |mcpu=power4 fails with an |flags with -mcpu=power4 |ICE.|fails with an ICE. Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Comment #4 from laurent at guerby dot net 2008-10-01 11:14 --- I checked and the bahviour hasn't changed in the past three years, libada is not rebuilt when the backend is. If it's accepted as normal (Paolo?) I'll close this report. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net, ||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Comment #5 from bonzini at gnu dot org 2008-10-01 11:20 --- I don't think they ever did; indeed toplevel bootstrap was enabled on 2005-12-14 which is after this bugreport was started. You can make clean-target; make all or make restrap. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug target/37615] terminate called after throwing and instance of 'XXX' c++ testsuite failures
--- Comment #2 from sposelenov at emcraft dot com 2008-10-01 11:28 --- Found the cause of the problem - it's binutils 2.17.50. Using ld version 2.18 or even 2.17.90 creates workable libstdc++.so. Could please someone responsible close this bug with correct resolution? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37615
[Bug fortran/36192] ICE with wrong index types and bad parens
--- Comment #6 from dominiq at lps dot ens dot fr 2008-10-01 12:09 --- Reduced code: program three_body real, parameter :: n = 2, d = 2 real, dimension(n,d) :: x x(1,:) = (/ 1.0, 0.0 /) end program three_body gives pr36192_ice.f90:3.18: real, dimension(n,d) :: x 1 Error: Expression at (1) must be of INTEGER type pr36192_ice.f90:3.20: real, dimension(n,d) :: x 1 Error: Expression at (1) must be of INTEGER type pr36192_ice.f90:3.27: real, dimension(n,d) :: x 1 Error: The module or main program array 'x' at (1) must have constant shape f951: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The ICE disappears if the line x(1,:) = (/ 1.0, 0.0 /) is commented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #4 from pdemarco at ppg dot com 2008-10-01 12:10 --- any chance of getting this fixed on 3.4.4 ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug tree-optimization/37662] [4.4 Regression] ice: tree check: expected ssa_name, have integer_cst in get_value_range, at tree-vrp.c:612
--- Comment #7 from bonzini at gnu dot org 2008-10-01 12:23 --- Subject: Bug 37662 Author: bonzini Date: Wed Oct 1 12:22:17 2008 New Revision: 140809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140809 Log: 2008-09-30 Paolo Bonzini [EMAIL PROTECTED] PR tree-optimization/37662 * tree-ssa-ccp.c (fold_gimple_assign): Invert the operands of a commutative binary operation if they are in the wrong order and fold_build2 produces non-GIMPLE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37662
[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C
--- Comment #5 from bonzini at gnu dot org 2008-10-01 12:24 --- committing patch as obvious, thanks. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-01 12:24:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37683
[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C
--- Comment #6 from bonzini at gnu dot org 2008-10-01 12:26 --- committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37683
[Bug c++/37683] [4.4 Regression]: Revision 140780 caused g++.dg/warn/Wparentheses-3.C
--- Comment #7 from bonzini at gnu dot org 2008-10-01 12:27 --- Subject: Bug 37683 Author: bonzini Date: Wed Oct 1 12:26:02 2008 New Revision: 140810 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140810 Log: 2008-09-30 H.J. Lu [EMAIL PROTECTED] PR c++/37683 * parser.c (cp_parser_selection_statement): Fix uninitialized variable. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37683
[Bug fortran/37691] New: Duplicate error messages
Extracted from pr36192, the following code program three_body real, parameter :: n = 2, d = 2 ! real, dimension(n), parameter :: m = (/ 1.0, 1.0 /) real, dimension(n,d) :: x, v ! real, dimension(n,d) :: x, v, x_n, v_n, x_hq, v_hq end program three_body yields the following errors pr36192_dup.f90:4.18: real, dimension(n,d) :: x, v 1 Error: Expression at (1) must be of INTEGER type pr36192_dup.f90:4.20: real, dimension(n,d) :: x, v 1 Error: Expression at (1) must be of INTEGER type pr36192_dup.f90:4.30: real, dimension(n,d) :: x, v 1 Error: The module or main program array 'v' at (1) must have constant shape pr36192_dup.f90:4.18: real, dimension(n,d) :: x, v 1 Error: Expression at (1) must be of INTEGER type pr36192_dup.f90:4.20: real, dimension(n,d) :: x, v 1 Error: Expression at (1) must be of INTEGER type pr36192_dup.f90:4.27: real, dimension(n,d) :: x, v 1 Error: The module or main program array 'x' at (1) must have constant shape where the messages Expression at (1) must be of INTEGER type are emitted twice. If the x_n, v_n, x_hq, v_hq arrays are added, these messages are emitted six times, as if they were delayed until the messages The module or main program array 'v' at (1) must have constant shape are emiited. I don't know why the INTEGER type error was delayed, but emitting it when it is first encountered should solve the problem. Note that in the patch http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01755.html submitted by Daniel kraft, all the Expression at (1) must be of INTEGER type errors were removed, making difficult to locate the primary cause of the errors (n and d declared as real). -- Summary: Duplicate error messages Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37691
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #2 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 13:10 --- Created an attachment (id=16439) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16439action=view) Preprocessed source for reduced bzip2.c Preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #3 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 13:10 --- Created an attachment (id=16440) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16440action=view) Reduced source for bzip2.c Source reduced with delta -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #4 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 13:13 --- Created an attachment (id=16441) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16441action=view) Reduced source for bzip2.c Indented reduced source. -- luisgpm at linux dot vnet dot ibm dot com changed: What|Removed |Added Attachment #16440|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #5 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 13:19 --- I'm still trying to minimize even further the source. Will attach when i have something better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 13:20 ---
Note that after tuples we always have a default label again, just the default
label isn't a default label. I have a patch to fix that, sort of
Index: tree-vrp.c
===
*** tree-vrp.c (revision 140810)
--- tree-vrp.c (working copy)
*** execute_vrp (void)
*** 7149,7157
--- 7149,7164
{
size_t j;
size_t n = TREE_VEC_LENGTH (su-vec);
+ tree label;
gimple_switch_set_num_labels (su-stmt, n);
for (j = 0; j n; j++)
gimple_switch_set_label (su-stmt, j, TREE_VEC_ELT (su-vec, j));
+ /* As we may have replaced the default label with a regular one
+make sure to make it a real default label again. This ensures
+optimal expansion. */
+ label = gimple_switch_default_label (su-stmt);
+ CASE_LOW (label) = NULL_TREE;
+ CASE_HIGH (label) = NULL_TREE;
}
if (VEC_length (edge, to_remove_edges) 0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37285
[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc
-- 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|NEW |ASSIGNED Last reconfirmed|2008-08-31 11:59:27 |2008-10-01 13:27:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37285
[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2
--- Comment #4 from mycae at yahoo dot com 2008-10-01 13:34 --- Created an attachment (id=16442) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16442action=view) .i and .s file for menu I also experience this problem when compiling with the latest wine 1.1.5 sources. I have attached the .i .s file generated by the following command /usr/bin/gcc --save-temps -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o menu.o menu.c gcc version: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 13:44 --- Indeed. This exposes a bug as we do not fold VIEW_CONVERT_EXPR char * (0.0). As we never initialize NEW_SETS for FRE we should not try to add to it. -- 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|NEW |ASSIGNED Last reconfirmed|2008-09-22 21:09:59 |2008-10-01 13:44:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37692] New: [alias-improvements-branch] can't alias fortran function arguments
This happens in testcases gfortran.dg/vect/vect-[2,3,4].f90 - On the alias branch we can't tell that subroutine arguments don't alias. e.g., X,Y in SUBROUTINE SAXPY(X,Y,A). As a result the vectorizer applies loop-versioning with runtime aliasing test, which also means it will handle misalignment using versioning instead of peeling: versioning for alias required: can't determine dependence between (*x_32(D))[D.1518_28] and (*y_29(D))[D.1518_28] vect-3.f90:6: note: mark for run-time aliasing test between (*x_32(D))[D.1518_28] and (*y_29(D))[D.1518_28] ... vect-3.f90:6: note: Alignment of access forced using versioning. vect-3.f90:6: note: Versioning for alignment will be applied. -- Summary: [alias-improvements-branch] can't alias fortran function arguments Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org GCC build triplet: i386-linux GCC host triplet: i386-linux GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37692
[Bug tree-optimization/37693] New: [alias-improvements-branch] can't prove non-zero number of iterations
This happens in testcase gfortran.dg/vect/pr32377.f90: On the alias branch can't prove that number of iteratios is non zero: Analyzing # of iterations of loop 1 exit condition [2, + , 1](no_overflow) D.1554_60 bounds on difference of bases: -2147483650 ... 2147483645 result: zero if D.1554_60 = 1 # of iterations (character(kind=4)) D.1554_60 + 0x0fffe, bounded by 2147483645 (set_nb_iterations_in_loop = scev_not_known)) (get_loop_exit_condition if (D.1554_60 = S.10_78) ) pr32377.f90:9: note: not vectorized: number of iterations cannot be computed. pr32377.f90:9: note: bad loop form. pr32377.f90:4: note: vectorized 0 loops in function. Using mainline we have: Analyzing # of iterations of loop 1 exit condition [2, + , 1](no_overflow) D.1416_112 bounds on difference of bases: 0 ... 2147483645 result: # of iterations (character(kind=4)) D.1416_112 + 0x0fffe, bounded by 2147483645 (set_nb_iterations_in_loop = (character(kind=4)) D.1416_112 + 0x0fffe)) pr32377.f90:9: note: == get_loop_niters:(character(kind=4)) D.1416_112 + 0x0(get_loop_exit_condition if (S.10_78 = D.1416_112) ) pr32377.f90:9: note: Symbolic number of iterations is (character(kind=4)) D.1416_112 + 0x0 -- Summary: [alias-improvements-branch] can't prove non-zero number of iterations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37693
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:12 ---
Doesn't ICE for me with a cross from x86_64,
./cc1 -quiet bzip2-reduced.i -O3 -ffast-math -funroll-loops -ftree-loop-linear
-fpeel-loops -mcpu=power4 {,-m32,-m64}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug tree-optimization/37694] New: [alias-improvements-branch] can't alias (restrict) function-pointer (read) and local array (write)
This happens in testcases gcc.dg/vect/no-scevccp-outer-6.c and gcc.dg/vect/vect-multitypes-6.c: On the alias branch we can't tell that a read through a (restrict) pointer (which is a function argument) does not overlap with write to a local arrays. As a result we try to vectorize the loop using loop-versioning controled by a run-time aliasing test. In no-scevccp-outer-6.c this capability is not yet supported for outer-loops so we can't vectorize the outer-loop (the inner loop does get vectorized). In vect-multitypes-6.c there are too many runtime checks required, so we bail out: === vect_prune_runtime_alias_test_list === vect-multitypes-6.c:34: note: disable versioning for alias - max number of generated checks exceeded. vect-multitypes-6.c:34: note: too long list of versioning for alias run-time tests. (with --param vect-max-version-for-alias-checks=20 we do vectorize the loop). -- Summary: [alias-improvements-branch] can't alias (restrict) function-pointer (read) and local array (write) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37694
[Bug tree-optimization/37692] [alias-improvements-branch] can't alias fortran function arguments
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:17 --- Mine. The alias-oracle doesn't use PTA information yet. -- 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 |2008-10-01 14:17:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37692
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #5 from dave dot korn at artimi dot com 2008-10-01 14:19 --- Sorry mate, all 3.x compilers are way past end-of-life now; there will never be another release. Your best bet is to hand-edit the header files in your local install. I don't remember the exact recipe, but of the two places where this bug crops up, one can be worked around by adding __attribute__ ((__unused__)) to the relevant variable declaration, and the other one has to be fixed by adding __attribute__ ((__noinline__)) to the function declaration. I haven't tested these workaround for performance impact. Shouldn't be too bad if you're not calling the functions from the middle of a loop that runs millions of times. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug tree-optimization/37695] New: [alias-improvements-branch] can't alias a restrict pointer write and a local array read
This happens in gcc.dg/vect/vect-42.c: On the alias branch we can't tell that a write through a restrict pointer (which is a function argument) does not overlap with reads from local arrays. As a result we vectorize using loop-versioning controled by a run-time aliasing test. This in turn forces us to handle misalignment using loop-versioning (rather than peeling, cause right now we don't support peeling combined with versioning, and these are the only ways we currently support misaligned stores). Without the aliasing problem, the loop is vectorized using peeling to align the store. === vect_analyze_dependences === vect-42.c:36: note: versioning for alias required: can't determine dependence between pb[i_59] and *D.2074_6 vect-42.c:36: note: mark for run-time aliasing test between pb[i_59] and *D.2074_6 vect-42.c:36: note: versioning for alias required: can't determine dependence between pc[i_59] and *D.2074_6 vect-42.c:36: note: mark for run-time aliasing test between pc[i_59] and *D.2074_6 ... vect-42.c:36: note: === vect_enhance_data_refs_alignment === vect-42.c:36: note: Unknown misalignment, is_packed = 0 vect-42.c:36: note: Alignment of access forced using versioning. vect-42.c:36: note: Versioning for alignment will be applied. -- Summary: [alias-improvements-branch] can't alias a restrict pointer write and a local array read Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37695
[Bug middle-end/37696] New: [meta-bug] PRs blocking adoption of the alias-improvements branch
Add PRs in the Depends on field. All dependent bugs are latent on the trunk in case partitioning would chose a pessimizing partitioning. -- Summary: [meta-bug] PRs blocking adoption of the alias- improvements branch Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization, alias Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org BugsThisDependsOn: 37692,37693 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37696
[Bug c++/37697] New: dynamic_cast to void cv* wrongly allowed with -fno-rtti
Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1
(on ARM target) shows use of RTTI which we have asserted is absent.
struct B1 { virtual int f(); };
struct B2 { virtual int g(); };
struct D: B1, B2 { };
/* These should be allowed even with -fno-rtti */
B1 *f2(B1 *p) { return dynamic_castB1 *(p); }
B1 *f3(D *p) { return dynamic_castB1 *(p); }
/* These should not be allowed with -fno-rtti */
/* gABI 2.9.4 case #1: dynamic castvoid cv*, which returns a pointer to the
complete lvalue */
void *g1(B1 *p) { return dynamic_castvoid *(p); }
/* gABI 2.9.4 case #2: dynamic cast operation from a proper base class to a
derived clasB1 */
D *g2(B1 *p) { return dynamic_castD *(p); }
/* gABI 2.9.4 case #3: dynamic_cast across the hierarchy which can be seen as a
cast to the complete lvalue and back to a sibling base */
B1 *g3(B2 *p) { return dynamic_castB1 *(p); }
--
Summary: dynamic_cast to void cv* wrongly allowed with -fno-rtti
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC target triplet: ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
[Bug tree-optimization/37694] [alias-improvements-branch] can't alias (restrict) function-pointer (read) and local array (write)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:24 --- restricted pointers are still not properly handled by the middle-end, neither are they dealt with by the alias-oracle. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14187 OtherBugsDependingO||37696 nThis|| Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37694
[Bug tree-optimization/37698] New: [alias-improvements-branch] pre makes latech-block non-empty
This happens in testcase gcc.dg/vect/vect-62.c: looks like on the alias branch pre is more powerful, as it moves the load into the latch block; as a result the latch block is not empty, and we fail to vectorize (with -fno-tree-pre vectorization succeeds). Related non-empty-latch PRs that prevernt vectorization: PR28643, PR33447 -- Summary: [alias-improvements-branch] pre makes latech-block non- empty Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37698
[Bug middle-end/14192] Restrict pointers don't help
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:28 --- Only two_restrict_pointers is valid. This is a dup of PR14187. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:28 --- *** Bug 14192 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hoogerbrugge at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
--- Comment #4 from rth at gcc dot gnu dot org 2008-10-01 14:29 --- Subject: Bug 35737 Author: rth Date: Wed Oct 1 14:28:04 2008 New Revision: 140812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140812 Log: PR tree-opt/35737 * tree-complex.c (set_component_ssa_name): Don't optimize is_gimple_min_invariant values with ssa_names in abnormal phis. Added: trunk/gcc/testsuite/gcc.c-torture/compile/complex-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-complex.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
--- Comment #5 from rth at gcc dot gnu dot org 2008-10-01 14:32 --- Subject: Bug 35737 Author: rth Date: Wed Oct 1 14:30:37 2008 New Revision: 140813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140813 Log: PR tree-opt/35737 * tree-complex.c (set_component_ssa_name): Don't optimize is_gimple_min_invariant values with ssa_names in abnormal phis. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/complex-6.c - copied unchanged from r140812, trunk/gcc/testsuite/gcc.c-torture/compile/complex-6.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-complex.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug tree-optimization/37699] New: [alias-improvements-branch] can't alias ptr and local array
This happens in gcc.dg/vect/vect-96.c and gcc.dg/vect/no-vfa-vect-43.c. In the first, we can't distinguish between a write through a (local) pointer to a global array (which is a field in a struct), and a read from a local array. s a result we vectorize the loop using loop-versioning controled by a run-time aliasing test, which also means we'll use versioning instead of peeling to align a misaligned store. In the second, we can't tell that reads through a pointer (which is a function argument) do not overlap with a write to a local array. As a result we try to vectorize the loop using loop-versioning controled by a run-time aliasing test, however this testcase doe not allow that (--param vect-max-version-for-alias-checks=0), so vectorization fails. -- Summary: [alias-improvements-branch] can't alias ptr and local array Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37699
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 --- *** Bug 16306 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/16306] [4.2/4.3/4.4 Regression] restrict and copying pointers problem
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:32 --- This is effectively a dup of PR14187. We fail to track what pointers are based on a restrict pointer. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16306
[Bug tree-optimization/16913] [4.2/4.3/4.4 Regression] restrict does not make a difference
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:33 --- This is a dup of PR14187 - we simply fail to implement restrict properly. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-01 14:33 --- *** Bug 16913 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-10-01 14:34 --- *** Bug 28030 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at pdoerfler dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/28030] missed optimization with load in a loop (restrict gets lost)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 14:34 --- *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28030
[Bug tree-optimization/37700] New: [alias-improvements-branch] redundant load doesn't get eliminated
This happens in testcase gcc.dg/vect/slp-19.c: The problem is with the loop at line 17: with trunk we detect that one of the elements of array 'in' is read twice, so we generate overall 8 loads (reusing one of them). On the alias branch we do not eliminate the extra load. All the reads and write are from/to local arrays, by the way. This results in 9 loads, which the vectorizer interperts as a complicated SLP permutation, so instead it is vectorized across iterations rather than using SLP: slp-19.c:17: note: Load permutation 0 1 2 4 5 6 7 8 slp-19.c:17: note: Build SLP failed: unsupported load permutation out [D.2646_11] = D.2647_12; -- Summary: [alias-improvements-branch] redundant load doesn't get eliminated Product: gcc Version: unknown Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37700
[Bug middle-end/29239] -fno-strict-aliasing disables restrict
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- This boils down to restrict being implemented as a different alias-set instead of as points-to information. Dup of PR14187. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29239
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- *** Bug 29239 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||acahalan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- PR14187 again. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32273
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-01 14:35 --- *** Bug 32273 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||tomash dot brechko at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 14:30 --- Note that C restrict semantics make it necessary to properly track what pointer is based on what other pointer. For this we miss both annotations and a (simple) propagator that propagates this information, maybe as part of PTA analysis. Note that the current implementation has both missed-optimization and latent wrong-code issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug middle-end/33272] Compiler does not take advantage of restrict
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:38 --- The implementation detail of restrict makes the alias-oracle not work properly. Dup of PR14187 - restrict should be a PTA thing. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-10-01 14:38 --- *** Bug 33272 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-01 14:31 --- Depends on proper restrict implementation. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14187 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug tree-optimization/14187] [tree-ssa] restricted pointers should not alias on the tree level
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-10-01 14:40 --- *** Bug 33705 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||astrange at ithinksw dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug tree-optimization/33705] restrict doesn't improve char * aliasing
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 14:40 --- This is because restrict is implemented as regular alias-sets. *** This bug has been marked as a duplicate of 14187 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33705
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
--- Comment #6 from rth at gcc dot gnu dot org 2008-10-01 14:42 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug middle-end/37696] [meta-bug] PRs blocking adoption of the alias-improvements branch
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 14:54 --- Proper restrict implementation is required. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14187 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37696
[Bug middle-end/14187] [tree-ssa] C restricted pointers are not properly implemented
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-10-01 15:01 --- This is not solely a tree issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Keywords|TREE| Summary|[tree-ssa] restricted |[tree-ssa] C restricted |pointers should not alias on|pointers are not properly |the tree level |implemented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 15:09 --- 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=37285
[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-01 15:11 --- Subject: Bug 37285 Author: rguenth Date: Wed Oct 1 15:09:26 2008 New Revision: 140814 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140814 Log: 2008-10-01 Richard Guenther [EMAIL PROTECTED] PR middle-end/37285 * tree-vrp.c (execute_vrp): If we optimized away the default case make sure to promote the label that got in place of it to a default case label. * gcc.c-torture/compile/pr37285.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37285.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37285
[Bug middle-end/37154] static inline function problem
--- Comment #10 from sparky at pld-linux dot org 2008-10-01 15:29 --- In that case the bug report is incorrect. The problem lays in glibc, in function lroundl which does not save cr3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug tree-optimization/37700] [alias-improvements-branch] redundant load doesn't get eliminated
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-01 15:33 ---
Smaller testcase, FRE should remove the redundancy but doesn't.
unsigned int out[16];
unsigned int in[16];
unsigned int ia[16];
int
foo (void)
{
unsigned int i;
for (i = 0; i 16; ++i)
{
out[i] = in[i];
ia[i] = in[i];
}
}
this is because we include VOPs in the value-numbering but fail to
value-number them properly to account for non-aliased stores.
--
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 |2008-10-01 15:33:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37700
[Bug c++/37701] New: dynamic_cast to void cv* wrongly allowed with -fno-rtti
Compiled -fno-rtti, g2 and g3 are faulted but g1 is not. Code for g1
(on ARM target) shows use of RTTI which we have asserted is absent.
struct B1 { virtual int f(); };
struct B2 { virtual int g(); };
struct D: B1, B2 { };
/* These should be allowed even with -fno-rtti */
B1 *f2(B1 *p) { return dynamic_castB1 *(p); }
B1 *f3(D *p) { return dynamic_castB1 *(p); }
/* These should not be allowed with -fno-rtti */
/* gABI 2.9.4 case #1: dynamic castvoid cv*, which returns a pointer to the
complete lvalue */
void *g1(B1 *p) { return dynamic_castvoid *(p); }
/* gABI 2.9.4 case #2: dynamic cast operation from a proper base class to a
derived clasB1 */
D *g2(B1 *p) { return dynamic_castD *(p); }
/* gABI 2.9.4 case #3: dynamic_cast across the hierarchy which can be seen as a
cast to the complete lvalue and back to a sibling base */
B1 *g3(B2 *p) { return dynamic_castB1 *(p); }
--
Summary: dynamic_cast to void cv* wrongly allowed with -fno-rtti
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC target triplet: ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37701
[Bug c++/37697] dynamic_cast to void cv* wrongly allowed with -fno-rtti
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 --- *** Bug 37701 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
[Bug c++/37701] dynamic_cast to void cv* wrongly allowed with -fno-rtti
--- Comment #1 from algrant at acm dot org 2008-10-01 15:35 --- *** This bug has been marked as a duplicate of 37697 *** -- algrant at acm dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37701
[Bug bootstrap/37702] New: Stage 2- C compiler cannot create executables-recent svn
Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-cygwin-gcc... /cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/xgcc -B/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ checking for C compiler default output file name... configure: error: in `/cygdrive/c/jimdata/home/cvsroot/gcc-obj/intl': configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[2]: Leaving directory `/cygdrive/c/jimdata/home/cvsroot/gcc-obj' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/cygdrive/c/jimdata/home/cvsroot/gcc-obj' make: *** [bootstrap] Error 2 $ uname -a CYGWIN_NT-5.1 mckelvey-xp 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin [EMAIL PROTECTED] ~/cvsroot/gcc-obj $ g++ -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) [EMAIL PROTECTED] ~/cvsroot/gcc-obj $ alias CONFIGURECVS alias CONFIGURECVS='/cygdrive/c/jimdata/home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++ 21 | tee clog' [EMAIL PROTECTED] ~/cvsroot/gcc-obj $ alias BUILD alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap 21 | tee log' -- Summary: Stage 2- C compiler cannot create executables-recent svn Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: James dot W dot Mckelvey at jpl dot nasa dot gov GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn
--- Comment #1 from James dot W dot Mckelvey at jpl dot nasa dot gov 2008-10-01 16:14 --- Created an attachment (id=16443) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16443action=view) config.log from bootstrap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 --- 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=37617
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-01 16:24 --- Subject: Bug 37617 Author: rguenth Date: Wed Oct 1 16:23:23 2008 New Revision: 140816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140816 Log: 2008-10-01 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37617 * tree-ssa-pre.c (create_expression_by_pieces): During FRE do not add to the NEW_SETS. * gcc.c-torture/compile/pr37617.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37617.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #3 from aran at 100acres dot us 2008-10-01 16:30 --- Created an attachment (id=16444) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16444action=view) patch for svn trunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug testsuite/37703] New: Ada testsuites lack multilib support
As I found while testing a patch for PR ada/37681, all parts of the Ada testsuite lack proper multilib support: * ada/acats isn't multilib-aware at all (i.e. runs only for the default multilib), and * gnat.dg at least runs the tests for all multilibs, but fails to pass the proper --RTS switch (as noted by Eric Botcazou: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01998.html) -- Summary: Ada testsuites lack multilib support Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37703
[Bug c++/37697] dynamic_cast to void cv* wrongly allowed with -fno-rtti
--- Comment #2 from algrant at acm dot org 2008-10-01 16:40 --- Bug report in error. -- algrant at acm dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37697
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 --- Thanks, gcc4.4 doesn't crash anymore now. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug middle-end/37154] static inline function problem
--- Comment #11 from sparky at pld-linux dot org 2008-10-01 16:47 --- Note: glibc problem have been detected and fixed already: - bug: https://bugzilla.redhat.com/show_bug.cgi?id=450790 - fix: http://www.sourceware.org/ml/libc-hacker/2008-06/msg1.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug middle-end/37154] static inline function problem
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-10-01 17:11 --- GCC is doing the correct thing. Glibc is broken so closing as invalid as glibc has already been fixed. -- 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=37154
[Bug bootstrap/37704] New: RFE: Need specific version of --disable-multilib
As seen in PR ada/37681, lack of multilib support in a specific target library can break bootstrap. To avoid this without having to disable multilib support completely, it would be useful to have either a --disable-libada-multilib or (better yet) a generic --disable-multilib[=liba,libb]. -- Summary: RFE: Need specific version of --disable-multilib Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: bonzini at gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37704
[Bug tree-optimization/37705] New: [graphite] Fix problems with SCoPs, that contain more than one loop
Graphite calls limit_scops() to ensure, that every SCoP contains a single surrounding loop, as graphite - at the moment - is not able to handle SCoPs with two outermost loops or a bb not contained in any loop. In theory that is possible without problems, only some little bugs are in the way. So fix the bugs, remove limit_scops() and make theory reality. -- Summary: [graphite] Fix problems with SCoPs, that contain more than one loop Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: grosser at gcc dot gnu dot org ReportedBy: grosser at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37705
[Bug tree-optimization/37705] [graphite] Fix problems with SCoPs, that contain more than one loop
-- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-10-01 17:16:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37705
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-10-01 17:17 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error bonzini at gnu dot org writes: No, there is not yet an extra configure switch for that, but I'll add it. You can create a PR and assign it to me. Done: PR bootstrap/37704. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug c/37303] const compound initializers in structs are written to .data instead of .rodata
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-01 17:25 --- From C99 6.5.2.5/8: String literals, and compound literals with const-qualified types, need not designate distinct objects -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37303
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #7 from luisgpm at linux dot vnet dot ibm dot com 2008-10-01 17:44 --- I still can ICE it with the same flags in a native system. Any other info you'd like to have available? I have a more reduced source, will post it soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #6 from pdemarco at ppg dot com 2008-10-01 18:04 --- (In reply to comment #5) Sorry mate, all 3.x compilers are way past end-of-life now; there will never be another release. okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. If I could upgrade to a stable 4.x for the change... I would. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug middle-end/35809] default case label for casesi should be sliced off from last element
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-01 18:05 --- This is maybe fixed with the patch for PR37285? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35809
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #6 from jason at redhat dot com 2008-10-01 18:01 --- Subject: Re: DW_TAG_imported_module is not in its DW_TAG_lexical_block Please send patches to gcc-patches for review (and CC me) rather than attaching them to the PR. (It would be nice if a bot would notice relevant subject lines on gcc-patches and add a link to the PR like we do for checkins). I wouldn't limit the new IMPORTED_DECL to importing namespaces; as a backend tree code it should support importing other declarations as well even though C++ doesn't allow that usage. That is, the comment in tree.def and the name of IMPORTED_DECL_NS_DECL should be more general, and the assert in dwarf2out that the imported decl is a namespace should either go away or get a comment that a language that wants to use it for other types of decl should make sure it works properly. + /* Get the innermost inclosing GIMPLE_BIND that has a non NULL + BLOCK, and append an IMPORTED_DECL not to its + BLOCK_VARS chained list. */ not? --- a/gcc/cp/name-lookup.c +++ b/gcc/cp/name-lookup.c @@ -3493,11 +3493,6 @@ do_using_directive (tree name_space) if (current_namespace != global_namespace) context = current_namespace; } - - /* Emit debugging info. */ - if (!processing_template_decl) -(*debug_hooks-imported_module_or_decl) (name_space, NULL_TREE, - context, false); } Seems like this will break debug info for namespace-scope using-directives. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #7 from paolo dot carlini at oracle dot com 2008-10-01 18:17 --- (In reply to comment #6) okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x release series, and previously we had 4.2.x, and previously 4.1.x... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #8 from pdemarco at ppg dot com 2008-10-01 18:19 --- (In reply to comment #7) (In reply to comment #6) okay, but I wish that you wouldn't freeze 3.x when 4.x is still in Alpha. Alpha?!? What do you mean, exactly? Certainly we have a very stable 4.3.x release series, and previously we had 4.2.x, and previously 4.1.x... My understanding was that 4.x was not available. I'll have to re-check. sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug fortran/37706] New: ICE: Segmentation fault
When the deck below is compiled with gfortran, an ICE occurs. Gfortran version: Using built-in specs. Target: i586-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20080925 --enable-languages=c,fortran --build=i586-pc-linux-gnu --enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software Thread model: posix gcc version 4.4.0 20080925 (experimental) [trunk revision 140657] (GCC) Command line: gfortran -c nudata_error.f90 Compiler output: nudata_error.f90: In function 'nudata': nudata_error.f90:72: 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. nudata_error.f90: module libcom_C ! Module: $Source: /tmp_mnt/cpesrv/projects/scale/scale5/src/couple/RCS/libcom_C.f90,v $ ! Revision: $Revision: 1.1 $ ! Author: $Author: IanGauld $ ! Date: $Date: 2001/09/17 12:40:21 $ ! State: $State: Stab $ ! Locker: $Locker: $ !...Created by Pacific-Sierra Research 77to90 4.3E 10:07:04 12/12/00 integer :: ndset, nolib, ntype, ngrp, kout, mpctab, inpt, ir, lpu, nn1, nn2, nn3, nn4, nn5, nn6, nn7, nn8, itmax, ilmax, iamax, ifmax, izmax, nreact, nfiso, nelem, nmo, nday, nyr, nenac, nenle, nenfp, nread, mread, non, mtot, ntot, maxgp, itot character(4), dimension(20) :: titlex character(4), dimension(18) :: title character(4), dimension(10) :: basis real :: therm, res, fast, err end module libcom_C module data_C ! Module: $Source: /tmp_mnt/cpesrv/projects/scale/scale5/src/couple/RCS/data_C.f90,v $ ! Revision: $Revision: 1.1 $ ! Author: $Author: IanGauld $ ! Date: $Date: 2001/09/17 12:40:14 $ ! State: $State: Stab $ ! Locker: $Locker: $ !...Created by Pacific-Sierra Research 77to90 4.3E 10:07:07 12/12/00 integer, dimension(200) :: l integer :: l0 integer :: l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, l33, l34, l35, l36, l37, l38, l39, l40, l41, l42, l43, l44, l45, l46, l47, l48, l49, l50, l51, l52, l53, l54, l55, l56, l57, l58, l59, l60, l61, l62, l63, l64, l65, l66, l67, l68, l69, l70, l71, l72, l73, l74, l75, l76, l77, l78, l79, l80, l81, l82, l83, l84, l85, l86, l87, l88, l89, l90, l91, l92, l93, l94, l95, l96, l97, l98, l99, l100, l101, l102, l103, l104, l105, l106, l107, l108, l109, l110, l111, l112, l113, l114, l115, l116, l117, l118, l119, l120, l121, l122, l123, l124, l125, l126, l127, l128, l129, l130, l131, l132, l133, l134, l135, l136, l137, l138, l139, l140, l141, l142, l143, l144, l145, l146, l147, l148, l149, l150, l151, l152, l153, l154, l155, l156, l157, l158, l159, l160, l161, l162, l163, l164, l165, l166, l167, l168, l169, l170, l171, l172, l173, l174, l175, l176, l177, l178, l179, l180, l181, l182, l183, l184, l185, l186, l187, l188, l189, l190, l191, l192, l193, l194, l195, l196, l197, l198, l199 common /data/l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, l33, l34, l35, l36, l37, l38, l39, l40, l41, l42, l43, l44, l45, l46, l47, l48, l49, l50, l51, l52, l53, l54, l55, l56, l57, l58, l59, l60, l61, l62, l63, l64, l65, l66, l67, l68, l69, l70, l71, l72, l73, l74, l75, l76, l77, l78, l79, l80, l81, l82, l83, l84, l85, l86, l87, l88, l89, l90, l91, l92, l93, l94, l95, l96, l97, l98, l99, l100, l101, l102, l103, l104, l105, l106, l107, l108, l109, l110, l111, l112, l113, l114, l115, l116, l117, l118, l119, l120, l121, l122, l123, l124, l125, l126, l127, l128, l129, l130, l131, l132, l133, l134, l135, l136, l137, l138, l139, l140, l141, l142, l143, l144, l145, l146, l147, l148, l149, l150, l151, l152, l153, l154, l155, l156, l157, l158, l159, l160, l161, l162, l163, l164, l165, l166, l167, l168, l169, l170, l171, l172, l173, l174, l175, l176, l177, l178, l179, l180, l181, l182,
[Bug fortran/37706] ICE with use only and equivalent
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-01 20:10 --- Reduced testcase: module data_C integer, dimension(200) :: l integer ::v equivalence ( l(1), l0 ) end module data_C subroutine nudata(a, l) USE data_C, only: v integer :: l(*) end subroutine nudata -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i586-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i586-pc-linux-gnu | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-10-01 20:10:57 date|| Summary|ICE: Segmentation fault |ICE with use only and ||equivalent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 --- I can reproduce this even with a stage1 compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-10-01 20:13 --- #0 0x10195c2c in single_exit (loop=0xf7b31930) at /home/apinski/src/other/gcc/gcc/cfgloop.c:1618 #1 0x106a1208 in number_of_latch_executions (loop=0xf7b31930) at /home/apinski/src/other/gcc/gcc/tree-scalar-evolution.c:2375 #2 0x1072bc2c in canonicalize_loop_induction_variables (loop=0xf7b31930, create_iv=1 '\001', ul=UL_SINGLE_ITER, try_eval=1 '\001') at /home/apinski/src/other/gcc/gcc/tree-ssa-loop-ivcanon.c:277 #3 0x1072be84 in canonicalize_induction_variables () at /home/apinski/src/other/gcc/gcc/tree-ssa-loop-ivcanon.c:330 #4 0x1075f740 in tree_ssa_loop_ivcanon () at /home/apinski/src/other/gcc/gcc/tree-ssa-loop.c:378 #5 0x10475700 in execute_one_pass (pass=0x10ebb2c8) at /home/apinski/src/other/gcc/gcc/passes.c:1279 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-01 20:14 --- This was with: GNU C (GCC) version 4.4.0 20080929 (experimental) [trunk revision 140763] (powerpc64-unknown-linux-gnu) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug regression/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-10-01 20:23 --- If I change the GC Parameters, I get a different backtrace: #0 0x105c9abc in gsi_stmt (i=Cannot access memory at address 0x4 ) at /home/apinski/src/other/gcc/gcc/gimple.h:4392 #1 0x105dd4fc in verify_stmts () at /home/apinski/src/other/gcc/gcc/tree-cfg.c:4179 #2 0x107dec80 in verify_ssa (check_modified_stmt=1 '\001') at /home/apinski/src/other/gcc/gcc/tree-ssa.c:750 So this looks GC related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #9 from brian at dessent dot net 2008-10-01 20:25 --- Subject: Re: Spurious 'might be used uninitialized' warnings in STL headers with -O2 You are confusing the state of the Cygwin port of gcc with gcc in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug fortran/37706] ICE with use only and equivalent
--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-01 20:26 --- Confirmed, reduced code: module data_C integer, dimension(200) :: l integer :: l0 integer :: l24, l27, l28, l29 equivalence ( l(1), l0 ) end module data_C subroutine nudata(nlibe, a, l) USE data_C, only: l24, l27, l28, l29 implicit none integer :: nlibe integer :: l(*) real :: a(*) return end subroutine nudata end The ICE disappears if the line equivalence ( l(1), l0 ) is commented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug libfortran/37707] New: Namelist read of array of derived type incorrect
The following program: type s integer m integer n end type s type(s) :: a(3) character*80 :: l = ' namlis a%m=1,2, a%n=5,6, /' namelist /namlis/ a a%m=[87,88,89] a%n=[97,98,99] print*,a%m print*,a%n read(l,namlis) write(*,namlis) end prints: 87 88 89 97 98 99 At line 12 of file nl.f90 Fortran runtime error: Cannot match namelist object name 2 The error condition is bogus. According to the Fortran 2003 Standard, subclause 10.10.1.2 (third paragraph): When the name in the input record represents an array variable or a variable of derived type, the effect is as if the variable represented where expanded into a sequence of scalar list items of intrinsic data types, in the same way that formatted input/output list items are expanded. In other words: a%m has to be read in in the same way as it has to be written out. That means that the original namelist read above should assign 1 to a(1)%m and 2 to a(2)%m and nothing (i.e., not change the value of a(3)%m) and, mutatis mutandis, for a(..)%n. -- Summary: Namelist read of array of derived type incorrect Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug fortran/37706] ICE with use only and equivalent
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-01 21:24 --- The ICE also disappears if 'l' is replaced by say 'l1' in the module data_C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37706
[Bug tree-optimization/37658] [4.3 Regression] long compile times in PRE on source with lots of labels/gotos
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-01 21:32 --- Confirmed. SCC consists of: MPT.765_6816(ab) ...[5000 others snipped]... code_6815 MPT.765_6793 Danny has some speedup ideas, apart from that you can tune --parm sccvn-max-scc-size. A value of 5000 shrinks compile-time to 2.4s. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
