[Bug c/57896] New: ICE in in expand_expr_real_2

[Bug c/57896] New: ICE in in expand_expr_real_2

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

            Bug ID: 57896
           Summary: ICE in in expand_expr_real_2
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zeccav at gmail dot com

Created attachment 30504
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30504&action=edit
C code causing an ICE in  expand_expr_real_2

The attached code causes an ICE in in expand_expr_real_2,
This is from testsuite/gcc.target/vperm-v4si-2.c
The ICE is maybe due to wrong index at cfgexpand.c:4329
I put 

 gcc_assert ((int)  ((enum tree_code) (t)->base.code) < sizeof_tree_code_type);

before "if (IS_TYPE_OR_DECL_P (t))" and I got the backtrace in the bottom
of the attached file. 
I defined sizeof_tree_code_type in tree.h and tree.c

const int sizeof_tree_code_type=sizeof(tree_code_type);

I am sorry I was not able to produce a shorter test case.

[Bug c/57896] ICE in in expand_expr_real_2

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> ---
I can reproduce the ICE with gcc-4.8.1 and gcc-4.8-20130711 on x86_64-linux,
using options -O0 -m64.  At higher optimization levels or with -m32 the ICE
doesn't occur.  gcc-4.9-20130714 doesn't ICE.

[Bug c/57896] ICE in in expand_expr_real_2

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

Mikael Pettersson <mikpe at it dot uu.se> changed:

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

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> ---
The ICE was fixed for 4.9/trunk by Marc Glisse's "Property for vector lowering"
patch in r196890, originally described here:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html

Backporting r196890 to current 4.8 branch fixes the ICE there too, but that may
or may not be the appropriate fix.  Author CC:d.

[Bug c/57896] ICE in in expand_expr_real_2

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-15
     Ever confirmed|0                           |1

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Mikael Pettersson from comment #2)
> The ICE was fixed for 4.9/trunk by Marc Glisse's "Property for vector
> lowering" patch in r196890, originally described here:
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html

Really? Ah, right, I moved a pass in that patch, that's probably what matters.

> Backporting r196890 to current 4.8 branch fixes the ICE there too, but that
> may or may not be the appropriate fix.  Author CC:d.

I doubt that backporting the whole thing makes sense. If moving the pass really
helps, that part maybe... But we first need to understand what is going on, the
patch is likely just hiding the real bug.

[Bug c/57896] ICE in in expand_expr_real_2

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 30506
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30506&action=edit
Slightly reduced testcase

The bug disappears if we remove some unused typedefs, or the preprocessor line
indications, or... valgrind doesn't report anything though. I have no idea what
kind of corruption is going on.

[Bug c/57896] ICE in in expand_expr_real_2

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #5 from Vittorio Zecca <zeccav at gmail dot com> ---
Trying your vastly reduced test case, 152 lines vs 3057 of my original
test case, I am getting
an ICE in convert_move, at expr.c:452.
The following is my backtrace:
<command-line>: In function ‘__get_cpuid_max’:
<command-line>:1:1: internal compiler error: in convert_move, at expr.c:452
0x62ee1b convert_move(rtx_def*, rtx_def*, int)
    ../../gcc-4.8.1/gcc/expr.c:451
0x62f098 convert_modes(machine_mode, machine_mode, rtx_def*, int)
    ../../gcc-4.8.1/gcc/expr.c:781
0x9939dd ix86_legitimize_address
    ../../gcc-4.8.1/gcc/config/i386/i386.c:13276
0x619880 memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
    ../../gcc-4.8.1/gcc/explow.c:461
0x60b5a4 change_address_1
    ../../gcc-4.8.1/gcc/emit-rtl.c:2021
0x671808 assign_parm_setup_stack
    ../../gcc-4.8.1/gcc/function.c:3234
0x671808 assign_parms
    ../../gcc-4.8.1/gcc/function.c:3416
0x67355f expand_function_start(tree_node*)
    ../../gcc-4.8.1/gcc/function.c:4824
0x58ac99 gimple_expand_cfg
    ../../gcc-4.8.1/gcc/cfgexpand.c:4552

Adding option -m32 I get ICE in ix86_expand_prologue, at
config/i386/i386.c:10559
>From gcc-bugs-return-426250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 16 01:59:26 2013
Return-Path: <gcc-bugs-return-426250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10812 invoked by alias); 16 Jul 2013 01:59:25 -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 8566 invoked by uid 48); 16 Jul 2013 01:57:22 -0000
From: "raj.khem at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
Date: Tue, 16 Jul 2013 01:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: raj.khem 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-57717-4-hXqPGGGHw0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57717-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57717-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: 2013-07/txt/msg00757.txt.bz2
Content-length: 1366

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW717

--- Comment #6 from Khem Raj <raj.khem at gmail dot com> ---
here is another case which fails before suggested patch and also after the
patch

void foo()
{

 double a[20000];
 double b = 3.1L / 20000;
}

Here is result below after applying the patch in comment #3

$ ./gcc/cc1 ~/a.c
 foo
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> <visibility> <early_local_cleanups> <*free_inline_summary>
<emutls> <whole-program>Assembling functions:
 foo
/homes/kraj/a.c: In function 'foo':
/homes/kraj/a.c:6:1: internal compiler error: in change_address_1, at
emit-rtl.c:1955
 }
 ^
0x5d7dd0 change_address_1
        ../../gcc/gcc/emit-rtl.c:1955
0x5dad82 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
        ../../gcc/gcc/emit-rtl.c:2087
0x61ac98 alter_subreg(rtx_def**, bool)
        ../../gcc/gcc/final.c:3062
0x61aed9 cleanup_subreg_operands(rtx_def*)
        ../../gcc/gcc/final.c:3008
