From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29329 invoked by alias); 30 Sep 2014 20:20:03 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29263 invoked by uid 48); 30 Sep 2014 20:19:57 -0000 From: "kaballo86 at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/62056] Long compile times with large tuples Date: Tue, 30 Sep 2014 20:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kaballo86 at hotmail dot com X-Bugzilla-Status: WAITING 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: In-Reply-To: References: 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: 2014-09/txt/msg02805.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D62056 --- Comment #10 from Agust=C3=ADn Berg=C3=A9 = --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #9) > I cannot say if the libstdc++ implementation could be better >>From a compile-time performance point of view it is, check the implementat= ion attached to this issue. > but the way to > prove it is simply to submit a new implementation and convince the > maintainers that it is better with numbers. I'm sure they will be delight= ed > to receive such contribution. But a draft is not enough. The new > implementation needs to pass all testcases in the testsuite. Such implementation and numbers were initially attached to this issue. The draft implementation is feature complete (modulo bugs) and is implemented w= ith the minimal possible number of changes from the current implementation. The entire functionality is retained, the layout is switch to left-to-right (instead of reversed), I have not analyzed codegen. I was directly instructed by libstdc++ developers to submit this issue, I w= as told they were not aware of the poor compile-time performance of tuple. I submitted the issue as instructed. I decided to add the proof-of-concept implementation so that people could understand the implications by simply replacing a header. I added the analysis of the underlying issue upon your request. I am not interested in pursuing this further without as much as a hint that= the compile-time performance issue would even be considered. Remember, this is = QoI, so completely ignoring this issue is a reasonable resolution. After all, th= is is a known issue with known solutions (or I should say workarounds, as the underlying issue is not addressed), and there are other concerns to keep in mind besides compile-time performance. >>From gcc-bugs-return-462972-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 20:44:11 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 12261 invoked by alias); 30 Sep 2014 20:44:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 12158 invoked by uid 55); 30 Sep 2014 20:44:06 -0000 From: "gerrit.los at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084 Date: Tue, 30 Sep 2014 20:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gerrit.los at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-09/txt/msg02806.txt.bz2 Content-length: 1938 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #7 from Gert-jan Los --- 2014-09-30 20:39:22 CEST schrieb trippels at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 > > --- Comment #6 from Markus Trippelsdorf --- > Ah, the system compiler was build slightly before Jason's > r215172 checkin from 20140911. > gcc version 4.9.2 20140911 (prerelease) (GCC) The code triggering the ICE has been part of my code base since at least 3 months. Within the project I used varying snaphots from trunk without any problems. I just retested with my system compiler [gcc version 4.9.1 (Debian 4.9.1-15)] and now also get: internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2066 To provide context I attached: a) backtrace b) bisect log c) check script for creduce and bisect d) my reduced testcase At every git-bisect step I did a full bootstrap $dir/$tgt/configure \ --prefix=$prefix \ --program-suffix=-snapshot \ --with-gmp=$prefix \ --with-mpfr=$prefix \ --with-mpc=$prefix \ --with-gnu-ld \ --enable-build-with-cxx --enable-cxx \ --enable-gold --enable-ld=default \ --enable-plugin --with-plugin-ld=ld.gold \ --enable-languages=c,c++ \ --enable-checking=release make -j4 bootstrap make install As you can see in bisect.log some checkouts did not trigger the internal compiler error. I now see one possible defect in my testing methodology: I'm grepping for the line number of the error message. Will retest with the fixed check condition and report back tomorrow if the outcome changes.