[Bug ipa/62104] New: [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403

[Bug ipa/62104] New: [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403

[trippels at gcc dot gnu.org]

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

            Bug ID: 62104
           Summary: [4.10 Regression] ICE: in
                    update_visibility_by_resolution_info, at
                    ipa-visibility.c:403
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org

Fixefox PGO/LTO build fails on final libxul link (-fprofile-use phase):

lto1: internal compiler error: in update_visibility_by_resolution_info, at
ipa-visibility.c:403
0xe4cf20 update_visibility_by_resolution_info
        ../../gcc/gcc/ipa-visibility.c:400
0xe4d932 function_and_variable_visibility
        ../../gcc/gcc/ipa-visibility.c:557
0xe4ea56 whole_program_function_and_variable_visibility
        ../../gcc/gcc/ipa-visibility.c:745
0xe4ea56 execute
        ../../gcc/gcc/ipa-visibility.c:793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit
status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
/var/tmp/mozilla-central/config/rules.mk:829: recipe for target 'libxul.so'
failed

[Bug ipa/62104] [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
markus@x4 /tmp % wget trippelsdorf.de/testcase.tar.bz2
--2014-08-12 12:07:24--  http://trippelsdorf.de/testcase.tar.bz2
Resolving trippelsdorf.de... 194.117.254.50
Connecting to trippelsdorf.de|194.117.254.50|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3066810 (2.9M) [application/x-bzip2]
Saving to: ‘testcase.tar.bz2’

2014-08-12 12:07:25 (3.05 MB/s) - ‘testcase.tar.bz2’ saved [3066810/3066810]

markus@x4 /tmp % tar -xjf testcase.tar.bz2
markus@x4 /tmp % g++ XPCComponents.o Unified_cpp_js_xpconnect_src1.o jsarray.o
lto1: internal compiler error: in update_visibility_by_resolution_info, at
ipa-visibility.c:403
0xe4cf20 update_visibility_by_resolution_info
        ../../gcc/gcc/ipa-visibility.c:400
0xe4d932 function_and_variable_visibility
        ../../gcc/gcc/ipa-visibility.c:557
0xe4ea56 whole_program_function_and_variable_visibility
        ../../gcc/gcc/ipa-visibility.c:745
0xe4ea56 execute
        ../../gcc/gcc/ipa-visibility.c:793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit
status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
>From gcc-bugs-return-458250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 12 10:18:09 2014
Return-Path: <gcc-bugs-return-458250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17194 invoked by alias); 12 Aug 2014 10:18:06 -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 16820 invoked by uid 48); 12 Aug 2014 10:17:39 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
Date: Tue, 12 Aug 2014 10:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: lto
X-Bugzilla-Keywords: build, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-62077-4-kvo9G0qDiU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62077-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62077-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: 2014-08/txt/msg00747.txt.bz2
Content-length: 2403

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> Ok, so there is one thing that changed (but only very recently) on trunk
> which
> is improved hashing of SCCs and thus more consistent ordering.
>
> Especially I'm talking about the fact that at compile-time (!) we sort
> via
>
> static int
> scc_entry_compare (const void *p1_, const void *p2_)
> {
>   const scc_entry *p1 = (const scc_entry *) p1_;
>   const scc_entry *p2 = (const scc_entry *) p2_;
>   if (p1->hash < p2->hash)
>     return -1;
>   else if (p1->hash > p2->hash)
>     return 1;
>   return 0;
> }
>
> static hashval_t
> hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
> {
>   /* Compute hash values for the SCC members.  */
>   for (unsigned i = 0; i < size; ++i)
>     sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
>
>   if (size == 1)
>     return sccstack[first].hash;
>
>   /* Sort the SCC of type, hash pairs so that when we mix in
>      all members of the SCC the hash value becomes independent on
>      the order we visited the SCC.  Disregard hashes equal to
>      the hash of the tree we mix into because we cannot guarantee
>      a stable sort for those across different TUs.  */
>   qsort (&sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
>
> which means returning 0 from the qsort compare function for hash
> collisions.  In theory the qsort implementation can randomly permute
> stuff here leading to comparison fails.
>
> I'm checking if breaking the tie via the DFS number fixes the miscompare
> I saw.
>
> Note that I assumed that "sane" implementations would behave consistently
> here, but of course with address-space randomization and friends and an
> implementation that breaks tie itself via addresses would break.
> (I'd choose a simpler tie breaker - first argument to compare is less
> than second arg to compare).
>
> Well.  Not sure what glibc msort does here.
>
> That said, the smallest object I observe differences is build/genconfig.o
> which has differences in the size(!) of the LTO_section_decls section
> and differences already in the decl-state refs part.

Doesn't help.  The list of miscompared files seems to be reproducible at least,
but the actual file contents are different for two compiles.

[Bug ipa/62104] [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
My PGO/LTO Firefox build script contained an error that caused
jsarray.o to be erroneously build with -fprofile-generate during
the -fprofile-use phase. The .gcov symbols in that file caused the ICE.

Closing as invalid, because this will not normally happen in practice.