0x7e80b6 reload(rtx_def*, int)
        ../../gcc/gcc/reload1.c:1240
0x70227b do_reload
        ../../gcc/gcc/ira.c:4701
0x70227b rest_of_handle_reload
        ../../gcc/gcc/ira.c:4801
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c/57896] ICE in in expand_expr_real_2

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #6 from Vittorio Zecca <zeccav at gmail dot com> ---
The following is a shorter version of Marc's test case:

__get_cpuid_max (unsigned int __ext, unsigned int *__sig) {
  unsigned __edx;
  __cpuid (0, 0, 0, 0, __edx);
}
int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int
*__ebx, unsigned int *__ecx, unsigned int *__edx) {
fail: return 0;
}
typedef int IV __attribute__((vector_size(16)));
typedef union {
  int s;
  IV v;
} U;
static U i[2], b, c;
void check0(void) {
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 0, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 0, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 0, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 0, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 1, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 1, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 1, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 1, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 4, 0, 0});
  (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0);
}
void check2(void) {
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 0, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 0, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 0, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 0, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 1, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 1, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 1, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 1, 4, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 0, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 0, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 0, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 0, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 1, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 1, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 1, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 1, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 4, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 4, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 4, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 4, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 5, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 5, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 5, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 5, 5, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 0, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 0, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 0, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 0, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 1, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 1, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 1, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 1, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 6, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 6, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 6, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 6, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 7, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 7, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 7, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 7, 6, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 0, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 0, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 0, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 0, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 1, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 1, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 1, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  7, 1, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 6, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 6, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  6, 6, 7, 0});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 3, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 3, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 4, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 4, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  2, 4, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  3, 4, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  0, 5, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  1, 5, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  2, 5, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  3, 5, 4, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 0, 5, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 0, 5, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  4, 1, 5, 4});
  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){  5, 1, 5, 4});
}

As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put

printf("\nexpr.c:6995 value->code=%d NUM_RTX_CODE=%d\n",(int)
value->code,NUM_RTX_CODE);
gcc_assert((int) value->code < NUM_RTX_CODE);

and I get an ICE there because value->code is 34816 and NUM_RTX_CODE is 145

Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int) value->code]
but the array rtx_class has only NUM_RTX_CODE elements.
However, I do not know how this is relevant to this issue.

[Bug c/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |4.8.4
            Summary|ICE in expand_expr_real_2   |[4.8 Regression] ICE in
                   |                            |expand_expr_real_2

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Currently, I see ICE only with 4.8:

./cc1 xx.c -m32 -quiet -march=x86-64

In function ‘__get_cpuid_max’:
Segmentation fault
 }
 ^
0xa3924f crash_signal
    /home/marek/src/gcc/gcc/toplev.c:332
0x11fc5fe pp_base_string(pretty_print_info*, char const*)
    /home/marek/src/gcc/gcc/pretty-print.c:835
0x11fd0a4 pp_base_format(pretty_print_info*, text_info*)
    /home/marek/src/gcc/gcc/pretty-print.c:496
0x11fa7ac diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
    /home/marek/src/gcc/gcc/diagnostic.c:755
0x11faabb internal_error(char const*, ...)
    /home/marek/src/gcc/gcc/diagnostic.c:1094
0x9b9aa7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
    /home/marek/src/gcc/gcc/rtl.c:773
0xc93a5d pro_epilogue_adjust_stack
    /home/marek/src/gcc/gcc/config/i386/i386.c:9517
0xca0b20 ix86_expand_prologue()
    /home/marek/src/gcc/gcc/config/i386/i386.c:10491
0xd645da gen_prologue()
    /home/marek/src/gcc/gcc/config/i386/i386.md:11810
0x80dc79 thread_prologue_and_epilogue_insns
    /home/marek/src/gcc/gcc/function.c:5949
0x8110a2 rest_of_handle_thread_prologue_and_epilogue
    /home/marek/src/gcc/gcc/function.c:6973
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-444171-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 08:12:27 2014
Return-Path: <gcc-bugs-return-444171-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28083 invoked by alias); 19 Feb 2014 08:12:27 -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 28016 invoked by uid 48); 19 Feb 2014 08:12:22 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2
Date: Wed, 19 Feb 2014 08:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: mpolacek 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: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: component
Message-ID: <bug-57896-4-Hopx8I0tUA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57896-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57896-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-02/txt/msg01928.txt.bz2
Content-length: 381

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Not a C FE issue.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Vittorio Zecca from comment #6)

> As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put
>  
> printf("\nexpr.c:6995 value->code=%d NUM_RTX_CODE=%d\n",(int)
> value->code,NUM_RTX_CODE);
> gcc_assert((int) value->code < NUM_RTX_CODE);
> 
> and I get an ICE there because value->code is 34816 and NUM_RTX_CODE is 145
> 
> Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int)
> value->code]
> but the array rtx_class has only NUM_RTX_CODE elements.
> However, I do not know how this is relevant to this issue.

This one points to infrastructure problem.

Adding a debug patch:

--cut here--
Index: explow.c
===================================================================
--- explow.c    (revision 207910)
+++ explow.c    (working copy)
@@ -186,8 +186,13 @@ plus_constant (enum machine_mode mode, rtx x, HOST
     }

   if (c != 0)
-    x = gen_rtx_PLUS (mode, x, GEN_INT (c));
+    {
+      rtx z = GEN_INT (c);
+      printf ("cccccc, %li\n", c);
+      debug_rtx (z);

+      x = gen_rtx_PLUS (mode, x, z);
+    }
   if (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF)
     return x;
   else if (all_constant)
--cut here--

