[Bug target/65368] New: _bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[Bug target/65368] New: _bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jamrial at gmail dot com]

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

            Bug ID: 65368
           Summary: _bzhi_u32 intrinsic generates incorrect code when -O1
                    or above is specified and index is an immediate
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamrial at gmail dot com

The code generated is a simple AND instruction that zeroes the high bits based
on the index value starting from the highest bit rather than the lowest.

Sample program:

------
#include <stdio.h>
#include <x86intrin.h>

int main(int argc, char **argv)
{
    unsigned int j = _bzhi_u32(atoi(argv[1]), 11);
    printf("%x\n", j);
    return 0;
}
------

compiled with "gcc -O1 -mbmi2 -std=c99 -o bzhi bzhi.c"

[jamrial@ArchVM~]$ ./bzhi 4294967295
1fffff

Disassemble is as follows

0000000000000000 <main>:
   0:   48 83 ec 08             sub    rsp,0x8
   4:   48 8b 7e 08             mov    rdi,QWORD PTR [rsi+0x8]
   8:   ba 0a 00 00 00          mov    edx,0xa
   d:   be 00 00 00 00          mov    esi,0x0
  12:   e8 00 00 00 00          call   17 <main+0x17>
  17:   89 c6                   mov    esi,eax
  19:   81 e6 ff ff 1f 00       and    esi,0x1fffff
  1f:   bf 00 00 00 00          mov    edi,0x0
  24:   b8 00 00 00 00          mov    eax,0x0
  29:   e8 00 00 00 00          call   2e <main+0x2e>
  2e:   b8 00 00 00 00          mov    eax,0x0
  33:   48 83 c4 08             add    rsp,0x8
  37:   c3                      ret



compiled with "gcc -mbmi2 -std=c99 -o bzhi bzhi.c"

[jamrial@ArchVM~]$ ./bzhi 4294967295
7ff

Disassemble is as follows

0000000000000000 <main>:
   0:   55                      push   rbp
   1:   48 89 e5                mov    rbp,rsp
   4:   48 83 ec 20             sub    rsp,0x20
   8:   89 7d ec                mov    DWORD PTR [rbp-0x14],edi
   b:   48 89 75 e0             mov    QWORD PTR [rbp-0x20],rsi
   f:   48 8b 45 e0             mov    rax,QWORD PTR [rbp-0x20]
  13:   48 83 c0 08             add    rax,0x8
  17:   48 8b 00                mov    rax,QWORD PTR [rax]
  1a:   48 89 c7                mov    rdi,rax
  1d:   e8 00 00 00 00          call   22 <main+0x22>
  22:   89 45 f8                mov    DWORD PTR [rbp-0x8],eax
  25:   c7 45 f4 0b 00 00 00    mov    DWORD PTR [rbp-0xc],0xb
  2c:   8b 45 f4                mov    eax,DWORD PTR [rbp-0xc]
  2f:   c4 e2 78 f5 45 f8       bzhi   eax,DWORD PTR [rbp-0x8],eax
  35:   89 45 fc                mov    DWORD PTR [rbp-0x4],eax
  38:   8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
  3b:   89 c6                   mov    esi,eax
  3d:   bf 00 00 00 00          mov    edi,0x0
  42:   b8 00 00 00 00          mov    eax,0x0
  47:   e8 00 00 00 00          call   4c <main+0x4c>
  4c:   b8 00 00 00 00          mov    eax,0x0
  51:   c9                      leave
  52:   c3                      ret

When the index is not an immediate the actual bzhi instruction is always used
(with or without -Ox flags), and the result is the expected one.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-10
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org
   Target Milestone|---                         |4.8.5
            Summary|_bzhi_u32 intrinsic         |[4.8/4.9/5
                   |generates incorrect code    |Regression]_bzhi_u32
                   |when -O1 or above is        |intrinsic generates
                   |specified and index is an   |incorrect code when -O1 or
                   |immediate                   |above is specified and
                   |                            |index is an immediate
     Ever confirmed|0                           |1

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 35000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35000&action=edit
gcc5-pr65368.patch

