[Bug preprocessor/58381] New: crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[Bug preprocessor/58381] New: crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381

            Bug ID: 58381
           Summary: crash in diagnostic_report_current_module when a
                    fatal_error happens during PCH processing on
                    NetBSD/spa64rc
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: martin at netbsd dot org

In toplev_main variable line_table is initialized and becomes 0x417dc000,
however, when invoking diagnostic_report_current_module with this backtrace it
is different:

#0  diagnostic_report_current_module (context=0x17b28d0, where=19) at
../../gcc-4.8.1/gcc/diagnostic.c:468
#1  0x00000000003a6368 in cp_diagnostic_starter (context=0x17b28d0,
diagnostic=0xffffffffffffa3e8)
    at ../../gcc-4.8.1/gcc/cp/error.c:2907
#2  0x00000000012d5e44 in diagnostic_report_diagnostic (context=0x17b28d0,
diagnostic=0xffffffffffffa3e8)
    at ../../gcc-4.8.1/gcc/diagnostic.c:756
#3  0x00000000012d6b90 in fatal_error (gmsgid=0x13e1230 "had to relocate PCH")
at ../../gcc-4.8.1/gcc/diagnostic.c:1076
#4  0x00000000008e83dc in gt_pch_restore (f=0x424a0738) at
../../gcc-4.8.1/gcc/ggc-common.c:704
#5  0x00000000005c575c in c_common_read_pch (pfile=0x42765800, name=0x4275dbc0
"conftest.h.gch", fd=4, 
    orig_name=0x4275dbb0 "conftest.h") at
../../gcc-4.8.1/gcc/c-family/c-pch.c:370
#6  0x00000000012f05f8 in should_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
    at ../../gcc-4.8.1/libcpp/files.c:787
#7  0x00000000012f097c in _cpp_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
    at ../../gcc-4.8.1/libcpp/files.c:872
#8  0x00000000012f0fe4 in _cpp_stack_include (pfile=0x42765800,
fname=0x4275db90 "conftest.h", angle_brackets=0, 
    type=IT_INCLUDE) at ../../gcc-4.8.1/libcpp/files.c:1008
#9  0x00000000012e1fc4 in do_include_common (pfile=0x42765800, type=IT_INCLUDE)
    at ../../gcc-4.8.1/libcpp/directives.c:793
#10 0x00000000012e2024 in do_include (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/directives.c:804
#11 0x00000000012e13dc in _cpp_handle_directive (pfile=0x42765800, indented=0)
    at ../../gcc-4.8.1/libcpp/directives.c:492
#12 0x00000000012f9dc4 in _cpp_lex_token (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/lex.c:1990
#13 0x0000000001306cec in cpp_get_token_1 (pfile=0x42765800,
location=0xffffffffffffb0b8)
    at ../../gcc-4.8.1/libcpp/macro.c:2355
#14 0x0000000001307330 in cpp_get_token_with_location (pfile=0x42765800,
loc=0xffffffffffffb0b8)
    at ../../gcc-4.8.1/libcpp/macro.c:2537
#15 0x00000000005b9484 in c_lex_with_flags (value=0xffffffffffffb0c0,
loc=0xffffffffffffb0b8, 
    cpp_flags=0xffffffffffffb0b2 "", lex_flags=0) at
../../gcc-4.8.1/gcc/c-family/c-lex.c:300
#16 0x00000000003b225c in cp_lexer_get_preprocessor_token (lexer=0x0,
token=0xffffffffffffb0b0)
    at ../../gcc-4.8.1/gcc/cp/parser.c:715
#17 0x00000000003f64e8 in cp_parser_initial_pragma
(first_token=0xffffffffffffb0b0)
    at ../../gcc-4.8.1/gcc/cp/parser.c:28139
#18 0x00000000003b1d98 in cp_lexer_new_main () at
../../gcc-4.8.1/gcc/cp/parser.c:585
#19 0x00000000003b6604 in cp_parser_new () at
../../gcc-4.8.1/gcc/cp/parser.c:3253
#20 0x00000000003f6b78 in c_parse_file () at
../../gcc-4.8.1/gcc/cp/parser.c:28335
#21 0x00000000005c30a0 in c_common_parse_file () at
../../gcc-4.8.1/gcc/c-family/c-opts.c:1046
#22 0x0000000000c5f230 in compile_file () at ../../gcc-4.8.1/gcc/toplev.c:543
#23 0x0000000000c62540 in do_compile () at ../../gcc-4.8.1/gcc/toplev.c:1864
#24 0x0000000000c62788 in toplev_main (argc=24, argv=0xffffffffffffb718) at
../../gcc-4.8.1/gcc/toplev.c:1940
#25 0x00000000012bc2c0 in main (argc=24, argv=0xffffffffffffb718) at
../../gcc-4.8.1/gcc/main.c:36

(gdb) print line_table
$6 = (line_maps *) 0x42e70000

(gdb) print *line_table
$16 = {info_ordinary = {maps = 0x114000000, allocated = 1, used = 1115871712,
cache = 0}, info_macro = {
    maps = 0x105000000, allocated = 0, used = 1117049688, cache = 0}, depth =
1, trace_includes = 55, 
  highest_location = 3, highest_line = 1117048808, max_column_hint = 0,
reallocator = 0x115000000, 
  round_alloc_size = 0, location_adhoc_data_map = {htab = 0x0, curr_loc = 1,
allocated = 335544320, data = 0x24282d9e0}}

The "used" fields look strange. Later in the same call it crashes:

Program received signal SIGSEGV, Segmentation fault.
0x00000000012fff88 in linemap_location_from_macro_expansion_p (set=0x42e70000,
location=19)
    at ../../gcc-4.8.1/libcpp/line-map.c:948