~/gcc-build-48/gcc/cc1 pr57896.c

...
 __get_cpuidcccccc, -4
(const_int -4 [0xfffffffffffffffc])
cccccc, -16
(const_int -16 [0xfffffffffffffff0])
cccccc, -24
(const_int -24 [0xffffffffffffffe8])
cccccc, -32
(const_int -32 [0xffffffffffffffe0])
cccccc, -40
(??? bad code 47104
)

pr57896.c: In function ‘__get_cpuid’:
pr57896.c:5:5: internal compiler error: in emit_move_insn_1, at expr.c:3437
 int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int
*__ebx, unsigned int *__ecx, unsigned int *__edx) {
     ^
0x62d74d emit_move_insn_1(rtx_def*, rtx_def*)
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3437
0x62d7b5 emit_move_insn(rtx_def*, rtx_def*)
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3535

Please note that the debug patch only encloses GEN_INT (...)
>From gcc-bugs-return-444241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:03:54 2014
Return-Path: <gcc-bugs-return-444241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15188 invoked by alias); 19 Feb 2014 18:03:54 -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 14781 invoked by uid 48); 19 Feb 2014 18:03:48 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/37743] Bogus printf format warning with __builtin_bswap32.
Date: Wed, 19 Feb 2014 18:03: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: attachments.created
Message-ID: <bug-37743-4-yDecQATOVD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-37743-4@http.gcc.gnu.org/bugzilla/>
References: <bug-37743-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-02/txt/msg01998.txt.bz2
Content-length: 299

http://gcc.gnu.org/bugzilla/show_bug.cgi?id7743

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2173&actioníit
gcc49-pr37743.patch

Untested fix.  The deprecation can hopefully be done separately.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Vittorio Zecca from comment #5)

> Adding option -m32 I get ICE in ix86_expand_prologue, at
> config/i386/i386.c:10559

I can confirm this with:

gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910] (GCC)

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10539
 }
 ^
0x98fdf5 ix86_expand_prologue()
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10539
0xa1ce5a gen_prologue()
       
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973

The output from the debug patch doesn't look suspicious, so this looks like a
real bug to me. Can someone please bisect which commit fixed/hid this bug?
>From gcc-bugs-return-444243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:10:40 2014
Return-Path: <gcc-bugs-return-444243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32414 invoked by alias); 19 Feb 2014 18:10:40 -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 32374 invoked by uid 55); 19 Feb 2014 18:10:37 -0000
From: "hjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60207] Wrong TFmode check in construct_container
Date: Wed, 19 Feb 2014 18:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl 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:
Message-ID: <bug-60207-4-SdCZioxKtE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60207-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60207-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-02/txt/msg02000.txt.bz2
Content-length: 487

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`207

--- Comment #2 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Wed Feb 19 18:10:04 2014
New Revision: 207913

URL: http://gcc.gnu.org/viewcvs?rev 7913&root=gcc&view=rev
Log:
Remove TFmode check for X86_64_INTEGER_CLASS

    PR target/60207
    * config/i386/i386.c (construct_container): Remove TFmode check
    for X86_64_INTEGER_CLASS.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Vittorio Zecca from comment #5)
> 
> > Adding option -m32 I get ICE in ix86_expand_prologue, at
> > config/i386/i386.c:10559
> 
> I can confirm this with:
> 
> gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910]
> (GCC)
> 
> ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

This is the same problem, as confirmed by following debug patch:

--cut here--
Index: i386.c
===================================================================
--- i386.c      (revision 207912)
+++ i386.c      (working copy)
@@ -10449,8 +10449,12 @@ ix86_expand_prologue (void)
   else if (!ix86_target_stack_probe ()
           || frame.stack_pointer_offset < CHECK_STACK_LIMIT)
     {
+      rtx x = GEN_INT (-allocate);
+
+      printf ("\nTestP1 %li\n", -allocate);
+      debug_rtx (x);
       pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
-                                GEN_INT (-allocate), -1,
+                                x, -1,
                                 m->fs.cfa_reg == stack_pointer_rtx);
     }
   else
@@ -10536,6 +10540,7 @@ ix86_expand_prologue (void)
                          gen_frame_mem (word_mode, t));
        }
     }
+  printf ("\nTestP2 %li %li\n", m->fs.sp_offset, frame.stack_pointer_offset);
   gcc_assert (m->fs.sp_offset == frame.stack_pointer_offset);

   /* If we havn't already set up the frame pointer, do so now.  */
--cut here--

GEN_INT (...) produces some non-sensical RTX, and INTVAL at the end of
pro_epilogue_adjust_stack chokes on it.

      m->fs.sp_offset = ooffset - INTVAL (offset);
      m->fs.sp_valid = valid;

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

...

TestP1 -56
(??? bad code 42752
)

TestP2 -139787679344504 64

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10544
 }
 ^
0x98fe35 ix86_expand_prologue()
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10544
0xa1ce9a gen_prologue()
       
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
        /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973
>From gcc-bugs-return-444250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:34:44 2014
Return-Path: <gcc-bugs-return-444250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29625 invoked by alias); 19 Feb 2014 18:34: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 29462 invoked by uid 48); 19 Feb 2014 18:34:40 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/37743] Bogus printf format warning with __builtin_bswap32.
Date: Wed, 19 Feb 2014 18:34: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: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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 resolution
Message-ID: <bug-37743-4-H9wiXCtT6s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-37743-4@http.gcc.gnu.org/bugzilla/>
References: <bug-37743-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-02/txt/msg02007.txt.bz2
Content-length: 650

http://gcc.gnu.org/bugzilla/show_bug.cgi?id7743

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

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.  That said, both testcases in this PR are inherently non-portable, on
some targets __builtin_bswap32 returns unsigned long, on most unsigned int,
could be even unsigned long long.  So, one should really use uint32_t and
PRIu32.

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jakub at redhat dot com
          Component|target                      |middle-end
            Version|4.8.1                       |4.8.3

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
Reconfirmed on 4.8.3 as "middle-end" catch-all bug.

Adding some CCs that might be interested in this PR.
>From gcc-bugs-return-444253-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:44:58 2014
Return-Path: <gcc-bugs-return-444253-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11105 invoked by alias); 19 Feb 2014 18:44:58 -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 11075 invoked by uid 48); 19 Feb 2014 18:44:55 -0000
From: "slayoo at staszic dot waw.pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
Date: Wed, 19 Feb 2014 18:44: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: slayoo at staszic dot waw.pl
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60267-4-f5iFV9VIYF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60267-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60267-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-02/txt/msg02010.txt.bz2
Content-length: 221

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`267

