Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No AVX ruby host-configs #3442

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from
Draft

No AVX ruby host-configs #3442

wants to merge 1 commit into from

Conversation

bmhan12
Copy link
Contributor

@bmhan12 bmhan12 commented Nov 14, 2024

This PR contains:

  • A spack build of TPLs, ruby gcc@12, with AVX disablement flags (-march=x86-64-v2 -mno-avx512f)
  • Another spack-build, same system and compiler, but without the AVX flags
  • There are 2 host-configs for each configuration, one for GEOS and one for LvArray (4 total).

In either case, not observing the valgrind error with the spack builds, that are currently visible in the current builds.

I assume the error is this one? :

$  valgrind --leak-check=yes ./tests/blt_gtest_smoke
...
...
...
=2650997== Your program just tried to execute an instruction that Valgrind
==2650997== did not recognise.  There are two possible reasons for this.
==2650997== 1. Your program has a bug and erroneously jumped to a non-code
==2650997==    location.  If you are running Memcheck and you just saw a
==2650997==    warning about a bad jump, it's probably your program's fault.
==2650997== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2650997==    i.e. it's Valgrind's fault.  If you think this is the case or
==2650997==    you are not sure, please let us know and we'll try to fix it.
==2650997== Either way, Valgrind will now raise a SIGILL signal which will
==2650997== probably kill your program.
...

@bmhan12 bmhan12 added the type: build system Build system issue label Nov 14, 2024
@bmhan12 bmhan12 self-assigned this Nov 14, 2024
@bmhan12
Copy link
Contributor Author

bmhan12 commented Nov 14, 2024

Output files running memcheck on geosx executable with and without suppression file:

With suppression file:

valgrind --leak-check=full --show-reachable=yes --suppressions=/usr/workspace/han12/GEOS/src/coreComponents/LvArray/scripts/valgrind.supp ./bin/geosx

memcheck_with_supression.txt


Without suppression file:

valgrind --leak-check=full --show-reachable=yes ./bin/geosx

memcheck_no_supress.txt

@rrsettgast
Copy link
Member

@bmhan12 Awesome. Looks like there are no access violations from valgrind in the examples I run. Kind of a relief, but then also disappointing that I am not presented with something to fix.

@bmhan12
Copy link
Contributor Author

bmhan12 commented Nov 14, 2024

@bmhan12 Awesome. Looks like there are no access violations from valgrind in the examples I run. Kind of a relief, but then also disappointing that I am not presented with something to fix.

I tried running testStackArray through memcheck, to see if anything related to #3424 would show up.
Nope, everything looks good there.

With suppression file:

valgrind --leak-check=full --show-reachable=yes --suppressions=/usr/workspace/han12/GEOS/src/coreComponents/LvArray/scripts/valgrind.supp ./tests/testStackArray

memcheck_stackarray_suppress.txt


Without suppression file:

valgrind --leak-check=full --show-reachable=yes ./tests/testStackArray

memcheck_stackarray_no_suppression.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: build system Build system issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants