Hi,
I have installed latest 1.8.5.1 git to confirm the behaviour I had seen
in previous versions.
What I see is that when I cherry-pick a patch across two branches
(source and destination) in a repository, cherry-pick picks changes from
the source branch which do not exist in the cherry-picked patch.
To reproduce please follow the following in a clean directory (apologies
for the large repo I use as example):
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout -b gcc-4_8-branch origin/gcc-4_8-branch
$ cd gcc
$ sed -i '877i myport_hook ()' tree-ssa-threadedge.c
$ git diff tree-ssa-threadedge.c
index b31e961..f022eed 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -874,6 +874,7 @@ thread_across_edge (gimple dummy_cond,
if (cond_arg_set_in_bb (e, e->dest))
goto fail;
}
+myport_hook ()
stmt_count = 0;
$ git add tree-ssa-threadedge.c
$ git commit -m 'cherry-pick test'
[gcc-4_8-branch 49a2b7f] cherry-pick test
1 file changed, 1 insertion(+)
$ git checkout master
$ git cherry-pick 49a2b7f # ensure you're cherry-picking the right sha
error: could not apply 49a2b7f... cherry-pick test
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
$ git diff tree-ssa-threadedge.c
diff --cc gcc/tree-ssa-threadedge.c
index cb6accf,f022eed..0000000
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@@ -936,34 -854,33 +936,47 @@@ thread_around_empty_blocks (edge taken_
STACK is used to undo temporary equivalences created during the
walk of
E->dest.
- SIMPLIFY is a pass-specific function used to simplify statements.
*/
-
-void
-thread_across_edge (gimple dummy_cond,
- edge e,
- bool handle_dominating_asserts,
- vec<tree> *stack,
- tree (*simplify) (gimple, gimple))
-{
- gimple stmt;
+ SIMPLIFY is a pass-specific function used to simplify statements.
++<<<<<<< HEAD
+ Our caller is responsible for restoring the state of the expression
+ and const_and_copies stacks. */
++=======
+ /* If E is a backedge, then we want to verify that the COND_EXPR,
+ SWITCH_EXPR or GOTO_EXPR at the end of e->dest is not affected
+ by any statements in e->dest. If it is affected, then it is not
+ safe to thread this edge. */
+ if (e->flags & EDGE_DFS_BACK)
+ {
+ if (cond_arg_set_in_bb (e, e->dest))
+ goto fail;
+ }
+ myport_hook ()
++>>>>>>> 49a2b7f... cherry-pick test
- stmt_count = 0;
+static bool
+thread_through_normal_block (edge e,
+ gimple dummy_cond,
+ bool handle_dominating_asserts,
+ vec<tree> *stack,
+ tree (*simplify) (gimple, gimple),
+ vec<jump_thread_edge *> *path,
+ bitmap visited,
+ bool *backedge_seen_p,
+ bitmap src_map,
+ bitmap dst_map)
+{
+ /* If we have traversed a backedge, then we do not want to look
+ at certain expressions in the table that can not be relied upon.
+ Luckily the only code that looked at those expressions is the
+ SIMPLIFY callback, which we replace if we can no longer use it.
*/
+ if (*backedge_seen_p)
+ simplify = dummy_simplify;
/* PHIs create temporary equivalences. */
- if (!record_temporary_equivalences_from_phis (e, stack))
- goto fail;
+ if (!record_temporary_equivalences_from_phis (e, stack,
*backedge_seen_p,
+ src_map, dst_map))
+ return false;
/* Now walk each statement recording any context sensitive
temporary equivalences we can detect. */
Note how there are changes that are not part of the cherry-picked patch
outside of the conflicting zone. This is trouble some because it means
that when I go in to fix a patch and look only at the conflicting zone,
I will have code outside the zone, that are _not_ part of the patch
modified as well.
Is this a bug or a feature? If the latter, why this behaviour and how
can I avoid it?
Cheers,
--
Paulo Matos
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html