[Bug 283] Wrong code with -O, possible cleanup_point_expr bug

gdc-bugzilla at gdcproject.org gdc-bugzilla at gdcproject.org
Thu Jan 25 23:58:45 UTC 2018


https://bugzilla.gdcproject.org/show_bug.cgi?id=283

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject.org> ---
Yes I think the CLEANUP_POINT_EXPR is the problem.

In briefest way of describing, the following is generated by codegen:

---
<<cleanup_point
    __gate68 = 0;
    TARGET_EXPR <__pfx69, __pfx69 = *this, __fieldPostblit (&__pfx69)>
    __gate68 = 1;>>;
__slPathE67 = {};
return <retval> = *__ctor (&__slPathE67, &__pfx69, __pfy70);
---

Gimplified into try/finally as:

---
try
  {
    __gate68 = 0;
    __pfx69 = *this;
    __fieldPostblit (&__pfx69);
    try
      {
        try
          {
            __gate68 = 1;
          }
        finally
          {
            __gate68.0_1 = __gate68;
            _2 = ~__gate68.0_1;
            if (_2 != 0) goto <D.4232>; else goto <D.4233>;
            <D.4232>:
            __fieldDtor (&__pfx69);
            <D.4233>:
          }
      }
    finally
      {
        __pfx69 = {CLOBBER};    // ***
      }
    __slPathE67 = {}
    _4 = __ctor (&__slPathE67, &__pfx69, __pfy70);    // ***
    <retval> = *_4;
    return <retval>;
  }
---

Marked with *** are places of interest.  First, temporary var __pfx69 is
clobbered (it is invalidated for further reuse).  Second, its address is taken
(undefined behaviour at this point).

This is likely a problem with the rewrite done in d_build_call, the
cleanup_point expression should encapsulate both parameter and call.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the D.gnu mailing list