--- Comment #12 from Sylwester Arabas <slayoo at staszic dot waw.pl> ---
Thanks a lot! I'll try it as soon as it will get into Debian's gcc-snapshot
package.

Sylwester

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems like r196890 made this latent.

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #15)
> I'll have a look (unless you want to continue poking).

According to ChangeLogs, you have much more experience in this part, so I would
be much grateful if you can take it from here.
>From gcc-bugs-return-444318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 09:29:06 2014
Return-Path: <gcc-bugs-return-444318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15495 invoked by alias); 20 Feb 2014 09:29:06 -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 15470 invoked by uid 48); 20 Feb 2014 09:29:02 -0000
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60288] New: gccgo crashes compiling '*func_ptr(0)'
Date: Thu, 20 Feb 2014 09:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vogt at linux dot vnet.ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
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 attachments.created
Message-ID: <bug-60288-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-02/txt/msg02075.txt.bz2
Content-length: 3074

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`288

            Bug ID: 60288
           Summary: gccgo crashes compiling '*func_ptr(0)'
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: vogt at linux dot vnet.ibm.com

Created attachment 32179
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2179&actioníit
test program

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207936
138bc75d-0d04-0410-961f-82ee72b054a4

This program crashes gcc:

-- BEGIN
package main
func f(i int) int { return i }
func main() {
    g := f
    println(*&g(0))  // <-- compiles (see below)
    pg := &g
    println(*pg(0))  // <-- crash
}
-- END

Instead of producing an error message, gccgo crashes in line 7:

-- snip --
foo.go:7:11: error: expected function
  println(*pg(0))
           ^
go1: internal compiler error: in do_flatten, at
go/gofrontend/expressions.cc:3835
0x80151dc9 Unary_expression::do_flatten(Gogo*, Named_object*,
Statement_inserter*)
    ../../gcc/go/gofrontend/expressions.cc:3835
0x80196583 Expression::flatten(Gogo*, Named_object*, Statement_inserter*)
    ../../gcc/go/gofrontend/expressions.h:635
0x80196583 Flatten::expression(Expression**)
    ../../gcc/go/gofrontend/gogo.cc:2841
0x80152a75 Expression::traverse(Expression**, Traverse*)
    ../../gcc/go/gofrontend/expressions.cc:54
0x80152a75 Expression_list::traverse(Traverse*)
    ../../gcc/go/gofrontend/expressions.cc:15187
0x80152a75 Call_expression::do_traverse(Traverse*)
    ../../gcc/go/gofrontend/expressions.cc:9124
0x80152a75 Call_expression::do_traverse(Traverse*)
    ../../gcc/go/gofrontend/expressions.cc:9118
0x801965a3 Flatten::expression(Expression**)
    ../../gcc/go/gofrontend/gogo.cc:2837
0x80154d67 Expression::traverse(Expression**, Traverse*)
    ../../gcc/go/gofrontend/expressions.cc:54
0x80198ddf Flatten::statement(Block*, unsigned long*, Statement*)
    ../../gcc/go/gofrontend/gogo.cc:2797
0x801da0b3 Statement::traverse(Block*, unsigned long*, Traverse*)
    ../../gcc/go/gofrontend/statements.cc:43
0x8019c791 Block::traverse(Traverse*)
    ../../gcc/go/gofrontend/gogo.cc:4279
0x8019cca3 Function::traverse(Traverse*)
    ../../gcc/go/gofrontend/gogo.cc:3805
0x8019cca3 Flatten::function(Named_object*)
    ../../gcc/go/gofrontend/gogo.cc:2774
0x8019d071 Bindings::traverse(Traverse*, bool)
    ../../gcc/go/gofrontend/gogo.cc:5877
0x8019d81d Gogo::traverse(Traverse*)
    ../../gcc/go/gofrontend/gogo.cc:1466
0x8019d81d Gogo::flatten()
    ../../gcc/go/gofrontend/gogo.cc:2875
0x8018bb8d go_parse_input_files(char const**, unsigned int, bool, bool)
    ../../gcc/go/gofrontend/go.cc:126
-- snip --

As a side note, gccgo compiles line 5 without even as much as a
warning while golang treats this as an error:

  (golang) ./foo.go:5: cannot take the address of g(0)

So it looks like gccgo reads the expression as

  (*pg)(0)

while golang reads it as

  *(pg(0))

Not sure whether this is a bug in gccgo.

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
Somehow we get old_size = 0 in gen_reg_rtx. It is calculated as:

      int old_size = crtl->emit.regno_pointer_align_length;

Trivial patch that prevents this situation and fixes the problem. However, it
is not clear to me if crtl->emit.regno_pointer_align_length should start larger
than zero.

--cut here--
Index: emit-rtl.c
===================================================================
--- emit-rtl.c  (revision 207935)
+++ emit-rtl.c  (working copy)
@@ -903,6 +903,8 @@ gen_reg_rtx (enum machine_mode mode)
       char *tmp;
       rtx *new1;

+      if (old_size < 1)
+       old_size = 1;
       tmp = XRESIZEVEC (char, crtl->emit.regno_pointer_align, old_size * 2);
       memset (tmp + old_size, 0, old_size);
       crtl->emit.regno_pointer_align = (unsigned char *) tmp;
--cut here--
>From gcc-bugs-return-444322-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 09:59:06 2014
Return-Path: <gcc-bugs-return-444322-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31750 invoked by alias); 20 Feb 2014 09:59:06 -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 31479 invoked by uid 48); 20 Feb 2014 09:59:02 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60287] Various issues on -WformatDate: Thu, 20 Feb 2014 09:59: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus 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: cc
Message-ID: <bug-60287-4-CFveWMRPBe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60287-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60287-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-02/txt/msg02079.txt.bz2
Content-length: 2006

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`287

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Chengnian Sun from comment #0)
> 1) Besides "-Wformat=2", gcc accepts any option in the form of
> -Wformat=<number>
>    Based on the manual, gcc only accepts "-Wformat=2", and others such as
> "-Wformat=0,1, 3-9" should be invalid. Any undocumented behavior?


