[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #15 from dodji at gcc dot gnu dot org 2010-02-22 08:18 --- Fixed in 4.5 (trunk) -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug fortran/38112] unneeded temporary
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-22 08:58 --- Paul, for the test case in comment 0 we still create a temporary: b(a)=1 where a is a simple-contiguous rank-one array without target/pointer attribute, which thus cannot alias with b. Do you think this is fixable? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug tree-optimization/42652] vectorizer created unaligned vector insns
--- Comment #17 from irar at il dot ibm dot com 2010-02-22 09:01 --- Is there a way to pass alignment information similar to PR 39954? Otherwise, a proper fix would be some inter-procedural analysis... Meantime, we can do intra-procedural analysis and fail when we reach function argument, i.e, use runtime checks. We already have several types of versioning, so adding another one will complicate the things even more, and will not always be possible (because of code size constrains). Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
[Bug fortran/43136] Excess copy-in/copy-out with character argument
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 09:01:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43136
[Bug driver/42485] [4.4/4.5 Regression] -V switch broken
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-22 09:02 --- Testing a patch to deprecated -b and -V. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
[Bug fortran/38112] unneeded temporary
--- Comment #5 from paul dot richard dot thomas at gmail dot com 2010-02-22 09:06 --- Subject: Re: unneeded temporary Tobias, I'll take a look tonight. Cheers Paul On Mon, Feb 22, 2010 at 9:58 AM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from burnus at gcc dot gnu dot org 2010-02-22 08:58 --- Paul, for the test case in comment 0 we still create a temporary: b(a)=1 where a is a simple-contiguous rank-one array without target/pointer attribute, which thus cannot alias with b. Do you think this is fixable? -- burnus at gcc dot gnu dot org changed: What |Removed |Added CC| |pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug target/43137] New: redundant register move for sign extending
Compile following code with options -march=armv7-a -mthumb -Os
int foo();
long long bar22()
{
int result = foo();
return result;
}
GCC generates:
bar22:
push{r3, lr}
bl foo
asrsr3, r0, #31// A
mov r1, r3 // B
pop {r3, pc}
Instruction A,B can be simplified to asrs r1, r0, #31.
In rtl expand, result was first extended to a DI register and then the DI
register was moved to return register. In later passs the low half of the
return value and variable result were recognized as in the same register, so
the low part move was removed. After register allocation I get:
(call_insn 5 2 7 2 src/t5.c:5 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI (foo) [flags 0x41]
function_decl 0x7f6e60fe0600 foo) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 255 {*call_value_insn} (nil)
(nil))
(insn 7 5 22 2 src/t5.c:5 (set (reg:DI 2 r2 [orig:136 result ] [136])
(sign_extend:DI (reg/v:SI 0 r0 [orig:133 result ] [133]))) 691
{*thumb2_extendsidi2} (nil))
(insn 22 7 15 2 src/t5.c:7 (set (reg:SI 1 r1 [+4 ])
(reg:SI 3 r3 [ result+4 ])) 658 {*thumb2_movsi_insn} (nil))
The high part register move didn't get any chance to be removed until the end
of compilation.
--
Summary: redundant register move for sign extending
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137
[Bug tree-optimization/42652] vectorizer created unaligned vector insns
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-02-22 10:27 --- (In reply to comment #17) Is there a way to pass alignment information similar to PR 39954? Well, that wasn't really a true fix but simply restored the (broken) behavior of earlier compilers so the 4.5 regression is gone ... Otherwise, a proper fix would be some inter-procedural analysis... Meantime, we can do intra-procedural analysis and fail when we reach function argument, i.e, use runtime checks. We already have several types of versioning, so adding another one will complicate the things even more, and will not always be possible (because of code size constrains). Yes, we need to propagate (mis-)alignment information properly. My plan for 4.6 is to add (mis-)alignemnt information to SSA_NAME_PTR_INFO and have a simple propagator computing it. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-22 10:54 ---
(In reply to comment #6)
How about the below patch? It fixes all testcases for me. I'm not sure
whether it makes sense to filter duplicate labels this late, but I don't know
how to do this earlier, as catches seem to be lowering independently of each
other.
Looks sensible, though unreachable block removal should be conditional on
us removing an edge, not on lowering anything.
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 2cb334f..c18b807 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see
#include flags.h
#include function.h
#include except.h
+#include pointer-set.h
#include tree-flow.h
#include tree-dump.h
#include tree-inline.h
@@ -3063,6 +3064,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)
eh_catch c;
edge_iterator ei;
edge e;
+ struct pointer_set_t *seen_values = pointer_set_create ();
/* Collect the labels for a switch. Zero the post_landing_pad
field becase we'll no longer have anything keeping these labels
@@ -3071,6 +3073,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)
for (c = r-u.eh_try.first_catch; c ; c = c-next_catch)
{
tree tp_node, flt_node, lab = c-label;
+ bool have_label = false;
c-label = NULL;
tp_node = c-type_list;
@@ -3083,14 +3086,26 @@ lower_eh_dispatch (basic_block src, gimple stmt)
}
do
{
- tree t = build3 (CASE_LABEL_EXPR, void_type_node,
-TREE_VALUE (flt_node), NULL, lab);
- VEC_safe_push (tree, heap, labels, t);
+ /* Filter out duplicate labels that arise when this handler
+ is shadowed by an earlier one. When no labels are
+ attached to the handler anymore, we remove
+ the corresponding edge and then we delete unreachable
+ blocks at the end of this pass. */
+ if (! pointer_set_contains (seen_values, TREE_VALUE
(flt_node)))
+ {
+ tree t = build3 (CASE_LABEL_EXPR, void_type_node,
+TREE_VALUE (flt_node), NULL, lab);
+ VEC_safe_push (tree, heap, labels, t);
+ pointer_set_insert (seen_values, TREE_VALUE (flt_node));
+ have_label = true;
+ }
tp_node = TREE_CHAIN (tp_node);
flt_node = TREE_CHAIN (flt_node);
}
while (tp_node);
+ if (! have_label)
+ remove_edge (find_edge (src, label_to_block (lab)));
}
/* Clean up the edge flags. */
@@ -3132,6 +3147,7 @@ lower_eh_dispatch (basic_block src, gimple stmt)
VEC_free (tree, heap, labels);
}
+ pointer_set_destroy (seen_values);
}
break;
@@ -3185,6 +3201,8 @@ execute_lower_eh_dispatch (void)
}
}
+ if (any_rewritten)
+delete_unreachable_blocks ();
return any_rewritten ? TODO_update_ssa_only_virtuals : 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #45 from dominiq at lps dot ens dot fr 2010-02-22 11:21 --- Bootstrapped and regtested on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02098.htm ) and x86_64-apple-darwin10 (see http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02102.html) with the patch in comment #43 with the fix in comment #44. Everything I can look at seems to work as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-02-22 12:02 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug target/43139] New: ICE in output_operand
/* { dg-do compile } */
/* { dg-options -g -O2 -fpic } */
typedef double T1[10];
typedef double T2[10][10];
typedef int T3[10];
void fn1 (void);
void fn2 (int, ...);
static void
bar (double v, double w, double x, double y, double z)
{
double a;
if (v / w 200.0)
{
a = x + (y - x) * __builtin_exp (-v / w);
fn2 (0);
fn2 (1, a * 20.2 / z, z);
fn1 ();
}
}
static void
baz (T2 u, T2 v, T2 w, T2 x, T1 y, T3 z, double q, int j, int k)
{
int i = z[k];
if (u[i][j] 0.0)
bar (q, x[i][j], v[i][j], w[i][j], y[i]);
}
static T2 a, b, c, d;
static T1 e;
static T3 f;
void test (int j, int k, double q)
{
baz (a, b, c, d, e, f, q, j, k);
}
ICEs on redhat/gcc-4_4-branch on i686-linux (and x86_64-linux -m32), with:
internal compiler error: output_operand: invalid expression as operand
I haven't been able to make this testcase ICE on the trunk, but I believe the
issue is just latent there, so I'm filing it here rather than tracking it
internally.
The issue is that %ebx + offset addition is CSEd, so we have:
leal(%ebx,%ecx,8), %ecx
...
fldla...@gotoff(%ecx)
fldlc...@gotoff(%ecx)
fldlb...@gotoff(%ecx)
fldld...@gotoff(%ecx)
(as this is in a loop, I don't think that is even a bad idea, the code is at
least shorter). But var-tracking finds out one of the tracked variables lives
in:
(note 189 177 190 4 (var_location w (expr_list:REG_DEP_TRUE (mem/s:DF (plus:SI
(reg:SI 2 cx [75])
(const:SI (unspec:SI [
(symbol_ref:SI (d) [flags 0x2] var_decl
0x7f9bb4c3faa0 d)
] 1))) [2 S8 A64])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
and i?86 delegitimize hook, as it doesn't see the PIC register anywhere in the
expression, just gives up. We don't have a target hook that would verify what
we throw at dw2_asm_output_addr_rtx won't ICE and target's checking ICEs when
it sees an unexpected UNSPEC (or on other targets e.g. might generate invalid
assembly). So, either we need to add such a target hook which will check the
rtx and tell caller it is not valid (so dwarf2out would just skip that
location), or we need to teach delegitimize langhook in this case to return
some fancy address (in this case it would be (symbol_ref d) + (reg cx) - (reg
bx)).
Unfortunately the delegitimization langhook is called not just in dwarf2out,
but in other places too, so it needs some verification whether it wouldn't
cause problems there.
--
Summary: ICE in output_operand
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43139
[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 12:40:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug tree-optimization/42917] [4.5 Regression] -fcompare-debug failure with -ftree-loop-linear
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-22 12:41 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 12:41:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42917
[Bug c++/43140] New: [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
Between revisions 156927 and 156932 g++.dg/graphite/pr41305.C has started to fail (likely due to revision 156928): [macbook] f90/bug% gcc45 -c -O3 -floop-interchange /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C: In member function 'pointer allocator_Tp::allocate(allocator::size_type) [with _Tp = double, pointer = double, allocator::size_type = long unsigned int]': /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C:80:5: instantiated from 'unbounded_arrayT, template-parameter-1-2 ::unbounded_array(unbounded_arrayT, template-parameter-1-2 ::size_type, ALLOC) [with T = double, ALLOC = allocatordouble, unbounded_arrayT, template-parameter-1-2 ::size_type = long unsigned int]' /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C:272:83: instantiated from 'vectorT, template-parameter-1-2 ::vector(vectorT, template-parameter-1-2 ::size_type, value_type) [with T = double, A = unbounded_arraydouble, allocatordouble , vectorT, template-parameter-1-2 ::size_type = long unsigned int, value_type = double]' /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C:323:32: instantiated from here /opt/gcc/work/gcc/testsuite/g++.dg/graphite/pr41305.C:24:12: warning: converting to non-pointer type 'allocatordouble::pointer' from NULL -- Summary: [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
--- Comment #1 from dominiq at lps dot ens dot fr 2010-02-22 12:55 --- CC Manuel López-Ibáñez and H.J. Lu. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, manu at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug tree-optimization/43026] [4.5 Regression][graphite] ICE in sese.c with -fgraphite-identity in 447.dealII
--- Comment #7 from spop at gcc dot gnu dot org 2010-02-22 13:11 --- Subject: Bug 43026 Author: spop Date: Mon Feb 22 13:10:49 2010 New Revision: 156956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156956 Log: Fix PR43026: handle COMPONENT_REFs in expand scalar expressions. 2010-02-11 Sebastian Pop sebastian@amd.com PR middle-end/43026 * sese.c (expand_scalar_variables_expr): Handle COMPONENT_REF. * g++.dg/graphite/pr43026.C: New. Added: branches/graphite/gcc/testsuite/g++.dg/graphite/pr43026.C Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/sese.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
[Bug tree-optimization/43141] New: [4.5 Regression] Wrong debug information with IPA-SRA
Split out from PR42336.
But here's a C testcase where we lose debug info about a parameter that was
optimized away: there are no formal parameters in the DWARF output for f.
int i;
static int f(int) __attribute ((noinline));
static int f(int x) { return i; }
int main()
{
return f(42);
}
--
Summary: [4.5 Regression] Wrong debug information with IPA-SRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43141
[Bug tree-optimization/43141] [4.5 Regression] Wrong debug information with IPA-SRA
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-22 13:17 --- Martin, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336#c22 still applies here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 13:17:54 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43141
[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-02-22 13:18 --- The ICE is fixed. The wrong-debug issue is PR43141 now. -- 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=42336
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-22 13:49 ---
It seems to me that the template parameter to allocator should be a pointer and
in this testcase is just double. So the warning is correct. If the testcase is
correct, then you should either catch the warning with // { dg-warning } or
silence it with // { dg-options -Wno-conversion-null }
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-02-22 13:49:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug middle-end/43045] [lto] ICE non-trivial conversion at assignment
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-22 14:08 --- Created an attachment (id=19933) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19933action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43045
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-22 14:09 --- Subject: Bug 42749 Author: rguenth Date: Mon Feb 22 14:09:26 2010 New Revision: 156960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156960 Log: 2010-02-22 Richard Guenther rguent...@suse.de PR tree-optimization/42749 * tree-tailcall.c (adjust_return_value_with_ops): Drop update parameter. Do arithmetic in the original type. (update_accumulator_with_ops): Likewise. (adjust_accumulator_values): Adjust. * gcc.c-torture/compile/pr42749.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42749.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug target/43129] Simplify global variable's address loading with option -fpic
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-22 14:14 --- CC Sebastian Pop. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||sebpop at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug target/43137] redundant register move for sign extending
--- Comment #1 from ramana at gcc dot gnu dot org 2010-02-22 14:32 --- Confirmed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 14:32:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137
Email Order
Dear Sir/Ma, Compliment of the season to you! I went through your website address and found some items i would like to place order on. but before i proceed i will like to know if your company accepts payment via VISA or MASTER CARD and if your company ship to Australia. If yes, please get back to me as soon as possible with your website address to confirm if the website address is the same with the one i checked or better still, you can email me with the price list on the items you have presently in stock as attachment. I will await your prompt response as soon as you receive this message,i will be very glad if you treat this email with good concern! Thank You, Frank Lewis OWNER. FRANCO PTY STORE 5655 Bourke Street Level 34. Melbourne, VIC 3000. Australia Phone Number: 61 3 8641 41600 franklewis...@gmail.com
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
--- Comment #4 from spop at gcc dot gnu dot org 2010-02-22 14:55 --- Subject: Bug 43140 Author: spop Date: Mon Feb 22 14:55:08 2010 New Revision: 156963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156963 Log: Fix PR43140: Add -Wno-conversion-null to pr41305.C. 2010-02-22 Sebastian Pop sebastian@amd.com Manuel López-Ibáñez m...@gcc.gnu.org PR middle-end/43140 * g++.dg/graphite/pr41305.C: Add -Wno-conversion-null. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/testsuite/g++.dg/graphite/pr41305.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #17 from comer352l at googlemail dot com 2010-02-22 15:09 --- Great, thank you Steven ! Will this patch also improve compilation time ? It currently needs about 45 seconds with 4.4.3 on a Athlon64X2-5000+ (even with -fnogcse). In the meantime I managed to test on a windows machine with a recent version (4.4.0) and the size increase doesn't occur there (but compilation is extremely slow, too). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
--- Comment #5 from spop at gcc dot gnu dot org 2010-02-22 15:13 --- Subject: Bug 43140 Author: spop Date: Mon Feb 22 15:13:39 2010 New Revision: 156964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156964 Log: Fix PR43097: rename only SSA_NAMEs. 2010-02-22 Sebastian Pop sebastian@amd.com PR middle-end/43140 * sese.c (get_rename): Assert that old_name is an SSA_NAME. (rename_variables_in_stmt): Continue when the use is not an SSA_NAME. * gfortran.dg/graphite/pr43097.f: New. Added: branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr43097.f Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/sese.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug tree-optimization/43097] [4.5 Regression] ICE in rename_map_elt_info for Graphite, vect in 173.applu
--- Comment #3 from spop at gcc dot gnu dot org 2010-02-22 15:19 --- This should have been added to this PR: I copied and forgot to adjust the PR number. Author: spop Date: Mon Feb 22 15:13:39 2010 New Revision: 156964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156964 Log: Fix PR43097: rename only SSA_NAMEs. 2010-02-22 Sebastian Pop sebastian@amd.com PR middle-end/43140 * sese.c (get_rename): Assert that old_name is an SSA_NAME. (rename_variables_in_stmt): Continue when the use is not an SSA_NAME. * gfortran.dg/graphite/pr43097.f: New. Added: branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr43097.f Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/sese.c -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 18:36:56 |2010-02-22 15:19:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
[Bug c++/43140] [4.5 Regression] FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-22 13:49:05 |2010-02-22 15:19:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43140
[Bug tree-optimization/43026] [4.5 Regression][graphite] ICE in sese.c with -fgraphite-identity in 447.dealII
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-11 16:56:36 |2010-02-22 15:20:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
[Bug c/42923] ice: verify_stmts failed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-22 15:46 --- *** This bug has been marked as a duplicate of 42749 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42923
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-02-22 15:46 --- *** Bug 42923 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||regehr at cs dot utah dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-22 15:44 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/43045] [lto] ICE non-trivial conversion at assignment
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-22 15:53 --- Subject: Bug 43045 Author: rguenth Date: Mon Feb 22 15:53:27 2010 New Revision: 156966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156966 Log: 2010-02-22 Richard Guenther rguent...@suse.de PR lto/43045 * tree-inline.c (declare_return_variable): Use the type of the call stmt lhs if available. * gfortran.dg/lto/20100222-1_0.f03: New testcase. * gfortran.dg/lto/20100222-1_1.c: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/lto/20100222-1_0.f03 trunk/gcc/testsuite/gfortran.dg/lto/20100222-1_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43045
[Bug middle-end/43045] [lto] ICE non-trivial conversion at assignment
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-22 16:03 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43045
[Bug c++/43142] New: ICE in output_505, at config/rs6000/rs6000.md:12485
g++ -O2 -c agg_bezier_ctrl.ii -fPIC -o xx.o In file included from ../../include/agg_conv_curve.h:29:0, from ../../include/ctrl/agg_bezier_ctrl.h:33, from agg_bezier_ctrl.cpp:27: ../../include/agg_curves.h: In destructor agg::curve3_div::~curve3_div(): ../../include/agg_curves.h:103:5: internal compiler error: in output_505, at config/rs6000/rs6000.md:12485 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. -- Summary: ICE in output_505, at config/rs6000/rs6000.md:12485 Product: gcc Version: unknown 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: ppc-suse-linux GCC host triplet: ppc-suse-linux GCC target triplet: ppc-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
[Bug c++/43142] ICE in output_505, at config/rs6000/rs6000.md:12485
--- Comment #1 from marcus at jet dot franken dot de 2010-02-22 16:56 --- Created an attachment (id=19934) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19934action=view) agg_bezier_ctrl.ii testcase, unreduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
[Bug target/43142] [4.5 Regression] ICE in output_505, at config/rs6000/rs6000.md:12485
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target Summary|ICE in output_505, at |[4.5 Regression] ICE in |config/rs6000/rs6000.md:1248|output_505, at |5 |config/rs6000/rs6000.md:1248 ||5 Target Milestone|--- |4.5.0 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
[Bug target/43142] [4.5 Regression] ICE in output_505, at config/rs6000/rs6000.md:12485
--- Comment #2 from marcus at jet dot franken dot de 2010-02-22 17:02 --- chroot /abuild/meissner/root.2/ grape:/usr/src/packages/BUILD/agg-2.5/src/ctrl gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64-suse-linux/4.5/lto-wrapper Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-cpu=default32 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.5.0 20100218 (experimental) [trunk revision 156860] (SUSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-22 17:10 --- Created an attachment (id=19935) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19935action=view) gcc45-pr43051.patch Updated patch, which includes lxo's fix, guality testcase and also a fix for infinite recursion discovered in redhat/gcc-4_4-branch backport. While this bootstraps/regtests on the trunk, on redhat/gcc-4_4-branch bootstrap fails due to endless alteration similar to PR42873 when compiling c-common.c (add_tlist) during profiledbootstrap. Haven't tried yet trunk profiledbootstrap. The alternation in this case is between: (gdb) p debug_rtx (var1-var_part[0].loc_chain-next-loc) (value/u:DI 90:90 @0x2a72678/0x28c5520) $30 = void (gdb) p debug_rtx (var1-var_part[0].loc_chain-loc) (mem/f:DI (value/s/u:DI 56:56 @0x2a722c8/0x2904028) [161 S8 A64]) $31 = void (gdb) p debug_rtx (var1-var_part[0].loc_chain-next-loc) (value/u:DI 90:90 @0x2a72678/0x28c5520) $32 = void (gdb) p debug_rtx (var1-var_part[0].loc_chain-next-next-loc) Cannot access memory at address 0x8 and (gdb) p debug_rtx (var2-var_part[0].loc_chain-loc) (mem/s/f:DI (value/s/u:DI 54:54 @0x2a722a8/0x2904078) [161 variable.next+0 S8 A64]) $33 = void (gdb) p debug_rtx (var2-var_part[0].loc_chain-next-loc) (mem/f:DI (value/s/u:DI 56:56 @0x2a722c8/0x2904028) [161 S8 A64]) $34 = void (gdb) p debug_rtx (var2-var_part[0].loc_chain-next-next-loc) (value/u:DI 90:90 @0x2a72678/0x28c5520) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-22 17:23 --- It is actually: dataflow difference found: old and new follow: (value/s/u:DI 54:54 @0x42b02e8/0x42a75c8) offset 0 (mem/f:DI (value/s/u:DI 56:56 @0x42b0308/0x42a7578) [161 S8 A64]) (value/u:DI 90:90 @0x42b06b8/0x41569c0) (value/s/u:DI 54:54 @0x42b02e8/0x42a75c8) offset 0 (mem/s/f:DI (value/s/u:DI 54:54 @0x42b02e8/0x42a75c8) [161 variable.next+0 S8 A64]) (mem/f:DI (value/s/u:DI 56:56 @0x42b0308/0x42a7578) [161 S8 A64]) (value/u:DI 90:90 @0x42b06b8/0x41569c0) alternating, it is quite weird that value 54 is in (mem (value 54)), guess need to find out in detail what's going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug middle-end/43083] [4.5 Regression] ICE with -fgraphite-identity with fall through return value
--- Comment #6 from spop at gcc dot gnu dot org 2010-02-22 17:40 --- Subject: Bug 43083 Author: spop Date: Mon Feb 22 17:40:23 2010 New Revision: 156970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156970 Log: Fix PR43083: Do not handle regions ending with multiple edges on the exit BB. 2010-02-22 Sebastian Pop sebastian@amd.com PR middle-end/43083 * graphite-scop-detection.c (create_single_exit_edge): Move the call to find_single_exit_edge to (create_sese_edges): ...here. Don't handle multiple edges exiting the function. (build_graphite_scops): Don't handle multiple edges exiting the function. * gcc.dg/graphite/pr43083.c: New. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr43083.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-scop-detection.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug c++/31754] Improve column number accuracy in error messages
--- Comment #22 from dodji at gcc dot gnu dot org 2010-02-22 17:46 --- Not working on this right now. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dodji 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=31754
[Bug other/42980] GCC parallel make install failures
--- Comment #6 from gary at intrepid dot com 2010-02-22 17:48 --- Created an attachment (id=19936) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19936action=view) parallel make -j6 install failure logs Attached, a collection of install logs run with SHELL=/bin/sh -x, where the install failed. The first log is for a libgomp install failure, and the rest are for libiberty. Note that it is difficult to reproduce the failures. I found that make -j6 led to more failures than make -j on our system. Also, couldn't get the install-target-libiberty target to fail, but perhaps didn't wait long enough. Instead, ran make -j6 install. Also, tried running this test on a ram fs, but couldn't make the installs fail, likely due to different interlocks. Similarly, the installs were more likely to fail on our RAID-ed disk subsystem, populated with high speed drives, than on a file system on a single drive. (These tests were run using the gcc-4.5-20100114 (gcc core) snapshot.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980
[Bug translation/36958] typos in french translation.
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dodji 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=36958
[Bug tree-optimization/43141] [4.5 Regression] Wrong debug information with IPA-SRA
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-02-22 18:01 --- Thanks for filing this separate PR. I am aware of this problem and it is quite high on my todo list. My first attempts to address this however don't bootstrap. I would like to get back to this by the end of the week but I think next week is a more realistic estimate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43141
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-22 18:17 --- Seems it is canonicalize_values_star that inserts the extra (mem (value 54:54)) every second run through bb 12 at the end of compute_bb_dataflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug c++/28584] Cast to pointer from integer of different size
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-22 19:04 --- Patch http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00891.html -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg00891.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2010-02-22 19:04:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #10 from jakub at gcc dot gnu dot org 2010-02-22 19:21 --- The next variable is said to live in value 90 and (mem (value 54)), that's where those two are equivalenced (canonicalize_values_star). The equivalencing between value 90 and value 54 is done in val_resolve: /* Map incoming equivalences. ??? Wouldn't it be nice if we just started sharing the location lists? Maybe a circular list ending at the value itself or some such. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug c++/43143] New: [c++0x] array value-initialization and variadics
This ought to compile, but doesn't:
templatetypename T
T declval();
templateclass T, class... Args
void test() {
T t(declvalArgs()...);
}
int main() {
testconst int(); // OK
testint[23](); // Error
}
--
Summary: [c++0x] array value-initialization and variadics
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43143
[Bug c++/43143] [c++0x] array value-initialization and variadics
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 19:25:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43143
[Bug c++/28584] Cast to pointer from integer of different size
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-22 19:49 --- Approved for GCC 4.6 http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00893.html -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||41998 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28584
[Bug c++/43144] New: Possible ADL bug in GCC 4.4.1
[copy-paste from email since I don't think Alisdair has gotten around to
submitting the bug]
I'm currently working at home with GCC 4.4.1 (MinGW build) and as you might
guess from the example, playing around with my own std lib implementation.
I'm currently failing to get my swap overload for arrays to use ADL, and I'm
running out of ideas. Want to run it past you in case I am pounding my head
against a GCC bug. Note that the non-array version picks up ADL correctly, as
can be seen by commenting out the line that chains the array-bases tests.
I'm leaning towards this being an ADL implementation bug, but I'm still not
100% confident in my understanding of the rules in this area so wanted to run
it past an expert before filing a bug report (which would be essentially the
same code cleaned up and without the 'pass' tests as noise)
If there is some subtle trick I am missing to enable ADL in this case, then I
fear our language is already far too subtle to live...
AlisdairM
main.cpp
#include cstddef
#include cstdio
#include type_traits
using std::size_t;
// DECLARE ALGORITHMS
//===
namespace std0x
{
template typename T
auto move(T) - typename std::remove_referenceT::type ;
// 20.3.2, swap:
templatetypename T
void swap(T a, T b);
template typename T, size_t N
void swap(T (a)[N], T (b)[N]);
}
// DEFINE ALGORITHMS
//===
template class T
auto std0x::move(T value) - typename std
::remove_referenceT::type {
return static_castT ( value );
}
// 20.3.2, swap:
templatetypename T
void std0x::swap(T a, T b) {
auto tmp( move(a) );
a = move(b);
b = move(tmp);
}
// Attempted workaround, guarantee namespace std0x on equal footing to ADL
namespace impl {
template typename T, size_t N
void swap(T (a)[N], T (b)[N]) {
for( size_t i = 0; i != N; ++i ) {
using namespace std0x;
// using std0x::swap;
swap(a[i], b[i]); // Why will this not trigger ADL? GCC bug or me?
}
}
}
template typename T, size_t N
void std0x::swap(T (a)[N], T (b)[N]) {
impl::swap(a, b); // attempt to trigger ADL
// for( size_t i = 0; i != N; ++i ) {
using std0x::swap;
// swap(a[i], b[i]);// Why will this not trigger ADL? GCC bug or me?
// }
}
// TEST HARNESS
//=
templatetypename T
auto test_array() - bool {
using std::printf;
using std0x::swap;
T const init_a[3]{1,2,3};
T const init_b[3]{4,5,6};
// initialize again from rvalues, rather than risk copy ctor
T a[3]{1,2,3};
T b[3]{4,5,6};
swap(a, b);
for(unsigned i = 0; i != 3; ++i ) {
if( a[i] != init_b[i]) {
printf(Error, bad 'a' element\n);
return false;
}
if( b[i] != init_a[i]) {
printf(Error, bad 'b' element\n);
return false;
}
}
return true;
}
templatetypename T
auto test() - bool {
using std::printf;
using std0x::swap;
T const init_a{13};
T const init_b{42};
// initialize again from rvalues, rather than risk copy ctor
T a{13};
T b{42};
swap(a, b);
if( a != init_b) {
printf(Error, bad 'a'\n);
return false;
}
if( b != init_a) {
printf(Error, bad 'b'\n);
return false;
}
return test_arrayT();
// return true;
}
// TEST DRIVER TYPES
// =
struct simple { int data; };
auto operator==(simple const a, simple const b ) - bool {
return a.data == b.data;
}
auto operator!=(simple const a, simple const b ) - bool {
return a.data != b.data;
}
struct move_only {
int data;
move_only(int a) : data{a} {}
move_only(move_only const ) = delete;
auto operator=(move_only const ) - move_only = delete;
move_only(move_only rhs) : data{rhs.data} { rhs.data = 0; }
auto operator=(move_only rhs) - move_only {
data = rhs.data;
rhs.data = 0;
return *this;
}
};
auto operator==(move_only const a, move_only const b ) - bool {
return a.data == b.data;
}
auto operator!=(move_only const a, move_only const b ) - bool {
return a.data != b.data;
}
namespace barrier
{
struct adl_only {
int data;
adl_only(int a) : data{a} {}
adl_only(adl_only const ) = delete;
auto operator=(adl_only const ) - move_only = delete;
};
void swap(adl_only a, adl_only b) {
using std0x::swap;
swap(a.data, b.data);
}
auto operator==(adl_only const a, adl_only const b ) - bool {
return a.data == b.data;
}
auto operator!=(adl_only const a, adl_only const b ) - bool {
return a.data != b.data;
}
}
// TEST DRIVER
// ===
int main()
{
printf( Hello world!\n );
int fails = 0;
if( !testint() ) ++fails;
if( !testsimple() ) ++fails;
if( !testmove_only() ) ++fails;
if( !testbarrier::adl_only() ) ++fails;
return fails;
}
--
Summary: Possible ADL bug in GCC 4.4.1
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #8 from abel at gcc dot gnu dot org 2010-02-22 20:10 --- (In reply to comment #7) Looks sensible, though unreachable block removal should be conditional on us removing an edge, not on lowering anything. Sure, I'd just make lower_eh_dispatch return a boolean for this and repost to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug c++/43145] New: local extern declaration gets wrong namespace
For this testcase:
namespace N {
void f();
}
void N::f()
{
extern int i;
extern void g();
i = 1;
g();
}
namespace N {
int i;
void g() { }
}
int main() { }
we end up with unsatisfied references to ::i and ::g.
--
Summary: local extern declaration gets wrong namespace
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code, patch
Severity: normal
Priority: P3
Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43145
[Bug c++/43145] local extern declaration gets wrong namespace
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-22 20:49 --- Created an attachment (id=19937) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19937action=view) patch for 4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43145
[Bug c++/43145] local extern declaration gets wrong namespace
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-22 20:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43145
[Bug middle-end/43083] [4.5 Regression] ICE with -fgraphite-identity with fall through return value
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 18:38:22 |2010-02-22 21:02:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #5 from drow at gcc dot gnu dot org 2010-02-22 21:06 --- (In reply to comment #3) * What is the purpose of insn 12 here? It looks to me like this is dead code, since r5 is restored in insn 38 (although, not knowing ARM so well, I may be wrong). I couldn't figure this out either. Where did it come from - was it so late that we never DCE'd it, or does something bizarre claim to be dependent on the value? Note how the sched1 pass has switched the two insns around. The register allocator now decides to use two new registers here, because r0 and r3 are both live. After RA, sched2 switches insn 9 and insn 10 again, and r2 and r3 become available in insn 10 -- but this is too late. Question for the ARM maintainer now is: Why does sched1 want to swap insns 9 and 10, when sched2 wants to swap them back again? I'm guessing, but presumably we want to separate the mul from the mla because they're dependent; the umull isn't. But I don't know what would swap them back again and that's probably the crux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug fortran/43146] New: Character constant declared in a module does not transfer correctly
Please compile the following snippet and watch that ch10 is printed as ASCII NUL (redirect to text file and see the produced characters, or use `./a.out | od -t x1' for even quicker result): module blahblah character(len=1), parameter :: ch10 = char(10) end module program testme3 use blahblah implicit none character(len=100) :: message !write(message, '(a,a)') ch10,'invars1m : enter jdtset=' write(6, '(a,a)') ch10,'invars1m : enter jdtset=' !write(6,'(A)') message end program It would have been OK if the ch10 is defined in the main program (or whatever subprogram block using it), but it is not OK if we import using use statement like above. This used not to be a problem with GCC 4.3.2. I am using Sabayon Linux 5.0 (derivative of Gentoo Linux) on an X86-64 platform. -- Summary: Character constant declared in a module does not transfer correctly Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug target/43118] vld4 and vst4 intrinsics are not handled correctly
--- Comment #3 from drow at gcc dot gnu dot org 2010-02-22 21:14 ---
Subject: Re: vld4 and vst4 intrinsics are not handled
correctly
On Fri, Feb 19, 2010 at 11:08:18AM -, rguenth at gcc dot gnu dot org wrote:
Likely because of the union in
__extension__ static __inline void __attribute__ ((__always_inline__))
vst4_u8 (uint8_t * __a, uint8x8x4_t __b)
{
union { uint8x8x4_t __i; __builtin_neon_oi __o; } __bu = { __b };
__builtin_neon_vst4v8qi ((__builtin_neon_qi *) __a, __bu.__o);
}
which does copy-initialization of __bu.
Right. FYI, my best idea to date of how to fix this is to convert the
multiple-vector types (like uint8x8x4_t) to builtin types. At that
point we can use the neon_reinterpret patterns to do the necessary
type punning without involving __builtin_neon_oi and the union.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-22 21:19 --- You may need to update to a newer version of gfortran. troutmask:sgk[207] gfc4x -o z j.f90 ./z | od -t x1 0000a 69 6e 76 61 72 73 31 6d 20 3a 20 65 6e 74 65 02072 20 6a 64 74 73 65 74 3d 0a 032 troutmask:sgk[208] gfc44 -o z j.f90 ./z | od -t x1 0000a 69 6e 76 61 72 73 31 6d 20 3a 20 65 6e 74 65 02072 20 6a 64 74 73 65 74 3d 0a 032 troutmask:sgk[209] gfc43 -o z j.f90 ./z | od -t x1 0000a 69 6e 76 61 72 73 31 6d 20 3a 20 65 6e 74 65 02072 20 6a 64 74 73 65 74 3d 0a 032 troutmask:sgk[211] gfc4x --version GNU Fortran (GCC) 4.5.0 20100111 (experimental) troutmask:sgk[212] gfc44 --version GNU Fortran (GCC) 4.4.3 20091216 (prerelease) troutmask:sgk[213] gfc43 --version GNU Fortran (GCC) 4.3.5 20091216 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug c/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-22 21:33 --- Subject: Bug 43125 Author: hjl Date: Mon Feb 22 21:33:21 2010 New Revision: 156976 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156976 Log: Move C tests for used attribute to c-c++-common. 2010-02-22 H.J. Lu hongjiu...@intel.com PR c/43125 * gcc.dg/attr-used-2.c: Moved to ... * c-c++-common/attr-used-2.c: Here. * gcc.dg/attr-used.c: Moved to ... * c-c++-common/attr-used.c: Here. Added: trunk/gcc/testsuite/c-c++-common/attr-used-2.c - copied unchanged from r156975, trunk/gcc/testsuite/gcc.dg/attr-used-2.c trunk/gcc/testsuite/c-c++-common/attr-used.c - copied unchanged from r156975, trunk/gcc/testsuite/gcc.dg/attr-used.c Removed: trunk/gcc/testsuite/gcc.dg/attr-used-2.c trunk/gcc/testsuite/gcc.dg/attr-used.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125
[Bug debug/27160] Debugging output forgets scope for typedefs.
--- Comment #3 from drow at gcc dot gnu dot org 2010-02-22 21:34 --- Works for me too, using GCC 4.4. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27160
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2010-02-22 21:39 --- Not sure if this can be qualified a regression, but still, making a release manager aware of this can't hurt, I guess. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #11 from mikpe at it dot uu dot se 2010-02-22 21:49 --- A recent 4.4 with the four unwind-related fixes I identified in CodeSourcery G++ lite 2009q3-67 applied still regresses in libjava as before with recent binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug c/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-22 21:57 --- Subject: Bug 43125 Author: hjl Date: Mon Feb 22 21:57:22 2010 New Revision: 156977 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156977 Log: Merge DECL_PRESERVE_P for C++. 2010-02-22 Mike Stump mikest...@comcast.net PR c++/43125 * decl.c (duplicate_decls): Merge DECL_PRESERVE_P. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125
[Bug c++/43126] at this point in file warnings are upside down
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-22 22:31 --- Subject: Bug 43126 Author: manu Date: Mon Feb 22 22:30:45 2010 New Revision: 156979 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156979 Log: 2010-02-22 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/43126 * c-typeck.c (convert_arguments): Print declaration location. * c-common.c (validate_nargs): Rename as builtin_function_validate_nargs. (check_builtin_function_arguments): Update. cp/ * typeck.c (convert_arguments): Update error message. testsuite/ * gcc.dg/cleanup-1.c: Update. * gcc.dg/func-args-1.c: Update. * gcc.dg/format/sentinel-1.c: Update. * g++.old-deja/g++.jason/scoping10.C: Update. * g++.old-deja/g++.ns/lookup5.C: Update. * g++.dg/ext/cleanup-1.C: Update. * g++.dg/parse/varmod1.C: Update. * g++.dg/parse/error33.C: Update. * g++.dg/expr/call3.C: Update. * g++.dg/func-args-1.C: New. Added: trunk/gcc/testsuite/g++.dg/func-args-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/expr/call3.C trunk/gcc/testsuite/g++.dg/ext/cleanup-1.C trunk/gcc/testsuite/g++.dg/parse/error33.C trunk/gcc/testsuite/g++.dg/parse/varmod1.C trunk/gcc/testsuite/g++.old-deja/g++.jason/scoping10.C trunk/gcc/testsuite/g++.old-deja/g++.ns/lookup5.C trunk/gcc/testsuite/gcc.dg/cleanup-1.c trunk/gcc/testsuite/gcc.dg/format/sentinel-1.c trunk/gcc/testsuite/gcc.dg/func-args-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug c++/43126] at this point in file warnings are upside down
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-22 22:32 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #18 from manu at gcc dot gnu dot org 2010-02-22 23:56 --- (In reply to comment #17) suggest having a c_ep_convert_and_check or similar function that handles excess precision: it would take the result type, the semantic result type (the type that gets used eventually to build an EXCESS_PRECISION_EXPR) and the value to convert. It would just call convert_and_check, ignoring the semantic type, *except* when the operand has integer type *and* the semantic type is non-NULL; in that case, it would first convert to the semantic type them to the result type. Wouldn't that change the normal result of promotion rules? Also, why call convert_and_check ignoring the semantic type and not just call convert? The excess precision type should be large enough to not cause any problem that needs checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-02-22 23:23 --- I don't think this should be P1, as getting the old behavior is apparently doable by hand, but I'm a big fan of backwards-compatibility and if the GCS haven't been updated then I think that GCC (as a GNU package) ought to try to follow that. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
-- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2010-02-21 15:39:13 |2010-02-23 00:27:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #19 from joseph at codesourcery dot com 2010-02-23 00:29 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work On Mon, 22 Feb 2010, manu at gcc dot gnu dot org wrote: --- Comment #18 from manu at gcc dot gnu dot org 2010-02-22 23:56 --- (In reply to comment #17) suggest having a c_ep_convert_and_check or similar function that handles excess precision: it would take the result type, the semantic result type (the type that gets used eventually to build an EXCESS_PRECISION_EXPR) and the value to convert. It would just call convert_and_check, ignoring the semantic type, *except* when the operand has integer type *and* the semantic type is non-NULL; in that case, it would first convert to the semantic type them to the result type. Wouldn't that change the normal result of promotion rules? No. The present logic is: convert (with convert_and_check) both operands to a common type, which may have excess precision; then, later, after producing the tree for the result of the operation, wrap that in an EXCESS_PRECISION_EXPR, using the semantic type, if there is a semantic type different from the type with excess precision. The proposed logic is the same, *except* that the conversion to a common type goes via the semantic type, *if* there is excess precision involved *and* the operand being converted had integer type. Also, why call convert_and_check ignoring the semantic type and not just call convert? The excess precision type should be large enough to not cause any problem that needs checking. Yes, you could just use convert for the second conversion (semantic type to type with excess precision). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug rtl-optimization/43147] New: SSE shuffle merge
I've noticed that GCC (my current version is 4.4.1) doesn't fully optimize SSE
shuffle merges, as seen in this example:
#include xmmintrin.h
extern void printv(__m128 m);
int main()
{
m = _mm_shuffle_ps(m, m, 0xC9); // Those two shuffles together swap
pairs
m = _mm_shuffle_ps(m, m, 0x2D); // And could be optimized to 0x4E
printv(m);
return 0;
}
This code generates the following assembly:
movaps .LC1, %xmm1
shufps $201, %xmm1, %xmm1
shufps $45, %xmm1, %xmm1; -- Both should merge to 78
movaps %xmm1, %xmm0
movaps %xmm1, -24(%ebp)
.LC0:
.long 1065353216 ; 1.0f
.long 1073741824 ; 2.0f
.long 1077936128 ; 3.0f
.long 1082130432 ; 4.0f
Would be nice to see it as an enhancement!
--
Summary: SSE shuffle merge
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: liranuna at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
[Bug rtl-optimization/43147] SSE shuffle merge
--- Comment #1 from liranuna at gmail dot com 2010-02-23 01:37 ---
It appears I am missing a line in the code I posted:
#include xmmintrin.h
extern void printv(__m128 m);
int main()
{
__m128 m = _mm_set_ps(1.0f, 2.0f, 3.0f, 4.0f);
m = _mm_shuffle_ps(m, m, 0xC9); // Those two shuffles together swap
pairs
m = _mm_shuffle_ps(m, m, 0x2D); // And could be optimized to 0x4E
printv(m);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #24 from debian-gcc at lists dot debian dot org 2010-02-23 01:37 --- thanks for the fixes. I don't care that much about the function markups. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug rtl-optimization/43147] SSE shuffle merge
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-23 01:42 --- I think that is because nothing simplifies: (vec_select:V4SF (vec_concat:V8SF (vec_select:V4SF (vec_concat:V8SF (reg:V4SF 62) (reg:V4SF 62)) (parallel [ (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 4 [0x4]) (const_int 7 [0x7]) ])) (vec_select:V4SF (vec_concat:V8SF (reg:V4SF 62) (reg:V4SF 62)) (parallel [ (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 4 [0x4]) (const_int 7 [0x7]) ]))) (parallel [ (const_int 1 [0x1]) (const_int 3 [0x3]) (const_int 6 [0x6]) (const_int 4 [0x4]) ])) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
[Bug rtl-optimization/43147] SSE shuffle merge
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-23 01:42 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-23 01:42:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
[Bug c++/43120] Diamond virtual inheritence with covariant return type confuses GCC
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-23 01:45 ---
Reduced a bit:
extern C void abort ();
struct A {
virtual void dummy() {}
};
struct B {
virtual B *clone() = 0;
};
struct C : public virtual B { };
struct D : public virtual B { };
struct E : public C, public D {
virtual E *clone() = 0;
};
struct F* fp;
struct F : public A, public E {
F(int) { fp = this; }
virtual E *clone() {
if (fp != this)
abort ();
}
};
int main() {
F *a = new F(123);
B *c = a;
c-clone();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
[Bug c++/43081] ICE with invalid in-class initializer
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-23 01:47 ---
This isn't specific to lambdas; this testcase gets the same ICE:
struct A
{
typedef void (F)();
F f = 1;
};
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[c++0x] ICE with invalid use|ICE with invalid in-class
|of lambda expression|initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43081
[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-23 01:50 --- ...which is a regression against 3.4, which says wa.C:4: error: invalid initializer for virtual method `void A::f()' -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.4 4.4.1 4.5.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2010-02-23 01:50:47 date|| Summary|ICE with invalid in-class |[4.3/4.4/4.5 regression] ICE |initializer |with invalid in-class ||initializer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43081
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-02-23 04:06 --- Created an attachment (id=19938) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19938action=view) smaller testcase Here is the smallest testcase I could get out of delta. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2010-02-23 06:01
---
Well, the GCS did change, and we did (mostly) update the default locations to
follow. However, as of now, the override methods don't all work the way the
configure --help output promises, and not all documentation gets put in
directories containing a coherent expansion of ${PACKAGE}.
Anyway, not marking this as regression then. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
