[Bug libstdc++/86450] Bootstrap failure due to -Wabi

2018-07-10 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #15 from Thomas Koenig --- (In reply to Jonathan Wakely from comment #11) > (In reply to Thomas Koenig from comment #9) > > (In reply to Jonathan Wakely from comment #7) > > > These warnings have been present for weeks - the idea that

[Bug libstdc++/86450] Bootstrap failure due to -Wabi

2018-07-10 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #16 from Steve Kargl --- On Tue, Jul 10, 2018 at 09:40:16PM +, redi at gcc dot gnu.org wrote: > > > There is an obvious patch. > > I will commit my patch by the end of the day, > > or revert the patch causing the problem. > > O

[Bug libstdc++/86450] Bootstrap failure due to -Wabi

2018-07-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #17 from Jonathan Wakely --- The problem is that gfortran development is dependent on a gcc-wide build mode which affects more than just gfortran. There's no good reason that libstdc++ should be a blocker for you (for the record, the

[Bug debug/86459] [9 Regression] ICE in output_macinfo_op, at dwarf2out.c:28095 since r260297

2018-07-10 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug libstdc++/86471] New: GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

2018-07-10 Thread mattreecebentley at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 Bug ID: 86471 Summary: GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays Product: gcc Version: 7.3.0 Status: UNCONFIRMED

[Bug libstdc++/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

2018-07-10 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #1 from Andrew Pinski --- Does -O3 bring the performance back? -O3 enables loop distrubtion which should be able to detect these loops.

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

2018-07-10 Thread mattreecebentley at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #2 from Matt Bentley --- (In reply to Andrew Pinski from comment #1) > Does -O3 bring the performance back? -O3 enables loop distrubtion which > should be able to detect these loops. Just tested - yes. However this is a fairly trivi

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

2018-07-10 Thread mattreecebentley at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #3 from Matt Bentley --- I thought I should note that there is also a missing optimization opportunity in the code. Clang optimizes the code I've listed to remove the benchmark loops entirely since it detects that the arrays aren't ac

[Bug debug/86459] [9 Regression] ICE in output_macinfo_op, at dwarf2out.c:28095 since r260297

2018-07-10 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459 --- Comment #3 from Mark Wielaard --- Author: mark Date: Tue Jul 10 22:44:30 2018 New Revision: 262545 URL: https://gcc.gnu.org/viewcvs?rev=262545&root=gcc&view=rev Log: PR debug/86459 - Fix -gsplit-dwarf -g3 gcc_assert There was a typo in the

[Bug debug/86459] [9 Regression] ICE in output_macinfo_op, at dwarf2out.c:28095 since r260297

2018-07-10 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/86450] Bootstrap failure due to -Wabi

2018-07-10 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #18 from Steve Kargl --- On Tue, Jul 10, 2018 at 10:11:54PM +, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 > > --- Comment #17 from Jonathan Wakely --- > The problem is that gfortran devel

[Bug fortran/86472] New: allocatable array, bound-procedure, submodule

2018-07-10 Thread jfeng33 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86472 Bug ID: 86472 Summary: allocatable array, bound-procedure, submodule Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fo

[Bug c++/86473] New: a problem in member lookup?

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86473 Bug ID: 86473 Summary: a problem in member lookup? Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assigne

[Bug c++/86474] New: a problem in member lookup?

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86474 Bug ID: 86474 Summary: a problem in member lookup? Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assigne

[Bug c++/86475] New: CWG 1550

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86475 Bug ID: 86475 Summary: CWG 1550 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gc

[Bug c++/86476] New: Members declared later in a class appear to be unavailable

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476 Bug ID: 86476 Summary: Members declared later in a class appear to be unavailable Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Pri

[Bug c++/86477] New: failure binding reference to vector element

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86477 Bug ID: 86477 Summary: failure binding reference to vector element Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/86478] New: Crashed on legal code

2018-07-10 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86478 Bug ID: 86478 Summary: Crashed on legal code Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: una

[Bug c++/86477] failure binding reference to vector element

2018-07-10 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86477 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/86477] failure binding reference to vector element

2018-07-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86477 --- Comment #2 from Marc Glisse --- We don't have attribute ext_vector_type (we have vector_size). Gcc warns about it. We don't allow constructing a vector from a scalar (broadcasting). What Andrew says. If I fix everything, binding a reference w

[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

2018-07-10 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #4 from Marc Glisse --- There have been questions before about enabling (parts of) ldist at -O2. (In reply to Matt Bentley from comment #3) > I thought I should note that there is also a missing optimization > opportunity in the code

<    1   2