948       linemap_assert (location <= MAX_SOURCE_LOCATION
(gdb) bt
#0  0x00000000012fff88 in linemap_location_from_macro_expansion_p
(set=0x42e70000, location=19)
    at ../../gcc-4.8.1/libcpp/line-map.c:948
#1  0x00000000012ff31c in linemap_lookup (set=0x42e70000, line=19) at
../../gcc-4.8.1/libcpp/line-map.c:642
#2  0x000000000130065c in linemap_macro_loc_to_def_point (set=0x42e70000,
location=19, original_map=0xffffffffffffa1a8)
    at ../../gcc-4.8.1/libcpp/line-map.c:1134
#3  0x0000000001300934 in linemap_resolve_location (set=0x42e70000, loc=19,
lrk=LRK_MACRO_DEFINITION_LOCATION, 
    map=0xffffffffffffa1a8) at ../../gcc-4.8.1/libcpp/line-map.c:1263
#4  0x00000000012d4ab8 in diagnostic_report_current_module (context=0x17b28d0,
where=19)
    at ../../gcc-4.8.1/gcc/diagnostic.c:481

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381

--- Comment #1 from Martin Husemann <martin at netbsd dot org> ---
The global pointer "line_table" is changed to the contents of the precompiled
header file in gt_pch_restore in this loop:

  /* Read in all the global pointers, in 6 easy loops.  */
  for (rt = gt_ggc_rtab; *rt; rt++)
    for (rti = *rt; rti->base != NULL; rti++)
      for (i = 0; i < rti->nelt; i++)
        if (fread ((char *)rti->base + rti->stride * i,
                   sizeof (void *), 1, f) != 1)
          fatal_error ("can%'t read PCH file: %m");

but not reset to the previous values when the compiler decides to not use the
pch contents (for example because the address of the mmap differs).

We probably need to save at least line_table (and maybe input_location) at the
start of this function and restore it before invoking fatal_error.

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381

--- Comment #2 from Martin Husemann <martin at netbsd dot org> ---
Created attachment 30790
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790&action=edit
Restore line_table and input_location before calling fatal_error when failing a
pch load

With this patch, the fatal_error is properly reported:

> $BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch -Wno-deprecated -c conftest.cc
conftest.cc:1:0: fatal error: had to relocate PCH
 #include "conftest.h"
 ^
compilation terminated.

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

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

Martin Husemann <martin at netbsd dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.8.1                       |5.2.0

--- Comment #3 from Martin Husemann <martin at netbsd dot org> ---
This still applies to recent versions and is an obvious fix. Please apply!

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Husemann from comment #3)
> This still applies to recent versions and is an obvious fix. Please apply!

I personally would prefer to factor out all that repeated code into a function
pch_read_fatal_error() or to an exit label and use goto pch_read_fatal_error;

In any case, patches need to be submitted to gcc-patches@gcc.gnu.org. Reviewers
rarely look for patches in bugzilla. See point #8 in
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

You should perhaps include the name of the file being patched in the subject.
I'm not sure we have a maintainer for ggc anymore.
>From gcc-bugs-return-494276-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 06 09:30:31 2015
Return-Path: <gcc-bugs-return-494276-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 117727 invoked by alias); 6 Aug 2015 09:30:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 117689 invoked by uid 48); 6 Aug 2015 09:30:27 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc
Date: Thu, 06 Aug 2015 09:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.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:
Message-ID: <bug-58381-4-WHHZbpjPn6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58381-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58381-4@http.gcc.gnu.org/bugzilla/>
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-SW-Source: 2015-08/txt/msg00418.txt.bz2
Content-length: 362

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

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Husemann from comment #3)
> This still applies to recent versions and is an obvious fix. Please apply!

Points #7 and #8 in https://gcc.gnu.org/wiki/Community can help you to get your
patch through.
>From gcc-bugs-return-494277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 06 09:32:13 2015
Return-Path: <gcc-bugs-return-494277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 122202 invoked by alias); 6 Aug 2015 09:32:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 121994 invoked by uid 48); 6 Aug 2015 09:32:07 -0000
From: "ysrumyan at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code
Date: Thu, 06 Aug 2015 09:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ysrumyan at gmail dot com
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-56309-4-LCxpkJpKsi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56309-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56309-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00419.txt.bz2
Content-length: 1463

https://gcc.gnu.org/bugzilla/show_bug.cgi?idV309

--- Comment #33 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
With current compiler there is not performance difference for by-ref and by-val
test-cases, but if we turn off if-convert transformation we will get ~2X
speed-up:
on Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz

 ./t1.exe
Took 11.55 seconds total.
 ./t1.noifcvt.exe
Took 6.51 seconds total.

The test will be attached.
This is caused by skew conditional branch probabilities for the loop:

    for (auto rhs_it = rbegin; rhs_it != rend; ++rhs_it) {
            tmp = x*(*rhs_it) + data[i] + carry;
            if (tmp >= imax) {
                    carry = tmp >> numbits;
                    tmp &= imax - 1;
            } else {
                    carry = 0;
            }
            data[i++] = tmp;
    }

Only 2.5% conditional branches are not taken since imax represents MAX_INT32
and profile estimation phase needs to be fixed to set-up unlikely probability
for integral comparison with huge constants.
To coupe with this issue we may implement Jakub approach to design Oracle for
if-conversion profitability which simply computes region (loop) costs for
if-converted and not-if-converted regions ( cost of all acyclic paths).
Using such approach we can see that for fixed profile hammock predication is
not profitable and if vectorization will not be successful loop must be
restored to orginal one.