On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries <tom_devr...@mentor.com> wrote: > [ quote-pasted from https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html > ] > >> CAST_RESTRICT based disambiguation unfortunately isn't reliable, >> e.g. to store a non-restrict pointer into a restricted field, >> we add a non-useless cast to restricted pointer in the gimplifier, >> and while we don't consider that field to have a special restrict tag >> because it is unsafe to do so, we unfortunately create it for the >> CAST_RESTRICT before that and end up with different restrict tags >> for the same thing. See the PR for more details. >> >> This patch turns off CAST_RESTRICT handling for now, in the future >> we might try to replace it by explicit CAST_RESTRICT stmts in some form, >> but need to solve problems with multiple inlined copies of the same >> function >> with restrict arguments or restrict variables in it and intermixed code >> from >> them (or similarly code from different non-overlapping source blocks). >> >> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> 4.6 too? >> >> 2011-10-06 Jakub Jelinek <ja...@redhat.com> >> >> PR tree-optimization/49279 >> * tree-ssa-structalias.c (find_func_aliases): Don't handle >> CAST_RESTRICT. >> * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Allow >> restrict propagation. >> * tree-ssa.c (useless_type_conversion_p): Don't return false >> if TYPE_RESTRICT differs. >> >> * gcc.dg/tree-ssa/restrict-4.c: XFAIL. >> * gcc.c-torture/execute/pr49279.c: New test. > > > Hi, > > In the patch adding support for CAST_RESTRICT ( > https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00176.html ) there was also a > bit: > ... > * fold-const.c (fold_unary_loc): Don't optimize > POINTER_PLUS_EXPR casted to TYPE_RESTRICT pointer by > casting the inner pointer if it isn't TYPE_RESTRICT. > ... > which is still around. I suppose we can remove this bit as well. > > OK for trunk if bootstrap and reg-test succeeds?
Ok. I think the checks on TREE_OPERAND (arg0, 1) are bogus though and either we should unconditionally sink the conversion or only if a conversion on TREE_OPERAND (arg0, 0) vanishes (I prefer the latter). Richard. > Thanks, > - Tom > >
