Date: Wed, 20 May 2026 02:02:40 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 295431] CURRENT compiler miscompiles lang/mit-scheme Message-ID: <bug-295431-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295431 Bug ID: 295431 Summary: CURRENT compiler miscompiles lang/mit-scheme Product: Base System Version: 16.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: jfc@mit.edu Created attachment 270915 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=270915&action=edit llvm IR The system cc compiler on CURRENT miscompiles lang/mit-scheme for amd64. The attached LLVM IR file is from src/microcode/cmpint.c. Compile it -O2 -S -fno-strict-aliasing -march=x86-64-v3. The assembly output for function guarantee_interp_return contains movabsq $7493989779944505344, %rcx # imm = 0x6800000000000000 orq %rax, %rcx movq $0, stack_pointer(%rip) movq %rcx, 0 The last line is a store to address 0, causing a runtime crash. The previous line is also incorrect, causing a store of NULL to an interpreter stack pointer that should never be NULL. That NULL value is used for the store address on the last line. Usually -fno-strict-aliasing prevents miscompilation but this time it does the opposite. FreeBSD clang version 21.1.8 (https://github.com/llvm/llvm-project.git llvmorg-21.1.8-0-g2078da43e25a) devel/llvm21 has the same behavior. The IR is incompatible with llvm19 due to the new "capture" keyword. That keyword is used for alias analysis. A possible clue. It's conceivable that the MIT Scheme code has undefined behavior other than aliasing. I have not had time to trace the optimization passes to see where the bad code came in. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-295431-227>