Skip to content

Unload the llvm module after loading the other dependencies for wb testing#27601

Merged
lydia-duncan merged 1 commit intochapel-lang:mainfrom
lydia-duncan:fixWhiteboxes
Aug 5, 2025
Merged

Unload the llvm module after loading the other dependencies for wb testing#27601
lydia-duncan merged 1 commit intochapel-lang:mainfrom
lydia-duncan:fixWhiteboxes

Conversation

@lydia-duncan
Copy link
Member

I may need to make a special dependencies script just for our whiteboxes, but at a glance the only thing we didn't want was LLVM, since it was confusing our CC setting, so try just unloading it.

…sting

I may need to make a special dependencies script just for our whiteboxes, but
at a glance the only thing we didn't want was LLVM, since it was confusing our
CC setting, so try just unloading it.

----
Signed-off-by: Lydia Duncan <lydia-duncan@users.noreply.github.com>
Copy link
Member

@jabraham17 jabraham17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems suspect to me, can you elaborate on what went wrong?

@lydia-duncan
Copy link
Member Author

Sure! The load dependencies script grabs LLVM along with everything else, but this seems to also result in LLVM being used for CC, which the whitebox configurations depend on to determine their TARGET setting. The whitebox configurations want to cover gnu, cray and intel, not LLVM

@lydia-duncan
Copy link
Member Author

At least, I think that's what is going on. I do believe it did not have LLVM in the environment before loading the dependencies (since it wasn't grabbing anything at all), and so running without LLVM in the environment should not hurt the configuration

@jabraham17
Copy link
Member

jabraham17 commented Aug 5, 2025

Ok this is concerning to me then. CHPL_TARGET_COMPILER is being explicitly set, and looking at the job output it seems like thats the case. LLVM being present should not break our builds

It does look like the clang from spack is being picked up by CHPL_HOST_COMPILER, perhaps that should be explicitly set to gnu?

@jabraham17
Copy link
Member

Yeah it looks like CHPL_LLVM=none is explicitly being set, so I suspect the problem is with CHPL_HOST_COMPILER.

I would suggest explicitly setting CHPL_HOST_COMPILER=gnu if chpl_host_value is not set. That seems like the more principled fix/what we expect a user to do, rather than just unloading LLVM

@lydia-duncan
Copy link
Member Author

It looks like that is supposed to get set to either cray-prgenv-${COMPILER} or ${COMPILER}, but it varies depending on what we're compiling for in the whitebox testing. I'm not seeing ${COMPILER} get set, so it probably happens on the module load, but I could be missing it somewhere

@jabraham17
Copy link
Member

My read of previous logs and the script is that CHPL_HOST_COMPILER has been gnu for TARGET, and set to the same as the target compiler for HOST-TARGET

Copy link
Member

@jabraham17 jabraham17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lydia and I discussed this offline. While I am still not sure this is the best/most principled solution, our XC testing is kept alive as a best effort (since XC is EOL) so this is fine to keep it afloat

@lydia-duncan lydia-duncan merged commit f8771d2 into chapel-lang:main Aug 5, 2025
10 checks passed
@lydia-duncan lydia-duncan deleted the fixWhiteboxes branch August 5, 2025 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants