[Bug c/32399] ICE in build2_stat, at tree.c:3074
--- Comment #1 from marcus at jet dot franken dot de 2007-06-19 06:24 --- Created an attachment (id=13734) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13734action=view) vertexbuffer.i gcc -O2 -c vertexbuffer.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug c/32399] New: ICE in build2_stat, at tree.c:3074
new regression, likely caused by pointer-plus branch merge extracted from Wine /home/marcus/projects/gcc/BIN/bin/gcc -m32 -O2 -c vertexbuffer.i vertexbuffer.i: In function 'f': vertexbuffer.i:1: internal compiler error: in build2_stat, at tree.c:3074 -- Summary: ICE in build2_stat, at tree.c:3074 Product: gcc Version: 4.3.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: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #4 from tbm at cyrius dot com 2007-06-19 06:39 --- (In reply to comment #3) I tested the patch on IA64 HP-UX and Linux and verified that it fixed the bug and caused no regressions. Jim, do you want to check this patch in? Given that Jim hasn't answered yet, maybe you can commit the patch yourself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug c++/32368] warnings from system headers not supressed.
--- Comment #3 from pluto at agmk dot net 2007-06-19 06:44 --- (In reply to comment #2) At variance with c++/32256, this one apparently happens as C code too... Probably should be not categorized as C++-only... these little bugs (PR32368, PR32256) are treated as blockers by people having `-Wall -Werror` in theirs projects. could we fix this issue easily and quickly in 4.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32368
[Bug c/21920] aliasing violations
--- Comment #115 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- *** Bug 32397 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rosenfeld at grumpf dot ||hope-2000 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/32397] wrong instruction order generated
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- ((Cyg_libm_ieee_double_shape_type *)x)-part is ovbiously an aliasing violation. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:10 --- This is caused by two things, jump threading and inlining. If we jump thread more, we no longer get the warning which is what you are seeing in 4.2.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug middle-end/32399] ICE in build2_stat, at tree.c:3074
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-19 08:21 --- This is IV-opts going funny I think as we get pointer+pointer (and yes real pointer SSA_NAMES and no casts). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-19 08:26 ---
This code itself is very weird and I don't know if it is really defined or not.
We have basically:
char *f(char *a, char *b)
{
return a + (int)b;
}
How can that even be defined.
Anyways the following fixes the problem:
Index: tree-ssa-address.c
===
--- tree-ssa-address.c (revision 125776)
+++ tree-ssa-address.c (working copy)
@@ -423,9 +423,9 @@
/* Add ELT to base. */
type = TREE_TYPE (parts-base);
- parts-base = fold_build2 (PLUS_EXPR, type,
+ parts-base = fold_build2 (POINTER_PLUS_EXPR, type,
parts-base,
-fold_convert (type, elt));
+fold_convert (sizetype, elt));
}
/* Finds the most expensive multiplication in ADDR that can be
Though I have not tested it at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-06-19 08:26:50
date||
Summary|ICE in build2_stat, at |[4.3 Regression] ICE in
|tree.c:3074 |build2_stat, at tree.c:3074
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #97 from pinskia at gcc dot gnu dot org 2007-06-19 08:11 --- *** Bug 32391 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sunjoong at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-19 08:11 --- So this is just a dup of bug 323 so closing as such. *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #5 from ubizjak at gmail dot com 2007-06-19 08:27 ---
(In reply to comment #4)
No, this one is caused by dataflow.
Dataflow uncovered generic middle-end (RTL?) problem:
We have this comment in instantiate_virutal_regs():
/* Scan through all the insns, instantiating every virtual register still
present. */
for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
/* These patterns in the instruction stream can never be recognized.
Fortunately, they shouldn't contain virtual registers either. */
if (GET_CODE (PATTERN (insn)) == USE
|| GET_CODE (PATTERN (insn)) == CLOBBER
|| GET_CODE (PATTERN (insn)) == ADDR_VEC
|| GET_CODE (PATTERN (insn)) == ADDR_DIFF_VEC
|| GET_CODE (PATTERN (insn)) == ASM_INPUT)
continue;
instantiate_virtual_regs_in_insn (insn);
However, for reduced testcase we generate following creative sequence to put
*.LC0 into virtual-outgoing-args and 0 into virtual-outgoing-args+8 (these are
sections[0] values):
;; f (stderr, [0], [0], conf_name, 0, sections[0])
(insn 6 5 7 pr32374.c:13 (clobber (mem/s/c:BLK (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -16 [0xfff0])) [5 A128])) -1 (nil))
(insn 7 6 8 pr32374.c:13 (set (mem/s/c:DI (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -16 [0xfff0])) [4 S8 A128])
(symbol_ref/f:DI (*.LC0) [flags 0x2] string_cst 0xb7cf1498)) -1
(nil))
(insn 8 7 9 pr32374.c:13 (set (mem/s/c:SI (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -8 [0xfff8])) [3 S4 A64])
(const_int 0 [0x0])) -1 (nil))
(insn 9 8 10 pr32374.c:13 (set (reg:DI 59)
(mem/s/c:DI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [5 S8 A128])) -1 (nil))
(insn 10 9 11 pr32374.c:13 (set (mem:DI (reg/f:DI 56 virtual-outgoing-args) [0
S8 A64])
(reg:DI 59)) -1 (nil))
(insn 11 10 12 pr32374.c:13 (set (reg:DI 60)
(mem/s/c:DI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -8 [0xfff8])) [5 S8 A64])) -1 (nil))
(insn 12 11 13 pr32374.c:13 (set (mem:DI (plus:DI (reg/f:DI 56
virtual-outgoing-args)
(const_int 8 [0x8])) [0 S8 A64])
(reg:DI 60)) -1 (nil))
Putting a break on emit_insn_raw, we can backtrack where (invalid!) clobber is
generated:
#0 make_insn_raw (pattern=0xb7d0ad00) at
../../gcc-svn/trunk/gcc/emit-rtl.c:3312
#1 0x081861c2 in emit_insn (x=0xb7d0ad00) at
../../gcc-svn/trunk/gcc/emit-rtl.c:4347
#2 0x081a9821 in store_constructor (exp=0xb7d63dc8, target=0xb7d4f768,
cleared=0, size=16) at ../../gcc-svn/trunk/gcc/expr.c:5066
#3 0x081aee5b in expand_expr_real_1 (exp=0x11, target=0xb7d4f768,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:7310
#4 0x081bf7cc in expand_expr_real (exp=0xb7d63dc8, target=0xb7d4f6f0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:6862
#5 0x081bf9b6 in expand_expr (exp=0x11, target=0xb7d0ad00, mode=VOIDmode,
modifier=EXPAND_STACK_PARM) at ../../gcc-svn/trunk/gcc/expr.h:504
#6 0x081bd4c4 in expand_expr_real_1 (exp=0xb7ca3058, target=0xb7d4f6f0,
tmode=dwarf2_read_address: Corrupted DWARF expression.
) at ../../gcc-svn/trunk/gcc/expr.c:7455
#7 0x081bf7cc in expand_expr_real (exp=0xb7ca3058, target=0xb7d4f6f0,
tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:6862
#8 0x08115bd1 in store_one_arg (arg=0xbf96e8f0, argblock=0xb7c9c070, flags=0,
variable_size=0, reg_parm_stack_space=0) at ../../gcc-svn/trunk/gcc/expr.h:504
#9 0x0811ad60 in expand_call (exp=0xb7d5a240, target=0x0, ignore=1) at
../../gcc-svn/trunk/gcc/calls.c:2654
It can be tracked from expand_call() down to expr.c:7303, where we re-assign
target to virtual-stack-vars in this highly suspicious part of code (Irix 6?):
else
{
/* Handle calls that pass values in multiple non-contiguous
locations. The Irix 6 ABI has examples of this. */
if (target == 0 || ! safe_from_p (target, exp, 1)
|| GET_CODE (target) == PARALLEL
|| modifier == EXPAND_STACK_PARM)
target
= assign_temp (build_qualified_type (type,
(TYPE_QUALS (type)
| (TREE_READONLY (exp)
* TYPE_QUAL_CONST))),
0, TREE_ADDRESSABLE (exp), 1);
store_constructor (exp, target, 0, int_expr_size (exp));
return target;
}
Just before the call to store_constructor, we have:
p debug_rtx (target)
(mem/s/c:BLK (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [5 A128])
and in
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #6 from ubizjak at gmail dot com 2007-06-19 08:58 --- FWIW, this shoot-in-the-dark patch fixes ICE: Index: expr.c === --- expr.c (revision 125789) +++ expr.c (working copy) @@ -5062,8 +5062,10 @@ store_constructor (tree exp, rtx target, cleared = 1; } +#if 0 if (! cleared) emit_insn (gen_rtx_CLOBBER (VOIDmode, target)); +#endif /* Store each element of the constructor into the corresponding field of TARGET. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-19 09:08 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:08:39 2007 New Revision: 125841 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125841 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/nrv13.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-19 09:11 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:11:22 2007 New Revision: 125842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125842 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/nrv13.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug target/32392] Support using -mrecip w/o additional Newton-Raphson run
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-19 09:15 --- Confirmed. For 2 NR steps to reach double precision (we'd miss it by some more ulps than the 2.5 for float precision) we would need to do at least the second NR in double precision. Note that this would make sense only for double precision input values that are exactly representable in float precision (otherwise, why the extra precision?). So practically not worth it. -- 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 Last reconfirmed|-00-00 00:00:00 |2007-06-19 09:15:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32392
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-19 09:17 --- The testcase indeed looks undefined (but valid). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-19 09:18 --- Subject: Bug 32353 Author: jakub Date: Tue Jun 19 09:18:13 2007 New Revision: 125843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125843 Log: PR tree-optimization/32353 * tree-ssa-structalias.c (set_uids_in_ptset): Also handle RESULT_DECL. * g++.dg/opt/nrv13.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/nrv13.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-19 09:19 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32353
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #43 from rguenth at gcc dot gnu dot org 2007-06-19 09:24 --- Subject: Bug 30252 Author: rguenth Date: Tue Jun 19 09:24:35 2007 New Revision: 125844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125844 Log: 2007-06-19 Richard Guenther [EMAIL PROTECTED] Michael Matz [EMAIL PROTECTED] PR tree-optimization/30252 * tree-ssa-structalias.c (solution_set_add): Make sure to preserve all relevant vars. (handle_ptr_arith): Make sure to only handle positive offsets. (push_fields_onto_fieldstack): Create fields for empty bases. * g++.dg/opt/pr30252.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/pr30252.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug target/31152] -(xy) generates wrong code
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-06-19 09:41 --- Confirmed. This is a bug in the negscc pattern in arm.md. It's only been there since 1994! -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-19 09:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #44 from rguenth at gcc dot gnu dot org 2007-06-19 09:45 --- Fixed on the 4.2 branch. Danny will fix this in a different way on the trunk. -- 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=30252
[Bug c/32397] wrong instruction order generated
--- Comment #2 from rosenfeld at grumpf dot hope-2000 dot org 2007-06-19 10:52 --- Subject: Re: wrong instruction order generated On Tue, Jun 19, 2007 at 07:56:01AM -, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 07:56 --- ((Cyg_libm_ieee_double_shape_type *)x)-part is ovbiously an aliasing violation. I doubt that. As you can see in the source file, x is a double and Cyg_libm_ieee_double_shape_type is a union containing a double. To quote the standard, 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types: a type compatible with the effective type of the object, [...] an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union) [...] So as far as I understand this should be perfectly legal by the ISO C standard. Maybe I'm missing somthing here, I read everywhere that using a union for this kind of thing is a gcc extension. I wonder, if there is no standard way to manipulate doubles by treating them as ints or bitfields or something like that, how is one supposed to write a floating point emulator in ISO C? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-19 11:16 --- Subject: Bug 31950 Author: rguenth Date: Tue Jun 19 11:16:43 2007 New Revision: 125846 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125846 Log: 2007-06-19 Richard Guenther [EMAIL PROTECTED] PR middle-end/31950 * tree-ssa-alias-warnings.c (ffan_walker): Punt on MTAGs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias-warnings.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-19 11:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug c/32397] wrong instruction order generated
--- Comment #3 from rask at sygehus dot dk 2007-06-19 11:27 --- You can use memcpy (int, float, min (sizeof (int), sizeof (float))) and vice versa. I suppose you can also memcpy() into or out of a char array of the right size. If you were to use the GCC extension of using a union, it would look something like this: double x; cyg_uint32 hx, lx; Cyg_libm_ieee_double_shape_type tmp; tmp.value = x; hx = tmp.parts.msw lx = tmp.parts.lsw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32397
[Bug middle-end/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #7 from ubizjak at gmail dot com 2007-06-19 11:54 --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug c++/32400] New: [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
svn snapshot from r125847 -- Summary: [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #1 from jojelino at gmail dot com 2007-06-19 12:10 --- Created an attachment (id=13735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13735action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #10 from dominiq at lps dot ens dot fr 2007-06-19 12:48 --- Even the code in comment #8 is invalid: several variables are used but not set: at least intp and sum. If I set them to 0, gfortran gives the same results with or without -O3. (tests done on PPC Darwin7). In my opinion the bug is invalid, but I'll let others make the final call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32401] New: [PPC/Altivec] Non optimal code structure with -mabi=altivec
With altivec enabled gcc prepares additional space on the stack. Unlike earlier
versions gcc 4.3 removes stack modification instructions if it isn't used. With
just -maltivec or with -mabi=altivec when altivec isn't used it works very
well. But with -mabi=altivec and altivec used gcc produces code with stucture
similar to one produced by eariler gcc versions with just stack modification
instructions removed. Seems like stack isn't optimized early enough.
This simple code:
void
test ( int len )
{
if (len) {
vector unsigned char vSetTo = {};
asm volatile ( : : v (vSetTo) ); /* do something */
}
}
gcc-4.3 -O2 -maltivec -mregnames test.c -S produces:
test:
cmpwi %cr7,%r3,0
beqlr- %cr7
vxor %v0,%v0,%v0
blr
while gcc-4.3 -O2 -maltivec -mabi=altivec -mregnames test.c -S produces:
test:
cmpwi %cr7,%r3,0
beq- %cr7,.L3 # -- should be beqlr
vxor %v0,%v0,%v0
.L3:
blr
The letter one has same structure as produced by earlier gcc versions, but
without stack modification instructions:
gcc 4.1.3 produces:
test:
cmpwi %cr7,%r3,0
stwu %r1,-16(%r1)
vxor %v0,%v0,%v0
beq- %cr7,.L4
.L4:
addi %r1,%r1,16
blr
--
Summary: [PPC/Altivec] Non optimal code structure with -
mabi=altivec
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sparky at pld-linux dot org
GCC build triplet: powerpc*-linux
GCC host triplet: powerpc*-linux
GCC target triplet: powerpc*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32401
[Bug c++/32402] New: Error while allocating array of pointers to objects of a pure virtual class
The compiler thinks we're allocating the actual abstract objects instead of an
array of pointers and reports the following error: cannot allocate an object
of abstract type '...'. Since we're actual allocating an array of pointers,
this should not be an error.
The following code (reproduce.cpp) demonstrates the problem:
class pure
{
public:
pure() {}
virtual bool isPure () = 0;
};
class notPure : public pure
{
public:
notPure() {}
virtual bool isPure () { return false; };
};
int main ()
{
pure ** list;
list = new (pure (*[3]));
for (int i = 0; i 3; i ++) {
list [i] = new notPure();
}
}
The error is reported on line 18 list = new (pure (*[3]));.
gcc -v results in:
Using built-in specs.
Target: i686-linux
Configured with: ../gcc-4.1.1/configure
--prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--target=i686-linux --build=i686-pc-mingw32 --host=i686-pc-mingw32
--disable-multilib
--with-local-prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--with-system-zlib --disable-libunwind-exceptions --disable-nls --enable-shared
--enable-languages=c,c++ --enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-threads=posix --enable-win32-registry=oce-gcc4.1.1-glibc2.5
Thread model: posix
gcc version 4.1.1
We're cross compiling from Windows to Linux.
The command line is very basic: gcc reproduce.cpp
This results in the following compiler output:
reproduce.cpp: In function 'int main()':
reproduce.cpp:18: error: cannot allocate an object of abstract type 'pure'
reproduce.cpp:2: note: because the following virtual functions are pure
within 'pure':
reproduce.cpp:5: note: virtual bool pure::isPure()
The preprocessed file looks as follows:
# 1 reproduce.cpp
# 1 built-in
# 1 command line
# 1 reproduce.cpp
class pure
{
public:
pure() {}
virtual bool isPure () = 0;
};
class notPure : public pure
{
public:
notPure() {}
virtual bool isPure () { return false; };
};
int main ()
{
pure ** list;
list = new (pure (*[3]));
for (int i = 0; i 3; i ++) {
list [i] = new notPure();
}
}
--
Summary: Error while allocating array of pointers to objects of a
pure virtual class
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: p dot vestjens at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #1 from p dot vestjens at gmail dot com 2007-06-19 14:47 --- Created an attachment (id=13736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736action=view) Sourcefile demonstrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug pending/32403] New:
NOTE: Defaulting component because reported component no longer exists Environment: System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007 i686 GNU/Linux Architecture: i686 host: i486-pc-linux-gnu build: i486-pc-linux-gnu target: m68hc11-unknown-none configured with: ../src/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --with-gnu-as --with-gnu-ld --enable-nls --without-included-gettext --disable-checking --enable-languages=c --build=i486-linux-gnu --host=i486-linux-gnu --target=m68hc11 --without-headers How-To-Repeat: When reporting a compiler error, preprocessor output mu how to correct or work around the problem, if known (multiple lines) -- Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marko at localhost dot localhost GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: m68hc11-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32403
[Bug fortran/32404] New: Wrong-code with sbdart (valgrind errors, different output)
Spin off from PR 32236. ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz (33181 lines of code) Unpack source and do: - Delete in tauaero.f:1601 the line data wlbaer/0.,0./ - Insert around drt.f:951 the lines weq = 0.0_kr wfull = 0.0_kr If one compiles (-O0) the program with g95, sunf95, ifort and gfortran (4.1.3, 4.2.0, 4.3) and compares the output, one finds (drf.f, subroutine stdout1): - sunf95, ifort and g95 produce identical output except for the 7th column - gfortran's output differs also in the 7th column, but starting from some row it also differs in the 4th column; the results for the 4th column are different depending on the gfortran version A possible reason might be that some variable has not been initialized, however, using ifort -check all I could only find the two problems above (weq, wfull) and g95 and g95 -freal=nan -flogical=true -finteger=123456 -pointer=invalid give the same result. Some further debugging (in drf.f's stdout1) shows that topup - or more precisely flup(ntop) - diverges at some point. flup is set via DISORT (disort.f). Both g95 and gfortran show quite a lot of uninitialized warnings in valgrind (over 30), ifort only shows two, sunf95 four. -- Summary: Wrong-code with sbdart (valgrind errors, different output) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code 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=32404
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-19 15:30 --- Bob, Can you please tell me why the compiler flags tauaero.f:1517 while the problem seems to be associated with the data statement at line 1601? The line number shown when an internal compiler error occurs is often not reliably; often something goes wrong at one place, but this is only triggered when the compiler is at a completely different place. I found the line using other compilers; but also the brand-new error message of the gfortran 4.3 compiler shows now: tauaero.f:1601.17: data wlbaer/0.,0./ 1 tauaero.f:1587.21: wlbaer(2)=0., 2 Error: 'wlbaer' at (1) already is initialized at (2) Thus either =0. in line 1587 or data wlbaer/0.,0./ needs to be removed. I have tried your suggestion (commenting out the data statement), but the code does not appear to work correctly with this modification. I miss a good test case. If you have one, I'm really interested. However, I found some divergence in the output compared with other compilers, see PR 32404. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug pending/32403] foo
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-19 16:02 --- blah -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary||foo http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32403
[Bug target/32369] [frv] macro DF_LIVE_IN passed 2 arguments, but takes just 1
--- Comment #4 from rask at gcc dot gnu dot org 2007-06-19 16:30 --- Subject: Bug 32369 Author: rask Date: Tue Jun 19 16:30:03 2007 New Revision: 125851 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125851 Log: 2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32369 * config/frv/frv.c (frv_ifcvt_modify_tests): Dataflow merge fix. (frv_ifcvt_modify_insn): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/frv/frv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug fortran/20863] [4.2 only] Pointer problems in PURE procedures
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:30 --- Tobias points out to me that this is not a regression - closed and out. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
[Bug target/20082] unrecognizable insn
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-19 16:32 --- Sorry for my screw-up on the PR number - it was 20882 that was fixed. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
[Bug fortran/20882] [4.2 only] PURE procedure containing pointer assignment to dummy with pointer component
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-19 16:32 --- This is not a regression, so that is it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #14 from daney at gcc dot gnu dot org 2007-06-19 16:36 --- Subject: Bug 32313 Author: daney Date: Tue Jun 19 16:36:42 2007 New Revision: 125852 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125852 Log: PR target/32313 * config/mips/mips.md (cprestore): Mark $gp as used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.
--- Comment #15 from daney at gcc dot gnu dot org 2007-06-19 16:43 --- The second time is the charm. There are still regressions caused by the dataflow merge, but at least we can bootstrap now. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #9 from pault at gcc dot gnu dot org 2007-06-19 16:44 --- This is not a regression so no backport. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #13 from rob1weld at aol dot com 2007-06-19 17:11 ---
The goal of the tests is not to measure some time, but to check that
intervals are properly ordered, i.e., t1=dat1=t1a and t2a=dat2-dat1= t2.
If that is the goal then could we eliminate all influence of time (midnight /
leap seconds / end of year, and whatever random issues occur) by using a
procedure similar to what is described in:
gcc-4_3-trunk/libmudflap/testsuite/lib/mfdg.exp ?
# Indicate that this test case is to be rerun several times. This
# is useful if it is nondeterministic. This applies to rerunning the
# test program only, not rebuilding it.
# The embedded format is { dg-repetitions N }, where N is the number
# of repetitions. It better be greater than zero.
#
proc dg-repetitions { line value } {
upvar dg-repetitions repetitions
set repetitions $value
}
#
# Indicate that this test case is to be run with a short timeout.
# The embedded format is { dg-timeout N }, where N is in seconds.
#
proc dg-timeout { line value } {
global dg-timeout
set dg-timeout $value
}
# dejagnu's config/unix.exp hard-codes 300 seconds as the timeout
# for any natively run executable. That's too long for tests run
# multiple times and that may possibly hang. So we override it here
# to provide some degree of control.
We could run the test 5 times and if we got at least one pass we could write
PASS: and use WARNING: to write the number of failures. If we get 5
failures then we just write FAIL:.
The last time I ran make -i check I got a pass on this test, the time before
a fail; previously it's been hit and miss. The above technique will catch
random failures better and avoid false positives.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #9 from rask at gcc dot gnu dot org 2007-06-19 17:35 --- Subject: Bug 32335 Author: rask Date: Tue Jun 19 17:35:16 2007 New Revision: 125853 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125853 Log: 2007-06-19 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32335 * config/m32c/m32c.c: Include dataflow header file. (m32c_emit_prologue): Adjust for prologue insn change. * config/m32c/prologue.md (prologue_enter_16): Only modify SP_REGNO once inside a PARALLEL. Assume frame size passed in operand 0 includes space to save the fb register. (prologue_enter_24): Likewise. (epilogue_exitd): Only modify SP_REGNO once inside a PARALLEL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/m32c.c trunk/gcc/config/m32c/prologue.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote: --- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- (In reply to comment #10) Talked to Dan Berlin and Diego Novillo here at Google. They told me that all locals are promoted to function scope. That *only* applies to register variables, not stack variables. Yes, but our GIMPLE optimizers don't know that and we do not have a way of enforcing that in GIMPLE. There just are no scope boundaries in the SSA web. So, the end result is that in SSA we only have function scope. We very very much want to preserve scope of stack variables, because we very very much want to share stack space between stack variables of different scopes. Failure to do so causes bad interactions with inlining, and causes stack space consumtion to grow to unacceptable levels. I.e. you can't build kernels anymore. Agreed. We have to find a way of either tying the hands of code motion transformations by making them use the SSA web *and* the TREE_BLOCKs, or make stack slot sharing aware of live ranges. Right now we have the unfortunate situation that an optimizer is making a valid transformation which breaks the scope assumption that stack sharing uses. I am not sure if it would be practical to force code motion optimizations to use anything other than the SSA web to do their analysis. Perhaps we could force scopes by building barriers on the SSA web itself (say, by putting PHI nodes at scope boundaries, or something). Alternatively, we could incorporate live-range analysis to stack slot sharing. That way, if code motion creates undue stack slot pressure, we would merely emit suboptimal code, instead of wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug rtl-optimization/32405] New: assertion failure in loop-iv.c; probable dataflow regression
The following 2 testcases began failing for an xtensa-elf target when the
dataflow branch was merged:
gcc.c-torture/execute/920501-6.c
gcc.c-torture/execute/930921-1.c
Both tests fail at -O3 with internal compiler error: in get_biv_step,
at loop-iv.c:792. Neither the Xtensa port nor the loop-iv.c code
changed at the time of the regression in a way that obviously affects this. I'm
suspecting it is somehow related to the dataflow merge.
Here is what appears to be happening for 930921-1.c. The test program is:
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) 32) 1;
}
main ()
{
unsigned i;
for (i = 0; i 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
At -O3, function f is inlined into main and x * 0xAAAB is recognized as
a DImode induction variable. I'm pretty sure the problem is related
to the lack of an adddi3 pattern in xtensa.md. We rely on optabs.c to
expand DImode addition. If I dump the RTL file, the induction
variable increment looks like:
;; ivtmp$55 = ivtmp$55 + 0x0aaab
(insn 26 25 27 930921-1.c:4 (set (reg:DI 50)
(mem/u/c/i:DI (symbol_ref/u:SI (*.LC1) [flags 0x2]) [2 S8 A64])) -1
(expr_list:REG_EQUAL (const_double -1431655765 [0xaaab] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
(nil)))
(insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil))
(insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)
(subreg:SI (reg:DI 50) 4))) -1 (nil))
(insn 29 28 30 930921-1.c:4 (set (reg:SI 52)
(const_int 1 [0x1])) -1 (nil))
(jump_insn 30 29 31 930921-1.c:4 (set (pc)
(if_then_else (ltu (subreg:SI (reg:DI 51) 4)
(subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4))
(label_ref 32)
(pc))) -1 (nil))
(insn 31 30 32 930921-1.c:4 (set (reg:SI 52)
(const_int 0 [0x0])) -1 (nil))
(code_label 32 31 33 6 [0 uses])
(insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0)
(subreg:SI (reg:DI 50) 0))) -1 (nil))
(insn 34 33 35 930921-1.c:4 (set (reg:SI 53)
(plus:SI (reg:SI 52)
(subreg:SI (reg:DI 51) 0))) -1 (nil))
(insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0)
(reg:SI 53)) -1 (nil))
(insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ])
(reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ])
(reg:DI 50))
(nil)))
The failing assertion in get_biv_step() is:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
The outer_mode is DImode; the inner_mode is SImode; and extend is
UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations
involved here. Is this code intended to work for DImode IVs when
the machine doesn't directly support DImode operations? I don't know
if the problem is in this loop-iv.c code or whether it ought not
recognize the DImode induction variable in the first place.
--
Summary: assertion failure in loop-iv.c; probable dataflow
regression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bwilson at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: xtensa-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug target/32406] New: [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
Build from svn r125825 with:
http://gcc.gnu.org/viewcvs?view=revrevision=125852
applied.
Configured: ../trunk/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--disable-java-awt --without-x --disable-tls --enable-__cxa_atexit
--disable-jvmpi --disable-libmudflap --enable-languages=c,c++
gcc.c-torture/execute/nestfunc-6.c is FAILing at -O2, -O3, and -Os. This is a
regression from:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00546.html
This is the test case:
---
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
extern void exit (int);
extern void qsort(void *, size_t, size_t, int (*)(const void *, const void *));
int main ()
{
__label__ nonlocal;
int compare (const void *a, const void *b)
{
goto nonlocal;
}
char array[3];
qsort (array, 3, 1, compare);
abort ();
nonlocal:
exit (0);
}
Here is the generated assembly:
/home/daney/gccsvn/mipsel-trunk/gcc/xgcc
-B/home/daney/gccsvn/mipsel-trunk/gcc/ -O3 -S nestfunc-6.c
---
.file 1 nestfunc-6.c
.section .mdebug.abi32
.previous
.abicalls
.rdata
.align 2
$LTRAMP0:
.word 0x03e00821 # move $1,$31
.word 0x04110001 # bgezal $0,.+8
.word 0x # nop
.word 0x8fe30014 # lw $3,20($31)
.word 0x8fe20018 # lw $2,24($31)
.word 0x0060c821 # move $25,$3
.word 0x0068 # jr $3
.word 0x0020f821 # move $31,$1
.word 0x # function address
.word 0x # static chain value
.globl _flush_cache
.text
.align 2
.globl main
.entmain
.type main, @function
main:
.frame $sp,96,$31 # vars= 64, regs= 2/0, args= 16, gp= 8
.mask 0xc000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
lui $28,%hi(__gnu_local_gp)
addiu $sp,$sp,-96
addiu $28,$28,%lo(__gnu_local_gp)
sw $31,92($sp)
sw $fp,88($sp)
.cprestore 16
lui $2,%hi($LTRAMP0)
addiu $6,$2,%lo($LTRAMP0)
addiu $3,$sp,40
addiu $2,$sp,24
sw $2,84($sp)
sw $3,80($sp)
sw $2,28($sp)
sw $sp,32($sp)
move$7,$3
addiu $8,$6,32
$L2:
lw $2,0($6)
lw $3,4($6)
lw $4,8($6)
lw $5,12($6)
addiu $6,$6,16
sw $2,0($7)
sw $3,4($7)
sw $4,8($7)
sw $5,12($7)
bne $6,$8,$L2
addiu $7,$7,16
lw $2,4($6)
lw $4,0($6)
sw $2,4($7)
sw $4,0($7)
lw $2,80($sp)
lui $3,%hi(compare.1584)
addiu $3,$3,%lo(compare.1584)
sw $3,32($2)
lw $3,80($sp)
addiu $2,$sp,28
sw $2,36($3)
lw $25,%call16(_flush_cache)($28)
lw $4,80($sp)
li $5,40 # 0x28
jalr$25
li $6,3# 0x3
lw $28,16($sp)
lw $4,84($sp)
lw $25,%call16(qsort)($28)
lw $7,80($sp)
li $5,3# 0x3
jalr$25
li $6,1# 0x1
lw $28,16($sp)
lw $25,%call16(abort)($28)
jalr$25
nop
$L3:
$L4:
lw $25,%call16(exit)($28)
jalr$25
move$4,$0
.setmacro
.setreorder
.endmain
.align 2
.entcompare.1584
.type compare.1584, @function
compare.1584:
.frame $fp,8,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x4000,-8
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-8
sw $fp,0($sp)
lw $fp,0($2)
lw $sp,4($2)
lui $2,%hi($L3)
addiu $2,$2,%lo($L3)
j $2
nop
.setmacro
.setreorder
.endcompare.1584
.ident GCC: (GNU) 4.3.0 20070618 (experimental)
Note that $gp ($28) is not restored at $L3 where it is used. The compare
function does 'goto nonlocal;' which is a jump to $L3, but $gp will have the
wrong value and must be restored.
This worked before the dataflow merge because the compare function would load
$gp (unnecessarily).
I think the fix is to load $gp at $L3.
--
Summary: [4.3 Regression] MIPS: FAIL in
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #2 from jojelino at gmail dot com 2007-06-19 18:13 --- Created an attachment (id=13737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13737action=view) source file that causes ICE reduced. just three line for ICE -- jojelino at gmail dot com changed: What|Removed |Added Attachment #13735|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #3 from jojelino at gmail dot com 2007-06-19 18:18 --- (From update of attachment 13737) removing static keyword at the top resolves problem. but is it workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #13 from spop at gcc dot gnu dot org 2007-06-19 18:35 --- Subject: Bug 32367 Author: spop Date: Tue Jun 19 18:35:39 2007 New Revision: 125855 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125855 Log: PR tree-optimization/32367 * tree-chrec.h (build_polynomial_chrec): Verify that the left hand side of the chrec has no evolution in that loop. * testsuite/gcc.dg/tree-ssa/pr32367.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32367.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-chrec.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #28 from amacleod at redhat dot com 2007-06-19 18:57 --- Won't solve the problem currently, but I think the long term solution is to do stack analysis when out-of-ssa and expand have been merged into a single entity. The live range info out-of-ssa calculates can be used to do a decent job of stack sharing regardless of scoping info. Short term, we might be able to check to see if a stack variable is used outside its scope when going out of ssa, and flag it for no sharing, or promote it to file level, or the next appropriate scope level. That would work as long as we don't end up promoting too many things in the wrong routines :-). I'm not fond of trying to make the optimization passes aware of scopes on top of everything else they are aware of, Id rather see it taken care of in one place, and not dependent on scoping info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug ada/32407] New: ACATS cd92001 fails
The detailed content of the log is shown below. splitting /home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/tests/cd/cd92001.a into: cd92001.adb BUILD cd92001.adb gnatmake --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ -gnatws -O2 -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support cd92001.adb -largs --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ /home/voax/linux/build-4.3.0/gcc/xgcc -c -B/home/voax/linux/build-4.3.0/gcc/ -gnatws -O2 -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support cd92001.adb gnatbind -aO./ -I/home/voax/linux/build-4.3.0/gcc/testsuite/ada/acats/support -I- -x cd92001.ali gnatlink cd92001.ali --GCC=/home/voax/linux/build-4.3.0/gcc/xgcc -B/home/voax/linux/build-4.3.0/gcc/ RUN cd92001 ,.,. CD92001 ACATS 2.5 07-06-18 18:43:09 CD92001 Check object attribute: X'Valid. * CD92001 Expected 'Valid =FALSE for Default item 1. * CD92001 Expected 'Valid =FALSE for Default item 2. * CD92001 Expected 'Valid =FALSE for Default item 3. * CD92001 Expected 'Valid =FALSE for Default item 4. * CD92001 Expected 'Valid =FALSE for Default item 5. * CD92001 Expected 'Valid =FALSE for Default item 6. * CD92001 Expected 'Valid =FALSE for Default item 7. * CD92001 Expected 'Valid =FALSE for Default item 8. * CD92001 Expected 'Valid =FALSE for Default item 9. * CD92001 Expected 'Valid =FALSE for Default item 10. * CD92001 Expected 'Valid =FALSE for Default item 11. * CD92001 Expected 'Valid =FALSE for Default item 12. * CD92001 Expected 'Valid =FALSE for Default item 13. * CD92001 Expected 'Valid =FALSE for Default item 14. * CD92001 Expected 'Valid =FALSE for Default item 15. * CD92001 Expected 'Valid =FALSE for Default item 16. * CD92001 Expected 'Valid =FALSE for Default item 17. * CD92001 Expected 'Valid =FALSE for Default item 18. * CD92001 Expected 'Valid =FALSE for Default item 19. * CD92001 Expected 'Valid =FALSE for Default item 20. * CD92001 Expected 'Valid =FALSE for Default item 21. * CD92001 Expected 'Valid =FALSE for Default item 22. * CD92001 Expected 'Valid =FALSE for Default item 23. * CD92001 Expected 'Valid =FALSE for Default item 24. * CD92001 Expected 'Valid =FALSE for Default item 25. * CD92001 Expected 'Valid =FALSE for Default item 26. * CD92001 Expected 'Valid =FALSE for Default item 27. * CD92001 Expected 'Valid =FALSE for Default item 28. * CD92001 Expected 'Valid =FALSE for Default item 29. * CD92001 Expected 'Valid =FALSE for Default item 30. * CD92001 Expected 'Valid =FALSE for Default item 31. * CD92001 Expected 'Valid =FALSE for Default item 32. * CD92001 Expected 'Valid =FALSE for Default item 33. * CD92001 Expected 'Valid =FALSE for Default item 34. * CD92001 Expected 'Valid =FALSE for Default item 35. * CD92001 Expected 'Valid =FALSE for Default item 36. * CD92001 Expected 'Valid =FALSE for Default item 37. * CD92001 Expected 'Valid =FALSE for Default item 38. * CD92001 Expected 'Valid =FALSE for Default item 39. * CD92001 Expected 'Valid =FALSE for Default item 40. * CD92001 Expected 'Valid =FALSE for Default item 41. * CD92001 Expected 'Valid =FALSE for Default item 42. * CD92001 Expected 'Valid =FALSE for Default item 43. * CD92001 Expected 'Valid =FALSE for Default item 44. * CD92001 Expected 'Valid =FALSE for Default item 45. * CD92001 Expected 'Valid =FALSE for Default item 46. * CD92001 Expected 'Valid =FALSE for Default item 47. * CD92001 Expected 'Valid =FALSE for Default item 48. * CD92001 Expected 'Valid =FALSE for Default item 49. * CD92001 Expected 'Valid =FALSE for Default item 50. * CD92001 Expected 'Valid =FALSE for Default item 51. * CD92001 Expected 'Valid =FALSE for Default item 52. * CD92001 Expected 'Valid =FALSE for Default item 53. * CD92001 Expected 'Valid =FALSE for Default item 54. * CD92001 Expected 'Valid =FALSE for Default item 55. * CD92001 Expected 'Valid =FALSE for Default item 56. * CD92001 Expected 'Valid =FALSE for Default item 57. * CD92001 Expected 'Valid =FALSE for Default item 58. * CD92001 Expected 'Valid =FALSE for Default item 59. * CD92001 Expected 'Valid =FALSE for Default item 60. * CD92001 Expected 'Valid =FALSE for Default item 61. * CD92001 Expected 'Valid =FALSE for Default item 62. * CD92001 Expected 'Valid =FALSE for Default item 63. * CD92001 Expected 'Valid =FALSE for Default item 64. * CD92001 Expected 'Valid =FALSE for Default item 65. * CD92001 Expected 'Valid =FALSE for Default item 66. * CD92001 Expected 'Valid =FALSE for Default item 67. * CD92001 Expected 'Valid =FALSE for Default item 68. * CD92001 Expected 'Valid =FALSE for Default item 69. * CD92001 Expected 'Valid =FALSE for Default item 70. * CD92001 Expected 'Valid =FALSE for Default item
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
We need to know that the return pointer (r2) is not used and that
the function is a leaf function (i.e., that the incoming value in
r2 is unchanged). Calls clobber r2.
Dave
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
This is an update. Since the dataflow merge I've been unable to
find a way to handle generation of the prologue/epilogue/return insns
that works on all hppa targets. However, debugging time has been
limited.
I had one successful build on hppa2.0w-hp-hpux11.11. However,
I haven't had a successful build on hppa64-hp-hpux11.11 or
hppa-unknown-linux-gnu. The hppa64 problem is PR 32398.
The linux problem is wierd. In stage2, I get the following
failure:
/bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo
../../sinf
o.h
make[3]: *** [ada/sinfo.h] Error 139
The above fault is a stack overflow. The problem is wierd in the sense
that the error doesn't occur when I run ./xsinfo ../../sinfo.h from
an interactive shell. It only occurs when the command is run by make.
Increasing the stack limit didn't help. This suggests a problem with
the environment passed to xsinfo.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #15 from hjl at lucon dot org 2007-06-19 20:10 --- (In reply to comment #14) The linux problem is wierd. In stage2, I get the following failure: /bin/sh: line 1: 4487 Segmentation fault (core dumped) ./xsinfo ../../sinf o.h make[3]: *** [ada/sinfo.h] Error 139 The above fault is a stack overflow. The problem is wierd in the sense that the error doesn't occur when I run ./xsinfo ../../sinfo.h from an interactive shell. It only occurs when the command is run by make. Increasing the stack limit didn't help. This suggests a problem with the environment passed to xsinfo. make may change stack limit. You can write a simple Makefile to check the real stack limit of processes spawned by make. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug c++/32408] New: Template Parsing Error
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code snippet that reproduces the problem:
template class T
struct templated_struct
{
int count;
};
template class T
int template_func()
{
templated_structT s;
if (s.count 0) return 0;
return 0;
}
int main()
{
template_funcint ();
return 0;
}
The compiler generates the follow error message when trying to compile the
above code:
test4.cc: In function int template_func():
test4.cc:16: error: parse error in template argument list
test4.cc: In function int template_func() [with T = int]:
test4.cc:22: instantiated from here
test4.cc:16: error: count is not a member template function
Note that the above code compiles just fine if you replace the '' token in the
IF statement with an '' or an '==', thus demonstrating that GCC seems to be
confusing the '' token for a template argument.
A temporary workaround is to put a set of parenthesis around s.count.
--
Summary: Template Parsing Error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chsalvia at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug c++/32409] New: Template Parsing Error
GCC may have a defective template parsing routine which seems to mistake the
'' token in an expression for the beginning of a template argument. The error
only seems to happen when a templated function evaluates a member of a
templated class or struct with a '' symbol.
Here is a simple code snippet that reproduces the problem:
template class T
struct templated_struct
{
int count;
};
template class T
int template_func()
{
templated_structT s;
if (s.count 0) return 0;
return 0;
}
int main()
{
template_funcint ();
return 0;
}
The compiler generates the follow error message when trying to compile the
above code:
test4.cc: In function int template_func():
test4.cc:16: error: parse error in template argument list
test4.cc: In function int template_func() [with T = int]:
test4.cc:22: instantiated from here
test4.cc:16: error: count is not a member template function
Note that the above code compiles just fine if you replace the '' token in the
IF statement with an '' or an '==', thus demonstrating that GCC seems to be
confusing the '' token for a template argument.
A temporary workaround is to put a set of parenthesis around s.count.
--
Summary: Template Parsing Error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chsalvia at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32409
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19 20:39 --- Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-* make may change stack limit. You are right. Make bumps the soft limit to unlimited when the hard limit is unlimited. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug target/32277] indir-call-prof fails on ia64-linux-gnu
--- Comment #1 from sje at cup dot hp dot com 2007-06-19 21:12 --- I proposed XFAIL'ing the test at one point but that patch was not accepted. See http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02016.html I get the same failure on IA64 HP-UX. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-19 21:12:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32277
[Bug c++/32408] Template Parsing Error
--- Comment #1 from schwab at suse dot de 2007-06-19 21:22 --- *** Bug 32409 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug c++/32409] Template Parsing Error
--- Comment #1 from schwab at suse dot de 2007-06-19 21:22 --- *** This bug has been marked as a duplicate of 32408 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32409
[Bug c++/32408] Template Parsing Error
--- Comment #2 from pcarlini at suse dot de 2007-06-19 22:04 --- Apparently you provided the wrong snippet, this one compiles just fine and well, doesn't have 22 lines... ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression
--- Comment #1 from rakdver at kam dot mff dot cuni dot cz 2007-06-19 22:07 --- Subject: Re: New: assertion failure in loop-iv.c; probable dataflow regression The failing assertion in get_biv_step() is: gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN)); The outer_mode is DImode; the inner_mode is SImode; and extend is UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations involved here. Is this code intended to work for DImode IVs when the machine doesn't directly support DImode operations? I don't know if the problem is in this loop-iv.c code or whether it ought not recognize the DImode induction variable in the first place. this looks more like some latent problem exposed by df branch merge. I will have a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-19 22:26:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405
[Bug c++/32410] New: Const functions in template don't give access errors with this until instantiated.
If you create a const member function to a template class, it seems to be able
to change a non-mutable member of the function by using the this pointer. The
following illegal code compiles:
template typename T
class Class
{
unsigned int i;
public:
void foo () const
{
this-i++;
}
};
However, if Classwhatever::foo is instantiated, then it gives an error for
changing the constant data member. However, if you remove the this- line,
the access errors occur even without an instantion. This is inconsistent
behavior. They should both cause errors at the same point.
--
Summary: Const functions in template don't give access errors
with this until instantiated.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coppro at users dot sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32410
[Bug c++/32408] Template Parsing Error
--- Comment #3 from chsalvia at gmail dot com 2007-06-19 23:08 ---
Sorry. It seems this is actually a namespace conflict issue. If you add
include the iostream header file and add using namespace std the code will
not compile, due to a conflict with std::count.
#include iostream
using namespace std;
template class T
struct templated_struct
{
int count;
};
template class T
int template_func()
{
templated_structT s;
if (s.count 0) return 0;
return 0;
}
int main()
{
template_funcint ();
return 0;
}
Now I'm not completely sure if this should be considered a bug. However, since
count is clearly a member of templated_struct, there shouldn't be a namespace
conflict here. Also, if you replace '' with '' or '==', it compiles fine
with no namespace conflict, which means gcc seems to be confusing '' with a
template argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug c++/32408] Template Parsing Error
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-19 23:10 --- *** This bug has been marked as a duplicate of 10200 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32408
[Bug c++/10200] Weird clash with same names in different scopes
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-19 23:10 --- *** Bug 32408 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||chsalvia at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
[Bug c++/32410] Const functions in template don't give access errors with this until instantiated.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-19 23:13 --- This is correct as *this is dependent so the compiler cannot resolve that until instantation time so this is not a bug. This is inconsistent behavior. Yes but i here is not depdendent. While this-i is. -- 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=32410
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #17 from danglin at gcc dot gnu dot org 2007-06-19 23:30 --- Created an attachment (id=13738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738action=view) Patch under test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #18 from danglin at gcc dot gnu dot org 2007-06-19 23:32
---
The stack overflow takes some time and I was able to attach gdb:
0x402a6c58 in read_encoded_value_with_base (encoding=11 '\v', base=0,
p=0x60384 , val=0xc019ea8c) at ../../../gcc/libgcc/../gcc/unwind-pe.h:200
200 ../../../gcc/libgcc/../gcc/unwind-pe.h: No such file or directory.
in ../../../gcc/libgcc/../gcc/unwind-pe.h
(gdb) bt
#0 0x402a6c58 in read_encoded_value_with_base (encoding=11 '\v', base=0,
p=0x60384 , val=0xc019ea8c) at ../../../gcc/libgcc/../gcc/unwind-pe.h:200
#1 0x402a70ac in linear_search_fdes (ob=0xc019ea14, this_fde=0x60378,
pc=0x2546b) at ../../../gcc/libgcc/../gcc/unwind-dw2-fde.c:812
#2 0x402a79b4 in _Unwind_IteratePhdrCallback (info=value optimized out,
size=value optimized out, ptr=0xc019e8cc)
at ../../../gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:389
#3 0x4025b3c8 in dl_iterate_phdr () from /lib/libc.so.6
#4 0x402a8f70 in _Unwind_Find_FDE (pc=0x2546b, bases=0xc019e3a4)
at ../../../gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:420
#5 0x402a42b0 in uw_frame_state_for (context=0xc019e230, fs=0xc019e418)
at ../../../gcc/libgcc/../gcc/unwind-dw2.c:1121
#6 0x402a611c in _Unwind_RaiseException (exc=0x42ac3a88)
at ../../../gcc/libgcc/../gcc/unwind.inc:103
#7 0x0001da88 in ada.exceptions.exception_propagation.propagate_exception (
from_signal_handler=value optimized out) at a-exexpr.adb:584
#8 0x0001dac8 in ada.exceptions.process_raise_exception (
e=value optimized out, from_signal_handler=false) at a-except.adb:776
#9 0x0001db28 in __gnat_raise_nodefer_with_msg (e=0xb) at a-except.adb:829
#10 0x0001e208 in __gnat_raise_exception (e=0x0,
message=value optimized out) at a-except.adb:859
#11 0x00027fec in ada.text_io.get_line (file=0x74e20, item=
{P_ARRAY = 0x0, P_BOUNDS = 0x0}) at a-textio.adb:630
---Type return to continue, or q return to quit---
#12 0x0002546c in ada.strings.unbounded.text_io.get_line (file=0x74e20)
at a-suteio.adb:72
#13 0x0001b540 in xsinfo__getline___832 ()
#14 0x0001ad7c in _ada_xsinfo ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #20 from mrs at apple dot com 2007-06-19 23:36 --- The patch was approved today on the gcc-patches list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #12 from malitzke at metronets dot com 2007-06-19 23:57 --- Why is this still unconfirmed after the corrobation by Mrs Johnson? Personally I could not care less if it is swept under the rug, like so many other PR's. Without-altivec would suit me fine as altivec is, to me, just a competive and unnecessary competitive response, by then Motorola, to Intel's SSE, which to me is just gumming up the X86 part of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-20 00:27 --- This is a target bug. Nothing can change it from being a target bug unless it turns out to be a middle-end bug on how addressing works inside the compiler. The main reason why it has not been confirmed, is because I and others have been busy with some of your other bugs and other things (like traveling to Japan). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-20 00:27:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #1 from hp at gcc dot gnu dot org 2007-06-20 02:53 --- I saw your comments on IRC at an attempt of using nonlocal_goto_receiver. You don't want to make a new pattern with that name, just rename exception_receiver; the obvious one-line patch. That pattern already has the necessary restore of $gp (not just a clobber). With a nonlocal_goto_receiver, the pattern exception_receiver is not used (grep for yourself!), so it doesn't hurt or something. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug fortran/32302] [4.2 Regression] Incorrect result with -O2
--- Comment #14 from pault at gcc dot gnu dot org 2007-06-20 05:02 --- Subject: Bug 32302 Author: pault Date: Wed Jun 20 05:02:39 2007 New Revision: 125870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125870 Log: 2007-06-20 Paul Thomas [EMAIL PROTECTED] PR fortran/32302 * trans-common.c (build_common_decl): If resizing of common decl is needed, update the TREE_TYPE. 2007-06-20 Paul Thomas [EMAIL PROTECTED] PR fortran/32302 * gfortran.dg/common_resize_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/common_resize_1.f Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-common.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32302] [4.2 Regression] Incorrect result with -O2
--- Comment #15 from pault at gcc dot gnu dot org 2007-06-20 05:03 --- Fixed on trunk and 4.2 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug other/32411] New: GCC Collect2 adds extra -lm's to link commands even when not linking with -lm.
The page http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts says libm is being replaced with libmpfr. I set out to remove all the excess references to -lm in the configure scripts and Makefiles produced. I found that I could remove -lm from everywhere and GCC _compiled_ OK. When I ran the testsuite there where a lot of extra errors in Gfortran so I put the un-modified configure file back and re-compiled GCC. I noticed that everything still compiled OK but the errors in libstdc++ where not well explained in the logs. I investigated and found that collect2 may have some problems with including -lm even when it is not specified on the command line. GNU C version 4.3.0 20070619 (experimental), GMP version 4.2.1, MPFR version 2.3.0-dev. GNU assembler version 2.17.50 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.17.50.20070426 # /opt/gcc-4_3-build-2/gcc/collect2 -v collect2 version 4.3.0 20070619 (experimental) (i386 Linux/ELF) /usr/bin/ld -v GNU ld (GNU Binutils) 2.17.50.20070426 See these tests results for a further explanation: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00919.html -- Summary: GCC Collect2 adds extra -lm's to link commands even when not linking with -lm. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32411
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #19 from rob1weld at aol dot com 2007-06-20 05:09 --- Just tried MPFR version 2.3.0 - it works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug middle-end/32024] ICE - libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12652
--- Comment #9 from rob1weld at aol dot com 2007-06-20 05:15 --- Still occurs: gcc version 4.3.0 20070619 (experimental) /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3': /root/downloads/gcc-4_3-trunk/libgcc/../gcc/libgcc2.c:557: internal compiler error: in fold_checksum_tree, at fold-const.c:12775 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
[Bug boehm-gc/31999] Make -i check finds one, and fails to find another, boehm-gc problem
--- Comment #2 from rob1weld at aol dot com 2007-06-20 05:30 --- Bug part 1 - FIXED I was still getting the undefined reference to `GC_local_malloc' errors in gcc version 4.3.0 20070614 but it may be fixed in gcc version 4.3.0 20070619. Bug part 1 - NOT - FIXED(?) 2): I don't know that boehm is integrated with GCC in accordance with the recommendations provided in the boehm DOCs. Bug part 3 - Seems FIXED(?) internal compiler error: in uses_jv_markobj_p, at java/boehm.c:245 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31999
[Bug rtl-optimization/28011] [4.1/4.2 Regression] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-20 05:47 --- Subject: Bug 28011 Author: kkojima Date: Wed Jun 20 05:47:09 2007 New Revision: 125871 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125871 Log: PR rtl-optimization/28011 Backport from mainline. * reload.c (push_reload): Set dont_share if IN appears in OUT also when IN is a PLUS rtx. (reg_overlap_mentioned_for_reload_p): Return true if X and IN are same PLUS rtx. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug rtl-optimization/28011] [4.1/4.2 Regression] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-06-20 05:52 --- Subject: Bug 28011 Author: kkojima Date: Wed Jun 20 05:52:05 2007 New Revision: 125872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125872 Log: PR rtl-optimization/28011 Backport from mainline. * reload.c (push_reload): Set dont_share if IN appears in OUT also when IN is a PLUS rtx. (reg_overlap_mentioned_for_reload_p): Return true if X and IN are same PLUS rtx. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug rtl-optimization/28011] [4.1/4.2 Regression] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #6 from kkojima at gcc dot gnu dot org 2007-06-20 05:54 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
