[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85302 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-10 Version|7.3.1 |8.0.1 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed on x86_64-linux with > ./cc1plus -quiet t.ii -std=c++11 -gsplit-dwarf -O1 -m32 -fPIE t.ii:11:27: internal compiler error: in size_of_loc_descr, at dwarf2out.c:1771 void f() { e.d(""); } ^ 0xd68549 size_of_loc_descr ../../src/trunk/gcc/dwarf2out.c:1771 0xd689b5 size_of_locs(dw_loc_descr_node*) ../../src/trunk/gcc/dwarf2out.c:1967 0xd75a7d skip_loc_list_entry ../../src/trunk/gcc/dwarf2out.c:10047 0xdaf70d index_location_lists as Jakub said -gsplit-dwarf is unmaintained (and I hope it gets purged at some point). #1 0x00d6854a in size_of_loc_descr (loc=0x76c66e10) at ../../src/trunk/gcc/dwarf2out.c:1771 1771 gcc_assert (loc->dw_loc_oprnd1.val_entry->index != NO_INDEX_ASSIGNED); (gdb) l 1766case DW_OP_addr: 1767 size += DWARF2_ADDR_SIZE; 1768 break; 1769case DW_OP_GNU_addr_index: 1770case DW_OP_GNU_const_index: 1771 gcc_assert (loc->dw_loc_oprnd1.val_entry->index != NO_INDEX_ASSIGNED);
[Bug lto/85078] [8 Regression] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jan Hubicka --- Fixed.
[Bug lto/85078] [8 Regression] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078 --- Comment #11 from Jan Hubicka --- Author: hubicka Date: Tue Apr 10 06:33:38 2018 New Revision: 259264 URL: https://gcc.gnu.org/viewcvs?rev=259264&root=gcc&view=rev Log: PR lto/85078 * ipa-devirt.c (rebuild_type_inheritance-hash): New. * ipa-utils.h (rebuild_type_inheritance-hash): Declare. * tree.c (free_lang_data_in_type): Fix handling of binfos; walk basetypes. (free_lang_data): Rebuild type inheritance graph. * g++.dg/torture/pr85078.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr85078.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/ipa-utils.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug testsuite/85306] [8 regression] Test case g++.dg/pr80463.C fails in r259231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85306 --- Comment #1 from Andrey Belevantsev --- Jakub has added -w to the test options in r259249. I'm sorry I have missed this one when committing. If this works for you now, I think you can close the PR.
[Bug c++/85311] New: const& aggregate parameter with empty default brace initializer results in undefined references to std containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85311 Bug ID: 85311 Summary: const& aggregate parameter with empty default brace initializer results in undefined references to std containers Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vis...@royal-caliber.com Target Milestone: --- Created attachment 43890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43890&action=edit preprocessed output Hello, The following code fails to link: --test.cpp-- #include struct Foo { std::vector x; }; void foo(const Foo& = {}) { } int main() { foo(); } --- $ g++ test.cpp /tmp/ccJsJY1c.o: In function `main': test.cpp:(.text+0x2a): undefined reference to `std::vector >::vector()' collect2: error: ld returned 1 exit status The problem is triggered by the default value for the parameter to foo(). It can be avoided by either changing the prototype of foo() to not have a default value, or by actually providing a value in the call to foo(). The same behavior occurs with several other std containers inside the aggregate such as deque and list. It can be reproduced in gcc versions 6.4.0, 7.2.0 and 7.3.0 and libstdc++ versions 6.0.22 and 6.0.24. The preprocessed file is attached. The output of g++ -v follows. Thank you, Vishal Output of "g++-7.3 -v -save-temps test.cpp" Using built-in specs. COLLECT_GCC=g++-7.3 COLLECT_LTO_WRAPPER=/home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --enable-languages=c,c++ --prefix=/home/vishal/localbuild --program-suffix=-7.3 --disable-multilib Thread model: posix gcc version 7.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0 /home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/x86_64-pc-linux-gnu /home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward /home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include /home/vishal/localbuild/include /home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o test.s GNU C++14 (GCC) version 7.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.3-p4, MPC version 1.0.2, isl version none warning: GMP header version 6.1.0 differs from library version 6.1.2. warning: MPFR header version 3.1.3-p4 differs from library version 3.1.6. warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (GCC) version 7.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.3-p4, MPC version 1.0.2, isl version none warning: GMP header version 6.1.0 differs from library version 6.1.2. warning: MPFR header version 3.1.3-p4 differs from library version 3.1.6. warning: MPC header version 1.0.2 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e93c907a87f28f1e65d001f94ea5afa5 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o test.o test.s GNU assembler version 2.29.1 (x86_64-pc-linux-gnu) using BFD version (Gentoo 2.29.1 p3) 2.29.1 COMPILER_PATH=/home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/:/home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/:/home/vishal/localbuild/libexec/gcc/x86_64-pc-linux-gnu/:/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/:/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/:/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/vishal/localbuild/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #20 from Eric Botcazou --- > This comment could be important: > > https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte- > stack-alignment-required-for-avx-on-windows- > x64?noredirect=1#comment86499640_30928265. As already said, MSVC does something completely different (it realigns the frame instead of the stack) and we cannot do that; the model must be Clang instead.
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 --- Comment #6 from Dmitry Vyukov --- It seems to me that compiler is fine here and we just have a bug in kernel code. Result of strlen called on char[16] can't possibly by >15 (without causing undefined behavior -- reading past the end of the object -- in which case result and anything else does not matter). So the "if (res >= 16) res = 15" check is always a no-op and can be removed (for programs without undefined behavior). In this program strlen returns 32, but that's because the program contains undefined behavior -- you can't call strlen on non-zero-terminated objects.
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 --- Comment #5 from Andrew Pinski --- (In reply to Kees Cook from comment #4) > But it's optimizing away the check. That what undefined means. > If strlen() were suddenly acting like > strnlen(), that'd be one thing, but the return value from strlen() is being > used by the memcpy() without the actual test in between. That's not sensible. It is undefined if strlen reads past an array bounds, so in theory it could have zero'ed out your whole hard drive and sent your boss an email saying you quit.
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 --- Comment #4 from Kees Cook --- But it's optimizing away the check. If strlen() were suddenly acting like strnlen(), that'd be one thing, but the return value from strlen() is being used by the memcpy() without the actual test in between. That's not sensible.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #19 from Royi --- This comment could be important: https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64?noredirect=1#comment86499640_30928265. Hopefully you'll find a way to bring AVX to Windows 64 using GCC. Thank You.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #5 from Eric Gallager --- (In reply to René J.V. Bertin from comment #4) > Any news on this front? Last I heard from Iain he was still having to deal with water damage to his office...
[Bug preprocessor/39533] [6/7/8 Regression] -MM may list a header file twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #21 from Eric Gallager --- (In reply to Eric Gallager from comment #20) > GCC 5 branch is being closed. > > (Why is this still in WAITING?) Closing due to rule that bugs in WAITING for 3 or more months with no response can be closed.
[Bug bootstrap/45174] Make fails in zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #31 from Eric Gallager --- (In reply to Eric Gallager from comment #30) > Is there a reason this bug is still in WAITING? No response; I'm going to close this.
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- If they want to optimize based on the size of the array then disable the builtin (and don't use The __builtin_ specific function). Basically this code is undefined and can do anything. If anything maybe strnlen should be used instead...
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 Kees Cook changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Kees Cook --- I realize the compiler would like like it to be undefined, but it's just not: this worked before, and there's nothing about a static-sized character array that says it will be NULL terminated. No optimization of strlen() can make that assumption, since it's the _contents_ and not the _size_ that determine the results of strlen(). Specifically, this breaks the Linux kernel's FORTIFY_SOURCE implementation, which is exactly trying to protect against these kinds of unexpected memory contents, etc. With the ? : optimized away FORITFY_SOURCE ends up becoming actively dangerous.
[Bug c++/84221] [6/7 Regression] spurious -Wunused warning on a variable of a template type declared unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84221 --- Comment #5 from Martin Sebor --- As per subsequent discussion (https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00203.html and follow-ups), the warning in the original test case is expected and desirable. The patch in r259098 doesn't change that but has GCC issue a warning for uses of the primary template.
[Bug c/85310] optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This code is undefined as the strlen of src is undefined as the you read past the end of the src array.
[Bug c/85310] New: optimization ignoring strlen() results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85310 Bug ID: 85310 Summary: optimization ignoring strlen() results Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kees at outflux dot net Target Milestone: --- Created attachment 43889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43889&action=edit test case Something is gcc 8 is broken when dealing with strlen() results. The correct behavior is seen in earlier versions of the compiler: $ gcc --version gcc (Ubuntu 7.3.0-14ubuntu1) 7.3.0 ... $ gcc -Wall -O2 -o testcase testcase.c $ ./testcase MY_SIZE: 16 dst: 15 done... The bad version happens in the current gcc trunk: $ /home/kees/bin/gcc-snapshot/gcc --version gcc (Ubuntu 20180322-1ubuntu1) 8.0.1 20180322 (experimental) [trunk revision 258755] ... $ /home/kees/bin/gcc-snapshot/gcc -Wall -O2 -o testcase testcase.c $ ./testcase MY_SIZE: 16 dst: 32 done... Segmentation fault (core dumped) Checking with godbolt confirms there is no test against "16" in the output: https://godbolt.org/g/63Sbir
[Bug demangler/85309] New: demangler failed with signal 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85309 Bug ID: 85309 Summary: demangler failed with signal 11 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: lyberta at lyberta dot net Target Milestone: --- Try to run my C++17 application under GDB I get: /build/gdb-uGdIdO/gdb-7.12/gdb/cp-support.c:1600: demangler-warning: unable to demangle '_ZSt7forwardIRZN3ftz6Engine20ClientNetworkHandler13ProcessEventsEvEUlRT_E_EOS3_RNSt16remove_referenceIS3_E4typeE' (demangler failed with signal 11) Unable to dump core, use `ulimit -c unlimited' before executing GDB next time. /build/gdb-uGdIdO/gdb-7.12/gdb/cp-support.c:1615: demangler-warning: unable to demangle '_ZSt7forwardIRZN3ftz6Engine20ClientNetworkHandler13ProcessEventsEvEUlRT_E_EOS3_RNSt16remove_referenceIS3_E4typeE' (demangler failed with signal 11) It is a lambda inside ftz::Engine::ClientNetworkHandler::ProcessEvents.
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #20 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00424.html
[Bug c++/85227] [7 Regression] ICE with structured binding of a forward declared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85227 Paolo Carlini changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |structured binding of a |structured binding of a |forward declared variable |forward declared variable --- Comment #4 from Paolo Carlini --- Fixed int trunk so far.
[Bug c++/85227] [7/8 Regression] ICE with structured binding of a forward declared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85227 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Apr 9 22:33:35 2018 New Revision: 259259 URL: https://gcc.gnu.org/viewcvs?rev=259259&root=gcc&view=rev Log: /cp 2018-04-09 Paolo Carlini PR c++/85227 * decl.c (cp_finish_decomp): In a template, if the type is incomplete issue a pedwarn and defer trying to do bindings. /testsuite 2018-04-09 Paolo Carlini PR c++/85227 * g++.dg/cpp1z/decomp44.C: New. * g++.dg/cpp1z/decomp45.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp44.C trunk/gcc/testsuite/g++.dg/cpp1z/decomp45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Milestone|8.0 |9.0 --- Comment #4 from Jeffrey A. Law --- So the general guidance we got earlier from Richie was to defer the missing warnings until gcc-9.
[Bug c++/85308] Stringstream constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85308 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- That's not a bug, it's how stringstream is supposed to work. Use std::stringstream con(BEFORE, std::ios::in|std::ios::out|std::ios::ate); if you want insertions to happen at the end, after the initial value.
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- So I went and found pr68548 which is related, but clearly different. Just thinking out loud here, I think we can pick up this missed jump thread by recording _1 & 1 == 0 on the false edge of the first conditional (when we know that _1 & 3 == 0). It doesn't scale well in the general case, but when there's just a few bits in the mask it might be reasonable. That ought to allow us to determine that _4 == 0 when bb4 is reached via bb2 and thread the jump. Not planning to look at any implementation for gcc-8 though.
[Bug fortran/83064] DO CONCURRENT and auto-parallelization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 Thomas Koenig changed: What|Removed |Added Keywords|wrong-code |missed-optimization Target Milestone|8.0 |9.0 Summary|[8 Regression] DO |DO CONCURRENT and |CONCURRENT inconsistent |auto-parallelization |results | --- Comment #27 from Thomas Koenig --- I have committed the workaround. This is no longer a regression, removing the regression marker. If autopar is modified so that the parallel annotation works with DO CONCURRENT, one needs to search for the string "PR 83064" for the part that needs to be undone to remove the workaround.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #9 from Eric Botcazou --- > Or build them in-tree, which automatically builds them that way. That avoids > the need to install them separately at all. You may need to control which version you build on specific platforms though so I wouldn't recommend in-tree build.
[Bug fortran/83064] [8 Regression] DO CONCURRENT inconsistent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 --- Comment #26 from Thomas Koenig --- Author: tkoenig Date: Mon Apr 9 21:52:05 2018 New Revision: 259258 URL: https://gcc.gnu.org/viewcvs?rev=259258&root=gcc&view=rev Log: 2018-04-09 Thomas Koenig PR fortran/83064 * trans-stmt.c (gfc_trans_forall_loop): Remove annotation for parallell processing of DO CONCURRENT -ftree-parallelize-loops is set. 2018-04-09 Thomas Koenig PR fortran/83064 * gfortran.dg/do_concurrent_5.f90: New test. * gfortran.dg/vect/vect-do-concurrent-1.f90: Adjust dg-bogus message. Added: trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect-do-concurrent-1.f90
[Bug debug/65821] [6/7/8 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Koenig --- Fixed, closing.
[Bug c++/85308] New: Stringstream constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85308 Bug ID: 85308 Summary: Stringstream constructor fails Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: cwgii_bccg at julianlocals dot com Target Milestone: --- Created attachment 43888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43888&action=edit -save-temps and example When specifying an initial value in a std::streamstring to resulting value of the item is wrong.
[Bug c++/85279] [6/7/8 Regression] Broken diagnostic for decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85279 --- Comment #1 from Jason Merrill --- Author: jason Date: Mon Apr 9 21:16:05 2018 New Revision: 259257 URL: https://gcc.gnu.org/viewcvs?rev=259257&root=gcc&view=rev Log: PR c++/85279 - dump_expr doesn't understand decltype. * error.c (dump_expr): Handle DECLTYPE_TYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype67.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug fortran/85307] New: Consistent handling of out-of-bounds access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85307 Bug ID: 85307 Summary: Consistent handling of out-of-bounds access Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Currently, we sometimes issue errors and mostly issue warnings for when a compile-time out-of-bounds-access is detected. Example: a.f90:4:30: integer, parameter :: x = b(4) 1 Error: Index in dimension 1 is out of bounds at (1) a.f90:5:12: print *,b(2:4) 1 Warning: Upper array reference at (1) is out of bounds (4 > 3) in dimension 1 a.f90:6:12: print *,b(4) 1 Warning: Array reference at (1) is out of bounds (4 > 3) in dimension 1 a.f90:8:14: do i=1,5 2 print *,b(i) 1 Warning: Array reference at (1) out of bounds (5 > 3) in loop beginning at (2) At the very least, the warnings about the parameter array should be hard errors, and possibly others as well. Let the discussions begin :-)
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #8 from Jonathan Wakely --- (In reply to Eric Botcazou from comment #4) > I personally build the GMP/MPFR/MPC libraries with --disable-shared. Or build them in-tree, which automatically builds them that way. That avoids the need to install them separately at all. https://gcc.gnu.org/wiki/InstallingGCC
[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Mon Apr 9 21:05:13 2018 New Revision: 259256 URL: https://gcc.gnu.org/viewcvs?rev=259256&root=gcc&view=rev Log: 2018-04-09 Thomas Koenig PR fortran/51260 * resolve.c (resolve_variable): Simplify cases where access to a parameter array results in a single constant. 2018-04-09 Thomas Koenig PR fortran/51260 * gfortran.dg/parameter_array_element_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_element_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #7 from Michael Teske --- (In reply to Eric Botcazou from comment #6) > > Why not add the directory to the RPATH of the created binaries? ... > > Are there any reasons against > > doing it? > > Yes, I don't think that we want to hardcode run-time paths by default. Usually, RPATH does not hardcode the run time path library path, it is still overridable with LD_LIBRARY_PATH, it just provides a default if LD_LIBRARY_PATH is not set. IMHO it would be convenient to have the possibility (need not be the default, just an option to configure) to have gcc finding it's library in the locations where they were when gcc was built. If one needs to have different versions of some utilities (possibly pre-built from different sources) it can be difficult if not impossible to maintain a useful LD_LIBRARY_PATH. Anyway, luckily the rpath tool exists for solaris so I can "tune" the gcc binaries after the build.
[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #3 from Pat Haugen --- (In reply to Jan Hubicka from comment #1) > Pat, can you try to figure out what value of min-speedup is neeed to recover > from this regression? Using r257582, either of the following options restores the behavior of not inlining the mainGtU call and eliminates the performance regression. --param inline-min-speedup=18 --param max-inline-insns-auto=24
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Will Hawkins changed: What|Removed |Added CC||whh8b at virginia dot edu --- Comment #5 from Will Hawkins --- I am using this as a jumping-off point to get involved with contributing code to gcc. I have nothing to offer yet, but I wanted to note here that I am going to start looking into this. Will
[Bug c++/85285] [6/7/8 Regression] ICE with flexible array in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85285 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85279] [6/7/8 Regression] Broken diagnostic for decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85279 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-09 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85262 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 9 20:53:31 2018 New Revision: 259255 URL: https://gcc.gnu.org/viewcvs?rev=259255&root=gcc&view=rev Log: PR c++/85262 - ICE with redundant qualification on constructor. * call.c (build_new_method_call_1): Move make_args_non_dependent after A::A() handling. Added: trunk/gcc/testsuite/g++.dg/parse/ctor10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Thomas Koenig --- I reran this with a revision that failed previously and found nothing. Looks like a bad case of cosmic rays, or (remotely possible) some race condition triggered by my excessive use of "make -j". Anyway, closing; sorry for the noise.
[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85277 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 --- Comment #6 from Arnd Bergmann --- I found that older versions (gcc-5 and before) did not warn when the type gets changed to bitfield of '_Bool' rather than 'unsigned int'. It seems that this was only because they tested each bit separately in the _Bool case rather than combining the first two comparisons into a &3 mask.
[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85277 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 9 20:40:06 2018 New Revision: 259254 URL: https://gcc.gnu.org/viewcvs?rev=259254&root=gcc&view=rev Log: PR c++/85277 - ICE with invalid offsetof. * semantics.c (finish_offsetof): Avoid passing non-DECL to %qD. Adjust -Winvalid-offsetof diagnostic to say conditionally supported. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.dg/ext/builtin-offsetof1.C trunk/gcc/testsuite/g++.dg/other/offsetof3.C trunk/gcc/testsuite/g++.dg/other/offsetof5.C trunk/gcc/testsuite/g++.dg/other/offsetof8.C
[Bug c++/85194] ICE with structured binding in broken for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85194 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for GCC8. error-recovery, not backporting to release branches.
[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85264 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 9 19:50:03 2018 New Revision: 259253 URL: https://gcc.gnu.org/viewcvs?rev=259253&root=gcc&view=rev Log: PR c++/85264 - ICE with excess template-parameter-list. * parser.c (cp_parser_check_template_parameters): Add template_id_p parameter. Don't allow an extra template header if true. (cp_parser_class_head): Pass template_id_p. (cp_parser_elaborated_type_specifier): Likewise. (cp_parser_alias_declaration): Likewise. (cp_parser_check_declarator_template_parameters): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic176.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/85194] ICE with structured binding in broken for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85194 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Apr 9 19:48:48 2018 New Revision: 259252 URL: https://gcc.gnu.org/viewcvs?rev=259252&root=gcc&view=rev Log: PR c++/85194 * parser.c (cp_parser_simple_declaration): For structured bindings, if *maybe_range_for_decl is NULL after parsing it, set it to error_mark_node. * g++.dg/cpp1z/decomp43.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/85306] New: [8 regression] The test cases gcc.dg/pr80463.c, g++.dg/pr80463.C, and gcc.dg/pr83972.c all fail in r259231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85306 Bug ID: 85306 Summary: [8 regression] The test cases gcc.dg/pr80463.c, g++.dg/pr80463.C, and gcc.dg/pr83972.c all fail in r259231 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- These are new test cases introduced in r259231 and they all fail on powerpc64: spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o pr80463.s cc1plus: warning: var-tracking-assignments changes selective scheduling output is: cc1plus: warning: var-tracking-assignments changes selective scheduling FAIL: g++.dg/pr80463.C -std=gnu++98 (test for excess errors) Excess errors: cc1plus: warning: var-tracking-assignments changes selective scheduling Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o pr80463.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o pr80463.s cc1plus: warning: var-tracking-assignments changes selective scheduling output is: cc1plus: warning: var-tracking-assignments changes selective scheduling FAIL: g++.dg/pr80463.C -std=gnu++11 (test for excess errors) Excess errors: cc1plus: warning: var-tracking-assignments changes selective scheduling Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o pr80463.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o pr80463.s cc1plus: warning: var-tracking-assignments changes
[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-09 Ever confirmed|0 |1
[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 Jonathan Wakely changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-09 Ever confirmed|0 |1 --- Comment #8 from Jonathan Wakely --- (In reply to blastrock from comment #7) > My initial suggestion was to mention that behavior in the documentation, but > if you think it is not worth it, I guess you can close this bug. I'm not sure why it's no longer mentioned, so I'll confirm this as a doc bug.
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-09 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 --- Comment #19 from Vittorio Romeo --- (In reply to Jonathan Wakely from comment #18) > (In reply to Vittorio Romeo from comment #17) > > Was the patch merged in trunk? > > It was committed to trunk: r251433 > > > The following still fails to compile on 20180407 > > Could you create a new bug for that please? Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
[Bug c++/85305] New: Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 Bug ID: 85305 Summary: Parameter pack expression in lambda capture list fails as part of a fold expression Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vittorio.romeo at outlook dot com Target Milestone: --- The following code snippet... template void foo() { ([i = Is]{}(), ...); } ...does not compile on gcc trunk 20180408 with the following error: : In function 'void foo()': :4:11: error: parameter packs not expanded with '...': ([i = Is]{}(), ...); ^~ :4:11: note: 'Is' :4:16: error: operand of fold expression has no unexpanded parameter packs ([i = Is]{}(), ...); ~~^~ Live example on godbolt.org: https://godbolt.org/g/YBk6L6
[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 --- Comment #7 from Thomas Koenig --- I will go back and re-bootstrap with a revision that failed earlier.
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 --- Comment #5 from Segher Boessenkool --- There also is /* We don't have to handle SIGN_EXTEND here, because even in the case of replacing something with a modeless CONST_INT, a CONST_INT is already (supposed to be) a valid sign extension for its narrower mode, which implies it's already properly sign-extended for the wider mode. Now, for ZERO_EXTEND, the story is different. */ This invalid sharing was never handled before?
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 --- Comment #4 from Segher Boessenkool --- I suppose the only way in which they are different is that those are the only cases that anyone ran into so far.
[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85211 --- Comment #7 from blastrock at free dot fr --- You are right, my bad. I managed to build it by adding the definition in gcc/config/arm/arm.h . My initial suggestion was to mention that behavior in the documentation, but if you think it is not worth it, I guess you can close this bug. Thanks anyway for your help!
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 --- Comment #6 from Eric Botcazou --- > Why not add the directory to the RPATH of the created binaries? I ended up > doing it manually afterwards by using the rpath utility from > https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 , > but it could be easily done during linking. Are there any reasons against > doing it? Yes, I don't think that we want to hardcode run-time paths by default.
[Bug rtl-optimization/80463] [6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Mon Apr 9 18:21:03 2018 New Revision: 259249 URL: https://gcc.gnu.org/viewcvs?rev=259249&root=gcc&view=rev Log: PR rtl-optimization/80463 * g++.dg/pr80463.C: Add -w to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pr80463.C
[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85262 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 --- Comment #6 from Jakub Jelinek --- Are you sure you e.g. haven't svn/git updated the tree while bootstrap was pending? Can you reproduce it again, or was it just one-off? If you still have the tree around, what are the differences in the two objects?
[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-09 Ever confirmed|0 |1
[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 --- Comment #5 from Jakub Jelinek --- Not reproduced on gcc110.fsffrance.org again with r259240: ../configure --enable-languages=all --prefix=/home/jakub/GCC Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Comparison successful.
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 --- Comment #18 from Jonathan Wakely --- (In reply to Vittorio Romeo from comment #17) > Was the patch merged in trunk? It was committed to trunk: r251433 > The following still fails to compile on 20180407 Could you create a new bug for that please?
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 --- Comment #3 from Jakub Jelinek --- --- gcc/combine.c.jj2018-03-15 08:36:28.756776703 +0100 +++ gcc/combine.c 2018-04-09 19:33:40.782844115 +0200 @@ -5574,12 +5574,13 @@ subst (rtx x, rtx from, rtx to, int in_d if (! x) x = gen_rtx_CLOBBER (mode, const0_rtx); } - else if (CONST_SCALAR_INT_P (new_rtx) - && GET_CODE (x) == ZERO_EXTEND) + else if (CONST_SCALAR_INT_P (new_rtx) && UNARY_P (x)) { - x = simplify_unary_operation (ZERO_EXTEND, GET_MODE (x), - new_rtx, GET_MODE (XEXP (x, 0))); - gcc_assert (x); + x = simplify_unary_operation (GET_CODE (x), GET_MODE (x), + new_rtx, + GET_MODE (XEXP (x, 0))); + if (!x) + return gen_rtx_CLOBBER (VOIDmode, const0_rtx); } else SUBST (XEXP (x, i), new_rtx); fixes this, by preventing creation of the invalid RTL where the RTL sharing and propagate_for_debug might make it reappear somewhere in the IL. We already did this for SUBREG and ZERO_EXTEND (strangely not for SIGN_EXTEND), wonder how are the other unary ops different.
[Bug demangler/85304] New: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304 Bug ID: 85304 Summary: Segmentation fault Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: mudongliangabcd at gmail dot com Target Milestone: --- Created attachment 43887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43887&action=edit PoC to trigger segment fault We found one segment fault in C++ Demangle Functions. From our simple analysis, one callq instruction exceed the range of stack region and then cxxfilt segments fault. The triggering method is as follows: ``` mkdir obj_test CFLAGS="-O2 -g -fstack-protector-all -fsanitize=address" ../configure --enable-shared=no --enable-static=yes make cd binutils gdb ./cxxfilt (gdb) r < poc_test ``` The corresponding Stack Trace in the gdb: ``` Program received signal SIGSEGV, Segmentation fault. 0x74e5931d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0 (gdb) info stack #0 0x74e5931d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0 #1 0x006a0126 in string_appendn (p=0x7fffe120, s=0x753f60 "(", n=1) at ./cplus-dem.c:4986 #2 0x0068db7d in demangle_expression (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1860 #3 0x0068e20a in demangle_integral_value (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120) at ./cplus-dem.c:1916 #4 0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069 #5 0x0068dfac in demangle_expression (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895 #6 0x0068e20a in demangle_integral_value (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120) at ./cplus-dem.c:1916 #7 0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069 #8 0x0068dfac in demangle_expression (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895 #9 0x0068e20a in demangle_integral_value (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120) at ./cplus-dem.c:1916 #10 0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069 #11 0x0068dfac in demangle_expression (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895 #12 0x0068e20a in demangle_integral_value (work=0x7fffe3b0, mangled=0x7fffe2c0, s=0x7fffe120) at ./cplus-dem.c:1916 .. ``` We will try to analyze more deeply to give a detailed report on this bug.
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 Jakub Jelinek changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This breaks during combine. We have: (gdb) p debug_rtx (i3) (insn 68 67 69 7 (set (reg:SI 89 [ _3 ]) (fix:SI (reg/v:SF 90 [ a ]))) "pr85300.c":4 174 {fix_truncsfsi_sse} (expr_list:REG_DEAD (reg/v:SF 90 [ a ]) (nil))) (gdb) p debug_rtx (i2) (insn 63 62 64 7 (set (reg/v:SF 90 [ a ]) (float:SF (reg:SI 88 [ _2 ]))) "pr85300.c":8 203 {*floatsisf2_mixed} (expr_list:REG_DEAD (reg:SI 88 [ _2 ]) (nil))) (gdb) p debug_rtx (i1) (insn 62 61 63 7 (set (reg:SI 88 [ _2 ]) (const_int 256 [0x100])) "pr85300.c":8 86 {*movsi_internal} (nil)) and first subst it so that we get: (set (reg:SI 89 [ _3 ]) (fix:SI (float:SF (reg:SI 88 [ _2 ] and then subst r88 for 256 and get: (set (reg:SI 89 [ _3 ]) (const_int 256 [0x100])) That is fine. But, during that substitution we also modify the i2 pattern, making it invalid: (insn 63 62 64 7 (set (reg/v:SF 90 [ a ]) (float:SF (const_int 256 [0x100]))) "pr85300.c":8 203 {*floatsisf2_mixed} (expr_list:REG_DEAD (reg:SI 88 [ _2 ]) (nil))) because the FLOAT rtx was shared between PATTERN (i2) and newpat.
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85264 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 --- Comment #5 from Jeffrey A. Law --- FWIW, there's another similar bug where DOM doesn't do a particularly good job at tracking the state of objects implied the results of logical operations which in turn causes missed optimizations. I've poked at it a few times but haven't come up with anything good to address the deficiency. It's on the Wuninitialized tracker, so I'll certainly take a look over the coming months.
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 --- Comment #4 from Jakub Jelinek --- Note, r142464 still doesn't warn, r142514 does, probably r142484 enabled the (premature) BIT_FIELD_REF comparison optimization in fold-const.c.
[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Maybe uninit just doesn't understand that in: [local count: 1073741825]: _1 = BIT_FIELD_REF ; _2 = _1 & 3; if (_2 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 719407025]: goto ; [100.00%] [local count: 354334802]: now_11 = ktime_get (); pretmp_14 = BIT_FIELD_REF ; [local count: 1073741825]: # now_5 = PHI # prephitmp_15 = PHI _4 = prephitmp_15 & 1; if (_4 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 719407025]: goto ; [100.00%] [local count: 354334802]: __tick_nohz_idle_restart_tick (now_5); [tail call] [local count: 1073741825]: return; if (_1 & 3) != 0 it implies (_1 & 1) != 0. Though, if I change the testcase to: void tick_nohz_idle_exit(void) { long now; struct tick_sched t = tick_nohz_idle_exit_ts; if (t.idle_active || t.tick_stopped) now = ktime_get(); if (t.tick_stopped) __tick_nohz_idle_restart_tick(now); } so that it doesn't have to reread tick_nohz_idle_exit_ts.tick_stopped after the ktime_get call, it doesn't warn anymore. In that case now is always initialized though, so it shouldn't matter what value we read for the uninit warning.
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 Michael Teske changed: What|Removed |Added CC||subscribe at teskor dot de --- Comment #5 from Michael Teske --- Why not add the directory to the RPATH of the created binaries? I ended up doing it manually afterwards by using the rpath utility from https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 , but it could be easily done during linking. Are there any reasons against doing it?
[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85277 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/84058] RTl partitioning fixup should drag very small blocks back to hot partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84058 Jan Hubicka changed: What|Removed |Added Target Milestone|8.0 |9.0 Summary|[8 Regression] RTl |RTl partitioning fixup |partitioning fixup should |should drag very small |drag very small blocks back |blocks back to hot |to hot partition|partition Severity|normal |enhancement --- Comment #9 from Jan Hubicka --- The most offending part is fixed. I am keeping the PR to track the enhancements possible in this area (which I plan to do after GCC 8 branches).
[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85302 --- Comment #2 from Jakub Jelinek --- That said, -gsplit-dwarf is pretty much unmaintained for more than 3 years now already.
[Bug rtl-optimization/84058] [8 Regression] RTl partitioning fixup should drag very small blocks back to hot partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84058 --- Comment #8 from Jan Hubicka --- Author: hubicka Date: Mon Apr 9 16:33:51 2018 New Revision: 259244 URL: https://gcc.gnu.org/viewcvs?rev=259244&root=gcc&view=rev Log: PR rtl/84058 * cfgcleanup.c (try_forward_edges): Do not give up on crossing jumps; choose last target that matches the criteria (i.e. no partition changes for non-crossing jumps). * cfgrtl.c (cfg_layout_redirect_edge_and_branch): Add basic support for redirecting crossing jumps to non-crossing. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/cfgrtl.c
[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85302 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce, neither on the trunk, nor on 7.x branch, in both cases native i686-linux builds.
[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85280 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Can't reproduce on x86_64-linux, i686-linux, powerpc64-linux nor powerpc64le-linux either, on the former ones I'm doing pretty much daily bootstraps with objc/obj-c++ included, on the latter from time to time, including gcc110.fsffrance.org.
[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- With the ICE fixed, this becomes a case of bug 70555. *** This bug has been marked as a duplicate of bug 70555 ***
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555 Jason Merrill changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #9 from Jason Merrill --- *** Bug 85256 has been marked as a duplicate of this bug. ***
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555 --- Comment #8 from Jason Merrill --- Bug 79627 is a case where we would need to do some capture in unevaluated context, just as in C VLAs make sizeof non-constant.
[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85277 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-09 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r254712. Before it was rejected with: pr85277.C:5:50: error: cannot apply ‘offsetof’ to member function ‘static int bar::baz()’ int bv0 = __builtin_offsetof(volatile bar, baz[0]);
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555 --- Comment #7 from Jason Merrill --- Created attachment 43886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43886&action=edit work in progress Here's the beginning of work for more general variably-modified type capture, based on the approach of capturing and remapping all the uses of outer automatic vars in the VLA type when the VLA variable is captured. Another approach would be to handle this later, when we actually do something that involves the dimensions; that could avoid some unnecessary captures, but currently the uses of the variable dimensions are hidden in ARRAY_REF, so we'd need to lower it to pointer arithmetic in affected cases.
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|ICE in expand_expr_real_1 |lambda capture of |accessing a |multi-dimensional VLA |multi-dimensional VLA via | |lambda-capture | --- Comment #6 from Jason Merrill --- Let's make this bug the primary one for implementation of more general VLA/variably-modified type capture support.
[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 9 15:32:05 2018 New Revision: 259240 URL: https://gcc.gnu.org/viewcvs?rev=259240&root=gcc&view=rev Log: PR c++/85256 - ICE capturing pointer to VLA. * lambda.c (add_capture): Distinguish between variable-size and variably-modified types. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C trunk/gcc/testsuite/g++.dg/cpp1y/vla7.C trunk/gcc/testsuite/g++.dg/cpp1y/vla9.C
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 Tom de Vries changed: What|Removed |Added CC||jakub at gcc dot gnu.org Severity|normal |enhancement
[Bug testsuite/85303] New: [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 Bug ID: 85303 Summary: [testsuite, libgomp] dg-message not supported Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- In libgomp test-cases, dg-error, dg-warning and dg-bogus can be used, but dg-message not.
[Bug target/85291] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #5 from Segher Boessenkool --- I'll handle it.
[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103 --- Comment #2 from Pat Haugen --- (In reply to Pat Haugen from comment #0) > > Very initial look at profile of bzip2 shows degradation is contained to > mainSort(), which showed a 54% increase in run cycles. Appears one of the > calls to mainGtU() is inlined into mainSort in the slow version, but the > drop in cycle counts on mainGtu is no where close to the increase on > mainSort. Appears the inlined copy of mainGtU() creates additional register pressure which results in register spill being generated in the loop of the inlined copy. The non-inlined copy of the loop is approx. 125 generated insns, whereas the inlined copy is about 215 insns (90 spill references).
[Bug target/85216] Performance issue with PHP on ppc64 systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85216 --- Comment #11 from Bill Schmidt --- (In reply to Timothy Pearson from comment #10) > > It's even slow compared to P8 with mitigations applied. Do you have a link > to the hostboot commit that may have enabled the P9 mitigation, or to the > register name (SCOM) that was modified to enable the mitigation? No, I'm sorry, I don't know those details. If you contact me offline I can probably find someone who does.
[Bug rtl-optimization/85302] New: [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85302 Bug ID: 85302 Summary: [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with r259224 on i686-linux-gnu, trying to build clamav. not seen on x86_64. $ cat PointerTracking.ii class a { const char *b; public: a(const char *c) : b(c) {} }; class B { public: void d(a); } e; void f() { e.d(""); } $ g++ -std=c++11 -c -gsplit-dwarf -O1 PointerTracking.ii PointerTracking.ii:11:21: internal compiler error: in size_of_loc_descr, at dwarf2out.c:1771 void f() { e.d(""); } ^ 0x81bc782 size_of_loc_descr ../../src/gcc/dwarf2out.c:1771 0x845f242 size_of_locs(dw_loc_descr_node*) ../../src/gcc/dwarf2out.c:1967 0x846086d skip_loc_list_entry ../../src/gcc/dwarf2out.c:10057 0x8467471 index_location_lists ../../src/gcc/dwarf2out.c:30904 0x8467438 index_location_lists ../../src/gcc/dwarf2out.c:30912 0x8467438 index_location_lists ../../src/gcc/dwarf2out.c:30912 0x8467438 index_location_lists ../../src/gcc/dwarf2out.c:30912 0x847f518 dwarf2out_finish ../../src/gcc/dwarf2out.c:31194 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Configured with: ../src/configure -v --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84732 --- Comment #9 from Arnd Bergmann --- One more instance got added to the kernel today: In file included from /git/arm-soc/include/trace/perf.h:90, from /git/arm-soc/include/trace/define_trace.h:97, from /git/arm-soc/include/trace/events/fscache.h:537, from /git/arm-soc/fs/fscache/internal.h:32, from /git/arm-soc/fs/fscache/main.c:20: /git/arm-soc/include/trace/events/fscache.h: In function 'perf_trace_fscache_netfs': /git/arm-soc/include/trace/events/fscache.h:200:1261: warning: 'strncpy' specified bound 8 equals destination size [-Wstringop-truncation] TRACE_EVENT(fscache_netfs, Same as the one from comment #5, this one happen for -fsanitize=kernel-address and is based on simple code that we don't warn for without sanitizer: strncpy(__entry->name, netfs->name, 8); __entry->name[7]= 0; I can probably work around that by turning off -Wstringop-truncation whenever sanitizers enabled in the kernel configuration (we already do that for -Wmaybe-uninitialized), if this one is unlikely to get fixed before the gcc-8 release.
[Bug target/85281] [8 Regression] Assembler messages: Error: operand size mismatch for `vpbroadcastb' with -mavx512bw -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85281 --- Comment #3 from Jakub Jelinek --- Created attachment 43885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43885&action=edit gcc8-pr85281-assorted-fixes.patch Other issues I've run into. These two patches together with with RUNTESTFLAGS='--target_board=unix\{-m32/-masm=intel,-m64/-masm=intel\} i386.exp' -FAIL: gcc.target/i386/avx5124vnniw-vp4dpwssd-2.c (test for excess errors) -FAIL: gcc.target/i386/avx5124vnniw-vp4dpwssds-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512dq-vreducesd-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512dq-vreducess-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vcvtsd2usi-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vcvtsd2usi64-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vcvtss2usi-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vcvtss2usi64-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vfixupimmsd-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vfixupimmss-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512vl-vcvtudq2pd-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512vl-vpmovswb-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512vl-vpmovwb-2.c (test for excess errors) -FAIL: gcc.target/i386/avx512vl-vshufpd-2.c (test for excess errors)
[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84955 Thomas Schwinge changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |cesar at gcc dot gnu.org
[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85300 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-09 CC||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r229538.
[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[7/8 Regression] Loop |[7 Regression] Loop |miscompilation starting |miscompilation starting |with r238367|with r238367 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85284 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Apr 9 13:27:33 2018 New Revision: 259234 URL: https://gcc.gnu.org/viewcvs?rev=259234&root=gcc&view=rev Log: 2018-04-09 Richard Biener PR tree-optimization/85284 * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions): Only use the niter constraining form of simple_iv when the exit is always executed. * gcc.dg/torture/pr85284.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr85284.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/85286] [8 Regression] ICE in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85286 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Starting with r252764 the ICE is instead: no-tree-pre-pr45241.c: In function ‘foo’: no-tree-pre-pr45241.c:5:1: internal compiler error: in vect_get_num_copies, at tree-vectorizer.h:1088 foo (short x) ^~~ 0x11b11f2 vect_get_num_copies ../../gcc/tree-vectorizer.h:1087 0x11bf934 vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-loop.c:5686 0x11aa054 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:8813 0x11c4afe vect_transform_loop(_loop_vec_info*) ../../gcc/tree-vect-loop.c:7396