Well, -Wformat=0 disables all format warnings (not really documented) - and
should be equivalent to -Wno-format; "-Wformat=1" is equivalent to "-Wformat" -
and that is explicitly documented in the manual:
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-294

And -Wformat=2 is equivalent to -Wformat=1 plus additional warnings.

-Wformat=3 would be equivalent to -Wformat=2 plus additional (nonexisting)
options. And I think it currently acts as -Wformat=2, which should be fine as
well.

(Similar is: -O0, -O1, -O2, -O3; where some other compilers have -O4 - but GCC
doesn't and [I think it] treats it as -O3.)


> 2) Is the warning name "[-Wformat=]" in the warning message intended?

Yes - as one doesn't want to distinguish between "-Wformat=2" and
"-Wformat/-Wformat=1 -Wformat-security". In particular, "-Wformat-security"
requires "-Wformat=1" in addition, otherwise, it doesn't warn at all.

Thus, printing [-Wformat=] is way easier than to re-construct the exact option.




> 3) Is the column number information correct in the warning message? Should
> the warning refer to the location of the problematic argument, or the
> function call?

Well, the column number is correct - but pointing to either to the proper '%'
in the format string or to the argument would be better. - Like always, there
is room for improvement.

[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
And finally, it looks that expand_vector_operations doesn't call init_emit ().

Backtrace:

Breakpoint 1, gen_reg_rtx (mode=V4SImode) at
../../gcc-svn/branches/gcc-4_8-branch/gcc/emit-rtl.c:864
864       unsigned int align = GET_MODE_ALIGNMENT (mode);
(gdb) bt
#0  gen_reg_rtx (mode=V4SImode) at
../../gcc-svn/branches/gcc-4_8-branch/gcc/emit-rtl.c:864
#1  0x000000000098aa82 in expand_vec_perm_interleave2 (d=0x7fffffffc110) at
../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:39408
#2  0x000000000098b2d0 in ix86_expand_vec_perm_const_1 (d=0x7fffffffc110) at
../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:40464
#3  0x000000000098b847 in ix86_vectorize_vec_perm_const_ok (vmode=<optimized
out>, sel=<optimized out>)
    at ../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:40670
#4  0x000000000072cac2 in can_vec_perm_p (mode=V4SImode, variable=false,
sel=0x7fffffffc1b0 "\004")
    at ../../gcc-svn/branches/gcc-4_8-branch/gcc/optabs.c:6492
#5  0x00000000008ed774 in lower_vec_perm(struct {...} *) (gsi=0x7fffffffc280)
    at ../../gcc-svn/branches/gcc-4_8-branch/gcc/tree-vect-generic.c:1207
#6  0x00000000008f0d39 in expand_vector_operations () at
../../gcc-svn/branches/gcc-4_8-branch/gcc/tree-vect-generic.c:1489

where

