Re: Bogus gcc.c-torture/execute/20071018-1.c testcase?
On Sat, 31 Dec 2011, Mark Kettenis wrote:
Execution of the test randomly fails for me on OpenBSD/amd64. Looking
at the code, it seems it is doing an out-of-bounds array access. For
refernce I've copied the code of the testcase below. As you can see
there's a foo(0) call in main(). Therefore
struct foo **upper = as-x[rank * 8 - 1];
becomes
struct foo **upper = as-x[-1];
so upper points to an address before the malloc()'ed memory. Then
when the code does
*upper = 0;
this generates a SIGSEGV, if the malloc()'ed memory happens to lie
right at the start of a page. I suppose that may never happen on some
platforms (Linux?) since many malloc() implementations will use the
start of a page for their own bookkeeping.
I don't really understand what the testcase is testing. Richard, can
you perhaps shed some light on this?
The testcase was added when trying to fix PR32921, I do not remember
whether it was relevant that an out-of-bounds array access occured
(but I suppose it was so). It was a miscompile, so a runtime testcase
is required.
I suppose changing the testcase to do as-x[rank * 8 - 8] and
pass in rank == 1 would make it fail similarly on rev. 129484
(or better make it as-x[rank * 2 = 2]).
Richard.
Thanks,
Mark
---
extern void abort(void);
struct foo {
int rank;
char *name;
};
struct mem {
struct foo *x[4];
};
void __attribute__((noinline)) bar(struct foo **f)
{
*f = __builtin_malloc(sizeof(struct foo));
}
struct foo * foo(int rank)
{
void *x = __builtin_malloc(sizeof(struct mem));
struct mem *as = x;
struct foo **upper = as-x[rank * 8 - 1];
*upper = 0;
bar(upper);
return *upper;
}
int main()
{
if (foo(0) == 0)
abort ();
return 0;
}
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: Lingering tbaa in anti_dependence?
On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Dec 29, 2011 at 04:24:31PM +, Richard Sandiford wrote:
AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
anti_dependence between a load X and store Y because Y might be defining
a new object in the same space as the object that was being read by X.
But it looks like we still use component-based disambiguation
(nonoverlapping_component_refs_p) in this case. Is it true that
that's also a problem? E.g. for:
struct s { int f; float g; };
struct t { int header; struct s s; };
float foo (struct t *newt, struct s *olds, int x, int y)
{
float ret = olds[x * y].g;
newt-header = 0;
newt-s.f = 1;
newt-s.g = 1.0;
return ret;
}
we can (and on ARM Cortex A8, do) move the store to newt-s.f above
the load from olds[...].g. If we view the assignment to newt
as defining a new object in the same space as the now-defunct olds,
and if x * y happens to be zero, then the accesses might well be
to the same address.
You would need a placement new in between the read from olds[x * y].g
and newt-* stores, without that it is definitely valid to move it
ahead of the store.
IMHO we should keep placement new in the IL in some form, and decide how
conservative we need to be based on whether the current function
or current loop etc. contains (or could contain) a placement new or not.
I disagree. Any representation of placement new would pessimize code
more than it is pessimized now. You also will lose the advantage that
the current implementation of our TBAA semantics integrate nicely
with the type-punning through union stuff which you'd otherwise have
to make explicit (thus, lower to the proposed placement-new style), too.
Also consider placement new in a function (it would be pure/const),
also consider that placement new is simply an inline function returning
its argument.
E.g. if a loop doesn't contain placement new anywhere, we could be less
conservative in optimizing that loop, do more vectorization on it etc.
For loops we can just do more proper dependence analysis.
Richard.
Jakub
RFC: Handle conditional expression in sccvn/fre/pre
Hi, Since SCCVN operates on SSA graph instead of the control flow graph for the sake of efficiency, it does not handle or value number the conditional expression of GIMPLE_COND statement. As a result, FRE/PRE does not simplify conditional expression, as reported in bug 30997. Since it would be complicate and difficult to process conditional expression in currently SCCVN algorithm, how about following method? STEP1 Before starting FRE/PRE, we can factor out the conditional expression, like change following codes: if (cond_expr) goto lable_a else goto label_b into codes: tmp = cond_expr if (tmp == 1) goto label_a else goto label_b STEP2 Let SCCVN/FRE/PRE do its job on value numbering cond_expr and redundancy elimination; STEP3 After FRE/PRE, for those tmp=cond_expr not used in any redundancy elimination, we can forward it to the corresponding GIMPLE_COND statement, just like tree-ssa-forwprop.c. In this way, the conditional expression will be handled as other expressions and no redundant assignment generated. Most important,this does not affect the current implementation of SCCVN/FRE/PRE. The only problem is the method cannot work on reversion of conditional expression. For example: x = a 2; if (a=2) goto label_a else goto lable_b could be optimized as: x = a 2 if (x == 0) goto label_a else goto label_b I have worked a draft patch to do the work and would like to hear your comments on this. Thanks very much. -- Best Regards.
Re: RFC: Handle conditional expression in sccvn/fre/pre
On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng amker.ch...@gmail.com wrote: Hi, Since SCCVN operates on SSA graph instead of the control flow graph for the sake of efficiency, it does not handle or value number the conditional expression of GIMPLE_COND statement. As a result, FRE/PRE does not simplify conditional expression, as reported in bug 30997. Since it would be complicate and difficult to process conditional expression in currently SCCVN algorithm, how about following method? STEP1 Before starting FRE/PRE, we can factor out the conditional expression, like change following codes: if (cond_expr) goto lable_a else goto label_b into codes: tmp = cond_expr if (tmp == 1) goto label_a else goto label_b STEP2 Let SCCVN/FRE/PRE do its job on value numbering cond_expr and redundancy elimination; STEP3 After FRE/PRE, for those tmp=cond_expr not used in any redundancy elimination, we can forward it to the corresponding GIMPLE_COND statement, just like tree-ssa-forwprop.c. In this way, the conditional expression will be handled as other expressions and no redundant assignment generated. Most important,this does not affect the current implementation of SCCVN/FRE/PRE. The only problem is the method cannot work on reversion of conditional expression. For example: x = a 2; if (a=2) goto label_a else goto lable_b could be optimized as: x = a 2 if (x == 0) goto label_a else goto label_b I have worked a draft patch to do the work and would like to hear your comments on this. I've previously worked on changing GIMPLE_COND to no longer embed the comparison but carry a predicate SSA_NAME only (this is effectively what you do as pre-processing before SCCVN). It had some non-trivial fallout (for example PRE get's quite confused and ends up separating conditionals and jumps too far ...) so I didn't finish it. A subset of all cases can be catched by simply looking up the N-ary at eliminate () time and re-writing the GIMPLE_COND to use the predicate - which might not actually be beneficial (but forwprop will undo not beneficial cases - hopefully). In the end I'd rather go the way changing the GIMPLE IL to not embed the comparison in the GIMPLE_COND - that reduces the amount of redundant way we can express the same thing. Richard. Thanks very much. -- Best Regards.
Re: A case exposing code sink issue
On Thu, Dec 29, 2011 at 9:50 AM, Jiangning Liu jiangning@arm.com wrote:
-Original Message-
From: Jiangning Liu
Sent: Wednesday, December 28, 2011 5:38 PM
To: Jiangning Liu; 'Richard Guenther'
Cc: Michael Matz; gcc@gcc.gnu.org
Subject: RE: A case exposing code sink issue
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of
Jiangning Liu
Sent: Tuesday, December 27, 2011 5:10 PM
To: 'Richard Guenther'
Cc: Michael Matz; gcc@gcc.gnu.org
Subject: RE: A case exposing code sink issue
The job to do this is final value replacement, not sinking (we do
not
sink non-invariant expressions - you'd have to translate them
through
the loop-closed SSA exit PHI node, certainly doable, patches
welcome ;)).
Richard,
In final value replacement, expression a + D. can be figured
out,
while a[i_xxx] failed to be CHRECed, so I'm wondering if we should
lower
a[i_xxx] to a + unitsize(a) * i_xxx first? It seems GCC intends
to
keep
a[i_xxx] until cfgexpand pass. Or we have to directly modify CHREC
algorithm to get it calculated?
Appreciate your kindly help in advance!
Richard,
Now I have a patch working for the case of step i++, by directly
modifying
scalar evolution algorithm. the following code would be generated after
SCCP,
l
# i_13 = PHI i_6(7), k_2(D)(4)
a_p.0_4 = a[i_13];
MEM[(int *)a][i_13] = 100;
i_6 = i_13 + 1;
if (i_6 = 999)
goto bb 7;
else
goto bb 6;
bb 6:
a_p_lsm.5_11 = MEM[(void *)a + 3996B];
a_p = a_p_lsm.5_11;
goto bb 3;
It looks good, but I still have problem when the case has step i+=k.
For this case the value of variable i exiting loop isn't invariant, the
algorithm below in scalar evolution doesn't work on it,
compute_overall_effect_of_inner_loop()
{
...
tree nb_iter = number_of_latch_executions (inner_loop);
if (nb_iter == chrec_dont_know)
return chrec_dont_know;
else
{
tree res;
/* evolution_fn is the evolution function in LOOP. Get
its value in the nb_iter-th iteration. */
res = chrec_apply (inner_loop-num, evolution_fn, nb_iter);
if (chrec_contains_symbols_defined_in_loop (res, loop-num))
res = instantiate_parameters (loop, res);
/* Continue the computation until ending on a parent of LOOP.
*/
return compute_overall_effect_of_inner_loop (loop, res);
}
}
In theory, we can still have the transformation like below even if the
step
is i+=k,
# i_13 = PHI i_6(7), k_2(D)(4)
i_14 = i_13,
a_p.0_4 = a[i_13];
MEM[(int *)a][i_13] = 100;
i_6 = i_13 + k_2(D); // i+=k
if (i_6 = 999)
goto bb 7;
else
goto bb 6;
bb 6:
a_p_lsm.5_11 = a[i_14];
a_p = a_p_lsm.5_11;
goto bb 3;
But I realize this is not a loop closed SSA form at all, because i_14
is
being used out of the loop. Where could we extend the liverange of
variable
i in GCC infrastructure and finally solve this problem?
It seems many people are still in the happy of the upcoming 2012 New Year.
:-)
Following my story, I find the following code in tree-ssa-copy.c
/* Avoid copy propagation from an inner into an outer loop.
Otherwise, this may move loop variant variables outside of
their loops and prevent coalescing opportunities. If the
value was loop invariant, it will be hoisted by LICM and
exposed for copy propagation.
??? The value will be always loop invariant.
In loop-closed SSA form do not copy-propagate through
PHI nodes in blocks with a loop exit edge predecessor. */
if (current_loops
TREE_CODE (arg_value) == SSA_NAME
(loop_depth_of_name (arg_value) loop_depth_of_name (lhs)
|| (loops_state_satisfies_p (LOOP_CLOSED_SSA)
loop_exit_edge_p (e-src-loop_father, e
{
phi_val.value = lhs;
break;
}
Here http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00066.html, Dan said
The original check was not because of coalescing, but because we would
copy prop in-loop variables outside the loop, causing *more*
invariantness in nested loops.
Can anybody give me a concrete example to explain this statement?
I can neither make sense of the code nor of Dans comment. But of
course the part about loop-closed-SSA is still true. I _suppose_ that
the situation is like
tem = stuff;
for ()
x = tem;
foo = x;
and Dan expects LIM to hoist x = tem (instead of sinking it by copyprop).
Then we'd coalesce tem and x (but it would be still live across the loop),
instead of coalescing x and foo (keeping tem live over the loop). LIM of
course does not hoist this kind of stuff because it appears too cheap.
Anyway, for my simple case, I don't see bad thing would happen when
propagate a[i] out of
Re: RFC: Handle conditional expression in sccvn/fre/pre
Thanks Richard, On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther richard.guent...@gmail.com wrote: I've previously worked on changing GIMPLE_COND to no longer embed the comparison but carry a predicate SSA_NAME only (this is effectively what you do as pre-processing before SCCVN). It had some non-trivial fallout (for example PRE get's quite confused and ends up separating conditionals and jumps too far ...) so I didn't finish it. Here changing GIMPLE_COND to no longer embed the comparison, do you mean this only in fre/pre passes or in common? If only in fre/pre passes, when and how these changed GIMPLE_COND be changed back to normal ones? If in common, won't this affects passes working on GIMPLE_COND, like tree-ssa-forwprop.c? A subset of all cases can be catched by simply looking up the N-ary at eliminate () time and re-writing the GIMPLE_COND to use the predicate - which might not actually be beneficial (but forwprop will undo not beneficial cases - hopefully). In the end I'd rather go the way changing the GIMPLE IL to not embed the comparison in the GIMPLE_COND - that reduces the amount of redundant way we can express the same thing. Will you try to handle the reversion comparison case as mentioned in my previous message? I guess this needs both sccvn and fre/pre's work. It would be great to hear your thoughts on this. Thanks -- Best Regards.
-fstack-protector, __stack_chk_fail_local and TARGET_LIBC_PROVIDES_SSP
Hi,
I ran into an issue with -fstack-protector on FreeBSD/i386. GCC
generates calls to __stack_chk_fail_local that the linker complains are
undefined. The following test case shows it:
% cat test.c
int
main( void ) {
return( 0 );
}
% gcc46 -o test test.c -fstack-protector-all -fPIE
/var/tmp//ccjYQxKu.o: In function `main':
test.c:(.text+0x37): undefined reference to `__stack_chk_fail_local'
/usr/local/bin/ld: test: hidden symbol `__stack_chk_fail_local' isn't defined
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I managed to fix the problem with the following one line change:
--- gcc/gcc.c.orig
+++ gcc/gcc.c
@@ -601,7 +601,7 @@
#ifndef LINK_SSP_SPEC
#ifdef TARGET_LIBC_PROVIDES_SSP
-#define LINK_SSP_SPEC %{fstack-protector:}
+#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-all:-lssp_nonshared}
#else
#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all:-lssp_nonshared
-lssp}
#endif
The configure script detects __stack_chk_fail in FreeBSD libc and
defines TARGET_LIBC_PROVIDES_SSP, but __stack_chk_fail_local should be
statically linked in so (a dynamic) libc should not provide it.
My question is now whether the problem is with FreeBSD's SSP
implementation (where exactly does GCC expect __stack_chk_fail_local to
be defined?) or with GCC (should GCC just always link in ssp_nonshared
as in the patch above?).
Re: RFC: Handle conditional expression in sccvn/fre/pre
On Mon, Jan 2, 2012 at 2:11 PM, Amker.Cheng amker.ch...@gmail.com wrote:
Thanks Richard,
On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
richard.guent...@gmail.com wrote:
I've previously worked on changing GIMPLE_COND to no longer embed
the comparison but carry a predicate SSA_NAME only (this is effectively
what you do as pre-processing before SCCVN). It had some non-trivial
fallout (for example PRE get's quite confused and ends up separating
conditionals and jumps too far ...) so I didn't finish it.
Here changing GIMPLE_COND to no longer embed the comparison,
do you mean this only in fre/pre passes or in common?
If only in fre/pre passes, when and how these changed GIMPLE_COND
be changed back to normal ones?
If in common, won't this affects passes working on GIMPLE_COND, like
tree-ssa-forwprop.c?
Everywhere. I posted a patch early last year and changed COND_EXPRs
on the RHS of an assignment later.
A subset of all cases can be catched by simply looking up the
N-ary at eliminate () time and re-writing the GIMPLE_COND to use
the predicate - which might not actually be beneficial (but forwprop
will undo not beneficial cases - hopefully).
In the end I'd rather go the way changing the GIMPLE IL to not
embed the comparison in the GIMPLE_COND - that reduces
the amount of redundant way we can express the same thing.
Will you try to handle the reversion comparison case as mentioned
in my previous message? I guess this needs both sccvn and fre/pre's
work. It would be great to hear your thoughts on this.
Well, with
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 182784)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -4335,16 +4335,23 @@ eliminate (void)
available value-numbers. */
else if (gimple_code (stmt) == GIMPLE_COND)
{
- tree op0 = gimple_cond_lhs (stmt);
- tree op1 = gimple_cond_rhs (stmt);
+ tree op[2];
tree result;
+ vn_nary_op_t nary;
- if (TREE_CODE (op0) == SSA_NAME)
- op0 = VN_INFO (op0)-valnum;
- if (TREE_CODE (op1) == SSA_NAME)
- op1 = VN_INFO (op1)-valnum;
+ op[0] = gimple_cond_lhs (stmt);
+ op[1] = gimple_cond_rhs (stmt);
+ if (TREE_CODE (op[0]) == SSA_NAME)
+ op[0] = VN_INFO (op[0])-valnum;
+ if (TREE_CODE (op[1]) == SSA_NAME)
+ op[1] = VN_INFO (op[1])-valnum;
result = fold_binary (gimple_cond_code (stmt), boolean_type_node,
- op0, op1);
+ op[0], op[1]);
+ if (!result)
+ result = vn_nary_op_lookup_pieces (2, gimple_cond_code (stmt),
+ boolean_type_node,
+ op, nary);
+
if (result TREE_CODE (result) == INTEGER_CST)
{
if (integer_zerop (result))
@@ -4354,6 +4361,13 @@ eliminate (void)
update_stmt (stmt);
todo = TODO_cleanup_cfg;
}
+ else if (result TREE_CODE (result) == SSA_NAME)
+ {
+ gimple_cond_set_code (stmt, NE_EXPR);
+ gimple_cond_set_lhs (stmt, result);
+ gimple_cond_set_rhs (stmt, boolean_false_node);
+ update_stmt (stmt);
+ }
}
/* Visit indirect calls and turn them into direct calls if
possible. */
you get the CSE (too simple patch, you need to check leaders properly).
You can then add similar lookups for an inverted conditional.
Richard.
Thanks
--
Best Regards.
Re: RFC: Handle conditional expression in sccvn/fre/pre
On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, with
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 182784)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -4335,16 +4335,23 @@ eliminate (void)
available value-numbers. */
else if (gimple_code (stmt) == GIMPLE_COND)
{
- tree op0 = gimple_cond_lhs (stmt);
- tree op1 = gimple_cond_rhs (stmt);
+ tree op[2];
tree result;
+ vn_nary_op_t nary;
- if (TREE_CODE (op0) == SSA_NAME)
- op0 = VN_INFO (op0)-valnum;
- if (TREE_CODE (op1) == SSA_NAME)
- op1 = VN_INFO (op1)-valnum;
+ op[0] = gimple_cond_lhs (stmt);
+ op[1] = gimple_cond_rhs (stmt);
+ if (TREE_CODE (op[0]) == SSA_NAME)
+ op[0] = VN_INFO (op[0])-valnum;
+ if (TREE_CODE (op[1]) == SSA_NAME)
+ op[1] = VN_INFO (op[1])-valnum;
result = fold_binary (gimple_cond_code (stmt), boolean_type_node,
- op0, op1);
+ op[0], op[1]);
+ if (!result)
+ result = vn_nary_op_lookup_pieces (2, gimple_cond_code (stmt),
+ boolean_type_node,
+ op, nary);
+
if (result TREE_CODE (result) == INTEGER_CST)
{
if (integer_zerop (result))
@@ -4354,6 +4361,13 @@ eliminate (void)
update_stmt (stmt);
todo = TODO_cleanup_cfg;
}
+ else if (result TREE_CODE (result) == SSA_NAME)
+ {
+ gimple_cond_set_code (stmt, NE_EXPR);
+ gimple_cond_set_lhs (stmt, result);
+ gimple_cond_set_rhs (stmt, boolean_false_node);
+ update_stmt (stmt);
+ }
}
/* Visit indirect calls and turn them into direct calls if
possible. */
you get the CSE (too simple patch, you need to check leaders properly).
You can then add similar lookups for an inverted conditional.
Thanks for your explanation. On shortcoming of this method is that it
cannot find/take cond_expr(and the implicitly defined variable) as the
leader in pre. I guess this is why you said it can handle a subset of all
cases in previous message?
on the other hand, I like this method, given the simplicity especially. :)
--
Best Regards.
Re: fixed_scalar_and_varying_struct_p and varies_p
Thanks for both replies.
Richard Guenther richard.guent...@gmail.com writes:
On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou ebotca...@adacore.com wrote:
fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
So in these cases fixed_scalar_and_varying_struct_p effectively becomes
a no-op on targets that don't allow MEMs in addresses and takes on
suspicious semantics for those that do. In the former case, every
address is treated as unvarying and f_s_a_v_s_p always returns null.
In the latter case, things like REG addresses are (wrongly) treated as
unvarying while a MEM address might correctly be treated as varying,
leading to false positives.
It looks like this goes back to when fixed_scalar_and_varying_struct_p
was added in r24759 (1999).
Does this mean that MEM_IN_STRUCT_P and MEM_SCALAR_P have also been
effectively disabled since then?
Some important callers (cse.c and sched-deps.c) do use the proper
varies_p routine, so it probably isn't quite that extreme. But...
AIUI, the true_dependence varies_p parameter exists for the benefit
of CSE, so that it can use its local cse_rtx_varies_p function.
All other callers should be using rtx_varies_p instead. Question is,
should I make that change, or is it time to get rid of
fixed_scalar_and_varying_struct_p instead?
I'd vote for the latter (and for eliminating MEM_IN_STRUCT_P and MEM_SCALAR_P
in the process, if the answer to the above question is positive), there is no
point in resurrecting this now IMO.
I agree. The tree level routines should be able to figure most of, if
not all, cases
on their own via rtx_refs_may_alias_p (similar to the
nonoverlapping_component_refs
case which we could simply delete as well).
...that's 2 votes for and none so far against. :-)
I compiled the cc1 .ii files on x86_64-linux-gnu with and without
fixed_scalar_and_varying_struct_p. There were 19 changes in total,
all of them cases where sched2 was able to reorder two memory accesses
because of f_s_a_v_s_p. I've attached the diff below.
A good example is:
if (bit_obstack)
{
element = bit_obstack-elements;
if (element)
/* Use up the inner list first before looking at the next
element of the outer list. */
if (element-next)
{
bit_obstack-elements = element-next;
bit_obstack-elements-prev = element-prev;
}
else
/* Inner list was just a singleton. */
bit_obstack-elements = element-prev;
else
element = XOBNEW (bit_obstack-obstack, bitmap_element);
}
else
{
element = bitmap_ggc_free;
if (element)
/* Use up the inner list first before looking at the next
element of the outer list. */
if (element-next)
{
bitmap_ggc_free = element-next;
bitmap_ggc_free-prev = element-prev;
}
else
/* Inner list was just a singleton. */
bitmap_ggc_free = element-prev;
else
element = ggc_alloc_bitmap_element_def ();
}
from bitmap.c, specifically:
bitmap_ggc_free = element-next;
bitmap_ggc_free-prev = element-prev;
Without f_s_a_v_s_p, sched2 couldn't tell that element-prev didn't
alias bitmap_ggc_free. And this in turn is because cfgcleanup
considered trying to merge this block with:
bit_obstack-elements = element-next;
bit_obstack-elements-prev = element-prev;
It called merge_memattrs for each pair of instructions that it was
thinking of merging, and because the element-next and element-prev
MEMs were based on different SSA names, we lost the MEM_EXPR completely.
As it happens, we decided not to merge the blocks after all.
So an obvious first observation is that query functions like
flow_find_cross_jump and flow_find_head_matching_sequence shouldn't
change the rtl. We should only do that once we've decided which
instructions we're actually going to merge.
Of course, that's not a trivial change. It's easy to make
try_head_merge_bb call merge_memattrs during merging, but less
easy for try_crossjump_to_edge and cond_exec_process_if_block.
(Note that the latter, like try_head_merge_bb, can end up merging
fewer instructions than flow_find_* saw).
But does the choice of SSA name actually count for anything this
late on? Should we consider MEM_EXPRs node_X-prev and node_Y-prev
to be similar enough, if node_X and node_Y have equal types?
I've attached a patch to remove fixed_scalar_and_varying_struct_p
just in case it's OK. Tested on mips64-linux-gnu.
Also, as Eric says, this is really the only middle-end use of
MEM_SCALAR and MEM_IN_STRUCT_P. It looks like the only other
use is in config/m32c/m32c.c:m32c_immd_dbl_mov. TBH, I don't
really understand what that function is trying to test, so I can't
tell whether it should be using MEM_EXPR instead.
I've attached a patch to remove MEM_IN_STRUCT_P and MEM_SCALAR too,
Re: RFC: Handle conditional expression in sccvn/fre/pre
On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng amker.ch...@gmail.com wrote:
On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, with
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 182784)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -4335,16 +4335,23 @@ eliminate (void)
available value-numbers. */
else if (gimple_code (stmt) == GIMPLE_COND)
{
- tree op0 = gimple_cond_lhs (stmt);
- tree op1 = gimple_cond_rhs (stmt);
+ tree op[2];
tree result;
+ vn_nary_op_t nary;
- if (TREE_CODE (op0) == SSA_NAME)
- op0 = VN_INFO (op0)-valnum;
- if (TREE_CODE (op1) == SSA_NAME)
- op1 = VN_INFO (op1)-valnum;
+ op[0] = gimple_cond_lhs (stmt);
+ op[1] = gimple_cond_rhs (stmt);
+ if (TREE_CODE (op[0]) == SSA_NAME)
+ op[0] = VN_INFO (op[0])-valnum;
+ if (TREE_CODE (op[1]) == SSA_NAME)
+ op[1] = VN_INFO (op[1])-valnum;
result = fold_binary (gimple_cond_code (stmt),
boolean_type_node,
- op0, op1);
+ op[0], op[1]);
+ if (!result)
+ result = vn_nary_op_lookup_pieces (2, gimple_cond_code
(stmt),
+ boolean_type_node,
+ op, nary);
+
if (result TREE_CODE (result) == INTEGER_CST)
{
if (integer_zerop (result))
@@ -4354,6 +4361,13 @@ eliminate (void)
update_stmt (stmt);
todo = TODO_cleanup_cfg;
}
+ else if (result TREE_CODE (result) == SSA_NAME)
+ {
+ gimple_cond_set_code (stmt, NE_EXPR);
+ gimple_cond_set_lhs (stmt, result);
+ gimple_cond_set_rhs (stmt, boolean_false_node);
+ update_stmt (stmt);
+ }
}
/* Visit indirect calls and turn them into direct calls if
possible. */
you get the CSE (too simple patch, you need to check leaders properly).
You can then add similar lookups for an inverted conditional.
Thanks for your explanation. On shortcoming of this method is that it
cannot find/take cond_expr(and the implicitly defined variable) as the
leader in pre. I guess this is why you said it can handle a subset of all
cases in previous message?
Yes. It won't handle
if (x 1)
...
tem = x 1;
or
if (x 1)
...
if (x 1)
though maybe we could teach PRE to do the insertion by properly
putting x 1 into EXP_GEN in compute_avail (but not into AVAIL_OUT).
Not sure about this though. Currently we don't do anything to
GIMPLE_COND operands (which seems odd anyway, we should
at least add the operands to EXP_GEN).
on the other hand, I like this method, given the simplicity especially. :)
Yeah.
--
Best Regards.
Re: fixed_scalar_and_varying_struct_p and varies_p
On Mon, Jan 2, 2012 at 3:42 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Thanks for both replies.
Richard Guenther richard.guent...@gmail.com writes:
On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou ebotca...@adacore.com wrote:
fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
So in these cases fixed_scalar_and_varying_struct_p effectively becomes
a no-op on targets that don't allow MEMs in addresses and takes on
suspicious semantics for those that do. In the former case, every
address is treated as unvarying and f_s_a_v_s_p always returns null.
In the latter case, things like REG addresses are (wrongly) treated as
unvarying while a MEM address might correctly be treated as varying,
leading to false positives.
It looks like this goes back to when fixed_scalar_and_varying_struct_p
was added in r24759 (1999).
Does this mean that MEM_IN_STRUCT_P and MEM_SCALAR_P have also been
effectively disabled since then?
Some important callers (cse.c and sched-deps.c) do use the proper
varies_p routine, so it probably isn't quite that extreme. But...
AIUI, the true_dependence varies_p parameter exists for the benefit
of CSE, so that it can use its local cse_rtx_varies_p function.
All other callers should be using rtx_varies_p instead. Question is,
should I make that change, or is it time to get rid of
fixed_scalar_and_varying_struct_p instead?
I'd vote for the latter (and for eliminating MEM_IN_STRUCT_P and
MEM_SCALAR_P
in the process, if the answer to the above question is positive), there is
no
point in resurrecting this now IMO.
I agree. The tree level routines should be able to figure most of, if
not all, cases
on their own via rtx_refs_may_alias_p (similar to the
nonoverlapping_component_refs
case which we could simply delete as well).
...that's 2 votes for and none so far against. :-)
I compiled the cc1 .ii files on x86_64-linux-gnu with and without
fixed_scalar_and_varying_struct_p. There were 19 changes in total,
all of them cases where sched2 was able to reorder two memory accesses
because of f_s_a_v_s_p. I've attached the diff below.
A good example is:
if (bit_obstack)
{
element = bit_obstack-elements;
if (element)
/* Use up the inner list first before looking at the next
element of the outer list. */
if (element-next)
{
bit_obstack-elements = element-next;
bit_obstack-elements-prev = element-prev;
}
else
/* Inner list was just a singleton. */
bit_obstack-elements = element-prev;
else
element = XOBNEW (bit_obstack-obstack, bitmap_element);
}
else
{
element = bitmap_ggc_free;
if (element)
/* Use up the inner list first before looking at the next
element of the outer list. */
if (element-next)
{
bitmap_ggc_free = element-next;
bitmap_ggc_free-prev = element-prev;
}
else
/* Inner list was just a singleton. */
bitmap_ggc_free = element-prev;
else
element = ggc_alloc_bitmap_element_def ();
}
from bitmap.c, specifically:
bitmap_ggc_free = element-next;
bitmap_ggc_free-prev = element-prev;
Without f_s_a_v_s_p, sched2 couldn't tell that element-prev didn't
alias bitmap_ggc_free. And this in turn is because cfgcleanup
considered trying to merge this block with:
bit_obstack-elements = element-next;
bit_obstack-elements-prev = element-prev;
It called merge_memattrs for each pair of instructions that it was
thinking of merging, and because the element-next and element-prev
MEMs were based on different SSA names, we lost the MEM_EXPR completely.
As it happens, we decided not to merge the blocks after all.
So an obvious first observation is that query functions like
flow_find_cross_jump and flow_find_head_matching_sequence shouldn't
change the rtl. We should only do that once we've decided which
instructions we're actually going to merge.
Of course, that's not a trivial change. It's easy to make
try_head_merge_bb call merge_memattrs during merging, but less
easy for try_crossjump_to_edge and cond_exec_process_if_block.
(Note that the latter, like try_head_merge_bb, can end up merging
fewer instructions than flow_find_* saw).
But does the choice of SSA name actually count for anything this
late on? Should we consider MEM_EXPRs node_X-prev and node_Y-prev
to be similar enough, if node_X and node_Y have equal types?
It's a conservative way of merging alias info. A more precise variant
would union the points-to information of both bases (and stick it to
a new SSA name), conveniently pt_solution_ior_into exists.
And no, we can't just pick either SSA name.
Back in time we decided it wasn't that important to try hard to
preserve alias info for this case...
I'd say open a missed
Re: LTO multiple definition failures
On 01/02/2012 12:22 AM, Andi Kleen wrote: Sandra Loosemoresan...@codesourcery.com writes: I'm still finding my way around LTO; can anyone who's more familiar with this help narrow down where to look for the cause of this? I don't even know if this is a compiler or ld bug at this point. I'm I would look into the interaction between the LTO plugin and your ld (and also try gold if you can) Generally there are still various issues in these areas which need workarounds in the LTOed programs, for some things (like ld -r and some ar) you also need the latest version of HJ Lu's binutils which implement http://gcc.gnu.org/ml/gcc/2010-12/msg00229.html A lot of older binutils lds also tended to mishandle mixed LTOed ar archives. For avoidance of doubt, I was using mainline HEAD for both gcc and binutils for my powerpc-none-eabi experiments last week. The port for our new target is based on GCC 4.6 and a binutils branch from a few months ago, but it looked to me like the ld/gcc interaction was basically the same -- the link error being triggered by a difference in the startup code on the two targets, instead. Anyway, the problem here isn't that I particularly care about coming up with some workaround to make LTO work, but rather that tests from the gcc testsuite are failing on this target because of what looks like buggy LTO behavior instead of bugs in the target support, and I wanted to be sure this was being tracked somewhere. I didn't see a relevant issue in either the gcc or binutils bugzillas, but if it's a known consequence of the ld -r problem, I'll shut up and go away again. ;-) -Sandra
Re: fixed_scalar_and_varying_struct_p and varies_p
I'd say open a missed optimization bug with the testcase and go ahead with both patches. Let's see if Eric has some comments first though. None, but the m32c maintainer may have some. DJ, do you happen to know the rationale for the use of the MEM_SCALAR_P and MEM_IN_STRUCT_P flags in m32c_immd_dbl_mov? What condition do these tests try to model exactly? -- Eric Botcazou
Re: LTO multiple definition failures
Anyway, the problem here isn't that I particularly care about coming up with some workaround to make LTO work, but rather that tests from the gcc testsuite are failing on this target because of what looks like buggy LTO behavior instead of bugs in the target support, and I wanted to be sure this was being tracked somewhere. I didn't see a relevant issue in either the gcc or binutils bugzillas, but if it's a known consequence of the ld -r problem, I'll shut up and go away again. ;-) AFAIK none of the test suite tests the ld -r problem, at least not on x86-linux. So it may be something else and still worth tracking down. -Andi -- a...@linux.intel.com -- Speaking for myself only.
[Bug target/39469] Calculated values replaced with constants even if the constants cost more than the calculations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Component|middle-end |target --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-02 08:54:44 UTC --- The ARM backend should do a splitter just like the rs6000 back-end does if it is faster/smaller to load a constant via the instructions.
[Bug tree-optimization/51070] [4.6/4.7 Regression] ICE verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51070 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression] ICE|[4.6/4.7 Regression] ICE |verify_gimple failed|verify_gimple failed --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 09:08:52 UTC --- Confirmed.
[Bug fortran/51682] Coarray ICEs when compiling with -fdefault-integer-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51682 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-02 09:54:44 UTC --- Author: burnus Date: Mon Jan 2 09:54:37 2012 New Revision: 182781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182781 Log: 2012-01-02 Tobias Burnus bur...@net-b.de PR fortran/51682 * trans-intrinsic.c (trans_this_image, trans_image_index, trans_num_images, conv_intrinsic_cobound): Fold_convert the caf_num_images/caf_this_images variables to the correct int kind. 2012-01-02 Tobias Burnus bur...@net-b.de PR fortran/51682 * gfortran.dg/coarray/image_index_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/image_index_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51682] Coarray ICEs when compiling with -fdefault-integer-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51682 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-02 09:57:45 UTC --- FIXED on the 4.7 trunk. Thanks for the report Dominique!
[Bug c++/51722] Options -g3 or -ggdb3 or -g3 -gdwarf-2 and other -g..level3 - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:15:57 UTC --- Try disabling PCH, too. If PCH is required to reproduce the bug also include all preprocessed headers to build the PCH.
[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-02 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:19:13 UTC --- (In reply to comment #2) This is a common problem with the -Warray-bounds warning, first jump threading (during vrp1) optimizes it into just a single s == 17 check, followed by a[11] = 0; b[11] = 0; c[17] = 0; d[11] = 0; if true and a[s] = 0; etc. if false (well, at the end of vrp1 the constants aren't in the array refs yet, but they are propagated there afterwards), and as no optimization figures out the weird if (s 1 == 0) check (if (s 2) would DTRT) to determine that s is not 17, vrp2 warns about those accesses. Perhaps for -Warray-bounds (at least if not -Warray-bounds=2 or similar) we shouldn't warn on code that has been jump threaded, anyway, I don't think that is solvable for 4.7 easily. What we perhaps could do more easily for this testcase (and could improve code too) is during VRP for: bb 2: D.1716_2 = s_1(D) 1; if (D.1716_2 == 0) goto bb 3; else goto bb 12; (or any other constant after , both signed and unsigned right shift, and == or !=) insert ASSERT_EXPRs into both bbs, saying that the SSA_NAME in rhs1 of the shift is in/out of second ==/!= operand rhs2 of shift, -- + ((1 rhs2) - 1) range. In this case it would be ASSERT_EXPRs that s_1(D) = 1 at the start of bb 3 (and if bb 12 had only one predecessor, also that s_1(D) 1 at bb 12 start). Richard, what do you think about that? Yeah, if that turns out to be a common pattern, though maybe restrict it to ==/!= 0 tests? (if that simplifies the patch)
[Bug tree-optimization/51719] [4.7 Regression] ICE: verify_gimple failed: LHS in noreturn call with -fpartial-inlining -fprofile-use and exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51719 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-02 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:20:54 UTC --- Confirmed.
[Bug gcov-profile/51717] [4.7 Regression] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51717 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||nathan at acm dot org Target Milestone|--- |4.7.0 Summary|FAIL: |[4.7 Regression] FAIL: |gcc.misc-tests/gcov-14.c|gcc.misc-tests/gcov-14.c |(test for excess errors)|(test for excess errors)
[Bug gcov-profile/51715] [4.7 Regression] FAIL: gcc.misc-tests/gcov-13.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51715 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||nathan at acm dot org Target Milestone|--- |4.7.0 Summary|FAIL: |[4.7 Regression] FAIL: |gcc.misc-tests/gcov-13.c|gcc.misc-tests/gcov-13.c |execution test |execution test
[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-02 Target Milestone|--- |4.7.0 Summary|FreeBSD uses unsupported|[4.7 Regression] FreeBSD |C++11 features when |uses unsupported C++11 |__cplusplus == 201103L |features when __cplusplus ||== 201103L Ever Confirmed|0 |1
[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721 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 #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 10:24:55 UTC --- Created attachment 26216 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26216 gcc47-pr51721.patch Uptested patch, this time even with testcases. Restricting just to EQ_EXPR/NE_EXPR would save just 3 extra stmts and two ifs in the patch, and restricting to EQ_EXPR/NE_EXPR with constant 0 as opposed to any constant wouldn't simplify the patch at all.
[Bug tree-optimization/51692] [4.7 Regression] ICE on several valgrind tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51692 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:26:37 UTC --- Mine.
[Bug target/51687] gcc is killed when compiling med-3.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51687 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-02 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:30:51 UTC --- Can't reproduce it either - the testcase uses a mere 40MB for 4.7 and 4.6.2 on x86_64-linux with -m32. Please check why your OS kills the process (and which process is killed).
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #38 from Marc Glisse marc.glisse at normalesup dot org 2012-01-02 10:39:35 UTC --- Thanks for the comments. (In reply to comment #36) The library should overload qsort, then the libitm/clone.cc change wouldn't be needed Indeed, that was the meaning of my comment provide the true qsort prototype instead, I'll do that next time. (In reply to comment #37) I think the change to tree.c should not be done as it is middle-end code. That should be in the C++ front-end specific code instead. That is the middle-end should not care about the difference between extern C function types and extern C++ ones. That makes sense. I am surprised to see that I only use the new function once outside of the cp/ directory, and I don't even know whether that is really necessary. On the other hand, there may be other places I missed that need to preserve this information while building variants of the type. And keeping it in tree.c avoids duplicating this code. Maybe it would make sense to keep it in the middle-end, making the extra field an opaque extra information that the middle-end needs to preserve if it ever builds type variants? Although if it clones the function in some way, preserving the linkage may not make that much sense. (I don't have any experience so I may talk nonsense ;-) This information is supposed to be related to the calling convention (although the g++ ABI uses the same in all cases), which I guess is relevant to pass down to middle and back-end (then it isn't opaque anymore). The functions like __builtin_memcpy declared in tree.c should probably have C linkage. Which means it might be better if I switched to using a non-zero value for C++ linkage (or at least make build_function_type build a C linkage type by default) so I don't interfere as much with the rest. So many choices... Well, that's for the next holidays unless someone else wants to work on it.
[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02
10:43:03 UTC ---
Analyzing function body size: float add1(float)
Accounting size:2.00, time:0.00 on new predicate:(not inlined)
BB 2 predicate:(true)
D.2207_2 = x_1(D) + 1.0e+0;
freq:1.00 size: 1 time: 1
Accounting size:1.00, time:1.00 on predicate:(true)
return D.2207_2;
freq:1.00 size: 1 time: 2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate:(not inlined)
Inline summary for float add1(float)/0 inlinable
self time: 3
global time: 0
self size: 4
global size: 0
self stack: 0
global stack:0
size:1.00, time:1.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
calls:
float add1(float) (float x)
{
float D.2207;
bb 2:
D.2207_2 = x_1(D) + 1.0e+0;
return D.2207_2;
}
Analyzing function body size: void process_fun_at(const Fun, T) [with Fun =
float(float); T = float]
Accounting size:2.00, time:0.00 on new predicate:(not inlined)
BB 2 predicate:(true)
D.2206_3 = fun_1(D) (x_2(D));
freq:1.00 size: 5 time: 17
D.2205_4 = D.2206_3;
freq:1.00 size: 0 time: 0
process (D.2205_4);
freq:1.00 size: 2 time: 11
return;
freq:1.00 size: 1 time: 2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate:(not inlined)
Inline summary for void process_fun_at(const Fun, T) [with Fun = float(float);
T = float]/2 inlinable
self time: 30
global time: 0
self size: 10
global size: 0
self stack: 0
global stack:0
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
calls:
void process(float)/3 function body not available
loop depth: 0 freq:1000 size: 2 time: 11 callee size: 0 stack: 0
indirect call loop depth: 0 freq:1000 size: 5 time: 17
Inline summary for void test(float)/1 inlinable
self time: 14
global time: 0
self size: 6
global size: 0
self stack: 0
global stack:0
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
calls:
void process_fun_at(const Fun, T) [with Fun = float(float); T = float]/2
function not considered for inlining
loop depth: 0 freq:1000 size: 3 time: 12 callee size: 5 stack: 0
void test(float) (float i)
{
bb 2:
process_fun_atfloat(float), float (add1, i_1(D));
return;
}
during early inlining we decide:
;; Function void test(float) (_Z4testf, funcdef_no=2, decl_uid=2196,
cgraph_uid=1)
Considering inline candidate void process_fun_at(const Fun, T) [with Fun =
float(float); T = float].
Estimating body: void process_fun_at(const Fun, T) [with Fun =
float(float); T = float]/2
Known to be false: not inlined
size:7 time:28
Estimating body: void process_fun_at(const Fun, T) [with Fun =
float(float); T = float]/2
Known to be false: not inlined
size:7 time:28
will not early inline: void test(float)/1-void process_fun_at(const Fun, T)
[with Fun = float(float); T = float]/2, callee is not leaf and code would grow
by 4
Iterations: 0
void test(float) (float i)
{
bb 2:
process_fun_atfloat(float), float (add1, i_1(D));
because we'd replace one call with two. Not sure what the
Inline summary for void process_fun_at(const Fun, T) [with Fun = float(float);
T = float]/2 inlinable
...
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
lines mean. Honza?
[Bug other/51679] spurious parenthesis for -fassociative-math in manual and man page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51679 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:46:04 UTC --- Author: rguenth Date: Mon Jan 2 10:46:01 2012 New Revision: 182785 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182785 Log: 2012-01-02 Richard Guenther rguent...@suse.de PR other/51679 * invoke.texi (fassociative-math): Remove spurious paranthesis. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug other/51679] spurious parenthesis for -fassociative-math in manual and man page
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51679 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:46:25 UTC --- Fixed.
[Bug other/51678] 'make pdf' is broken in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51678 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:47:19 UTC --- Must be broken since forever or caused by your host TeX installation.
[Bug c/51676] -Wsuggest-attribute={pure,const} should give line number of declaration, not definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51676 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-02 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:48:54 UTC --- Yeah, it's pretty difficult (read: impossible) to implement. Consider multiple declarations as well ...
[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51675 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.2 Target Milestone|--- |4.7.0 Summary|ICE verify-gimple with |[4.7 Regression] ICE |openmp |verify-gimple with openmp --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:54:40 UTC --- Works with 4.6.
[Bug bootstrap/51686] make install-strip-gcc didn't install liblto-plugin* files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51686 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 10:59:08 UTC --- Author: rguenth Date: Mon Jan 2 10:59:04 2012 New Revision: 182788 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182788 Log: 2012-01-02 Richard Guenther rguent...@suse.de PR bootstrap/51686 * Makefile.def (install-strip-gcc): Depend on install-strip-lto-plugin. * Makefile.in: Regenerate. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in
[Bug bootstrap/51686] make install-strip-gcc didn't install liblto-plugin* files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51686 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 11:02:15 UTC --- Author: rguenth Date: Mon Jan 2 11:02:10 2012 New Revision: 182790 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182790 Log: 2012-01-02 Richard Guenther rguent...@suse.de PR bootstrap/51686 * Makefile.def (install-strip-gcc): Depend on install-strip-lto-plugin. * Makefile.in: Regenerate. Modified: branches/gcc-4_6-branch/ChangeLog branches/gcc-4_6-branch/Makefile.def branches/gcc-4_6-branch/Makefile.in
[Bug bootstrap/51686] make install-strip-gcc didn't install liblto-plugin* files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51686 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 11:02:25 UTC --- Fixed.
[Bug middle-end/51728] [4.7 Regression]: libstdc++ 25_algorithms/count_if/1.cc, 25_algorithms/partition_point/1.cc, 25_algorithms/search/1.cc SEGV ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51728 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|regression |middle-end Target Milestone|--- |4.7.0
[Bug target/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-02 Component|lto |target Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 11:17:47 UTC --- Please attach the resolution file (you can obtain it by adding -v -save-temps to the command-line, the file is the one mentioned as argument to the -fresolution= command-line argument to lto1.exe) What binutils version are you using? I suspect a mismatch between binutils/gcc here.
[Bug target/51726] LTO and attribute 'selectany'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-02
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02
11:19:41 UTC ---
It's a target bug - the target should ignore the attribute on extern
declarations.
case VAR_DECL:
if (lookup_attribute (selectany, DECL_ATTRIBUTES (decl)))
{
if (DECL_INITIAL (decl)
/* If an object is initialized with a ctor, the static
initialization and destruction code for it is present in
each unit defining the object. The code that calls the
ctor is protected by a link-once guard variable, so that
the object still has link-once semantics, */
|| TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl)))
make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
else
error (%q+D:'selectany' attribute applies only to
initialized objects, decl);
}
thus, restrict processing to !DECL_EXTERNAL
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-02 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug c++/51724] no matching function for call; confused by earlier errors, bailing out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51724 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 Known to fail||4.6.2 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 11:23:25 UTC --- Confirmed, the branch ICEs like t.C: In member function ‘void solverT, Plugin::foo(solverT, Plugin::type) [with T = int, Plugin = plugin, solverT, Plugin::type = int]’: t.C:39:32: instantiated from here t.C:33:3: error: no matching function for call to ‘plugin::foo(solverint, plugin , solverint, plugin ::type)’ t.C:33:3: note: candidates are: in dependent_type_p, at cp/pt.c:18102 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fixed on trunk.
[Bug testsuite/51703] FAIL: gfortran.dg/io_real_boz_[345].f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51703 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 2012-01-02 11:24:32 UTC --- Seemingly fixed by http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00026.html Thanks for the report - and thanks to Richard for the patch. Please confirm that it is now fixed - and close the bug.
[Bug target/51729] New: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 Bug #: 51729 Summary: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org dspr2-MULT.c and dspr2-MULTU.c are supposed to test that we use the DSP accumulator registers to parallelise multiplications. They don't work in 4.7, and I'm about to XFAIL them. There seem to be two main problems: * The cost of moving between DSP accumulators is greater than the cost of moving a DSP register to or from memory. When I last looked, this was enough to make the register allocator consider memory to be cheaper. This isn't a problem without -mdsp because there is then only one accumulator register, LO+HI. (Note that we no longer allow HI and LO to store independent values.) The cost of moving between accumulators is therefore ignored. On some (many?) targets, moving something out of an accumulator and back again _is_ more expensive than storing an accumulator to memory, so this isn't necessarily a bug in the backend. * Even if we massage the costs to avoid that problem, each of the pseudos that we'd like to use accumulators has one =ka constraint and one d constraint. At one point this meant that DSP_REGS and GENERAL_REGS had the same cost, and reg_alloc_order could be used to prefer accumulators: http://gcc.gnu.org/ml/gcc/2010-12/msg00471.html http://gcc.gnu.org/ml/gcc/2011-01/msg00093.html But GENERAL_REGS now seems to have a lower cost, and since GENERAL_REGS are much easier to spill than DSP_REGS, it's hard to argue with that.
[Bug target/51729] dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-01-02 11:33:39 UTC --- Author: rsandifo Date: Mon Jan 2 11:33:35 2012 New Revision: 182793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182793 Log: gcc/testsuite/ PR target/51729 * gcc.target/mips/dspr2-MULT.c: Remove -ffixed-hi -ffixed-lo. XFAIL. * gcc.target/mips/dspr2-MULTU.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c
[Bug rtl-optimization/47477] [4.6/4.7/4.8 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|4.7.0 |4.8.0 Summary|[4.6/4.7 regression]|[4.6/4.7/4.8 regression] |Sub-optimal mov at end of |Sub-optimal mov at end of |method |method --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 11:36:32 UTC --- Postponing for 4.8, as agreed by Richard this is stage1 material and unfortunately has been forgotten during 4.7 stage1. From quick glance at it, we want to reimplement get_unwidened and the narrowing integer conversion part of convert_to_integer on GIMPLE, must likely in forwprop.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #15 from dodji at seketeli dot org dodji at seketeli dot org 2012-01-02 12:01:45 UTC --- It would be very helpful to get this into 4.6.3 too if it's safe Sure thing. I am currently testing the patch on 4.6. Thanks for the head-up.
[Bug c/51730] New: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Bug #: 51730 Summary: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: js...@gcc.gnu.org During a distro mass rebuild, I found that many packages still have configure generated with autoconf 2.60 through 2.67, and these autoconf contain a not strictly valid C: /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0 reported by James Lemley on 2005-10-05; see http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html This test is not quite right, since xlc is allowed to reject this program, as the initializer for xlcbug is not one of the forms that C requires support for. However, doing the test right would require a runtime test, and that would make cross-compilation harder. Let us hope that IBM fixes the xlc bug, and also adds support for this kind of constant expression. In the meantime, this test will reject xlc, which is OK, since our stdbool.h substitute should suffice. We also test this with GCC, where it should work, to detect more quickly whether someone messes up the test in the future. */ char digs[] = 0123456789; int xlcbug = 1 / ((digs + 5)[-2 + (_Bool) 1] == digs[4] ? 1 : -1); check. Until http://gcc.gnu.org/viewcvs?root=gccview=revrev=172958 GCC has been accepting this though, and I suppose we don't want to fold array refs that way when generating code. Would it be possible to fold it that way (try harder) just when we know we are not going to generate code based on it (or when we know we'd error out otherwise)? I know it sounds like an ugly hack, unfortunately autoconf 2.6[0-7] generated configure scripts are going to be around for many years and the stdbool.h checks would fail in hundreds of packages.
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 12:14:38 UTC --- Note that autoconf 2.59 and earlier didn't contain this and autoconf 2.68 removed it again, as it started failing with newer xlc version too.
[Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 Bug #: 51731 Summary: code generation bug in negative indices in arrays on 64-bit targets Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m.hekkel...@cmbi.ru.nl Created attachment 26217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26217 source file containing a fully self contained bug description When compiling the attached code with -O3 the generated code is incorrect as can be seen by the output of the program. The problem was introduced in gcc 4.5, earlier versions did not have this problem.
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-01-02 12:29:05 UTC --- I am testing patches for both issues.
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-01-02 12:31:24 UTC --- (In reply to comment #1) FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test It is not related to original failure; following patchlet fixes the failure: --cut here-- @@ -11207,7 +11210,7 @@ expand_vec_perm_broadcast (struct expand_vec_perm_ elt *= BITS_PER_UNIT; temp = gen_reg_rtx (DImode); emit_insn (gen_extzv (temp, gen_lowpart (DImode, d-op0), - GEN_INT (elt), GEN_INT (8))); + GEN_INT (8), GEN_INT (elt))); emit_insn (gen_mux1_brcst_qi (d-target, gen_lowpart (QImode, temp))); break; --cut here--
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-02 12:30:42 UTC --- See also RFC patch: http://gcc.gnu.org/ml/fortran/2011-10/msg00136.html and reply: http://gcc.gnu.org/ml/fortran/2011-10/msg00138.html
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681
--- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-01-02 12:35:25
UTC ---
Patch:
--cut here--
Index: ia64.c
===
--- ia64.c (revision 182780)
+++ ia64.c (working copy)
@@ -11085,7 +11085,7 @@ static bool
expand_vec_perm_shrp (struct expand_vec_perm_d *d)
{
unsigned i, nelt = d-nelt, shift, mask;
- rtx tmp, op0, op1;;
+ rtx tmp, hi, lo;
/* ??? Don't force V2SFmode into the integer registers. */
if (d-vmode == V2SFmode)
@@ -11101,6 +11101,11 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
if (d-testing_p)
return true;
+ hi = shift nelt ? d-op1 : d-op0;
+ lo = shift nelt ? d-op0 : d-op1;
+
+ shift %= nelt;
+
shift *= GET_MODE_UNIT_SIZE (d-vmode) * BITS_PER_UNIT;
/* We've eliminated the shift 0 case via expand_vec_perm_identity. */
@@ -3,11 +8,9 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
shift = 64 - shift;
tmp = gen_reg_rtx (DImode);
- op0 = (shift nelt ? d-op0 : d-op1);
- op1 = (shift nelt ? d-op1 : d-op0);
- op0 = gen_lowpart (DImode, op0);
- op1 = gen_lowpart (DImode, op1);
- emit_insn (gen_shrp (tmp, op0, op1, GEN_INT (shift)));
+ hi = gen_lowpart (DImode, hi);
+ lo = gen_lowpart (DImode, lo);
+ emit_insn (gen_shrp (tmp, hi, lo, GEN_INT (shift)));
emit_move_insn (d-target, gen_lowpart (d-vmode, tmp));
return true;
--cut here--
Just a bunch of mix-ups; where high/low part goes, shift value is not adjusted
after operand swap, and shift value is compared in *bits* to number of
elements.
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529 --- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 12:46:14 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182796 Log: 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 --- Comment #12 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 12:46:15 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182796 Log: 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51052 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 12:46:16 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182796 Log: 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 12:46:15 UTC --- Author: pault Date: Mon Jan 2 12:46:08 2012 New Revision: 182796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182796 Log: 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/51529 * trans-array.c (gfc_array_allocate): Null allocated memory of newly allocted class arrays. PR fortran/46262 PR fortran/46328 PR fortran/51052 * interface.c(build_compcall_for_operator): Add a type to the expression. * trans-expr.c (conv_base_obj_fcn_val): New function. (gfc_conv_procedure_call): Use base_expr to detect non-variable base objects and, ensuring that there is a temporary variable, build up the typebound call using conv_base_obj_fcn_val. (gfc_trans_class_assign): Pick out class procedure pointer assignments and do the assignment with no further prcessing. (gfc_trans_class_array_init_assign, gfc_trans_class_init_assign gfc_trans_class_assign): Move to top of file. * gfortran.h : Add 'base_expr' field to gfc_expr. * resolve.c (get_declared_from_expr): Add 'types' argument to switch checking of derived types on or off. (resolve_typebound_generic_call): Set the new argument. (resolve_typebound_function, resolve_typebound_subroutine): Set 'types' argument for get_declared_from_expr appropriately. Identify base expression, if not a variable, in the argument list of class valued calls. Assign it to the 'base_expr' field of the final expression. Strip away all references after the last class reference. 2012-01-02 Paul Thomas pa...@gcc.gnu.org PR fortran/46262 PR fortran/46328 PR fortran/51052 * gfortran.dg/typebound_operator_7.f03: New. * gfortran.dg/typebound_operator_8.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-01-02 12:52:00 UTC --- Author: gjl Date: Mon Jan 2 12:51:57 2012 New Revision: 182797 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182797 Log: contrib/ PR target/51345 * gcc_update (files_and_dependencies): Add gcc/config/avr/t-multilib, gcc/config/avr/multilib.h. libgcc/ PR target/51345 * config/avr/lib1funcs.S: Remove FIXME comments. (SPEED_DIV): Depend on __AVR_HAVE_8BIT_SP__. gcc/ PR target/51345 * config.gcc (tm_file target=avr]): Add avr/avr-multilib.h (tmake_file target=avr): Add avr/t-multilib. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Use AVR_HAVE_8BIT_SP to built-in define __AVR_HAVE_8BIT_SP__, __AVR_HAVE_16BIT_SP__. * config/avr/genmultilib.awk: New file. * config/avr/t-multilib: New auto-generated file. * config/avr/multilib.h: New auto-generated file. * config/avr/t-avr (AVR_MCUS): New variable. (genopt.sh): Use it. (s-mlib): Depend on t-multilib. (t-multilib, multilib.h): New dependencies. (s-avr-mlib): New rule to build t-multilib, multilib.h from AVR_MCUS. (MULTILIB_OPTIONS): Remove. (MULTILIB_MATCHES): Remove. (MULTILIB_DIRNAMES): Remove. (MULTILIB_EXCEPTIONS): Remove: * config/avr/genopt.sh: Don't use hard coded file name; pass AVR_MCUS from t-avr instead. Added: trunk/gcc/config/avr/genmultilib.awk trunk/gcc/config/avr/multilib.h trunk/gcc/config/avr/t-multilib Modified: trunk/contrib/ChangeLog trunk/contrib/gcc_update trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/genopt.sh trunk/gcc/config/avr/t-avr trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S
[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51052 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #9 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:00:36 UTC --- Fixed on trunk. Thanks for the report Paul
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:01:21 UTC --- Fixed on trunk. Thanks for the report Paul
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-01-02 13:03:35 UTC --- On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote: char digs[] = 0123456789; int xlcbug = 1 / ((digs + 5)[-2 + (_Bool) 1] == digs[4] ? 1 : -1); check. Until http://gcc.gnu.org/viewcvs?root=gccview=revrev=172958 GCC has been accepting this though, and I suppose we don't want to fold array refs that way when generating code. Would it be possible to fold it that way (try harder) just when we know we are not going to generate code based on it (or when we know we'd error out otherwise)? I know it sounds like an ugly As I understand it, the point of that commit was that the conversion of all array references to pointer arithmetic (losing all information about signs of indices) was problematic. But it should still be valid to fold a comparison that way: if the addresses being compared have the same base object and all offsets are constant integers, a final byte offset for each address can be computed mod the size of the address space and it's OK to fold based on comparing those offsets (if the actual, signed offsets involved overflow anywhere, that would have been execution-time undefined behavior). That is, I think it would be better to fix this by improving the folding of address comparisons, rather than by changing how array references are expanded.
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:03:12 UTC --- Fixed on trunk. Thanks to everybody for the reports and testcases. Paul
[Bug other/51732] New: typo in man gcc: runt-time check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51732 Bug #: 51732 Summary: typo in man gcc: runt-time check Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: martinw...@gmail.com man gcc says: -mno-8bit-idiv On some processors, like Intel Atom, 8bit unsigned integer divide is much faster than 32bit/64bit integer divide. This option will generate a runt-time check. If both dividend and divisor are within range of 0 to 255, 8bit unsigned integer divide will be used instead of 32bit/64bit integer divide. Can we fix runt-time? This is new in gcc-4.6
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:04:43 UTC --- Fixed on trunk. Thanks for the reports Paul
[Bug fortran/51334] [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:556
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51334 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pault at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:08:18 UTC --- Fixed on trunk by r182796. (Forgot to put this in the ChangeLogs!). Thanks for the report Paul
[Bug tree-optimization/45397] [4.5/4.6/4.7 Regression] Issues with integer narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2012-01-02 13:09:09 UTC --- Hmm, we could solve this via forward-propagation in gimple, too. I have a patch which does this, but not sure if it is material for current stage. The missing patterns in forward-propagation are: - X ==/!= X - true/false, - (type) X ==/!= (type) X - true/false - X code Y ==/!= X code Z - Y ==/!= Z (with code +, -, or ^). - (type) X ==/!= Y CST - X ==/!= (type-of-X) (Y CST) if type-of-X has smaller, or equal precision as type and is unsigned, and type-of-x and type are of integral kind, and CST fits into type-of-X. - (type) (X op CST) - (type) X op CST' with CST' = (type) X; and type has smaller or equal precision to type-of-x and both types are of integral kind. (for op = +,-,,|,^) - (type) ((type2) X op Y) - X op (type) Y, if type has smaller or equal precision to type2 and type-of-x is compatible to type, all types are of integral kind, and op is a +,-,,|,or ^ expression.
[Bug fortran/51634] [OOP] ICE with polymorphic operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas pault at gcc dot gnu.org 2012-01-02 13:28:13 UTC --- Fixed on trunk as long as explicit allocations are inserted, as below. I will raise a separate PR for the lack of automatic allocate on assign for class objects with derived type components. Thanks for the report. Paul module field_module implicit none private public :: field type :: field real, allocatable :: f(:) contains procedure :: multiply_real = multiply procedure :: copy = copy_field generic :: operator(*)= multiply_real generic :: assignment(=) = copy end type contains subroutine copy_field (lhs, rhs) class(field), intent(inout) :: lhs class(field), intent(in) :: rhs if (allocated (lhs%f)) deallocate (lhs%f) allocate (lhs%f(size (rhs%f, 1))) lhs%f = rhs%f end subroutine function multiply(lhs,rhs) class(field) ,intent(in) :: lhs real ,intent(in) :: rhs class(field) ,allocatable :: multiply integer :: i allocate(multiply, source = field([(0.0, i = 1, size (lhs%f, 1))])) multiply%f = lhs%f * rhs end function end module field_module program main use field_module implicit none type(field) :: f, g real :: dt, half allocate (g%f(2), source = [1.0, 2.0]) dt = 7 half = 0.5 f = g * dt * half print *, f%f end program main
[Bug fortran/51733] New: [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 Bug #: 51733 Summary: [OOP] No allocate on assign for class objects with allocatable components. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pa...@gcc.gnu.org The testcase in PR51634 needs explicit allocations, as in the final comment. PR51634 was closed, since the nesting of typebound operators is fixed. Paul
[Bug middle-end/51728] [4.7 Regression]: libstdc++ 25_algorithms/count_if/1.cc, 25_algorithms/partition_point/1.cc, 25_algorithms/search/1.cc SEGV ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51728 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 13:47:46 UTC --- ICEs in exactly the same spot as PR51725 and the same fix cures it. *** This bug has been marked as a duplicate of bug 51725 ***
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 13:47:46 UTC --- *** Bug 51728 has been marked as a duplicate of this bug. ***
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02
13:52:14 UTC ---
Seems that canonical vs. non-canonical VALUEs are mixed up.
In cselib_invalidate_mem, we don't terminate the loop:
addr = cselib_lookup (XEXP (x, 0), VOIDmode, 0, GET_MODE (x));
mem_chain = addr-addr_list;
for (;;)
{
if ((*mem_chain)-elt == v)
{
unchain_one_elt_list (mem_chain);
break;
}
mem_chain = (*mem_chain)-next;
}
because v is here a canonical_cselib_val of (*mem_chain)-elt. We could
perhaps
compare here canonical_cselib_val ((*mem_chain)-elt) == v instead, or just
canonicalizing the mem_elt value early when inserting it into
addr_list/*_containing_mem fixes this too:
--- gcc/cselib.c.jj2012-01-01 19:54:46.0 +0100
+++ gcc/cselib.c2012-01-02 14:46:51.180804640 +0100
@@ -1264,6 +1264,8 @@ add_mem_for_addr (cselib_val *addr_elt,
{
struct elt_loc_list *l;
+ mem_elt = canonical_cselib_val (mem_elt);
+
/* Avoid duplicates. */
for (l = mem_elt-locs; l; l = l-next)
if (MEM_P (l-loc)
ALex?
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-02 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 14:01:19 UTC --- (In reply to comment #2) On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote: char digs[] = 0123456789; int xlcbug = 1 / ((digs + 5)[-2 + (_Bool) 1] == digs[4] ? 1 : -1); check. Until http://gcc.gnu.org/viewcvs?root=gccview=revrev=172958 GCC has been accepting this though, and I suppose we don't want to fold array refs that way when generating code. Would it be possible to fold it that way (try harder) just when we know we are not going to generate code based on it (or when we know we'd error out otherwise)? I know it sounds like an ugly As I understand it, the point of that commit was that the conversion of all array references to pointer arithmetic (losing all information about signs of indices) was problematic. But it should still be valid to fold a comparison that way: if the addresses being compared have the same base object and all offsets are constant integers, a final byte offset for each address can be computed mod the size of the address space and it's OK to fold based on comparing those offsets (if the actual, signed offsets involved overflow anywhere, that would have been execution-time undefined behavior). That is, I think it would be better to fix this by improving the folding of address comparisons, rather than by changing how array references are expanded. I think what changed is that we keep digs[4] in the IL now, rather than representing it as digs + 4. So it seems to be some missed folding. Indeed we have (char *) digs + 4 == digs[4] I'll look into this.
[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Blocks||51634 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-02 14:07:17 UTC --- See also the test case in PR 51634.
[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-02 14:11:03 UTC --- (Mixed up the test cases. The PR mentioned in comment 1 is the same as in comment 0 - and a good test case. I mixed it up with PR 46262 comment 3, which is a longer example which also requires allocation on assignment.)
[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02
14:15:39 UTC ---
Like
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 182784)
+++ gcc/fold-const.c(working copy)
@@ -8886,6 +8886,13 @@ fold_comparison (location_t loc, enum tr
indirect_base0 = true;
}
offset0 = TREE_OPERAND (arg0, 1);
+ if (host_integerp (offset0, 1)
+ (TREE_INT_CST_LOW (offset0)
+ ((unsigned HOST_WIDE_INT)-1 (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+ {
+ bitpos0 = TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT;
+ offset0 = NULL_TREE;
+ }
}
base1 = arg1;
@@ -8909,6 +8916,13 @@ fold_comparison (location_t loc, enum tr
indirect_base1 = true;
}
offset1 = TREE_OPERAND (arg1, 1);
+ if (host_integerp (offset1, 1)
+ (TREE_INT_CST_LOW (offset1)
+ ((unsigned HOST_WIDE_INT)-1 (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+ {
+ bitpos1 = TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT;
+ offset1 = NULL_TREE;
+ }
}
/* A local variable can never be pointed to by
to be beautified ...
[Bug bootstrap/51734] New: [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 Bug #: 51734 Summary: [4.7 Regression] Bootstrap fails in libada Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: s390-*-linux When linking libgnat.so we fail like a-calfor.o: In function `ada__calendar__formatting__split': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:399:(.text+0x3aa): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__4': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:444:(.text+0x7ba): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__2': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:492:(.text+0x898): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__split__3': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:540:(.text+0x97c): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o a-calfor.o: In function `ada__calendar__formatting__time_of__2': /home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a -calfor.adb:603:(.text+0xfcc): relocation truncated to fit: R_390_GOT12 against symbol `ada__calendar__days_in_month' defined in .rodata section in a-calend.o [more similar errors in other files omitted] make[5]: *** [gnatlib-shared-default] Error 1 make[5]: Leaving directory `/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s 390-suse-linux/gcc/ada' GCC was configured like + CFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchron ous-unwind-tables -g -U_FORTIFY_SOURCE' + CXXFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchr onous-unwind-tables -g -U_FORTIFY_SOURCE' + XCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchro nous-unwind-tables -g -U_FORTIFY_SOURCE' + TCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchro nous-unwind-tables -g -U_FORTIFY_SOURCE' + GCJFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchr onous-unwind-tables -g -U_FORTIFY_SOURCE' + ../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=yes --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=ht tp://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --disable-libgcj --disabl e-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enab le-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-run time-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex -- without-system-libunwind --with-tune=z196 --with-arch=z10 --with-long-double-128 --enable-decimal-float --build=s390-suse-linux
[Bug bootstrap/51734] [4.7 Regression] Bootstrap fails in libada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51734 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 14:58:30 UTC --- While the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725#c5 change might not be a complete solution, I think it is right and desirable, because new_elt_loc_list doesn't add the MEM location to mem_elt's locs, but to its canonical_cselib_val's locs (if different from mem_elt of course), and at that point we'd be adding e.g. into addr_list as well as first_containing_mem chain something that didn't get any MEM locs.
[Bug c++/51722] Options -g3 or -ggdb3 or -g3 -gdwarf-2 and other -g..level3 - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722 --- Comment #3 from Yuriy Lalym ylalym at gmail dot com 2012-01-02 15:06:30 UTC --- Without PCH errors aren't present. all preprocessed headers to build the PCH #include stdio.h It is enough one header for error origin.
[Bug c++/51722] Options -g3 or -ggdb3 or -g3 -gdwarf-2 and other -g..level3 - internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51722
--- Comment #4 from Yuriy Lalym ylalym at gmail dot com 2012-01-02 15:16:03
UTC ---
main.cpp
---
#include QtCore/QCoreApplication
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
return a.exec();
}
---
pch.h
---
#include stdio.h
g++-4.7 -m64 -pipe -g3 -gdwarf-4 -fvar-tracking-assignments -Wall -W
-D_REENTRANT -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I.
-I/usr/include/QtCore -I/usr/include -I. -x c++-header -c pch.h -o
untitled5.gch/c++
g++-4.7 -c -include untitled5 -m64 -pipe -g3 -gdwarf-4
-fvar-tracking-assignments -Wall -W -D_REENTRANT -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include -I.
-o main.o main.cpp
*** glibc detected *** /usr/local/lib/gcc/x86_64-suse-linux/4.7.0/cc1plus:
double free or corruption (out): 0x0010c180 ***
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02
15:29:20 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=181332 aka PR51060.
Slightly more reduced testcase:
template typename T const T min (const T , const T );
void
foo ()
{
#pragma omp parallel num_threads (min (4, 5))
;
}
which ICEs starting with r181332 with just -fopenmp.
struct A { A (); ~A (); };
int foo (const A );
void
foo ()
{
#pragma omp parallel num_threads (foo (A ()))
;
}
apparently ICEd already in 4.2 though. Guess the C++ FE needs to insert some
CLEANUP_POINT_EXPRs around the omp stmts.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-02 15:52:45 UTC --- (In reply to comment #20) Fortunately it seems that this bug was the last issue that needed to be fixed. Firefox now builds fine with -lto and -g. Can you also check the following variant? Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 182784) +++ gcc/dwarf2out.c (working copy) @@ -22501,15 +22501,8 @@ dwarf2out_finish (const char *filename) else if (TYPE_P (node-created_for)) context = TYPE_CONTEXT (node-created_for); - gcc_assert (context - (TREE_CODE (context) == FUNCTION_DECL - || TREE_CODE (context) == NAMESPACE_DECL)); - - origin = lookup_decl_die (context); - if (origin) - add_child_die (origin, die); - else - add_child_die (comp_unit_die (), die); + origin = get_context_die (context); + add_child_die (origin, die); } } }
[Bug c++/20140] template function complains about char-array initialized from wide string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20140 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-01-02 16:15:55 UTC --- Author: paolo Date: Mon Jan 2 16:15:49 2012 New Revision: 182805 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182805 Log: /cp 2012-01-02 Paolo Carlini paolo.carl...@oracle.com PR c++/20140 * typeck2.c (digest_init_r): Use copy_init when initializing an array of chars. /testsuite 2012-01-02 Paolo Carlini paolo.carl...@oracle.com PR c++/20140 * g++.dg/template/init9.C: New. Added: trunk/gcc/testsuite/g++.dg/template/init9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/20140] template function complains about char-array initialized from wide string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20140 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-02 16:16:52 UTC --- Fixed for 4.7.0.
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-02 16:23:42 UTC --- Maybe I'm just tired (sorry in case) but I really don't see how this can possibly work: *negative* index?!? Can you explain?
[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 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 #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 16:29:29 UTC --- Created attachment 26218 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26218 gcc47-pr51669.patch Untested fix.
[Bug bootstrap/51735] New: [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735 Bug #: 51735 Summary: [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org Bootstrap started failing on s390x with r182760: /home/andreas/git/gcc-head/gcc/tree-ssa-pre.c: In function ‘bool insert_aux(basic_block)’: /home/andreas/git/gcc-head/gcc/tree-ssa-pre.c:3791:1: internal compiler error: Segmentation fault This might be a duplicate of PR51725.
[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Target||s390x-ibm-linux Priority|P3 |P2 Host||s390x-ibm-linux Build||s390x-ibm-linux
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #22 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-01-02 16:52:49 UTC --- (In reply to comment #21) (In reply to comment #20) Fortunately it seems that this bug was the last issue that needed to be fixed. Firefox now builds fine with -lto and -g. Can you also check the following variant? Yes. This one is also OK.
[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51735
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02
16:54:47 UTC ---
Is the segfault in the
for (;;)
{
if ((*mem_chain)-elt == v)
{
unchain_one_elt_list (mem_chain);
break;
}
mem_chain = (*mem_chain)-next;
}
loop (or, does the #c5 patch from that PR fix it)?
[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51462 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-02 17:00:21 UTC --- Author: dodji Date: Mon Jan 2 17:00:13 2012 New Revision: 182806 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182806 Log: PR c++/51462 - ICE in cx_check_missing_mem_inits gcc/cp/ PR c++/51462 * semantics.c (cx_check_missing_mem_inits): Don't assert in case of error. gcc/testsuite/ PR c++/51462 * g++.dg/cpp0x/constexpr-99.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-99.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #9 from Damian Rouson damian at rouson dot net 2012-01-02 17:01:47 UTC --- Thanks for the fix! I'm very excited about the way 4.7 is shaping up. It appears this will be a very significant release for those interested in the more advanced capabilities of OOP. Damian
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731
--- Comment #2 from M.L. Hekkelman m.hekkelman at cmbi dot ru.nl 2012-01-02
17:03:46 UTC ---
Beste paolo.carlini,
maandag 2 januari 2012, 17:23:42, schreef je:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com
2012-01-02 16:23:42 UTC ---
Maybe I'm just tired (sorry in case) but I really don't see how this can
possibly work: *negative* index?!? Can you explain?
It is a technique that dates back to, who knows when. It is even
common practice to have a zero sized array in the struct, like this:
struct page
{
charkeys[1024];
int offsets[0];
};
This way you have a fixed size page you can write to disk containing
non terminated strings in keys and the direct offsets to the keys in
the offsets arrays. Fill the page until the keys and offsets would
collide with the addition of a new key.
E.g. the B-Tree implementation of the HFS file system in MacOS
Classic uses this.
I have used code like this for many years now, and this code works
with all compilers I'm aware off but not with gcc 4.5 and 4.6.
[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51731 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-02 17:10:17 UTC --- Having a zero-sized array at the end of a struct is surely a commonly used technique, close to standard flexible array members, but that is not what you are doing. Trying to reference data.e[-1] through data.e[-9] is of course not valid C++ (nor C) when e is an array (it might be valid if e was a pointer and pointed into the middle of some array).
[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51462 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-02 17:10:15 UTC --- Should be fixed in 4.7 (trunk)
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #16 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-02 17:08:50 UTC --- Author: dodji Date: Mon Jan 2 17:08:45 2012 New Revision: 182807 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182807 Log: PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gcov/gcov-2.C
[Bug c++/51151] Invalid -Woverflow warning in C++ frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-02 17:34:19 UTC --- Andreas, can we close this?
