[Bug middle-end/63764] New: nternal compiler error: in verify_ssa, at tree-ssa.c:939

[Bug middle-end/63764] New: nternal compiler error: in verify_ssa, at tree-ssa.c:939

[mkg at us dot ibm.com]

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

            Bug ID: 63764
           Summary: nternal compiler error: in verify_ssa, at
                    tree-ssa.c:939
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mkg at us dot ibm.com

Created attachment 33913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33913&action=edit
File performs several builtin operations in a loop.

mkg@genoa:~/tests/olivier$ /home/user/gcc/install/gcc-mainline-test/bin/g++ -O6
 -funroll-loops --save-temps  test2.c  -S
test2.c: In function ?void test(int, cfloat (*)[3], cfloat (**)[3])?:
test2.c:47:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
 }
 ^
0x10c1b24f verify_ssa(bool, bool)
        /home/user/gcc/gcc-mainline-test/gcc/tree-ssa.c:939
0x108d7c7b execute_function_todo
        /home/user/gcc/gcc-mainline-test/gcc/passes.c:1875
0x108d8c03 do_per_function
        /home/user/gcc/gcc-mainline-test/gcc/passes.c:1602
0x108d8daf execute_todo
        /home/user/gcc/gcc-mainline-test/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

mkg@genoa:~/tests/olivier$ gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.8/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-ppc64el
--with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

This compiler was built from head in trunk, on Ubuntu 14.04 PowerPC LE

[Bug tree-optimization/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[trippels at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
            Version|tree-ssa                    |5.0
   Last reconfirmed|                            |2014-11-07
          Component|middle-end                  |tree-optimization
                 CC|                            |trippels at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|nternal compiler error: in  |[5 Regression] ICE: in
                   |verify_ssa, at              |verify_ssa, at
                   |tree-ssa.c:939              |tree-ssa.c:939
   Target Milestone|---                         |5.0
           Severity|major                       |normal

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Also happens when building the Linux kernel:

trippels@gcc2-power8 linux-3.17.2 % cat dev.i
struct hlist_head
{
  struct hlist_node *first
};
struct hlist_node
{
  struct hlist_node *next
};
struct net_device
{
  int ifindex;
  struct hlist_node index_hlist
} * a;
b, f;
*fn1 (int *p1, int p2)
{
  struct hlist_head *c;
  struct net_device *d;
  c = &a[b];
  struct hlist_head *e = c;
  d = (
      {
        0;
        e->first ? (
                       {
                         (char *) e->first
                             - __builtin_offsetof(typeof(*d), index_hlist);
                       })
                 : 0;
      });
  for (; d;
       d = (
           {
             0;
             d->index_hlist.next
                 ? (
                       {
                         (char *) d->index_hlist.next
                             - __builtin_offsetof(typeof(*d), index_hlist);
                       })
                 : 0;
           }))
    if (d->ifindex == p2)
      return d;
  return 0;
}
*fn2 (int *p1, int p2)
{
  struct hlist_head *g;
  struct net_device *h;
  g = &a[b];
  struct hlist_head *i = g;
  h = (
      {
        typeof((
            {
              &f;
            })) j
            = (
                {
                  i->first;
                });
        j ? (
                {
                  (char *) j - __builtin_offsetof(typeof(*h), index_hlist);
                })
          : 0;
      });
  for (; h; h = (
                {
                  typeof((
                      {
                        &f;
                      })) k
                      = (
                          {
                            typeof(0) *l = *(volatile typeof(h) *) &(
                                                &h->index_hlist)->next;
                            l;
                          });
                  k ? (
                          {
                            (char *) k
                                - __builtin_offsetof(typeof(*h), index_hlist);
                          })
                    : 0;
                }))
    if (h->ifindex == p2)
      return h;
  return 0;
}
fn3 () { fn1 (0, 0); }

trippels@gcc2-power8 linux-3.17.2 % gcc -w -c -O2 dev.i
dev.i: In function ‘fn3’:
dev.i:92:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
 fn3 () { fn1 (0, 0); }
 ^
>From gcc-bugs-return-465942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 07 09:40:44 2014
Return-Path: <gcc-bugs-return-465942-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6441 invoked by alias); 7 Nov 2014 09:40: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 6400 invoked by uid 48); 7 Nov 2014 09:40:39 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
Date: Fri, 07 Nov 2014 09:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63764-4-bRVhbeltmQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63764-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63764-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-11/txt/msg00414.txt.bz2
Content-length: 355

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #1)
> Also happens when building the Linux kernel:
That is a different issue and already recorded as bug 63569 (I reduced it
further based on thinking why it would produce wrong code too).

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the #c4 testcase, it is even unclear to me whether we shouldn't reject it.
typedef float V __attribute__((vector_size (4 * sizeof (float))));
void
fn2 ()
{
  V saijplus16 = (V) { 0.0, 0.0, 0.0, 0.0 };
  ((V) saijplus16)[0] = 0;
}
doesn't ICE (at least on x86_64) though,
void
fn3 ()
{
  float __attribute__((vector_size (4 * sizeof (float)))) saijplus16 = (float
__attribute__((vector_size (4 * sizeof (float))))) { 0.0, 0.0, 0.0, 0.0 };
  ((float __attribute__((vector_size (4 * sizeof (float))))) saijplus16)[0] =
0;
}
does.  The difference is when
handling the (type) saijplus16 cast in build_c_cast.
In the ppc case and fn3 case, the type is the same, so we end up with
NON_LVALUE_EXPR of saijplus16.  In the fn2 case with V typedef, the type is
different (saijplus16 has V type, the cast uses its main variant), so we end up
with VIEW_CONVERT_EXPR of saijplus16 instead.  The VCE gets folded away, while
NON_LVALUE_EXPR remains.  But in all cases the casts aren't valid lvalue.
Note, C++ ICEs on all the testcases.
IMHO either we need to reject it (but how to find out in the case of
build_c_cast that it originally was non-lvalue?), or we need to skip the
NON_LVALUE_EXPRs when marking the var as addressable and taking address of it.

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:

