From: Karsten P. <Kar...@gm...> - 2016-11-25 19:24:34
|
With karstenoecksMBP:sbclgitnew karstenpoeck$ clang --version Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin16.1.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin and latest head with your commit results in The build seems to have finished successfully, including 18 (out of 18) contributed modules. If you would like to run more extensive tests on the new SBCL, you can try: cd tests && sh ./run-tests.sh Finished running tests. Status: Expected failure: compiler.pure.lisp / MV-CALL-TYPE-DERIVATION Unexpected success: threads.pure.lisp / (WAIT-ON-SEMAPHORE SEMAPHORE-NOTIFICATION LP-1038034) Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL RECURSIVE) Expected failure: full-eval.impure.lisp / INLINE-FUN-CAPTURES-DECL Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT (7 tests skipped for this combination of platform and features) ok //apparent success (reached end of run-tests.sh normally) Karsten On 25.11.16 10:44, Jan Moringen wrote: > On Wed, 2016-11-23 at 20:18 -0500, Douglas Katzman wrote: > >> The way we left things, scymtym is going to take over the fix by >> #undef'ing FORTIFY_SOURCE based on whatever range of clang_major and >> clang_minor versions (preprocessor defines) seem sufficiently wide to >> exclude the bug while leaving the safeguards in when they are known >> to work. > > I tested and pushed a workaround that disables the problematic behavior > by defining > > #define _FORTIFY_SOURCE 0 > > if the clang version is 6.0. This fixes the problem on our MacOS build > slave. Can people with access to different clang versions please verify > that nothing broke there. > > Thanks in advance and kind regards, > Jan > > ------------------------------------------------------------------------------ > |