p x_rtl.emit.regno_pointer_align_length
$2 = 0
>From gcc-bugs-return-444326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:19:30 2014
Return-Path: <gcc-bugs-return-444326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17280 invoked by alias); 20 Feb 2014 10:19:30 -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 17257 invoked by uid 48); 20 Feb 2014 10:19:26 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.
Date: Thu, 20 Feb 2014 10:19: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.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords target_milestone short_desc
Message-ID: <bug-60280-4-ijBthpMKYD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60280-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60280-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-02/txt/msg02083.txt.bz2
Content-length: 871

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`280

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Target Milestone|---                         |4.9.0
            Summary|gcc.target/arm/ivopts.c and |[4.9 Regression]
                   |gcc.target/arm/ivopts-2.c   |gcc.target/arm/ivopts.c and
                   |failed caused by preserving |gcc.target/arm/ivopts-2.c
                   |loop structure.             |failed caused by preserving
                   |                            |loop structure.

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, does it work in 4.8?  We preserve loops there as well (just not so early).

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The bug is in the backend, gen_reg_rtx shouldn't be called when init_emit has
not been called.

If one looks e.g. at tree-ssa-loop-ivopts.c or even
ix86_vectorize_vec_perm_const_ok, it avoids using gen_reg_rtx and instead uses
gen_raw_REG:
  d.target = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 1);
  d.op1 = d.op0 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 2);
  if (!d.one_operand_p)
    d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);
So, we should avoid calling gen_reg_rtx if d->testing_p, we can create
gen_raw_REG instead if really needed.  Let me skim through the routines.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, from quick skim of relevant routines that do gen_reg_rtx, I see:

gen_reg_rtx called only after if (d->testing_p) return true;, thus ok:
expand_vec_perm_blend
expand_vec_perm_pshufb
expand_vec_perm_palignr
expand_vec_perm_vpermq_perm_1
expand_vec_perm_vperm2f128
expand_vec_perm_vperm2f128_vblend
expand_vec_perm_2vperm2f128_vshuf
expand_vec_perm_vpshufb2_vpermq
expand_vec_perm_vpshufb2_vpermq_even_odd
expand_vec_perm_vpshufb4_vpermq2

Does not look at testing_p at all, not ok:
expand_vec_perm_pshufb2
expand_vec_perm_even_odd_1

Not ok:
expand_vec_perm_interleave2
expand_vec_perm_broadcast_1

So, I think we want to fix those 4 routines.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #21 from Uroš Bizjak <ubizjak at gmail dot com> ---
--cut here--
Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c  (revision 207935)
+++ config/i386/i386.c  (working copy)
@@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
   if (!d.one_operand_p)
     d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);

-  start_sequence ();
+  init_dummy_function_start ();
   ret = ix86_expand_vec_perm_const_1 (&d);
-  end_sequence ();
+  expand_dummy_function_end ();

   return ret;
 }
--cut here--

Jakub, what do you think about this patch?
>From gcc-bugs-return-444331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:53:34 2014
Return-Path: <gcc-bugs-return-444331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8515 invoked by alias); 20 Feb 2014 10:53:33 -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 8461 invoked by uid 48); 20 Feb 2014 10:53:29 -0000
From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.
Date: Thu, 20 Feb 2014 10:53: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.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker.cheng 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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60280-4-zqvy3ZK2yw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60280-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60280-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-02/txt/msg02088.txt.bz2
Content-length: 258

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`280

--- Comment #3 from bin.cheng <amker.cheng at gmail dot com> ---
I think 4_8 is ok for this case.  At least it doesn't have
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was
right.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #21)
> --- config/i386/i386.c  (revision 207935)
> +++ config/i386/i386.c  (working copy)
> @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
>    if (!d.one_operand_p)
>      d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);
>  
> -  start_sequence ();
> +  init_dummy_function_start ();
>    ret = ix86_expand_vec_perm_const_1 (&d);
> -  end_sequence ();
> +  expand_dummy_function_end ();
>  
>    return ret;
>  }
> --cut here--
> 
> Jakub, what do you think about this patch?

IMHO that is way too expensive.

So, say expand_vec_perm_interleave2 is only called with d->testing_p from
ix86_vectorize_vec_perm_const_ok, and thus I'd say something like:
  if (!d->testing_p)
    {
      dremap.target = gen_reg_rtx (dremap.vmode);
      dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
    }
  dfinal.op1 = dfinal.op0;
should fix expand_vec_perm_interleave2.  I think dfinal.op0 should have
dfinal.vmode already from the caller (we can easily perhaps gcc_checking_assert
double check it when testing the patch).
>From gcc-bugs-return-444334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:57:16 2014
Return-Path: <gcc-bugs-return-444334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11783 invoked by alias); 20 Feb 2014 10:57:16 -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 11718 invoked by uid 48); 20 Feb 2014 10:57:11 -0000
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60288] gccgo crashes compiling '*func_ptr(0)'
Date: Thu, 20 Feb 2014 10:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vogt at linux dot vnet.ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60288-4-RibpBO22rB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60288-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60288-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-02/txt/msg02091.txt.bz2
Content-length: 298

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`288

--- Comment #1 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
> So it looks like gccgo reads the expression as
>
>   (*pg)(0)
    ^^^^^^^^

I meant

->  (*(&g))(0)

> while golang reads it as
>
>   *(pg(0))
    ^^^^^^^^

->  *(&(g(0)))

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

> IMHO that is way too expensive.

Agreed.

Anyway, it looks you got this problem under control ;)
>From gcc-bugs-return-444336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 11:07:20 2014
Return-Path: <gcc-bugs-return-444336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18560 invoked by alias); 20 Feb 2014 11:07:19 -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 18521 invoked by uid 48); 20 Feb 2014 11:07:15 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60236] gfortran.dg/vect/pr32380.f fails on ARM
Date: Thu, 20 Feb 2014 11:07: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
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-60236-4-SA9cHIP9ad@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60236-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60236-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-02/txt/msg02093.txt.bz2
Content-length: 1631

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`236

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> This patch tries to solve the problem in a more general way.
> I wonder if one of you could try this patch on PowerPC?

Sorry for the late answer, but my G5 was buzzy regtesting. With the patch in
comment 5, tested with

make -k check-gfortran RUNTESTFLAGS="vect.exp=pr32380.f
--target_board=unix'{-m32,-m64}'"

I get


        === gfortran tests ==
Schedule of variations:
    unix/-m32
    unix/-m64

Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/vect.exp ...

        === gfortran Summary for unix/-m32 ==
# of expected passes        2
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/vect.exp ...

        === gfortran Summary for unix/-m64 ==
# of expected passes        2

        === gfortran Summary ==
# of expected passes        4
/opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran  version 4.9.0
20140218 (experimental) [trunk revision 207836p2] (GCC)

So the patch is OK for powerpc-apple-darwin9.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86
   Target Milestone|4.8.4                       |4.7.4
            Summary|[4.8 Regression] ICE in     |[4.7/4.8/4.9 Regression]
                   |expand_expr_real_2          |ICE in expand_expr_real_2
           Severity|minor                       |normal

--- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> ---
>From a quick view of expand_vec_perm_interleave2, the problem is latent on 4.9
and 4.7 branches. Probably more important than P3 due to data corruption, but
let RMs decide.
>From gcc-bugs-return-444338-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 11:34:39 2014
Return-Path: <gcc-bugs-return-444338-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5642 invoked by alias); 20 Feb 2014 11:34:38 -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 5615 invoked by uid 48); 20 Feb 2014 11:34:34 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60276] [4.7/4.8 Regression] -O3 autovectorizer breaks on a particular loop
Date: Thu, 20 Feb 2014 11:34: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.8.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60276-4-mCpSZjIMtr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60276-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60276-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-02/txt/msg02095.txt.bz2
Content-length: 469

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`276

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

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
It fails for me with trunk: r207224 works, but starting with r207225 it fails
again.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32180
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32180&action=edit
gcc48-pr57896.patch

So like this (4.8 version, untested)?  Uros, can you please double-check it?
The point is, if d->testing_p is true, we should do as few work as possible,
certainly not call any emit_insn or gen_reg_rtx, and as soon as we know we'll
certainly eventually return true, return it.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32181&action=edit
gcc49-pr57896.patch

Corresponding 4.9 version, which is somewhat different due to my? changes not
to emit subregs on the lhs when possible.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #27 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #25)
> Created attachment 32180 [details]
> gcc48-pr57896.patch
> 
> So like this (4.8 version, untested)?  Uros, can you please double-check it?
> The point is, if d->testing_p is true, we should do as few work as possible,
> certainly not call any emit_insn or gen_reg_rtx, and as soon as we know
> we'll certainly eventually return true, return it.

I have started bootstrap/regtest on 4.8 branch, together with following patch:

--cut here--
Index: emit-rtl.c
===================================================================
--- emit-rtl.c  (revision 207935)
+++ emit-rtl.c  (working copy)
@@ -894,6 +894,9 @@ gen_reg_rtx (enum machine_mode mode)
       return gen_rtx_CONCAT (mode, realpart, imagpart);
     }

+  /* Do not call gen_reg_rtx with uninitialized crtl.  */
+  gcc_assert (crtl->emit.regno_pointer_align_length);
+
   /* Make sure regno_pointer_align, and regno_reg_rtx are large
      enough to have an element for this pseudo reg number.  */

--cut here--

I will propose this patch for mainline, hopefully to save someone from
debugging this nasty data corruption.
>From gcc-bugs-return-444350-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 12:09:55 2014
Return-Path: <gcc-bugs-return-444350-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4810 invoked by alias); 20 Feb 2014 12:09:55 -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 4461 invoked by uid 48); 20 Feb 2014 12:09:51 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60276] [4.7/4.8/4.9 Regression] -O3 autovectorizer breaks on a particular loop
Date: Thu, 20 Feb 2014 12:09: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.8.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60276-4-nvcLahbBSd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60276-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60276-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-02/txt/msg02107.txt.bz2
Content-length: 942

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`276

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
And with less convoluted vectorized code but still broken (avoids integer
promotions):

extern void abort (void);

static void
foo (int *out, const int *lp, const int *hp, unsigned samples)
{
  int x, target;
  for (x = 0, target = 0; x < (int)samples; x += 2, target++)
    {
      out[x + 0] = lp[target] - ((hp[target] + hp[target - 1] + 2) >> 2);
      out[x - 1] = hp[target - 1] + ((out[x - 2] + out[x]) >> 1);
    }
}

int main(void)
{
  const int lp[25] = {
      0, 2, 4, 6, 8,
      10, 12, 14, 16,
      18, 20, 22, 24,
      26, 28, 30, 32,
      34, 36, 38, 40,
      42, 44, 46, 48,
  };
  const int hp[25] = {0};
  int out[49] = {0};
  int s;

  out[0] = lp[0] - (((hp[0] << 1) + 2) >> 2);
  foo (out + 2, lp + 1, hp + 1, 48);

  for (s = 0; s < 49; s++)
    if (out[s] != s)
      abort ();

  return 0;
}

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps just make it gcc_checking_assert?

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #29 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #28)
> Perhaps just make it gcc_checking_assert?

On release branches perhaps, but the consequences of
crtl->emit.regno_pointer_align_length == 0 warrant ICE even in the released
compiler. We are talking about "ICE in gen_reg_rtx ..." vs. "some random ICE
due to corrupted internal data" (as is this PR) reports. From maintainer's POV,
I'd like to have gcc_assert in development and release branches.
>From gcc-bugs-return-444358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 13:15:03 2014
Return-Path: <gcc-bugs-return-444358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1327 invoked by alias); 20 Feb 2014 13: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 1195 invoked by uid 48); 20 Feb 2014 13:14:54 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557
Date: Thu, 20 Feb 2014 13: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: abel at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60268-4-q6qqBUZQ6o@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60268-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60268-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-02/txt/msg02115.txt.bz2
Content-length: 185

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`268

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If this works, fine with me, but I'll defer the review to Vladimir.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #30 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #25)
> Created attachment 32180 [details]
> gcc48-pr57896.patch
> 
> So like this (4.8 version, untested)?  Uros, can you please double-check it?
> The point is, if d->testing_p is true, we should do as few work as possible,
> certainly not call any emit_insn or gen_reg_rtx, and as soon as we know
> we'll certainly eventually return true, return it.

I have:

- eyeballed the code a bit and found no issues (this is sorta unreliable test).

- bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} with the
gen_reg_rtx patch from Comment #27 applied.

- additionaly tested with
GCC_TEST_RUN_EXPENSIVE=1 make check-gcc
RUNTESTFLAGS='--target_board=unix\{-msse2,-msse4,-mavx\} dg-torture.exp=vshuf*'
on x86_64 AVX target (also with gen_reg_rtx patch applied) and found no issues.

- I don't have AVX2 target to test on, perhaps the above test should be also
run on AVX2 capable target with -mavx2 option added, preferably with
gen_reg_rtx patch applied.
>From gcc-bugs-return-444395-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 17:42:52 2014
Return-Path: <gcc-bugs-return-444395-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16228 invoked by alias); 20 Feb 2014 17:42:52 -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 16168 invoked by uid 48); 20 Feb 2014 17:42:48 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60292] New: [4.9 Regression] ICE: in fill_vec_av_set, at sel-sched.c:3863 with -m64 after r206174 on powerpc-apple-darwin9.8.0
Date: Thu, 20 Feb 2014 17:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
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 cc cf_gcchost cf_gcctarget cf_gccbuild
Message-ID: <bug-60292-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-02/txt/msg02152.txt.bz2
Content-length: 1103

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`292

            Bug ID: 60292
           Summary: [4.9 Regression] ICE: in fill_vec_av_set, at
                    sel-sched.c:3863 with -m64 after r206174 on
                    powerpc-apple-darwin9.8.0
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: abel at gcc dot gnu.org, iains at gcc dot gnu.org
              Host: powerpc-apple-darwin9
            Target: powerpc-apple-darwin9
             Build: powerpc-apple-darwin9