The problem is that the RTL pattern for bzhi doesn't really match what the
instruction does.
Attached is an attempt to model what the instruction does and still let combine
put memory operands into the insn.
Wonder how many other bmi/bmi2 instructions have similar problems.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)

> Wonder how many other bmi/bmi2 instructions have similar problems.

Looking through i386.md file, it looks others are OK, although it is possible
to implement bmi_bextr with zero_extract RTX (removing one unspec).
>From gcc-bugs-return-479923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 09:06:37 2015
Return-Path: <gcc-bugs-return-479923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15851 invoked by alias); 10 Mar 2015 09:06:37 -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 15714 invoked by uid 48); 10 Mar 2015 09:06:30 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/64998] -shared -static-libasan does not actually link libasan
Date: Tue, 10 Mar 2015 09:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: y.gribov 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: cc
Message-ID: <bug-64998-4-5fekwjysNr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64998-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64998-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-03/txt/msg01067.txt.bz2
Content-length: 489

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

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y.gribov at samsung dot com

--- Comment #1 from Yury Gribov <y.gribov at samsung dot com> ---
No, with -static-libasan the runtime only gets linked into executable by
design. I think this is not a bug.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For zero_extract RTL we require that the POS and LEN arguments are in the right
ranges, while bextr allows any values, and either uses 0 for bits outside of
the original operand and for LEN uses umin (len, <bitsize>).

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 35000 [details]
> gcc5-pr65368.patch
> 
> The problem is that the RTL pattern for bzhi doesn't really match what the
> instruction does.
> Attached is an attempt to model what the instruction does and still let
> combine put memory operands into the insn.

+      (zero_extract:SWI48
+        (match_operand:SWI48 1 "nonimmediate_operand")
+        (umin:SWI48
+          (and:SWI48 (match_operand:SWI48 2 "register_operand")
+             (const_int 255))
+          (match_dup 3))
+        (const_int 0)))

Do we really need to complicate the insn this far? I'd say that:

      (zero_extract:SWI48
        (match_operand:SWI48 1 "nonimmediate_operand")
        (match_operand:SWI48 2 "register_operand")
        (const_int 0))

should do the trick. x86 is !SHIFT_COUNT_TRUNCATED target, so combine should
not be too creative here.

(I don't have haswell to play with, so the above is just "thinking loud"...).
>From gcc-bugs-return-479932-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 09:26:03 2015
Return-Path: <gcc-bugs-return-479932-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 91213 invoked by alias); 10 Mar 2015 09:26: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 91189 invoked by uid 48); 10 Mar 2015 09:25:59 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/65371] arm loop with volatile variable
Date: Tue, 10 Mar 2015 09:26: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: enhancement
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: component
Message-ID: <bug-65371-4-sAo8XYNBWb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65371-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65371-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-03/txt/msg01076.txt.bz2
Content-length: 741

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
On x86 I see

func:
.LFB0:
        .cfi_startproc
        movq    67112960, %rax
        orq     $65536, %rax
        movq    %rax, 67112960
.L2:
        movq    67112960, %rax
        testl   $131072, %eax
        je      .L2
        movq    67112960, %rax
        orq     $16777216, %rax
        movq    %rax, 67112960
        ret

not very optimal for -Os either.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #3)
> For zero_extract RTL we require that the POS and LEN arguments are in the
> right ranges, while bextr allows any values, and either uses 0 for bits
> outside of the original operand and for LEN uses umin (len, <bitsize>).

Ah, thanks, this explains my question from Comment #4.

