[Bug target/50304] poor code for accessing certain element of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||joey.ye at arm dot com --- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-04 08:06:16 UTC --- Confirmed. Still happening on Trunk as of 2013/03/04.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 08:17:56 UTC --- In any case, this looks like a clear backend bug, as it allows const_int 32 in the operand (through the use of M constraint), but then doesn't handle it at all in arm_output_shift (it forces use of %S3 on it and that requires 0 .. 31 constant, not 0 .. 32). And while the code has undefined behavior, if you never invoke it, you should still be able to have it in a valid program.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
Venkataramanan venkataramanan.kumar at amd dot com changed:
What|Removed |Added
CC||venkataramanan.kumar at amd
||dot com
--- Comment #5 from Venkataramanan venkataramanan.kumar at amd dot com
2013-03-04 08:27:31 UTC ---
While analyzing cases of threading through backedge.
GCC threads this case.
But does not thread this case.
int first;
void thread_backedge (void)
{
int i = 0;
do
{
if (first ==1)
{
foo ();
first=0;
}
bla ();
first =0;
} while (i++ 100);
}
int first;
void thread_backedge (void)
{
int i = 0;
do
{
if (first ==1)
{
foo ();
first=0;
}
else
{
bla ();
first =0;
}
} while (i++ 100);
}
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
--- Comment #6 from Venkataramanan venkataramanan.kumar at amd dot com
2013-03-04 08:34:06 UTC ---
(In reply to comment #5)
int first;
void thread_backedge (void)
{
int i = 0;
do
{
if (first ==1)
{
foo ();
first=0;
}
else
{
bla ();
first =0;
}
} while (i++ 100);
}
Can be jump threaded
if (first ==1)
{
foo();
}
else
{
L1:
bla()
}
first =0
i++
if i=99 goto L1
else return.
[Bug bootstrap/56509] [4.8 regression] gnattools build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56509 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Summary|[4.8 regression] gnattols |[4.8 regression] gnattools |build failure |build failure Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 08:48:59 UTC --- If the dependency cannot be removed, we'll probably need to link the gnattools with the C++ compiler.
[Bug bootstrap/56509] [4.8 regression] gnattools build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56509 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 09:08:31 UTC --- Created attachment 29577 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29577 gcc48-pr56509.patch Would it help to just move opts_obstack and opts_concat from opts.c to opts-common.c ?
[Bug target/56315] ARM: Improve use of 64-bit constants in logical operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56315 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-03-04 09:12:26 UTC --- Confirmed
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04
09:21:38 UTC ---
That reduced testcase actually compiles in a few seconds on a fast box, so
let's make it larger, then it will take a few years:
struct S { unsigned long s1; void **s2[0]; };
void **a, **b, **c, **d, **e, **f;
static void **
baz (long x, long y)
{
void **s = f;
*f = (void **) (y 8 | (x 0xff));
f += y + 1;
return s;
}
void bar (void);
void
foo (void)
{
void **g = b[4];
a = b[2];
b = b[1];
g[2] = e;
void **h = ((void **)
a)[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][66];
void **i = ((struct S *) h)-s2[4];
d = baz (4, 3);
d[1] = b;
d[2] = a;
d[3] = bar;
b = d;
g[1] = i[2];
a = g;
((void (*) (void)) (i[1])) ();
}
Alex, I think creating debug temporaries from within expand_debug_expr sounds
too complicated and furthermore at expand_debug_expr time we don't know yet
whether we'll actually return non-NULL for the whole expression or throw
everything away. So, what would you think about just keeping the code as is
and just after expand_debug_expr is called, we look at the VARIABLE_LOCATION
second operand and if the RTL nesting depth is deep enough (say 3-4 levels of
nesting?) in something that we'd be ok to split into debug temporaries (I'd say
RTX_*COMPARE/UNARY/*ARITH/TERNARY plus first operand of MEM), create debug
temporary for the subexpression and replace the operand with the debug
temporary. Otherwise, I'm afraid with TER we can end up with arbitrarily deep
DEBUG_INSN operands.
[Bug other/39851] gcc -Q --help=target does not list extensions selected by -march=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39851 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added CC||bratsinot at gmail dot com --- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org 2013-03-04 09:29:32 UTC --- *** Bug 56507 has been marked as a duplicate of this bug. ***
[Bug c++/56464] [C++11] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 09:45:14 UTC --- Sorry, I didn't notice that in 54383 we aren't in a class.
[Bug c++/56516] New: problem parsing templates: object.field 10 interpreted as ill formed template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56516
Bug #: 56516
Summary: problem parsing templates: object.field 10
interpreted as ill formed template
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: walter.mascaren...@gmail.com
// The following code illustrates what I consider to be a bug in
// g++ 4.7.2 with options -std=c++11 -g -Wall, with Qt 5.0.1 in Ubuntu 12.04
LTS
template typename T
inline
int field(T const)
{
return 0;
}
template typename T
struct Foo
{
int field;
};
template typename N
inline
void useFoo()
{
FooN foo;
// the next line causes the error parse error in template argument list
// g++ seems to be considering foo.field 10 as some ill formed
// invocation of the template function field
for( ; foo.field 10; )
{
}
}
int main()
{
useFooint();
return 0;
}
[Bug rtl-optimization/56494] [4.8 Regression] ICE in simplify_truncation, at simplify-rtx.c:619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56494 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 CC||mpolacek at gcc dot gnu.org Known to work||4.7.3 Summary|ICE in simplify_truncation, |[4.8 Regression] ICE in |at simplify-rtx.c:619 |simplify_truncation, at ||simplify-rtx.c:619 Ever Confirmed|0 |1 Known to fail||4.8.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-04 09:49:02 UTC --- Confirmed.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04
09:53:39 UTC ---
(In reply to comment #4)
This happens because 0 - 1 overflows in sizetype:
#6 0x00ac3e3d in size_binop_loc (loc=0, code=MINUS_EXPR,
arg0=0x76d65d60, arg1=0x76d65f00)
at /home/eric/svn/gcc/gcc/fold-const.c:1417
1417 return int_const_binop_1 (code, arg0, arg1, -1);
(gdb) p debug_tree(arg0)
integer_cst 0x76d65d60 type integer_type 0x76d710a8 sizetype
constant visited 0
$28 = void
(gdb) p debug_tree(arg1)
integer_cst 0x76d65f00 type integer_type 0x76d710a8 sizetype
constant visited 1
$29 = void
(gdb) frame 4
#4 0x00f28804 in force_fit_type_double (type=0x76d710a8,
cst=...,
overflowable=-1, overflowed=false) at /home/eric/svn/gcc/gcc/tree.c:1109
1109 tree t = make_node (INTEGER_CST);
(gdb) p cst
$30 = {low = 18446744073709551615, high = -1}
Now it didn't overflow on the 4.7 branch:
Breakpoint 2, int_const_binop (code=MINUS_EXPR, arg1=0x76d66f00,
arg2=0x76d790a0) at
/home/eric/svn/gcc-4_7-branch/gcc/fold-const.c:1085
1085 return t;
(gdb) p debug_tree(arg1)
integer_cst 0x76d66f00 type integer_type 0x76d77000 sizetype
constant visited 0
$4 = void
(gdb) p debug_tree(arg2)
integer_cst 0x76d790a0 type integer_type 0x76d77000 sizetype
constant visited 1
$5 = void
(gdb) p debug_tree(t)
integer_cst 0x76d66f20 type integer_type 0x76d77000 sizetype
constant visited -1
This low_bound - 1 idiom is pervasive in Ada and it will probably overflow
only
for 0 so we could add a kludge to size_binop_loc, similarly to the kludge that
exists in layout_type:
Index: fold-const.c
===
--- fold-const.c(revision 196253)
+++ fold-const.c(working copy)
@@ -1389,9 +1389,13 @@ size_binop_loc (location_t loc, enum tre
gcc_assert (int_binop_types_match_p (code, TREE_TYPE (arg0),
TREE_TYPE (arg1)));
- /* Handle the special case of two integer constants faster. */
+ /* Handle general case of two integer constants. For sizetype constant
+ calculations, we always want to know about overflow, even in the
+ unsigned case. */
if (TREE_CODE (arg0) == INTEGER_CST TREE_CODE (arg1) == INTEGER_CST)
{
+ int overflowable = -1;
+
/* And some specific cases even faster than that. */
if (code == PLUS_EXPR)
{
@@ -1404,6 +1408,11 @@ size_binop_loc (location_t loc, enum tre
{
if (integer_zerop (arg1) !TREE_OVERFLOW (arg1))
return arg0;
+
+ /* ??? We make an exception for 0 - 1 because it's an idiom
+used in length calculations for zero-based arrays. */
+ if (integer_zerop (arg0) integer_onep (arg1))
+ overflowable = 1;
}
else if (code == MULT_EXPR)
{
@@ -1411,10 +1420,7 @@ size_binop_loc (location_t loc, enum tre
return arg1;
}
- /* Handle general case of two integer constants. For sizetype
- constant calculations we always want to know about overflow,
-even in the unsigned case. */
- return int_const_binop_1 (code, arg0, arg1, -1);
+ return int_const_binop_1 (code, arg0, arg1, overflowable);
}
return fold_build2_loc (loc, code, type, arg0, arg1);
What do you think Richard?
What will the result be used for in this case? The result, usizetype_max,
is certainly not 0 - 1 == -1 as it is unsigned.
Adding kludges like that might work, but I'd rather try to fix callers
to ask more intelligent questions. That is,
+ /* ??? We make an exception for 0 - 1 because it's an idiom
+used in length calculations for zero-based arrays. */
+ if (integer_zerop (arg0) integer_onep (arg1))
+ overflowable = 1;
the length of an array is max-index - min-index + 1. What's the call
stack of this testcases case triggering the overflow?
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #15 from rguenther at suse dot de rguenther at suse dot de
2013-03-04 09:57:40 UTC ---
On Fri, 1 Mar 2013, aldyh at redhat dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #12 from Aldy Hernandez aldyh at redhat dot com 2013-03-01
19:17:32 UTC ---
--- Comment #11 from Ian Lance Taylor ian at airs dot com 2013-03-01
14:52:53 UTC ---
I suspect we can handle this case by observing that all the incoming values
to
the PHI node are constants.
Ian.
They're not all constants. In this particular case we have phis like this:
state_2 = PHI 0(6), state_3(12), 2(5)
I suppose we could chase the SSA def chain and if all the phi arguments
are either constants, or known to point to an SSA that has been
previously analyzed as constant, then we can avoid generating an
overflow. But we'd have to keep track of states across calls to
vrp_visit_phi_node. Is this what you had in mind, or am I
misunderstanding something?
Obviously, Richi's idea is much simpler :). With his suggestion we
could probably do with:
@@ -8111,11 +8109,9 @@ vrp_visit_phi_node (gimple phi)
if (cmp_max 0 || cmp_max 0)
{
if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
- || !vrp_var_may_overflow (lhs, phi))
+ || !vrp_var_may_overflow (lhs, phi)
+ || supports_overflow_infinity (TREE_TYPE (vr_result.max)))
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
- vr_result.max =
- positive_overflow_infinity (TREE_TYPE (vr_result.max));
}
And similarly for MIN. In the above, supports_overflow_infinity is just
there to make sure we have a CONSTANT_CLASS_P. If that's not needed, we
could even do:
if (cmp_max 0 || cmp_max 0)
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
and be done with it.
That's what I was suggesting.
As for strict-overflow warnings in VRP my suggestion was that we
want to warn only when a folding result _changes_. Thus, propagate
-fwrapv and -fno-wrapv in parallel using two lattices and compare
the final result. That's way less prone to false positives.
Richard.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:02:36 UTC --- Author: jakub Date: Mon Mar 4 10:02:26 2013 New Revision: 196424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196424 Log: PR middle-end/56461 * tree-vect-loop.c (destroy_loop_vec_info): For !clean_stmts, just set nbbs to 0 instead of having separate code path. (vect_analyze_loop_form): Call destroy_loop_vec_info with true instead of false as last argument if returning NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:06:27 UTC --- Author: jakub Date: Mon Mar 4 10:06:22 2013 New Revision: 196425 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196425 Log: PR middle-end/56461 * tree-vect-stmts.c (vectorizable_shift): Don't call create methods on vec_oprnds0 or vec_oprnds1 before loop, only call it on vec_oprnds1 right before pushing anything to it for scalar_shift_arg. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:08:05 UTC --- Author: jakub Date: Mon Mar 4 10:08:01 2013 New Revision: 196426 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196426 Log: PR middle-end/56461 * tree-vect-stmts.c (vectorizable_conversion): Don't call vec_oprnds0.create (1) for modifier == NONE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/56516] problem parsing templates: object.field 10 interpreted as ill formed template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56516 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 10:08:59 UTC --- Dup (-std=c++11 isn't needed) *** This bug has been marked as a duplicate of bug 10200 ***
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:09:05 UTC --- Author: jakub Date: Mon Mar 4 10:08:57 2013 New Revision: 196427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196427 Log: PR middle-end/56461 * tree-loop-distribution.c (ldist_gen): Call partition_free after each partitions.ordered_remove. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug c++/10200] Weird clash with same names in different scopes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||walter.mascarenhas at gmail ||dot com --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 10:09:01 UTC --- *** Bug 56516 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/56494] [4.8 Regression] ICE in simplify_truncation, at simplify-rtx.c:619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56494 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:11:39 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=192186
[Bug other/56517] New: ICE: in find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56517 Bug #: 56517 Summary: ICE: in find_valid_class, at reload.c:704 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, ra Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Blocks: 56183 Target: avr This ICE occurs for gcc.c-torture/compile/pr55921.c from the GCC test suite: /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c: In function 'foo': /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c:21:1: internal compiler error: in find_valid_class, at reload.c:704 0x850ee60 find_valid_class ../../../gcc.gnu.org/trunk/gcc/reload.c:704 0x851339d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class, machine_mode, machine_mode, int, int, int, reload_type) ../../../gcc.gnu.org/trunk/gcc/reload.c:1152 0x8519705 find_reloads(rtx_def*, int, int, int, short*) ../../../gcc.gnu.org/trunk/gcc/reload.c:4099 0x8528544 calculate_needs_all_insns ../../../gcc.gnu.org/trunk/gcc/reload1.c:1520 0x8528544 reload(rtx_def*, int) ../../../gcc.gnu.org/trunk/gcc/reload1.c:941 0x843f543 do_reload ../../../gcc.gnu.org/trunk/gcc/ira.c:4631 0x843f543 rest_of_handle_reload ../../../gcc.gnu.org/trunk/gcc/ira.c:4731 Please submit a full bug report, == configure == Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-target-optspace=yes --enable-languages=c,c++ Thread model: single gcc version 4.8.0 20130228 (experimental) (GCC) FAIL: gcc.c-torture/compile/pr55921.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 -flto (internal compiler error)
[Bug other/56517] ICE: in find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56517 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 Ever Confirmed|0 |1
[Bug libstdc++/54043] [C++11] cout nullptr does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 10:44:24 UTC --- Then I suppose that if anything this is library, not core, even if there are interactions. Is there an open LWG DR?
[Bug tree-optimization/56501] [4.6/4.7 Regression] gcc 4.6 ICE on noreturn function at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56501 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|gcc 4.6 ICE on noreturn |[4.6/4.7 Regression] gcc |function at -Os and above |4.6 ICE on noreturn ||function at -Os and above --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 10:44:42 UTC --- Which makes it a 4.6/4.7 regression.
[Bug rtl-optimization/56494] [4.8 Regression] ICE in simplify_truncation, at simplify-rtx.c:619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56494 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:46:34 UTC --- Created attachment 29578 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29578 gcc48-pr56494.patch Untested fix.
[Bug middle-end/56504] -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 10:48:16 UTC --- Confirmed. The array versions could be used by loop distribution pattern detection.
[Bug libstdc++/56505] [4.7 Regression] cannot construct std::thread with pointer to member and non-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56505 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug libstdc++/54043] [LWG 2221] cout nullptr does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |SUSPENDED Summary|[C++11] cout nullptr |[LWG 2221] cout nullptr |does not work |does not work --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 10:50:26 UTC --- Ah great, thanks Daniel.
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 10:52:35 UTC --- Why TER into debug-insns at all?
[Bug libstdc++/54043] [C++11] cout nullptr does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 --- Comment #13 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-03-04 10:46:27 UTC --- (In reply to comment #12) Then I suppose that if anything this is library, not core, even if there are interactions. Is there an open LWG DR? You may want to refer to: http://cplusplus.github.com/LWG/lwg-active.html#2221
[Bug middle-end/56504] -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-04 10:53:07 UTC --- (In reply to comment #0) Unfortunately, no further documentation is available, telling whether, e.g., src and dst may be the same or not. AMD told me that src and dst are permitted to be the same.
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 10:56:14 UTC --- Because TERed stmts won't be expanded, so there is nothing to refer to. Furthermore, in many cases expand_debug_expr relies on seeing the inner operand.
[Bug tree-optimization/56270] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 10:56:51 UTC --- Confirmed. Probably a latent issue on trunk. Mine.
[Bug rtl-optimization/56514] Using -fdisable-rtl-ira makes gcc crash (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56514 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 10:58:55 UTC --- Yeah.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|location references block |[4.8 Regression] location |not in block tree, |references block not in |verify_gimple failed (LTO + |block tree, verify_gimple |profile)|failed (LTO + profile) Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 11:03:04 UTC --- Confirmed. I'll try to nail it down.
[Bug c++/56518] New: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56518 Bug #: 56518 Summary: Segmentation fault Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: elisey.za...@gmail.com Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.11, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2) COLLECT_GCC_OPTIONS='-std=c++0x' '-save-temps' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -std=c++0x -fpch-preprocess -o test.ii ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/backward /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c++0x' '-save-temps' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++0x -version -o test.s GNU C++ (Gentoo 4.6.3 p1.11, pie-0.5.2) version 4.6.3 (x86_64-pc-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.1.0, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Gentoo 4.6.3 p1.11, pie-0.5.2) version 4.6.3 (x86_64-pc-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.1.0, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 64306da8006a5416135a72df2a9600e1 test.cpp: In function ‘int main(int, char**)’: test.cpp:9:36: internal compiler error: Segmentation fault
[Bug c++/56518] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56518 --- Comment #1 from Elisey Zanko elisey.zanko at gmail dot com 2013-03-04 11:10:09 UTC --- Created attachment 29579 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29579 A preprocessed file causing bug
[Bug fortran/56519] New: DO CONCURRENT: wrongly accepts calls to impure intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56519 Bug #: 56519 Summary: DO CONCURRENT: wrongly accepts calls to impure intrinsics Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Based on https://groups.google.com/d/topic/comp.lang.fortran/cZ1KQ_2Zt_c/discussion The following program is accepted, but the intrinsic procedure is IMPURE. (F2008:) C825 A reference to a nonpure procedure shall not appear within a DO CONCURRENT construct. Note: All standard intrinsic functions are pure. (cf. F2008, 13.1). But only some subroutines are pure. However, in intrinsics.c, the used intrinsic subroutine is marked as CLASS_IMPURE! And in principle, gfc_intrinsic_sub_interface checks for this – but it does not seem to work, here. While it triggers in a URE subroutine. implicit none integer :: i real :: array(123), val do concurrent (i = 1:123) call random_number (val) ! INVALID: Impure but accepted array(i) = val !call foo(array) ! OK; rejected with: ! Subroutine call to 'foo' in DO CONCURRENT block at (1) is not PURE end do end
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-04 11:12:42 UTC --- Author: gjl Date: Mon Mar 4 11:12:30 2013 New Revision: 196428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196428 Log: PR testsuite/52641 PR tree-optimization/52631 * gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr52631.c
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-04 11:12:42 UTC --- Author: gjl Date: Mon Mar 4 11:12:30 2013 New Revision: 196428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196428 Log: PR testsuite/52641 PR tree-optimization/52631 * gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr52631.c
[Bug fortran/56519] DO CONCURRENT: wrongly accepts calls to impure intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56519 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-04 11:18:42 UTC --- The DO CONCURRENT diagnostic is done in resolve.c's pure_subroutine, called by (e.g.) resolve_unknown_s – except for intrinsics. FORALL is not affected as CALL is not allowed in FORALL.
[Bug c++/56518] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56518 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|elisey.zanko at gmail dot | |com | Known to work||4.7.0, 4.8.0 Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 11:20:01 UTC --- Both 4.7 and mainline are fine.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 11:29:16 UTC --- What will the result be used for in this case? The result, usizetype_max, is certainly not 0 - 1 == -1 as it is unsigned. It's used for the upper bound of variable-sized arrays: /* Finally we use (hb = lb) ? hb : lb - 1 for the upper bound in all the other cases. Note that, here as well as above, the condition used in the comparison must be equivalent to the condition (length != 0). This is relied upon in order to optimize array comparisons in compare_arrays. */ else gnu_high = build_cond_expr (sizetype, build_binary_op (GE_EXPR, boolean_type_node, gnu_orig_max, gnu_orig_min), gnu_max, size_binop (MINUS_EXPR, gnu_min, size_one_node)); The result wraps around but that's fine; we just don't want the overflow. Adding kludges like that might work, but I'd rather try to fix callers to ask more intelligent questions. That is, + /* ??? We make an exception for 0 - 1 because it's an idiom +used in length calculations for zero-based arrays. */ + if (integer_zerop (arg0) integer_onep (arg1)) + overflowable = 1; the length of an array is max-index - min-index + 1. What's the call stack of this testcases case triggering the overflow? Yes, the formula for the upper bound is designed to yield a length of zero if the upper bound is lower than the lower bound. size_binop is called from ada/gcc-interface/decl.c:gnat_to_gnu_entity.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 12:10:32 UTC --- We inline __gcov_indirect_call_profiler: 2 foo.o 4 211 1fa7ccac167ed480 PREVAILING_DEF foo 218 1fa7ccac167ed480 RESOLVED_EXEC __gcov_merge_add 220 1fa7ccac167ed480 RESOLVED_IR __gcov_indirect_call_profiler 229 1fa7ccac167ed480 RESOLVED_EXEC __gcov_init bar.o 2 165 fdbab47f5593e985 PREVAILING_DEF_IRONLY __gcov_indirect_call_profiler 186 fdbab47f5593e985 PREVAILING_DEF_IRONLY bar We build the function decls via build_fn_decl which ends up using input_location of the first random function we are processing. But that doesn't seem to be the issue after all ... The issue is that we do in expand_call_inline: /* Build a block containing code to initialize the arguments, the actual inline expansion of the body, and a label for the return statements within the function to jump to. The type of the statement expression is the return type of the function call. */ id-block = make_node (BLOCK); BLOCK_ABSTRACT_ORIGIN (id-block) = fn; BLOCK_SOURCE_LOCATION (id-block) = input_location; if (gimple_block (stmt)) prepend_lexical_block (gimple_block (stmt), id-block); that is, we only link the copied BLOCK tree into the caller BLOCK tree if the call stmt had an associated BLOCK. Which isn't the case for the calls created by the middle-end (profile instrumentation in this case).
[Bug c++/56518] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56518
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
Known to fail||4.6.4
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04
12:52:43 UTC ---
The ICE is
#0 0x007bafa2 in c_common_signed_or_unsigned_type (unsignedp=1,
type=0x0)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/c-family/c-common.c:3018
#1 0x007bfe47 in shorten_compare (op0_ptr=0x7fffcb80,
op1_ptr=0x7fffcb78, restype_ptr=0x7fffcb70,
rescode_ptr=0x7fffcb6c)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/c-family/c-common.c:3567
3562 else if (unsignedp0 == unsignedp1 real1 == real2
3563TYPE_PRECISION (TREE_TYPE (primop0)) TYPE_PRECISION
(*restype_ptr)
3564TYPE_PRECISION (TREE_TYPE (primop1)) TYPE_PRECISION
(*restype_ptr))
3565{
3566 type = common_type (TREE_TYPE (primop0), TREE_TYPE (primop1));
3567 type = c_common_signed_or_unsigned_type (unsignedp0
3568 || TYPE_UNSIGNED
(*restype_ptr),
3569 type);
which ends up calling cp_common_type which has (still also on trunk):
static tree
cp_common_type (tree t1, tree t2)
{
...
if (SCOPED_ENUM_P (t1) || SCOPED_ENUM_P (t2))
{
if (TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2))
return build_type_attribute_variant (t1, attributes);
else
return NULL_TREE;
}
but common_type () is not expected to return NULL_TREE.
ISTR this bug, it got fixed for 4.7+.
[Bug tree-optimization/56270] [4.6/4.7/4.8 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.3.6 Target Milestone|--- |4.6.4 Summary|loop over array of struct |[4.6/4.7/4.8 Regression] |float causes compiler |loop over array of struct |error: segmentation fault |float causes compiler ||error: segmentation fault --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 13:05:19 UTC --- Also ICEs on trunk for me with -O1 -ftree-vectorize. Works with 4.3 at least.
[Bug tree-optimization/56270] [4.6/4.7/4.8 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04
13:13:58 UTC ---
Reduced testcase:
typedef struct {
float l, h;
} tFPinterval;
tFPinterval X[1024];
tFPinterval Y[1024];
tFPinterval Z[1024];
void Compute(void)
{
int d;
for (d= 0; d 1024; d++)
{
Y[d].l= X[d].l + X[d].h;
Y[d].h= Y[d].l;
Z[d].l= X[d].l;
Z[d].h= X[d].h;
}
}
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-03-04 13:24:04 UTC --- The wrong-code with -O3 -fno-tree-coalesce-vars stopped occurring at r190284, Richard Biener's large Allow anonymous SSA names patch. The patch description mentions minor code generation differences, but it doesn't appear to contain actual wrong code fixes so the underlying issue may still be latent on trunk.
[Bug fortran/56520] New: Syntax error causes misleading message: Invalid character in name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520 Bug #: 56520 Summary: Syntax error causes misleading message: Invalid character in name Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl An extra parenthesis at the end of a statement leads to the error message: Invalid character in name at (1) The message has nothing to do with the actual error. Here is a small program to reproduce it: ! misleading.f90 -- ! Syntax error is reported with a misleading message ! program misleading implicit none real :: a, b, c a = 1.0 b = 1.0 c = exp(-a*b) ) end program misleading
[Bug debug/49828] reversed order of inlined function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49828 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com 2013-03-04 14:14:23 UTC --- Filed for GDB: http://sourceware.org/bugzilla/show_bug.cgi?id=15223
[Bug tree-optimization/56270] [4.6/4.7/4.8 Regression] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04
14:19:37 UTC ---
We don't properly vectorize the 2nd reference to the load (this time
unpermuted). When vectorizing the 2nd SLP instance with that reference
we encounter
/* Check if the chain of loads is already vectorized. */
if (STMT_VINFO_VEC_STMT (vinfo_for_stmt (first_stmt)))
{
*vec_stmt = STMT_VINFO_VEC_STMT (stmt_info);
return true;
}
but that leaves SLP_TREE_VEC_STMTS unpopulated. Shared nodes between SLP
instances seem to be somewhat fragile ...
Especially in this case in which even wrong-code would occur as the
instances do not share the same permutation.
if (slp
!SLP_INSTANCE_LOAD_PERMUTATION (slp_node_instance).exists ()
first_stmt != SLP_TREE_SCALAR_STMTS (slp_node)[0])
first_stmt = SLP_TREE_SCALAR_STMTS (slp_node)[0];
also doesn't make much sense to me - instead it probably should be asserted:
if (slp
first_stmt != SLP_TREE_SCALAR_STMTS (slp_node)[0])
gcc_assert (SLP_INSTANCE_LOAD_PERMUTATION (slp_node_instance).exists
())
but bb-slp-29.c asserts here.
Easiest is for now to clear STMT_VINFO_VEC_STMT for all loads after
scheduling an SLP instance.
[Bug tree-optimization/56521] New: [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 Bug #: 56521 Summary: [4.8 Regression] Uninitialized value_id Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: vr...@gcc.gnu.org Target: x86_64-linux valgrind --track-origins=yes --leak-check=full --db-attach=yes ./cc1 \ -fno-diagnostics-show-caret -O2 -w -o pr3.s \ /usr/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr3.c shows: ==32184== Conditional jump or move depends on uninitialised value(s) ==32184==at 0xBCCF6D: add_to_value(unsigned int, pre_expr_d*) (tree-ssa-pre.c:577) ==32184==by 0xBD519A: compute_avail() (tree-ssa-pre.c:3846) ==32184==by 0xBD7C1A: do_pre() (tree-ssa-pre.c:4711) ==32184==by 0x977D9B: execute_one_pass(opt_pass*) (passes.c:2330) ==32184==by 0x977F8F: execute_pass_list(opt_pass*) (passes.c:2378) ==32184==by 0x977FC0: execute_pass_list(opt_pass*) (passes.c:2379) ==32184==by 0x6963B7: expand_function(cgraph_node*) (cgraphunit.c:1640) ==32184==by 0x696872: expand_all_functions() (cgraphunit.c:1744) ==32184==by 0x6972FC: compile() (cgraphunit.c:2042) ==32184==by 0x69747B: finalize_compilation_unit() (cgraphunit.c:2119) ==32184==by 0x5326B7: c_write_global_declarations() (c-decl.c:10118) ==32184==by 0xA68DEE: compile_file() (toplev.c:557) ==32184== Uninitialised value was created by a client request ==32184==at 0x6048D6: pool_alloc(alloc_pool_def*) (alloc-pool.c:327) ==32184==by 0xBF7201: visit_reference_op_call(tree_node*, gimple_statement_d*) (tree-ssa-sccvn.c:2738) ==32184==by 0xBF91FC: visit_use(tree_node*) (tree-ssa-sccvn.c:3503) ==32184==by 0xBF982E: process_scc(vectree_node*, va_heap, vl_ptr) (tree-ssa-sccvn.c:3643) ==32184==by 0xBF9C64: extract_and_process_scc_for_name(tree_node*) (tree-ssa-sccvn.c:3727) ==32184==by 0xBF9E0F: DFS(tree_node*) (tree-ssa-sccvn.c:3781) ==32184==by 0xBFA8F5: run_scc_vn(vn_lookup_kind) (tree-ssa-sccvn.c:4027) ==32184==by 0xBD7BF5: do_pre() (tree-ssa-pre.c:4701) ==32184==by 0x977D9B: execute_one_pass(opt_pass*) (passes.c:2330) ==32184==by 0x977F8F: execute_pass_list(opt_pass*) (passes.c:2378) ==32184==by 0x977FC0: execute_pass_list(opt_pass*) (passes.c:2379) ==32184==by 0x6963B7: expand_function(cgraph_node*) (cgraphunit.c:1640) and plenty of other errors. visit_reference_op_call doesn't initialize value_id field, before http://gcc.gnu.org/viewcvs?root=gccview=revrev=189323 richi said value_id was supposed to be initialized later on through set_value_id_for_result but as lhs here is NULL or not SSA_NAME, that function doesn't do anything.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2013-03-04 15:12:25 UTC --- On Mon, 4 Mar 2013, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 11:29:16 UTC --- What will the result be used for in this case? The result, usizetype_max, is certainly not 0 - 1 == -1 as it is unsigned. It's used for the upper bound of variable-sized arrays: /* Finally we use (hb = lb) ? hb : lb - 1 for the upper bound in all the other cases. Note that, here as well as above, the condition used in the comparison must be equivalent to the condition (length != 0). This is relied upon in order to optimize array comparisons in compare_arrays. */ else gnu_high = build_cond_expr (sizetype, build_binary_op (GE_EXPR, boolean_type_node, gnu_orig_max, gnu_orig_min), gnu_max, size_binop (MINUS_EXPR, gnu_min, size_one_node)); The result wraps around but that's fine; we just don't want the overflow. Hm, if hb lb - what kind of pair do you expect? The only case where lb - 1 is the upper bound (whatever upper bound is for an empty array ...) - isn't lb - 1 always equal to hb in that case, thus are not hb and lb one element apart for empty arrays (length == 0)? So just do ... gnu_high = gnu_orig_max; ? Maybe I'm missign something ... Richard.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #21 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 15:30:50 UTC --- Reopened, the fix breaks LTO bootstrap with Ada: /tmp/cc5Nhl9J.s: Assembler messages: /tmp/cc5Nhl9J.s:6206: Error: symbol `.LC0' is already defined /tmp/cc5Nhl9J.s:6219: Error: symbol `.LC0' is already defined /tmp/cc5Nhl9J.s:6996: Error: symbol `.LC0' is already defined make[4]: *** [/tmp/ccuFb8kg.ltrans2.ltrans.o] Error 1 make[4]: *** Waiting for unfinished jobs /tmp/ccf05Tt7.s: Assembler messages: /tmp/ccf05Tt7.s:5618: Error: symbol `.LC5' is already defined /tmp/ccf05Tt7.s:5629: Error: symbol `.LC5' is already defined make[4]: *** [/tmp/ccuFb8kg.ltrans8.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /home/eric/install/gcc/x86_64-suse-linux/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [gnatbind] Error 1 make[3]: *** Waiting for unfinished jobs The reason for the name collision seems obvious enough... I still think the best solution is not to fiddle with the alignment of DECL_IN_CONSTANT_POOL objects at this point, since the machinery assumes that their alignment doesn't matter (or more precisely that they only need to have the alignment of their type, which is correct as far as I know).
[Bug lto/56495] ICE in lto_output_tree with -g -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56495 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-04 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 15:33:20 UTC --- Can you please specify how you configured GCC? It seems to work for me, that is - I get past compile-stage where I then have to add -r -nostdlib to continue with WPA and LTRANS stage which also work fine for me. Can you also provide the output you get when adding -v to the command that fails for you? Thanks.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 15:38:53 UTC --- Hm, if hb lb - what kind of pair do you expect? The only case where lb - 1 is the upper bound (whatever upper bound is for an empty array ...) - isn't lb - 1 always equal to hb in that case, thus are not hb and lb one element apart for empty arrays (length == 0)? No, you can have superflat arrays and they need to have zero length (instead of a negative one) in Ada, hence the formula.
[Bug tree-optimization/56522] New: [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 Bug #: 56522 Summary: [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz 196263 ASSIGNMENT : 57.274 : 217.94 : 56.53 196260 ASSIGNMENT : 62.83 : 239.08 : 62.01 4.6 branch ASSIGNMENT : 64.311 : 244.72 : 63.47 196263: 2013-02-25 Richard Biener rguent...@suse.de PR tree-optimization/56175 * tree-ssa-forwprop.c (hoist_conversion_for_bitop_p): New predicate, split out from ... (simplify_bitwise_binary): ... here. Also guard the conversion of (type) X op CST to (type) (X op ((type-x) CST)) with it. * gcc.dg/tree-ssa/forwprop-24.c: New testcase. -O3 -g0 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math -fno-PIE -fno-exceptions -fno-stack-protector -static CPU Sandy Bridge
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 15:42:18 UTC --- (In reply to comment #21) Reopened, the fix breaks LTO bootstrap with Ada: /tmp/cc5Nhl9J.s: Assembler messages: /tmp/cc5Nhl9J.s:6206: Error: symbol `.LC0' is already defined /tmp/cc5Nhl9J.s:6219: Error: symbol `.LC0' is already defined /tmp/cc5Nhl9J.s:6996: Error: symbol `.LC0' is already defined make[4]: *** [/tmp/ccuFb8kg.ltrans2.ltrans.o] Error 1 make[4]: *** Waiting for unfinished jobs /tmp/ccf05Tt7.s: Assembler messages: /tmp/ccf05Tt7.s:5618: Error: symbol `.LC5' is already defined /tmp/ccf05Tt7.s:5629: Error: symbol `.LC5' is already defined make[4]: *** [/tmp/ccuFb8kg.ltrans8.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /home/eric/install/gcc/x86_64-suse-linux/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [gnatbind] Error 1 make[3]: *** Waiting for unfinished jobs The reason for the name collision seems obvious enough... I still think the best solution is not to fiddle with the alignment of DECL_IN_CONSTANT_POOL objects at this point, since the machinery assumes that their alignment doesn't matter (or more precisely that they only need to have the alignment of their type, which is correct as far as I know). How can the patch cause a name collision when all the patch does is avoid creating a new decl...? They are static and thus should be mangled. Well, and if we want a new decl just to re-assign a unique name here then we want to copy over alignment information. That is, LTO should handle constant-pool entries by _not_ streaming the decl then. Honza, how are those supposed to make the symtab - WPA - LTRANS transition anyway?
[Bug tree-optimization/56521] [4.8 Regression] Uninitialized value_id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56521 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 15:43:27 UTC --- Confirmed.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de 2013-03-04 15:45:09 UTC --- On Mon, 4 Mar 2013, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 15:38:53 UTC --- Hm, if hb lb - what kind of pair do you expect? The only case where lb - 1 is the upper bound (whatever upper bound is for an empty array ...) - isn't lb - 1 always equal to hb in that case, thus are not hb and lb one element apart for empty arrays (length == 0)? No, you can have superflat arrays and they need to have zero length (instead of a negative one) in Ada, hence the formula. Btw, it's easy to not get the overflow for this formula by using fold_build2 instead of size_binop.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 15:49:35 UTC --- So, can the Ada FE be changed to use that? Hacks like this belong with a comment in the FE that needs them IMHO.
[Bug c/56523] New: -Wunitialized is described to be enabled -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523 Bug #: 56523 Summary: -Wunitialized is described to be enabled -Wall Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: corentinja...@gmail.com The online docs ( http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html ) and the gcc 4.7 man page state incorrectly that -Wall enable -Wunitialized. The docs also state -Wunitialized is enable by -Wextra, and that is the observed and correct behaviour.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2013-03-04 16:06:25 UTC --- We build the function decls via build_fn_decl which ends up using input_location of the first random function we are processing. But that doesn't seem to be the issue after all ... The issue is that we do in expand_call_inline: /* Build a block containing code to initialize the arguments, the actual inline expansion of the body, and a label for the return statements within the function to jump to. The type of the statement expression is the return type of the function call. */ id-block = make_node (BLOCK); BLOCK_ABSTRACT_ORIGIN (id-block) = fn; BLOCK_SOURCE_LOCATION (id-block) = input_location; if (gimple_block (stmt)) prepend_lexical_block (gimple_block (stmt), id-block); that is, we only link the copied BLOCK tree into the caller BLOCK tree if the call stmt had an associated BLOCK. Which isn't the case for the calls created by the middle-end (profile instrumentation in this case). Hmm, yeah, thre are few cases where we sort of assume that each call has a block. I wonder what should we do here, just prepend the block for the outermost block of the caller function then? In general however LTO of libgcov is not supposed to work same way as libgcc or glibc does not work. We can't LTO yet any functions where middle-end invent calls post LTO streaming. I blieve we still do so for libgcov for fork calls. Honza
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #23 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 16:10:53 UTC --- How can the patch cause a name collision when all the patch does is avoid creating a new decl...? They are static and thus should be mangled. They clearly aren't. Well, and if we want a new decl just to re-assign a unique name here then we want to copy over alignment information. That is, LTO should handle constant-pool entries by _not_ streaming the decl then. Honza, how are those supposed to make the symtab - WPA - LTRANS transition anyway? The irony being that the initial implementation didn't stream the DECL but was changed because the varpool was just starting to being streamed as well. :-)
[Bug c/56523] -Wunitialized is described to be enabled by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04
16:16:16 UTC ---
On which basis do you think it doesn't? In practice, for a stupid example like
the below, with -Wall:
int main()
{
int a;
return a;
}
I get:
test.c: In function ‘main’:
test.c:4:3: warning: ‘a’ is used uninitialized in this function
[-Wuninitialized]
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 16:18:21 UTC --- So, can the Ada FE be changed to use that? Hacks like this belong with a comment in the FE that needs them IMHO. The 2 other related hacks are in stor-layout.c line 2214 and 2236 though and there are a lot of calls to size_binop in the Ada front-end. IMO this one is really benign compared to the others.
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #9 from Adam Seering aseering at vertica dot com 2013-03-04 16:43:07 UTC --- Thanks! I'm curious if the fix is likely to get backported? Also, is there a straightforward workaround? Would you expect it to trigger with all cases of a va_list not allocated on the stack?
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law law at redhat dot com 2013-03-04 16:55:27 UTC --- WRT the second example in c#5. See thread_across_edge where we refuse to thread across a DFS_EDGE_BACK when one of the arguments in the conditional is set in the block. This is the equivalency problem I mentioned in IRC. When you traverse the backedge, you have to be very careful because equivalences created when you traversed from outside the loop into the loop are no longer valid once you traverse the backedge. Or at least that's my best memory of the situation.
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506 --- Comment #3 from Michael Mehlich mmehlich at semanticdesigns dot com 2013-03-04 16:58:45 UTC --- Considering that based on 14.5.3(5) a template member declaration XYZT...,T...::type x; with T bound to int,bool,char must expand to XYZint,bool,char,int, YZint,bool,char,bool, YZint,bool,char,char::type x; I'd consider it rather counter-intuitive if I cannot get a match as described in my original message. Does the standard actually specify how the matching process works in detail in the presence of variadic templates? Going through the template section, I haven't found anything definite that would put light onto this issue (though I might have missed it). I can't really understand your because it is not followed by ...; after all, in XYZT..., U... the parameter pack U is also not immediately followed by a ..., so why is that case ok but my original one isn't? It is pretty easy to implement a matcher that successfully matches the case in the original message, so I don't think the standard has any excuse not to consider this a successful match, either. Notwithstanding that, the standards committee might have decided otherwise. If so, where does it say so in the standard, resp. how can I conclude this from what I can find in there? -- Michael
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 17:02:23 UTC --- The fix seems extremely safe, so I think backporting to 4.6 and 4.7 makes sense.
[Bug c++/56464] [C++11] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 17:12:47 UTC --- Author: jason Date: Mon Mar 4 17:12:32 2013 New Revision: 196437 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196437 Log: PR c++/56464 PR c++/54383 * semantics.c (lambda_expr_this_capture): Handle NSDMI and non-class scopes. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/54383] Internal compiler error for lamba function using this- with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 17:12:48 UTC --- Author: jason Date: Mon Mar 4 17:12:32 2013 New Revision: 196437 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196437 Log: PR c++/56464 PR c++/54383 * semantics.c (lambda_expr_this_capture): Handle NSDMI and non-class scopes. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/56464] [C++11] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 17:14:22 UTC --- Fixed for 4.8.
[Bug c++/54383] Internal compiler error for lamba function using this- with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 17:14:33 UTC --- Fixed for 4.8.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-04 17:15:25 UTC --- (In reply to comment #13) A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). I have verified in the debugger that SRA does not create any new SSA names on its own, all of them are created by renaming after the pass finishes (i.e. by TODO_update_ssa). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well. I'm not sure what you mean. SRA does not process debug stmts but it now creates them. The re-namer is apparently clever enough not to create a PHI node and thus a new SSA name because of debug statements, yet it manages to create them in a different order, probably because it sees uses were there are none without debug statements. Can that be the case? Is creating such uses really a bug?
[Bug middle-end/56524] New: Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524
Bug #: 56524
Summary: Compiler ICE when compiling with -mips16
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@gcc.gnu.org
CC: al...@redhat.com
Target: mips*-*-*
This test program (from glibc) generates an ICE when compiled with -mips16.
The internal error we are hitting was part of the fix for pr52555. The test
program is a bit finicky, I think it is dependent on the order that GCC
processes the functions. I don't know if this is a bug in the generic code
or in mips specific code and how mips handles the mips16 flag.
% cat mktime.i
unsigned int __bswap_32 (unsigned int __bsx)
{ return __builtin_bswap32 (__bsx); }
#pragma GCC optimize (wrapv)
inline int leapyear (long long int year)
{
return
((year 3) == 0
(year % 100 != 0
|| ((year / 100) 3) == (- (1900 / 100) 3)));
}
mips-mti-linux-gnu-gcc -c -mips16 mktime.i
mktime.i:7:1: internal compiler error: in save_optabs_if_changed, at
optabs.c:6221
{
^
0x8198e5 save_optabs_if_changed(tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/optabs.c:6221
0x4b090b decl_attributes(tree_node**, tree_node*, int)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/attribs.c:545
0x4cf728 start_function(c_declspecs*, c_declarator*, tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c/c-decl.c:7727
0x557114 c_common_parse_file()
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/56523] -Wunitialized is described to be enabled by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523
--- Comment #2 from corentinjabot at gmail dot com 2013-03-04 17:33:26 UTC ---
Actually after a few more test it works correctly but the statement This
enables some extra warning flags that are not enabled by -Wall. is confusing
since the to set of options overlap.
I also tested with the following c++ snippet:
#include iostream
class A {
public:
A() {}
bool foo;
void bar() {
if(foo)
std::cout Foo\n;
}
};
int main () {
A a;
a.bar();
return 0;
}
The uninitialized variable is detected only with -O1. It is vaguely documented
but that behavior seems quite odd and unexpected when you are not aware of it.
[Bug tree-optimization/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 17:41:41 UTC --- Author: ebotcazou Date: Mon Mar 4 17:41:32 2013 New Revision: 196439 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196439 Log: PR tree-optimization/56424 * ipa-split.c (split_function): Do not set the RSO flag if result is not by reference and its type is a register type. Added: trunk/gcc/testsuite/gcc.dg/pr56424.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug c/56523] -Wunitialized is described to be enabled by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-04 17:43:18 UTC --- That some warnings are only emitted when optimizing is well known, and discussed in many places.
[Bug tree-optimization/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-04 17:43:45 UTC --- Thanks for reporting the problem.
[Bug middle-end/56525] New: [4.8 Regression] Access to ggc_freed memory in flow_loops_find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525 Bug #: 56525 Summary: [4.8 Regression] Access to ggc_freed memory in flow_loops_find Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org valgrind --track-origins=yes --leak-check=full --db-attach=yes ./cc1 /usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr54458.c -O3 -fomit-frame-pointer -o /tmp/x.s fails with: ==2723== Invalid read of size 8 ==2723==at 0x670584: flow_loops_find(loops*) (cfgloop.c:445) ==2723==by 0x8EC17E: fix_loop_structure(bitmap_head_def*) (loop-init.c:242) ==2723==by 0xAA5F93: repair_loop_structures() (tree-cfgcleanup.c:716) ==2723==by 0xAA602F: cleanup_tree_cfg() (tree-cfgcleanup.c:746) ==2723==by 0x977221: execute_function_todo(void*) (passes.c:1921) ==2723==by 0x97669A: do_per_function(void (*)(void*), void*) (passes.c:1701) ==2723==by 0x977476: execute_todo(unsigned int) (passes.c:1996) ==2723==by 0x977E86: execute_one_pass(opt_pass*) (passes.c:2344) ==2723==by 0x977FEB: execute_pass_list(opt_pass*) (passes.c:2378) ==2723==by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379) ==2723==by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379) ==2723==by 0x696413: expand_function(cgraph_node*) (cgraphunit.c:1640) ==2723== Address 0xb46b6f0 is not stack'd, malloc'd or (recently) free'd This happens after unswitching pass, where a loop is first ggc_freed: #1 0x005fa4c8 in ggc_free (p=0x719896e8) at ../../gcc/ggc-page.c:1544 #2 0x0066fe08 in flow_loop_free (loop=0x719896e8) at ../../gcc/cfgloop.c:195 #3 0x006721ca in delete_loop (loop=0x719896e8) at ../../gcc/cfgloop.c:1277 #4 0x008ec13c in fix_loop_structure (changed_bbs=0x19162d0) at ../../gcc/loop-init.c:234 #5 0x00aa5f94 in repair_loop_structures () at ../../gcc/tree-cfgcleanup.c:716 #6 0x00aa6030 in cleanup_tree_cfg () at ../../gcc/tree-cfgcleanup.c:746 and then used in flow_loops_find: 443 /* The current active loop tree has valid loop-fathers for 444 header blocks. */ 445 if (!from_scratch 446 header-loop_father-header == header) When not under valgrind, header-loop_father-header will be typically 0xafafafafafafafaf, so won't match and show that it indeed does something wrong.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #44 from William J. Schmidt wschmidt at gcc dot gnu.org 2013-03-04 17:53:17 UTC --- Compiling mgrid.f on powerpc64-unknown-linux-gnu as follows: $ gfortran -S -m32 -O3 -mcpu=power7 -fpeel-loops -funroll-loops -ffast-math -fvect-cost-model mgrid.f I examined the assembly generated for revisions 193330, 193331 (this issue), and 196171 (PR55334). What I'm seeing is that for both 193331 and 196171, the inliner is much more aggressive, and in particular is inlining several copies of some pretty large functions. For -m32, I am not seeing any specialization of resid_, so although the change in 196171 helped a little, it appears that this was by reducing overall code size. There weren't any changes in inlining decisions. Of course there is a lot of distance between 193331 and 196171, so it is not a perfect comparison, though it appears 196171 is where -m32 received a slight boost. Anyway, the non-inlined call tree for 193330 is: main MAIN__ resid_ (x4) comm3_ psinv_ (x3) comm3_ norm2u3_ (x2) interp_ (x2) setup_ rprj3_ (x4) zran3_ The non-inlined call tree for 193331 is: main MAIN__ comm3_ (x5) resid_ comm3_ norm2u3_ (x2) setup_ zran3_ So with 193331 we have the following additional inlines: 3 inlines of resid_, size = 1068, total size = 3204 3 inlines of psinv_, size = 1046, total size = 3138 2 inlines of interp_, size = 1544, total size = 3088 4 inlines of rprj3_, size = 220, total size = 880 Here size is the number of lines of assembly code of the called procedure, including labels, so it's just a rough measure. The number of static call sites of comm3_ was also reduced by one, but I don't know whether it was inlined or specialized away. These are pretty large procedures to be duplicating, particularly to be duplicating more than once. Looking at resid_, it already generates spill code on its own, so putting 3 copies of this in its caller isn't likely to be very helpful. Of these, I think only rprj3_ looks like a reasonable inline candidate. Total lines of the assembly files are: 8660 r193330/mgrid.s 16398 r193331/mgrid.s 14592 r196171/mgrid.s Inlining creates unreachable code, so removing the unreachable procedures gives: 7765 r193330/mgrid.s 12591 r193331/mgrid.s 10795 r196171/mgrid.s With r196171 the reachable code is still about 40% larger than r193330 (where some reasonable inlining was already being done). This is better than the 60% bloat with r193331 but still seems too high. Again, these are rough measures but I think they are indicative. Without knowing anything about the inliner, I think the inlining heuristics probably need to take more account of code size than they seem to do at the moment, particularly when making more than one copy of a procedure and thus reducing spatial locality.
[Bug c++/54995] Converting lambda to C-style functions when there is template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54995 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 18:10:39 UTC --- 56447 has a more compact testcase. *** This bug has been marked as a duplicate of bug 56447 ***
[Bug c++/56447] [C++11] Lambda in template has conversion op it shouldn't have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56447 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||temtaime at gmail dot com --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 18:10:40 UTC --- *** Bug 54995 has been marked as a duplicate of this bug. ***
[Bug c++/55828] problem with access to static method from lambda in another method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55828 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 18:15:07 UTC --- Same issue as 51494. *** This bug has been marked as a duplicate of bug 51494 ***
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||vladimir.bayda at gmail dot ||com --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-03-04 18:15:08 UTC --- *** Bug 55828 has been marked as a duplicate of this bug. ***
[Bug middle-end/56526] New: [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 Bug #: 56526 Summary: [4.8 regression] false positive for maybe-uninitialized Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net I haven't tracked down when this started happening, but it's a regression from fsf/4.7 and google/4.7, as well as trunk from some months ago. /work/mhargett/gcc-trunk-lto-O3/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-lto-O3/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -O3 -g -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcc-nm.o -o gcc-nm \ file-find.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../../gcc-trunk/libiberty/simple-object-mach-o.c: In function 'simple_object_mach_o_find_sections': ../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error: 'wrapper_sect_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] secoffset = wrapper_sect_offset + subsect_offset; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1 ../../gcc-trunk/libiberty/simple-object-mach-o.c: In function 'simple_object_mach_o_find_sections': ../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error: 'wrapper_sect_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] secoffset = wrapper_sect_offset + subsect_offset; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [lto-wrapper] Error 1 make[3]: *** Waiting for unfinished jobs mv -f Tcollect2 collect2 make[3]: Leaving directory `/work/mhargett/gcc-trunk-lto-O3/gcc' make[2]: *** [all-stage2-gcc] Error 2 wrapper_sect_offset is initialized in the block predicated by ((gnu_sections_found SOMO_WRAPPING) != 0), and is only accessed in a block with the same (outer) predicate. reproduced with bootstrap-lto on current trunk with -O3. save-temp outputs are attached.
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #1 from Matt Hargett matt at use dot net 2013-03-04 19:04:58 UTC --- Created attachment 29580 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29580 save-temps output from same commandline/path
[Bug bootstrap/56509] [4.8 regression] gnattools build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56509 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2013-03-04 19:50:07 UTC --- This is working.
[Bug target/56511] memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com 2013-03-04 20:10:09 UTC --- This seems to be the old issue with non-optimal memcpy,memset etc expanding for x86. See for instance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052. There were some attempts to imrove that expanding (e.g. here - http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00853.html) but with no success yet.
[Bug c/56527] New: Provide an import counterpart to attribute((visibility(protected)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527 Bug #: 56527 Summary: Provide an import counterpart to attribute((visibility(protected))) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@mit.edu This is a common idiom: #ifdef BUILDING_LIBWHATEVER #define LIBWHATEVER_API __attribute__((visibility(protected))) #else #define LIBWHATEVER_API ??? #endif Protected can be replaced with default without changing anything. The issue is: what to specify for imports (the ??? above). The common approach seems to be __attribute__((visibility(default))), since hidden is asking for trouble and protected won't link due to undefined protected symbols. Neither one is good. I want an attribute (which could be a new visibility) that acts like default visibility for undefined symbols, like default visibility [1] for inline defined symbols, and fails to compile for non-inline symbols. (In this definition, inline should probably include implicitly instantiated templates as well.) This will catch errors when a non-inline function is defined in the right place. [1] This isn't quite ideal. To avoid interposing a possible protected instantiation of an inline function, these should probably end up as default visibility but weak. P.S. It would be neat if calls to functions with this attribute generated explicit GOT references rather than going to the PLT. (IMO Windows gets this right.)
[Bug tree-optimization/56486] [4.6/4.7 Regression] infinite loop in cc1 at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 Dara Hazeghi dhazeghi at yahoo dot com changed: What|Removed |Added Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression] |infinite loop in cc1 at -O1 |infinite loop in cc1 at -O1 |and above | --- Comment #4 from Dara Hazeghi dhazeghi at yahoo dot com 2013-03-04 20:59:27 UTC --- (In reply to comment #3) I suppose hangs == just takes very long. You're correct - 285 seconds on a 2.8GHZ i7. It's also only at -O1.
[Bug rtl-optimization/56494] [4.8 Regression] ICE in simplify_truncation, at simplify-rtx.c:619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56494 --- Comment #4 from rdsandiford at googlemail dot com rdsandiford at googlemail dot com 2013-03-04 21:06:10 UTC --- jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org writes: Created attachment 29578 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29578 gcc48-pr56494.patch Thanks for the fix. Looks good to me FWIW. Truncations can't be to a narrower mode (already asserted at the top of the function) so in some ways I think it would be clearer to have an if ... else rather than two ifs. Richard
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-04 21:50:58 UTC --- (In reply to comment #2) +1 I'm seeing the same pattern. Infact, I'm noticing a lot of my maths code seems to be performing a lot of redundant moves. Some examples would be great regarding this matter, although I can already imagine what the code looks like. One of the problems is the auto-inc-dec pass (see PR 50749). A long time ago the rule of thumb for SH4 programmers was read float values with post-inc addressing in your C code, and write float values with pre-dec addressing. This does not work anymore, since all memory accesses are turned into array like index based addresses internally in the compiler. Then the auto-inc-dec RTL pass is supposed to find post-inc and pre-dec addressing mode opportunities, but it fails to do so in most cases. I have started writing a replacement RTL pass that would try to optimize addressing mode selections. I hope to get it in for GCC 4.9. Anyway, if you have some example code that you can share, it would be really appreciated and helpful during development for testing purposes. Are there actually any builtins/intrinsics available for the SH4? How do I access the awesome vector operations without breaking out the inline asm? There aren't that many HW vector ops on SH4, just fipr and ftrv. At the moment, there are no builtins for those, so you'd have to use inline asm intrinsics. Like I mentioned in comment #1, I'd rather make the compiler figure out opportunities from portable generic code. Although for ftrv the patterns might be a bit complicated, also because the compiler then has to manage the 2nd FPU regs bank... It would be nice to have some intrinsics that understand vectors as sequences of 4 float regs, and automate a sequential (vector) load. That would be the job of the address-mode-selection RTL pass. It would also improve overall code quality on SH. The fastest way to load 4 float vectors is to use 2x fmov.d. The compiler could also do that automatically, but this requires FPSCR switching, which unfortunately also needs some rework (e.g. see PR 53513, PR 6526). And on top of that, we also have PR 13423. It seems that the proper fix for this is a new reworked (vector) ABI for SH. Also, the ftrv opcode doesn't seem to be accessible either. True. I really hope that I'll find enough time to brush up SH FPU code generation for GCC 4.9. Until then, I'd suggest to use inline-asm style intrinsics.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-04 21:52:15 UTC --- Author: jakub Date: Mon Mar 4 21:52:08 2013 New Revision: 196445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196445 Log: PR middle-end/56461 * diagnostic.c (diagnostic_append_note): Save and restore old prefix. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c
[Bug c/56528] New: __attribute__((visibility)) ignored for a function declaration with an asm label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56528
Bug #: 56528
Summary: __attribute__((visibility)) ignored for a function
declaration with an asm label
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: richard-gccbugzi...@metafoo.co.uk
Adding an asm label attribute to a function declaration with a visibility
attribute causes the visibility attribute to be ignored:
$ echo 'void f() __attribute__((visibility(hidden))); void g() { f(); }' |
gcc -x c - -S -o - | grep hidden
.hidden f
$ echo 'void f() __asm__(f) __attribute__((visibility(hidden))); void g() {
f(); }' | gcc -x c - -S -o - | grep hidden
$
[Bug target/56529] New: [SH] Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56529 Bug #: 56529 Summary: [SH] Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* The original problem was reported here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00088.html Actually the compiler should prohibit the -mdiv=call-table option on SH2, because there is no suitable implementation in libgcc. However, this fails, due to the following lines in sh.c: /* SH1 .. SH3 cores often go into small-footprint systems, so default to the smallest implementation available. */ else if (TARGET_SH2)/* ??? EXPERIMENTAL */ sh_div_strategy = SH_DIV_CALL_TABLE; I'm not sure what that is for, but it certainly is broken or incomplete (libgcc pieces missing).
[Bug target/56529] [SH] Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56529 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-04 23:44:09 UTC --- Created attachment 29581 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29581 A possible patch This patch seems to fix the problem, although tested only with 'make all-gcc'. BTW, the 'call-table' option for -mdiv= hasn't been documented either. Will fix that, too.
[Bug c/56527] Provide an import counterpart to attribute((visibility(protected)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527 --- Comment #1 from Andy Lutomirski luto at mit dot edu 2013-03-05 00:37:20 UTC --- In fact, without an improvement like this, protected visibility is unusable on objects -- anything linking against a protected object will generate a copy relocation. The fact that the resulting binary is even loadable is IMO a bug (whether in binutils for generating it or in glibc for loading it is debatable.)
