* [Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
@ 2014-06-19 9:18 ` ubizjak at gmail dot com
2014-06-25 5:13 ` thopre01 at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ubizjak at gmail dot com @ 2014-06-19 9:18 UTC (permalink / raw)
To: gcc-bugs
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);
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
2014-06-19 9:18 ` [Bug rtl-optimization/61559] " ubizjak at gmail dot com
@ 2014-06-25 5:13 ` thopre01 at gcc dot gnu.org
2014-06-25 6:22 ` ebotcazou at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: thopre01 at gcc dot gnu.org @ 2014-06-25 5:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
2014-06-19 9:18 ` [Bug rtl-optimization/61559] " ubizjak at gmail dot com
2014-06-25 5:13 ` thopre01 at gcc dot gnu.org
@ 2014-06-25 6:22 ` ebotcazou at gcc dot gnu.org
2014-09-03 17:11 ` [Bug tree-optimization/61559] " ubizjak at gmail dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-06-25 6:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (2 preceding siblings ...)
2014-06-25 6:22 ` ebotcazou at gcc dot gnu.org
@ 2014-09-03 17:11 ` ubizjak at gmail dot com
2014-09-04 8:56 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ubizjak at gmail dot com @ 2014-09-03 17:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (3 preceding siblings ...)
2014-09-03 17:11 ` [Bug tree-optimization/61559] " ubizjak at gmail dot com
@ 2014-09-04 8:56 ` rguenth at gcc dot gnu.org
2014-09-04 9:52 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-09-04 8:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (4 preceding siblings ...)
2014-09-04 8:56 ` rguenth at gcc dot gnu.org
@ 2014-09-04 9:52 ` jakub at gcc dot gnu.org
2014-09-04 9:59 ` rguenther at suse dot de
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-09-04 9:52 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (5 preceding siblings ...)
2014-09-04 9:52 ` jakub at gcc dot gnu.org
@ 2014-09-04 9:59 ` rguenther at suse dot de
2014-09-04 11:36 ` ubizjak at gmail dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenther at suse dot de @ 2014-09-04 9:59 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (6 preceding siblings ...)
2014-09-04 9:59 ` rguenther at suse dot de
@ 2014-09-04 11:36 ` ubizjak at gmail dot com
2014-09-04 11:52 ` rguenther at suse dot de
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ubizjak at gmail dot com @ 2014-09-04 11:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (7 preceding siblings ...)
2014-09-04 11:36 ` ubizjak at gmail dot com
@ 2014-09-04 11:52 ` rguenther at suse dot de
2014-09-04 12:08 ` jakub at gcc dot gnu.org
2014-11-13 8:46 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: rguenther at suse dot de @ 2014-09-04 11:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (8 preceding siblings ...)
2014-09-04 11:52 ` rguenther at suse dot de
@ 2014-09-04 12:08 ` jakub at gcc dot gnu.org
2014-11-13 8:46 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-09-04 12:08 UTC (permalink / raw)
To: gcc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug tree-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
2014-06-19 9:16 [Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe ubizjak at gmail dot com
` (9 preceding siblings ...)
2014-09-04 12:08 ` jakub at gcc dot gnu.org
@ 2014-11-13 8:46 ` rguenth at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-11-13 8:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread