[Bug libstdc++/80662] libstdc++ basic_string casting oddity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libstdc++/80662] New: libstdc++ basic_string casting oddity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662 Bug ID: 80662 Summary: libstdc++ basic_string casting oddity Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug tree-optimization/80655] -Werror=format-truncation inconsistency between x86_32 and x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80655 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2017-05-06

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #8 from Keith Thompson --- That's a surprising interpretation of the word "amendment". Searching isocpp.org and other sites, I haven't found any official reference to an "amendment" to the C++ standard. The nearest thing I've

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #7 from Andrew Pinski --- (In reply to Keith Thompson from comment #6) > Shall I submit a separate ticket against the documentation? > > "info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and > std=++03: > >

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #6 from Keith Thompson --- Shall I submit a separate ticket against the documentation? "info gcc" for gcc-7.1.0 has the following description for -std=c=+98 and std=++03: 'c++98' 'c++03' The 1998 ISO C++

[Bug c++/80648] [DR903] Valid C++11 null pointer constant (1-1) is rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80648 --- Comment #5 from Jonathan Wakely --- Whether or not it's part of the standard has no bearing on whether it's a bug in GCC, because we don't claim to implement just the original published standard. GCC's policy is to implement the standard

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80280 --- Comment #4 from Volker Reichelt --- Author: reichelt Date: Sun May 7 19:41:09 2017 New Revision: 247728 URL: https://gcc.gnu.org/viewcvs?rev=247728=gcc=rev Log: PR translation/80280 * call.c (print_z_candidate): Fix

[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to janus from comment #6) > The regtest went pretty well, although I'm seeing these three failures: > > FAIL: gfortran.dg/coarray_lock_7.f90 -O scan-tree-dump-times original > FAIL:

[Bug c++/79664] ICE with #pragma omp parallel in constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79664 Volker Reichelt changed: What|Removed |Added Known to work||6.3.1, 7.1.0 Target Milestone|---

[Bug c++/79681] [6 Regression] ICE with constexpr and bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > This draft patch fixes the ICE on comment 0 and comment 4: > > [..] > > Regtesting now ... The regtest went pretty well, although I'm seeing these three

[Bug c++/79639] [6 Regression] ICE with -O and constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79639 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.0

[Bug fortran/79311] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code

[Bug c++/66153] Internal compiler error in nested template function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153 --- Comment #7 from Peter Boyle --- Signature of fail in 8.0.0 (head) is: ^~~~ prog.cc: In substitution of 'template Container(arg.data[0]))> function(const Container&) [with int N = 1; obj = ]': prog.cc:43:101:

[Bug c++/66153] Internal compiler error in nested template function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153 --- Comment #6 from Peter Boyle --- Just an update: Still fails in G++ 7.1.0 and in 8.0.0 (head) on Wandbox. Still passes in Clang 4.0.0 and 5.0.0(head).

[Bug fortran/80657] Loop in character function declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657 --- Comment #2 from Vittorio Zecca --- You do not get line numbers but offset in f951. Need rebuild with -g option or addr2line usage?

[Bug fortran/80645] [8 regression] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug tree-optimization/78496] [7/8 Regression] Missed opportunities for jump threading

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Sun May 7 15:10:55 2017 New Revision: 247727 URL: https://gcc.gnu.org/viewcvs?rev=247727=gcc=rev Log: 2017-05-07 Jeff Law Revert: 2017-05-06 Jeff

[Bug fortran/80657] Loop in character function declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80657 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/79072] ICE with class(*) pointer function result and character value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #7 from Dominique d'Humieres --- > Comment 5 code example gives incorrect results with the 7.1.0 release, > but correct results with 6.3 and 5.2 -- a regression. Likely caused by revision r241439. AFAICT this could be two different

[Bug testsuite/80661] New: make check-gcc RUNTESTFLAGS="dg.exp=g*" runs all the tests in gcc.dg

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80661 Bug ID: 80661 Summary: make check-gcc RUNTESTFLAGS="dg.exp=g*" runs all the tests in gcc.dg Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal

[Bug c++/80660] New: Member function pointer optimization affected by incompatible virtual function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80660 Bug ID: 80660 Summary: Member function pointer optimization affected by incompatible virtual function Product: gcc Version: 8.0 Status: UNCONFIRMED Severity:

[Bug c/79027] [8 Regression] fold-const.c:11104:1: internal compiler error: Floating point exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79027 --- Comment #8 from John David Anglin --- The error on the trunk is caused by the middle end trying to do a mode change between SImode and BLKmode. Tweaking pa_cannot_change_mode_class() to reject changes to/modes with zero size appears to fix

[Bug fortran/79072] ICE with class(*) pointer function result and character value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 neil.n.carlson at gmail dot com changed: What|Removed |Added Known to fail||7.1.0 --- Comment #6

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #30 from Thomas Koenig --- I think there still is one thing to do. Apparently, AMD CPUs (which use only vanilla at the moment) are slightly faster with -mprefer-avx128, and they should be much faster if they have FMA3. Unless I

[Bug fortran/68600] Inlined MATMUL is too slow.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING --- Comment #15 from Thomas

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658 --- Comment #1 from Marc Glisse --- I am not sure what you expect from this PR exactly. If you have issues about glibc's implementation of malloc, please see about it with glibc (here is for gcc only). They already know about the performance