[Bug c/99694] New: gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os

[Bug c/99694] New: gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os

[haoxintu at gmail dot com]

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

            Bug ID: 99694
           Summary: gcc: fatal error: Killed signal terminated program cc1
                    under -O2 to -Os
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all.

GCC takes too much compiling time and then crashes on the valid small.c under
-O2 to -Os. Also, all GCC-9 upward versions behave the same.

$cat small.c
#include <stdint.h>
int a, b, c;
void d() {
  uint16_t e;
  int32_t *f;
  int32_t *g;
  if (a) {
    int32_t *k;
    for (;; *k += 1) {
      int32_t **i = &f;
      int32_t **l = &g;
      for (e = 6; e; e++) {
        g = k = f;
      j:
        **l = 0;
      }
      *i = c;
    }
  }
  uint16_t i = &e;
  b = i / 0;
  goto j;
}

$time gcc -w -c -O1 small.c

real    0m0.057s
user    0m0.023s
sys     0m0.006s


$time gcc -w -c -Os small.c (same as -O2 and -O3)
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

real    79m53.073s
user    78m10.888s
sys     0m28.194s

$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc/build-20210320/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/tuhaoxin/compilers/gcc/build-20210320/ --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ -disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210320 (experimental) (GCC) 


Thanks,
Haoxin

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gcc: fatal error: Killed    |[9/10/11 Regression] gcc:
                   |signal terminated program   |fatal error: Killed signal
                   |cc1 under -O2 to -Os        |terminated program cc1
                   |                            |under -O2 to -Os since
                   |                            |r9-7156-g33579b59aaf02eb7
                 CC|                            |law at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-03-22

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r9-7156-g33579b59aaf02eb7.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |9.4

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the hang is during VN in the PRE pass, after a short while we keep
cycling between process_bb on
<bb 4> [local count: 719407025]:
# k_14 = PHI <f_27(3), f_28(8)>
# f_28 = PHI <f_27(3), f_28(8)>
# g_30 = PHI <f_27(3), f_28(8)>
# e_10 = PHI <e_21(3), e_13(8)>
*g_30 = 0;
e.1_2 = e_10;
_3 = e.1_2 + 1;
e_13 = _3;
e.3_4 = e_13;
if (e.3_4 != 0)
  goto <bb 8>; [0.00%]
else
  goto <bb 5>; [100.00%]
and on
<bb 8> [local count: 0]:
goto <bb 4>; [100.00%]
forever.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug middle-end/99694] [9/10/11 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:b931e4792b8696f3da69f70988720c4d1ec6142a

commit r11-7762-gb931e4792b8696f3da69f70988720c4d1ec6142a
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Mar 22 11:09:46 2021 +0100

    tree-optimization/99694 - fix value-numbering PHIs

    This avoids endless cycling when a PHI node with unchanged backedge
    value (the PHI result appearing there) is subject to CSE since doing
    that effectively alters the hash entry.  The way to avoid this is
    to ignore such edges when processing the PHI node.

    2021-03-22  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99694
            * tree-ssa-sccvn.c (visit_phi): Ignore edges with the
            PHI result.

            * gcc.dg/torture/pr99694.c: New testcase.

[Bug middle-end/99694] [9/10 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] gcc:   |[9/10 Regression] gcc:
                   |fatal error: Killed signal  |fatal error: Killed signal
                   |terminated program cc1      |terminated program cc1
                   |under -O2 to -Os since      |under -O2 to -Os since
                   |r9-7156-g33579b59aaf02eb7   |r9-7156-g33579b59aaf02eb7
      Known to fail|                            |10.2.0
      Known to work|                            |11.0
           Priority|P3                          |P2

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug middle-end/99694] [9/10 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:73d1e612011f1781275c7504c4fa5c365c0c3ddd

commit r10-9525-g73d1e612011f1781275c7504c4fa5c365c0c3ddd
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Mar 22 11:09:46 2021 +0100

    tree-optimization/99694 - fix value-numbering PHIs

    This avoids endless cycling when a PHI node with unchanged backedge
    value (the PHI result appearing there) is subject to CSE since doing
    that effectively alters the hash entry.  The way to avoid this is
    to ignore such edges when processing the PHI node.

    2021-03-22  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99694
            * tree-ssa-sccvn.c (visit_phi): Ignore edges with the
            PHI result.

            * gcc.dg/torture/pr99694.c: New testcase.

    (cherry picked from commit b931e4792b8696f3da69f70988720c4d1ec6142a)

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[haoxintu at gmail dot com]

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

--- Comment #7 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r9-7156-g33579b59aaf02eb7.

Hi Martin. I am sorry to bother you, and I just have a question about how to
find a bad commit quickly in GCC.

As far as I know, we can use git bitset to set a bad and good commit to then
apply binary search to find the exact place that caused the error(I usually do
like this). My question is, is this means I should always find a commit (to be
tested), then build the source code and run the given test case to tell a
bad/good result? My concern is that build a GCC from a source code may take a
relatively long time (maybe more than half an hour), so if the number of
commits is much, it will take a long time to find the error commit. Is my
understanding correct or not? 

Also, I am wondering if you are using an automatic tool or other approaches
that can quickly find the bad commit to cause the problem. If I learned how to
do this quickly, I'd like to do the bitset myself and tell the bad commit when
I submit a report next time.

Please correct me if I am wrong and any suggestions are welcome! Thank you very
much!


Best,
Haoxin

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Haoxin Tu from comment #7)
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r9-7156-g33579b59aaf02eb7.
> 
> Hi Martin. I am sorry to bother you, and I just have a question about how to
> find a bad commit quickly in GCC.

Hello.

You don't have to find a bad revision, we can easily do that.

>  
> As far as I know, we can use git bitset to set a bad and good commit to then
> apply binary search to find the exact place that caused the error(I usually
> do like this). My question is, is this means I should always find a commit
> (to be tested), then build the source code and run the given test case to
> tell a bad/good result? My concern is that build a GCC from a source code
> may take a relatively long time (maybe more than half an hour), so if the
> number of commits is much, it will take a long time to find the error
> commit. Is my understanding correct or not? 

I have a script which I use:
https://github.com/marxin/script-misc/blob/master/gcc-bisect.py

I can do quick bisection as I have built binaries for all GCC revisions for a
couple last years.

> 
> Also, I am wondering if you are using an automatic tool or other approaches
> that can quickly find the bad commit to cause the problem. If I learned how
> to do this quickly, I'd like to do the bitset myself and tell the bad commit
> when I submit a report next time.
> 
> Please correct me if I am wrong and any suggestions are welcome! Thank you
> very much!

We thank you for a nice bug report. Keep doing :)