Speculating a bit further, is BZHI just a special case of BEXTR, where start =
0 (I'm referring to [1]). It would be nice to make these insn as general as
possible, so combine will have a chance here.

[1] http://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets
>From gcc-bugs-return-479935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 09:33:43 2015
Return-Path: <gcc-bugs-return-479935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 129953 invoked by alias); 10 Mar 2015 09:33:43 -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 129912 invoked by uid 48); 10 Mar 2015 09:33:40 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65376] LTO prevents use of fmadd
Date: Tue, 10 Mar 2015 09:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto, missed-optimization
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: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget cf_known_to_fail
Message-ID: <bug-65376-4-tUwDpB6EkT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65376-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65376-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-03/txt/msg01079.txt.bz2
Content-length: 442

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64
      Known to fail|4.8.3, 4.9.2, 5.0           |

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Err, no.  Works on x86_64.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > For zero_extract RTL we require that the POS and LEN arguments are in the
> > right ranges, while bextr allows any values, and either uses 0 for bits
> > outside of the original operand and for LEN uses umin (len, <bitsize>).
> 
> Ah, thanks, this explains my question from Comment #4.
> 
> Speculating a bit further, is BZHI just a special case of BEXTR, where start
> = 0 (I'm referring to [1]). It would be nice to make these insn as general
> as possible, so combine will have a chance here.
> 
> [1] http://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets

To some extent BZHI is a special case of BEXTR, but I'm afraid any
generalization is much harder due to the weirdo encoding of the operands,
unless both the START and LEN are CONST_INTs (and if they are constants, it is
questionable if BEXTR or BZHI are the best instructions to use, because both
take just register for the LEN or START/LEN pair, so one would need to set some
register to a constant and then perform BEXTR/BZHI, so two instructions, while
there is always the option to perform AND and right shift (or right shift and
AND).
>From gcc-bugs-return-479940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 09:51:52 2015
Return-Path: <gcc-bugs-return-479940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6028 invoked by alias); 10 Mar 2015 09:51:51 -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 3710 invoked by uid 48); 10 Mar 2015 09:51:48 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
Date: Tue, 10 Mar 2015 09:51: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: 4.3.4
X-Bugzilla-Keywords: compile-time-hog, memory-hog
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:
Message-ID: <bug-44563-4-tUB9EeaPL5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-44563-4@http.gcc.gnu.org/bugzilla/>
References: <bug-44563-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-03/txt/msg01084.txt.bz2
Content-length: 423

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder why we have split_bb_on_noreturn_calls in cfg-cleanup rather than in
fixup_cfg.  It's quite expensive, walking all stmts and calling
gimple_call_noreturn_p which is very expensive.  We fixup noreturn calls in
fixup cfg so I wonder why we have this leftover in cfgcleanup...  testing
removal.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[ubizjak at gmail dot com]

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

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

> To some extent BZHI is a special case of BEXTR, but I'm afraid any
> generalization is much harder due to the weirdo encoding of the operands,
> unless both the START and LEN are CONST_INTs (and if they are constants, it
> is questionable if BEXTR or BZHI are the best instructions to use, because
> both take just register for the LEN or START/LEN pair, so one would need to
> set some register to a constant and then perform BEXTR/BZHI, so two
> instructions, while there is always the option to perform AND and right
> shift (or right shift and AND).

Probably I didn't form the question in the right way - I was trying to point
out, if we also describe BEXTR without unspec (in a similar way as your
proposed patch describes BZHI), then combine will be able to propagate eventual
immediates to the insn, and in this case reduce BEXTR with START=0 and LEN=n to
an AND.
>From gcc-bugs-return-479942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 09:55:46 2015
Return-Path: <gcc-bugs-return-479942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20852 invoked by alias); 10 Mar 2015 09:55:46 -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 20788 invoked by uid 48); 10 Mar 2015 09:55:42 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/65367] [5 Regression] indefinite loop occurs with sanitize enabled and certain optimization options
Date: Tue, 10 Mar 2015 09:55: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-65367-4-cPem8TSRuy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65367-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65367-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-03/txt/msg01086.txt.bz2
Content-length: 491

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r220641.  I'll take a look.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[ubizjak at gmail dot com]

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

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

