User account creation filtered due to spam.
extern void link_error (void);
void bar0 (int * __restrict__ arr1, int * __restrict__ arr2)
arr1 = 1;
arr2 = 1;
if (arr1 != 1)
arr1 and arr2 should not alias, hence the "if" should be eliminated
The .optimized dump is:
bar0 (arr1, arr2)
# TMT.46_5 = VDEF <TMT.46_4>;
*arr1 = 1;
# TMT.46_6 = VDEF <TMT.46_5>;
*arr2 = 1;
if (*arr1 != 1) goto <L0>; else goto <L1>;
# TMT.46_7 = VDEF <TMT.46_6>;
Works for me with GNU C version 3.5-tree-ssa 20040217 (merged
0: 01 00 3f 20 lda t0,1
4: 00 00 31 b0 stl t0,0(a1)
8: 00 00 30 b0 stl t0,0(a0)
c: 01 80 fa 6b ret
Which version and target are you seeing this problem for?
Interestingly the following code is optimized:
extern int foo (int * , int *);
void bar1 (void)
int * arr1 = malloc (12);
int * arr2 = malloc (12);
arr1 = 1;
arr2 = 1;
if (arr1 != 1)
foo (arr1, arr2);
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00116.html>.
(In reply to comment #3)
> Interestingly the following code is optimized:
That is because we create a new may_alias variable for malloc to point to so we know that it cannot alias anything.
*** Bug 14192 has been marked as a duplicate of this bug. ***
Note that C restrict semantics make it necessary to properly track what
pointer is based on what other pointer. For this we miss both annotations
and a (simple) propagator that propagates this information, maybe as part
of PTA analysis.
Note that the current implementation has both missed-optimization and latent
*** Bug 16306 has been marked as a duplicate of this bug. ***
*** Bug 16913 has been marked as a duplicate of this bug. ***
*** Bug 28030 has been marked as a duplicate of this bug. ***
*** Bug 29239 has been marked as a duplicate of this bug. ***
*** Bug 32273 has been marked as a duplicate of this bug. ***
*** Bug 33272 has been marked as a duplicate of this bug. ***
*** Bug 33705 has been marked as a duplicate of this bug. ***
This is not solely a tree issue.
Subject: Bug 14187
Date: Mon Jun 29 12:23:21 2009
New Revision: 149048
2009-06-29 Richard Guenther <email@example.com>
* tree-ssa-alias.h (struct pt_solution): Add vars_contains_restrict
* tree-ssa-structalias.c (struct variable_info): Add is_restrict_var
(new_var_info): Initialize is_global_var properly for SSA_NAMEs.
(make_constraint_from, make_copy_constraint): Move earlier.
(make_constraint_from_heapvar): New function.
(handle_lhs_call): Use it.
(find_func_aliases): Use it to track conversions to restrict
(struct fieldoff): Add only_restrict_pointers flag.
(push_fields_onto_fieldstack): Initialize it.
(create_variable_info_for): Track global restrict qualified pointers.
(intra_create_variable_infos): Use make_constraint_from_heapvar.
Track restrict qualified pointer arguments.
(set_uids_in_ptset): Use varinfo is_global_var flag.
(find_what_var_points_to): Set the vars_contains_restrict flag.
Always create the points-to solution for sets including restrict tags.
(pt_solutions_same_restrict_base): New function.
* tree-ssa-alias.c (ptr_derefs_may_alias_p): For two restrict
qualified pointers use pt_solutions_same_restrict_base as
additional source for disambiguation.
* gcc.dg/tree-ssa/restrict-1.c: New testcase.
* gcc.dg/tree-ssa/restrict-2.c: Likewise.
* gcc.dg/tree-ssa/restrict-3.c: Likewise.
* gcc.c-torture/execute/20090623-1.c: Likewise.
* gcc.dg/tree-ssa/ldist-13.c: Likewise.
* gcc.dg/tree-ssa/ldist-14.c: Likewise.
(In reply to comment #17)
Richard, since this is a new feature of GCC 4.5, shouldn't we mention it in the GCC 4.5 changes.html?
Even something short would be welcome by users, such as:
"Better optimizations when using the <a href="http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html">restrict keyword</a>".
Subject: Re: [tree-ssa] C restricted pointers are not
On Mon, 11 Jan 2010, manu at gcc dot gnu dot org wrote:
> ------- Comment #18 from manu at gcc dot gnu dot org 2010-01-11 19:23 -------
> (In reply to comment #17)
> > Fixed.
> Richard, since this is a new feature of GCC 4.5, shouldn't we mention it in the
> GCC 4.5 changes.html?
> Even something short would be welcome by users, such as:
> "Better optimizations when using the <a
It's not universally better tho due to limitations on the RTL export
side. I'll think of sth.
Richi, is restrict working now, even with -fno-strict aliasing?
(In reply to comment #20)
> Richi, is restrict working now, even with -fno-strict aliasing?
Yes, it is. See PR42617 for patches still required on the RTL side, it's
a bit late to apply them for 4.5 now.