Skip site navigation (1)Skip section navigation (2)
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>