Compiling the test gfortran.dg/pr44691.f with -m64 -O2 -fselective-scheduling2
gives the following ICE

/opt/gcc/work/gcc/testsuite/gfortran.dg/pr44691.f:39:0: internal compiler
error: in fill_vec_av_set, at sel-sched.c:3863
       END

Line 3863 of sel-sched.c is the gcc_assert

          /* A fence insn should not get here.  */
          gcc_assert (!fence_insn_p);

introduced by r206174.

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Feb 20 20:39:46 2014
New Revision: 207969

URL: http://gcc.gnu.org/viewcvs?rev=207969&root=gcc&view=rev
Log:
    PR target/57896
    * config/i386/i386.c (expand_vec_perm_interleave2): Don't call
    gen_reg_rtx if d->testing_p.
    (expand_vec_perm_pshufb2, expand_vec_perm_broadcast_1): Return early
    if d->testing_p and we will certainly return true.
    (expand_vec_perm_even_odd_1): Likewise.  Don't call gen_reg_rtx
    if d->testing_p.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Feb 20 20:40:52 2014
New Revision: 207970

URL: http://gcc.gnu.org/viewcvs?rev=207970&root=gcc&view=rev
Log:
    PR target/57896
    * config/i386/i386.c (expand_vec_perm_interleave2): Don't call
    gen_reg_rtx if d->testing_p.
    (expand_vec_perm_pshufb2, expand_vec_perm_even_odd_1,
    expand_vec_perm_broadcast_1): Return early if d->testing_p and
    we will certainly return true.

Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c

[Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.7/4.8/4.9 Regression]    |[4.7 Regression] ICE in
                   |ICE in expand_expr_real_2   |expand_expr_real_2

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

[Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

--- Comment #34 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Feb 21 07:55:35 2014
New Revision: 207983

URL: http://gcc.gnu.org/viewcvs?rev=207983&root=gcc&view=rev
Log:
    Backport from mainline
    2014-02-21  Jakub Jelinek  <jakub@redhat.com>

    * config/i386/i386.c (ix86_expand_vec_perm): Use V8SImode
    mode for mask of V8SFmode permutation.

    Backport from 4.8 branch
    2014-02-20  Jakub Jelinek  <jakub@redhat.com>

    PR target/57896
    * config/i386/i386.c (expand_vec_perm_interleave2): Don't call
    gen_reg_rtx if d->testing_p.
    (expand_vec_perm_pshufb2, expand_vec_perm_even_odd_1,
    expand_vec_perm_broadcast_1): Return early if d->testing_p and
    we will certainly return true.


Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config/i386/i386.c

[Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2014-02/msg01255.htm
                   |                            |l
         Resolution|---                         |FIXED

--- Comment #35 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed everywhere.
>From gcc-bugs-return-444446-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 21 08:20:24 2014
Return-Path: <gcc-bugs-return-444446-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27049 invoked by alias); 21 Feb 2014 08:20: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 27006 invoked by uid 48); 21 Feb 2014 08:20:18 -0000
From: "terry.guo at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60298] New: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c
Date: Fri, 21 Feb 2014 08:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: terry.guo at arm 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-60298-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-02/txt/msg02203.txt.bz2
Content-length: 1977

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`298

            Bug ID: 60298
           Summary: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: terry.guo at arm dot com

Created attachment 32185
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2185&actioníit
case to reproduce the ICE

This issue is found during regression test of latest trunk for Thumb-1 target
Cortex-M0. Here is command to reproduce this issue:

terguo01@terry-pc01:case$ ../install-native/bin/arm-none-eabi-gcc  -O0 -w -c
-mthumb -mcpu=cortex-m0 -o pr54713-1.o pr54713-1.c
pr54713-1.c: In function 'f10':
pr54713-1.c:70:1: internal compiler error: Segmentation fault
 }
 ^
0xb1b7ce crash_signal
    /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/toplev.c:337
0xaeccbf simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)

/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/simplify-rtx.c:417
0x9a6df3 update_equiv

/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:351
0x9b06e7 lra_constraints(bool)

/myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:4054
0x99d609 lra(_IO_FILE*)
    /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra.c:2339
0x94b7af do_reload
    /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5457
0x94baf8 rest_of_handle_reload
    /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5598
0x94bb42 execute
    /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.