[cfe-dev] moving the clang-omp merge along

[Jack Howarth]

Philip,
     Also, it would be quite unfortunate if the previous partial merge of
clang-omp, which I assume was done to make the -fopenmp/-lgomp support in
clang trunk more usable, in the end became a major impediment towards
getting the clang-omp changes into clang trunk in time for 3.5's release.
             Jack


On Wed, May 28, 2014 at 9:21 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

> Philip,
>     From observing many merges in FSF gcc over the years, it is crazy to
> take a new branch, selectively pull in small sections and then take long
> breaks where the two start to rapidly fork. If a branch is to be merged,
> the process should at least be scheduled such that the process will take
> place over a known period of time so attempts can be made to keep the two
> in sync or at least keep track of where the two have begun to diverge. At
> the moment, there are quite a few files introduced from clang-omp that are
> no longer in sync and the svn web browser access doesn't seem to allow you
> to easily view the commit history on individual files to see if they have
> been changed since the original commits.
>              Jack
>
>
> On Wed, May 28, 2014 at 8:25 PM, Philip Reames <listmail at philipreames.com>wrote:
>
>>  I would strongly recommend that you get your current branch in sync with
>> clang-TOT as a first step.  Once this done, you should separate individual
>> patches and submit them for review.  Based on previous history, the
>> community is unlikely to accept a single massive change set.
>>
>> p.s. The tone of your last sentence is less than ideal.  These are the
>> folks actually working on getting the work you are interested merged into
>> upstream.  You should thank them, not critique them.  (I'm not one of them,
>> btw.)
>>
>> Philip
>>
>>
>> On 05/28/2014 03:19 PM, Jack Howarth wrote:
>>
>>      Andrey Bokhanko expressed interest in getting the clang-omp
>> merge done in time for the 3.5 release but wants guidance on the process. I
>> suggested starting with the creation a new clang-omp branch upstream
>> rebased on clang trunk  for generation of merge patch. Unfortunately
>> merging the  current changes from the clang-omp (based on clang 3.4) to a
>> clang-omp (based on clang trunk)  looks very difficult as selective patches
>> have been committed into clang trunk from clang-omp and don't appear to
>> have been kept synchronized with the current changes from upstream. Does
>> anyone know if these new files from previous commits out of clang-omp
>> contain any local changes which haven't been back ported to clang-omp? It
>> would seem that postponing this merge will just make the process harder as
>> time goes on if selective merges from clang-omp into clang trunk continue
>> in the interim. Hopefully the folks who did the original selective commits
>> would help detangle this mess.
>>            Jack
>>
>>
>> _______________________________________________
>> cfe-dev mailing listcfe-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140528/a5d8acdb/attachment.html>