[Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

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

            Bug ID: 61559
           Summary: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
            Target: i686-pc-linux-gnu

gcc.dg/builtin-bswap-8.c fails on i686 with -mmovbe:

~/gcc-build/gcc/cc1 -O2 -march=corei7 -mmovbe -m32 builtin-bswap-8.c

foo5:
        movbe   4(%esp), %eax
        movbe   8(%esp), %edx
        andl    %edx, %eax
        bswap   %eax
        ret
foo6:
        movbe   4(%esp), %eax
        movbe   8(%esp), %edx
        orl     %edx, %eax
        bswap   %eax
        ret
foo7:
        movbe   4(%esp), %eax
        movbe   8(%esp), %edx
        xorl    %edx, %eax
        bswap   %eax
        ret

It looks that direct swap from memory (movbe) interferes with bswap
elimination. Without -mmovbe, following asm is produced:

foo5:
        movl    8(%esp), %eax
        andl    4(%esp), %eax
        ret
foo6:
        movl    8(%esp), %eax
        orl     4(%esp), %eax
        ret
foo7:
        movl    8(%esp), %eax
        xorl    4(%esp), %eax
        ret

[Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.preudhomme at arm dot com

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Adding a CC that might be interested in this PR.
>From gcc-bugs-return-454539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 19 09:22:29 2014
Return-Path: <gcc-bugs-return-454539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3961 invoked by alias); 19 Jun 2014 09:22:29 -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 3642 invoked by uid 48); 19 Jun 2014 09:22:22 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
Date: Thu, 19 Jun 2014 09:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
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:
Message-ID: <bug-61559-4-wRd5PQ5jOe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61559-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61559-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-SW-Source: 2014-06/txt/msg01621.txt.bz2
Content-length: 640

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
On a related note, -march=i386 generates long sequences of rol insns, e.g.:

foo5:
        movl    4(%esp), %eax
        rolw    $8, %ax
        roll    $16, %eax
        rolw    $8, %ax
        movl    8(%esp), %edx
        rolw    $8, %dx
        roll    $16, %edx
        rolw    $8, %dx
        andl    %edx, %eax
        rolw    $8, %ax
        roll    $16, %eax
        rolw    $8, %ax
        ret

Please note that this arch doesn't have bswap insn, but this insn isn't
generated for optimized code anyway.
>From gcc-bugs-return-454540-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 19 09:24:04 2014
Return-Path: <gcc-bugs-return-454540-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5089 invoked by alias); 19 Jun 2014 09:24:04 -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 5027 invoked by uid 48); 19 Jun 2014 09:24:00 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61454] ICE in simplification of initialization expression with array
Date: Thu, 19 Jun 2014 09:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fxcoudert at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-61454-4-BMMLhwnTwy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61454-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61454-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-06/txt/msg01622.txt.bz2
Content-length: 1058

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |fxcoudert at gcc dot gnu.org

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
In expr.c:scalarize_intrinsic_call(), we don't deal correctly with intrinsics
that have an optional kind argument. I'm testing this simple patch to fix it:


