[Bug libstdc++/62056] New: Long compile times with large tuples

[Bug libstdc++/62056] New: Long compile times with large tuples

[kaballo86 at hotmail dot com]

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

            Bug ID: 62056
           Summary: Long compile times with large tuples
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kaballo86 at hotmail dot com

Created attachment 33270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33270&action=edit
draft flat tuple implementation

The recursive implementation of `std::tuple` causes noticeable longer
compilation times and memory usage than a non-recursive implementation would.
Furthermore, with a max template depth of 256 (Clang's default), the following
test case results in a compilation error when attempting to use `make_tuple` 
with more than 17 arguments:

    #include <tuple>

    struct T {} t;

    int main()
    {
      auto tt = std::make_tuple(
        t, t, t, t, t, t, t, t,
        t, t, t, t, t, t, t, t,
        t, t
        );
      return sizeof(std::get<15>(tt));
    }

The times reported for building this example with one less argument to
`make_tuple` are:

 TOTAL                 :   0.45             34300 kB
 TOTAL (-O2)           :   0.37             28160 kB

With a flat implementation (draft attached), the times reported are:

 TOTAL                 :   0.31             21245 kB
 TOTAL (-O2)           :   0.21             18056 kB

With the default template depth limit of 900, the limit is reached with more
than 63 elements for the recursive implementation, and more than 253 elements
for the flat implementation (reached while building an `index_sequence`).

The times reported for building a similar example but with 63 elements are:

 TOTAL (recursive)     :   0.96            102293 kB
 TOTAL (recursive -O2) :   0.58             77839 kB
 TOTAL (flat)          :   0.27             33737 kB
 TOTAL (flat -O2)      :   0.20             27213 kB

[Bug libstdc++/62056] Long compile times with large tuples

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Piotr Dziwinski from comment #1)
> I would also second the proposal to fix this issue by implementing flat
> version of std::tuple. Perhaps the existing std::tr1::tuple implementation
> can be re-used here?

GCC's std::tr1:tuple is not a flat implementation, and does not conform to the
C++11 requirements, so no, that's not an option.

[Bug c++/62056] Long compile times with large tuples

[piotrdz at gmail dot com]

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

--- Comment #3 from Piotr Dziwinski <piotrdz at gmail dot com> ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Piotr Dziwinski from comment #1)
> > I would also second the proposal to fix this issue by implementing flat
> > version of std::tuple. Perhaps the existing std::tr1::tuple implementation
> > can be re-used here?
> 
> GCC's std::tr1:tuple is not a flat implementation, and does not conform to
> the C++11 requirements, so no, that's not an option.

Oh, you're right - somehow I got convinced that std::tr1::tuple was a flat
implementation since it compiles so much faster. But this raises a question -
why do the two recursive implementations have such different compile times?
Perhaps by analyzing the differences between std::tr1::tuple and std::tuple, we
can learn something to our advantage?

[Bug c++/62056] Long compile times with large tuples

[piotrdz at gmail dot com]

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

--- Comment #5 from Piotr Dziwinski <piotrdz at gmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> tr1::tuple doesn't support perfect-forwarding or move semantics
> 
> tr1::tuple doesn't support uses-allocator construction
> 
> tr1::tuple doesn't support 'final' classes
> 
> tr1::tuple doesn't have correct exception specifications
> 
> tr1::tuple doesn't prevent implicit conversions that would use explicit
> constructors
> 
> tr1::tuple doesn't support tuple concatenation
> 
> If you can add all those features to the <tr1/tuple> implementation so that
> it meets the C++11 requirements and it still compiles faster then I'd be
> interested in your analysis of the remaining differences. Otherwise I'm
> going to assume the difference is because the <tuple> header contains more
> than twice as many lines of code and several additional features.

Ok, I understand it now. I was speaking from only somewhat experienced user
perspective and I did not realise the deeper implications of standard
compliance.

Just for the record, I did some testing and found two important factors here
are:
 - dependency to <array> (to enable it in tuple concatenation) - (change in
compile time 0.357s -> 0.231s),
 - allocator constructors - (change 0.231s -> 0.185s).

So in the end please ignore my interruption with `std::tr1::tuple`. It seems
the recursive version of `std::tuple` is not going to be optimized easily and
the new flat implementation is the way to go here.

[Bug c++/62056] Long compile times with large tuples

[kaballo86 at hotmail dot com]

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

--- Comment #6 from Agustín Bergé <kaballo86 at hotmail dot com> ---
(In reply to Piotr Dziwinski from comment #5)
> It seems
> the recursive version of `std::tuple` is not going to be optimized easily
> and the new flat implementation is the way to go here.

Well, not necessarily, It's not `std::tuple` which is at fault, but the
compiler (gcc and every other). Note that this issue was moved from libstdc++
to c++, so that's promising!
>From gcc-bugs-return-462935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 14:13:19 2014
Return-Path: <gcc-bugs-return-462935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6101 invoked by alias); 30 Sep 2014 14:13:18 -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 6057 invoked by uid 48); 30 Sep 2014 14:13:13 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
Date: Tue, 30 Sep 2014 14:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: vries at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-61605-4-rKfDT4SrE3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61605-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61605-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-09/txt/msg02769.txt.bz2
Content-length: 359

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |vries at gcc dot gnu.org

