[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Andrew Pinski --- How does this work for everyone else? Can you attach the preprocessed source?
[Bug middle-end/77981] gcc 7 miscompiles kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77981 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Bug in the kernel, see dup bug 77964. *** This bug has been marked as a duplicate of bug 77964 ***
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Andrew Pinski changed: What|Removed |Added CC||jirislaby at gmail dot com --- Comment #12 from Andrew Pinski --- *** Bug 77981 has been marked as a duplicate of this bug. ***
[Bug middle-end/77981] New: gcc 7 miscompiles kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77981 Bug ID: 77981 Summary: gcc 7 miscompiles kernel Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jirislaby at gmail dot com Target Milestone: --- I am using gcc-7 (SUSE Linux) 7.0.0 20161007 (experimental) from martin liska's https://build.opensuse.org/project/show/home:marxin:syzkaller And the kernel does not boot. It is looping and page faulting inside get_builtin_firmware: { #ifdef CONFIG_FW_LOADER struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { if (!strcmp(name, b_fw->name)) { cd->size = b_fw->size; cd->data = b_fw->data; return true; } } #endif return false; } But $ nm vmlinux-4.8.1-* |grep __.*_builtin_fw 81ac2158 R __end_builtin_fw 81ac2158 R __start_builtin_fw And sure, the test b_fw != __end_builtin_fw seems to be removed from the code: 81049d20 : 81049d20: e8 fb bb 68 00 callq 816d5920 <__fentry__> 81049d25: 41 54 push %r12 81049d27: 49 89 fcmov%rdi,%r12 81049d2a: 55 push %rbp 81049d2b: 48 89 f5mov%rsi,%rbp 81049d2e: 53 push %rbx 81049d2f: 48 c7 c3 58 21 ac 81mov$0x81ac2158,%rbx 81049d36: eb 04 jmp81049d3c81049d38: 48 83 c3 18 add$0x18,%rbx 81049d3c: 48 8b 33mov(%rbx),%rsi 81049d3f: 48 89 efmov%rbp,%rdi 81049d42: e8 d9 3d 36 00 callq 813adb20 81049d47: 85 c0 test %eax,%eax 81049d49: 75 ed jne81049d38 81049d4b: 48 8b 43 10 mov0x10(%rbx),%rax 81049d4f: 49 89 44 24 08 mov%rax,0x8(%r12) 81049d54: 48 8b 43 08 mov0x8(%rbx),%rax 81049d58: 5b pop%rbx 81049d59: 5d pop%rbp 81049d5a: 49 89 04 24 mov%rax,(%r12) 81049d5e: b8 01 00 00 00 mov$0x1,%eax 81049d63: 41 5c pop%r12 81049d65: c3 retq 81049d66: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1) 81049d6d: 00 00 00 gcc-6 produces this: 81ac2230 R __end_builtin_fw 81ac2230 R __start_builtin_fw and (chopped) 81049e39: 48 c7 c3 30 22 ac 81mov$0x81ac2230,%rbx 81049e40: 48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx 81049e47: 74 3f je 81049e88 The 'if' ^ 81049e49: 48 89 f5mov%rsi,%rbp 81049e4c: 49 89 fcmov%rdi,%r12 81049e4f: eb 0d jmp81049e5e 81049e51: 48 83 c3 18 add$0x18,%rbx 81049e55: 48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx 81049e5c: 74 2a je 81049e88 81049e5e: 48 8b 33mov(%rbx),%rsi 81049e61: 48 89 efmov%rbp,%rdi 81049e64: e8 f7 1e 36 00 callq 813abd60 81049e69: 85 c0 test %eax,%eax 81049e6b: 75 e4 jne81049e51
[Bug tree-optimization/77980] New: Regression in GCC-7.0.0's optimizer.
/7.0.0/lto-wrapper target: x86_64-pc-linux-gnu configure woth: ../gcc/configure --prefix=/home/kota/opt/gcc --program-suffix=-7.0 --disable-multilib --enable-languages=c thred model: posix gcc version 7.0.0 20161013 (experimental) (GCC) using built-in specs. clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 */
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Riccardo Mutschlechner changed: What|Removed |Added CC||riccardo at cs dot wisc.edu --- Comment #21 from Riccardo Mutschlechner --- Not sure if this is the best place to start, but here goes. I've noticed another similar issue. Let's say you've compiled a binary, `test`, from a source `test.c`. If you then flip the arguments to gcc by mistake, `gcc -o test.c test` rather than `gcc -o test test.c`, you will overwrite the source file by trying to compile the binary, thus losing it permanently without some other backup. Can I add some functionality that double checks against compiling *into* a source file extension? Is this cruft, or something that would actually be used - and if so, what is a good way to go about doing this? Would love to do it ASAP.
[Bug tree-optimization/77979] New: ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77979 Bug ID: 77979 Summary: ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- This is a regression from 6.2.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.0 20161013 (experimental) [trunk revision 241136] (GCC) $ $ gcc-trunk -O1 -c small.c $ gcc-6.2 -Os -c small.c $ $ gcc-trunk -Os -c small.c small.c: In function ‘fn1’: small.c:3:6: internal compiler error: Segmentation fault void fn1 () ^~~ 0xbe954f crash_signal ../../gcc-source-trunk/gcc/toplev.c:338 0xe7b040 tree_check ../../gcc-source-trunk/gcc/tree.h:3286 0xe7b040 get_value_range ../../gcc-source-trunk/gcc/tree-vrp.c:650 0xe7f51c get_vr_for_comparison ../../gcc-source-trunk/gcc/tree-vrp.c:7134 0xe7f51c compare_names ../../gcc-source-trunk/gcc/tree-vrp.c:7299 0xe7f51c vrp_evaluate_conditional_warnv_with_ops ../../gcc-source-trunk/gcc/tree-vrp.c:7389 0xe7f93b vrp_evaluate_conditional ../../gcc-source-trunk/gcc/tree-vrp.c:7423 0xe90f36 simplify_stmt_for_jump_threading ../../gcc-source-trunk/gcc/tree-vrp.c:10349 0xdf169e simplify_control_stmt_condition ../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:453 0xdf20e8 thread_through_normal_block ../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1088 0xdf3402 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*, avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*)) ../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1189 0xe88843 identify_jump_threads ../../gcc-source-trunk/gcc/tree-vrp.c:10536 0xe88843 vrp_finalize ../../gcc-source-trunk/gcc/tree-vrp.c:10624 0xe88843 execute_vrp ../../gcc-source-trunk/gcc/tree-vrp.c:11016 0xe88843 execute ../../gcc-source-trunk/gcc/tree-vrp.c:11102 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ --- int a, b, c, d, e, f; void fn1 () { int g = b; a = -~(d || a) << 4 || e; b = c || g ^ a; if (f < g) d = e; }
[Bug fortran/77978] New: stop codes misinterpreted in both f2003 and f2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77978 Bug ID: 77978 Summary: stop codes misinterpreted in both f2003 and f2008 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz Target Milestone: --- Stop codes changed from the f2003 standard to f2008. The first of these 2 programs has a stop code valid in f2003 but not in f2008, the second has a stop code valid in f2008 but not in f2003. But gfortran 6.1.1 happily compiles and runs both programs with either -std=f2003 or -f2008. Here are the program listings, gfortran -v result, and the results of compiling with the -std options that should not have worked: cayley[~/Jfh] % cat stopnumber.f90 ! stop666 (no space before 666) is valid f95 or f2003 but bad f2008 implicit none stop666 end program cayley[~/Jfh] % cat stopnumber2.f90 ! stop expression is valid f2008 but bad f2003 implicit none stop merge(667,668,.true.) end program cayley[~/Jfh] % gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160602 (GCC) cayley[~/Jfh] % gfortran -std=f2008 stopnumber.f90 cayley[~/Jfh] % ./a.out STOP 666 cayley[~/Jfh] % gfortran -std=f2003 stopnumber2.f90 cayley[~/Jfh] % ./a.out STOP 667 cayley[~/Jfh] %
[Bug fortran/77972] ICE on broken character continuation with -Wall etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77972 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- Testing fix now.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #11 from Marc Glisse --- (In reply to Andrew Pinski from comment #5) > Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for > __start_builtin_fw and __end_builtin_fw Shouldn't we recommend "+g" instead of "+r"? (In reply to Markus Trippelsdorf from comment #9) > Is subtracting undefined, too? > > - for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { > + for (b_fw = __start_builtin_fw; __end_builtin_fw - b_fw; b_fw++) { See bug 77813.
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 --- Comment #13 from John Paul Adrian Glaubitz --- Created attachment 39807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39807=edit Pre-processed source for tools/qtextboundaryfinder.cpp
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #12 from John Paul Adrian Glaubitz --- Hi! We just recently started seeing this issue in Debian, however, only for the powerpc-linux-gnuspe targets, i.e. e500v2 (Debian architecture: powerpcspe) [1]: g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o .obj/release-shared/qtextboundaryfinder.o tools/qtextboundaryfinder.cpp tools/qtextboundaryfinder.cpp: In member function 'bool QTextBoundaryFinder::isAtBoundary() const': tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:17958 } ^ 0x109c5aab validate_condition_mode(rtx_code, machine_mode) ../../src/gcc/config/rs6000/rs6000.c:17957 0x10b438df branch_comparison_operator(rtx_def*, machine_mode) ../../src/gcc/config/rs6000/predicates.md:1125 0x10b43b13 branch_positive_comparison_operator(rtx_def*, machine_mode) ../../src/gcc/config/rs6000/predicates.md:1204 0x10b5bad7 recog_72 ../../src/gcc/config/rs6000/altivec.md:643 0x10bb7f3b recog_for_combine_1 ../../src/gcc/combine.c:10945 0x10bbd4ff recog_for_combine ../../src/gcc/combine.c:11142 0x10bcb0c7 try_combine ../../src/gcc/combine.c:3503 0x10bcec7f combine_instructions ../../src/gcc/combine.c:1475 0x10bcec7f rest_of_handle_combine ../../src/gcc/combine.c:14356 0x10bcec7f execute ../../src/gcc/combine.c:14399 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o .obj/release-shared/qtimeline.o tools/qtimeline.cpp g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared -o .obj/release-shared/qvector.o tools/qvector.cpp Preprocessed source stored into /tmp/ccg5tpbm.out file, please attach this to your bugreport. I'm attaching the pre-processed source in case that might be useful. Odd that despite this bug being so old, it just surfaced on Debian powerpcspe recently. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=qt4-x11=powerpcspe=4%3A4.8.7%2Bdfsg-9=1476330034
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #10 from Andrew Pinski --- (In reply to Markus Trippelsdorf from comment #9) > Is subtracting undefined, too? Yes. Comparing two unrelated arrays or subtracting them is undefined.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Markus Trippelsdorf --- Is subtracting undefined, too? - for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { + for (b_fw = __start_builtin_fw; __end_builtin_fw - b_fw; b_fw++) {
[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566 --- Comment #6 from Dominique d'Humieres --- Beware of pr30617 in the test in comment 4! Otherwise the patch seems to work as expected. Thanks, Dominique > Le 13 oct. 2016 à 16:14, pault at gcc dot gnu.org> a écrit : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566 > > --- Comment #5 from Paul Thomas --- > Created attachment 39805 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit > Fix for the PR > > The attached fixes the testcase in the comment and more besides. I think that > some of the fix is unnecessary. I will do final adjustments once I am back at > base. > > It bootstraps and regtests on FC23/x87_64 > > Paul > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/71912] [6 regression] flexible array in struct in union rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912 Martin Sebor changed: What|Removed |Added Summary|[6/7 regression] flexible |[6 regression] flexible |array in struct in union|array in struct in union |rejected|rejected Known to fail|7.0 | --- Comment #8 from Martin Sebor --- Fixed on trunk in r241143.
[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71912 --- Comment #7 from Martin Sebor --- Author: msebor Date: Thu Oct 13 22:26:36 2016 New Revision: 241143 URL: https://gcc.gnu.org/viewcvs?rev=241143=gcc=rev Log: PR c++/71912 - [6/7 regression] flexible array in struct in union rejected gcc/cp/ChangeLog: PR c++/71912 * class.c (struct flexmems_t): Add members. (find_flexarrays): Add arguments. Correct handling of anonymous structs. (diagnose_flexarrays): Adjust to issue warnings in addition to errors. (check_flexarrays): Add argument. (diagnose_invalid_flexarray): New functions. gcc/testsuite/ChangeLog: PR c++/71912 * g++.dg/ext/flexary4.C: Adjust. * g++.dg/ext/flexary5.C: Same. * g++.dg/ext/flexary9.C: Same. * g++.dg/ext/flexary19.C: New test. * g++.dg/ext/flexary18.C: New test. * g++.dg/torture/pr64312.C: Add a dg-error directive to an ill-formed regression test. * g++.dg/compat/struct-layout-1_generate.c (subfield): Add argument. Avoid generating a flexible array member in an array. Added: trunk/gcc/testsuite/g++.dg/ext/flexary18.C trunk/gcc/testsuite/g++.dg/ext/flexary19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/g++.dg/ext/flexary4.C trunk/gcc/testsuite/g++.dg/ext/flexary5.C trunk/gcc/testsuite/g++.dg/ext/flexary9.C trunk/gcc/testsuite/g++.dg/torture/pr64312.C
[Bug fortran/68040] [5/6/7 Regression] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68040 --- Comment #6 from Dominique d'Humieres --- related to/duplicate of pr77972?
[Bug fortran/77972] ICE on broken character continuation with -Wall etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77972 --- Comment #2 from Dominique d'Humieres --- related to/duplicate of pr68040?
[Bug sanitizer/59962] --with-build-config=bootstrap-asan doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59962 --- Comment #1 from Andrew Pinski --- Does this work now?
[Bug debug/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52472 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #10 from Andrew Pinski --- Fixed over 2 years ago but forgot to close.
[Bug c++/77976] `auto x = type{…}` initialization syntax rejects `explicit` user-defined conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77976 Tomasz Kamiński changed: What|Removed |Added CC||tomaszkam at gmail dot com --- Comment #1 from Tomasz Kamiński --- Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999
[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917 --- Comment #10 from PeteVine --- Yeah, I began suspecting as much yesterday so I left it running overnight on ARM. It managed to get to stage comparison but failed due to many differences. But not before I'd got impatient in the morning and did a start/stop switching the linker back to gold, probably my fault :)
[Bug tree-optimization/64567] missed optimization: redundant test before clearing bit(s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64567 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #3 from Andrew Pinski --- (In reply to Rasmus Villemoes from comment #2) > (In reply to Andreas Schwab from comment #1) > > This transformation is incorrect if the lvalue may be pointing to a > > read-only object. > > True. And one may also incur an extra cache penalty if the cache line > containing foo was already held shared but not exclusive. Or incorrect due to C11/C++11 memory model. Anyways it is correct for scalar auto variables and this should be transformed at the gimple level if not already.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #8 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #7) > You don't need it for both. > struct builtin_fw *b_fw = __start_builtin_fw; > asm ("" : "+r" (b_fw)); > for (; b_fw != __end_builtin_fw; b_fw++) { > should be enough. And indeed, without that it is undefined behavior. You might want to do end only then instead of the start. Because in theory GCC could say it is always false as &__end_builtin_fw[-1] is undefined behavior too so GCC say if the initial value was not __end_builtin_fw[0] go into an infinite loop.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #7 from Jakub Jelinek --- You don't need it for both. struct builtin_fw *b_fw = __start_builtin_fw; asm ("" : "+r" (b_fw)); for (; b_fw != __end_builtin_fw; b_fw++) { should be enough. And indeed, without that it is undefined behavior.
[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77962 Jakub Jelinek changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- *** Bug 77977 has been marked as a duplicate of this bug. ***
[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77977 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Yeah. *** This bug has been marked as a duplicate of bug 77962 ***
[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77977 Ian Lance Taylor changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Ian Lance Taylor --- Jakub, did you figure anything out about this?
[Bug go/77977] New: stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77977 Bug ID: 77977 Summary: stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o' Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: msebor at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- When configured with --enable-languages=all,ada,c,c++,fortran,go,lto,objc,obj-c++ today's top of trunk (at r241131) fails to bootstrap on x86_64-linux with the error below. There is no other error earlier that I can see (this was a serial build, i.e., with -j1). make[8]: Entering directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo' /usr/bin/mkdir -p runtime/internal; files=`echo /src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go /src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /home/msebor/build/gcc-trunk/./gcc/gccgo -B/home/msebor/build/gcc-trunk/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -fno-split-stack -O2 -g -m32 -I . -c -fgo-pkgpath=`echo runtime/internal/atomic.lo | sed -e 's/.lo$//' -e 's/-go$//'` -fgo-compiling-runtime -o runtime/internal/atomic.lo $files libtool: compile: /home/msebor/build/gcc-trunk/./gcc/gccgo -B/home/msebor/build/gcc-trunk/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -fno-split-stack -O2 -g -m32 -I . -c -fgo-pkgpath=runtime/internal/atomic -fgo-compiling-runtime /src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go /src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go libtool: compile: mv -f "stubs.o" "runtime/internal/.libs/atomic.o" mv: cannot stat 'stubs.o': No such file or directory Makefile:4942: recipe for target 'runtime/internal/atomic.lo' failed make[8]: *** [runtime/internal/atomic.lo] Error 1 make[8]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo' Makefile:3039: recipe for target 'all-recursive' failed make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo' Makefile:1407: recipe for target 'all' failed make[6]: *** [all] Error 2 make[6]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo' Makefile:5537: recipe for target 'multi-do' failed make[5]: *** [multi-do] Error 1 make[5]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo' Makefile:2305: recipe for target 'all-multi' failed make[4]: *** [all-multi] Error 2 make[4]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo' Makefile:3039: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo' Makefile:1407: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo' Makefile:25608: recipe for target 'all-target-libgo' failed make[1]: *** [all-target-libgo] Error 2 make[1]: Leaving directory '/home/msebor/build/gcc-trunk' Makefile:29771: recipe for target 'bootstrap' failed make: *** [bootstrap] Error 2 make: Leaving directory '/home/msebor/build/gcc-trunk'
[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-13 Ever confirmed|0 |1 --- Comment #9 from Andrew Pinski --- .
[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917 --- Comment #8 from Andrew Pinski --- (In reply to PeteVine from comment #7) > BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by > the presence of `-flto` among environment C(XX)FLAGS, as otherwise it > definitely makes sense for configure to always sanitize those flags. With --with-build-config=bootstrap-lto you will not need -flto in C(XX)FLAGS. Really -flto in C(XX)FLAGS is the cause of the problem you are running into.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #6 from Andrew Pinski --- That is change: extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name, void *buf, size_t size) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { --- CUT -- to (there might already be a macro in linux which does the asm like below already): extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name, void *buf, size_t size) { struct builtin_fw *b_fw; struct builtin_fw *b_fw_start = __start_builtin_fw, b_fw_end = __end_builtin_fw; asm("":"+r"(b_fw_start)); asm("":"+r"(b_fw_end)); for (b_fw = b_fw_start; b_fw != b_fw_end; b_fw++) {
[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 --- Comment #13 from Bill Schmidt --- Author: wschmidt Date: Thu Oct 13 19:50:41 2016 New Revision: 241139 URL: https://gcc.gnu.org/viewcvs?rev=241139=gcc=rev Log: 2016-10-13 Bill SchmidtPR tree-optimization/77937 * gcc.dg/torture/pr77937-1.c: New. * gcc.dg/torture/pr77937-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77937-1.c trunk/gcc/testsuite/gcc.dg/torture/pr77937-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77975 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |tree-optimization Target Milestone|--- |6.3 Summary|[6 / 7 Regression] Missed |[6/7 Regression] Missed |optimization for some small |optimization for some small |constants |constants
[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77974 --- Comment #3 from Marek Polacek --- Nice. Will you commit the patch? Thanks.
[Bug c/77975] New: [6 / 7 Regression] Missed optimization for some small constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77975 Bug ID: 77975 Summary: [6 / 7 Regression] Missed optimization for some small constants Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: quiath at go2 dot pl Target Milestone: --- When compiling with GCC 6.1, 6.2 or 7.0 the code generated with -O1 -O2 and -O3 does not fold depending on some small constants e.g. 3 used in the body of the function. GCC 5.4 was better. Example code: // missed optimization, compiled to a loop unsigned int f3() { unsigned int a = 3; while (a) { a >>= 1; } return a; } // expected optimization, compiled to a single instruction unsigned int f7() { unsigned int a = 7; while (a) { a >>= 1; } return a; } x86-64 assembly from gcc 7 (identical for 6) according to godbolt.org Note that f7 is folded while f3 is not. f3(): mov eax, 3 .L2: shr eax jne .L2 mov eax, 0 ret f7(): mov eax, 0 ret See also example here: https://godbolt.org/g/ircKQ0
[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77974 --- Comment #2 from Andreas Schwab--- I think this is intented: diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c index a104193c23..0eb1528079 100644 --- a/gcc/config/m68k/m68k.c +++ b/gcc/config/m68k/m68k.c @@ -4546,6 +4546,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc) return ""; } } + return ""; } case RELOC_TLSGD:
[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77973 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.4, 5.4.0 Keywords||ice-on-valid-code, openmp Last reconfirmed||2016-10-13 CC||marxin at gcc dot gnu.org, ||mjambor at suse dot cz Ever confirmed|0 |1 Summary|ICE in scan_omp_1_op, at|[6/7 Regression] ICE in |omp-low.c:3841 |scan_omp_1_op, at ||omp-low.c:3841 Known to fail||6.2.0, 7.0 --- Comment #1 from Martin Liška --- Confirmed, started with r232549 (HSA branch merge).
[Bug fortran/77972] ICE on broken character continuation with -Wall etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77972 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- All compilers I have (4.5.0+) ICE.
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 --- Comment #4 from Jonathan Wakely --- Created attachment 39806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39806=edit Patch to remove special-case for reference_wrapper. This patch makes it work as desired. We need to fix 3-4 test cases too which explicitly check for the current behaviour (it's by design, matching Boost.Function). I submitted a defect report, with a proposed change to make the copy + move constructors say "if f’s target is a callable object passed viaspecialization of reference_wrapper or a function pointer."
[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77971 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with GCC 4.6.0.
[Bug bootstrap/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77974 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This should fix it, but is the fallthru really intended? --- a/gcc/config/m68k/m68k.c +++ b/gcc/config/m68k/m68k.c @@ -4548,6 +4548,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc) } } } + /* FALLTHRU */ case RELOC_TLSGD: return "@TLSGD";
[Bug bootstrap/77974] New: m68k bootstrap failure due to -Werror=implicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77974 Bug ID: 77974 Summary: m68k bootstrap failure due to -Werror=implicit-fallthrough Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Target Milestone: --- Attempting to bootstrap gcc-7-20161009 on m68k-linux fails with: /mnt/scratch/objdir7/./prev-gcc/xg++ -B/mnt/scratch/objdir7/./prev-gcc/ -B/mnt/scratch/install7/m68k-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu -I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-7-20161009/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-7-20161009/gcc -I/mnt/scratch/gcc-7-20161009/gcc/. -I/mnt/scratch/gcc-7-20161009/gcc/../include -I/mnt/scratch/gcc-7-20161009/gcc/../libcpp/include -I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber -I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-7-20161009/gcc/../libbacktrace -o m68k.o -MT m68k.o -MMD -MP -MF ./.deps/m68k.TPo /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c: In function 'const char* m68k_get_reloc_decoration(m68k_reloc)': /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4537:4: error: this statement may fall through [-Werror=implicit-fallthrough] if (TARGET_68020) ^~ /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4551:5: note: here case RELOC_TLSGD: ^~~~ cc1plus: all warnings being treated as errors make[3]: *** [m68k.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir7/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir7' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir7' make: *** [bootstrap] Error 2 I believe gcc-7-20161002 had the same issue. gcc-7-20160918 bootstrapped fine. Configuration options: /mnt/scratch/gcc-7-20161009/configure --prefix=/mnt/scratch/install7 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++ --disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto --disable-multilib --disable-libgomp
[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77962 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Thu Oct 13 18:25:15 2016 New Revision: 241135 URL: https://gcc.gnu.org/viewcvs?rev=241135=gcc=rev Log: Create the *logue in the same order as before (PR77962) PR77962 shows Go failing on 32-bit x86. This happens because the i386 port requires the split stack prologue to be created before the normal prologue, and my previous patch changed it to be the other way around. This patch changes it back. Things will be exactly as before for targets that do not do shrink-wrapping for separate components. For targets that *do* support it, all three prologue/epilogue creation functions will now be called twice for functions that have anything wrapped separately (instead of just the prologue created twice). PR bootstrap/77962 * function.c (thread_prologue_and_epilogue_insns): Call all make_*logue_seq in the same order as traditional. Call them all a second time if shrink_wrapped-separate. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug fortran/77973] New: ICE in scan_omp_1_op, at omp-low.c:3841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77973 Bug ID: 77973 Summary: ICE in scan_omp_1_op, at omp-low.c:3841 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With version 7 and option -fopenmp : $ cat z1.f90 subroutine s(x) integer :: x(:) integer :: i !$omp parallel !$omp target teams distribute do i = 1, 2 x(i) = 1 end do !$omp end parallel end $ gfortran-7-20161009 -fopenmp -c z1.f90 z1.f90:5:0: !$omp target teams distribute internal compiler error: in scan_omp_1_op, at omp-low.c:3841 0xafa012 scan_omp_1_op ../../gcc/omp-low.c:3841 0xee7462 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set>*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:11684 0xb11b68 scan_omp_op ../../gcc/omp-low.c:394 0xb11b68 scan_sharing_clauses ../../gcc/omp-low.c:2054 0xb20d08 scan_omp_target ../../gcc/omp-low.c:3192 0xb20d08 scan_omp_1_stmt ../../gcc/omp-low.c:3983 0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:568 0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:596 0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:596 0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0xaf5c99 scan_omp ../../gcc/omp-low.c:4026 0xb21038 scan_omp_parallel ../../gcc/omp-low.c:2694 0xb21038 scan_omp_1_stmt ../../gcc/omp-low.c:3950 0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:568 0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:596 0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0xaf5c99 scan_omp ../../gcc/omp-low.c:4026
[Bug fortran/77972] New: ICE on broken character continuation with -Wall etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77972 Bug ID: 77972 Summary: ICE on broken character continuation with -Wall etc. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- ICEs down to at least 4.8; gcc-7 in combination with option -Wall, or one of -pedantic, -std=f95, -std=f2003, -std=f2008, ... Follow-up of pr71686. $ cat z1.f90 program p character(8) :: z z = 'abc& !end $ cat z2.f90 program p character(8) :: z = 'abc& !end $ gfortran-7-20161009 -Wall z1.f90 0x68903e gfc_format_decoder ../../gcc/fortran/error.c:935 0x13c9bff pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:660 0x13bd020 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:945 0x688d4f gfc_warning ../../gcc/fortran/error.c:792 0x6899e6 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.c:823 0x6fecb8 gfc_next_char_literal(gfc_instring) ../../gcc/fortran/scanner.c:1424 0x6de738 next_string_char ../../gcc/fortran/primary.c:903 0x6e06a7 match_string_constant ../../gcc/fortran/primary.c:1102 0x6e06a7 gfc_match_literal_constant(gfc_expr**, int) ../../gcc/fortran/primary.c:1455 0x6bc01f match_primary ../../gcc/fortran/matchexp.c:149 0x6bc01f match_level_1 ../../gcc/fortran/matchexp.c:211 0x6bc01f match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6bc308 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6bc59c match_level_2 ../../gcc/fortran/matchexp.c:480 0x6bc6f2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6bc804 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6bc804 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6bc9c2 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6bcab2 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6bcba2 match_level_5 ../../gcc/fortran/matchexp.c:811
[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77971 --- Comment #1 from Gerhard Steinmetz--- For completeness, compiles without variable "g" : $ cat z3.f90 module m contains function f() f = 1 entry g() g = 2 end end $ gfortran-7-20161009 -O0 -c z3.f90 Problem detected with variable named "f" : $ cat z4.f90 module m real f contains function f() f = 1 entry g() g = 2 end end $ gfortran-7-20161009 -O0 -c z4.f90 z4.f90:4:13: z4.f90:2:9: real f 2 z4.f90:4:13: function f() 1 Error: Procedure 'f' at (1) has an explicit interface and must not have attributes declared at (2)
[Bug fortran/77971] New: ICE at -O0 in make_decl_rtl, at varasm.c:1310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77971 Bug ID: 77971 Summary: ICE at -O0 in make_decl_rtl, at varasm.c:1310 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- ICE down to at least 4.8, at -O0 : $ cat z1.f90 module m real g contains function f() f = 1 entry g() g = 2 end end $ gfortran-7-20161009 -O0 -c z1.f90 z1.f90:7:0: g = 2 internal compiler error: in make_decl_rtl, at varasm.c:1310 0xf1e0be make_decl_rtl(tree_node*) ../../gcc/varasm.c:1306 0x90dd88 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9755 0x91a8a6 expand_expr ../../gcc/expr.h:279 0x91a8a6 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5252 0x8083e6 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3649 0x8083e6 expand_gimple_stmt ../../gcc/cfgexpand.c:3745 0x80a80e expand_gimple_basic_block ../../gcc/cfgexpand.c:5752 0x810996 execute ../../gcc/cfgexpand.c:6363
[Bug c/77970] inconsistent and unhelpful -Wformat warning for %lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77970 --- Comment #1 from joseph at codesourcery dot com --- I think the correct logic would be something like: if the argument is for a standard typedef, and the format doesn't correspond exactly to that typedef (or one differing only by sign, e.g. allow %ju for an intmax_t unless -Wformat-signedness), warn (with an option to disable it) even if they match (or match up to sign) on this particular system. Likewise if the format is for a standard typedef but the argument isn't. Hard to implement for various reasons (including format macros - glibc's definitions of those for intmax_t match the underlying type rather than using "j", for example), and would have false positives in various cases, but more warnings rather than less seems right here and would make warnings more consistent between targets. The option to disable warnings for mismatched typedefs could then have different stringencies for whether it disables even int/long mismatches, or only cases that already wouldn't warn but for the use of standard typedefs.
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 --- Comment #3 from David Krauss --- … Woops, that f is the function parameter, not the target. So it's not a conflicting requirement, but it could be a template for fixing the the copy constructor constraint.
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 --- Comment #2 from David Krauss --- The converting constructor requirements also say more explicitly, shall not throw exceptions when f is a function pointer or a reference_wrapper for some T. Probably the copy constructor should be worded similarly. In any case, the exception guarantee isn't affected, as sizeof(reference_wrapper) == sizeof(T*).
[Bug c/77970] New: inconsistent and unhelpful -Wformat warning for %lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77970 Bug ID: 77970 Summary: inconsistent and unhelpful -Wformat warning for %lc Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The following snippet compiles with no warnings on popular 64-bit targets including powerpc64-*-linux, sparc-sun-solaris2.10, and x86_64-*-linux. However, on a number of 32-bit targets the same code causes GCC to issue a warning about one or the other call pedantically complaining about either the literal zero not having the expected type of wint_t (e.g., where wint_t is an alias for long) even though the two have the same size and sign, or about the L'a' argument not having the wint_t type for the same reason (the type of L'a' is wchar_t). (This is analogous to warnings issued for %li with an int argument, or for %i with a long argument, on ILP32.) printf ("%lc", 0); printf ("%lc", L'a'); Unlike the warnings for ordinary integer directives which is issued consistently, issuing the warning for %lc inconsistently, based on the underlying type of wchar_t and wint_t, and only on uncommon targets and not on mainstream targets where most code is developed is unhelpful for portability and only serves to cause code to fail to compile when ported (see for example the thread around https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00993.html for the effort it took to clean up these warnings in the builtin-sprintf*.c tests). Issuing the warning when both the sign and the size of the argument are the same as those expected is useless entirely since objects of the two types are indistinguishable. (The warning is not issued when the types only differ in signedness such as int and unsigned int unless the -Wformat-signedness option is explicitly specified.) To be useful for portability, the warning should be issued consistently on all targets, especially those where most development is done (LP64 targets such powerpc64-*-linux and x86_64-*-linux. The warning is also only useful if there exists a target where wint_t and wchar_t (for the L'a' case) or int (for the int argument case) are different sizes. If there is no such target (I don't know of one and a survey of GCC config files didn't reveal one either) the warning isn't useful even if wint_t and wchar_t differ in sign because sign mismatches are handled separately under the -Wformat-signedness option. As a data point, Clang stopped issuing this warning in 2011 in response to the following Clang bug: https://llvm.org/bugs/show_bug.cgi?id=7981 GCC should do the same and either suppress the warning altogether or issue it only with -Wpedantic. Test case: $ (set -x && cd ~/tmp && cat a.c && for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu; do /build/sysroot/$t/bin/$t-gcc -S -Wall -o/dev/null a.c; done) + cd /home/msebor/tmp + cat a.c typedef __WCHAR_TYPE__ wchar_t; void f (void) { __builtin_printf ("%lc", 0); __builtin_printf ("%lc", L'a'); } + for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu + /build/sysroot/i386-rehat-linux/bin/i386-rehat-linux-gcc -S -Wall -o/dev/null a.c a.c: In function 'f': a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument 2 has type 'long int' [-Wformat=] __builtin_printf ("%lc", L'a'); ~~^ %ld + for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu + /build/sysroot/sparc-sun-solaris2.12/bin/sparc-sun-solaris2.12-gcc -S -Wall -o/dev/null a.c a.c: In function 'f': a.c:5:24: warning: format '%lc' expects argument of type 'wint_t', but argument 2 has type 'int' [-Wformat=] __builtin_printf ("%lc", 0); ~~^ %c + for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu + /build/sysroot/x86_64-unknown-solaris2.10/bin/x86_64-unknown-solaris2.10-gcc -S -Wall -o/dev/null a.c + for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu + /build/sysroot/bfin-uclinux/bin/bfin-uclinux-gcc -S -Wall -o/dev/null a.c + for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux hppa-unknown-linux-gnu + /build/sysroot/m68k-linux/bin/m68k-linux-gcc -S -Wall -o/dev/null a.c a.c: In function 'f': a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument 2 has type 'long int' [-Wformat=] __builtin_printf ("%lc", L'a'); ~~^ %ld + for t in i386-rehat-linux
[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77968 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug sanitizer/77963] inconsistent (false?) leaks detection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77963 --- Comment #1 from Kostya Serebryany --- lsan does not work with ptrace. There is https://github.com/google/sanitizers/issues/728 for it. We don't have plans to fix it, but the change I sent for review yesterday causes lsan to complain loudly instead of producing false reports. If you know how to *fix* it, i.e. to make lsan work with ptrace -- please tell.
[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77968 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-13 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Egad. Will revert the create_var_decl hunk, thanks for the heads up.
[Bug c++/77967] [6/7 Regression] ICE in cp_parser_type_name, at cp/parser.c:16419 (trying to add a method to a template alias)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77967 Martin Liška changed: What|Removed |Added Target Milestone|--- |6.3 Summary|[6/7 Regression] ICE in |[6/7 Regression] ICE in |method_on_alias_internal_er |cp_parser_type_name, at |ror.cpp:7:1: internal |cp/parser.c:16419 (trying |compiler error: in |to add a method to a |cp_parser_type_name, at |template alias) |cp/parser.c:16419 (trying | |to add a method to a| |template alias) |
[Bug c++/77967] [6/7 Regression] ICE in method_on_alias_internal_error.cpp:7:1: internal compiler error: in cp_parser_type_name, at cp/parser.c:16419 (trying to add a method to a template alias)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77967 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.5.4, 4.6.4, 4.7.4, 4.8.5, ||4.9.4, 5.4.0 Keywords||ice-on-invalid-code Last reconfirmed||2016-10-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|trying to add a method to a |[6/7 Regression] ICE in |template alias triggers an |method_on_alias_internal_er |internal compiler error |ror.cpp:7:1: internal ||compiler error: in ||cp_parser_type_name, at ||cp/parser.c:16419 (trying ||to add a method to a ||template alias) Known to fail||6.2.0 --- Comment #1 from Martin Liška --- Confirmed.
[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 --- Comment #12 from Bill Schmidt --- Just saw your request to include the test case. I will do this but may ask you to review the dejagnu bits for accuracy for your target, as these don't fire on arches I regularly build for.
[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 --- Comment #11 from Bill Schmidt --- Author: wschmidt Date: Thu Oct 13 15:34:22 2016 New Revision: 241125 URL: https://gcc.gnu.org/viewcvs?rev=241125=gcc=rev Log: 2016-10-13 Bill SchmidtPR tree-optimization/77937 * gimple-ssa-strength-reduction.c (analyze_increments): Set cost to infinite when we have a pointer with an increment of -1. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c
[Bug fortran/77961] Allocatable components in CLASS-typed coarrays unsupported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77961 --- Comment #2 from vehre at gcc dot gnu.org --- This is no regression, because before the patch mentioned in comment #1, the construct of having allocatable components in derived types was flagged as error. Now this construct is supported for derived types at least. For class-typed coarrays looking up the token fails. This bug is similar if not a duplicate of pr77785.
[Bug c++/66170] Bogus warning with -Wsign-conversion when using static_cast on an int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66170 Sergey Vidyuk changed: What|Removed |Added CC||sir.vestnik at gmail dot com --- Comment #1 from Sergey Vidyuk --- I have similair issue with gcc-6.2 [vestnik@VestniK-laptop C++]$ cat fasttest.cpp #include #include void foo(const std::vector vec, const int idx) { if (idx < 0 || vec.size() <= static_cast(idx)) { std::cout << "No such index\n"; return; } std::cout << "Valid index\n"; } int main() { foo({1, 2, 3, 4 ,5}, 6); return 0; } [vestnik@VestniK-laptop C++]$ g++ -std=c++11 -Wsign-conversion -Wall -Werror fasttest.cpp -o fasttest fasttest.cpp: In function 'void foo(std::vector, int)': fasttest.cpp:5:31: error: conversion to 'std::vector::size_type {aka long unsigned int}' from 'const int' may change the sign of the result [-Werror=sign-conversion] if (idx < 0 || vec.size() <= static_cast(idx)) ^~~~ cc1plus: all warnings being treated as errors [vestnik@VestniK-laptop C++]$ g++ --version g++ (GCC) 6.2.1 20160830 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It looks like static_cast type was incorrectly treated as const int instead of size_t. Changing static_cast(idx) to static_cast(idx) silences diagnostics but such fix looks lihe a strange hack.
[Bug go/77969] New: go testsuite shows ICEs and runtime errors with -flto [-g]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77969 Bug ID: 77969 Summary: go testsuite shows ICEs and runtime errors with -flto [-g] Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: rguenth at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- I saw the following a few weeks ago: Running target unix/-flto/-g/ FAIL: go.test/test/chan/select5.go -O (internal compiler error) FAIL: go.test/test/chan/select5.go -O (test for excess errors) FAIL: go.test/test/chan/select5.go execution FAIL: go.test/test/fixedbugs/bug206.go -O (internal compiler error) FAIL: go.test/test/fixedbugs/bug206.go -O (test for excess errors) FAIL: go.test/test/fixedbugs/bug206.go execution FAIL: go.test/test/fixedbugs/bug392.dir/pkg2.go -O (internal compiler error) FAIL: go.test/test/fixedbugs/bug392.dir/pkg2.go -O (test for excess errors) FAIL: go.test/test/fixedbugs/bug392.dir/pkg3.go -O (test for excess errors) FAIL: go.test/test/fixedbugs/issue4932.dir/state2.go -O (internal compiler error) FAIL: go.test/test/fixedbugs/issue4932.dir/state2.go -O (test for excess errors) FAIL: go.test/test/fixedbugs/issue5291.dir/prog.go, -O2 -g (internal compiler error) FAIL: go.test/test/fixedbugs/issue5910.dir/main.go -O (internal compiler error) FAIL: go.test/test/fixedbugs/issue5910.dir/main.go -O (test for excess errors) FAIL: go.test/test/index0.go -O (internal compiler error) FAIL: go.test/test/index0.go -O (test for excess errors) FAIL: go.test/test/index0.go execution FAIL: go.test/test/index1.go -O (internal compiler error) FAIL: go.test/test/index1.go -O (test for excess errors) FAIL: go.test/test/index1.go execution FAIL: go.test/test/index2.go -O (internal compiler error) FAIL: go.test/test/index2.go -O (test for excess errors) FAIL: go.test/test/index2.go execution
[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566 --- Comment #5 from Paul Thomas --- Created attachment 39805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit Fix for the PR The attached fixes the testcase in the comment and more besides. I think that some of the fix is unnecessary. I will do final adjustments once I am back at base. It bootstraps and regtests on FC23/x87_64 Paul
[Bug ada/77968] [7 Regression] ICEs with -flto on gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77968 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug ada/77968] New: [7 Regression] ICEs with -flto on gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77968 Bug ID: 77968 Summary: [7 Regression] ICEs with -flto on gnat.dg Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- When running check-gnat with -flto you'll stumble upon a load of +===GNAT BUG DETECTED==+ | 7.0.0 20161013 (experimental) [trunk revision 221942] (x86_64-pc-linux-gnu) GCC error:| | in self_referential_size, at stor-layout.c:187 | which is /* We shouldn't have true variables here. */ gcc_assert (TREE_READONLY (ref)); that's likely because of 2016-07-11 Eric Botcazou <ebotca...@adacore.com> * gcc-interface/trans.c (add_decl_expr): Minor tweak. * gcc-interface/utils.c (create_var_decl): For an external variable, also clear TREE_READONLY in LTO mode if the initializer is not a valid constant and set DECL_READONLY_ONCE_ELAB instead. possibly all flag_generate_lto uses in ada/gcc-frontend are "bogus".
[Bug c/77966] Corrupt function with -fsanitize-coverage=trace-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966 --- Comment #2 from Denis Vlasenko --- Without -fsanitize-coverage=trace-pc, the second, redundant check "snic->wq_count<=1?" is not generated. This eliminates the hanging "impossible" code path: : 0: 8b 07 mov(%rdi),%eax 2: 85 c0 test %eax,%eax 4: 74 09 je f 6: 48 8b 7f 08 mov0x8(%rdi),%rdi a: e9 00 00 00 00 jmpq ioread32 f: c3 retq
[Bug c/77966] Corrupt function with -fsanitize-coverage=trace-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966 Denis Vlasenko changed: What|Removed |Added CC||vda.linux at googlemail dot com --- Comment #1 from Denis Vlasenko --- Simplified a bit: - spinlock_t is not essential - mempool_t is not essential - snic_log_q_error_err_status variable is not necessary - __attribute__ ((__aligned__)) can be dropped too - struct vnic_wq can be folded OTOH: - struct vnic_wq_ctrl wrapping of int variable is necessary - wq_lock[1] unused member is necessary (makes gcc "know for sure" that wq[1] is 1-element array) - each of -O2 -fno-reorder-blocks -fsanitize-coverage=trace-pc are necessary extern unsigned int ioread32(void *); struct vnic_wq_ctrl { unsigned int error_status; }; struct snic { unsigned int wq_count; struct vnic_wq_ctrl *wq[1]; int wq_lock[1]; }; void snic_log_q_error(struct snic *snic) { unsigned int i; for (i = 0; i < snic->wq_count; i++) ioread32(>wq[i]->error_status); } : 0: 53 push %rbx 1: 48 89 fbmov%rdi,%rbx 4: e8 00 00 00 00 callq __sanitizer_cov_trace_pc 9: 8b 03 mov(%rbx),%eax b: 85 c0 test %eax,%eax # snic->wq_count==0? d: 75 09 jne18 f: 5b pop%rbx # yes, 0 10: e9 00 00 00 00 jmpq __sanitizer_cov_trace_pc #tail call 15: 0f 1f 00nopl (%rax) 18: e8 00 00 00 00 callq __sanitizer_cov_trace_pc 1d: 48 8b 7b 08 mov0x8(%rbx),%rdi 21: e8 00 00 00 00 callq ioread32 26: 83 3b 01cmpl $0x1,(%rbx) # snic->wq_count<=1? 29: 76 e4 jbef 2b: e8 00 00 00 00 callq __sanitizer_cov_trace_pc Looks like gcc thinks that the loop can execute only zero or one time (or else we run off wq[1]). So when it iterated once: 21: e8 00 00 00 00 callq ioread32 it checks that snic->wq_count <= 1 26: 83 3b 01cmpl $0x1,(%rbx) 29: 76 e4 jbef and if not, we are in "impossible" land and just stop codegen. -fsanitize-coverage=trace-pc generator twitches one last time: 2b: e8 00 00 00 00 callq __sanitizer_cov_trace_pc
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Andrew Pinski --- Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for __start_builtin_fw and __end_builtin_fw
[Bug c++/77967] New: trying to add a method to a template alias triggers an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77967 Bug ID: 77967 Summary: trying to add a method to a template alias triggers an internal compiler error Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kaelig.chatel at lixoft dot com Target Milestone: --- Created attachment 39804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39804=edit preprocessed source code raising the error -- Fixing the code will remove the problem. And the output still gives the location of the error, if no real diagnosis as usual for an invalid code. So, I think this is a trivial bug in its consequencies for users. -- The problem is that an "internal compiler error" is raised for the attached code: - first, a template alias is defined - then, an erroneous code tries to define a method for this template alias as if it was a template class (in the first use case, it was previously a class, and I forgot to clean this part of my code, raising the "internal compiler error"). -- command gcc -v -save-temps -std=c++11 method_on_alias_internal_error.cpp - command outputs --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --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 --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE method_on_alias_internal_error.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o method_on_alias_internal_error.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/5 /usr/include/x86_64-linux-gnu/c++/5 /usr/include/c++/5/backward /usr/lib/gcc/x86_64-linux-gnu/5/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed method_on_alias_internal_error.ii -quiet -dumpbase method_on_alias_internal_error.cpp -mtune=generic -march=x86-64 -auxbase method_on_alias_internal_error -std=c++11 -version -fstack-protector-strong -Wformat -Wformat-security -o method_on_alias_internal_error.s GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609 (x86_64-linux-gnu) compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609 (x86_64-linux-gnu) compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 15157934e8203caff79287fd8f2d2843 method_on_alias_internal_error.cpp:7:1: internal compiler error: in cp_parser_type_name, at cp/parser.c:15248 bar::bar(const T& cr) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-13 Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf --- Started with r235622: commit 73447cc5d17178b0a756be48133e55fdc7574c13 Author: rguenthDate: Fri Apr 29 08:36:49 2016 + 2016-04-29 Richard Biener PR tree-optimization/13962 PR tree-optimization/65686 * tree-ssa-alias.h (ptrs_compare_unequal): Declare. * tree-ssa-alias.c (ptrs_compare_unequal): New function using PTA to compare pointers. * match.pd: Add pattern for pointer equality compare simplification using ptrs_compare_unequal good: callkmem_cache_alloc testq %rax, %rax movq%rax, %r12 je .L28 movq$__start_builtin_fw, %r13 cmpq$__end_builtin_fw, %r13 jne .L86 jmp .L30 .L32: addq$24, %r13 cmpq$__end_builtin_fw, %r13 je .L30 .L86: movq0(%r13), %rsi movq%rbx, %rdi callstrcmp -- bad: callkmem_cache_alloc testq %rax, %rax movq%rax, %r15 movq(%rsp), %r8 je .L6 movq$__start_builtin_fw, %rbx jmp .L7 .L20: addq$24, %rbx .L7: movq(%rbx), %rsi movq%rbp, %rdi callstrcmp
[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77917 --- Comment #7 from PeteVine --- BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by the presence of `-flto` among environment C(XX)FLAGS, as otherwise it definitely makes sense for configure to always sanitize those flags.
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #3 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #2) > Can you bisect? Suspect changes might be the shrink wrapping changes from > last night - r241063 and r241059-r241061. It is much older issue. Even gcc from 20160928 fails. And bisecting is annoying, because unfortunately the failure only happens on bare metal (booting under qemu is fine). So I have to reboot all the time. I will try to bisect by looking at the assembly output.
[Bug c/77966] New: Corrupt function with -fsanitize-coverage=trace-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966 Bug ID: 77966 Summary: Corrupt function with -fsanitize-coverage=trace-pc Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jpoimboe at redhat dot com Target Milestone: --- In the Linux kernel, we found another case (other than bug 70646) where a couple of functions are getting corrupted. Arnd Bergmann reduced it down to a simple test case, and I've reduced it slightly further: $ cat test.c typedef int spinlock_t; extern unsigned int ioread32(void *); struct vnic_wq_ctrl { unsigned int error_status; }; struct vnic_wq { struct vnic_wq_ctrl *ctrl; } mempool_t; struct snic { unsigned int wq_count; __attribute__ ((__aligned__)) struct vnic_wq wq[1]; spinlock_t wq_lock[1]; }; unsigned int snic_log_q_error_err_status; void snic_log_q_error(struct snic *snic) { unsigned int i; for (i = 0; i < snic->wq_count; i++) snic_log_q_error_err_status = ioread32(>wq[i].ctrl->error_status); } $ gcc -O2 -fno-reorder-blocks -fsanitize-coverage=trace-pc -c test.c -o test.o $ objdump -dr test.o test.o: file format elf64-x86-64 Disassembly of section .text: : 0: 53 push %rbx 1: 48 89 fbmov%rdi,%rbx 4: e8 00 00 00 00 callq 95: R_X86_64_PC32__sanitizer_cov_trace_pc-0x4 9: 8b 03 mov(%rbx),%eax b: 85 c0 test %eax,%eax d: 75 09 jne18 f: 5b pop%rbx 10: e9 00 00 00 00 jmpq 15 11: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4 15: 0f 1f 00nopl (%rax) 18: e8 00 00 00 00 callq 1d 19: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4 1d: 48 8b 7b 10 mov0x10(%rbx),%rdi 21: e8 00 00 00 00 callq 26 22: R_X86_64_PC32 ioread32-0x4 26: 83 3b 01cmpl $0x1,(%rbx) 29: 89 05 00 00 00 00 mov%eax,0x0(%rip)# 2f 2b: R_X86_64_PC32 snic_log_q_error_err_status-0x4 2f: 76 de jbef 31: e8 00 00 00 00 callq 36 32: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4 Notice how the function ends unexpectedly after the last call to __sanitizer_cov_trace_pc(). $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Can you bisect? Suspect changes might be the shrink wrapping changes from last night - r241063 and r241059-r241061.
[Bug c/77965] New: -Wduplicated-cond should find duplicated condition / identical expressions of form "a || a" or "a && a"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77965 Bug ID: 77965 Summary: -Wduplicated-cond should find duplicated condition / identical expressions of form "a || a" or "a && a" Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- First, I wonder whether "-Wduplicated-cond" should be enabled by -Wextra (or even -Wall). Secondly, it only warns for "if (a) ... else if (a) ...". However, it would be also useful to warn for "(a || a)" and "(a && a)" as such code is easily written by copy'n'paste. [Possibly, instead of -Wduplicated-cond it should be used with -Wtautological-compare?] By comparison, cppcheck finds this issue and outputs: (style) Same expression on both sides of '||'. Example: #include int foo(int x) { assert (x == 5 || x == 5); return (x == 5 || x == 5) ? 1 : 0; }
[Bug c/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #1 from Markus Trippelsdorf --- markus@x4 linux % gcc --save-temps -Wp,-MD,drivers/base/.firmware_class.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -march=k8 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-maybe-uninitialized -Wno-frame-address -O2 --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO -DKBUILD_BASENAME='"firmware_class"' -DKBUILD_MODNAME='"firmware_class"' -c -o drivers/base/firmware_class.o drivers/base/firmware_class.c
[Bug c/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0
[Bug target/77826] [7 Regression] ICE in decompose, at wide-int.h:928 w/ -m64 -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826 --- Comment #9 from Richard Biener --- Author: rguenth Date: Thu Oct 13 12:15:38 2016 New Revision: 241108 URL: https://gcc.gnu.org/viewcvs?rev=241108=gcc=rev Log: 2016-10-13 Richard BienerPR middle-end/77826 * genmatch.c (struct capture): Add value_match member. (commutate): Preserve value_match. (lower_opt_convert): Likewise. (lower_cond): Likewise. (replace_id): Likewise. (struct dt_operand): Add value_match member. (decision_tree::cmp_node): Compare it. (decision_tree::insert_operand): Honor it when finding and when appending a DT_MATCH. (dt_operand::gen_match_op): Generate a type check after operand_equal_p if ! value_match for both GENERIC and GIMPLE. (parser::get_internal_capture_id): New helper. (parser::finish_match_operand): New function lowering @@. (parser::parse_capture): Parse @@ as value-match. (parser::parse_expr): Use get_internal_capture_id. (parser::parse_simplify): Call finish_match_operand. (walk_captures): New helper. * match.pd (X - (X / Y) * Y -> X % Y): Use value-matching instead of operand_equal_p. ((X /[ex] A) * A -> X): Likewise. ((X | Y) ^ X -> Y & ~ X): Handle constants properly by using convert[12] and value-matching. ((A | B) & (A | C) -> A | (B & C)): Likewise. ((X | Y) | Y -> X | Y): Likewise. ((X ^ Y) ^ Y -> X): Likewise. (A - (A & B) -> ~B & A): Likewise. ((T)(P + A) - (T)P -> (T) A): Likewise. ((T)P - (T)(P + A) -> -(T) A): Likewise. ((T)(P + A) - (T)(P + B) -> (T)A - (T)B): Likewise. * doc/match-and-simplify.texi: Amend capture section. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/match-and-simplify.texi trunk/gcc/genmatch.c trunk/gcc/match.pd
[Bug c/77964] New: [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Bug ID: 77964 Summary: [7 Regression] Linux kernel firmware loader miscompiled Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Created attachment 39803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39803=edit unreduced testcase A Linux kernel build with gcc trunk crashes early during boot. It happens during loading of builtin firmware. RIP points to strcmp() in fw_get_builtin_firmware() on a bogus address. markus@x4 linux % scripts/faddr2line ./vmlinux _request_firmware+0xa8 _request_firmware+0xa8/0xff: fw_get_builtin_firmware at drivers/base/firmware_class.c:55 (inlined by) _request_firmware_prepare at drivers/base/firmware_class.c:1066 (inlined by) _request_firmware at drivers/base/firmware_class.c:1149 drivers/base/firmware_class.c: 49 static bool fw_get_builtin_firmware(struct firmware *fw, const char *name, 50 void *buf, size_t size) 51 { 52 struct builtin_fw *b_fw; 53 54 for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { 55 if (strcmp(name, b_fw->name) == 0) { 56 fw->size = b_fw->size; 57 fw->data = b_fw->data; 58 59 if (buf && fw->size <= size) 60 memcpy(buf, fw->data, fw->size); 61 return true; 62 } 63 } 64 65 return false; 66 } I have attached the firmware_class.i file. The kernel crashes for -O1 -O2 and -Os. Strangely -O3 is fine. Haven't looked deeper yet, but maybe someone sees what is going on?
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 --- Comment #1 from Jonathan Wakely --- (In reply to David Krauss from comment #0) > This is not conforming. Hmm, I think that's debatable. [func.wrap.func.con] says: Throws: shall not throw exceptions if f’s target is a callable object passed via reference_wrapper or a function pointer. By your interpretation, it is impossible for the target to be a callable object passed by reference_wrapper, because the target will be the reference_wrapper itself. This wording seems to imply that when the function(F) constructor is passed a reference_wrapper the target should be the wrapped T. However, the function(F) constructor doesn't say anything like that, it says "*this targets a copy of f". So I'm tempted to say this is a defect in the standard. The copy constructor is trying to be helpful, and say it won't throw under certain conditions, but it does so confusingly.
[Bug c/77946] -Wimplicit-fallthrough=1 ICE: tree check: expected tree that contains ‘decl with visibility’ structure, have ‘label_decl’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77946 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77558 --- Comment #11 from Tom de Vries --- Author: vries Date: Thu Oct 13 11:40:33 2016 New Revision: 241103 URL: https://gcc.gnu.org/viewcvs?rev=241103=gcc=rev Log: Revert backport "Remove RECORD_TYPE special-casing in std_canonical_va_list_type" 2016-10-13 Tom de Vriesrevert: 2016-10-11 Tom de Vries backport from trunk: 2016-10-11 Tom de Vries PR middle-end/77558 * builtins.c (std_canonical_va_list_type): Remove RECORD_TYPE special-casing. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/builtins.c
[Bug c/77946] -Wimplicit-fallthrough=1 ICE: tree check: expected tree that contains ‘decl with visibility’ structure, have ‘label_decl’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77946 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Oct 13 10:42:36 2016 New Revision: 241094 URL: https://gcc.gnu.org/viewcvs?rev=241094=gcc=rev Log: PR c/77946 * tree.h (FALLTHROUGH_LABEL_P): Use private_flag instead of public_flag. * varasm.c (default_binds_local_p_3): Formatting fix. * c-c++-common/Wimplicit-fallthrough-34.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-34.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h trunk/gcc/varasm.c
[Bug c++/77431] warn for having the same code in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Polacek --- Coalescing. *** This bug has been marked as a duplicate of bug 64279 ***
[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279 Marek Polacek changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Marek Polacek --- *** Bug 77431 has been marked as a duplicate of this bug. ***
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #12 from Alexander Volkov --- Sorry, it should be struct B : A { virtual void f() final; }; in the first example.
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 Alexander Volkov changed: What|Removed |Added CC||a.volkov at rusbitech dot ru --- Comment #11 from Alexander Volkov --- Please, reopen. Of course, it makes sense to suggest adding override in the following case: struct A { virtual void f(); }; struct B : A { virtual void f() final override; }; B::f() is specified as virtual, so if we remove A::f(), then B::f() will not become a new virtual, but we'll get a compile error instead thanks to 'override' keyword. But it is redundant in the following case: struct A { virtual void f(); }; struct B : A { void f() final; }; It is absolutely clear that B::f() overrides A::f(). If we remove A::f() or change it's signature, then we'll get an error. There is no need to add 'override' here.
[Bug tree-optimization/77943] [5/6 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943 Martin Liška changed: What|Removed |Added Summary|[5/6/7 Regression] |[5/6 Regression] |Optimization incorrectly|Optimization incorrectly |commons noexcept calls with |commons noexcept calls with |non-noexcept calls |non-noexcept calls --- Comment #8 from Martin Liška --- Fixed on trunk.
[Bug c++/68391] -Wsuggest-override does not work on Item 12 of Effective Modern C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68391 Alexander Volkov changed: What|Removed |Added CC||a.volkov at rusbitech dot ru --- Comment #1 from Alexander Volkov --- -Wsuggest-override should not produce warnings in this case, because none of members of Derived override virtual functions of Base. -Woverloaded-virtual has another meaning: "With this option, the compiler warns when you define a function with the same name as a virtual function, but with a type signature that does not match any declarations from the base class."
[Bug tree-optimization/77943] [5/6/7 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943 --- Comment #7 from Martin Liška --- Author: marxin Date: Thu Oct 13 10:06:35 2016 New Revision: 241090 URL: https://gcc.gnu.org/viewcvs?rev=241090=gcc=rev Log: Do not merge BBs with a different EH landing pads (PR PR tree-optimization/77943 * g++.dg/tree-ssa/pr77943.C: New test. PR tree-optimization/77943 * tree-ssa-tail-merge.c (merge_stmts_p): Do not merge BBs with a different EH landing pads. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr77943.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 39802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39802=edit gcc7-pr77959.patch Untested fix.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- expand_assignment is called with REALPART_EXPRas to, where C.3418 is CONST_DECL. Of course one can't store into a CONST_DECL. If I compare this to how we compile: program p interface subroutine s(x) real :: x end end interface call s(1.0) end subroutine s(x) real :: x x = x + 1 end then the difference is that to_rtx = expand_expr (to, NULL_RTX, VOIDmode, EXPAND_WRITE); in that case returns (mem:SF (reg/f:DI 90) [1 C.3418+0 S4 A32]) and not the CONST_DOUBLE. I'll have a look.
[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77959 --- Comment #7 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #6) > Maybe turning on RTL checking will find the problem is located. Indeed, the rtl-checking enabled build says: internal compiler error: RTL check: expected code 'mem', have 'const_double' in get_mem_attrs, at rtl.h:3300 0xa8b327 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) ../../git/gcc/gcc/rtl.c:811 0x8345d8 get_mem_attrs ../../git/gcc/gcc/rtl.h:3300 0x83038b get_mem_attrs ../../git/gcc/gcc/expr.c:6950 0x83038b store_field ../../git/gcc/gcc/expr.c:6778 0x82d2e3 expand_assignment(tree_node*, tree_node*, bool) ../../git/gcc/gcc/expr.c:5167 0x7253bd expand_gimple_stmt_1 ../../git/gcc/gcc/cfgexpand.c:3649 0x7253bd expand_gimple_stmt ../../git/gcc/gcc/cfgexpand.c:3745
[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77962 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- Created attachment 39801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39801=edit preliminary patch This patch fixes the i386 problem (or, works around it). On 32-bit i386 the split prologue has to be created before the regular prologue as far as I see. Testing now if that works on powerpc; if not, we can always also disallow separate shrink-wrapping functions with split stack (maybe not a bad idea anyway).
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #10 from vehre at gcc dot gnu.org --- Waiting one week before backporting to gcc-6.
[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72832 --- Comment #9 from vehre at gcc dot gnu.org --- Author: vehre Date: Thu Oct 13 08:51:21 2016 New Revision: 241088 URL: https://gcc.gnu.org/viewcvs?rev=241088=gcc=rev Log: gcc/fortran/ChangeLog: 2016-09-01 Andre VehreschildPR fortran/72832 * trans-expr.c (gfc_copy_class_to_class): Add generation of runtime array bounds check. * trans-intrinsic.c (gfc_conv_intrinsic_size): Add a crutch to get the descriptor of a function returning a class object. * trans-stmt.c (gfc_trans_allocate): Use the array spec on the array to allocate instead of the array spec from source=. gcc/testsuite/ChangeLog: 2016-09-01 Andre Vehreschild PR fortran/72832 * gfortran.dg/allocate_with_source_22.f03: New test. * gfortran.dg/allocate_with_source_23.f03: New test. Expected to fail. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_22.f03 trunk/gcc/testsuite/gfortran.dg/allocate_with_source_23.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/77963] New: inconsistent (false?) leaks detection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77963 Bug ID: 77963 Summary: inconsistent (false?) leaks detection. Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: pawel_sikora at zoho dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 39800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39800=edit testcase hi, i've observed that running application under gdb/ltrace/strace reports strange memory leaks, e.g: % make g++ -Wall -g2 s.cpp -fsanitize=address -Og -shared -fPIC -o s.so -lboost_thread g++ -Wall -g2 m.cpp -fsanitize=address -Og -o m ./s.so -ldl [pawels@pawels]~/ssd/leaks% ./m; echo $? 0 [pawels@pawels]~/ssd/leaks% ltrace ./m __asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0x7f833ad36540) = 0 __libc_start_main([ "./m" ] __asan_init(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0 __asan_version_mismatch_check_v6(1, 0x7ffddcdce888, 0x7ffddcdce898, 0) = 0 __asan_register_globals(0x601080, 2, 0x7ffddcdce898, 0) = 0 dlopen("./s.so", 1) = 0x7f833cbabb18 dlsym(0x7f833cbabb18, "foo") = 0x7f833b7e4d20 dlclose(0x7f833cbabb18) = 0 __asan_unregister_globals(0x601080, 2, 0, 1) = 0x80078140 = ==4777==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 440 byte(s) in 1 object(s) allocated from: #0 0x7f833baaeea0 in operator new(unsigned long) (/lib64/libasan.so.3+0xc7ea0) #1 0x7f833a33a83d in boost::detail::make_external_thread_data() (/lib64/libboost_thread.so.1.60.0+0x1283d) Indirect leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7f833baaeea0 in operator new(unsigned long) (/lib64/libasan.so.3+0xc7ea0) #1 0x7f833a33a9e9 in boost::detail::make_external_thread_data() (/lib64/libboost_thread.so.1.60.0+0x129e9) SUMMARY: AddressSanitizer: 464 byte(s) leaked in 2 allocation(s). +++ exited (status 1) +++
[Bug target/77957] [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Oct 13 08:29:03 2016 New Revision: 241087 URL: https://gcc.gnu.org/viewcvs?rev=241087=gcc=rev Log: PR target/77957 * hooks.h (hook_tree_void_null): Declare. * hooks.c (hook_tree_void_null): New function. * langhooks.c (lhd_return_null_tree_v): Remove. * langhooks-def.h (lhd_return_null_tree_v): Remove. * cfgexpand.c (stack_protect_prologue): If guard_decl is NULL, set y to const0_rtx. * function.c (stack_protect_epilogue): Likewise. * config/tilepro/tilepro.c (TARGET_STACK_PROTECT_GUARD): Redefine if TARGET_THREAD_SSP_OFFSET is defined. * config/s390/s390.c (TARGET_STACK_PROTECT_GUARD): Likewise. * config/sparc/sparc.c (TARGET_STACK_PROTECT_GUARD): Likewise. * config/tilegx/tilegx.c (TARGET_STACK_PROTECT_GUARD): Likewise. * config/rs6000/rs6000.c (TARGET_STACK_PROTECT_GUARD): Likewise. * config/i386/i386.c (TARGET_STACK_PROTECT_GUARD): Likewise. (ix86_stack_protect_guard): New function. c/ * c-objc-common.h (LANG_HOOKS_GETDECLS): Use hook_tree_void_null instead of lhd_return_null_tree_v. ada/ * gcc-interface/misc.c (LANG_HOOKS_GETDECLS): Use hook_tree_void_null instead of lhd_return_null_tree_v. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-objc-common.h trunk/gcc/cfgexpand.c trunk/gcc/config/i386/i386.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/s390/s390.c trunk/gcc/config/sparc/sparc.c trunk/gcc/config/tilegx/tilegx.c trunk/gcc/config/tilepro/tilepro.c trunk/gcc/function.c trunk/gcc/hooks.c trunk/gcc/hooks.h trunk/gcc/langhooks-def.h trunk/gcc/langhooks.c
[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77962 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-13 CC||ian at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||uros at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1