Martin

> 
> 
> Best,
> Haoxin

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:a343b3bda748c2eb602d4e7de17d827a5912c53b

commit r9-9343-ga343b3bda748c2eb602d4e7de17d827a5912c53b
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Mar 22 11:09:46 2021 +0100

    tree-optimization/99694 - fix value-numbering PHIs

    This avoids endless cycling when a PHI node with unchanged backedge
    value (the PHI result appearing there) is subject to CSE since doing
    that effectively alters the hash entry.  The way to avoid this is
    to ignore such edges when processing the PHI node.

    2021-03-22  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99694
            * tree-ssa-sccvn.c (visit_phi): Ignore edges with the
            PHI result.

            * gcc.dg/torture/pr99694.c: New testcase.

    (cherry picked from commit b931e4792b8696f3da69f70988720c4d1ec6142a)

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to fail|                            |9.3.0
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[haoxintu at gmail dot com]

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

--- Comment #11 from Haoxin Tu <haoxintu at gmail dot com> ---
Hi all.

I hope you all are doing well.

I am sorry to bother you again. May I ask a quick question about how do you
treat the bug-revealing test case which may include the valid syntax but
contain the UB? (e.g.,"b = i / 0;" in the above case is undefined). BTW, I did
not find my answer in the document
https://www.gnu.org/software/gcc/bugs/management.html.

(1)From my understanding, compilers should compile well (no crashing or
performance issue) with those test programs although they contain UB. Ideally,
programmers may introduce a UB by accident in their program, after compiling,
not to mention whether the warning message emitted by compilers is correct or
not, compilers should exit normally.  Am I correct here? 
(2)From my experience, those bugs caused by the UB-included program can always
occur in the optimization phase. So I think those test cases can be critical as
well (compared with wrong-code issues)? How do you categorize the importance of
related crashes or performance issues caused by such test programs? 

I am asking the question because I am thinking whether the effort is worthing
or not if I devise a tool that can produce diverse syntactic valid but may
contain UB test programs to detect crashes or performance issues in compilers.
The motivation is that I noticed the goal of most existing program generators
(e.g.,Csmith [1], YARPGen [2]) is to produce UB-free test programs to detect
miscompiliation bugs in compilers, few (only CCG [3], a quite old tool so that
may be hard to find bugs right now) aims to detect crashs using programs with
UB. So I guess our community may lack such test cases to further stress
compilers. If such diverse test programs (such as the reported one) can help
improve the quality of compilers, I'd like to spend some time on it.

