git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Unexpected cherry-pick behaviour

From
Paulo Matos <paulo@matos-sorge.com>
Date
Dec 11, 2013, 11:19 UTC
Message-ID
<beee32a53ece8b839578703deb851eaa@matos-sorge.com>
In-Reply-To
<CALWbr2zPPnDiv7oVBhnM9dSW=pfz2jUA_A5u_gk2ttgXTStvkw@mail.gmail.com>
On 11/12/2013 11:09, Antoine Pelisse wrote:
Show 14 quoted lines
>> 
>> I don't know how to interpret the fact that the line you sent (with 
>> the
>> obvious --conflicts being --conflict) outputs nothing...
> 
> That is expected. git-checkout with this option [1] will reset the
> conflict on gcc/tree-ssa-threadedge.c file to the initial conflict
> state, and use the diff3 markers. You should have a new look at that
> file as you will now be able to see the "ancestor" in the conflict.
> 
> [1] You can have a look either at git-checkout manpage or here:
> http://git-scm.com/docs/git-checkout, especially --merge and
> --conflict options.
> --

Got it, but still not helpful as git is still modifying code out of the conflicting zone.

$ git checkout --conflict=diff3 tree-ssa-threadedge.c $ 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,57 @@@ 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.

++<<<<<<< ours
  +   Our caller is responsible for restoring the state of the expression
  +   and const_and_copies stacks.  */
++||||||| base
++  /* 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;
++    }
++=======
+   /* 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 ()
++>>>>>>> theirs

  -  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.  */
-- 
Paulo Matos
Previous: Antoine PelisseNext: Antoine Pelisse
Message 5 of 13 in “Unexpected cherry-pick behaviour”
  1. Paulo MatosDec 10, 2013
  2. Junio C HamanoDec 10, 2013
  3. Paulo MatosDec 11, 2013
  4. Antoine PelisseDec 11, 2013
  5. Paulo MatosDec 11, 2013
  6. Antoine PelisseDec 14, 2013
  7. Philip OakleyDec 14, 2013
  8. Junio C HamanoDec 14, 2013
  9. Philip OakleyDec 15, 2013
  10. Philip OakleyDec 16, 2013
  11. Junio C HamanoDec 16, 2013
  12. Junio C HamanoDec 14, 2013
  13. Antoine PelisseDec 14, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.