[Bug c++/62056] Long compile times with large tuples

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Agustín Bergé from comment #8)
> Please let me know if I can help you in any other way.

Thanks for the detailed explanation.


As for the g++ issue, then a minimal testcase that does not include the whole
of <tuple> might be useful to see what could be speed up: See
https://gcc.gnu.org/bugs/minimize.html The testcase itself might generate code
programmatically using macros, for example, but less code without any headers
is easier to analyze.

I cannot say if the libstdc++ implementation could be better, 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 delighted to receive such
contribution. But a draft is not enough. The new implementation needs to pass
all testcases in the testsuite.
>From gcc-bugs-return-462963-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 17:41:51 2014
Return-Path: <gcc-bugs-return-462963-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16564 invoked by alias); 30 Sep 2014 17:41:51 -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 16499 invoked by uid 48); 30 Sep 2014 17:41:47 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
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 17:41: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: doko 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc cf_known_to_work short_desc cf_known_to_fail
Message-ID: <bug-63405-4-IuNan6oXHf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63405-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63405-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-09/txt/msg02797.txt.bz2
Content-length: 780

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at gcc dot gnu.org
      Known to work|4.9.2                       |
            Summary|[5 regression] ICE in       |[4.9/5 regression] ICE in
                   |cp_perform_integral_promoti |cp_perform_integral_promoti
                   |ons, at cp/typeck.c:2084    |ons, at cp/typeck.c:2084
      Known to fail|                            |4.9.1

--- Comment #3 from Matthias Klose <doko at gcc dot gnu.org> ---
you need -fstack-protector or -fstack-protector-strong to reproduce this.

[Bug c++/62056] Long compile times with large tuples

[kaballo86 at hotmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5605 bytes --]

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

--- Comment #10 from Agustín Bergé <kaballo86 at hotmail dot com> ---
(In reply to Manuel López-Ibáñez 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 implementation
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 delighted
> 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 with
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 was
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, this
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: <gcc-bugs-return-462972-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 12158 invoked by uid 55); 30 Sep 2014 20:44:06 -0000
From: "gerrit.los at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
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: <bug-63405-4-66aRsfBfej@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63405-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63405-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-09/txt/msg02806.txt.bz2
Content-length: 1938

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

--- Comment #7 from Gert-jan Los <gerrit.los at gmail dot com> ---
2014-09-30 20:39:22 CEST schrieb trippels at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?idc405
>
> --- Comment #6 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
> 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Þfault \
                        --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.

[Bug c++/62056] Long compile times with large tuples

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Jonathan, what should we do about this? Is this implementation better than the
one in libstdc++?

If so, what steps are needed to get this integrated?
>From gcc-bugs-return-463061-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 20:37:32 2014
Return-Path: <gcc-bugs-return-463061-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12128 invoked by alias); 1 Oct 2014 20:37:32 -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 12090 invoked by uid 48); 1 Oct 2014 20:37:27 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/62056] Long compile times with large tuples
Date: Wed, 01 Oct 2014 20:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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: component
Message-ID: <bug-62056-4-zXdYYizlyD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62056-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: 2014-10/txt/msg00082.txt.bz2
Content-length: 577

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I think this is a libstdc++ issue for now. It would be nice to have a simpler
testcase for the g++ compile time problem, then we can open a different
independent report.
>From gcc-bugs-return-463062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 20:41:08 2014
Return-Path: <gcc-bugs-return-463062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15527 invoked by alias); 1 Oct 2014 20:41:08 -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 15237 invoked by uid 55); 1 Oct 2014 20:41:02 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation
Date: Wed, 01 Oct 2014 20:41: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: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63428-4-5JQanyDkH5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63428-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63428-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-10/txt/msg00083.txt.bz2
Content-length: 611

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Oct  1 20:40:29 2014
New Revision: 215776

URL: https://gcc.gnu.org/viewcvs?rev!5776&root=gcc&view=rev
Log:
    PR target/63428
    * config/i386/i386.c (expand_vec_perm_pshufb): Fix up rperm[0]
    argument to avx2_permv2ti.

    * gcc.dg/torture/vshuf-4.inc: Move test 122 from EXPTESTS
    to test 24 in TESTS.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/vshuf-4.inc