Sorry again for my bothering and any suggestions are welcome! 

[1] https://github.com/csmith-project/csmith
[2] https://github.com/intel/yarpgen
[3] https://github.com/Mrktn/ccg

Thanks!
Haoxin

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
> 
> (1)From my understanding, compilers should compile well (no crashing or
> performance issue) with those test programs although they contain UB.

Yes, a compiler should produce a valid error message and exit for invalid
input.
However, e.g. in case of C++, error recovery is very difficult and we have a
bazillion
of invalid tests for which we either crash or loop infinitely.

> Ideally, programmers may introduce a UB by accident in their program, after
> compiling, not to mention whether the warning message emitted by compilers
> is correct or not, compilers should exit normally.  Am I correct here? 

Yes. However, having an UBSAN input, wrong things can happen during run-time.
That's why we have all the sanitizers in the GCC (and Clang).

> (2)From my experience, those bugs caused by the UB-included program can
> always occur in the optimization phase. So I think those test cases can be
> critical as well (compared with wrong-code issues)? How do you categorize
> the importance of related crashes or performance issues caused by such test
> programs? 

There are categorized pretty low, as expained.

> 
> I am asking the question because I am thinking whether the effort is
> worthing or not if I devise a tool that can produce diverse syntactic valid
> but may contain UB test programs to detect crashes or performance issues in
> compilers. The motivation is that I noticed the goal of most existing
> program generators (e.g.,Csmith [1], YARPGen [2]) is to produce UB-free test
> programs to detect miscompiliation bugs in compilers, few (only CCG [3], a
> quite old tool so that may be hard to find bugs right now) aims to detect
> crashs using programs with UB. So I guess our community may lack such test
> cases to further stress compilers. If such diverse test programs (such as
> the reported one) can help improve the quality of compilers, I'd like to
> spend some time on it.

I would not spend much time on it. It's pretty easy to create an invalid input
which cause compiler to crash. What's more interesting are valid inputs that
lead
to a wrong-code. That's why all these tools try having UBSAN free input.

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[haoxintu at gmail dot com]

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

--- Comment #13 from Haoxin Tu <haoxintu at gmail dot com> ---
(In reply to Martin Liška from comment #12)

Ok, got you. Thanks for your speedy reply~

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #12)
> > I am asking the question because I am thinking whether the effort is
> > worthing or not if I devise a tool that can produce diverse syntactic valid
> > but may contain UB test programs to detect crashes or performance issues in
> > compilers. The motivation is that I noticed the goal of most existing
> > program generators (e.g.,Csmith [1], YARPGen [2]) is to produce UB-free test
> > programs to detect miscompiliation bugs in compilers, few (only CCG [3], a
> > quite old tool so that may be hard to find bugs right now) aims to detect
> > crashs using programs with UB. So I guess our community may lack such test
> > cases to further stress compilers. If such diverse test programs (such as
> > the reported one) can help improve the quality of compilers, I'd like to
> > spend some time on it.
> 
> I would not spend much time on it. It's pretty easy to create an invalid
> input
> which cause compiler to crash. What's more interesting are valid inputs that
> lead
> to a wrong-code. That's why all these tools try having UBSAN free input.

I disagree - syntactically valid input should not crash the compiler or make it
slow.  Yes, fixing cases with obvious non-sensical input might be low priority,
but the exposed issues are often also issues for "correct" programs.

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)
> I disagree - syntactically valid input should not crash the compiler or make
> it slow.  Yes, fixing cases with obvious non-sensical input might be low
> priority, but the exposed issues are often also issues for "correct"
> programs.

Yeah.
I don't think ICEs/compiler hangs etc. on syntactically valid programs with UB
somewhere in it should be low priority, UB happens at runtime when some
statement is encountered and perhaps certain conditions are met, but there is
no guarantee those conditions will be met in the testcase at runtime or the
statement will be encountered.
Then there are ICEs/compiler hangs etc. on syntactically invalid programs, if
it happens without reporting errors the priority isn't much lower, if it
happens after reporting errors it is much lower priority (error recovery bugs).
Of course, for programs that invoke UB at runtime, anything that happens during
the runtime after encountering the UB is a non-bug.

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
Oh, you are right, I moved syntactically valid inputs (with a potential UBSAN)
into the same bag with syntactically invalid input.

[Bug middle-end/99694] [9 Regression] gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os since r9-7156-g33579b59aaf02eb7

[haoxintu at gmail dot com]

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

--- Comment #17 from Haoxin Tu <haoxintu at gmail dot com> ---
Thank you all for the detailed clarification! I have got the answer now. Let's
try together to make compilers a better place:)