> Probably I didn't form the question in the right way - I was trying to point
> out, if we also describe BEXTR without unspec (in a similar way as your
> proposed patch describes BZHI), then combine will be able to propagate
> eventual immediates to the insn, and in this case reduce BEXTR with START=0
> and LEN=n to an AND.

To answer my own question: It isn't feasible. BEXTR indeed has weird operand
encoding [1], involving "control operand" with special meaning.

[1] http://www.felixcloutier.com/x86/BEXTR.html
>From gcc-bugs-return-479944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 10 10:08:28 2015
Return-Path: <gcc-bugs-return-479944-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104772 invoked by alias); 10 Mar 2015 10:08:28 -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 104694 invoked by uid 48); 10 Mar 2015 10:08:24 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65370] [5 Regression] r213519  causes: error: redeclaration of 'template... may not have default arguments [-fpermissive]
Date: Tue, 10 Mar 2015 10:08: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: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc short_desc
Message-ID: <bug-65370-4-YZx2rIPLuU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65370-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65370-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-03/txt/msg01088.txt.bz2
Content-length: 831

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot com
            Summary|[5 Regression] rejects      |[5 Regression] r213519
                   |valid code on               |causes: error:
                   |powerpc64le-linux-gnu       |redeclaration of
                   |                            |'template... may not have
                   |                            |default arguments
                   |                            |[-fpermissive]

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Started with r213519.

[Bug target/65368] [4.8/4.9/5 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Mar 10 21:03:21 2015
New Revision: 221335

URL: https://gcc.gnu.org/viewcvs?rev=221335&root=gcc&view=rev
Log:
    PR target/65368
    * config/i386/i386.md (bmi2_bzhi_<mode>3): Removed define_insn,
    new define_expand.
    (*bmi2_bzhi_<mode>3, *bmi2_bzhi_<mode>3_1): New define_insns.

    * gcc.target/i386/bmi2-bzhi-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md
    trunk/gcc/testsuite/ChangeLog

[Bug target/65368] [4.8/4.9 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.8/4.9/5                  |[4.8/4.9
                   |Regression]_bzhi_u32        |Regression]_bzhi_u32
                   |intrinsic generates         |intrinsic generates
                   |incorrect code when -O1 or  |incorrect code when -O1 or
                   |above is specified and      |above is specified and
                   |index is an immediate       |index is an immediate

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far, backports will follow soon.

[Bug target/65368] [4.8/4.9 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jun  3 15:26:15 2015
New Revision: 224085

URL: https://gcc.gnu.org/viewcvs?rev=224085&root=gcc&view=rev
Log:
        Backported from mainline
        2015-03-10  Jakub Jelinek  <jakub@redhat.com>

        PR target/65368
        * config/i386/i386.md (bmi2_bzhi_<mode>3): Removed define_insn,
        new define_expand.
        (*bmi2_bzhi_<mode>3, *bmi2_bzhi_<mode>3_1): New define_insns.

        * gcc.target/i386/bmi2-bzhi-2.c: New test.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.md
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/65368] [4.8/4.9 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jun  3 21:34:36 2015
New Revision: 224103

URL: https://gcc.gnu.org/viewcvs?rev=224103&root=gcc&view=rev
Log:
        Backported from mainline
        2015-03-10  Jakub Jelinek  <jakub@redhat.com>

        PR target/65368
        * config/i386/i386.md (bmi2_bzhi_<mode>3): Removed define_insn,
        new define_expand.
        (*bmi2_bzhi_<mode>3, *bmi2_bzhi_<mode>3_1): New define_insns.

        * gcc.target/i386/bmi2-bzhi-2.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/bmi2-bzhi-2.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.md
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/65368] [4.8/4.9 Regression]_bzhi_u32 intrinsic generates incorrect code when -O1 or above is specified and index is an immediate

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now for 4.8+.