Index: expr.c
==================================================================--- expr.c    (revision 211685)
+++ expr.c    (working copy)
@@ -1955,7 +1955,7 @@ scalarize_intrinsic_call (gfc_expr *e)
   for (; a; a = a->next)
     {
       n++;
-      if (a->expr->expr_type != EXPR_ARRAY)
+      if (!a->expr || a->expr->expr_type != EXPR_ARRAY)
     continue;
       array_arg = n;
       expr = gfc_copy_expr (a->expr);

[Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[thopre01 at gcc dot gnu.org]

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

thopre01 at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |thopre01 at gcc dot gnu.org

--- Comment #3 from thopre01 at gcc dot gnu.org ---
Adding the author of this file in CC as there is more chance he is interested
in this issue.

[Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ebotcazou at gcc dot gnu.org       |

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I guess the transformations should accept MEMs instead of just REGs but, no,
I'm not particularly interested in quirks of CISC architectures, I have enough
to do with those of RISC architectures.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-03
                 CC|                            |rguenth at gcc dot gnu.org
          Component|rtl-optimization            |tree-optimization
     Ever confirmed|0                           |1

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Eric Botcazou from comment #4)
> I guess the transformations should accept MEMs instead of just REGs but, no,
> I'm not particularly interested in quirks of CISC architectures, I have
> enough to do with those of RISC architectures.

The problem is that with both function arguments in memory, combine simplifies
sequence of bswaps with memory argument ( == movbe) in foo7 to:

Failed to match this instruction:
(set (reg:SI 84 [ D.2318 ])
    (xor:SI (mem/c:SI (plus:SI (reg/f:SI 16 argp)
                (const_int 4 [0x4])) [2 b+0 S4 A32])
        (mem/c:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])))

This is invalid RTX, where both input arguments are in memory.

The optimized tree dump for foo7 is:

  <bb 2>:
  _2 = __builtin_bswap32 (a_1(D));
  _4 = __builtin_bswap32 (b_3(D));
  _5 = _4 ^ _2;
  _6 = __builtin_bswap32 (_5); [tail call]
  return _6;

It looks to me that the optimization has to be re-implemented as tree
optimization (probably by extending fold_builtin_bswap in builtins.c). This
generic optimization will also benefit targets without bswap RTX pattern, e.g.
plain i386, as observed in Comment #2.

I'm recategorizing the PR as a tree-optimization.
>From gcc-bugs-return-461151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 03 17:15:04 2014
Return-Path: <gcc-bugs-return-461151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12301 invoked by alias); 3 Sep 2014 17:15:02 -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 12219 invoked by uid 48); 3 Sep 2014 17:14:57 -0000
From: "dje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63156] web can't handle AUTOINC correctly
Date: Wed, 03 Sep 2014 17:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dje at gcc dot gnu.org
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-63156-4-a8B83dlvzg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63156-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63156-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/msg00985.txt.bz2
Content-length: 547

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-03
                 CC|                            |dje at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Eric Botcazou from comment #4)
> > I guess the transformations should accept MEMs instead of just REGs but, no,
> > I'm not particularly interested in quirks of CISC architectures, I have
> > enough to do with those of RISC architectures.
> 
> The problem is that with both function arguments in memory, combine
> simplifies sequence of bswaps with memory argument ( == movbe) in foo7 to:
> 
> Failed to match this instruction:
> (set (reg:SI 84 [ D.2318 ])
>     (xor:SI (mem/c:SI (plus:SI (reg/f:SI 16 argp)
>                 (const_int 4 [0x4])) [2 b+0 S4 A32])
>         (mem/c:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])))
> 
> This is invalid RTX, where both input arguments are in memory.
> 
> The optimized tree dump for foo7 is:
> 
>   <bb 2>:
>   _2 = __builtin_bswap32 (a_1(D));
>   _4 = __builtin_bswap32 (b_3(D));
>   _5 = _4 ^ _2;
>   _6 = __builtin_bswap32 (_5); [tail call]
>   return _6;

Seems to me we want

  (bit_xor (bswap32 @0) (bswap32 @1)) -> (bswap32 (bit_xor @0 @1))

in match-and-simplify speak.

On trunk this transform would go to tree-ssa-forwprop.c as pattern.
It would apply to all bitwise binary ops and all bswap builtins
(all bit/byte-shuffling operations applying the same shuffle to
both operands).

(for bitop in bit_xor bit_ior bit_and
  (for bswap in BUILT_IN_BSWAP16 BUILT_IN_BSWAP32 BUILT_IN_BSWAP64
    (simplify
      (bitop (bswap @0) (bswap @1))
      (bswap (bitop @0 @1))))
  (simplify
    (bitop (vec_perm @1 @2 @0) (vec_perm @3 @4 @0))
    (vec_perm (bitop @1 @3) (bitop @2 @4) @0)))

not sure if the vector permute one is profitable (but I guess a
permute is always more expensive than a bit operation).

The requested transform of course relies on somebody transforming
bswap (bswap (x)) to x and for vec_perm detecting a cancelling
operation (tree-ssa-forwprop.c can do that already I think).

Mine.  Fixed by the above on match-and-simplify.

> It looks to me that the optimization has to be re-implemented as tree
> optimization (probably by extending fold_builtin_bswap in builtins.c). This
> generic optimization will also benefit targets without bswap RTX pattern,
> e.g. plain i386, as observed in Comment #2.
> 
> I'm recategorizing the PR as a tree-optimization.
>From gcc-bugs-return-461184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 09:04:46 2014
Return-Path: <gcc-bugs-return-461184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27839 invoked by alias); 4 Sep 2014 09:04:45 -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 27454 invoked by uid 48); 4 Sep 2014 09:04:38 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
Date: Thu, 04 Sep 2014 09:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61559-4-H0zZRDfNH3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61559-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61559-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-SW-Source: 2014-09/txt/msg01018.txt.bz2
Content-length: 431

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #6)

