[Bug target/41176] [4.4/4.5 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
--- Comment #7 from jakub at gcc dot gnu dot org 2009-10-08 07:43 --- Created an attachment (id=18748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18748action=view) pr41176.i Smaller testcase for 4.4 branch. ICEs with -m64 -O1 -fschedule-insns -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
[Bug fortran/41627] mixing common and modules elicits seg fault
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-08 07:47 --- Backtrace (of comment 3) using an older GCC 4.5 (20090526): #0 0x00549453 in gfc_trans_pointer_assignment (expr1=0x12d8ea0, expr2=0x12d3b80) at /home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans-expr.c:4117 #1 0x0052b2f8 in gfc_trans_code (code=0x12d3c50) at /home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans.c:1072 #2 0x00543b45 in gfc_generate_function_code (ns=0x12d00b0) at /home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans-decl.c:4153 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41627
[Bug fortran/41629] New: [OOP] gimplification error on valid code
The following code results in a gimplication error: type t1 integer :: comp end type type(t1), target :: a class(t1) :: x pointer :: x a%comp = 3 x = a print *,x%comp end The problem here is that 'encapsulate_class_symbol' is called too early (i.e. before the symbol has acquired the pointer attribute). Solution: encapsulate_class_symbol must be called at resolution stage. -- Summary: [OOP] gimplification error on valid code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41629
[Bug middle-end/22072] bizarre code for int*int/2 for -Os
--- Comment #16 from ubizjak at gmail dot com 2009-10-08 08:17 --- Vlad, is it OK if I backport this patch to 4.4? I have tested it on 4.4 without problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22072
[Bug fortran/41627] mixing common and modules elicits seg fault
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-08 08:43 --- The use of common in the context of this PR badly hurts my understanding of commons: storage arrays computed at compile time. The standard says (f2008): 5.7.2 COMMON statement 5.7.2.1 General 1 The COMMON statement specifies blocks of physical storage, called common blocks, that can be accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global data facility based on storage association (16.5.3). 2 A common block that does not have a name is called blank common. R568 common-stmt is COMMON [ / [ common-block-name ] / ] common-block-object-list [ [ , ] / [ common-block-name ] / common-block-object-list ] ... R569 common-block-object is variable-name [ ( array-spec ) ] or proc-pointer-name C595 (R569) An array-spec in a common-block-object shall be an explicit-shape-spec-list. C596 (R569) Only one appearance of a given variable-name or proc-pointer-name is permitted in all common-block-object-lists within a scoping unit. C597 (R569) A common-block-object shall not be a dummy argument, a result variable, an allocatable variable, a derived-type object with an ultimate component that is allocatable, an automatic object, a variable with the BIND attribute, an unlimited polymorphic pointer, or a coarray. C598 (R569) If a common-block-object is of a derived type, the type shall have the BIND attribute or the SEQUENCE attribute and it shall have no default initialization. C599 (R569) A variable-name or proc-pointer-name shall not be a name made accessible by use association. 5.3.8.2 Explicit-shape array R516 explicit-shape-spec is [ lower-bound : ] upper-bound R517 lower-bound is specification-expr R518 upper-bound is specification-expr C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type definition, or interface body. 1 An explicit-shape array is an array whose shape is explicitly declared by an explicit-shape-spec-list. The rank is equal to the number of explicit-shape-specs. 2 An explicit-shape array that is a named local variable of a subprogram or BLOCK construct may have bounds that are not constant expressions. The bounds, and hence shape, are determined at entry to a procedure de ned by the subprogram, or on execution of the BLOCK statement, by evaluating the bounds' expressions. The bounds of such an array are una ected by the rede nition or unde nition of any variable during execution of the procedure or BLOCK construct. 3 The values of each lower-bound and upper-bound determine the bounds of the array along a particular dimension and hence the extent of the array in that dimension. If lower-bound appears it speci es the lower bound; otherwise the lower bound is 1. The value of a lower bound or an upper bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set of integer values between and including the lower and upper bounds, provided the upper bound is not less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the extent in that dimension is zero, and the array is of zero size. 1 1.3.10 automatic data object automatic object nondummy data object with a type parameter or array bound that depends on the value of a speci cation-expr that is not an constant expression I cannot see how real, pointer, dimension(:) :: ro can defines an explicit-shape array or a non-automatic object. So is the use of common in this PR valid or not? Note that if C595 or C597 applies, the burden is probably on the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41627
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-08 09:42 --- set::insert never invalidates iterators, so that's not a good example. set::erase invalidates iterators pointing to erased elements, but debug mode already catches that. One problem I see with this request is that when debug mode detects a problem it aborts the program. If I understand your request correctly, it would mean that programs could abort when they haven't done anything wrong, e.g. std::setint s; std::setint::iterator i = s.insert(5); s.erase(2); return *i; The erase call would have updated the mutation count so it no longer matches the iterator's mutation count, but the program is correct so why should it abort? If I've misunderstood, could you give an example of problems you want to solve? -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-08 09:43 --- (In reply to comment #1) std::setint::iterator i = s.insert(5); Oops, that should be std::setint::iterator i = s.insert(5).first; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
[Bug bootstrap/41620] [4.5 regression] Bootstrap failure
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-10-08 10:07 --- Subject: Bug 41620 Author: hubicka Date: Thu Oct 8 10:06:52 2009 New Revision: 152556 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152556 Log: PR bootstrap/41620 * ipa.c (cgraph_externally_visible_p, function_and_variable_visibility, whole_program_function_and_variable_visibility): Skip non-finalized nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41620
[Bug c++/41619] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon
--- Comment #2 from kenneth dot hoste at elis dot ugent dot be 2009-10-08 10:47 --- Created an attachment (id=18749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18749action=view) Fortran testcase Turns out the same error message occurs with SPEC CPU2000's 178.galgel, more specifically when compiling the lapak.f90 file using one of the following flag combinations: -O1 -fno-ira-share-save-slots -fcaller-saves -ffixed-form -O2 -fno-ira-share-save-slots -ffixed-form -O3 -fno-ira-share-save-slots -ffixed-form -Os -fno-ira-share-save-slots -ffixed-form A testcase reduced mainly with delta is attached. To reproduce the error, just use: gfortran -O2 -fno-ira-share-save-slots -ffixed-form testcase.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #42 from steven at gcc dot gnu dot org 2009-10-08 11:06 --- Add Matz, following comment #40. Micha, maybe you can open a separate bug report for the issues you mention in your mail (http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html) and make that new PR block this existing one? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org Last reconfirmed|2009-08-13 13:39:23 |2009-10-08 11:06:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 11:23 --- We're (slowly) working on this. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-22 23:14:03 |2009-10-08 11:23:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #43 from matz at gcc dot gnu dot org 2009-10-08 11:24 --- There already is PR31094 about this enhancement. -- matz at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31094 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-08 11:26 --- See also my mail http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html about this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64
--- Comment #6 from danglin at gcc dot gnu dot org 2009-10-08 13:10 --- Bootstrap also fails on armv5tejl-unknown-linux-gnueabi: build/gensupport.o:(.data+0x20): undefined reference to `obstack' -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
[Bug fortran/41627] mixing common and modules elicits seg fault
--- Comment #7 from dh458 at oakapple dot net 2009-10-08 13:23 --- Subject: Re: mixing common and modules elicits seg fault The use of common in the context of this PR badly hurts my understanding of commons: storage arrays computed at compile time. For better or worse, the Sun Studio 12 Update 1 compiler compiles the reduced test case without comment and executes it without complaint. Whether this particular code would ever actually be good for anything is another matter. While hacking blindly I got gfortran to core dump on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41627
[Bug target/41176] [4.4/4.5 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
--- Comment #8 from jakub at gcc dot gnu dot org 2009-10-08 13:33 --- This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3. When X is still a pseudo, this is considered valid, as lfd accept any offset, but when RA chooses to assign X to a GPR register, the address doesn't match the Y constraint in movdf_hardfloat64. Is this a bug in reload that it doesn't attempt to force the address into a register, or in target description that it should tell reload to do so somehow? Or does the backend need to be able to handle these, perhaps by forcing splitting of it? ld X,disp(Y) for (disp 3) != 0 could be splitted into addi X,Y,disp;ld X,0(X), for std X,disp(Y), (disp 3) != 0 if X != Y perhaps addi Y,Y,disp;std X,0(Y);adddi Y,Y,-disp but for std X,disp(Y) I have no idea if there are no scratch regs available. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
[Bug c/41630] New: Optimization error on vectors of uint64_t
System. Fedora 11 - Linux 2.6.30.8-64.fc11.x86_64 #1 SMP gcc-4.4.1, Release: 2.fc11 (Fedora's package) Problem in short. definitions: typedef uint64_t obj[1]; obj x0, x1, X[2]; then the following code doesn't work: X[0][0] = x0[0]; X[1][0] = x1[0]; while this works: *X[0] = *x0; *X[1] = *x1; (As far as I know these are equivalent). Problem only with -O3 and 64-bit code. Works perfectly at least with gcc34, -O2 and/or 32-bit code. Detailed information. The program gcc-bug.c compiled as gcc -Wall -O3 -o gcc-bug gcc-bug.c produce the following (wrong) output: (1) x0 = 12345 (1) x1 = 67890 (2) x0 = 12345 (2) x1 = 4195296 instead of the correct one: (1) x0 = 12345 (1) x1 = 67890 (2) x0 = 12345 (2) x1 = 67890 In attachment gcc-bug.c and gcc-bug.i, generated with -v -save-temps. -- Summary: Optimization error on vectors of uint64_t Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: emanuele dot cesena at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug c/41630] Optimization error on vectors of uint64_t
--- Comment #1 from emanuele dot cesena at gmail dot com 2009-10-08 13:50 --- Created an attachment (id=18750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18750action=view) source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug c/41630] Optimization error on vectors of uint64_t
--- Comment #2 from emanuele dot cesena at gmail dot com 2009-10-08 13:51 --- Created an attachment (id=18751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18751action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug c/41630] Optimization error on vectors of uint64_t
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-08 14:16 --- Whatever it is, doesn't happen in mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64
--- Comment #7 from hubicka at ucw dot cz 2009-10-08 14:18 ---
Subject: Re: [4.5 Regression] GCC does not bootstrap on powerpc64
Hi,
the following patch should fix the problem. I am
bootstrapping/regtesting it at x86_64-linux, but it would be nice to
know if it actually fixes the bootstrap. It does work on reduced
testcase for me.
Honza
* cgraphbuild.c (record_reference): When parameter DATA is NULL,
do not mark cgraph nodes as needed.
(record_references_in_initializer): Add new only_vars parameter.
* cgraph.h (record_references_in_initializer): New parameter.
* varasm.c (assemble_variable): Update call.
* varpool.c (varpool_analyze_pending_decls): Always look for
referenced vars.
Index: cgraphbuild.c
===
--- cgraphbuild.c (revision 152557)
+++ cgraphbuild.c (working copy)
@@ -33,13 +33,16 @@ along with GCC; see the file COPYING3.
#include tree-pass.h
/* Walk tree and record all calls and references to functions/variables.
- Called via walk_tree: TP is pointer to tree to be examined. */
+ Called via walk_tree: TP is pointer to tree to be examined.
+ When DATA is non-null, record references to callgraph.
+ */
static tree
-record_reference (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
+record_reference (tree *tp, int *walk_subtrees, void *data)
{
tree t = *tp;
tree decl;
+ bool do_callgraph = data != NULL;
switch (TREE_CODE (t))
{
@@ -57,7 +60,7 @@ record_reference (tree *tp, int *walk_su
/* Record dereferences to the functions. This makes the
functions reachable unconditionally. */
decl = TREE_OPERAND (*tp, 0);
- if (TREE_CODE (decl) == FUNCTION_DECL)
+ if (TREE_CODE (decl) == FUNCTION_DECL do_callgraph)
cgraph_mark_address_taken_node (cgraph_node (decl));
break;
@@ -218,13 +221,15 @@ struct gimple_opt_pass pass_build_cgraph
};
/* Record references to functions and other variables present in the
- initial value of DECL, a variable. */
+ initial value of DECL, a variable.
+ When ONLY_VARS is true, we mark needed only variables, not functions. */
void
-record_references_in_initializer (tree decl)
+record_references_in_initializer (tree decl, bool only_vars)
{
struct pointer_set_t *visited_nodes = pointer_set_create ();
- walk_tree (DECL_INITIAL (decl), record_reference, NULL, visited_nodes);
+ walk_tree (DECL_INITIAL (decl), record_reference,
+only_vars ? NULL : decl, visited_nodes);
pointer_set_destroy (visited_nodes);
}
Index: cgraph.h
===
--- cgraph.h(revision 152557)
+++ cgraph.h(working copy)
@@ -459,7 +459,7 @@ struct cgraph_node *cgraph_function_vers
bitmap);
void tree_function_versioning (tree, tree, VEC (ipa_replace_map_p,gc)*, bool,
bitmap);
struct cgraph_node *save_inline_function_body (struct cgraph_node *);
-void record_references_in_initializer (tree);
+void record_references_in_initializer (tree, bool);
bool cgraph_process_new_functions (void);
bool cgraph_decide_is_function_needed (struct cgraph_node *, tree);
Index: varasm.c
===
--- varasm.c(revision 152557)
+++ varasm.c(working copy)
@@ -2082,7 +2082,7 @@ assemble_variable (tree decl, int top_le
Without this, if the variable is placed in a
section-anchored block, the template will only be marked
when it's too late. */
- record_references_in_initializer (to);
+ record_references_in_initializer (to, false);
}
decl = to;
Index: varpool.c
===
--- varpool.c (revision 152557)
+++ varpool.c (working copy)
@@ -365,9 +365,9 @@ varpool_analyze_pending_decls (void)
already informed about increased alignment. */
align_variable (decl, 0);
- if (DECL_INITIAL (decl))
- record_references_in_initializer (decl);
}
+ if (DECL_INITIAL (decl))
+ record_references_in_initializer (decl, analyzed);
changed = true;
}
timevar_pop (TV_CGRAPH);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
[Bug c/41630] [4.3/4.4 Regression] Optimization error on vectors of uint64_t
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-08 14:52 ---
Simplified testcase, fails at -O1. Likely an aliasing issue, but I didn't
yet fully investigate (nor ruled out a non-conforming testcase - though
TBAA is out of the question here):
typedef unsigned long obj[1];
extern void abort (void);
static void test_level2(obj X[])
{
if (*X[0] != 12345
|| *X[1] != 67890)
abort ();
}
static void test_level1(obj x0, obj x1)
{
obj X[2];
X[0][0] = x0[0];
X[1][0] = x1[0];
if (*x0 != 12345
|| *x1 != 67890)
abort ();
test_level2 (X);
}
int main()
{
obj X[2];
*X[0] = 12345;
*X[1] = 67890;
test_level1(X[0], X[1]);
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.3.4 4.4.1
Known to work||4.2.4 4.5.0
Last reconfirmed|-00-00 00:00:00 |2009-10-08 14:52:06
date||
Summary|Optimization error on |[4.3/4.4 Regression]
|vectors of uint64_t |Optimization error on
||vectors of uint64_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug fortran/41631] New: [OOP] Support CLASS IS () in SELECT TYPE
CLASS IS() is correctly parsed but it has been disabled as the actual implementation is missing. There are two parsing test cases, which can be re-enabled when the the feature is implemented: - gcc/testsuite/gfortran.dg/select_type_2.f03 - gcc/testsuite/gfortran.dg/select_type_1.f03 Cf. also http://gcc.gnu.org/ml/fortran/2009-09/msg00286.html -- Summary: [OOP] Support CLASS IS () in SELECT TYPE Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41631
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #6 from kayhayen at gmx dot de 2009-10-08 15:02 --- Hello, is there anything else we can do to help with this bug? Yours, Kay Hayen -- kayhayen at gmx dot de changed: What|Removed |Added CC||kayhayen at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug c/41630] [4.3/4.4 Regression] Optimization error on vectors of uint64_t
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-08 15:03 ---
What we can see after inlining is
bb 2:
X[0][0] ={v} 12345;
D.1614_1 = (long unsigned int *) X[1];
*D.1614_1 ={v} 67890;
D.1614_2 = (long unsigned int *) X[1];
X.0_3 = (long unsigned int *) X;
D.1623_5 = *X.0_3;
X[0][0] ={v} D.1623_5;
D.1622_6 = *D.1614_2;
X[1][0] ={v} D.1622_6;
D.1623_7 = *X.0_3;
if (D.1623_7 != 12345)
goto bb 4;
...
bb 6:
D.1625_10 = X[0][1];
if (D.1625_10 != 67890)
goto bb 7;
else
goto bb 8;
so the final check is reading from X[0][1] but we only ever store to X[1][0].
So the testcase can be simplified to
typedef unsigned long obj[1];
extern void abort (void);
static void test_level2(obj X[])
{
if (*X[1] != 67890)
abort ();
}
int main()
{
obj X[2];
X[1][0] = 67890;
test_level2(X);
return 0;
}
or even to
typedef unsigned long obj[1];
extern void abort (void);
int main()
{
obj X[2];
X[1][0] = 67890;
if (X[0][1] != 67890)
abort ();
return 0;
}
which will also fail with 4.2.4 (but still not 4.5.0). But that also
raises the question of the validity again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug c/41630] [4.3/4.4 Regression] Optimization error on vectors of uint64_t
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-08 15:07 --- With 4.3 and 4.4 it is SRA that does not avoid generating wrong code, with 4.5 SRA optimizes the code correctly and recognizes both forms access the same memory (and thus we optimize the program to return 0). Workaround: -fno-tree-sra -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug c/41630] [4.3/4.4 Regression] Optimization error on vectors of uint64_t
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #7 from charlet at gcc dot gnu dot org 2009-10-08 15:08 --- Feel free to submit a patch. Note that middle-end warnings (such as -Wuninitialized) do not always support properly all front-end semantics, in particular for high level languages such as Ada, so I'd recommend simply removing this switch. Classifying as an enhancement btw, since this is only a warning, and warnings always produce false positives, so this is not necessarily unexpected. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2009-10-08 15:16 --- Created an attachment (id=18752) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18752action=view) Fix PR41313 with dual approach -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #18718|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*
--- Comment #41 from howarth at nitro dot med dot uc dot edu 2009-10-08 15:17 --- Posted revised patch from Comment 40 to gcc-patches... http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00519.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #7 from doko at ubuntu dot com 2009-10-08 15:17 --- With binutils from the 2.20 branch, and gcc from the 4.4 branch, including Jakub's patch, and excluding the current workaround from Ramana, I get: $ gcc -c main.c $ objdump --wide -h main.o | grep ALLOC 0 .text 001c 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0050 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0050 2**0 ALLOC $ gcc -c -g main.c $ objdump --wide -h main.o | grep ALLOC 0 .text 001c 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0050 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0050 2**0 ALLOC OpenOffice rebuilt with these tools doesn't crash anymore. See PR ld/10695 and http://qa.openoffice.org/issues/show_bug.cgi?id=105359 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #8 from ramana at gcc dot gnu dot org 2009-10-08 15:36 --- (In reply to comment #7) With binutils from the 2.20 branch, and gcc from the 4.4 branch, including Jakub's patch, and excluding the current workaround from Ramana, I get: IIUC and to make things explicit, the work-around is needed for any binutils prior to the 2.20 branch until the backport is done. If the backport is committed we should pull out my work around as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug fortran/41582] Allocation of abstract types requires a type spec or a SOURCE
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-08 15:39 --- Created an attachment (id=18753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18753action=view) Patch allocate(class) w/o source=/type-spec; plus PR 41581 interim fix (completely untested) Patch also changes the warning of allocate(...,source=class) into an error, cf. PR 41581. Patch is untested - not even by compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41582
[Bug middle-end/41573] [4.5 Regression] segfault in trunk related to strings
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 16:03 --- Subject: Bug 41573 Author: matz Date: Thu Oct 8 16:03:11 2009 New Revision: 152563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152563 Log: PR middle-end/41573 * builtins.c (fold_builtin_isascii): Use fold_build2. (fold_builtin_isdigit): Ditto. * except.c (duplicate_eh_regions_1): Tolerate NULL labels. * tree-cfg.c (struct rus_data, remove_useless_stmts_warn_notreached, remove_useless_stmts_cond, remove_useless_stmts_tf, remove_useless_stmts_tc, remove_useless_stmts_bind, remove_useless_stmts_goto, remove_useless_stmts_label, remove_useless_stmts_1, remove_useless_stmts, pass_remove_useless_stmts): Remove. * tree-pass.h (pass_remove_useless_stmts): Don't declare. * passes.c (init_optimization_passes): Don't add pass_remove_useless_stmts. * tree-eh.c (lower_eh_constructs_2): Handle empty cleanups. * tree.c (free_lang_data_in_decl): Don't clear DECL_INITIAL of static constants. * lto-symtab.c (lto_symtab_register_decl): Accepts DECL_INITIAL for static constants. * lto-streamer-out.c (output_gimple_stmt): Handle GIMPLE_NOP. * lto-streamer-in.c (input_gimple_stmt): Handle GIMPLE_NOP. testsuite/ * gcc.dg/tree-ssa/foldstring-1.c: Use fre dump. * gcc.dg/tree-ssa/useless-1.c: Use gimple dump. * gcc.dg/pr41573.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr41573.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/except.c trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/lto-symtab.c trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/foldstring-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/useless-1.c trunk/gcc/tree-cfg.c trunk/gcc/tree-eh.c trunk/gcc/tree-pass.h trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573
[Bug c++/37177] [c++0x] ICE on decltype(rel_ops::operatorint);
--- Comment #4 from jason at gcc dot gnu dot org 2009-10-08 16:09 --- Subject: Bug 37177 Author: jason Date: Thu Oct 8 16:09:22 2009 New Revision: 152564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152564 Log: PR c++/37177 * pt.c (resolve_nondeduced_context): New. * cvt.c (convert_to_void): Call it. * semantics.c (finish_decltype_type): Likewise. * typeck.c (decay_conversion): Here too. * pt.c (tsubst_decl): Don't clobber input_location. Don't register a bad specialization. Added: trunk/gcc/testsuite/g++.dg/template/explicit-args2.C trunk/gcc/testsuite/g++.dg/template/explicit-args3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/variadic-throw.C trunk/gcc/testsuite/g++.old-deja/g++.pt/crash58.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37177
[Bug c++/36816] [c++0x] error deducing template argument taking the address of rvalue reference template
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-08 16:09 --- Subject: Bug 36816 Author: jason Date: Thu Oct 8 16:09:31 2009 New Revision: 152565 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152565 Log: PR c++/36816 * pt.c (maybe_adjust_types_for_deduction): Do rvalue ref adjustment even when DEDUCE_EXACT. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-deduce.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36816
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #3 from mrs at gcc dot gnu dot org 2009-10-08 16:36 --- These two look ok to me. The testsuite should be glanced at by Janis to double check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #4 from mrs at gcc dot gnu dot org 2009-10-08 16:44 --- Oh, if one wanted to, one could have libgcc_s forward the EH calls into /usr/lib/libgcc_s.1.dylib by dlopening it and then doing dlsym on the symbols and calling them. This would `fix' the programs that linked against a gcc libgcc_s file that uses EH when run on a system that has EH on the system. With that technology, I think all the mismatching here, just goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug ada/39502] Unexpected uninitialized warning
--- Comment #8 from manu at gcc dot gnu dot org 2009-10-08 17:39 --- The output of -fdump-tree-optimized-all-lineno and -fdump-tree-ssa-all-lineno with and without -fPIC would be interesting. Also, GCC 4.4 and 4.5 fixed a lot of false positives in Wuninitialized, so please try with at least GCC 4.4.1. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org OtherBugsDependingO||24639 nThis|| Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39502
[Bug c++/36816] [c++0x] error deducing template argument taking the address of rvalue reference template
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-08 17:48 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36816
[Bug c++/37177] [c++0x] ICE on decltype(rel_ops::operatorint);
--- Comment #5 from jason at gcc dot gnu dot org 2009-10-08 17:48 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37177
[Bug c++/37204] [c++0x] reinterpret_castT(v) incorrectly yields an lvalue
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-08 17:50:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37204
[Bug preprocessor/41632] New: The preprocessor incorrectly reports #ident as being deprecated
See http://gcc.gnu.org/ml/gcc/2009-10/msg00071.html -- Summary: The preprocessor incorrectly reports #ident as being deprecated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nvachhar at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41632
[Bug c++/41570] [4.5 Regression] [c++0x] ICE with -g and variadic templates
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-10-04 18:24:39 |2009-10-08 17:54:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41570
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #9 from espindola at google dot com 2009-10-08 18:20 --- (In reply to comment #8) Raphael, can you look into this? Sure. Sorry about the delay. The only thing the compiler should need the plugin-api.h for is the enum ld_plugin_symbol_resolution. If we split plugin-api.h in two, we would be able to compile gcc itself without stdint.h. The problem with this approach is that the lto plugin would still fail to build in a system without stdint.h. Is it OK to have optional features like the gold plugin not supported in systems like Tru64 UNIX V4.0F? Yet another possibility would be to change the build system so that we always build the lto plugin with xgcc (in addition to the plugin-api.h split). No idea how hard this is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug target/41176] [4.4/4.5 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
--- Comment #9 from uweigand at gcc dot gnu dot org 2009-10-08 18:39 --- (In reply to comment #8) This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3. When X is still a pseudo, this is considered valid, as lfd accept any offset, but when RA chooses to assign X to a GPR register, the address doesn't match the Y constraint in movdf_hardfloat64. Is this a bug in reload that it doesn't attempt to force the address into a register, or in target description that it should tell reload to do so somehow? Or does the backend need to be able to handle these, perhaps by forcing splitting of it? If reload were fixing up this insn, it would indeed have to make sure that the Y - r constraints are respected, e.g. by reloading the address. However, this whole insn is *generated* by reload, in order to load a value into a reload register. Unfortunately, for such reload insns (which are simple moves), reload will simply assume they must be supported by the target, unless there is a secondary reload for this case. To fix this, I guess the rs6000 backend either has to accept the insn and implement it via splitting, or else register a secondary reload for this case (which is also able to request scratch registers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
[Bug c/41633] New: -Wframe-larger-than should warn about outgoing function calls, specifically varargs
gcc should warn when the stack frame for a called varargs function is in excess of a -Wframe-larger-than=NNN bytes. Such a check could be done at each call site, to see whether the outgoing arguments alone already exhaust NNN. -- Summary: -Wframe-larger-than should warn about outgoing function calls, specifically varargs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41633
[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64
--- Comment #8 from meissner at gcc dot gnu dot org 2009-10-08 18:59 --- Created an attachment (id=18754) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18754action=view) Patch that fixes the powerpc bootstrap problem. This is the patch that I checked in that came from Jan Hubicka. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
[Bug middle-end/41626] [4.5 Regression] GCC does not bootstrap on powerpc64
--- Comment #9 from meissner at gcc dot gnu dot org 2009-10-08 19:00 --- Patch checked into mainline, subversion id 152569. -- meissner at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #16 from rwild at gcc dot gnu dot org 2009-10-08 19:06 --- Created an attachment (id=18755) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755action=view) (hopefully) better patch Gah. Initial white space isn't stripped from the case argument, I should've known. Can you try this patch instead? Thanks, Ralf -- rwild at gcc dot gnu dot org changed: What|Removed |Added Attachment #18629|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug debug/41353] VTA missed-debug issues
--- Comment #17 from aoliva at gcc dot gnu dot org 2009-10-08 19:20 --- Subject: Bug 41353 Author: aoliva Date: Thu Oct 8 19:20:22 2009 New Revision: 152573 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152573 Log: PR debug/41353 * regmove.c (regmove_backward_pass): Replace src with dst in the debug insn, and check for dst before rather than after. Modified: trunk/gcc/ChangeLog trunk/gcc/regmove.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug debug/41353] VTA missed-debug issues
--- Comment #18 from aoliva at gcc dot gnu dot org 2009-10-08 19:22 --- All fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #17 from davek at gcc dot gnu dot org 2009-10-08 19:37 --- (In reply to comment #16) Created an attachment (id=18755) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755action=view) [edit] (hopefully) better patch Gah. Initial white space isn't stripped from the case argument, I should've known. Can you try this patch instead? ESAMEPATCH! http://gcc.gnu.org/bugzilla/attachment.cgi?id=18629action=view commit 33c578ca6b47a47ecacae017e45fd796022dadc4 http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755action=view commit 33c578ca6b47a47ecacae017e45fd796022dadc4 Will wait for you to dig up the correct one, I'm liable to get it wrong if I try and come up with a properly portable way of stripping whitespace :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libstdc++/41622] [c++0x] std::hashstd::string::operator() copies its argument
--- Comment #5 from jbytheway at gmail dot com 2009-10-08 19:40 --- Ah well. I'm not surprised. If you do wish to argue the point at Santa Cruz and I can be any help then let me know. I have no particular intention to contribute; I'm just working through my backlog of bug reports (this one started out as a bug report and even after I realised it wasn't a bug I thought I might as well tell you anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41622
[Bug libstdc++/41622] [c++0x] std::hashstd::string::operator() copies its argument
--- Comment #6 from paolo dot carlini at oracle dot com 2009-10-08 19:54 --- (In reply to comment #5) I have no particular intention to contribute; Too bad, I hope you want to reconsider this decision. In case, however, please don't attach patches, because we can't and we don't want to plagiarize your code and we can't either commit it as-is without a Copyright Assignment on file (unless the whole patch is, say, below 10 lines) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41622
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #18 from rwild at gcc dot gnu dot org 2009-10-08 19:57 --- Created an attachment (id=18756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18756action=view) ditto, but without the d'oh factor That's what you get when you name one pr-41418 and the other pr41418. Sorry about that -- rwild at gcc dot gnu dot org changed: What|Removed |Added Attachment #18755|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug fortran/41579] [OOP/Polymorphism] Nesting of SELECT TYPE
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-08 20:27 --- Mine (have a patch). -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-08 20:27:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41579
[Bug lto/41529] [4.5 Regression] LTO configuration should detect if the target is ELF
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-08 21:26 --- I installed libelf on a i386-darwin machine at /usr/local so I could build a cross compiler to spu-elf and test LTO on my laptop. And now a native build of GCC picks up libelf and we get: checking for the correct version of libelf... yes The following languages will be built: c,lto,c++,fortran,java,objc So this is a regression. I will report how it fails later on. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|LTO configuration should|[4.5 Regression] LTO |detect if the target is ELF |configuration should detect ||if the target is ELF Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
[Bug debug/41616] Variables promoted to Gimple registers by aliasing are not getting debug statements.
--- Comment #2 from aoliva at gcc dot gnu dot org 2009-10-08 21:34 --- Yup, ADDR_EXPRs don't count as dereferences in debug stmts, but if the variable doesn't get a memory location, we end up dropping the whole expression. We have to. Finding another location holding the value of b isn't enough if the relevant value is the address of b. Since b did not get a memory location, its address is non-existent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41616
[Bug lto/41554] -flto and -fwhopr should be moved to common.opt
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-10-08 21:36 --- Likewise, -Wabi and -Wpsabi belong on common.opt, and the post_options processing belongs in common code not in individual front ends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41554
[Bug c/41634] New: segfault in trunk
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O3 -fno-builtin file.i file.i: In function 'test_readmode': file.i:4:6: 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: segfault in trunk Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i586-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41634
[Bug c/41634] segfault in trunk
--- Comment #1 from marcus at jet dot franken dot de 2009-10-08 21:43 --- Created an attachment (id=18757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18757action=view) file.i /home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O3 -fno-builtin file.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41634
[Bug tree-optimization/41634] [4.5 Regression] ICE in dom
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-10-08 21:46 --- #0 0x00cb8976 in htab_remove_elt_with_hash (htab=0x43b0dd20, element=0xb2e4, hash=2085838349) at /Users/apinski/src/change/gcc/libiberty/hashtab.c:706 #1 0x00672a4e in remove_local_expressions_from_table () at /Users/apinski/src/change/gcc/gcc/tree-ssa-dom.c:836 #2 0x0067702b in dom_opt_leave_block (walk_data=0xb468, bb=0x43cfc740) at /Users/apinski/src/change/gcc/gcc/tree-ssa-dom.c:1763 #3 0x00bb6c26 in walk_dominator_tree (walk_data=0xb468, bb=0x43cfc740) at /Users/apinski/src/change/gcc/gcc/domwalk.c:205 #4 0x00671d45 in tree_ssa_dominator_optimize () at /Users/apinski/src/change/gcc/gcc/tree-ssa-dom.c:651 Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i586-unknown-linux-gnu |i?86-*-* Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-10-08 21:46:36 date|| Summary|segfault in trunk |[4.5 Regression] ICE in dom Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41634
[Bug tree-optimization/41634] [4.5 Regression] ICE in dom
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-08 21:49 --- This appeared between revision 152380 and 152576. The only patch which touched dom during that time was: +2009-10-05 Richard Guenther rguent...@suse.de + + PR tree-optimization/23821 + * tree-vrp.c (vrp_finalize): Do not perform copy propagation. + * tree-ssa-dom.c (cprop_operand): Do not propagate copies into + simple IV increments. But that does not mean it was caused by that patch though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41634
[Bug lto/41635] New: inappropriate assertion that fopen succeeds
As noted in my review of the LTO front end, resolution = fopen (resolution_file_name, r); gcc_assert (resolution != NULL); is not an appropriate use of an assertion because the fopen could fail through system resource exhaustion even if you know the file exists and is readable and has proper contents. A normal error or fatal error needs to be given instead. -- Summary: inappropriate assertion that fopen succeeds Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41635
[Bug lto/41636] New: lto-elf.c i18n problems
The macros in lto-elf.c with diagnostics fatal_error (elf#BITS_getshdr() failed: %s, elf_errmsg (-1));\ fatal_error (elf#BITS_newehdr() failed: %s, elf_errmsg (-1));\ are not i18n-friendly; only the elf bit gets extracted for translation to gcc.pot. The code should explicitly say something like if (BITS == 32) fatal_error (...); else fatal_error (...); so that both messages are explicitly in the source and can be extracted for gcc.pot and translated. -- Summary: lto-elf.c i18n problems Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org OtherBugsDependingO 40883 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41636
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.
--- Comment #7 from dougkwan at gcc dot gnu dot org 2009-10-08 22:17 --- Subject: Bug 41574 Author: dougkwan Date: Thu Oct 8 22:16:58 2009 New Revision: 152580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152580 Log: 2009-10-08 Doug Kwan dougk...@google.com PR rtl-optimization/41574 * gcc.dg/pr41574.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr41574.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.
--- Comment #8 from dougkwan at google dot com 2009-10-08 22:20 --- This is fixed in trunk but at least gcc-4.4.0, where this bug was found, is still broken. -- dougkwan at google dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.4.0 Resolution|FIXED | Version|4.5.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug c/41045] Extended asm with C operands doesn�t work at top level
--- Comment #2 from nelhage at mit dot edu 2009-10-08 22:20 --- For an example of real code that wanted to use toplevel inline ASM, see the following recent Linux commit: http://git.kernel.org/linus/796216a57fe45c04adc35bda1f0782efec78a713 Lack of this feature necessitated a fairly hideous (IMO) workaround, and a multi-paragraph documentation of it in the commit messages. Note that while (as stated in the commit message) an unrelated GCC issue originally caused the desire to use inline assembly, a later commit (0b1c723d0bd199300a1a2de57a46000d17577498) takes advantage of the fact that this block uses inline assembly, and so they really do want a toplevel assembly block here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
[Bug c/41045] Extended asm with C operands doesn�t work at top level
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-08 22:28 --- So they want a way to turn off progbits instead? That seems better than doing extended inline-asm at the top level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
[Bug c/41045] Extended asm with C operands doesn�t work at top level
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-08 22:32 --- (In reply to comment #3) So they want a way to turn off progbits instead? That seems better than doing extended inline-asm at the top level. And is less messy really since then the syntax would be something like: #define RESERVE_BRK(name,sz) \ static char __brk_reservation_#name[sz] __attribute__((section(brk_reservation, nobits), used); Which gets rid of the messy inline-asm and makes things look like a real variable, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-10-08 23:06 --- I ran into this again, this time on powerpc-linux-gnu when I forgot to include -maltivec on the link line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41565
[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-08 23:08 --- Oh -maltivec is even weirder than -m32 as it does not change the ABI (well it does but not with respect non vector arguments and such) but I should be able to compile some files with -maltivec and some without. Note the -maltivec case shows up in real code already. Think mpeg players. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41565
[Bug driver/41637] New: testsuite (-flto/-fwrop) leaves crap in /tmp
Just looking into /tmp after a testsuite runs there are a lot of files there. cc0FIKlt.errccceY3TE.err cciZMsdN.o.063t.alias ccqFjO6o.errccy5TZdA.out cc0hiz3p.wpa.o ccCFYtDM.wpa.o.063t.alias ccj4ba9L.out ccqfuPHN.o.063t.alias ccy7ECNJ.out cc0hKTzD.errccCG7VOZ.lto.o ccjdsNY9.wpa.o.064t.alias ccQkrpZG.args ccy9sdwM.err cc0k5wqP.outccCgeHHu.errccJEfXym.lto.o ccqouheB.o.064t.alias ccyAqAAM.o.063t.alias cc0Ozqm1.o.063t.alias ccCHoca3.outccJGczq7.out ccQouyAC.wpa.o.063t.alias ccyaxNXz.err cc0Phjpr.wpa.o.063t.alias cccK5VB6.out ccjgNZW8.wpa.o.063t.alias ccQozpxk.wpa.o ccyBmPPE.out cc1iVMRd.lto.o ccckjtgo.o.063t.alias ccJjqEQP.lto.o ccqPmK7z.outccydQI8s.o.063t.alias cc1xHp8y.outccclqqey.le ccjKAC6a.ltrans.out ccqq6YWh.wpa.o.064t.alias ccyFQagL.out cc22yyVE.o.064t.alias cccMEAnN.o.064t.alias ccjkFKpm.o.063t.alias ccQqd0Yv.wpa.o.063t.alias ccyggdbc.wpa.o.063t.alias cc2DRkCf.outcccmSh1b.c ccjo0gmo.wpa.o.064t.alias ccQshPjf.lto.o ccyiHfNi.o.063t.alias cc2gdrl2.ltrans.out cccmVw1b.out ccjOy4nj.o.063t.alias ccQSN6LV.outccYjSSG0.out cc2p3Tcf.args ccCNucKD.out ccjQMr9a.ltrans.out ccqUFGHe.outccYLXAnn.lto.o cc2QYfVs.s cccOj91a.outccJT4LeX.ld ccqvg7qW.ltrans.out ccYPAEzh.le cc2tmqG6.args ccCPi3tX.args ccJZuONo.o.063t.alias ccQvU1p5.lto.o ccyPdZoe.lto.o cc2WeO2S.lto.o ccCrjXda.args cck7i7Q2.s ccqzAyLd.args ccYPLCku.out cc2zotJQ.o.063t.alias ccCRmXl1.errcck7SKUV.args ccre6xGt.wpa.o.063t.alias ccYQJku1.wpa.o.063t.alias Some of them come from bug 41564 but others I don't know where they come from. -- Summary: testsuite (-flto/-fwrop) leaves crap in /tmp Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41637
[Bug lto/41638] New: Back-end builtins are mishandled
lto_get_builtin_tree uses built_in_decls but that is only for the built_in_class of BUILT_IN_NORMAL. The back-ends have their own array with the builtins in them for the class of BUILT_IN_MD. So currently we translate all of the back-end builtins into normal builtins. This is why gcc.dg/vmx/3a-03.c currently fails; Most likely all of the vmx testsuite in fact. In that example __builtin_altivec_vrefp is changed when reading back the file into __builtin_lgammal. -- Summary: Back-end builtins are mishandled Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code, ice-on-valid-code, link-failure Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41638
[Bug lto/41638] Back-end builtins are mishandled
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-08 23:48 --- Note the back-end builtin arrays don't have the same name so it is not as simple as using that array. I think we need to add either a target hook or have a standard name for them. Also the assert there for END_BUILTINS is also incorrect for BUILT_IN_MD as there could be more target builtins than there are normal builtins. Which means the use of enum built_in_function is incorrect for function_code and could break when we compile with the C++ front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41638
