Edmund Grimley Evans: >> http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?p=8963#p8963 >> >> Do you have any suggestions on how to move forward? The easiest option is >> just to give the test two possible things to diff against, but this buries >> the issue and does not really solve it. > > That looks worrying. It might be a real bug. > > If I've understood correctly, you get different behaviour with and > without the patch on amd64. But the patch consists of a load of > independent changes. So, if we can't think of anything else, there's > the option here of doing a bisection search to find out which hunk of > the patch causes the difference. (Though it could be more complicated > I suppose: like whether an odd or even number of hunks are applied...) >
Not amd64 but arm64 - the Debian name for aarch64 / armv8. But yes to the other parts of what you said. Alright, thanks for the tips, I'll try the bisect when I get some time. Actually there was a paper posted to Hacker News yesterday: https://www.st.cs.uni-saarland.de/publications/files/zeller-esec-1999.pdf whose algorithm would be perfect for this sort of thing, unfortunately I don't think it was released as a piece of executable software :( > Is -1 cast to a pointer being used as a special value somewhere? That > value would not survive being packed and unpacked. > >> Another thing now: your robopatch results in the following patch: >> >> https://anonscm.debian.org/cgit/debian-science/packages/giac.git/tree/debian/patches/fix-48-bit-addr.patch?id=075cd498f2590ed067e73da827a5cb07b4d1aa5b >> >> As you can see, it makes some changes to src/cocoa.cc that are not guarded >> by #ifdef SMARTPTR64 conditions. Judging by your perl expression, I guess >> this should also be unpatched? > > I think that code in cocoa.cc is wrong either way: (1<<31) is an > overflow already, whatever you cast it to afterwards. It should > probably be (1LL<31), and then there's no need to convert it to > longlong or ulonglong, i.e.: gen p(int((1LL<<31)-1)) > I see right, according to the C/C++ standards you shouldn't perform operations that require more than 16 bits on these. But I think the existing results that we're getting probably wouldn't be affected since they are running on machines where ints do have >= 32 bits so it wouldn't be overflowing in practice in these cases. >> Similarly, src/ifactor.cc and the third hunk of src/vecteur.cc should >> probably be reverted just for "neatness" purposes, but I don't think this >> would have affected any of the results described. > > src/ifactor.cc looks like a false positive: the << is not a shift. So > revert that. > > Third hunk of vecteur.cc should make no difference either way. > > So I'd recommend trying to discover which part of that patch changes > the test result on amd64, and maybe it will then be possible to > understand why... > X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