> Seems to me we want
> 
>   (bit_xor (bswap32 @0) (bswap32 @1)) -> (bswap32 (bit_xor @0 @1))
> 
> in match-and-simplify speak.

Please note that there are some more interesting transformations involving
immediates and bit_not, as shown in builtin-bswap-8.c.
>From gcc-bugs-return-461185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 09:16:27 2014
Return-Path: <gcc-bugs-return-461185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2579 invoked by alias); 4 Sep 2014 09:16:26 -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 2510 invoked by uid 55); 4 Sep 2014 09:16:18 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
Date: Thu, 04 Sep 2014 09:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61559-4-lkqKNcub43@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61559-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61559-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-SW-Source: 2014-09/txt/msg01019.txt.bz2
Content-length: 1094

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 4 Sep 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
> 
> --- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
> (In reply to Richard Biener from comment #6)
> 
> > Seems to me we want
> > 
> >   (bit_xor (bswap32 @0) (bswap32 @1)) -> (bswap32 (bit_xor @0 @1))
> > 
> > in match-and-simplify speak.
> 
> Please note that there are some more interesting transformations involving
> immediates and bit_not, as shown in builtin-bswap-8.c.

Added.

/* PR61559.  Transforms for gcc.dg/builtin-bswap-8.c  */
(for bswap in BUILT_IN_BSWAP16 BUILT_IN_BSWAP32 BUILT_IN_BSWAP64
  (simplify
    (bswap (bswap @0))
    @0)
  (simplify
    (bswap (bit_not (bswap @0)))
    (bit_not @0))
  (for bitop in bit_xor bit_ior bit_and
    (simplify
      (bitop (bswap @0) (bswap @1))
      (bswap (bitop @0 @1)))
    (simplify
      (bswap (bitop (bswap @0) INTEGER_CST@1))
      (bitop @0 (bswap @1)))))
>From gcc-bugs-return-461186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 09:36:18 2014
Return-Path: <gcc-bugs-return-461186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10524 invoked by alias); 4 Sep 2014 09:36:17 -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 10488 invoked by uid 48); 4 Sep 2014 09:36:10 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63157] may_alias doesn't work as expected in template nested types
Date: Thu, 04 Sep 2014 09:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: keywords bug_status cf_reconfirmed_on everconfirmed cf_known_to_fail
Message-ID: <bug-63157-4-VziFYPh80b@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63157-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63157-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/msg01020.txt.bz2
Content-length: 1083

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-04
     Ever confirmed|0                           |1
      Known to fail|                            |5.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Seems to be a C++ frontend bug - test_type<T>::type doesn't get may_alias
applied:

