[Bug c++/63320] New: [5 Regression] bogus ‘this’ was not captured for this lambda function error

["trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 63320
           Summary: [5 Regression] bogus ‘this’ was not captured for this
                    lambda function error
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Happened building qt-creator:

markus@x4 coreplugin % cat windowsupport.ii
class A {
  static void addWindow();
  static void activateWindow(void *);
};
void A::addWindow() {
  int* action {};
  [action] { activateWindow(action); };
}

markus@x4 coreplugin % g++ -c -std=c++14 windowsupport.ii
windowsupport.ii: In lambda function:
windowsupport.ii:7:35: error: ‘this’ was not captured for this lambda function
   [action] { activateWindow(action); };
                                   ^
(4.9 and 4.8 are fine)
markus@x4 coreplugin % g++ -c -std=c++11 windowsupport.ii
markus@x4 coreplugin % icpc -c -std=c++11 windowsupport.ii
markus@x4 coreplugin % clang++ -w -c -std=c++11 windowsupport.ii
markus@x4 coreplugin %
>From gcc-bugs-return-462195-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Sep 21 16:43:07 2014
Return-Path: <gcc-bugs-return-462195-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17655 invoked by alias); 21 Sep 2014 16:43:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17610 invoked by uid 48); 21 Sep 2014 16:43:03 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63321] New: [SH] Unused T bit result of shll / shlr insns
Date: Sun, 21 Sep 2014 16:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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 cf_gcctarget
Message-ID: <bug-63321-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02029.txt.bz2
Content-length: 2746

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc321

            Bug ID: 63321
           Summary: [SH] Unused T bit result of shll / shlr insns
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: olegendo at gcc dot gnu.org
            Target: sh*-*-*

The following examples resemble code that is usually used when implementing
pointer tagging (storing meta info in always-zero bits of a pointer variable).
The shll / shr insns shift the MSB / LSB out into the T bit.  However, the T
bit value is lost and redundant MSB / LSB extractions remain in the code.

unsigned int foo (unsigned int);

unsigned int test2 (unsigned int x)
{
  unsigned int xx = x >> 1;
  if (x & 1)
    return foo (xx);
  else
    return xx;
}

/*
        mov     r4,r1
        shlr    r1
        mov     r4,r0
        tst     #1,r0
        bf/s    .L5
        mov     r1,r0
        rts
        nop
        .align 1
.L5:
        mov.l   .L6,r0
        jmp     @r0
        mov     r1,r4

better:
        shlr    r4
        bt      .L5
        rts
        mov     r4,r0
.L5:
        mov.l   .L6,r0
        jmp     @r0
        nop
*/



void test2_1 (unsigned int x, unsigned int* y)
{
  y[0] = x >> 1;
  y[1] = x & 1;
}

/*
        mov     r4,r1
        mov     r4,r0
        shlr    r1
        and     #1,r0
        mov.l   r1,@r5
        rts
        mov.l   r0,@(4,r5)

better:
        shlr    r4
        movt    r0
        mov.l   r4,@r5
        rts
        mov.l   r0,@(4,r5)
*/

unsigned int test3 (unsigned int x)
{
  unsigned int xx = x << 1;
  if (x & (1 << 31))
    return foo (xx);
  else
    return xx;
}

/*
        cmp/pz  r4
        mov     r4,r0
        bf/s    .L13
        add     r0,r0
        rts
        nop
        .align 1
.L13:
        mov     r0,r4
        mov.l   .L14,r0
        jmp     @r0
        nop

better:
        shll    r4
        bt      .L13
        rts
        mov     r4,r0
.L13:
        mov.l   .L14,r0
        jmp     @r0
        nop
*/

void test3_1 (unsigned int x, unsigned int* y)
{
  y[0] = x << 1;
  y[1] = x >> 31;
}

/*
        mov     r4,r1
        shll    r4
        add     r1,r1
        movt    r4
        mov.l   r1,@r5
        rts
        mov.l   r4,@(4,r5)

better:
        shll    r4
        movt    r0
        mov.l   r4,@r5
        rts
        mov.l   r0,@(4,r5)
*/

It seems that combine doesn't try to combine those adjacent insns into a
parallel, which could be used to implement that kind of patterns.  An
alternative is to do a manual combining/peepholing of insns in the split pass
after combine, as it is done for other insns.