Is the merge of the clang-omp changes being abandoned for the 3.5 release or will these additional changes to trunk also be allowed into the clang 3.5 branch? If official clang 3.5 release is left with only a partial merge of these changes, it would seem to require upstream to pause and rebase their clang-omp tree on clang 3.5 instead of the current clang 3.4 (to allow for a stable release of clang-omp to be available based on clang 3.5).
Jack
Jack,
Please go ahead and merge those changes into the 3.5 release. There’s still time before we close the branches to non-bug fix changes.
-bw
Jack,
Please go ahead and merge those changes into the 3.5 release.
They aren't landed yet on trunk, as far as I understand.
There’s still time before we close the branches to non-bug fix changes.
-bw
> Is the merge of the clang-omp changes being abandoned for the 3.5
release or will these additional changes to trunk also be allowed into the
clang 3.5 branch? If official clang 3.5 release is left with only a partial
merge of these changes, it would seem to require upstream to pause and
rebase their clang-omp tree on clang 3.5 instead of the current clang 3.4
(to allow for a stable release of clang-omp to be available based on clang
3.5).
This is probably correct, yes.
Nico,
A simple review of cfe-commits mailing list archive for the past couple of months shows that Alexey Bataev has been regularly committing sections of the clang-omp merge so it really isn’t true to say that nothing has landed in trunk yet. It is unfortunate that the clang-omp changes were never submitted as a complete series of patches on the mailing list so only the clang-omp developers have a good sense of what remains to be committed from their tree.
Jack
Nico,
A simple review of cfe-commits mailing list archive for the past
couple of months shows that Alexey Bataev has been regularly committing
sections of the clang-omp merge so it really isn't true to say that nothing
has landed in trunk yet.
Oh sure, anything that was committed by yesterday is part of 3.5. I think
Bill understood your question as "We landed this bit of code very recently
that we'd like to merge", but from what I understand it's more "there's a
largeish chunk of code in some upstream repo". I don't think Bill meant to
say that all that unmerged code should just be merged to 3.5 
Nico,
So basically branching for 3.5 completely terminates the process of merging the clang-omp changes. It is unfortunate that llvm seems to have a rather disorganized process for merging trees like clang-omp. It would have been nice to see some level of coordination to get that committed cleanly rather than a piecemeal fashion over multiple llvm releases.
Jack
Jack,
The standard release process is that release is time-based, not
feature based (with known timeframe in advance). So, OpenMP patches
have good chances to go in 3.6 (if they will be committed there,
surely) and there is nothing bad here.
The rush of getting code into the release branch IMO seriously affects
the quality of the code. So, it's much better to have "OMP bits are
not yet included fully" instead of "we merged all the stuff in a
hurry, stuff should work, but it was neither tested, nor reviewed". In
case of OpenMP there are many important questions which need to be
answered, e.g. the runtime library.