Date: Thu, 04 Jun 2020 18:15:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores Message-ID: <bug-246630-227-pi1M8fFdnT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246630-227@https.bugs.freebsd.org/bugzilla/> References: <bug-246630-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246630 --- Comment #30 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Fabian Keil from comment #29) That's very strange. I could fairly easily reproduce the different printf.o output by building either with "make -j2", or with "make" on the same machi= ne.=20 Since "make -j" appears to mess around with ttys and stderr, it could expla= in the slightly different memory contents of the program at startup. In any ca= se, removing the integrated cc1 stage always resulted in the same printf.o outp= ut. Are you saying you ran the same build on different machines? Are you 100% s= ure that all the includes pulled into printf.c were exactly the same? Is there = any way you can do a sha256sum of the .i files? > Maybe there's a relevant difference between the clang 10.0.0 in stable/11= and the more recent one in HEAD. I don't think so, head has 10.0.1-rc1, but it showed precisely the effects I mentioned before. Disabling integrated cc1 fixed it for me. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246630-227-pi1M8fFdnT>