[Bug middle-end/67421] New: gcc.dg/wide-shift-64.c FAILs

[Bug middle-end/67421] New: gcc.dg/wide-shift-64.c FAILs

[ro at gcc dot gnu.org]

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

            Bug ID: 67421
           Summary: gcc.dg/wide-shift-64.c FAILs
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: jiwang at gcc dot gnu.org
  Target Milestone: ---
              Host: sparc*-sun-solaris2.*
            Target: sparc*-sun-solaris2.*
             Build: sparc*-sun-solaris2.*

Created attachment 36275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36275&action=edit
wide-shift-64.c.219r.combine

The new gcc.dg/wide-shift-64.c testcase FAILs on SPARC for the 64-bit multilib
only:

FAIL: gcc.dg/wide-shift-64.c scan-rtl-dump-not combine "ior"

I'm attaching the dump.

Btw. I noticed a nit: both the ChangeLog entry and the commit message mention
gcc.dg/wide_shift_64_1.c and gcc.dg/wide_shift_128_1.c,
  while the actual files are named gcc.dg/wide-shift-64.c and
gcc.dg/wide-shift-128.c (similarly for the aarch64 testcase), which makes it
harder to find
when/by whom the files were committed.

  Rainer

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[jiwang at gcc dot gnu.org]

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

--- Comment #1 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #0)
> Created attachment 36275 [details]
> wide-shift-64.c.219r.combine
> 
> The new gcc.dg/wide-shift-64.c testcase FAILs on SPARC for the 64-bit
> multilib
> only:
> 
> FAIL: gcc.dg/wide-shift-64.c scan-rtl-dump-not combine "ior"
> 
> I'm attaching the dump.

Rainer,

  I am trying to reproduce this on my cross environment while I can't.

  And searching in your dump file, I haven't found "ior" so the testcase should
have passed. 

  Can you please have a quick looks at the compile options used when testing
this testcase in your multi-lib environment, then I can reproduce in my local
sparc x86 cross env where I only have cc1 configured with --target=sparc-linux.

  Thanks.

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Jiong Wang <jiwang at gcc dot gnu.org> ---
> (In reply to Rainer Orth from comment #0)
>> Created attachment 36275 [details]
>> wide-shift-64.c.219r.combine
>> 
>> The new gcc.dg/wide-shift-64.c testcase FAILs on SPARC for the 64-bit
>> multilib
>> only:
>> 
>> FAIL: gcc.dg/wide-shift-64.c scan-rtl-dump-not combine "ior"
>> 
>> I'm attaching the dump.
>
> Rainer,
>
>   I am trying to reproduce this on my cross environment while I can't.
>
>   And searching in your dump file, I haven't found "ior" so the testcase should
> have passed. 

I just noticed I must have been dreaming when submitting this bug
report: it's the *32-bit* case that fails, not the 64-bit one.  I'm
attaching the correct dump this time.

>   Can you please have a quick looks at the compile options used when testing
> this testcase in your multi-lib environment, then I can reproduce in my local
> sparc x86 cross env where I only have cc1 configured with --target=sparc-linux.

cc1 is invoked like this for a 32-bit-default configuration:

$ cc1 -quiet wide-shift-64.c -mcpu=v9 -O2 -fdump-rtl-combine -o wide-shift-64.s

        Rainer

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #36275|0                           |1
        is obsolete|                            |

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 36290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36290&action=edit
wide-shift-64.c.219r.combine

32-bit dump

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
> cc1 is invoked like this for a 32-bit-default configuration:
> 
> $ cc1 -quiet wide-shift-64.c -mcpu=v9 -O2 -fdump-rtl-combine -o
> wide-shift-64.s
> 
> 	Rainer

Thanks, I basically understand where is the problem. By some option combination
sparc will enable target private wide shift pattern to override the middle-end
generic optimization, as the generic optimization honor target private
mechanism by the follow checking at expr.c:

             && ! have_insn_for (ASHIFT, mode)  

although the target private wide shift generate worse code.

I can't reproduce this issue by the following configure on trunk

../gcc-git-official/configure --enable-tls --target=sparc-linux
--enable-languages=c,c++

While after search sparc source code, I found sparc defined target private wide
shift, but it's only enabled when "TARGET_ARCH64 || TARGET_V8PLUS", then only
used when "! TARGET_ARCH64"

(define_expand "ashldi3"
  "TARGET_ARCH64 || TARGET_V8PLUS"
{
  if (! TARGET_ARCH64)

So, the testcase failed when I pass -mv8plus and -mcpu=v9 at the same time
which enable sparc target wide shift under 32bit.

[FAIL]./cc1 -quiet wide-shift-64.c -O2 -fdump-rtl-combine -nostdinc -mv8plus
-mcpu=v9

Jeff was suggesting we add cost check in generic code to make better decision
whether generic code should honor target private pattern.

Currently, I think we can just skip sparc for this testcase as I haven't found
good way in dejagnu to just skip when "-mv8plus" specified.
>From gcc-bugs-return-496278-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 03 10:38:36 2015
Return-Path: <gcc-bugs-return-496278-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 93391 invoked by alias); 3 Sep 2015 10:38:36 -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 91482 invoked by uid 48); 3 Sep 2015 10:38:33 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
Date: Thu, 03 Sep 2015 10:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.2.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-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67442-4-a3AeqXiNTH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67442-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67442-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: 2015-09/txt/msg00256.txt.bz2
Content-length: 798

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Assert triggers through

/space/rguenther/src/svn/trunk2/gcc/testsuite/g++.dg/tree-ssa/pr49911.C:8:22:
internal compiler error: in wide_int_to_tree, at tree.c:1398^M
0xf49a69 wide_int_to_tree(tree_node*,
generic_wide_int<wide_int_ref_storage<false> > const&)^M
        /space/rguenther/src/svn/trunk2/gcc/tree.c:1398^M
0xcab4e4 set_min_and_max_values_for_integral_type(tree_node*, int, signop)^M
        /space/rguenther/src/svn/trunk2/gcc/stor-layout.c:2645^M
0x62c701 finish_enum_value_list(tree_node*)^M
        /space/rguenther/src/svn/trunk2/gcc/cp/decl.c:13267^M

-fstrict-enums related.  set_min_and_max_values_for_integral_type
doesn't handle differing sgn correctly.

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[jiwang at gcc dot gnu.org]

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

--- Comment #5 from Jiong Wang <jiwang at gcc dot gnu.org> ---
Author: jiwang
Date: Thu Sep 10 10:37:17 2015
New Revision: 227629

URL: https://gcc.gnu.org/viewcvs?rev=227629&root=gcc&view=rev
Log:
[Patch/expand] Cost instruction sequences when doing left wide shift

Patch background details:

    https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01147.html

gcc/
  PR rtl-optimization/67421
  * expr.c (expand_expr_real_2): Cost instrcution sequences when doing left
wide
  shift tranformation.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c

[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs

[jiwang at gcc dot gnu.org]

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

Jiong Wang <jiwang at gcc dot gnu.org> changed:

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

--- Comment #6 from Jiong Wang <jiwang at gcc dot gnu.org> ---
fixed