Test suite compilation failing on Mac

[kiranns]

My configuration:
MacOS Mojave 10.14.6Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Errors I am seeing:
template<typename...T>
^
/Users/kiran/libmorton/libmorton/test/libmorton_test.h:98:107: error: expected expression
return control_encode_impl<sizeof...(fields)>(std::numeric_limits<uint64_t>::digits / sizeof...(fields), { fields... });
^
/Users/kiran/libmorton/libmorton/test/libmorton_test.h:102:118: error: a space is required between consecutive right angle brackets
(use '> >')
void control_decode_impl(uint64_t encoding, std::size_t bitCount, const std::valarray<std::reference_wrapper<uint64_t>>& fields) {

[Forceflow]

Hmm ... weird.
I did recently drop C++11 requirement for the headers themselves, but the libmorton_test.h (part of the test suite, not the libmorton headers themselves) you're referring to still uses variadic templates, which are a C++11 feature

Does the clang version your using support that?

[kiranns]

I don't think it supports it. I could be mistaken, but isnt that the compilation error?

…

On Thu, Jun 4, 2020, 3:18 PM Jeroen Baert ***@***.***> wrote: Hmm ... weird. I *did* recently drop C++11 requirement for the headers themselves, but the libmorton_test.h (part of the test suite, not the libmorton headers themselves) you're referring to still uses variadic templates, which are a C++11 feature Does the clang version your using support that? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETRWLWT6MBE6ENKCBTGOGDRVAMRZANCNFSM4NOGFLIQ> .

[kiranns]

Hi Joroen, I have another question. I would like to encode a voxel with each dimension being a uint64. Does your current library support that? Thanks Kiran

…

On Thu, Jun 4, 2020, 3:18 PM Jeroen Baert ***@***.***> wrote: Hmm ... weird. I *did* recently drop C++11 requirement for the headers themselves, but the libmorton_test.h (part of the test suite, not the libmorton headers themselves) you're referring to still uses variadic templates, which are a C++11 feature Does the clang version your using support that? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETRWLWT6MBE6ENKCBTGOGDRVAMRZANCNFSM4NOGFLIQ> .

[Forceflow]

Well, if each of your coordinates can be 64 bits (and you sure all of those bits are used), your morton number has to be 64*3 bits = 192 bits, so you'd need some kind of 256-bit type to store that. You can probably derive methods to do that based on this library.

You sure you're not dealing with 16 / 32 bit coordinates stored in a uint64?

[kiranns]

I am sure. I would like to store the encoded number in an array of 3 uint64s.

…

On Thu, Jun 4, 2020, 4:00 PM Jeroen Baert ***@***.***> wrote: Well, if each of your coordinates can be 64 bits (and you sure all of those bits are used), your morton number has to be 64*3 bits = 192 bits, so you'd need some kind of 256-bit type to store that. You sure you're not dealing with 16 / 32 bit coordinates stored in a uint64? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETRWLSUKA5IBQ4ETGYHMJLRVARSLANCNFSM4NOGFLIQ> .

[Forceflow]

Well, have a look at the pre-shifted LUT method in morton3D.h

// ENCODE 3D Morton code : Pre-Shifted LookUpTable (sLUT)
	template<typename morton, typename coord>
	inline morton m3D_e_sLUT(const coord x, const coord y, const coord z) {
		morton answer = 0;
		for (unsigned int i = sizeof(coord); i > 0; --i) {
			unsigned int shift = (i - 1) * 8;
			answer =
				answer << 24 |
				(Morton3D_encode_z_256[(z >> shift) & EIGHTBITMASK] |
					Morton3D_encode_y_256[(y >> shift) & EIGHTBITMASK] |
					Morton3D_encode_x_256[(x >> shift) & EIGHTBITMASK]);
		}
		return answer;
	}

You can adapt this method to work with 64-bit coordinates as well, and have some logic to writeout the result to three seperate uint64's. I see it's already using sizeof(coord) in its internal logic, so that's taken care of.

And to answer your original question: if you really want to compile the test suite (which, again: is not required to use the library!), you'll have to resort to a compiler which supports C++11 / variadic templates.

[Kristine1975]

Hmm ... weird.
I did recently drop C++11 requirement for the headers themselves, but the libmorton_test.h (part of the test suite, not the libmorton headers themselves) you're referring to still uses variadic templates, which are a C++11 feature

Does the clang version your using support that?

It does (Apple's clang 10.0.1 equals official clang 7.0.0), but it's not turned on by default. Adding -std=c++11 to CFLAGS in the makefile fixes it:

CFLAGS=-O3 -m64 -std=c++11 -I ../libmorton/include/

However this results in further compile errors because apparently Apple defines uint_fast16_t differently: it's not unsigned int but unsigned short:

libmorton_test.cpp:121:66: note: in instantiation of function template specialization 'libmorton::m3D_e_sLUT_ET<unsigned int, unsigned short>'
      requested here
        f3D_32_encode.push_back(encode_3D_32_wrapper("LUT Shifted ET", &m3D_e_sLUT_ET<uint_fast32_t, uint_fast16_t>));
                                                                        ^
./../libmorton/include/morton3D.h:67:16: note: candidate function template not viable: no known conversion from 'const uint_fast32_t [256]' to
      'const unsigned short *' for 2nd argument
        inline morton compute3D_ET_LUT_encode(const coord c, const coord *LUT) {

Morton3D_encode_x_256 is an array of uint_fast32_t and passed to compute3D_ET_LUT_encode as its second argument. According to the explicitly specified template arguments this second argument must in this case be a pointer to uint_fast16_t, not an array/pointer to uint_fast32_t. On platforms where both uint_fast16_t and uint_fast32_t are identical (most likely unsigned int) this compiles just fine. If they are different (as on macOS), you get @kiranns compile error.

[Forceflow]

Does only the test suite fail to compile, or are the header files not usable too?

[Kristine1975]

The following tests fail to compile. Once I commented them out, the remaining tests compiled successfully:

libmorton/test/libmorton_test.cpp

Line 121 in 7a45306

f3D_32_encode.push_back(encode_3D_32_wrapper("LUT Shifted ET", &m3D_e_sLUT_ET<uint_fast32_t, uint_fast16_t>));

libmorton/test/libmorton_test.cpp

Line 123 in 7a45306

f3D_32_encode.push_back(encode_3D_32_wrapper("LUT ET", &m3D_e_LUT_ET<uint_fast32_t, uint_fast16_t>));

libmorton/test/libmorton_test.cpp

Line 158 in 7a45306

f3D_32_encode.push_back(encode_3D_32_wrapper("AVX512 instruction set", &m3D_e_BITALG<uint_fast32_t, uint_fast16_t>));

libmorton/test/libmorton_test.cpp

Line 160 in 7a45306

f3D_32_decode.push_back(decode_3D_32_wrapper("AVX512 Instruction set", &m3D_d_BITALG<uint_fast32_t, uint_fast16_t>));

libmorton/test/libmorton_test.cpp

Line 164 in 7a45306

f2D_64_encode.push_back(encode_2D_64_wrapper("LUT Shifted ET", &m2D_e_sLUT_ET<uint_fast64_t, uint_fast32_t>));

libmorton/test/libmorton_test.cpp

Line 166 in 7a45306

f2D_64_encode.push_back(encode_2D_64_wrapper("LUT ET", &m2D_e_LUT_ET<uint_fast64_t, uint_fast32_t>));

[davidwwalker611]

I'm still getting this same problem making libmorton_test on my new MacBook using clang 14. Has the bug been fixed?

[Forceflow]

Can you post the full compile output?

[davidwwalker611]

report.txt

Here is the compile output