From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DCE863850435; Wed, 11 May 2022 21:57:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCE863850435 From: "sam at gentoo dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/105573] New: ICE when building numpy on SPARC64 Date: Wed, 11 May 2022 21:57:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sam at gentoo dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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 target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 21:57:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105573 Bug ID: 105573 Summary: ICE when building numpy on SPARC64 Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sam at gentoo dot org Target Milestone: --- Created attachment 52957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D52957&action=3Dedit loops.i Originally reported downstream in Gentoo at https://bugs.gentoo.org/843575 = by Agostino Sarubbo (ago). Occurs when building numpy 1.22.3 on SPARC64 with GCC 11.3 (but also seen it with: numpy 1.22.3/gcc 11.2.1_p20220115; numpy 1.21.1/gcc 10.3.0). I've minimised a reproducer (attached) and can reproduce it myself: ``` $ cat loops.i UINT_sign_args, UINT_sign_steps; *UINT_sign_ip1; __attribute__((optimize("O3"))) UINT_sign() { char *op1 =3D UINT_sign_args; int os1 =3D UINT_sign_steps, i; for (; i; i++, op1 +=3D os1) { unsigned in =3D *(unsigned *)UINT_sign_ip1; int *out =3D op1; *out =3D in > 0; } } $ sparc64-unknown-linux-gnu-gcc -O2 -pipe -mcpu=3Dniagara4 -c loops.i loops.i:1:1: warning: data definition has no type or storage class 1 | UINT_sign_args, UINT_sign_steps; | ^~~~~~~~~~~~~~ loops.i:1:1: warning: type defaults to =E2=80=98int=E2=80=99 in declaration= of =E2=80=98UINT_sign_args=E2=80=99 [-Wimplicit-int] loops.i:1:17: warning: type defaults to =E2=80=98int=E2=80=99 in declaratio= n of =E2=80=98UINT_sign_steps=E2=80=99 [-Wimplicit-int] 1 | UINT_sign_args, UINT_sign_steps; | ^~~~~~~~~~~~~~~ loops.i:2:1: warning: data definition has no type or storage class 2 | *UINT_sign_ip1; | ^ loops.i:2:2: warning: type defaults to =E2=80=98int=E2=80=99 in declaration= of =E2=80=98UINT_sign_ip1=E2=80=99 [-Wimplicit-int] 2 | *UINT_sign_ip1; | ^~~~~~~~~~~~~ loops.i:3:33: warning: return type defaults to =E2=80=98int=E2=80=99 [-Wimp= licit-int] 3 | __attribute__((optimize("O3"))) UINT_sign() { | ^~~~~~~~~ loops.i: In function =E2=80=98UINT_sign=E2=80=99: loops.i:4:15: warning: initialization of =E2=80=98char *=E2=80=99 from =E2= =80=98int=E2=80=99 makes pointer from integer without a cast [-Wint-conversion] 4 | char *op1 =3D UINT_sign_args; | ^~~~~~~~~~~~~~ loops.i:8:16: warning: initialization of =E2=80=98int *=E2=80=99 from incom= patible pointer type =E2=80=98char *=E2=80=99 [-Wincompatible-pointer-types] 8 | int *out =3D op1; | ^~~ during GIMPLE pass: isel loops.i:3:33: internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:267 3 | __attribute__((optimize("O3"))) UINT_sign() { | ^~~~~~~~~ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ``` Please let me know if you need further information or hardware access (but = I've reproduced this above using a cross-compiler without issues).=