dqrng 0.4.0 fails to build: error: no match for 'operator/'
#88
Comments
|
Hmm, it is weird. CRAN version 0.3.2 builds fine, but 0.3.2.1 from here 7853a3e fails already. However there seems to be no 0.3.2 here at all. |
|
Looks like the last non-CRAN version to build is 0.3.1.2, i.e. ad154c2 commit: 0.3.1.3, i.e. commit abdb3eb – is already broken: However whatever CRAN has as 0.3.2 builds with no issues. |
|
v0.3.2 is bfcf168. Due to an issue with Rcpp, v0.3.2 had to be directly based on v0.3.1 instead of the development versions v0.3.1.x. Can you tell me more about the environment, especiall0.3.1.3y the compiler, you are using? The code the build of 0.3.1.3 is complaining about has been in the package since the very beginning. Of course, it might be that it had never been compiled. My guess: Your compiler does not support 128 bit integers so that the implementation in in |
@rstub Thank you for responding! I am using gcc 13.2.0, but this is a 32-bit (Big-endian) arch, and apparently uint128 is not supported for 32-bit: https://stackoverflow.com/questions/16088282/is-there-a-128-bit-integer-in-gcc I could raise an issue with GCC upstream, if some further clarification is needed. But it looks like 32-bit arch may need to fall back to 64-bit integers. Would it be possible to have such a codepath for better compatibility? P. S. For the context, I am maintaining it in MacPorts, and it would be nice not to be forced to peg a package to an older version. We support ppc and i386, and there are people using arm and mips too, I believe. |
|
Thanks for confirming my guess. I probably should update PCG to get imneme/pcg-cpp@66478a9. Then I can test without compiler internal 128bit integers. Due to some UBSAN failures (c.f. #89) I will have to build a version 0.4.1 soon. I will try to provide a fix for this in there as well. BTW, how is the performance of |
|
@rstub Tests pass (for CRAN-sourced 0.3.2): Overall output of checks: |
Merged
|
@rstub The build from fd688fb works, though with some warnings: And this: There is a failure in tests now, though it may not be in fact related to It looks very similar to this bug in |
|
I am not sure where the UB should be or where the |
|
@rstub Sorry, been busy with other stuff, I rerun tests and respond here tomorrow. |
|
@rstub This is what I get, running tests from 6048c1b version: |
|
Thanks @barracuda156! I have been able to run some tests on an old i686 Laptop, which does show some of the issues you are seeing:
It does not show the invalid alignment / bus error, though. Can you install the package in a test environment and create a file // cloned_calls.cpp
// [[Rcpp::plugins(cpp11)]]
#include <Rcpp.h>
// [[Rcpp::depends(dqrng,BH)]]
#include <dqrng.h>
#include <dqrng_distribution.h>
// [[Rcpp::export]]
bool cloned_calls(int stream) {
dqrng::random_64bit_accessor engine{};
auto cloned_engine = engine.clone(stream);
Rcpp::NumericVector u1(10);
Rcpp::NumericVector u2(10);
engine.generate<dqrng::uniform_distribution>(u1);
cloned_engine->generate<dqrng::uniform_distribution>(u2);
return Rcpp::is_true(Rcpp::all(u1 == u2));
}
/***R
cloned_calls(stream = 0)
cloned_calls(stream = 1)
dqrng::dqRNGkind("PCG64")
cloned_calls(stream = 0)
cloned_calls(stream = 1)
*/Then call |
|
@rstub I get a segfault on that: |
|
Do you know how to get more information from that segfault using a debugger? You can start this in |
|
One more thing. Could you compile and run this C++ program that only uses PCG: #include <iostream>
#include <sstream>
#include <vector>
#include <pcg_random.hpp>
int main(void) {
pcg64 rng;
std::cout << rng << std::endl;
rng.set_stream(1234);
std::cout << rng << std::endl;
pcg_extras::pcg128_t number;
std::vector<pcg_extras::pcg128_t> state;
std::stringstream iss;
iss << rng;
using pcg_extras::operator>>;
while (iss >> number)
state.push_back(number);
// state[1] is the current stream
// PCG will do 2*stream + 1 to make sure stream is odd; need to revert that here
rng.set_stream(state[1]/pcg_extras::pcg128_t(2) + pcg_extras::pcg128_t(0ULL));
std::cout << rng << std::endl;
return 0;
}Do you get similar errors? |
|
Do I need some specific version? I do not know where this header is supposed to come from. (But since I build this manually and not in MacPorts, environment may not know about other R packages, unless those are explicitly specified.) |
|
Sorry for being unclear. This should be compiled w/o using R at all, i.e.
`g++ -I<path/to/include> -o dqrng_test2 dqrng_trst2.cpp`.
Sergey Fedorov ***@***.***> schrieb am Mo. 20. Mai 2024 um
12:06:
… Do I need some specific version?
36-244% Rscript -e "Rcpp::sourceCpp('test_dqrng2.cpp')"
using C++ compiler: ‘g++-mp-13 (MacPorts gcc13 13.2.0_4+stdlib_flag) 13.2.0’
using SDK: ‘NA’‘NA’‘NA’‘NA’‘NA’‘NA’
/opt/local/bin/g++-mp-13 -std=gnu++17 -I"/opt/local/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I"/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/Rcpp/include" -I"/Users/svacchanda/Desktop/_opt_PPCSnowLeopardPorts_lang_guile2/test" -isystem/opt/local/include/LegacySupport -I/opt/local/include -fPIC -pipe -Os -arch ppc -c test_dqrng2.cpp -o test_dqrng2.o
test_dqrng2.cpp:4:10: fatal error: pcg_random.hpp: No such file or directory
4 | #include <pcg_random.hpp>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make: *** [test_dqrng2.o] Error 1
Warning message:
In system2("xcrun", "--show-sdk-path", TRUE, TRUE) :
running command ''xcrun' --show-sdk-path 2>&1' had status 64
Error in Rcpp::sourceCpp("test_dqrng2.cpp") :
Error 1 occurred building shared library.
Execution halted
I do not know where this header is supposed to come from. (But since I
build this manually and not in MacPorts, environment may not know about
other R packages, unless those are explicitly specified.)
—
Reply to this email directly, view it on GitHub
<#88 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGUIIS2ZADMEE52GVRZ6XL3ZDHDJZAVCNFSM6AAAAABHZFYAZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGEYTSNBWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@barracuda156 Please let me know if you have questions concerning my above requests. I have time until next week before I have to fix the UBSAN error found by CRAN. I would like to get fixes for your use case in that release as well. |
|
@rstub I will deal with this by tomorrow (will try doing it today). Thank you! |
|
@rstub Is this of any help? |
|
It looks like as if the error is happening right away even before the problematic code. Could you try the following program which adds more output in the beginning? #include <iostream>
#include <sstream>
#include <vector>
#include <pcg_random.hpp>
int main(void) {
pcg64 rng;
std::cout << "RNG created" << std::endl;
std::cout << rng << std::endl;
rng.set_stream(1234);
std::cout << "stream set" << std::endl;
std::cout << rng << std::endl;
pcg_extras::pcg128_t number;
std::vector<pcg_extras::pcg128_t> state;
std::stringstream iss;
iss << rng;
using pcg_extras::operator>>;
while (iss >> number)
state.push_back(number);
// state[1] is the current stream
// PCG will do 2*stream + 1 to make sure stream is odd; need to revert that here
rng.set_stream(state[1]/pcg_extras::pcg128_t(2) + pcg_extras::pcg128_t(0ULL));
std::cout << rng << std::endl;
return 0;
} |
|
Also, if this is indeed already a problem with printing the RNG, you could try this with the headers from imneme/pcg-cpp#92. Thanks! |
|
For the updated program, but with existing headers from |
|
Thanks! So it is indeed already the printing of the RNG that is problematic. The latest version of PCG does have some fixes concerning printing. It would be great if you could test against that version. |
|
Did I understand correctly, that I can just replace those 3 headers borrowing new versions from https://github.com/imneme/pcg-cpp/tree/master/include and apply a patch from imneme/pcg-cpp#92 onto |
|
Thanks! You understood correctly. This means that even the most recent version of PCG does fail in your environment. I am not sure I will be able to fix this. It would be good to get an issue created in the PCG repo, even though that is pretty quiet right now. I can provide suitable code for this, but will need your help to create the actual error messages. Would you be interested in working on this? As for this package: I am considering disabling PCG completely or at least the problematic parts. Do you know if there is a good way to identify your platform at compile time? |
Yes, sure. This is not something I can fix myself, but I can test whatever needed.
If we can use macros inside C/C++ code, then this gonna work: This assumes the issue applies to ppc and ppc64, but only on macOS. (I have no way presently to test anything on ppc64 or on BSD, so we can guess here.) |
|
In #91 I am now excluding PCG completely on MacOS for PowerPC, but now I have to exclude several tests to run as well. Can you send me the output of |
Possible values for the triple will range from |
|
Can you give the version from #91 a try? Everything but the UB from |
|
I have applied three commits as patches on top of the master, and ran tests: |
|
Looks like the UB is serious enough to fail the tests. I have pushed some additional changes to #91. Can you test those, please? |
|
Everything passes now: Thank you! |
|
Excellent! I will send this as version 0.4.1 to CRAN. |
|
Hi @barracuda156 #include <iostream>
#include "pcg_random.hpp"
int main(void) {
pcg64 rng;
rng.seed(20240409);
rng.set_stream(90404202);
std::cout << rng << std::endl;
return 0;
}As example code. With upstream PCG, this should produce an error like With the patch from imneme/pcg-cpp#92 applied, this should compile but produce a segmentation fault upon execution. Do you want to submit the issue? Or do prefer providing me with the necessary output from you environment so that I can submit one? |
|
@barracuda156, Are you interested in bring this to the PCG developers together? |
|
@rstub Sure, let’s do it. What should I do from my end? |
|
@barracuda156 I think it would be best to supply error messages from a minimal example. Could you compile #include <iostream>
#include "pcg_random.hpp"
int main(void) {
pcg64 rng;
rng.seed(20240409);
rng.set_stream(90404202);
std::cout << rng << std::endl;
return 0;
}with upstream PCG as well as the patch from imneme/pcg-cpp#92 applied? With the upstream version, you should get |
|
Sorry for a delay, will do this tomorrow. |
|
|
First version as-is ( |
|
Thanks! I have now created imneme/pcg-cpp#93. Let's see how that goes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: