[Bug c/114855] New: ICE: Segfault

[Bug c/114855] New: ICE: Segfault

[jeremy.rutman at gmail dot com]

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

            Bug ID: 114855
           Summary: ICE: Segfault
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jeremy.rutman at gmail dot com
  Target Milestone: ---

Created attachment 58041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58041&action=edit
output from  gcc -v

Attempt to compile some autogenerated code resulted in `cc: internal compiler
error: Segmentation fault signal terminated program cc1` . Compile command was 

gcc -v -Wall -O3 -DNDEBUG -fomit-frame-pointer -freport-bug -save-temps -c
aesDecrypt.c -o aesDecrypt.o

I put the offending source file 
aesDecrypt.c
here:
https://paste.c-net.org/ExamineLarch
and the .i file from the -save-temps 
aesDecrypt.i 
here
https://paste.c-net.org/TiredInduce
I'm not sure what the -freport-bug is doing but I used it in the compile
command anyway.  Apologies for the unwieldy size of the autogenerated code
being compiled.

[Bug middle-end/114855] ICE: Segfault

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Worthing noting on the trunk most of the compile time seems to be in the ranger
code ...

[Bug middle-end/114855] ICE: Segfault

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code basically does a bunch of:

  const SWord8 s599 = s557 ? s595 : s598;
  const SWord8 s600 = s561 ? 14 : 246;
  const SWord8 s601 = s561 ? 3 : 72;
  const SWord8 s602 = s559 ? s600 : s601;
  const SWord8 s603 = s561 ? 102 : 181;
  const SWord8 s604 = s561 ? 62 : 112;
  const SWord8 s605 = s559 ? s603 : s604;
  const SWord8 s606 = s557 ? s602 : s605;
  const SWord8 s607 = s555 ? s599 : s606;
  const SWord8 s608 = s561 ? 138 : 139;


Continuously.

[Bug middle-end/114855] ICE: Segfault

[jeremy.rutman at gmail dot com]

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

--- Comment #3 from jeremy rutman <jeremy.rutman at gmail dot com> ---
For what it's worth, clang is able to compile the code in question. 

Ubuntu clang version 18.1.3 (1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[Bug middle-end/114855] ICE: Segfault

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-04-26

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Trunk at -O1:

dominator optimization             : 495.14 ( 82%)   0.20 (  5%) 495.44 ( 81%) 
 113M (  5%)

I can confirm the segfault with the 13.2 release.  It segfaults in

#0  0x00000000009a8603 in (anonymous
namespace)::pass_waccess::check_dangling_stores (this=this@entry=0x2866fc0,
bb=0x7ffff5277480, stores=..., bbs=...)
    at /space/rguenther/src/gcc-13-branch/gcc/gimple-ssa-warn-access.cc:4535

with too deep recursion.  That was fixed by r14-4308-gf194c684a28a5d for
PR111600 and could be backported, leaving the compile-time hog.  I'll do
that next week.

[Bug middle-end/114855] ICE: Segfault

[jeremy.rutman at gmail dot com]

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

--- Comment #5 from jeremy rutman <jeremy.rutman at gmail dot com> ---
Using gcc 14.0.1 20240117 (experimental) [master r14-8187-gb00be6f1576] I was
able to compile when not using any flags:

$ /usr/lib/gcc-snapshot/bin/cc -c aesDecrypt.c -o aesDecrypt.o

But when using the flags as before 

$  /usr/lib/gcc-snapshot/bin/cc -Wall -O3 -DNDEBUG -fomit-frame-pointer -c
aesDecrypt.c -o aesDecrypt.o

the compile kept going for at least one hour on my machine before I aborted.

[Bug middle-end/114855] ICE: Segfault

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
I've backported the fix for the recursion issue, only the memory/compile-time
hog issue should prevail on the branch.  comment#14 now also applies to the GCC
13 branch.

[Bug middle-end/114855] ICE: Segfault

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
LOoks like the primary culprits now are:

dominator optimization             : 666.73 (  7%)   0.77 (  2%) 671.76 (  7%) 
 170M (  4%)
backwards jump threading           :7848.77 ( 85%)  21.04 ( 65%)7920.05 ( 85%) 
1332M ( 29%)

TOTAL                              :9250.99         32.58       9341.40        
4619M

[Bug middle-end/114855] ICE: Segfault

[amacleod at redhat dot com]

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

--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Macleod from comment #7)
> LOoks like the primary culprits now are:
> 
> dominator optimization             : 666.73 (  7%)   0.77 (  2%) 671.76 ( 
> 7%)   170M (  4%)
> backwards jump threading           :7848.77 ( 85%)  21.04 ( 65%)7920.05 (
> 85%)  1332M ( 29%)
> 
> TOTAL                              :9250.99         32.58       9341.40     
> 4619M

If I turn off threading, then VRP opps up with 400, so I took a look at VRP.

The biggest problem is that this testcase has on the order of 400,000 basic
blocks, with a pattern of a block of code followed by a lot of CFG diamonds
using a number of differense ssa-names from within the block over and over.  
When we are calculating /storing imports and exports for every block, then
utilizing that info to try to find outgoing ranges that maybe we can use, it
simply adds up.

For VRP, we currently utilize different cache models depoending on the number
of block.. Im wondering if maybe this might not be a good testcase to actually
use a different VRP when the number of block are excessive.  I wroite the fast
VRP pass last year, which currently isnt being used.  I'm goign to experiment
with it to see if we turn it on for CFGs that above a threasdhold (100,000 BB?
), we enable the lower overhead fast VRP instead for all VRP passes. 

The threading issue probably needs to have some knobs added or tweaked for such
very large BBs. there would be a LOT of threading opportunities in the code I
saw, so I can see why it would be so busy.  I saw a lot fo branches to branches
using the same SSA_NAMe.