[Bug c/94239] New: [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[Bug c/94239] New: [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[ro at gcc dot gnu.org]

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

            Bug ID: 94239
           Summary: [10 regression] cc1 SEGV in
                    get_location_from_adhoc_loc with gcc.dg/pr20245-1.c
                    etc.
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
              Host: i386-pc-solaris2.11
            Target: i386-pc-solaris2.11
             Build: i386-pc-solaris2.11

Between 20200319 (f22712bd8a2ed57d3cc7e6fa92730bd5852e27b3) and 20200320
(719c864225e28c33a0737a331a772781ce8e6591), two tests regressed on Solaris
11/x86
(32-bit only):

+FAIL: gcc.dg/pr20245-1.c (internal compiler error)
+FAIL: gcc.dg/pr20245-1.c (test for excess errors)

Excess errors:
during GIMPLE pass: lower
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/pr20245-1.c:5:6: internal
compiler error: Segmentation Fault
0x91a511c crash_signal
        /vol/gcc/src/hg/master/local/gcc/toplev.c:328
0x9d33aa6 get_location_from_adhoc_loc(line_maps const*, unsigned int)
        /vol/gcc/src/hg/master/local/libcpp/line-map.c:257
0x9d33aa6 get_pure_location(line_maps*, unsigned int)
        /vol/gcc/src/hg/master/local/libcpp/line-map.c:323

+FAIL: gcc.dg/pr28419.c (internal compiler error)
+FAIL: gcc.dg/pr28419.c (test for excess errors)

Excess errors:
during GIMPLE pass: lower
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/pr28419.c:2:6: internal
compiler error: Segmentation Fault
0x91a511c crash_signal
        /vol/gcc/src/hg/master/local/gcc/toplev.c:328
0x9d33aa6 get_location_from_adhoc_loc(line_maps const*, unsigned int)
        /vol/gcc/src/hg/master/local/libcpp/line-map.c:257
0x9d33aa6 get_pure_location(line_maps*, unsigned int)
        /vol/gcc/src/hg/master/local/libcpp/line-map.c:323

The failure can be reproduced with

$ cc1 -fpreprocessed pr20245-1.i -quiet -o pr20245-1.s
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x09d33aa6 in get_location_from_adhoc_loc (loc=4264370176, set=0xfaefb000)
    at /vol/gcc/src/hg/master/local/libcpp/line-map.c:257
257       return set->location_adhoc_data_map.data[loc & MAX_LOCATION_T].locus;
(gdb) where
#0  0x09d33aa6 in get_location_from_adhoc_loc (loc=4264370176, set=0xfaefb000)
    at /vol/gcc/src/hg/master/local/libcpp/line-map.c:257
#1  get_pure_location (set=0xfaefb000, loc=4264370176)
    at /vol/gcc/src/hg/master/local/libcpp/line-map.c:323
#2  0x094c0da5 in get_pure_location (loc=4264370176)
    at /vol/gcc/src/hg/master/local/gcc/input.h:148
#3  set_block (loc=4264370176, block=<block 0xfa4a0000>)
    at /vol/gcc/src/hg/master/local/gcc/tree.c:14840
#4  0x09b634df in gimple_set_block (block=<optimized out>, g=
    <gimple_return 0xfa4967b0>)
    at /vol/gcc/src/hg/master/local/gcc/gimple.h:1865
#5  lower_function_body () at /vol/gcc/src/hg/master/local/gcc/gimple-low.c:136
#6  (anonymous namespace)::pass_lower_cf::execute (this=<optimized out>)
    at /vol/gcc/src/hg/master/local/gcc/gimple-low.c:195
#7  0x090b5a1e in execute_one_pass (pass=<opt_pass* 0xa42d160 "lower"(13)>)
    at /vol/gcc/src/hg/master/local/gcc/passes.c:2502
#8  0x090b6385 in execute_pass_list_1 (pass=<opt_pass* 0xa42d160 "lower"(13)>, 
    pass@entry=<opt_pass* 0xa42d060 "*warn_unused_result"(-1)>)
    at /vol/gcc/src/hg/master/local/gcc/passes.c:2590
#9  0x090b63ce in execute_pass_list (fn=0xfa49f000, 
    pass=<opt_pass* 0xa42d060 "*warn_unused_result"(-1)>)
    at /vol/gcc/src/hg/master/local/gcc/passes.c:2601
#10 0x08cbbcfa in cgraph_node::analyze (this=<optimized out>)
    at /vol/gcc/src/hg/master/local/gcc/context.h:48
#11 0x08cbea41 in analyze_functions (first_time=first_time@entry=true)
    at /vol/gcc/src/hg/master/local/gcc/cgraphunit.c:1227
#12 0x08cbf5a7 in symbol_table::finalize_compilation_unit (this=0xfa4080d0)
    at /vol/gcc/src/hg/master/local/gcc/cgraphunit.c:2973
#13 0x091a5571 in compile_file ()
    at /vol/gcc/src/hg/master/local/gcc/toplev.c:483
#14 0x091a7b9f in do_compile ()
    at /vol/gcc/src/hg/master/local/gcc/toplev.c:2273
#15 toplev::main (this=0xfeffd8de, argc=<optimized out>, argv=<optimized out>)
    at /vol/gcc/src/hg/master/local/gcc/toplev.c:2412
