M2
M2 copied to clipboard
Macaulay2
latest llvm compile issues
@jkyang92 I might have accepted that pull request too soon (#2989). The part below is failing under llvm 17.0.5. I thought it worked under 17.0.4... But now I'm not sure about that.
Under cmake, I get the following error, when doing ninja in the build tree in a cmake build. (M2 builds fine now, which is good).
@mahrud Why are mathicgb unit tests being compiled when I do ninja (with no target name)?
[27/548] Building CXX object Macaulay2/e/mathicgb/CMakeFiles/mathicgb-unit-tests.dir/test/Range.cpp.o
FAILED: Macaulay2/e/mathicgb/CMakeFiles/mathicgb-unit-tests.dir/test/Range.cpp.o
/opt/homebrew/bin/ccache /opt/homebrew/opt/llvm/bin/clang++ -DNDEBUG -DOM_NDEBUG -DSING_NDEBUG -I/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathicgb -I/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/memtailor -I/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathic -isystem /opt/homebrew/include -isystem /Users/mike/src/M2-current-branches/M2-development/M2/BUILD/mike/builds.tmp/cmake-latestclang/usr-host/include -O2 -g -DNDEBUG -std=gnu++17 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -mmacosx-version-min=12.6 -march=native -Wuninitialized -g -I/Users/mike/src/M2-current-branches/M2-development/M2/BUILD/mike/builds.tmp/cmake-latestclang/usr-host/include -I/Users/mike/src/M2-current-branches/M2-development/M2/include -I/Users/mike/src/M2-current-branches/M2-development/M2/BUILD/mike/builds.tmp/cmake-latestclang/include -Wall -Wextra -Wfatal-errors -Wcast-qual -Wno-unused-parameter -Wno-attributes -Wno-unused-command-line-argument -MD -MT Macaulay2/e/mathicgb/CMakeFiles/mathicgb-unit-tests.dir/test/Range.cpp.o -MF Macaulay2/e/mathicgb/CMakeFiles/mathicgb-unit-tests.dir/test/Range.cpp.o.d -o Macaulay2/e/mathicgb/CMakeFiles/mathicgb-unit-tests.dir/test/Range.cpp.o -c /Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathicgb/test/Range.cpp
/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathicgb/test/Range.cpp:158:15: fatal error: no matching function for call to 'rangeToVector'
158 | auto val3 = rangeToVector(val3a,val3b);
| ^~~~~~~~~~~~~
/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathicgb/mathicgb/Range.hpp:256:6: note: candidate template ignored: substitution failure [with Iterator = Iterator]: no matching constructor for initialization of 'std::vector<typename std::decay<decltype(* begin)>::type>' (aka 'vector<std::pair<int &, int>>')
256 | auto rangeToVector(
| ^
257 | Iterator begin,
258 | Iterator end
259 | ) -> decltype(
260 | std::vector<typename std::decay<decltype(*begin)>::type>(begin, end)
| ~~~
/Users/mike/src/M2-current-branches/M2-development/M2/Macaulay2/e/mathicgb/mathicgb/Range.hpp:284:6: note: candidate function template not viable: requires single argument 'range', but 2 arguments were provided
284 | auto rangeToVector(
| ^
285 | RangeParam&& range
| ~~~~~~~~~~~~~~~~~~
1 error generated.
If you don't give it a target name it'll compile everything, including unit tests, so you can run them next.
This should be unrelated to #2989. It seems to be unhappy about the decltype because it can't find an appropriate constructor for std::vector. Also using llvm 16.0.6 on linux I can't reproduce this issue. Approximately, I think this is because the type of val3a or val3b is probably doing something unexpected.
Just reading the code in mathicgb, the code at lines 304 and 305 mathicgb/Range.hpp (not in test) seems wrong. In particular, the pointer and reference typedefs are more likely to be correct if we use typedef value_type *pointer, and typedef value_type &reference. The general case seems impossible to get right, in particular if the wrapped interator has a pointer (or reference) typedef that isn't an actual native pointer. This might also explain the comment in the test (that says the test fails if one uses strings rather than integers).
As of now I can't actually reproduce this so, @mikestillman could you try making the changes and seeing if it helps?
Yes, I'll work on fixing mathicgb as @jkyang92 suggests. I handled it by commenting out the testing of mathicgb in cmake... Not exactly a good solution!
Hmm, I thought I had a compile error just a few days ago with respect to tests in mathicgb, but cannot reproduce it currently on cmake build, so maybe we can close this.