[Bug target/7625] gcc pessimized 64-bit % operator on hppa2.0
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:49 --- Boooiinngg... Or, is anyone working on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:57 --- GCC 3.4 did better, said the reporter in comment #0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|GCC4 moves the result of a |[4.0/4.1/4.2 regression] |conditional block through |GCC4 moves the result of a |inadequate registers|conditional block through ||inadequate registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug target/25671] test_bit() compilation does not expand to "bt" instruction
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 --- The resulting code for -march=opteron: test_bit: .LFB2: leal63(%rsi), %edx testl %esi, %esi movl%esi, %eax cmovns %esi, %edx sarl$31, %eax shrl$26, %eax sarl$6, %edx leal(%rsi,%rax), %ecx movslq %edx,%rdx andl$63, %ecx subl%eax, %ecx movl$1, %eax sall%cl, %eax cltq testq %rax, (%rdi,%rdx,8) setne %al movzbl %al, %eax ret For -march=nocona the code is even uglier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug target/25671] test_bit() compilation does not expand to "bt" instruction
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 --- This is what the i386 machine description has to say about BT and friends: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, ;; it depends on the cpu implementation. They're never faster than ;; the corresponding and/ior/xor operations, so with 32-bit there's ;; no point. But in 64-bit, we can't hold the relevant immediates ;; within the instruction itself, so operating on bits in the high ;; 32-bits of a register becomes easier. ;; ;; These are slow on Nocona, but fast on Athlon64. We do require the use ;; of btrq and btcq for corner cases of post-reload expansion of absdf and ;; negdf respectively, so they can never be disabled entirely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug target/25671] test_bit() compilation does not expand to "bt" instruction
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-11 23:03 --- Code size issue -- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16996 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-12 21:28 --- fold_truthop is called with this input: Breakpoint 11, fold_truthop (code=TRUTH_ANDIF_EXPR, truth_type=0x2adff4d0, lhs=0x2adf64b0, rhs=0x2adf6690) at fold-const.c:4820 4820 if (TREE_SIDE_EFFECTS (lhs) || TREE_SIDE_EFFECTS (rhs)) (gdb) p debug_generic_expr(lhs) (intD.0) wordD.1878 & 1 $50 = void (gdb) p debug_generic_expr(rhs) ((intD.0) wordD.1878 & 08000) == 32768 $51 = void (gdb) And it folds this input to 0, which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:41:46 date|| Summary|Some OpenMP semantics are |[4.2 Regression] Some OpenMP |caught too late (in the |semantics are caught too |gimplifier) |late (in the gimplifier) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-20 20:53 ---
I have tested this test case again with lcm.c patched with the patch below to
check for insertions on edges where an expression is already available. The
abort does not trigger.
The version of GCC that I patched and tested was extracted from SVN with the
following commands: svn co -r {"2004-08-10 15:10"} (etc.)
Index: lcm.c
===
--- lcm.c (revision 85749)
+++ lcm.c (working copy)
@@ -426,10 +426,6 @@ pre_edge_lcm (FILE *file ATTRIBUTE_UNUSE
dump_sbitmap_vector (file, "earliest", "", earliest, num_edges);
#endif
- sbitmap_vector_free (antout);
- sbitmap_vector_free (antin);
- sbitmap_vector_free (avout);
-
later = sbitmap_vector_alloc (num_edges, n_exprs);
/* Allocate an extra element for the exit block in the laterin vector. */
@@ -462,6 +458,32 @@ pre_edge_lcm (FILE *file ATTRIBUTE_UNUSE
}
#endif
+#if 1
+ {
+sbitmap *avout_check;
+sbitmap *insert_ = *insert;
+int x;
+
+avout_check = sbitmap_vector_alloc (num_edges, n_exprs);
+sbitmap_vector_zero (avout_check, num_edges);
+
+for (x = 0; x < num_edges; x++)
+ {
+ basic_block bb = INDEX_EDGE_PRED_BB (edge_list, x);
+ if (bb->index < 0)
+ continue;
+ sbitmap_copy (avout_check[x], avout[bb->index]);
+ sbitmap_a_and_b (avout_check[x], avout_check[x], insert_[x]);
+ if (sbitmap_first_set_bit (avout_check[x]) >= 0)
+ abort ();
+ }
+ }
+#endif
+
+ sbitmap_vector_free (antout);
+ sbitmap_vector_free (antin);
+ sbitmap_vector_free (avout);
+
return edge_list;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-20 21:13 --- Created an attachment (id=11306) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11306&action=view) CFG at the start of gcse -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-20 21:14 --- Created an attachment (id=11307) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11307&action=view) LCM dataflow solution for the first gcse pass -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #10 from steven at gcc dot gnu dot org 2006-04-20 21:15 --- Created an attachment (id=11308) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11308&action=view) LCM dataflow solution for the second gcse pass -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-20 21:16 --- One of these days someone should manually compute the LCM sets from attachments 1, 2, and 3 ... -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-02-11 00:37:04 |2006-04-20 21:16:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/11884] Bad address passed to function with > 8 arguments
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-24 22:28 --- Reporter has disappeared. No-one has complained about this in recent GCCs (i.e. open branches) so closing as WONTFIX. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11884
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-24 22:29 --- Still an issue here?? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #6 from steven at gcc dot gnu dot org 2006-04-24 22:32 --- Works for me. Works for the reporter. I say this works. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug rtl-optimization/24814] unrolling doesn't put loop notes in right place
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-24 22:34 --- What are loop notes again? Ah, yes. Legacy. Fixed on mainline. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24814
[Bug rtl-optimization/24815] loop unrolling ends up with too much reg+index addressing
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-24 22:37 --- I'm sure Zdenek would argue that strength reduction is not the unroller's task (and fwiw I agree), and Joern would argue that it is. Either way, this is a valid bug report. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-24 22:37:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24815
[Bug rtl-optimization/12771] Weak loop optimizer
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-24 22:44 --- The loop optimizer in gcc 4.2 has lots of changes. How does it perform for this code now? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12771
[Bug rtl-optimization/13335] cse of sub-expressions of zero_extend/sign_extend expressions
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-24 22:45 --- Has this one fallen through the cracks? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13335
[Bug rtl-optimization/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-24 22:51 --- I'm inclined to say "don't do this" but i can see why this is a problem for the reporter. I can't reproduce the issue myself, though. Tom, do you still see a problem here? Sorry for the long delay btw. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-27 19:10 --- Patches addressing some of the issues: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00969.html http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01049.html I'm linking them from here for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #5 from steven at gcc dot gnu dot org 2006-04-27 20:46 ---
So I asked myself, why are we not catching this in vrp? I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield load?
It turns out that we make _all_ loads VARYING right away, so we end up with:
Value ranges after VRP:
b_1: ~[0B, 0B] EQUIVALENCES: { b_2 } (1 elements)
b_2: VARYING
D.1882_3: VARYING
D.1883_4: [0, 1] EQUIVALENCES: { } (0 elements)
D.1884_5: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1885_6: [0, 127] EQUIVALENCES: { } (0 elements)
D.1886_7: [0, +INF] EQUIVALENCES: { } (0 elements)
ior (b)
{
D.1886;
unsigned char D.1885;
signed char D.1884;
signed char D.1883;
D.1882;
:
D.1882_3 = b_2->bit;
D.1883_4 = (signed char) D.1882_3;
D.1884_5 = D.1883_4 | 1;
D.1885_6 = (unsigned char) D.1884_5;
D.1886_7 = () D.1885_6;
b_2->bit = D.1886_7;
return;
}
where, at least so it seems to me, we could find something like,
D.1882_3: [0, 1] (etc.)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-02-18 18:24:49 |2006-04-27 20:46:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-27 21:32 --- Yes, BIT_IOR_EXPR is also not handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug middle-end/27181] Does not fold access to base with cast to different derived type
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-28 19:12:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27181
[Bug fortran/27351] Use variable after free in gfc_conv_array_transpose
-- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01124.html Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-29 09:55:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
[Bug c++/27336] "this" pointer is not assumed to be not null
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-01 19:17 --- Re. comment #2 and comment #3, yes you are expecting too much of the nonnull attribute. The attribute only applies to function arguments, not to function results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug c++/27336] "this" pointer is not assumed to be not null
--- Comment #5 from steven at gcc dot gnu dot org 2006-05-01 19:19 ---
Ehm, right, ignore comment #4.
Yes it is possible.
No, it's not very practical. Your code looks like,
bool f(A *a) {
g(a);
return a;
}
to the middle end. It would take a significant amount of extra work to walk
through all formal and actual argument lists in a CALL_EXPR to find "attribute
nonnull"-arguments in the callee argument list. I'm not sure that's worth the
cost.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug fortran/27378] ICE on unexpected ELSE statement
--- Comment #1 from steven at gcc dot gnu dot org 2006-05-02 16:57 ---
Index: parse.c
===
--- parse.c (revision 113473)
+++ parse.c (working copy)
@@ -624,6 +624,7 @@ next_statement (void)
if (gfc_at_eol ())
{
if (gfc_option.warn_line_truncation
+ && gfc_current_locus.lb
&& gfc_current_locus.lb->truncated)
gfc_warning_now ("Line truncated at %C");
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-02 16:57:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27378
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-02 17:38 --- The inner loop in the .cunroll, .ivopts and .final_cleanup with GVN-PRE disabled look like this: # Int_Index_37 = PHI ; :; (*D.1561_56)[Int_Index_37] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; if (D.1563_41 >= Int_Index_58) goto ; else goto ; :; goto (); and # ivtmp.34_26 = PHI ; # Int_Index_37 = PHI ; :; D.1613_59 = (int *) ivtmp.34_26; MEM[base: D.1613_59, offset: 20B] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; ivtmp.34_19 = ivtmp.34_26 + 4B; if (D.1563_41 >= Int_Index_58) goto ; else goto ; :; goto (); and :; MEM[base: (int *) ivtmp.34, offset: 20B] = Int_Loc; Int_Index = Int_Index + 1; ivtmp.34 = ivtmp.34 + 4B; if (D.1563 >= Int_Index) goto ; else goto ; which compiles to: .L4: addl$1, %eax movl%ecx, 20(%edx) addl$4, %edx cmpl%eax, %ebx jge .L4 With PRE enabled, we get this: # Int_Index_37 = PHI ; :; D.1559_54 = pretmp.27_59; D.1560_55 = pretmp.28_45; D.1561_56 = pretmp.28_49; (*pretmp.28_49)[Int_Index_37] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; if (D.1563_41 >= Int_Index_58) goto ; else goto ; :; goto (); and # ivtmp.38_26 = PHI ; :; D.1559_54 = pretmp.27_59; D.1560_55 = pretmp.28_45; D.1561_56 = pretmp.28_49; D.1622_34 = (int *) pretmp.28_49; D.1623_33 = (int *) Int_1_Par_Val_2; D.1624_22 = (int *) ivtmp.38_26; D.1625_21 = D.1623_33 + D.1624_22; MEM[base: D.1622_34, index: D.1625_21, step: 4B, offset: 20B] = Int_Loc_3; ivtmp.38_35 = ivtmp.38_26 + 1; D.1626_20 = (unsigned int) Int_1_Par_Val_2; D.1627_17 = D.1626_20 + ivtmp.38_35; D.1628_16 = D.1627_17 + 5; Int_Index_15 = (One_Fifty) D.1628_16; if (D.1563_41 >= Int_Index_15) goto ; else goto ; :; goto (); and :; MEM[base: (int *) prephitmp.33, index: (int *) Int_1_Par_Val + (int *) ivtmp.38, step: 4B, offset: 20B] = Int_Loc; ivtmp.38 = ivtmp.38 + 1; if ((One_Fifty) ((unsigned int) Int_1_Par_Val + 5 + ivtmp.38) <= D.1563) goto ; else goto ; and from there: .L5: leal(%edi,%edx), %eax addl$1, %edx movl%ecx, 20(%ebx,%eax,4) leal(%ecx,%edx), %eax cmpl%esi, %eax jle .L5 So it's a mix of PRE and IVOPTs that gives this strange code. BTW regarding "Its strange that tree-ch messes up", please next time don't blame random passes if you don't fully analyze the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #7 from steven at gcc dot gnu dot org 2006-05-03 21:33 --- Re. comment #5, user code could also have a CFG like that, so we should handle this case properly (and we do, tree-ch is doing the right thing afaict). Re. comment #6, I don't see what the register allocator has to do with this at all. The bottom line is that for the case where we produce good code, IVOPTs selects a simple addressing mode and produces a simple loop exit condition; and for the complicated code, IVOPTs picks an addressing mode that requires a lea and an extra register. Look back at that loop for a moment. With tree-ch, ignoring dead code (the sets to SSA names 5[456] are dead!), the .cunroll dump (i.e. just before IVOPTs) looks like this: # Int_Index_37 = PHI ; :; (*pretmp.28_49)[Int_Index_37] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; if (D.1563_41 >= Int_Index_58) goto ; else goto ; :; goto (); That looks rather nice to me. But just after IVOPTs (in the .ivopts dump) we have turned that simple nice code into this mess: # ivtmp.38_26 = PHI ; :; D.1622_34 = (int *) pretmp.28_49; D.1623_33 = (int *) Int_1_Par_Val_2; D.1624_22 = (int *) ivtmp.38_26; D.1625_21 = D.1623_33 + D.1624_22; MEM[base: D.1622_34, index: D.1625_21, step: 4B, offset: 20B] = Int_Loc_3; ivtmp.38_35 = ivtmp.38_26 + 1; D.1626_20 = (unsigned int) Int_1_Par_Val_2; D.1627_17 = D.1626_20 + ivtmp.38_35; D.1628_16 = D.1627_17 + 5; Int_Index_15 = (One_Fifty) D.1628_16; if (D.1563_41 >= Int_Index_15) goto ; else goto ; :; goto (); If this is caused by the register allocator, I'd like to know why you'd think that. And if this is the doing of tree-ch, then I'd like to know what you expect tree-ch to do instead. But as far as I can tell, this is just a very poor choice by IVOPTs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug libstdc++/7979] OpenUNIX8/Unixware stage 3 failing in eh_alloc.cc
--- Comment #17 from steven at gcc dot gnu dot org 2006-05-04 21:10 --- Too old. Upgrade. :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7979
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-05 18:42 --- Bud already voted to close this in comment #11 :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #2 from steven at gcc dot gnu dot org 2006-05-13 09:45 --- Index: alpha.c === --- alpha.c (revision 113736) +++ alpha.c (working copy) @@ -7410,6 +7410,7 @@ alpha_does_function_need_gp (void) for (; insn; insn = NEXT_INSN (insn)) if (INSN_P (insn) + && ! JUMP_TABLE_DATA_P (insn) && GET_CODE (PATTERN (insn)) != USE && GET_CODE (PATTERN (insn)) != CLOBBER && get_attr_usegp (insn)) ? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-13 09:45:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug middle-end/26729] [4.0 regression] bad bitops folding
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sayle at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail|3.3.6 3.4.3 4.0.2 4.1.0 |3.3.6 3.4.3 4.0.2 Known to work|2.95.4 4.2.0|2.95.4 4.2.0 4.1.0 Summary|[4.0/4.1 regression] bad|[4.0 regression] bad bitops |bitops folding |folding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #9 from steven at gcc dot gnu dot org 2006-05-14 14:23 --- Please take bugs if you post patches for them, it makes it easier to search for bugs that nobody is looking at. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sayle at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #6 from steven at gcc dot gnu dot org 2006-05-14 14:25 --- Seb, wrong code regression in your code. Are you working on this?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/27603] [4.1/4.2 Regression] wrong code, apparently due to bad VRP (-O2)
--- Comment #7 from steven at gcc dot gnu dot org 2006-05-15 04:36 --- Investigating a fix. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-14 17:44:48 |2006-05-15 04:36:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug tree-optimization/27603] [4.1/4.2 Regression] wrong code, apparently due to bad VRP (-O2)
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-15 19:55 --- No need for investigation anymore :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug tree-optimization/27745] ICE in execute_todo with -O2 -ftree-loop-linear
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-24 05:49:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27745
[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return
--- Comment #13 from steven at gcc dot gnu dot org 2006-05-24 06:08 --- Re. comment #12, my copy of the June 1997 Fortran 95 draft is very clear assuming we agree that there is no default initialization for this pointer. 14.6.2.1 Pointer association status A pointer may have a pointer association status of associated, disassociated, or undefined. Its association status may change during execution of a program. Unless a pointer is initialized (explicitly or by default), it has an initial association status of undefined. A pointer may be initialized to have an association status of disassociated. 5.1.2.7 POINTER attribute An object with the POINTER attribute shall neither be referenced nor defined unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE statement (6.3.1), it becomes pointer associated with a target object that may be referenced or defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662
[Bug tree-optimization/26242] [4.1/4.2 Regression] VRP is not documented in passes.texi
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:50 --- It is sad that this is not release critical, and even worse that the contributor of vrp apparently can't miss half an hour to document his work as he is required to do. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-28 09:50:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26242
[Bug middle-end/24434] [4.0/4.1/4.2 Regression] get_varargs_alias_set returns 0 always
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:53 --- This looks like one that the mem-ssa folks may want to give a look. Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24434
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19 --- Real bug, despite Andrew's usual portion of x86-hate. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-02 23:19:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-03 23:49 --- You could add a basic block list scheduler at the tree level just before out-of-ssa, with heuristics to make life times as short as possible :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug tree-optimization/17506] [4.0/4.1/4.2 regression] warning about uninitialized variable points to wrong location
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug tree-optimization/26251] [4.2 Regression] code size increase with -Os
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-04 09:32 --- This should have a higher priority than P3 IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Internal error with -O1 (CSE)
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-04 09:34 --- Would be fixed with fwprop due to not recursively calling fold_rtx. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-04 09:36:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-11-11 18:50:50 |2006-06-05 10:19:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-05 10:25 --- Four patches for loop-invariant.c went in since comment #7, and the bug hasn't been reconfirmed since. http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we still have the bug. Can someone confirm this still passes with -fno-move-loop-invariants? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #17 from steven at gcc dot gnu dot org 2006-06-05 10:27 --- Following comment #16, closing as FIXED. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-05 10:29 --- Just like other bugs, this one will need a test case. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/26051] [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-05 10:34 --- Andrew, if you have nothing to say, don't say anything as silly as "This is interesting". Rainer, there is no test case and no description for how to reproduce this. But is this still an issue at all? You seem to be able to report Solaris 10 test results, e.g. http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00113.html, for mainline. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26051
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #11 from steven at gcc dot gnu dot org 2006-06-05 10:37 --- When regstack is involved, Sayle is probably the only one who can fix it for real. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-05-21 21:30:19 |2006-06-05 10:37:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug tree-optimization/16876] [4.0/4.1/4.2 Regression] ICE on testcase with -O3 in gen_lowpart and fold-const
--- Comment #13 from steven at gcc dot gnu dot org 2006-06-05 10:41 --- Unassigning rth, since he's obviously not actually interested in fixing this. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug tree-optimization/16876] [4.0/4.1/4.2 Regression] ICE on testcase with -O3 in fold-const
--- Comment #14 from steven at gcc dot gnu dot org 2006-06-05 10:44 --- The failures in 3.4 and later are in fold_const, so the gen_lowpart problem is now avoided by, well, ICEing earlier :) -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1/4.2 Regression] ICE |on testcase with -O3 in |on testcase with -O3 in |gen_lowpart and fold-const |fold-const http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug middle-end/27906] reload allocates register of live register variable to earlyclobber output
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-06 04:31:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27906
[Bug bootstrap/18058] [4.2 Regression] Bootstrap fails with BOOTCFLAGS="-O0 -fkeep-inline-functions"
--- Comment #32 from steven at gcc dot gnu dot org 2006-06-11 08:35 --- Issues in general are not specific enough. The question is, do we still have a regression here. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug tree-optimization/27882] [4.2 regression] segfault in ipa-inline.c, if (e->callee->local.disregard_inline_limits
--- Comment #18 from steven at gcc dot gnu dot org 2006-06-11 08:36 --- A pre-processed C test case would be nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug target/27861] [4.0/4.1/4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-11 08:38 --- Are your host and build machine really mipsel-linux-gnu? Or is this a cross to mipsel? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #11 from steven at gcc dot gnu dot org 2006-06-11 08:54 --- This problem may be in some other place than expand. rebuild_jump_labels for example can also add REG_LABEL notes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug middle-end/26983] [4.0/4.1/4.2 Regression] Missing label in a nested function with builtin_setjmp/longjmp
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-11 08:55 --- I can't reproduce this with ToT. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #12 from steven at gcc dot gnu dot org 2006-06-11 09:21 ---
The offending insns for me are (using -dAP):
!(insn 315 243 316 (set (reg/f:SI 19 %l3 [167])
!(high:SI (label_ref:SI 123))) 40 {*movsi_high} (nil)
!(nil))
sethi %hi(.LL20), %l3 ! 315 *movsi_high [length = 1]
!(insn 316 315 301 (set (reg/f:SI 19 %l3 [167])
!(lo_sum:SI (reg/f:SI 19 %l3 [167])
!(label_ref:SI 123))) 39 {*movsi_lo_sum} (nil)
!(nil))
and
!(insn 319 253 320 (set (reg/f:SI 19 %l3 [167])
!(high:SI (label_ref:SI 123))) 40 {*movsi_high} (nil)
!(nil))
sethi %hi(.LL20), %l3 ! 319 *movsi_high [length = 1]
!(insn 320 319 365 (set (reg/f:SI 19 %l3 [167])
!(lo_sum:SI (reg/f:SI 19 %l3 [167])
!(label_ref:SI 123))) 39 {*movsi_lo_sum} (nil)
!(nil))
or %l3, %lo(.LL20), %l3! 320 *movsi_lo_sum [length = 1]
These insns appear for the first time in the .greg dump. This probably means,
I'm sorry to say, that this is a reload issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #13 from steven at gcc dot gnu dot org 2006-06-11 09:34 --- I spoke too soon. The code_label that is removed for me is code_label 123, which disappears after flow2. Calling rebuild_jump_labels at the end of rest_of_handle_flow2 makes the problem disappear for me, but that is too big a hammer for this problem, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #14 from steven at gcc dot gnu dot org 2006-06-11 09:55 ---
This hacks around this particular problem.
Not a fix, you know, but it explains what is going wrong here.
Index: reload1.c
===
--- reload1.c (revision 114548)
+++ reload1.c (working copy)
@@ -7755,7 +7755,11 @@ gen_reload (rtx out, rtx in, int opnum,
}
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
-emit_insn (gen_move_insn (out, in));
+{
+ tem = emit_insn (gen_move_insn (out, in));
+ if (GET_CODE (in) == LABEL_REF)
+ mark_jump_label (in, tem, 0);
+}
#ifdef HAVE_reload_load_address
else if (HAVE_reload_load_address)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug bootstrap/18058] [4.2 Regression] Bootstrap fails with BOOTCFLAGS="-O0 -fkeep-inline-functions"
--- Comment #35 from steven at gcc dot gnu dot org 2006-06-11 20:28 --- Re. comment #34: Read comment #31. If one bug is used for (at least) two different problems, confusion is what you get. Anyway, your patch is apparently still unreviewed...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug target/28001] incrementing a variable produces smaller code than an explicit assignment
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-12 19:43 --- This will never be implemented. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28001
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 04:22 --- Could it be an issue on the autovect branch? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 20:26 --- The solution is "don't do -fschedule-insns on x86". Unless you first add heuristics in the scheduler to keep a better eye on register pressure, and fix the many known bugs in scheduling for x86. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction
--- Comment #12 from steven at gcc dot gnu dot org 2006-06-14 05:28 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-17 10:18 --- It actually does finish for me at -O with gcc 4.0.2. It just takes an incredible amount of time and memory, but that doesn't surprise me so much, given the nature of this evil test case ;-) With gcc 4.2 20060617, I can't compile the test case. After a long time and after using up to 1.5 GB, the compiler dies with: cc1: out of memory allocating 399751872 bytes after a total of 79527936 bytes -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 10:18:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-17 11:05 --- Caused by excessive inlining: inline heuristics : 37.25 (25%) usr 0.04 ( 1%) sys 36.56 (15%) wall 2312 kB ( 0%) ggc integration : 19.91 (13%) usr 1.49 (36%) sys 62.70 (26%) wall 1058857 kB (76%) ggc -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/28071] A file that can not be compiled in reasonable time/space
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-17 11:05 --- Platform independent. Honza, one for you I suppose. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org GCC build triplet|all gcc version in fact (up | |to 4.1) | GCC host triplet|Intel and Apple G4 | GCC target triplet|Linux and OS X | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/21920] alias violating
--- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06 --- Release folks from the I-use-C-but-do-not-understand-its-semantics punishment list. Seriously, though... There is no reason to spam every one of these people every time there is another duplicate of this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC|hurbain at cri dot ensmp dot| |fr, gopalv82 at gmail dot | |com, adruab at voria dot| |com, renzo at cs dot unibo | |dot it, devin at dungeon2 | |dot cainetworks dot com, c | |dot pop at free dot fr, zybi| |at talex dot pl, sorenj at | |us dot ibm dot com, bobm75 | |at gmail dot com, puvar at | |rambler-co dot ru, steger at| |mvtec dot com, | |grigory_zagorodnev at linux | |dot intel dot com | CC|fabdouze at caramail dot| |com, lucho at haemimont dot | |bg, davmac at ozonline dot | |com dot au, hayim at dv-| |networks dot com, linuxadmin| |at yandex dot ru, ja2morri | |at uwaterloo dot ca, davids | |at webmaster dot com, | |danfuzz at milk dot com,| |thomas dot anders at blue- | |cable dot de, gino at dtecta| |dot com, duraid at octopus | |dot com dot au | CC|christophe dot guillon at st| |dot com, cdfrey at netdirect| |dot ca, evgeny at nowecom | |dot ru, ghouston at arglist | |dot com, gcc at arbruijn dot| |dds dot nl, kalas at| |unicontrols dot cz, fm at | |4js dot com, Andreas dot| |Glowatz at philips dot com, | |horst dot lehser at hightec-| |rt dot com, steffen dot | |zimmermann at philips dot | |com, jochang at gmail dot | |com | CC|jason dot elbaum at gmail | |dot com, spelis at | |federation dot 3dlabs dot | |com, noaml at mainsoft dot | |com, andreg at discreet dot | |com, dmeggy at techsol dot | |ca, zengpan at goldhuman dot| |com, pjh at cs dot unh dot | |edu, oder at eleks dot lviv | |dot ua, rarob at erols dot | |com, julien dot durand dot | |1981 at gmail dot com, | |ulrich dot lauther at | |siemens dot com | CC|larschri at pvv dot ntnu dot| |no, cxl at ntllib dot org, | |strasbur at chkw386 dot ch | |dot pwr dot wroc dot pl,| |mike at arl dot army dot| |mil, d dot bonekaemper at | |rtsgroup dot net, sumii at | |saul dot cis dot upenn dot | |edu, czang at panasas dot | |com, pgonzalez at bluel dot | |com, pierre dot chatelier at| |club-internet dot fr, boris | |at lml dot ls dot fi dot upm| |dot es | CC|jfran at clip dot dia dot fi| |dot upm dot es, rick dot ju | |at sun dot com, charles at | |provis dot com, mor_gopal at| |yahoo dot com, l_heldt at | |poczta dot onet dot pl, djk | |at super dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug rtl-optimization/28108] Some cse optimizations require hash collisions
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-20 20:02:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28108
[Bug debug/28063] [4.2 regression] Dwarf no longer uses merged strings for DW_AT_comp_dir
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-23 23:48:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28063
[Bug middle-end/28151] ICE on complex
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-24 13:50 --- We ICE in fold-const.c line 1691 (r114961): = const_binop (PLUS_EXPR, const_binop (MULT_EXPR, r2, r2, notrunc), const_binop (MULT_EXPR, i2, i2, notrunc), notrunc); This happens because const_binop (MULT_EXPR, r2, r2, notrunc) returns NULL_TREE. The input argument r2 is 0.0: Breakpoint 3, const_binop (code=RDIV_EXPR, arg1=0x2affafc0, arg2=0x2affaf90, notrunc=0) at fold-const.c:1691 1691 notrunc); (gdb) step const_binop (code=MULT_EXPR, arg1=0x2af2e5c8, arg2=0x2af2e5c8, notrunc=0) at fold-const.c:1554 1554 STRIP_NOPS (arg1); (gdb) p debug_tree(arg1) unit size align 32 symtab 0 alias set -1 precision 32 pointer_to_this > constant invariant 0.0> $17 = void (gdb) p debug_tree(arg2) unit size align 32 symtab 0 alias set -1 precision 32 pointer_to_this > constant invariant 0.0> $18 = void (gdb) -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-24 11:37:02 |2006-06-24 13:50:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] ICE on complex
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-24 13:53 --- Uhm, Richi is right. Ignore comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug c/28152] New: Diagnostic about wrong use _Complex prints __complex__
$ cat t.c
int
main (void)
{
_Complex float z;
z = _Complex (1.9007326203904e+19, 0.0);
z = _Complex (1.0e+0, 0.0) / z;
$ ./cc1 -quiet t.c
t.c: In function 'main':
t.c:6: error: expected expression before '__complex__'
t.c:7: error: expected expression before '__complex__'
$ ./cc1 --version
GNU C version 4.2.0 20060624 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$
--
Summary: Diagnostic about wrong use _Complex prints __complex__
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-24 14:13 --- The code that causes this "regression" is actually in the first ever checkin of fold-const.c (r330). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
--- Comment #7 from steven at gcc dot gnu dot org 2006-06-24 14:15 --- The problem appears to be caused by the change of semantics of const_binop in this patch: 2005-11-16 Eric Botcazou <[EMAIL PROTECTED]> * fold-const.c (const_binop): Don't constant fold the operation if the result has overflowed and flag_trapping_math. * simplify-rtx.c (simplify_const_binary_operation): Likewise. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-24 14:20 ---
Another test case:
_Complex float b;
int
main (void)
{
_Complex float a = __FLT_MAX__;
b = __FLT_MAX__ + a;
}
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 Regression] ICE|[4.1/4.2 Regression] ICE
|with complex division |with complex math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-25 23:05:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27950
[Bug target/27827] [4.0/4.1/4.2 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #25 from steven at gcc dot gnu dot org 2006-06-28 17:30 --- Pure luck or not, this is a regression. -- steven at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i?86-*-*, x86_64-*-*|i386, x86_64 Last reconfirmed|2006-06-01 08:43:34 |2006-06-28 17:30:40 date|| Summary|gcc 4 produces worse x87|[4.0/4.1/4.2 Regression] gcc |code on all platforms than |4 produces worse x87 code on |gcc 3 |all platforms than gcc 3 Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/21498] clause 7.1.5.3/2 of the c++ is not enforced
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-01 11:18 --- Mark, this bug concerns a C++ standard question, perhaps you could give your interpretation... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com Last reconfirmed|2005-11-04 04:36:06 |2006-07-01 11:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-03 21:52 --- Paul, Since gfortran is developed by volunteers who are often gfortran users themselves, it usually depends on the needs of the developers what gets implemented in gfortran. Given that nobody has responded to your latest comment in months, apparently this is not a feature that many gfortran users are interested in. That is not really surprising because most of them probably used g77 before (GNU Fortran 77) which also did not support RECORD. What would be helpful to know in this case, is how the standard DERIVED TYPE feature of Fortran 90 (and later) compares to your STRUCTURE+RECORD thing. If the semantics of these two features is not very different, then perhaps we can implement it without too much trouble. Now, if you have time for some research, perhaps you could figure out a thing or two for us, such as: how does the SGI compiler handle mixed F95 derived types and RECORD declarations; how are STRUCTURE types layed out? Basically any comparison of derived types vs. STRUCTURE would be nice. If the two features can easily co-exist, then I think it should be quite easy to implement support for STRUCTURE in gfortran. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-02 07:13:40 |2006-07-03 21:52:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25297
[Bug fortran/28276] EXPONENT() broken for real constants
-- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-06 08:57 --- Uros, You could post it now, just so that people can have a look at it and maybe suggest some changes. You know how that goes. It would be interesting to see if this actually gives speedups... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28252
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #14 from steven at gcc dot gnu dot org 2006-07-09 00:34 --- Fixed on the trunk? If so, please remove the "4.2" marker from this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-09 07:48 --- To quote from the F95 June 97 working draft, note 12.17: "Because an INTENT(OUT) variable is considered undefined on entry to the procedure, any default initialization specified for its type will be applied." Of the fortran bugs we have, this is one of the more serious bugs. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-02 19:28:17 |2006-07-09 07:48:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug fortran/24285] format(1000(a,$))
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-09 10:29 --- FX, are you working on this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/25709] BIND (Fortran 2003) is not supported at all
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
[Bug fortran/28339] gfortran misses a record from a format statement
-- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #18 from steven at gcc dot gnu dot org 2006-07-13 21:47 --- Re. comment #16: That looks like you get an internal compiler error (ICE )while building g++ which has nothing to do with libgfortran. If that ICE is reproducible, it deserves its own bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/28378] Intrinsic extensions should be deselectable via command line
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-14 16:59 --- Enhancement request for compatibility with XLF. Not a high-priority enhancement, but probably not very difficult to implement for a hobbyist. -- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2006-07-14 16:59:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28378
[Bug rtl-optimization/27616] [4.1/4.2 Regression] Internal error with -O1 (CSE)
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-14 17:02 --- The patch identified in comment #8 can't have caused the CSE problem, but it probably exposed a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-15 22:58 --- Probably latent on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
