Created attachment 235946 [details] Test case generated by LLVM
Created attachment 235947 [details] LLVM bitcode file to reproduce crash It turns out to be a back end bug, possibly triggered by a second front end bug generating bad code for an inline assembly statement. I added the bitcode file (cc -emit-llvm) that crashes llc from LLVM 14 or 15.
Created attachment 235950 [details] Much smaller test case for backend
https://github.com/llvm/llvm-project/issues/57183
The source code has invalid inline assembly constraints. As far as LLVM is concerned, the fix is to report an error instead of crashing. There are many things you can do with inline assembly that crash the compiler and these bugs seem to be a low priority. We can 1. Find a volunteer to fix clang to report an error. 2. Close this bug as uninteresting. 3. Hold this bug open and test each new LLVM release until it is fixed. 4. Move this bug to the specific port involved and send a bug report upstream. Same for bug 265757 which is the same code in a different package.
(In reply to John F. Carr from comment #5) I don't have a dog in this fight, but I'd vote for option 4 because: - The source code is buggy, port maintainer coould fix it; and - It's on the radar upstream and it's their decision what priority they give it.
Upstream bug report: https://github.com/llvm/llvm-project/issues/57888
(In reply to Bob Bishop from comment #6) I think it should stay assigned to toolchain@ because once clang's upstream would fix it they should probably backport the fix.
Upstream project's bug report: https://github.com/awslabs/aws-crt-python/issues/395
This is essentially a duplicate of 265756 related to port devel/aws-checksums. Same code, different package. A comment there says the code has been fixed upstream.
(In reply to John F. Carr from comment #10) I'm confused. This *is* Ceti Alph^W^W 265756. And I don't see which PR was about aws-checksums? mcl
(In reply to Mark Linimon from comment #11) I think the confusion is that the same Amazon code that calculates checksums, and that was causing a clang assertion, has been copy/pasted between several pieces of software that try to do something with AWS. Specifically, in bug 234232 the issue was first reported for devel/aws-checksums, after which I reported it upstream at https://bugs.llvm.org/show_bug.cgi?id=40985 (which is now https://github.com/llvm/llvm-project/issues/40330), which is _still_ open as of today, 2023-08-31. Meanwhile somebody else also reported it directly to the aws-checksums developers in https://github.com/awslabs/aws-checksums/issues/49, and eventually it was fixed there in https://github.com/awslabs/aws-checksums/commit/ad53be196a25bbefa3700a01187fdce573a7d2d0, by adjusting the inline assembly to have less-impossible constraints. However, at the time *this* bug was created, the devel/py-awscrt port still had an old copy of the awscrt files, including the crash-prone crc32c_sse42_asm.c file with inline assembly. And in the mean time, the py-awscrt people seem to have updated their vendor copy of awscrt to a newer version, which no longer provokes any assertion or "impossible constraint" errors. Therefore, I think this bug can be closed now?