void check(short int*, msg*) (short int * a, struct msg * b)
{
  short int D.2260;
  struct msg_alias * {ref-all} q;
  struct type * p;

  *a = 5;
  q = b;
  q->D.2232.seq_no = 6;
  p = b;
  p->D.2254.seq_no = 6;
  D.2260 = *a;
  if (D.2260 == 5) goto <D.2261>; else goto <D.2262>;
  <D.2261>:
  abort ();
  <D.2262>:

(testcase with uncommented working case and renamed p to q for that case)

Confirmed on trunk.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Aren't these optimizations actually a pessimization for -mmovbe if the inner
bswap is on a read from memory?  Assuming the load and bswap instruction is
cheap, then e.g. loading two values with bswap on them and doing say xor on
them afterwards might be cheaper than load the two values, xor them and then
bswap them (because for that bswap you don't have a load+bswap instruction).

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 4 Sep 2014, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Aren't these optimizations actually a pessimization for -mmovbe if the inner
> bswap is on a read from memory?  Assuming the load and bswap instruction is
> cheap, then e.g. loading two values with bswap on them and doing say xor on
> them afterwards might be cheaper than load the two values, xor them and then
> bswap them (because for that bswap you don't have a load+bswap instruction).

Depends on how fast that load+bswap instruction is I suppose (if it
plays nicely with things like store-forwarding on the pipeline
and pipelines as well as regular loads, etc.).

That said - what does the optimization guides say on consecutive
movbe instructions vs. non-movbe and a bswap instruction?

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> Aren't these optimizations actually a pessimization for -mmovbe if the inner
> bswap is on a read from memory?  Assuming the load and bswap instruction is
> cheap, then e.g. loading two values with bswap on them and doing say xor on
> them afterwards might be cheaper than load the two values, xor them and then
> bswap them (because for that bswap you don't have a load+bswap instruction).

    (simplify
      (bitop (bswap @0) (bswap @1))
      (bswap (bitop @0 @1)))

This one should be:

    (simplify
      (bswap (bitop (bswap @0) (bswap @1)))
      (bitop @0 @1))

This is what builtin-bswap-8.c tests, and I believe it will address Jakub's
concerns.
>From gcc-bugs-return-461200-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 11:38:04 2014
Return-Path: <gcc-bugs-return-461200-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9716 invoked by alias); 4 Sep 2014 11:38:04 -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 9666 invoked by uid 48); 4 Sep 2014 11:38:00 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
Date: Thu, 04 Sep 2014 11:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61559-4-5Mxm3xgDIj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61559-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61559-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-SW-Source: 2014-09/txt/msg01034.txt.bz2
Content-length: 342

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

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #11)

> This one should be:
> 
>     (simplify
>       (bswap (bitop (bswap @0) (bswap @1)))
>       (bitop @0 @1))

Oh, we already have this. Please disregard this message.
>From gcc-bugs-return-461201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 11:39:23 2014
Return-Path: <gcc-bugs-return-461201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10682 invoked by alias); 4 Sep 2014 11:39:23 -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 10617 invoked by uid 48); 4 Sep 2014 11:39:15 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
Date: Thu, 04 Sep 2014 11:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61559-4-WKluKiGw6s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61559-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61559-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/msg01035.txt.bz2
Content-length: 1124

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

--- Comment #13 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (for bitop in bit_xor bit_ior bit_and
>   (for bswap in BUILT_IN_BSWAP16 BUILT_IN_BSWAP32 BUILT_IN_BSWAP64
>     (simplify
>       (bitop (bswap @0) (bswap @1))
>       (bswap (bitop @0 @1))))
>   (simplify
>     (bitop (vec_perm @1 @2 @0) (vec_perm @3 @4 @0))
>     (vec_perm (bitop @1 @3) (bitop @2 @4) @0)))
>
> not sure if the vector permute one is profitable (but I guess a
> permute is always more expensive than a bit operation).

For the vector version, there is no reason to restrict to bit operations. It
works just as well for float addition, etc. And at least in the case where
@1==@3&&@2==@4 (I hope there is always a CSE to clean up the duplicated bitop)
and everything is single-use, it is profitable.

> The requested transform of course relies on somebody transforming
> bswap (bswap (x)) to x and for vec_perm detecting a cancelling
> operation (tree-ssa-forwprop.c can do that already I think).

Yes for vec_perm, in simplify_permutation.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 4 Sep 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
> 
> --- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
> (In reply to Uroš Bizjak from comment #11)
> 
> > This one should be:
> > 
> >     (simplify
> >       (bswap (bitop (bswap @0) (bswap @1)))
> >       (bitop @0 @1))
> 
> Oh, we already have this. Please disregard this message.

Not sure - we don't exactly have it.  OTOH I think
that

    (simplify
      (bitop (bswap @0) (bswap @1))
      (bswap (bitop @0 @1)))

is profitable in most cases (not only when wrapped inside another
bswap).  Jakubs concern applies though.

OTOH

    (simplify
      (bswap (bitop (bswap @0) INTEGER_CST@1))
      (bitop @0 (bswap @1)))))

may generally apply (not only to INTEGER_CST 2nd operand to bitop).
The argument would be that one bswap goes away.  But again if
@0 was a memory and @1 is not then this isn't always profitable(?)
(well, the outer bswap goes away).

So merge the restricted first one and this to

   (simplify
     (bswap (bitop:c (bswap @0) @1))
     (bitop @0 (bswap @1)))

?  Thus only one operand of the bitop needs to be a bswap if
there is an outer bswap.  For constant @1 the inner bswap
will be folded away as well as if @1 is a bswap itself.