> does.  The difference is when
> handling the (type) saijplus16 cast in build_c_cast.
> In the ppc case and fn3 case, the type is the same, so we end up with
> NON_LVALUE_EXPR of saijplus16.  In the fn2 case with V typedef, the type is
> different (saijplus16 has V type, the cast uses its main variant), so we end up
> with VIEW_CONVERT_EXPR of saijplus16 instead.  The VCE gets folded away, while
> NON_LVALUE_EXPR remains.  But in all cases the casts aren't valid lvalue.
> Note, C++ ICEs on all the testcases.
> IMHO either we need to reject it (but how to find out in the case of
> build_c_cast that it originally was non-lvalue?), or we need to skip the
> NON_LVALUE_EXPRs when marking the var as addressable and taking address of it.

What folds away the VIEW_CONVERT_EXPR, when?  c-typeck.c:lvalue_p does not 
consider VIEW_CONVERT_EXPRs to be lvalues, and lvalue checks are meant to 
happen before any folding that could change a non-lvalue to an lvalue.

Maybe build_array_ref needs to ensure that references to elements of 
non-lvalue vectors don't become lvalues?  (This would be different to 
non-lvalue arrays arising from non-lvalue structs and unions, where the 
result of an array reference *is* an lvalue but modifying it, or accessing 
it after the next sequence point, has undefined behavior.)

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #7)
> On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:
> What folds away the VIEW_CONVERT_EXPR, when?  c-typeck.c:lvalue_p does not 
> consider VIEW_CONVERT_EXPRs to be lvalues, and lvalue checks are meant to 
> happen before any folding that could change a non-lvalue to an lvalue.
> 
> Maybe build_array_ref needs to ensure that references to elements of 
> non-lvalue vectors don't become lvalues?  (This would be different to 
> non-lvalue arrays arising from non-lvalue structs and unions, where the 
> result of an array reference *is* an lvalue but modifying it, or accessing 
> it after the next sequence point, has undefined behavior.)

