Hi Samuel, I think the problem lies in the Makefile.
Because for different arch, certain assembly instructions may best exploit the potential of the hardware. As for the vectorize option, different kinds of CPU support different SIMD instructions like SSE/SSE2/AVX/AVX2/AVX-512. So there should be problem with -march=native -ftree-vectorize. Regards, Gengyu Rao On 12/5/2019 11:26 PM, Samuel Henrique wrote: Hello, We've always had problems with t50's new upstream forcing some CPU specific instructions, like hardcoding "march=native" in the Makefile. Usually the main signal of this type of problem is the non-reproducibility of the package, the diff being some assembly instructions. The problem is that we are seeing this happening now[0], and I believe we should make sure that this is not the case before releasing it on Buster. I tried taking a look but couldn't find anything, so I'd like to ask for the team's help, as I know we have people good at this kind of stuff. The main objective here is identify the source of the non-reproducibility on i386, in order to know if it's related to some cpu specific thing being changed at compilation time, which would consist of RC bug. Thanks, [0]https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/t50.html . -- Samuel Henrique <samueloph>