/* PR61559.  Transforms for gcc.dg/builtin-bswap-8.c  */
(for bswap in BUILT_IN_BSWAP16 BUILT_IN_BSWAP32 BUILT_IN_BSWAP64
  (simplify
    (bswap (bswap @0))
    @0)
  (simplify
    (bswap (bit_not (bswap @0)))
    (bit_not @0))
  (for bitop in bit_xor bit_ior bit_and
    /* This might not be profitable if the inner bswaps are
       free because @0 and @1 are memory operands and the
       target has an instruction for load+bswap.  */
    (simplify
      (bitop (bswap @0) (bswap @1))
      (bswap (bitop @0 @1)))
    (simplify
      (bswap (bitop:c (bswap @0) @1))
      (bitop @0 (bswap @1)))))
>From gcc-bugs-return-461203-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 12:02:20 2014
Return-Path: <gcc-bugs-return-461203-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29421 invoked by alias); 4 Sep 2014 12:02:20 -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 29190 invoked by uid 48); 4 Sep 2014 12:02:13 -0000
From: "avi@cloudius-systems.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63164] New: unnecessary calls to __dynamic_cast
Date: Thu, 04 Sep 2014 12:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: avi@cloudius-systems.com
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
Message-ID: <bug-63164-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/msg01037.txt.bz2
Content-length: 1432

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

            Bug ID: 63164
           Summary: unnecessary calls to __dynamic_cast
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: avi@cloudius-systems.com

The code

  struct A {
    virtual ~A() {}
  };

  struct B final : A {
    virtual ~B() {}
  };

  B* dc(A* a) {
    return dynamic_cast<B*>(a);
  }

compiles into the following assembly, which contains a call (jump) to
__dynamic_cast:

0000000000000000 <dc(A*)>:
   0:    48 85 ff                 test   %rdi,%rdi
   3:    74 1b                    je     20 <dc(A*)+0x20>
   5:    31 c9                    xor    %ecx,%ecx
   7:    ba 00 00 00 00           mov    $0x0,%edx
            8: R_X86_64_32    typeinfo for B
   c:    be 00 00 00 00           mov    $0x0,%esi
            d: R_X86_64_32    typeinfo for A
  11:    e9 00 00 00 00           jmpq   16 <dc(A*)+0x16>
            12: R_X86_64_PC32    __dynamic_cast-0x4
  16:    66 2e 0f 1f 84 00 00     nopw   %cs:0x0(%rax,%rax,1)
  1d:    00 00 00
  20:    31 c0                    xor    %eax,%eax
  22:    c3                       retq


However, since B is declared final, a simple compare of a's typeinfo with B's
would suffice.  This is a missed optimization opportunity.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[jakub at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3499 bytes --]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #14)
> On Thu, 4 Sep 2014, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
> > 
> > --- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
> > (In reply to Uroš Bizjak from comment #11)
> > 
> > > This one should be:
> > > 
> > >     (simplify
> > >       (bswap (bitop (bswap @0) (bswap @1)))
> > >       (bitop @0 @1))
> > 
> > Oh, we already have this. Please disregard this message.
> 
> Not sure - we don't exactly have it.  OTOH I think
> that
> 
>     (simplify
>       (bitop (bswap @0) (bswap @1))
>       (bswap (bitop @0 @1)))
> 
> is profitable in most cases (not only when wrapped inside another
> bswap).  Jakubs concern applies though.

My concern has not been backed up by data from any target, and generally I'd
say it should be better if we are able to canonicalize in the middle-end (e.g.
for VN etc.).
The question is if for selected ISAs and if the arguments are all memories e.g.
right before expansion or during expansion or RTL optimizations it might not be
worth to undo that if it proves to be beneficial.
>From gcc-bugs-return-461205-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 04 12:11:09 2014
Return-Path: <gcc-bugs-return-461205-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2410 invoked by alias); 4 Sep 2014 12:11:08 -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 2341 invoked by uid 48); 4 Sep 2014 12:11:05 -0000
From: "m.zakirov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
Date: Thu, 04 Sep 2014 12:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: m.zakirov at samsung dot com
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: attachments.created
Message-ID: <bug-61875-4-mCZdbXasFX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61875-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61875-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/msg01039.txt.bz2
Content-length: 436

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

--- Comment #6 from Marat Zakirov <m.zakirov at samsung dot com> ---
Created attachment 33446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3446&actioníit
Proposed patch

According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00061.html I think
this bug should be closed as invalid. If you want libsanitizer to assert when
meet -fexceptions you may use attached patch.

[Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.  Note I've only implemented what is necessary for the testcase not what
was discussed additionally.