[clang] Flag `-mlong-double-128` causes segfault

[kozakaron]

The following code causes segmentation fault when compiled with the -mlong-double-128 flag on Windows 11:

int main()
{
    long double x = 1.0L;
    x *= 2.0L;    // crashes here

    return 0;
}

Runs flawlessly with GCC, and with Ubuntu Clang in WSL. Also runs fine without the flag or with -mlong-double-64 or -mlong-double-80 . Also fails with clang++.

Normal operation

D:\> clang -o bug_report bug_report.c
D:\> .\bug_report.exe

Returns with code 0 almost instantly.

Error

D:\> clang -o bug_report bug_report.c -mlong-double-128
D:\> .\bug_report.exe

Runs for seconds, and returns a non-zero value. Gnu debugger says, it had segmentation fault after executing the marked line.

Environment

• OP Sys: Windows 11 Pro 23H2
• CPU: AMD Ryzen 7 5800H

D:\> clang --version
(built by Brecht Sanders) clang version 16.0.6
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/mingw64/bin

[EugeneZelenko]

Could you please try 19 or main branch? https://godbolt.org should be helpful.

[kozakaron]

Well I don't read assembly. But here it is:

This one crashes

clang -S -fverbose-asm -o bug_report.s bug_report.c -mlong-double-128

	.text
	.def	@feat.00;
	.scl	3;
	.type	0;
	.endef
	.globl	@feat.00
.set @feat.00, 0
	.file	"bug_report.c"
	.def	main;
	.scl	2;
	.type	32;
	.endef
	.section	.rdata,"dr"
	.p2align	4, 0x0                          # -- Begin function main
.LCPI0_0:
	.quad	0x0000000000000000              # fp128 1
	.quad	0x3fff000000000000
	.text
	.globl	main
	.p2align	4, 0x90
main:                                   # @main
.seh_proc main
# %bb.0:
	pushq	%rbp
	.seh_pushreg %rbp
	subq	$64, %rsp
	.seh_stackalloc 64
	leaq	64(%rsp), %rbp
	.seh_setframe %rbp, 64
	.seh_endprologue
	callq	__main
	movl	$0, -4(%rbp)
	movaps	.LCPI0_0(%rip), %xmm0
	movaps	%xmm0, -32(%rbp)
	movaps	-32(%rbp), %xmm1
	movaps	%xmm1, %xmm0
	callq	__addtf3
                                        # kill: def $xmm1 killed $xmm0
	movaps	%xmm0, -32(%rbp)
	xorl	%eax, %eax
	addq	$64, %rsp
	popq	%rbp
	retq
	.seh_endproc
                                        # -- End function
	.addrsig

For reference, this one does not

clang -S -fverbose-asm -o bug_report.s bug_report.c

	.text
	.def	@feat.00;
	.scl	3;
	.type	0;
	.endef
	.globl	@feat.00
.set @feat.00, 0
	.file	"bug_report.c"
	.def	main;
	.scl	2;
	.type	32;
	.endef
	.globl	main                            # -- Begin function main
	.p2align	4, 0x90
main:                                   # @main
.seh_proc main
# %bb.0:
	pushq	%rbp
	.seh_pushreg %rbp
	subq	$64, %rsp
	.seh_stackalloc 64
	leaq	64(%rsp), %rbp
	.seh_setframe %rbp, 64
	.seh_endprologue
	callq	__main
	movl	$0, -4(%rbp)
	fld1
	fstpt	-32(%rbp)
	fldt	-32(%rbp)
	fadd	%st, %st(0)
	fstpt	-32(%rbp)
	xorl	%eax, %eax
	addq	$64, %rsp
	popq	%rbp
	retq
	.seh_endproc
                                        # -- End function
	.addrsig

[kozakaron]

Could you please try 19 or main branch? https://godbolt.org should be helpful.

clang version 19.1.4 throws a linker error, which is I guess an acceptable error instead of a faulty executable:

D:\> C:\lib\clang+llvm-19.1.4-x86_64-pc-windows-msvc\bin\clang.exe  -o bug_report.exe bug_report.c -mlong-double-128

bug_report-330d35.o : error LNK2019: unresolved external symbol __addtf3 referenced in function main
bug_report.exe : fatal error LNK1120: 1 unresolved externals
clang: error: linker command failed with exit code 1120 (use -v to see invocation)

[radl97]

Could you please try 19 or main branch? https://godbolt.org/ should be helpful.

Note that the issue is with Clang on MinGW, and godbolt only supports MinGW clang 16.0.2.

Godbolt reproduces the issue on this version.

If I had to guess, __addtf3 ABI incompatibility arises. I think the addtf3 implementation is built with default long double (passing parameters from stack), but the program using it through the intrinsic assumes long double is 128-bit, so it passes parameters through XMM, instead.

For this, I have tested removing the call to the __addtf3 function from the failing assembly listing, and the program did indeed work terminated successfully. (but this is still not a proof of anything)