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
Estimator unit test fails on M1 Mac #4287
Comments
Do the tests pass with a non-complex build? |
No, it fails regardless of real/complex |
Also, I tried to compile with the address sanitizer support, but it seems that homebrew gnu compilers don't come with the libraries for the M1, whereas for intel Macs the libraries are there. |
With the release of command line tools 4.1 I was able to independently reproduce this. |
This issue remains with gcc-12 on my mac. It is an issue of gcc on mac I believe. |
Does macports or brew installed clang have any issues? It would be good to have a recommendable route and to update the build recipe in the manual. |
I only tried brew. The issue with clang was, I failed to find a working C++ standard library advanced enough for qmcpack needs. |
So to bring me into the loop here, is this still just an M1 phenomenon? |
The ARM-based Orange PI reporting at https://cdash.qmcpack.org/CDash/viewTest.php?onlyfailed&buildid=396302 shows only numerical "differences"/failures in a deterministic optimizer test. No x86 builds are failing. => only issues on M1 so far. Has anyone already tried the spack route instead of macports, brew? |
Reproduced with macports gcc 12.2.0 |
I just hit this problem using gcc13 installed via homebrew on an M1 laptop running OSX Monterrey 12.7. Clang seems to still be problematic for the reasons Ye mentioned earlier. |
Tried reinvestigating this just now on an m1 with Sonoma 14.1 . With #4815 I was finally able to build with AppleClang (!) and this test passed. Builds with gcc13 from macports resulting in a failing estimator unit test (only), but I notice they also configured with OpenBLAS while the AppleClang one picked up the preferred Accelerate framework. There might be other potentially significant differences. fftw-3, hdf5, boost were from macports. Note that the mpich and openmpi ports have issues so we aren't yet at a clean and easy build solution on Apple where everything "just works" as expected. |
Not an Accelerate/OpenBLAS issue. Builds differing only by appleclang/gcc-13 fail only for the gcc-13 case. |
Playing around with this I found that the bus error results from either of the CHECK_THROWS_AS tests in the InputSection::init TEST_CASE in test_InputSection.cpp. With them both commented, all the tests pass with gcc13.2 from macports.
|
As far as I can tell gcc 13 does not officially support apple M1 at all. Looking at the homebrew formula its pulling in a unmerged branch from a well know but not official repo. I don't see any reason why we should support it or even look into any further. Use a compiler where support for M1 has actually been merged. I would suggest we only officially support mainline llvm on osx. |
Describe the bug
develop branch seems to have a bug, at least on my mac. I haven't been able to reproduce it anywhere else. Looks like a BUS error on unit_test_estimator
(note also, if you want to be able to even compile on the M1 right now with homebrew g++, you have to change your CLT from v14. There was a bug introduced with CLT v14 that seems to have a problem linking. The current solution is to download a previous CLT or use the 14.1 beta CLT. Any of those can be downloaded from apple developer)
To Reproduce
git checkout develop
build_dir=build_gcc
mkdir -p $build_dir
cd $build_dir
CC=gcc-12
CXX=g++-12
cmake -D QMC_MPI=0
-D CMAKE_C_COMPILER=$CC
-D CMAKE_CXX_COMPILER=$CXX
-D QMC_COMPLEX=1
..
make -j 8
ctest -R unit_estimators
Expected behavior
test shouldn't fail
System:
Additional context
I talked through this with Ye at the All-hands meeting, and the cause is still unclear to us.
When I recompile with -g, lldb gives the backtrace below
The issue seems to be in InputSection::setFromValue. It is failing on the "count" name being passed in as RealType(15.)
Not really sure why it is failing but passing elsewhere. @ye-luo told me to ping @PDoakORNL to see if he had any ideas
The text was updated successfully, but these errors were encountered: