[Clang][CI] Extend clang version output #20520

KornevNikita · 2025-10-30T17:41:37Z

There is a customer request to make clang++ --version output more
informative. This patch adds a string like this to the output:
"Intel SYCL compiler X build based on:" - here goes regular clang output.
Where X is "development" by default.
"Nightly YYYY-MM-DD" for regular nightly builds.
"X.Y.Z Nightly YYYY-MM-DD" for nightly release builds.
"X.Y.Z release" for official releases.

This patch adds "Nightly build" string to clang version output. Previously it was like: clang version 22.0.0git (https://github.com/intel/llvm.git 2de7d37) Now it looks like: clang version 22.0.0git (https://github.com/intel/llvm.git 2de7d37 Nightly build) I'm preserving the repo path, but extending the revision. Anyways, we need to define both CLANG_VC_REPOSITORY and CLANG_VC_REVISION CMake variables to redefine the output, see: llvm/llvm/cmake/modules/GenerateVersionFromVCS.cmake Moreover, we need to define LLVM_VC_REPOSITORY & LLVM_VC_REVISION, because if it's not the same as CLANG_VC_* variables, there will be two sections of brackets after clang version, like: clang version 22.0.0git (https://github.com/intel/llvm.git 2de7d37) (https://github.com/intel/llvm.git 2de7d37 Nightly build) This is kind of hacky, but it allows as not to change the source code.

.github/workflows/sycl-linux-build.yml

sarnex · 2025-10-30T17:55:10Z

.github/workflows/sycl-nightly.yml

-      build_configure_extra_args: '--hip --cuda'
+      build_configure_extra_args: |
+        --hip --cuda \
+        -DLLVM_VC_REPOSITORY="${{ github.repositoryUrl }}" -DLLVM_VC_REVISION="${{ github.sha }} Nightly build" \


since we're only doing this for the nightly, is there some benefit we get to knowing if someone is using the nightly or not?

I'll also add the same thing for nightly release builds like x.y.z pre-release build and x.y.z release build for official releases, so this is needed to distinguish them.

bader · 2025-10-30T18:47:31Z

This patch adds "Nightly build" string to clang version output.

Why? How is the "nightly build" different from regular non-nightly build?

KornevNikita · 2025-10-31T10:16:35Z

This patch adds "Nightly build" string to clang version output.

Why? How is the "nightly build" different from regular non-nightly build?

What you mean by regular non-nightly build? There is a huge set of options on how to build the toolchain. Nightly builds are built in some specific way, tested properly enough and published. So there is a customer request to make the version info a bit more informative.

For more details see: #20520 This PR adds branch:hash to nightly builds on release branches. It also allows to specify a custom version manually in case of official release builds, e.g. "6.3.0 release build".

bader · 2025-10-31T19:13:31Z

What you mean by regular non-nightly build?

I mean builds done by other workflows (e.g. pre-commit, post-commit, etc.).

So there is a customer request to make the version info a bit more informative.

What is missing in the current version info? How does you change make it more informative?

Previous attempt: #20520 That one is kind of hacky, therefore proceeding with a more proper solution. There is a customer request to make clang version output more informative. This patch adds a string like this to the output: "Intel SYCL compiler X build based on:" - here goes regular clang output. Where X is "development" by default. "Nightly" for regular nightly builds. "X.Y.Z Nightly" for nightly release builds. "X.Y.Z release" for official releases.

KornevNikita · 2025-11-03T16:50:29Z

Closing in favor of #20536.
@bader could you please check the new PR.

bader · 2025-11-03T17:40:14Z

Closing in favor of #20536.
@bader could you please check the new PR.

@KornevNikita, why did you open another PR? Please, use one PR for all the discussions/review process.
I suggest you re-open this one and reply to my questions above. I don't any of my questions to be answered in #20536.

There is a customer request to make clang version output more informative. This patch adds a string like this to the output: "Intel SYCL compiler X build based on:" - here goes regular clang output. Where X is "development" by default. "Nightly" for regular nightly builds. "X.Y.Z Nightly" for nightly release builds. "X.Y.Z release" for official releases.

KornevNikita · 2025-11-04T10:31:39Z

@bader I've updated the PR, could you please check the description, as the approach was changed a bit.

What is missing in the current version info? How does you change make it more informative?

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here. Maybe @AlexeySachkov has some.

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

elizabethandrews · 2025-11-04T17:04:19Z

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

bader · 2025-11-04T17:56:14Z

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here.

@KornevNikita, I'm confused. I don't understand what exactly the problem you are trying to solve by adding "Nightly" string to the version reported by the driver.
Why commit SHA reported by the driver today is not enough? Do you have a reference to the requests from "some people"?

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

I agree. I would expect our compiler to emit the version similar to the upstream compiler.

mdtoguchi · 2025-11-04T17:57:25Z

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

There is additional release information emitted with the Intel compiler, but as I understand it the intel/llvm bits just emit the clang version.

AlexeySachkov · 2025-11-04T19:16:25Z

The build info is missing. Some people are using our nightly builds, so they need this info to distinguish builds, I guess. If you're still against this change, then we can drop it, as I have nothing to say more here.

@KornevNikita, I'm confused. I don't understand what exactly the problem you are trying to solve by adding "Nightly" string to the version reported by the driver. Why commit SHA reported by the driver today is not enough? Do you have a reference to the requests from "some people"?

CMPLRLLVM-68631 is the internal tracker number. Hash does not exactly describe where a build is coming from: for example a local build and a build downloaded from nightly can have the same hash, but they could be built with different flags or options (like support for device image compression, or SYCL JIT). Another benefit is that we can instantly compare two nightly builds to understand which one is newer/older, without having to look up a commit hash in the repo. However, I do not see this part being implemented despite it being mentioned in the description - without it just "Nightly" string alone does not bring much benefit

KornevNikita · 2025-11-05T09:45:21Z

Anyways, we still need this change to mark our official releases, as of now clang says nothing about it. Do you have any concerns regarding this point?

@mdtoguchi can you confirm this? I thought we emitted release information ?

There is additional release information emitted with the Intel compiler, but as I understand it the intel/llvm bits just emit the clang version.

Yes, there is such mechanism in the internal compiler version, but intel/llvm clang currently reports the same info as llvm-project clang.

without it just "Nightly" string alone does not bring much benefit

Added date.

bader · 2025-11-05T17:50:46Z

I want @AlexeySachkov to decide the readiness of this change as he is in context of the customer request mentioned in the description. @KornevNikita, please, get approval from @AlexeySachkov before merging this PR.

elizabethandrews

Can you add tests with mock values?

KornevNikita · 2025-11-06T17:38:45Z

@elizabethandrews

Can you add tests with mock values?

Hmm, it's kind of tricky since we need to re-build clang to get the updated output, not sure how to implement it. Do you have any thoughts? At least we could add a test to Nightly to check if the output is right.

elizabethandrews · 2025-11-06T20:28:26Z

@elizabethandrews

Can you add tests with mock values?

Hmm, it's kind of tricky since we need to re-build clang to get the updated output, not sure how to implement it. Do you have any thoughts? At least we could add a test to Nightly to check if the output is right.

Can you manually define SYCL_BUILD_INFO for a FE/driver test?

KornevNikita · 2025-11-07T10:27:53Z

@elizabethandrews

Can you add tests with mock values?

Hmm, it's kind of tricky since we need to re-build clang to get the updated output, not sure how to implement it. Do you have any thoughts? At least we could add a test to Nightly to check if the output is right.

Can you manually define SYCL_BUILD_INFO for a FE/driver test?

I'm not sure what you mean, could you please elaborate a bit? I believe this macro is backed into clang during compilation, so the only way to change it is to re-build the application, isn't it?

AlexeySachkov

We will also need a similar PR for the release branch, correct?

Overall, this looks good to me, but we must repeat the same on the release branch as well

AlexeySachkov · 2025-11-10T15:26:51Z

.github/workflows/sycl-linux-build.yml

      id: build
      # Emulate default value for manual dispatch as we've run out of available arguments.
      run: cmake --build $GITHUB_WORKSPACE/build --target ${{ inputs.build_target || 'sycl-toolchain' }}
+    - run: $GITHUB_WORKSPACE/build/bin/clang++ --version


Is this for debugging purposes?

Yep, but I'd like to keep this just in case.

AlexeySachkov · 2025-11-10T15:29:21Z

.github/workflows/sycl-nightly.yml

      toolchain_decompress_command: ${{ needs.ubuntu2404_oneapi_build.outputs.toolchain_decompress_command }}

  build-win:
+    needs: get_date


A similar functionality is used in the tagging process below:

llvm/.github/workflows/sycl-nightly.yml

Lines 369 to 377 in 698f908

- name: Compute tag

id: tag

run: |

if [ "${{ github.event_name == 'schedule' }}" == "true" ]; then

echo "TAG=$(date +'%Y-%m-%d')" >> "$GITHUB_OUTPUT"

else

# TODO: Use date of the commit?

echo "TAG=$(date +'%Y-%m-%d')-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"

fi

I suggest that we unify all places within this workflow file which rely on a date - I think that it is important that the date we put into nightly builds is aligned with tags that we push.

Updated here 479b59d

elizabethandrews · 2025-11-10T15:59:59Z

@elizabethandrews

Can you add tests with mock values?

Hmm, it's kind of tricky since we need to re-build clang to get the updated output, not sure how to implement it. Do you have any thoughts? At least we could add a test to Nightly to check if the output is right.

Can you manually define SYCL_BUILD_INFO for a FE/driver test?

I'm not sure what you mean, could you please elaborate a bit? I believe this macro is backed into clang during compilation, so the only way to change it is to re-build the application, isn't it?

I was wondering if defining the macro manually with some mock value on the RUN line would be enough to get a test. Having said that though, I looked at some previous commits in llvm.org changing version information and I don't see tests added, so I am not sure if it is required. If the driver team approves this, then it is fine by me as well.

KornevNikita · 2025-11-10T16:54:25Z

@elizabethandrews thanks for the clarification.

@intel/dpcpp-clang-driver-reviewers @intel/dpcpp-cfe-reviewers @intel/dpcpp-devops-reviewers could you please take a look?

sarnex

yaml lgtm

mdtoguchi · 2025-11-10T17:09:45Z

clang/lib/Driver/Driver.cpp

 }

 void Driver::PrintVersion(const Compilation &C, raw_ostream &OS) const {
+  OS << "Intel SYCL compiler " << getSYCLBuildInfo() << " build based on:\n";


This information would only be output via Driver invocation and other usages of getClangFullVersion() would just emit the clang version. Is there any reason to provide a more general version output as opposed to Driver only?

Yep, initially I tried to inline this into the getClangFullVersion() function. But, it causes many tests (~50) to fail, so some tweaking is required. On the other hand, the request was to just have this note in clang++ --version. So I decided to avoid additional test changes, as they seem excessive.

Thanks for the info - Given that please add a --version test to verify the output is as expected to the Driver LIT tests.

KornevNikita requested a review from a team as a code owner October 30, 2025 17:41

github-advanced-security bot found potential problems Oct 30, 2025

View reviewed changes

.github/workflows/sycl-linux-build.yml Outdated Show resolved Hide resolved

KornevNikita temporarily deployed to WindowsCILock October 30, 2025 17:41 — with GitHub Actions Inactive

sarnex reviewed Oct 30, 2025

View reviewed changes

KornevNikita had a problem deploying to WindowsCILock October 30, 2025 18:02 — with GitHub Actions Failure

KornevNikita temporarily deployed to WindowsCILock October 30, 2025 18:02 — with GitHub Actions Inactive

KornevNikita temporarily deployed to WindowsCILock October 30, 2025 18:08 — with GitHub Actions Inactive

KornevNikita mentioned this pull request Oct 31, 2025

[CI][sycl-rel-6_3] Update clang version output #20523

Closed

KornevNikita mentioned this pull request Nov 3, 2025

[Clang][CI] Extend clang version output #20536

Closed

KornevNikita closed this Nov 3, 2025

KornevNikita reopened this Nov 4, 2025

KornevNikita had a problem deploying to WindowsCILock November 4, 2025 10:06 — with GitHub Actions Error

KornevNikita requested review from a team as code owners November 4, 2025 10:12

KornevNikita changed the title ~~[SYCL][CI] Improve clang++ version output~~ [Clang][CI] Extend clang version output Nov 4, 2025

KornevNikita had a problem deploying to WindowsCILock November 4, 2025 10:13 — with GitHub Actions Failure

KornevNikita temporarily deployed to WindowsCILock November 4, 2025 10:13 — with GitHub Actions Inactive

KornevNikita temporarily deployed to WindowsCILock November 4, 2025 10:47 — with GitHub Actions Inactive

fix cmake & add date

698f908

KornevNikita requested a review from a team as a code owner November 5, 2025 12:20

KornevNikita temporarily deployed to WindowsCILock November 5, 2025 12:20 — with GitHub Actions Inactive

KornevNikita temporarily deployed to WindowsCILock November 5, 2025 12:46 — with GitHub Actions Inactive

KornevNikita had a problem deploying to WindowsCILock November 5, 2025 13:03 — with GitHub Actions Failure

KornevNikita temporarily deployed to WindowsCILock November 5, 2025 13:03 — with GitHub Actions Inactive

bader requested a review from AlexeySachkov November 5, 2025 17:37

elizabethandrews reviewed Nov 6, 2025

View reviewed changes

AlexeySachkov approved these changes Nov 10, 2025

View reviewed changes

use same date across workflow

479b59d

KornevNikita had a problem deploying to WindowsCILock November 10, 2025 16:39 — with GitHub Actions Failure

KornevNikita temporarily deployed to WindowsCILock November 10, 2025 16:39 — with GitHub Actions Inactive

sarnex approved these changes Nov 10, 2025

View reviewed changes

KornevNikita had a problem deploying to WindowsCILock November 10, 2025 17:08 — with GitHub Actions Failure

mdtoguchi reviewed Nov 10, 2025

View reviewed changes

KornevNikita temporarily deployed to WindowsCILock November 10, 2025 17:21 — with GitHub Actions Inactive

	- name: Compute tag
	id: tag
	run: \|
	if [ "${{ github.event_name == 'schedule' }}" == "true" ]; then
	echo "TAG=$(date +'%Y-%m-%d')" >> "$GITHUB_OUTPUT"
	else
	# TODO: Use date of the commit?
	echo "TAG=$(date +'%Y-%m-%d')-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
	fi

[Clang][CI] Extend clang version output #20520

Are you sure you want to change the base?

[Clang][CI] Extend clang version output #20520

Uh oh!

Conversation

KornevNikita commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bader commented Oct 30, 2025

Uh oh!

KornevNikita commented Oct 31, 2025

Uh oh!

bader commented Oct 31, 2025

Uh oh!

KornevNikita commented Nov 3, 2025

Uh oh!

bader commented Nov 3, 2025

Uh oh!

KornevNikita commented Nov 4, 2025

Uh oh!

elizabethandrews commented Nov 4, 2025

Uh oh!

bader commented Nov 4, 2025

Uh oh!

mdtoguchi commented Nov 4, 2025 • edited by bader Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexeySachkov commented Nov 4, 2025

Uh oh!

KornevNikita commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bader commented Nov 5, 2025

Uh oh!

elizabethandrews left a comment

Choose a reason for hiding this comment

Uh oh!

KornevNikita commented Nov 6, 2025

Uh oh!

elizabethandrews commented Nov 6, 2025

Uh oh!

KornevNikita commented Nov 7, 2025

Uh oh!

AlexeySachkov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elizabethandrews commented Nov 10, 2025

Uh oh!

KornevNikita commented Nov 10, 2025

Uh oh!

sarnex left a comment

Choose a reason for hiding this comment

Uh oh!

mdtoguchi Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

KornevNikita commented Oct 30, 2025 •

edited

Loading

mdtoguchi commented Nov 4, 2025 •

edited by bader

Loading

KornevNikita commented Nov 5, 2025 •

edited

Loading

mdtoguchi Nov 10, 2025 •

edited

Loading