[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" <gcc-bugzilla@gcc.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.