From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7F4003858C50; Thu, 4 Apr 2024 09:42:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F4003858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712223771; bh=iwAlQ1biml+q1fZhE2N7f0S9yayAyFjwbxyZ6kJN3yA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W9/pBO7vCkKaLPZAURYZhdtpDEWEEFIrFOae35HnHfLCMKe3+RkLDq66K064wim2v AlYh2k+lbvq+pxWs/+PbsE1v7VCawa8OVTp7klybnB3pA5s2DgqYZWFzBqkT/3gXoQ e0BUFFzESsJ3Lbgh1feXIgujJBANb2l24IuBMDpk= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus Date: Thu, 04 Apr 2024 09:42:48 +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: 11.4.0 X-Bugzilla-Keywords: compile-time-hog, memory-hog, ra X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114480 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amonakov at gcc dot gnu.org --- Comment #19 from Richard Biener --- Alexander - the testcase at -O1 shows curiously high 3.16% 9840 cc1plus cc1plus [.] mergesort which is attributed (by callgrind) to if (sizeof (size_t) =3D=3D 8 && LIKELY (c->size =3D=3D 8)) --> MERGE_ELTSIZE (8); and the caller in tree-into-ssa.cc:prune_unused_phi_nodes doing qsort (defs, adef, sizeof (struct dom_dfsnum), cmp_dfsnum); I'm not sure why callgrind pins it this way, but perf somewhat agrees: Samples=E2=94=82 =E2=94=82MERGE_ELTSIZE (8);=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 1 =E2=94=822d0:=E2=94=82 mov %r9,%rsi=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 8 =E2=94=82 =E2=94=82 mov %r9,0x8(%rsp)=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 =E2=96=92 528 =E2=94=82 =E2=94=82 mov %r12,%rdi=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 31 =E2=94=82 =E2=94=82=E2=86=92 call *0x0(%r13)=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 236 =E2=94=82 =E2=94=82 mov 0x8(%rsp),%r9=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 =E2=96=92 2 =E2=94=82 =E2=94=82 sar $0x1f,%eax=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 244 =E2=94=82 =E2=94=82 mov %r12,%rcx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 =E2=94=82 =E2=94=82 movslq %eax,%rdx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 531 =E2=94=82 =E2=94=82 and $0x8,%eax=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 62 =E2=94=82 =E2=94=82 add $0x8,%rbx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 =E2=94=82 =E2=94=82 cltq=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=97=86 725 =E2=94=82 =E2=94=82 xor %r9,%rcx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 914 =E2=94=82 =E2=94=82 add %rax,%r12=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 1 =E2=94=82 =E2=94=82 and %rdx,%rcx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 =E2=94=82 =E2=94=82 xor %r9,%rcx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 3 =E2=94=82 =E2=94=82 mov (%rcx),%rcx=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 2155 =E2=94=82 =E2=94=82 mov %rcx,-0x8(%rbx)=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 =E2=96=92 29 =E2=94=82 =E2=94=82 cmp %r12,%rbx=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 =E2=96=92 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80je 1d7 I'll note the swapping of 8 bytes is a bit odd and it seems to be if-converted, thus always doing a write. I'm of course questioning what prune_unused_phi_nodes does but I have no idea if that's sensible at all, but it seems slow for this testcase, and the sorting is the slowest part of it.=