[Bug libstdc++/62056] Long compile times with large tuples

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug libstdc++/62056] Long compile times with large tuples

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
             Status|WAITING                     |NEW

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Thus, I guess this is confirmed, just waiting for a review.
>From gcc-bugs-return-463078-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 01 23:38:37 2014
Return-Path: <gcc-bugs-return-463078-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27509 invoked by alias); 1 Oct 2014 23:38:36 -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 27480 invoked by uid 48); 1 Oct 2014 23:38:33 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61489] Wrong warning with -Wmissing-field-initializers.
Date: Wed, 01 Oct 2014 23:38: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: 4.9.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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: cc
Message-ID: <bug-61489-4-GVhPFRolN0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61489-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61489-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: 2014-10/txt/msg00099.txt.bz2
Content-length: 528

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

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

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

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Daniel Sommermann from comment #10)
> Which release will this go out in?

GCC 5.1.0 presumably.
>From gcc-bugs-return-463079-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 02 01:13:42 2014
Return-Path: <gcc-bugs-return-463079-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24175 invoked by alias); 2 Oct 2014 01:13:38 -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 24157 invoked by uid 48); 2 Oct 2014 01:13:33 -0000
From: "xhzcomputer at 126 dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/63436] New: libgcc2.c:273:1: internal compiler error: Segmentation fault
Date: Thu, 02 Oct 2014 01:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: xhzcomputer at 126 dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63436-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-10/txt/msg00100.txt.bz2
Content-length: 1437

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

            Bug ID: 63436
           Summary: libgcc2.c:273:1: internal compiler error: Segmentation
                    fault
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xhzcomputer at 126 dot com

My Steps are as follows:
$./gcc-4.7.2/configure --prefix=$CROSS_GCC_TMP --target=$TARGET
--with-sysroot=$SYSROOT --with-newlib --enable-languages=c
--with-mpfr-include=/vita/build/gcc-4.7.2/mpfr/src
--with-mpfr-lib=/vita/build/gcc-build/mpfr/src/.libs --disable-shared
--disable-threads --disable-decimal-float --disable-libquadmath
--disable-libmudflap --disable-libgomp --disable-nls --disable-libssp
$make
Then errors are coming:

.......
../../../gcc-4.7.2/libgcc/libgcc2.c: In function '__absvdi2':
../../../gcc-4.7.2/libgcc/libgcc2.c:273:1: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [_absvdi2.o] Error 1
make[2]: Leaving directory `/vita/build/gcc-build/i686-none-linux-gnu/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/vita/build/gcc-build'
make: *** [all] Error 2



How to resolve it?Someone help me please.

[Bug libstdc++/62056] Long compile times with large tuples

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #11)
> Jonathan, what should we do about this? Is this implementation better than
> the one in libstdc++?

I don't know, I haven't looked.

Agustin, do you have a copyright assignment?
>From gcc-bugs-return-463097-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 02 09:07:27 2014
Return-Path: <gcc-bugs-return-463097-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32494 invoked by alias); 2 Oct 2014 09:07:26 -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 32437 invoked by uid 48); 2 Oct 2014 09:07:20 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63362] The c++11 triviality-traits need front-end help
Date: Thu, 02 Oct 2014 09:07: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: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
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: bug_status resolution
Message-ID: <bug-63362-4-Ew7487qUVa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63362-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-10/txt/msg00118.txt.bz2
Content-length: 448

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Can be closed now.

[Bug libstdc++/62056] Long compile times with large tuples

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Agustín Bergé from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Agustin, do you have a copyright assignment?
> 
> I do not have one. The attached <tuple> is derived from libstdc++'s <tuple>
> and I have left the license in place, wouldn't that be enough?

No. You are free to release your derived work under the terms of the GPL, but
that is not sufficient for the code to be accepted into the FSF repository.

> I did not
> intend for the attachment to be a patch (it is not a patch, I did not
> consider coding styles, I did not run tests, etc), but merely a proof of
> concept implementation so that others could measure the compile-time
> performance win of a flat implementation.

And that's fine. But to respond to Manu in comment 11 and comment 13, we need
more than just a review, since the proof of concept attached here cannot be
used without the usual legal prerequisites being met. Another option would be
for someone else to provide a flat implementation, but again that is more than
just a review.
>From gcc-bugs-return-463440-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 11:32:08 2014
Return-Path: <gcc-bugs-return-463440-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14557 invoked by alias); 7 Oct 2014 11:32:08 -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 14529 invoked by uid 48); 7 Oct 2014 11:32:04 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/56383] error with multiple enable_shared_from_this base classes
Date: Tue, 07 Oct 2014 11:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on target_milestone everconfirmed
Message-ID: <bug-56383-4-3N5YcZGGpM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56383-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56383-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-10/txt/msg00461.txt.bz2
Content-length: 454

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-07
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1