[Bug 207175] projects/clang380-import for TARGET_ARCH=powerpc : clang 3.8.0 sometimes mishandles va_list overflow_arg_area vs. reg_save_area

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175

--- Comment #2 from Mark Millard <markmi at dsl-only.net> ---
(In reply to Mark Millard from comment #1)

The following has been submitted to llvm 26605. It matches up with the exchange
on the lists.


Roman Divacky (rdivacky at vlakno.cz) came up with the following patch [other
than some discussion of what turned into "(8)" in "getIn8(8)" below]. The
svnlite diff below is from my testing area for projects/clang380-import in
FreeBSD's svn. So the revision number is from there too.

Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp
===================================================================
--- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp       
(revision 295601)
+++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp       
(working copy)
@@ -3569,6 +3569,8 @@
  {
    CGF.EmitBlock(UsingOverflow);

+    Builder.CreateStore(Builder.getInt8(8), NumRegsAddr);
+
    // Everything in the overflow area is rounded up to a size of at least 4.
    CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4);

The "(8)" is intended to match the "(8)" from:

  llvm::Value *CC =
      Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond");


My simple test cases and FreeBSD's clang380-import "buildworld" materials
(built with the udpate clang 3.8.0) all indicate that this fixes the problem
reported.

For example each of the following now work based on code generation from the
patched clang 3.8.0:

la -l -n /

svnlite update -295601 /usr/src

Both are from using the patched clang 3.8.0 to "buildworld" and then install it
and reboot and use the software. The FreeBSD vintage started from is
projects/clang380-import -r295601 .

I did some testing with doubles in use as a variant of my simplified example as
well in order to test the fpr related handling, not just gpr related. The mix
worked fine.


[Note: I run with the signal delivery modified to have a "red zone" to deal
with other aspects of clang 3.8.0 code generation that are currently not ABI
compliant for when the stack pointer is moved. Having a "red zone" is still
operationally correct for an ABI compliant code generation, it just temporarily
wastes more bytes. Also: the kernel was built with gcc 4.2.1 but world was
built with the patched clang 3.8.0. At this stage I've only been identifying
issues with "world" vs. clang 3.8.0. The kernel is a much more involved issue.]

-- 
You are receiving this mail because:
You are the assignee for the bug.