Greetings all,
as some of you surely know, current state of LLVM on Solaris platform is far
from being ideal.
Recently here at Oracle we have started putting effort into actually
making LLVM/Clang on Solaris (both x86 and SPARC) a good citizen.
We have both intent and (finally) legal permissions to contribute into the trunk,
and we have already developed a set of - now small and hopefully clean 
- patches
that address main deficiencies:
    - makefiles tweaked to be functional in all compilation modes
      (say, for ninja build)
    - Clang's gcc toolchain detection fixed
      (especially to handle multiple gccs installed on a system vs. hardcoded paths)
    - TLS relocations handling for SPARC fixed
    - JIT relocations handling for SPARC implemented
After these changes we are able to bootstrap clang (which is completely
impossible with current trunk on SPARC/Solaris).
As well as successfully build/test serious apps like MySQL.
We would very much like to hit 5.0 release with these changes,
however with currently published schedule it is clear that we
will need your extra help and will to review/integrate our patches.
I'm thus asking for advice - how can we possibly make that 5.0 target without
dropping quality of reviews? Any volunteers to help specifically with these reviews?
Note, that we dont have commit rights yet...
Thanks!
Fedor Sergeev, Oracle compiler teamm
Hi, Fedor,
That's good news. As you've indicated, the best way to get the changes reviewed is to break them into small pieces with good regressions tests. These should be uploaded to our code-review site (https://reviews.llvm.org/, see http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface for more information). Please make sure the patch descriptions fully describe the changes being proposed, and take care to follow the instructions regarding generating full-context diffs and adding the correct mailing lists as subscribers for each review.
  -Hal
Hi, Fedor,
That's good news. As you've indicated, the best way to get the
changes reviewed is to break them into small pieces with good
regressions tests. These should be uploaded to our code-review site
(https://reviews.llvm.org/, see Code Reviews with Phabricator — LLVM 18.0.0git documentation
for more information). Please make sure the patch descriptions fully
describe the changes being proposed, and take care to follow the
instructions regarding generating full-context diffs and adding the
correct mailing lists as subscribers for each review.
Thanks. This is all well understood here.
Patches will be as small as possible, and we actually started the process
filing 3 code-reviews through the last month.
1 already integrated and 2 pending (D33868 and D34136).
My call for volunteers comes from the actual experience of trying to get attention
to these patches.
Not that I'm complaining... I'm just doing the math and see that 9 Aug is very close...
regards,
Fedor.
Hi, Fedor,
That's good news. As you've indicated, the best way to get the
changes reviewed is to break them into small pieces with good
regressions tests. These should be uploaded to our code-review site
(https://reviews.llvm.org/, see http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
for more information). Please make sure the patch descriptions fully
describe the changes being proposed, and take care to follow the
instructions regarding generating full-context diffs and adding the
correct mailing lists as subscribers for each review.
Thanks. This is all well understood here.
Patches will be as small as possible, and we actually started the process
filing 3 code-reviews through the last month.
1 already integrated and 2 pending (D33868 and D34136).
Feel free to "ping" them weekly.
-Hal