Apparently I misremembered it, trying it again, I see the VCE still there in
*vecp upon entry to convert_vector_to_pointer_for_subscript, the difference
between VIEW_CONVERT_EXPR and NON_LVALUE_EXPR is just that
c_common_mark_addressable_vec looks through VCE and marks the inner part as
addressable (because VCE is handled_component_p), while for non_lvalue_expr it
does not.

So, shall we convert_vector_to_pointer_for_subscript add something like
  if (!lvalue_p (*vecp))
    error_at (...); ?
What wording for it?

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:

> > Maybe build_array_ref needs to ensure that references to elements of 
> > non-lvalue vectors don't become lvalues?  (This would be different to 
> > non-lvalue arrays arising from non-lvalue structs and unions, where the 
> > result of an array reference *is* an lvalue but modifying it, or accessing 
> > it after the next sequence point, has undefined behavior.)
> 
> Apparently I misremembered it, trying it again, I see the VCE still there in
> *vecp upon entry to convert_vector_to_pointer_for_subscript, the difference
> between VIEW_CONVERT_EXPR and NON_LVALUE_EXPR is just that
> c_common_mark_addressable_vec looks through VCE and marks the inner part as
> addressable (because VCE is handled_component_p), while for non_lvalue_expr it
> does not.
> 
> So, shall we convert_vector_to_pointer_for_subscript add something like
>   if (!lvalue_p (*vecp))
>     error_at (...); ?
> What wording for it?

I'd think it's reasonable to subscript a non-lvalue vector (including e.g. 
the return value of a function with vector return type) - this might of 
course need to create a temporary object, as with non-lvalue arrays.

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #9)
> On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:
> > So, shall we convert_vector_to_pointer_for_subscript add something like
> >   if (!lvalue_p (*vecp))
> >     error_at (...); ?
> > What wording for it?
> 
> I'd think it's reasonable to subscript a non-lvalue vector (including e.g. 
> the return value of a function with vector return type) - this might of 
> course need to create a temporary object, as with non-lvalue arrays.

For rhs yes, supposedly.  But not for lhs.  So, perhaps if *vecp is not an
lvalue, assign to temporary and take address of that, but then in the end wrap
the result of the subscripting into NON_LVALUE_EXPR, so that we actually error
out on the testcase?

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:

> > I'd think it's reasonable to subscript a non-lvalue vector (including e.g. 
> > the return value of a function with vector return type) - this might of 
> > course need to create a temporary object, as with non-lvalue arrays.
> 
> For rhs yes, supposedly.  But not for lhs.  So, perhaps if *vecp is not an
> lvalue, assign to temporary and take address of that, but then in the end wrap
> the result of the subscripting into NON_LVALUE_EXPR, so that we actually error
> out on the testcase?

Yes, that sort of thing - make the result of subscripting not an lvalue if 
the expression subscripted is not an lvalue, so that an error results on 
assigning to it.

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

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

So like this (untested so far)?

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Yes, like that.

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Nov 21 09:25:51 2014
New Revision: 217909

URL: https://gcc.gnu.org/viewcvs?rev=217909&root=gcc&view=rev
Log:
    PR target/63764
c-family/
    * c-common.h (convert_vector_to_pointer_for_subscript): Change
    return type to bool.
    * c-common.c: Include gimple-expr.c.
    (convert_vector_to_pointer_for_subscript): Change return type to
    bool.  If *vecp is not lvalue_p and has VECTOR_TYPE, return true
    and copy it into a TARGET_EXPR and use that instead of *vecp
    directly.
c/
    * c-typeck.c (build_array_ref): Adjust
    convert_vector_to_pointer_for_subscript caller.  If it returns true,
    call non_lvalue_loc on the result.
cp/
    * typeck.c (cp_build_array_ref): Adjust
    convert_vector_to_pointer_for_subscript caller.  If it returns true,
    call non_lvalue_loc on the result.
testsuite/
    * c-c++-common/pr63764-1.c: New test.
    * c-c++-common/pr63764-2.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr63764-1.c
    trunk/gcc/testsuite/c-c++-common/pr63764-2.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c-family/c-common.h
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.