Hi Camm, I can still reproduce the build failure. Do you want access to an Amazon AWS node where you could see it yourself? Do you do IRC, can you ping me? (those instances are quite expensive, I'd rather not keep them running for days)
Lucas On 19/11/16 at 10:43 -0500, Camm Maguire wrote: > severity 844148 normal > tags 844148 unreproducible > thanks > > Greetings, and thanks for your report! > > This is not an issue with GCL or acl2. > > From upstream: > ============================================================================= > Hi, Camm -- > > Yes, I think that's right. The comments in > books/system/hons-check/memoize-tests.lisp about "lock" pertain to a > variant of ACL2 called ACL2(p) (which was formerly called ACL2(hp)), > and ACL2(p) is only supported for CCL and perhaps SBCL and LispWorks, > since it assumes native threads. In source file memoize-raw.lisp, > macros with-global-memoize-lock and with-global-memoize-lock-static > only mess with locks when #+(or ccl sb-thread lispworks). > > -- Matt > > Cc: c...@maguirefamily.org > > From: Camm Maguire <c...@paradis.debian.org> > > Date: Wed, 16 Nov 2016 16:29:55 +0000 > > > > Greetings! ACL2 on GCL does not employ threads and locks, the comments > > in hons-check/memoize-tests.lisp notwithstanding, right? > > > > Take care, > > -- > > Camm Maguire > > c...@maguirefamily.org > > ========================================================================== > > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > > > ============================================================================= > > > Sorry but that's not a reason for reassigning the bug to the glibc > > package. The same way I can say that the GNU libc doesn't have bugs in > > the TSX code, so I am just reassigning the bug back to acl2. > > > > Aurelien > > > This of course is not right, as the websites mentioned in the original > bug report admitted that glibc turned on code under tsx which has > recently found to be buggy. Please see the original poster. > > > Additional note: the non TSX machine has 2 cores, while the TSX > > machine has 64 cores. This might be a parallel building issue. > > > > Aurelien > > > I know this code intimately, and the overwhelming indication in this > case is that there is an issue in at least one of the dynamically linked > standard libraries used by gcl. Parallel builds are done with -j 8 on a > daily basis under standard cpus with no issue at all. There is no cpu > specific code in either gcl or acl2. Hence the issue must lie in used > libraries which alter their behavior in such environments. > > If you can think of a better place for this bug, I'm all ears. I cannot > pin it down further as it is not reproducible in any accessible > environment. Hence I will close this in a week unless a more suitable > destination is agreed upon. > > Take care, > > > Aurelien Jarno <aurel...@aurel32.net> writes: > > > control: reassign 844148 acl2 > > > > On 2016-11-14 11:24, Camm Maguire wrote: > >> reassign 844148 glibc > >> thanks > >> > >> Greetings, and thanks so much for your report! > >> > >> Neither ACL2 nor underlying gcl makes any use of threads or locks, but > >> does rely on standard libc calls, which are known to turn on code in TSX > >> environments that still have bugs. GCL does make use of setjmp/longjmp > >> and volatile declarations which might appear similar but in no way are > >> cpu specific. > > > > Sorry but that's not a reason for reassigning the bug to the glibc > > package. The same way I can say that the GNU libc doesn't have bugs in > > the TSX code, so I am just reassigning the bug back to acl2. > > > > Aurelien > > -- > Camm Maguire c...@maguirefamily.org > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > >
