[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 Richard Biener changed: What|Removed |Added Target Milestone|7.0 |5.5 --- Comment #6 from Richard Biener --- Fixed on trunk sofar (will backport - this is a latent issue in other ways as well).
[Bug tree-optimization/77879] [7 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Oct 7 07:44:47 2016 New Revision: 240854 URL: https://gcc.gnu.org/viewcvs?rev=240854&root=gcc&view=rev Log: 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c/77883] ice with -Wall flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77883 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-07 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Me neither.
[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67958 --- Comment #2 from Iain Sandoe --- On Darwin, PIE implies PIC (all executables that can be PIE are 'dynamic') - (the case of mdynamic-no-pic is not combinable with pie). so, on Darwin, the output of -1 should be the same as -2; (likewise -3 & -4; -5 & -6; -7 & -8). So, for 1,3,5,7 the current tests could be conditionalised on ! *-*-darwin* and the checks from 2,4,6,8 copied in and made conditional on *-*-darwin*.
[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-10-07
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
So you are complaining that VRP doesn't compute a range for n? Because I can't
see the tree-ssa-strlen pass computing ranges.
Confirmed for VRP. It seems to ignore most builtins completely.
unsigned f (int i)
{
if (i >= 0 && i < 2)
{
const char *p = "abc";
p += i;
return __builtin_strlen (p);
}
return 0;
}
Found new range for _2: [0, 1]
marking stmt to be not simulated again
Visiting statement:
p_6 = "abc" + _2;
Found new range for p_6: VARYING
Visiting statement:
_3 = __builtin_strlen (p_6);
Found new range for _3: VARYING
p_6 would be [&"abc", &"abc"+1] not sure if we have a useful way to represent
it. I guess &MEM["abc"], &MEM["abc" + 1] with the same &STRING_CST would be
it.
[Bug sanitizer/77891] Signed overflow sanitizer doesn't catch multiplication overflows due to promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77891 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-07 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- (In reply to Andrew Pinski from comment #1) > Convert.c comes into play again. In particular its "premature" optimization performing narrowing of the integer multiplication to unsigned short multiplication.
[Bug c/77883] ice with -Wall flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77883 David Binderman changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from David Binderman --- (In reply to Richard Biener from comment #3) > Me neither. I tried again with a later copy of gcc trunk (revision 240853) and am not able to reproduce here. My apologies for wasting your times. I've reported over 300 bugs in gcc over the last six years and this is one of very few false reports.
[Bug c/69356] Wrong description of compound literals for scalar types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69356 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/onlined | |ocs/gcc/Compound-Literals.h | |tml | Component|web |c --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html
[Bug c/69356] compound literals for scalar types are still lvalues unlike casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69356 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-07 Summary|Wrong description of|compound literals for |compound literals for |scalar types are still |scalar types|lvalues unlike casts Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- (In reply to Christian Brauner from comment #0) > In section 6.26 Compound Literals of the gcc manual it is stated that > > "Compound literals for scalar types and union types are also allowed, but > then the compound literal is equivalent to a cast." > > Which is either wrong or at least misleading. A cast does not yield an > lvalue It did in older versions of GCC as an extension (maybe undocumented). So I suspect when that extension was removed; this wording was not changed.
[Bug web/45778] Append summary information instead of prepending the information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 --- Comment #8 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > I like the fact that the bugzilla URL is topmost, that no longer requires > me scrolling down. Me too. I was looking at older emails from bugzilla and compared them to the newer ones, I had harder time dealing with the olders. Note this was just recently I have been looking at ones older than 2010.
[Bug web/32927] Online installation instructions only for mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927 Andrew Pinski changed: What|Removed |Added CC||schnetter at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 53919 has been marked as a duplicate of this bug. ***
[Bug web/53919] Version-specific install instructions not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Andrew Pinski --- Dup of bug 32927. *** This bug has been marked as a duplicate of bug 32927 ***
[Bug fortran/77884] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-07 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, however I can see ICEs on all releases that support -fcoarray (4.7.0+).
[Bug fortran/77885] ICE in gfc_add_class_array_ref, at fortran/class.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-07 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.0 --- Comment #1 from Martin Liška --- Confirmed, 4.7.x accepts the code.
[Bug driver/58505] jv-convert fails to compile with gcj-4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58505 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- Won't fix java has been removed from GCC 7.
[Bug driver/56244] -O3 should imply -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56244 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- No longer working on it. It was suggested unrolling should be not be used in itself but rather a tool for other passes to use it.
[Bug driver/26686] ../../../gcc/libgfortran/mk-kinds-h.sh: Unknown type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26686 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-07 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Does this work now?
[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-07 Ever confirmed|0 |1 --- Comment #11 from Andrew Pinski --- Does this happen with newer versions of GCC?
[Bug driver/63869] gcc-4.9.2 make failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63869 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-07 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Does this work now? Also can you supply the exact command sequence you used to configure/invoke make?
[Bug pending/55996] [meta-bug] GCC 4.9 pending patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- .
[Bug bootstrap/23198] AC_PROG_INSTALL (autoconf 2.13) does not detect bad install program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23198 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski --- No feedback in over 4 years so closing.
[Bug bootstrap/33070] Bootstrap comparison failure between stage2/3 but no objdump differences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33070 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- No feedback in over 4 years so closing.
[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- .
[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320 Andrew Pinski changed: What|Removed |Added Keywords||build Status|WAITING |NEW
[Bug target/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.2.2 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug tree-optimization/77893] New: VRP simplify_bit_ops_using_ranges should be applied during propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77893 Bug ID: 77893 Summary: VRP simplify_bit_ops_using_ranges should be applied during propagation Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: easyhack, missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- A redundant _3 = _2 & _1; that is replaced by _3 = _2; should instead produce a [_2, _2] range for _3 during propagation.
[Bug testsuite/39774] New: FAIL: g++/g++.dg-struct-layout-1//t004_x.C on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39774 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No feedback in over 7 years.
[Bug fortran/77885] ICE in gfc_add_class_array_ref, at fortran/class.c:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77885 --- Comment #2 from Dominique d'Humieres --- The change occurred between revisions r192440 (2012-10-14, compiles) and r192525 (2012-10-17, ICE), likely r192495 (pr50981 and pr54618). If I replace 'class' with 'type' I get the error call s(x) 1 Error: Actual argument to 'x' at (1) must be a coarray
[Bug fortran/77884] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77884 --- Comment #3 from Dominique d'Humieres --- The tests compiles with '-fcoarray=single' for gfortran configured with '--enable-checking=release'.
[Bug other/77894] New: Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894
Bug ID: 77894
Summary: Enable GNU indirect function support by default as it
will be used in glibc.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: stli at linux dot vnet.ibm.com
Target Milestone: ---
Starting with glibc-commits "Add configure check to test if gcc supports
attribute ifunc."
(https://sourceware.org/git/?p=glibc.git;a=commit;h=022dfdce000374b60aadfb0a5ed9a5c4c1dbd29b),
"Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to
false... "
(https://sourceware.org/git/?p=glibc.git;a=commit;h=00980d845f8f2ec3ed4ad161a1e5b97704be1929)
and further, for glibc with multi-arch support it is recommended to use a GCC
which has been built with support for GNU indirect functions. This ensures that
correct debugging information is generated for functions selected by IFUNC
resolvers. This support can either be enabled by configuring GCC with
'--enable-gnu-indirect-function', or by enabling it by default by setting
'default_gnu_indirect_function' variable for a particular architecture in the
GCC source file 'gcc/config.gcc'.
Currently GNU indirect function support is only enabled by default for few
configurations like intel and s390. Please enable it by default for other
architectures, too. E.g. according to the rpm-spec file fedora/rhel is
configuring gcc with --enable-gnu-indirect-function for the following
architectures: %{ix86} x86_64 ppc ppc64 ppc64le ppc64p7 s390 s390x %{arm}
aarch64.
Perhaps a configure check could test the presence of the non-standard gnu ifunc
support in the assembler, linker and dynamic linker and could automatically
dis/enable the support. But this behaviour should be discussed by the gcc
maintainers.
[Bug tree-optimization/77664] Missed optimization: signed int >= 0 && < unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77664 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Oct 7 09:33:47 2016 New Revision: 240858 URL: https://gcc.gnu.org/viewcvs?rev=240858&root=gcc&view=rev Log: PR tree-optimization/77664 * tree-ssa-reassoc.c (update_range_test): Also clear low and high for the other ranges. (optimize_range_tests_diff): Fix up formatting. (optimize_range_tests_var_bound): New function. (optimize_range_tests): Use it. * gcc.dg/tree-ssa/pr77664.c: New test. * gcc.dg/pr77664.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr77664.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr77664.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- You haven't provided complete testcase, but #c2 certainly doesn't warn for me with -Wimplicit-fallthrough and current trunk.
[Bug other/77894] Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- the ifunc abi still has many problems and i don't think it's possible to detect dynamic linker support for cross compilation so if it is enabled do it only if the default libc is glibc (e.g. on linux musl, bionic and uclibc does not plan to implement it).
[Bug tree-optimization/77664] Missed optimization: signed int >= 0 && < unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77664 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/77890] class template type deduction fails for lambda functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77890 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-07 CC||jason at redhat dot com, ||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug tree-optimization/77895] New: Unaligned movdqa generated by GCC 6.2.0 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77895 Bug ID: 77895 Summary: Unaligned movdqa generated by GCC 6.2.0 with -O3 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jack.d.whitham at gmail dot com Target Milestone: --- Created attachment 39766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39766&action=edit Test case to reproduce bug A strange custom implementation of "memcpy" from a data compression library is badly vectorized by GCC 6.2.0 when using "-O3", or alternatively "-O1 -fvect-cost-model -ftree-loop-vectorize". The vectorizer seems to assume that the "src" address is word-aligned, but there is no reason to assume so (it's an "unsigned char*"). The program segfaults at the "movdqa" instruction. Bug can be reproduced with GCC 6.2.0 on Debian "sid" AMD64: $ gcc-6 -v Using built-in specs. COLLECT_GCC=gcc-6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --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 6.2.0 20160927 (Debian 6.2.0-5) $ gcc-6 -O3 example.c -o example $ ./example Segmentation fault This bug is also in GCC 5.4.1 and GCC 4.9.4, but apparently not in GCC 4.8. This bug occurs with x86 code as well as AMD64. Please accept my apologies for guessing about the component and if this issue is already known. I searched for duplicates and found a number of similar-sounding bugs, but all were marked as "resolved" in earlier versions of GCC.
[Bug tree-optimization/77895] Unaligned movdqa generated by GCC 6.2.0 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77895 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- *((unsigned int*)dst) = *((unsigned int*)src); this requires dst and src to be aligned as 'unsigned int'. Thus vectorization will peel until it reaches alignment (which it can't for your 1-byte aligned src/dst).
[Bug target/77894] Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894 --- Comment #2 from Florian Weimer --- (In reply to nsz from comment #1) > the ifunc abi still has many problems and i don't think it's possible to > detect > dynamic linker support for cross compilation so if it is enabled do it only > if > the default libc is glibc (e.g. on linux musl, bionic and uclibc does not > plan to implement it). Will GCC generate IFUNCs although the attribute is never used? If it is harmless to enable it, I'd suggest to do so unconditionally, so that people can cross-build glibc on any Linux system using the system compiler.
[Bug target/77894] Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894 --- Comment #3 from nsz at gcc dot gnu.org --- currently --enable-gnu-indirect-function enables its use in gcc target libs like libatomic which breaks if the libc has no support for it. (In reply to Florian Weimer from comment #2) > (In reply to nsz from comment #1) > > the ifunc abi still has many problems and i don't think it's possible to > > detect > > dynamic linker support for cross compilation so if it is enabled do it only > > if > > the default libc is glibc (e.g. on linux musl, bionic and uclibc does not > > plan to implement it). > > Will GCC generate IFUNCs although the attribute is never used? > > If it is harmless to enable it, I'd suggest to do so unconditionally, so > that people can cross-build glibc on any Linux system using the system > compiler. currently --enable-gnu-indirect-function enables ifuncs in gcc target libs like libatomic, which breaks if the libc has no support for it (i think this is a significant abi commitment between gcc and libc which is not justified).
[Bug c++/77803] [7 Regression] Bogus implicit-fallthrough warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77803 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Oct 7 11:45:50 2016 New Revision: 240861 URL: https://gcc.gnu.org/viewcvs?rev=240861&root=gcc&view=rev Log: PR c++/77803 * gimplify.c (last_stmt_in_scope): Add check for FALLTHROUGH (). * g++.dg/warn/Wimplicit-fallthrough-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/77803] [7 Regression] Bogus implicit-fallthrough warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77803 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/77892] local function declarations don't match namespace scope declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77892
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-10-07
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Without line-wrapping:
struct S{friend void f(){}};
void f();
int main()
{
void f();
f();
}
/tmp/cchVsieq.o: In function `main':
/tmp/f.cc:8: undefined reference to `f()'
collect2: error: ld returned 1 exit status
The local redeclaration prevents the inline definition being emitted.
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 --- Comment #4 from Bernd Schmidt --- Author: bernds Date: Fri Oct 7 12:16:55 2016 New Revision: 240862 URL: https://gcc.gnu.org/viewcvs?rev=240862&root=gcc&view=rev Log: PR tree-optimization/77880 * expr.c (by_pieces_ninsns): Use unsigned HOST_WIDE_INT where necessary. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug c++/69733] -Wignored-qualifiers points to wrong const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733 --- Comment #2 from Bernd Schmidt --- Author: bernds Date: Fri Oct 7 12:21:55 2016 New Revision: 240863 URL: https://gcc.gnu.org/viewcvs?rev=240863&root=gcc&view=rev Log: c/ PR c++/69733 * c-decl.c (smallest_type_quals_location): New static function. (grokdeclarator): Try to find the correct location for an ignored qualifier. cp/ PR c++/69733 * decl.c (grokdeclarator): Try to find the correct location for an ignored qualifier. testsuite/ PR c++/69733 * c-c++-common/pr69733.c: New test. * gcc.dg/pr69733.c: New test. * gcc.target/i386/pr69733.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr69733.c trunk/gcc/testsuite/gcc.dg/pr69733.c trunk/gcc/testsuite/gcc.target/i386/pr69733.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880 Bernd Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Bernd Schmidt --- Fixed.
[Bug c++/69733] -Wignored-qualifiers points to wrong const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733 Bernd Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bernd Schmidt --- Fixed.
[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889 --- Comment #3 from Martin Sebor --- (In reply to Richard Biener from comment #2) > So you are complaining that VRP doesn't compute a range for n? Because I > can't see the tree-ssa-strlen pass computing ranges. > > Confirmed for VRP. It seems to ignore most builtins completely. I wasn't suggesting the problem is in VRP but rather in tree-ssa-strlen. My patch for bug 77608 makes it work by having the plus_stmt_object_size function call get_range_info to obtain the range for the offset so it seems that the same approach should work for strlen. (Please note this isn't meant to be a complaint. I'm pointing out an opportunity for improvement.)
[Bug c++/77700] suspicios code in cp/parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77700 --- Comment #1 from Bernd Edlinger --- Author: edlinger Date: Fri Oct 7 17:10:38 2016 New Revision: 240867 URL: https://gcc.gnu.org/viewcvs?rev=240867&root=gcc&view=rev Log: 2016-10-07 Bernd Edlinger PR c++/77700 * c-common.c (c_common_truthvalue_conversion): Warn also for suspicious enum values in boolean context. cp: 2016-10-07 Bernd Edlinger PR c++/77700 * parser.c (cp_parser_base_specifier): Fix a warning. testsuite: 2016-10-07 Bernd Edlinger PR c++/77700 * c-c++-common/Wint-in-bool-context.c: Update test. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wint-in-bool-context.c
[Bug c++/77700] suspicios code in cp/parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77700 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bernd Edlinger --- fixed on trunk.
[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 7 18:18:03 2016 New Revision: 240870 URL: https://gcc.gnu.org/viewcvs?rev=240870&root=gcc&view=rev Log: 2016-10-07 Steven G. Kargl PR fortran/77406 * interface.c (gfc_compare_interfaces): Fix detection of ambiguous interface involving alternate return. (check_interface1): Improve error message and loci. 2016-10-07 Steven G. Kargl PR fortran/77406 * gfortran.dg/pr77406.f90: New test. * gfortran.dg/assumed_type_3.f90: Update error messages. * gfortran.dg/defined_operators_1.f90: Ditto. * gfortran.dg/generic_26.f90: Ditto. * gfortran.dg/generic_7.f90: Ditto. * gfortran.dg/gomp/udr5.f90: Ditto. * gfortran.dg/gomp/udr7.f90: Ditto. * gfortran.dg/interface_1.f90: Ditto. * gfortran.dg/interface_37.f90: Ditto. * gfortran.dg/interface_5.f90: Ditto. * gfortran.dg/interface_6.f90: Ditto. * gfortran.dg/interface_7.f90 * gfortran.dg/no_arg_check_3.f90 * gfortran.dg/operator_5.f90 * gfortran.dg/proc_ptr_comp_20.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr77406.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_type_3.f90 trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90 trunk/gcc/testsuite/gfortran.dg/generic_26.f90 trunk/gcc/testsuite/gfortran.dg/generic_7.f90 trunk/gcc/testsuite/gfortran.dg/gomp/udr5.f90 trunk/gcc/testsuite/gfortran.dg/gomp/udr7.f90 trunk/gcc/testsuite/gfortran.dg/interface_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_37.f90 trunk/gcc/testsuite/gfortran.dg/interface_5.f90 trunk/gcc/testsuite/gfortran.dg/interface_6.f90 trunk/gcc/testsuite/gfortran.dg/interface_7.f90 trunk/gcc/testsuite/gfortran.dg/no_arg_check_3.f90 trunk/gcc/testsuite/gfortran.dg/operator_5.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90
[Bug c++/77896] New: Object vtable lookups are not hoisted out of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896
Bug ID: 77896
Summary: Object vtable lookups are not hoisted out of loops
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Target Milestone: ---
C++ virtual function calls normally require two memory loads followed by an
indirect jump: one load fetches the vtable from the object, another to fetch
the function address from the vtable, and the indirect call to invoke the
function.
Given that an object's vtable is fixed over its lifetime, and the contents of a
given vtable are compile-time constant, I would expect the vtable lookups to be
hoisted out of loops when appropriate. For example:
foo.cpp ===
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n) {
for (int i=0; i < n; i++)
f->frob(i);
}
Compiles at -O2 to substantially the same x86 assembly code for gcc-4.9,
gcc-5.2 and gcc-6.2:
_Z5frobNP3Fooi:
testl %esi, %esi
jle .L10
pushq %r12
movl%esi, %r12d
pushq %rbp
movq%rdi, %rbp
pushq %rbx
xorl%ebx, %ebx
.L5:
movq0(%rbp), %rax
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*(%rax)
cmpl%ebx, %r12d
jne .L5
popq%rbx
popq%rbp
popq%r12
.L10:
rep ret
I would have expected to see something more like this (obtained using the bound
member function extension):
_Z5frobNP3Fooi:
.LFB12:
pushq %r13
pushq %r12
pushq %rbp
pushq %rbx
subq$8, %rsp
movq(%rdi), %rax
testl %esi, %esi
movq(%rax), %r13
jle .L1
movq%rdi, %r12
movl%esi, %ebp
xorl%ebx, %ebx
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%r12, %rdi
call*%r13
cmpl%ebx, %ebp
jne .L5
.L1:
addq$8, %rsp
popq%rbx
popq%rbp
popq%r12
popq%r13
ret
Altering the test case to trigger speculative devirtualization as follows:
bug2.cpp ===
#include
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n)
{
for (int i=0; i < n; i++)
f->frob(i);
}
struct Bar : Foo {
void frob(int i) { printf("Bar:%d\n", i); }
};
int main()
{
Bar b;
frobN(&b, 10);
}
=
Shows that even the speculative devirtualization is stuck inside the loop body:
_Z5frobNP3Fooi:
testl %esi, %esi
jle .L13
pushq %r12
movl%esi, %r12d
pushq %rbp
movq%rdi, %rbp
pushq %rbx
xorl%ebx, %ebx
jmp .L8
.L16:
xorl%eax, %eax
movl$.LC0, %edi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
je .L15
.L8:
movq0(%rbp), %rax
movl%ebx, %esi
movq(%rax), %rax
cmpq$_ZN3Bar4frobEi, %rax
je .L16
addl$1, %ebx
movq%rbp, %rdi
call*%rax
cmpl%ebx, %r12d
jne .L8
.L15:
popq%rbx
popq%rbp
popq%r12
.L13:
rep ret
If the vtable lookup could be hoisted, the speculative de-virt could become
very powerful by replicating the loop, something like this:
_Z5frobNP3Fooi:
testl %esi, %esi
jle .L10
pushq %r12
movl%esi, %r12d
pushq %rbp
movq%rdi, %rbp
pushq %rbx
xorl%ebx, %ebx
movq0(%rbp), %rax
pushq %r12
movq(%rax), %r13
cmpq$_ZN3Bar4frobEi, %r13
je .L16
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*%r13
cmpl%ebx, %r12d
jne .L5
jmp .L10
.L16:
xorl%eax, %eax
movl$.LC0, %edi
movl%ebx, %esi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
jne .L16
popq%r13
.L10:
popq%rbx
popq%rbp
popq%r12
rep ret
[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Oct 7 18:57:45 2016 New Revision: 240871 URL: https://gcc.gnu.org/viewcvs?rev=240871&root=gcc&view=rev Log: 2016-10-07 Steven G. Kargl PR fortran/77406 * interface.c (gfc_compare_interfaces): Fix detection of ambiguous interface involving alternate return. (check_interface1): Improve error message and loci. 2016-10-07 Steven G. Kargl PR fortran/77406 * gfortran.dg/pr77406.f90: New test. * gfortran.dg/assumed_type_3.f90: Update error messages. * gfortran.dg/defined_operators_1.f90: Ditto. * gfortran.dg/generic_26.f90: Ditto. * gfortran.dg/generic_7.f90: Ditto. * gfortran.dg/gomp/udr5.f90: Ditto. * gfortran.dg/gomp/udr7.f90: Ditto. * gfortran.dg/interface_1.f90: Ditto. * gfortran.dg/interface_37.f90: Ditto. * gfortran.dg/interface_5.f90: Ditto. * gfortran.dg/interface_6.f90: Ditto. * gfortran.dg/interface_7.f90 * gfortran.dg/no_arg_check_3.f90 * gfortran.dg/operator_5.f90 * gfortran.dg/proc_ptr_comp_20.f90: Ditto. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77406.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/interface.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/gfortran.dg/assumed_type_3.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_26.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_7.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr5.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr7.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_1.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_37.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_5.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_6.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_7.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/no_arg_check_3.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/operator_5.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90
[Bug fortran/77897] New: Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 Bug ID: 77897 Summary: Compile error with KNL & -O3 for GTC code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- Created attachment 39767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39767&action=edit Source files module.F90 and pushe.f90 (in bug.tar) As a basic sanity check: > ftn -c module.F90 > ftn -c pushe.f90 > module swap PrgEnv-cray PrgEnv-gnu > ftn -c module.F90 > ftn -c pushe.f90 > ftn -c -O3 module.F90 > ftn -c -O3 pushe.f90 > > module list Currently Loaded Modulefiles: ... 12) gcc/6.2.0 13) craype-network-aries 14) craype-sandybridge Now checking KNL target: > module swap craype-sandybridge craype-mic-knl > ftn -c -O3 module.F90 > ftn -c -O3 pushe.f90 /tmp/cc4TRnzd.s: Assembler messages: /tmp/cc4TRnzd.s:61: Error: bad register name `%xmm24' /tmp/cc4TRnzd.s:63: Error: bad register name `%xmm24' /tmp/cc4TRnzd.s:65: Error: bad register name `%xmm16' ... [many more lines of messages]
[Bug fortran/77897] Compile error with KNL & -O3 for GTC code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897 --- Comment #1 from Bill Long --- Compiling these files appears to have a problem when the target is set to Intel KNL. The compiler appears to be generating incorrect register and instruction names, leading to assembler messages. See with gfortran 6.2. Compiles OK with any of these changes: 1) Change target to Sandybridge 2) Remove the -O3 option 3) Use a different vendor compiler (Cray)
[Bug c/38295] Support pointer difference as constant in static initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295 Florian Weimer changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||fw at gcc dot gnu.org Resolution|WONTFIX |--- --- Comment #10 from Florian Weimer --- This is already implemented for differences between C && label addresses. I think there is no compelling reason why this would not work for the addresses of static functions, too.
[Bug fortran/38592] eliminate some string comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #6 from kargl at gcc dot gnu.org ---
Sometime between 4.8.4 and 4.9.4, the _gfortran_compare_string
has been replaced by a memcmp().
% gfc48 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s
call_gfortran_compare_string
% gfc49 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s
With gcc7, the -fdump-tree-original gives
__builtin_memmove ((void *) &a, (void *) &"yes"[1]{lb: 1 sz: 1}, 3);
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
{
logical(kind=4) D.3408;
D.3408 = __builtin_memcmp ((void *) &"yes"[1]{lb: 1 sz: 1},
(void *) &a, 3) == 0;
_gfortran_transfer_logical_write (&dt_parm.0, &D.3408, 4);
}
_gfortran_st_write_done (&dt_parm.0);
and -fdump-tree-optimized shows
:
MEM[(c_char * {ref-all})&a] = "yes";
dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_1 = __builtin_memcmp_eq (&"yes"[1]{lb: 1 sz: 1}, &a, 3);
_2 = _1 == 0;
D.3408 = _2;
_gfortran_transfer_logical_write (&dt_parm.0, &D.3408, 4);
D.3408 ={v} {CLOBBER};
_gfortran_st_write_done (&dt_parm.0);
dt_parm.0 ={v} {CLOBBER};
a ={v} {CLOBBER};
return;
I personally think this is non-issue now and the bug can be
closed.
[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.3 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on 6 and 7. Closing.
[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443 --- Comment #1 from Nathan Sidwell --- Author: nathan Date: Fri Oct 7 20:01:17 2016 New Revision: 240874 URL: https://gcc.gnu.org/viewcvs?rev=240874&root=gcc&view=rev Log: cp/ PR c++/64433 DR1658, DR1611 * init.c (emit_mem_initializers): Don't construct vbases of abstract classes. (push_base_cleanups): Don't push vbase cleanups for abstract class when in C++14 mode. * method.c (synthethesized_method_walk): Don't walk vbases of abstract classes when in C++14 mode. testsuite/ PR c++/66443 * g++.dg/cpp0x/pr66443-cxx11.C: New. * g++.dg/cpp0x/pr66443-cxx11-2.C: New. * g++.dg/cpp1y/pr66443-cxx14.C: New * g++.dg/cpp1y/pr66443-cxx14-2.C: New. * g++.dg/cpp1y/pr66443-cxx14-3.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
[Bug c++/64433] Segmentation fault while compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433 --- Comment #4 from Nathan Sidwell --- Author: nathan Date: Fri Oct 7 20:01:17 2016 New Revision: 240874 URL: https://gcc.gnu.org/viewcvs?rev=240874&root=gcc&view=rev Log: cp/ PR c++/64433 DR1658, DR1611 * init.c (emit_mem_initializers): Don't construct vbases of abstract classes. (push_base_cleanups): Don't push vbase cleanups for abstract class when in C++14 mode. * method.c (synthethesized_method_walk): Don't walk vbases of abstract classes when in C++14 mode. testsuite/ PR c++/66443 * g++.dg/cpp0x/pr66443-cxx11.C: New. * g++.dg/cpp0x/pr66443-cxx11-2.C: New. * g++.dg/cpp1y/pr66443-cxx14.C: New * g++.dg/cpp1y/pr66443-cxx14-2.C: New. * g++.dg/cpp1y/pr66443-cxx14-3.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed in r240874.
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343 --- Comment #12 from Marc Mutz --- Created attachment 39768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39768&action=edit Preprocessed source for PCH Command line for PCH file: g++ -pipe -g -O3 -std=c++1z \ -I/usr/include/glib-2.0 \ -I/usr/lib/x86_64-linux-gnu/glib-2.0/include \ -pthread \ -fvisibility=hidden \ -fvisibility-inlines-hidden \ -fsanitize=address \ -fsanitize=undefined \ -fno-omit-frame-pointer \ -Wall \ -W \ -Wvla \ -Wdate-time \ -Wshift-overflow=2 \ -Wduplicated-cond \ -Werror \ -Wno-error=cpp \ -Wno-error=deprecated-declarations \ -Wno-error=strict-overflow \ -D_REENTRANT \ -fPIC \ -DQT_NO_USING_NAMESPACE \ -DQT_NO_FOREACH \ -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \ -DQT_USE_ICU \ -DQT_HAVE_POLL \ -DQT_HAVE_PPOLL \ -DQT_BUILD_CORE_LIB \ -DQT_BUILDING_QT \ -DQT_NO_CAST_TO_ASCII \ -DQT_ASCII_CAST_WARNINGS \ -DQT_MOC_COMPAT \ -DQT_USE_QSTRINGBUILDER \ -DQT_DEPRECATED_WARNINGS \ -DQT_DISABLE_DEPRECATED_BEFORE=0x05 \ -D_LARGEFILE64_SOURCE \ -D_LARGEFILE_SOURCE \ -DQT_NO_DEBUG \ -I/home/marc/Qt/qt5/qtbase/src/corelib \ -I. \ -Iglobal \ -I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \ -I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \ -I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \ -I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \ -I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \ -I../../include \ -I../../include/QtCore \ -I../../include/QtCore/5.8.0 \ -I../../include/QtCore/5.8.0/QtCore \ -I.moc \ -I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \ -x c++-header \ -c /home/marc/Qt/qt5/qtbase/src/corelib/global/qt_pch.h \ -o .pch/Qt5Core.gch/c++ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/d/gcc/trunk --enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++ Thread model: posix gcc version 7.0.0 20161005 (experimental) (GCC) git log -10 --oneline c7b01e7 PR sanitizer/77823 * c-ubsan.c (ubsan_instrument_shift): Return NULL_TREE if type0 is not integral. d20 Fix pr69941.c test failure for avr ea55eab 2016-10-05 Jerry DeLisle 9ce1157 PR bootstrap/77819 - undefined reference to gnu_libc_printf_pointer_format with uClibc 5c176eb * c-common.c (c_common_reswords): Update comment for C++11. 4ef2832 [fold-const] Fix native_encode_real for HFmode constants 59deb1a 70564 fix newly-added tests for not_fn c375ef0 libcpp/ChangeLog: 77a1a89 Move all existing strchr and strrchr folding from builtins.c to gimple-fold.c. ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343
Marc Mutz changed:
What|Removed |Added
CC||marc.mutz at kdab dot com
--- Comment #13 from Marc Mutz ---
Created attachment 39769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39769&action=edit
Preprocessed source for a TU that fails
Command line for a TU that fails:
g++ -c -include .pch/Qt5Core -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-o .obj/qlibraryinfo.o \
/home/marc/Qt/qt5/qtbase/src/corelib/global/qlibraryinfo.cpp
Fails with:
{standard input}: Assembler messages:
{standard input}:22992: Error: symbol `.Lubsan_type1' is already defined
[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343 --- Comment #14 from Marc Mutz --- More examples (incl. ones with .Lubsan_type3) available on request.
[Bug tree-optimization/77898] New: VR_RANGE with inverted bounds after evrp and before vrp1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
Bug ID: 77898
Summary: VR_RANGE with inverted bounds after evrp and before
vrp1
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following problem was uncovered during the testing of a patch for bug 77608
and briefly discussed in the thread Re: VR_RANGE with inverted bounds at
https://gcc.gnu.org/ml/gcc/2016-10/msg00054.html.
Given the code below, a call to the get_range_info() function made in
plus_stmt_object_size() in tree-object-size.c yields the VR_RANGE [2147483648,
-2147483649] for the offset i in the (p += i) expression even though the
correct range is [0, 1].
void f (int i)
{
const char *p = "ab";
if (i < 0 || 1 < i)
i = 0;
p += i;
unsigned long n = __builtin_object_size (p, 2);
if (n < 2 || 3 < n)
__builtin_abort ();
}
The .evrp dump for the function shows what looks like an incorrect anti-range.
The .vrp1 dump, however, shows the correct range.
Value ranges after Early VRP:
i.0_1: [0, +INF]
_2: ~[2147483648, 18446744071562067967]
_3: [0, +INF]
i_4: VARYING
i_6(D): VARYING
p_8: VARYING
n_10: VARYING
f (int i)
{
int i_6(D) = i;
long unsigned int n;
const char * p;
unsigned int i.0_1;
sizetype _2;
long unsigned int _3;
:
# RANGE [0, 4294967295]
i.0_1 = (unsigned int) i_6(D);
if (i.0_1 > 1)
goto ;
else
goto ;
:
:
# i_4 = PHI
# RANGE ~[2147483648, 18446744071562067967]
_2 = (sizetype) i_4;
# PT =
p_8 = "ab" + _2;
...
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #5 from Marc Mutz --- It's in a function template, in case that helps. I'll try to trim it down now.
[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886
--- Comment #6 from Marc Mutz ---
Created attachment 39770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39770&action=edit
Test case
Result:
$ g++ -Wextra -std=c++1z -O2 bug.cpp
bug.cpp: In function ‘void qt_memfill(T*, T, int) [with T = int]’:
bug.cpp:10:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 0: do { *dest++ = value;
^
bug.cpp:12:7: note: here
case 7: *dest++ = value;
^~~~
bug.cpp:12:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 7: *dest++ = value;
^
bug.cpp:14:7: note: here
case 6: *dest++ = value;
^~~~
bug.cpp:14:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 6: *dest++ = value;
^
bug.cpp:16:7: note: here
case 5: *dest++ = value;
^~~~
bug.cpp:16:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 5: *dest++ = value;
^
bug.cpp:18:7: note: here
case 4: *dest++ = value;
^~~~
bug.cpp:18:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 4: *dest++ = value;
^
bug.cpp:20:7: note: here
case 3: *dest++ = value;
^~~~
bug.cpp:20:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
case 3: *dest++ = value;
^
bug.cpp:22:7: note: here
case 2: *dest++ = value;
^~~~
iow: only the attribute helps.
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #7 from Marc Mutz --- Version: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/d/gcc/trunk --enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++ Thread model: posix gcc version 7.0.0 20161005 (experimental) (GCC) Specifically: $ git log -10 --online c7b01e7 PR sanitizer/77823 * c-ubsan.c (ubsan_instrument_shift): Return NULL_TREE if type0 is not integral. d20 Fix pr69941.c test failure for avr ea55eab 2016-10-05 Jerry DeLisle 9ce1157 PR bootstrap/77819 - undefined reference to gnu_libc_printf_pointer_format with uClibc 5c176eb * c-common.c (c_common_reswords): Update comment for C++11. 4ef2832 [fold-const] Fix native_encode_real for HFmode constants 59deb1a 70564 fix newly-added tests for not_fn c375ef0 libcpp/ChangeLog: 77a1a89 Move all existing strchr and strrchr folding from builtins.c to gimple-fold.c. ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #8 from Marc Mutz --- #c3 is also in a template, indeed.
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-10-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Jakub Jelinek --- Created attachment 39771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39771&action=edit gcc7-pr77886.patch Untested fix.
[Bug tree-optimization/77899] New: incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899
Bug ID: 77899
Summary: incorrect VR_RANGE for a signed char function argument
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Similar to bug 77898 but with different and more wide-ranging symptoms (it
persists past even the last invocation of the VRP pass), in the following
program the range of the variable i is bounded by its type to [-128, 127].
Thus the result of the (p += i) expression is guaranteed to be in the range [d
+ 2, d + 257] and the if expression always false. However, GCC represents the
range of the signed char offset by the VR_ANTI_RANGE ~[128,
18446744073709551487] and fails to optimize the if statement away.
This is another case that popped up during the testing of my patch for bug
77608 where it affects the result of __builtin_object_size.
$ cat x.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S
-Wall -Wextra -Wpedantic -fdump-tree-vrp=/dev/stdout x.c
void f (signed char i)
{
char d [260];
const char *p = &d[130];
p += i;
if (p < d + 2 || d + 257 < p)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5
;; 2 succs { 4 3 }
;; 3 succs { 4 5 }
;; 4 succs { }
;; 5 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
p_7 -> { p_3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)
Value ranges after VRP:
_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
p_7: VARYING
f (signed char i)
{
const char * p;
char d[260];
sizetype _1;
:
_1 = (sizetype) i_2(D);
p_3 = &d[130] + _1;
if (&MEM[(void *)&d + 2B] > p_3)
goto ;
else
goto ;
:
if (&MEM[(void *)&d + 257B] < p_3)
goto ;
else
goto ;
:
__builtin_abort ();
:
d ={v} {CLOBBER};
return;
}
;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { }
;; 4 succs { 1 }
Value ranges after VRP:
_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
_7: [0, +INF]
_8: [0, +INF]
_9: [0, +INF]
f (signed char i)
{
const char * p;
char d[260];
sizetype _1;
_Bool _7;
_Bool _8;
_Bool _9;
:
_1 = (sizetype) i_2(D);
p_3 = &d[130] + _1;
_7 = &MEM[(void *)&d + 257B] < p_3;
_8 = &MEM[(void *)&d + 2B] > p_3;
_9 = _8 | _7;
if (_9 != 0)
goto ;
else
goto ;
:
__builtin_abort ();
:
d ={v} {CLOBBER};
return;
}
[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899 --- Comment #1 from Andrew Pinski --- This is the complex part because size_type is unsigned so the range converting from signed [-127, 128] to unsigned is ~[128, 18446744073709551487]
[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899 --- Comment #2 from Andrew Pinski --- So to fix this in reality is to change how POINTER_PLUS_EXPR takes an unsigned integer to be a signed integer. But this will take many extra issues and need to be done though out the compiler.
[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886 --- Comment #10 from Marc Mutz --- I can confirm patch fixes my Qt build, ie. not just bug.cpp. Thanks!
[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899 --- Comment #3 from Martin Sebor --- The offset is this in plus_stmt_object_size() in tree-object-size.c: unit size align 64 symtab 0 alias set -1 canonical type 0x70da41f8 precision 64 min max > static visited def_stmt _1 = (sizetype) i_3(D); version 1 ptr-info 0x70ec8f20> I can work around it there by checking the type of i_3(D) (which is signed char) and using its range to bound _1. I wonder if this same workaround could be put in get_range_info until POINTER_PLUS_EXPR is changed to take a signed offset as you suggest.
[Bug c++/77887] -Wimplicit-fallthrough fails to trigger in an unused function template specialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77887 --- Comment #2 from Marc Mutz --- Created attachment 39772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39772&action=edit Expanded version of test-case for 77886, adding an unused inline non-template overload of the function template Findings: l.30 \ l.29 template specialisation overload inline - doesn"t warn - doesn't warn non-inline + warns + warns
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Dominique d'Humieres changed: What|Removed |Added CC||bugs at stellardeath dot org --- Comment #4 from Dominique d'Humieres --- *** Bug 64947 has been marked as a duplicate of this bug. ***
[Bug fortran/64947] ICE in gimplify_expr, at gimplify.c:8425 with arrays of type(C_PTR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64947 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Dominique d'Humieres --- Duplicate of pr50892. *** This bug has been marked as a duplicate of bug 50892 ***
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 --- Comment #5 from Dominique d'Humieres --- AFAICT this PR has been fixed between revisions r240781 and r240870.
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING CC||lkrupp at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres --- > AFAICT this PR has been fixed between revisions r240781 and r240870. Likely by r240850.
[Bug c++/77896] Object vtable lookups are not hoisted out of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896 --- Comment #1 from Ryan Johnson --- It appears that multiple calls to different virtual functions of the same object are not optimized, either (each performs the same load-load-jump operation).
[Bug c++/77896] Object vtable lookups are not hoisted out of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896 --- Comment #2 from Andrew Pinski --- (In reply to Ryan Johnson from comment #1) > Given that an object's vtable is fixed over its lifetime, Yes but functions including virtual functions can deconstruct the object and then call inplacement new on the same object and change what the type is for that object. So saying the object's vtable is fixed is correct but the lifetime of the object is not fixed.
[Bug c++/77896] Object vtable lookups are not hoisted out of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896 --- Comment #3 from Andrew Pinski --- Basically what I am trying to say is there is a lot of analysis needed to determine if the lifetime of object does not end during a call to a virtual function. > Altering the test case to trigger speculative devirtualization as follows: This is a dup of another bug which says once it has been speculative to a specific function which does not change the lifetime of the object, we can split the loop. That is a dup of bug 67886 really.
[Bug fortran/77900] New: Compile time errors/warning for IO statements appear wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77900
Bug ID: 77900
Summary: Compile time errors/warning for IO statements appear
wrong
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
While looking at something else I stumbled on this with iomesg_1.f90.
$ gfc -std=gnu iomsg_1.f90
iomsg_1.f90:25:121:
sg=ch) ! { dg-warning "STATUS specifier in CLOSE statement.*has invalid value"
}
1
Warning: STATUS specifier in CLOSE statement at (1) has invalid value ‘no_idea’
I think the above should be a compile error no matter what.
The line in questions is:
close(23,status="no_idea", err=500, iomsg=ch) ! { dg-warning "STATUS
specifier in CLOSE statement.*has invalid value" }
It gives the expected error when changed to:
close(23,status="no_idea") ! { dg-warning "STATUS specifier in CLOSE
statement.*has invalid value" }
Compile time errors vs warning should have nothing to do with the absence or
presence of err= or iomsg=
The wrong logic is in fortran/io.c. Probably other statements involved here.
[Bug fortran/77900] Compile time errors/warning for IO statements appear wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77900 --- Comment #1 from Jerry DeLisle --- This goes way back to at least 4.0 so maybe we chose to do this?
