From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id BFF8C385B834; Mon, 23 Mar 2020 21:21:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BFF8C385B834
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1584998490;
 bh=D8D/wH4RS+I3xq88SzMQT8F1UT1UTsqjDAMQPj65trQ=;
 h=From:To:Subject:Date:From;
 b=WrVpRLcQn5nZbkeUlrpt2jBAhH7bI4eWtHGi1ypSsRpTSJeDgRTq+K+e3+muvhpZZ
 r6po4UihlDIwi6KI3cnG03KVunqq0KI70fPC0mC5FZxbNIUWZGQazNrbZNkvmaEvSz
 d/fpJ26kWPd+H5nvvTjo/s/tGPk3zpohdb4eyO2I=
From: "eyalroz at technion dot ac.il" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/94294] New: [missed optimization] new+delete
 of unused local string not removed
Date: Mon, 23 Mar 2020 21:21:30 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 10.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: eyalroz at technion dot ac.il
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-94294-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2020 21:21:30 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94294

            Bug ID: 94294
           Summary: [missed optimization] new+delete of unused local
                    string not removed
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

(Relevant Godbolt: https://godbolt.org/z/GygbjZ)

This is the second of two apparent bugs, following bug 94293. They both
manifest when compiling the following program:

#include <string>

int bar() {
    struct poor_mans_pair {
        int first;
        std::string second;
    };
    poor_mans_pair p {=20
        123, "Hey... no small-string optimization for me please!" };
    return p.first;
}

For x86_64, this would ideally compile into:

bar():
        mov     eax, 123
        ret

but when compiling this  with GCC 10.0.1 20200322 (or GCC 9.x etc.), we get
assembly which calls operator new[](), populates the string, calls operator
delete[](), then returns 123:

bar():
        sub     rsp, 8
        mov     edi, 51
        call    operator new(unsigned long)
        movdqa  xmm0, XMMWORD PTR .LC0[rip]
        mov     esi, 51
        mov     rdi, rax
        movups  XMMWORD PTR [rax], xmm0
        movdqa  xmm0, XMMWORD PTR .LC1[rip]
        movups  XMMWORD PTR [rax+16], xmm0
        movdqa  xmm0, XMMWORD PTR .LC2[rip]
        movups  XMMWORD PTR [rax+32], xmm0
        mov     eax, 8549
        mov     WORD PTR [rdi+48], ax
        mov     BYTE PTR [rdi+50], 0
        call    operator delete(void*, unsigned long)
        mov     eax, 123
        add     rsp, 8
        ret
.LC0:
        .quad   7935393319309894984
        .quad   3273110194895396975
.LC1:
        .quad   8007513861377913971
        .quad   8386118574366356592
.LC2:
        .quad   2338053640980164457
        .quad   8314037903514690925

This bug report is about how the allocation and de-allocation are not
elided/optimized-away, even though the std::string variable is local and
unused.

AFAICT, g++ is not required to do this. And, in fact, clang++ doesn't do th=
is
with its libc++. cppreference says that, starting in C++14,

> New-expressions are allowed to elide or combine allocations made=20
> through replaceable allocation functions. In case of elision, the
> storage may be provided by the compiler without making the call to=20
> an allocation function (this also permits optimizing out unused
> new-expression)

and this is, indeed, the case of an unused new-expression. Well,
eventually-unused.=20

Note: I suppose it's theoretically possible that this bug only manifests
because   bug 94293 prevents the allocated space from being recognized as
unused; but I can't tell whether that's the case.=