[llvm-bugs] [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=26519

Mark Millard <markmi at dsl-only.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #24 from Mark Millard <markmi at dsl-only.net> ---
(In reply to Krzysztof Parzyszek from comment #19)
> Committed a fix in r302183.

Bad news: Another code generation error, this
time demonstrated in compiling part of perl5. . .
(I tried to build a port that indirectly
tried build perl5 but perl5's miniperl crashes.)

/usr/obj/portswork/usr/ports/lang/perl5.24/work/perl-5.24.1/numeric.c

has Perl_cast_iv(NV f) for which clang double stores
two different things to one address [24(r1)]. Below
the => lines are the double store, the second
destroying the r30 value that was saved in the first:

Dump of assembler code for function Perl_cast_iv:
   0x0196a114 <+0>:     mflr    r0
   0x0196a118 <+4>:     stw     r0,4(r1)
   0x0196a11c <+8>:     stwu    r1,-32(r1)
   0x0196a120 <+12>:    stw     r31,28(r1)
=>   0x0196a124 <+16>:  stw     r30,24(r1)
   0x0196a128 <+20>:    mr      r31,r1
   0x0196a12c <+24>:    mfcr    r12
=>   0x0196a130 <+28>:  stw     r12,24(r31)

Note: r31 == r1 for that second "=>" line.

The return code sequence has a similar
problem: two loads from the same address.

Note: r31 == r1 here too.

=>   0x0196a1bc <+168>: lwz     r12,24(r31)
   0x0196a1c0 <+172>:   lwz     r0,36(r1)
   0x0196a1c4 <+176>:   lwz     r31,28(r1)
=>   0x0196a1c8 <+180>: lwz     r30,24(r1)
   0x0196a1cc <+184>:   mtcrf   32,r12
   0x0196a1d0 <+188>:   addi    r1,r1,32
   0x0196a1d4 <+192>:   mtlr    r0
   0x0196a1d8 <+196>:   blr

The Perl_cast_iv source code looks like:

IV
Perl_cast_iv(NV f)
{
  if (f < IV_MAX_P1)
    return f < IV_MIN ? IV_MIN : (IV) f;
  if (f < UV_MAX_P1) {
#if CASTFLAGS & 2
    /* For future flexibility allowing for sizeof(UV) >= sizeof(IV)  */
    if (f < UV_MAX_P1_HALF)
      return (IV)(UV) f;
    f -= UV_MAX_P1_HALF;
    return (IV)(((UV) f) | (1 + (UV_MAX >> 1)));
#else
    return (IV)(UV) f;
#endif
  }
  return f > 0 ? (IV)UV_MAX : 0 /* NaN */;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170506/b048f884/attachment.html>