#16 0x09cd6ae1 in main (argc=6, argv=0xfeffd944)
    at /vol/gcc/src/hg/master/local/gcc/main.c:39

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.0

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-03-20
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
I noticed this on x86_64-linux as well last night in a fully bootstrapped
compiler but today I can't reproduce with just stage1.

It can be seen in powerpc64le-unknown-linux-gnu test results:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556737.html
and m68k-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/556729.html

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
                 CC|                            |law at redhat dot com

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
Almost certainly the bug we were looking at earlier today Jakub.

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html
Sorry for that.

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer <seurer at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at linux dot vnet.ibm.com

--- Comment #4 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
I think this also hit powerpc though only on power 8.

Regressions on trunk (power8) on update from
37482edc3f7f19110da7178d0d4c3003ea5272f3, r10-7280 to
9def91e9f2a7051c9c146f16c1a10d1b25d33b47, r10-7281:

New failures (these tests were not seen to fail previously):
FAIL: gcc.dg/pr20245-1.c (internal compiler error)
FAIL: gcc.dg/pr20245-1.c (test for excess errors)
FAIL: gcc.dg/pr28419.c (internal compiler error)
FAIL: gcc.dg/pr28419.c (test for excess errors)

This only happens on a bootstrap.

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html
> Sorry for that.

I've just applied your patch (the primary one above), rebuilt cc1 on
both i386-pc-solaris2.11 and sparc-sun-solaris2.11 (where the failures
had apppeared in this Friday's bootstaps, too), and run the two affected
tests for both 32 and 64-bit: both failures are gone now.

Thanks.
        Rainer

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 94262 has been marked as a duplicate of this bug. ***

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[rguenth at gcc dot gnu.org]

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

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

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

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asolokha at gmx dot com

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 94287 has been marked as a duplicate of this bug. ***

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5db9e89323cd0a0be16a94f2f984121531ea7772

commit r10-7343-g5db9e89323cd0a0be16a94f2f984121531ea7772
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 23 19:44:58 2020 +0100

    c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]

    Unfortunately the patch broke
    +FAIL: gcc.dg/pr20245-1.c (internal compiler error)
    +FAIL: gcc.dg/pr20245-1.c (test for excess errors)
    +FAIL: gcc.dg/pr28419.c (internal compiler error)
    +FAIL: gcc.dg/pr28419.c (test for excess errors)
    on some targets (and under valgrind on the rest of them).

    Those functions don't have the opening { and so c_parser_compound_statement
    returned error_mark_node before initializing *endlocp.
    So, either we can initialize it in that case too:
    --- gcc/c/c-parser.c    2020-03-20 22:09:39.659411721 +0100
    +++ gcc/c/c-parser.c    2020-03-21 09:36:44.455705261 +0100
    @@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
             if we have just prepared to enter a function body.  */
           stmt = c_begin_compound_stmt (true);
           c_end_compound_stmt (brace_loc, stmt, true);
    +      if (endlocp)
    +       *endlocp = brace_loc;
           return error_mark_node;
         }
       stmt = c_begin_compound_stmt (true);
    or perhaps simpler initialize it to the function_start_locus at the
    beginning and have those functions without { have function_start_locus ==
    function_end_locus like the __GIMPLE functions (where propagating the
    closing } seemed too difficult).

    2020-03-23  Jakub Jelinek  <jakub@redhat.com>

            PR gcov-profile/94029
            PR c/94239
            * c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
            the function_start_locus location.  Don't do that afterwards for
the
            __GIMPLE body parsing.

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r9-8467-gf83c2d2991a762f729741a409a1ac7871733ee40
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 23 19:44:58 2020 +0100

    c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]

    Unfortunately the patch broke
    +FAIL: gcc.dg/pr20245-1.c (internal compiler error)
    +FAIL: gcc.dg/pr20245-1.c (test for excess errors)
    +FAIL: gcc.dg/pr28419.c (internal compiler error)
    +FAIL: gcc.dg/pr28419.c (test for excess errors)
    on some targets (and under valgrind on the rest of them).

    Those functions don't have the opening { and so c_parser_compound_statement
    returned error_mark_node before initializing *endlocp.
    So, either we can initialize it in that case too:
    --- gcc/c/c-parser.c    2020-03-20 22:09:39.659411721 +0100
    +++ gcc/c/c-parser.c    2020-03-21 09:36:44.455705261 +0100
    @@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
             if we have just prepared to enter a function body.  */
           stmt = c_begin_compound_stmt (true);
           c_end_compound_stmt (brace_loc, stmt, true);
    +      if (endlocp)
    +       *endlocp = brace_loc;
           return error_mark_node;
         }
       stmt = c_begin_compound_stmt (true);
    or perhaps simpler initialize it to the function_start_locus at the
    beginning and have those functions without { have function_start_locus ==
    function_end_locus like the __GIMPLE functions (where propagating the
    closing } seemed too difficult).

    2020-03-23  Jakub Jelinek  <jakub@redhat.com>

            PR gcov-profile/94029
            PR c/94239
            * c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
            the function_start_locus location.  Don't do that afterwards for
the
            __GIMPLE body parsing.