[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- As soon as consider more complicated testcases than just pre/post increment, this is going to be very hard to define and especially implement. The way the warning works right now is that all rvalue uses of a variable are marked as "read" and the warning then warns about variables that don't have the "read" bit set, but have the "used" bit set (i.e. they aren't fully unused). This is especially because the FEs used to fold expressions aggressively very early (and still do, especially the C FE), so not all expressions (even use in sizeof etc. counts) survive long enough where we actually would know what the lhs is corresponding to rhs. Also, we do not warn if there are any side-effects in between the rvalue use of the var and the store to it. So, if we do want to warn about m = m + 1; we still shouldn't warn for m = foo (m) + 1; or m = (n = m) + 1; etc. Handling the pre/post increment by 1 might be easiest, just remember whether the var is not "read" before processing it and reset the "read" bit if so afterwards, but as soon as you run into more complex expressions that is going to be harder and harder.
[Bug fortran/78976] [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 --- Comment #4 from Janne Blomqvist --- Author: jb Date: Wed Jan 4 08:06:54 2017 New Revision: 244048 URL: https://gcc.gnu.org/viewcvs?rev=244048&root=gcc&view=rev Log: PR 78796 Modify testcases due to gfc_trans_string_copy change As r244011 had to be reverted, this change adds back the testcase changes that are needed due to r244003. 2017-01-04 Janne Blomqvist PR fortran/78534 PR fortran/78976 * gfortran.dg/dependency_49.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. * gfortran.dg/transfer_intrinsic_1.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_49.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
[Bug target/78796] TLS fails to link on aarch64 with -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796 --- Comment #10 from Janne Blomqvist --- Author: jb Date: Wed Jan 4 08:06:54 2017 New Revision: 244048 URL: https://gcc.gnu.org/viewcvs?rev=244048&root=gcc&view=rev Log: PR 78796 Modify testcases due to gfc_trans_string_copy change As r244011 had to be reverted, this change adds back the testcase changes that are needed due to r244003. 2017-01-04 Janne Blomqvist PR fortran/78534 PR fortran/78976 * gfortran.dg/dependency_49.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. * gfortran.dg/transfer_intrinsic_1.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_49.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #17 from Janne Blomqvist --- Author: jb Date: Wed Jan 4 08:06:54 2017 New Revision: 244048 URL: https://gcc.gnu.org/viewcvs?rev=244048&root=gcc&view=rev Log: PR 78796 Modify testcases due to gfc_trans_string_copy change As r244011 had to be reverted, this change adds back the testcase changes that are needed due to r244003. 2017-01-04 Janne Blomqvist PR fortran/78534 PR fortran/78976 * gfortran.dg/dependency_49.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. * gfortran.dg/transfer_intrinsic_1.f90: Change scan-tree-dump-times due to gfc_trans_string_copy change to avoid -Wstringop-overflow. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_49.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
[Bug bootstrap/77569] [7 Regression] self tests fail when not using C locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #8 from Andrew M. --- (In reply to Andrew Pinski from comment #7) > One thing to try is -fno-tree-ter. Stack sizes for -fno-tree-ter: 4.9.4: 272 bytes 5.1-5.4: 288 bytes 6.1-6.3: 560 bytes 7: 560 bytes Performance improves a lot with -fno-tree-ter with 5.x going back to 4.9 levels, and 6.x being somewhere inbetween 4.9 and 6.x without -f-no-tree-ter.
[Bug tree-optimization/78895] [6 Regression] wrong code with -O1 when setting union twice since 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78895 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/59124] [5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[5/6/7 Regression] Wrong|[5/6 Regression] Wrong |warnings "array subscript |warnings "array subscript |is above array bounds" |is above array bounds" --- Comment #45 from Jeffrey A. Law --- AFAICT all the valid tests within this BZ have been fixed on the trunk (and likely in gcc-6 as well). I'm removing the gcc-7 regression marker. Any additional issues with unrolling triggering false positive Wuninitialized warnings be reported as new bugs rather than piled onto this BZ.
[Bug bootstrap/78984] New: [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 Bug ID: 78984 Summary: [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- The following bootstrap procedure, to build x86 (32-bit) executables of GCC on a 64-bit (x86_64-linux-gnu) machine, succeeded with version 4.8.5 and earlier, but fails with versions 4.9.0, 4.9.4, 5.1.0, 6.1.0: version=4.9.0 export CC="gcc -m32" CXX="g++ -m32" LDFLAGS="-m32" ../gcc-$version/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu-inst-gcc/$version --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32 --with-gmp=/arch/x86-linux/gnu-inst-gcc/$version --with-mpfr=/arch/x86-linux/gnu-inst-gcc/$version --with-mpc=/arch/x86-linux/gnu-inst-gcc/$version --with-libelf=/arch/x86-linux/gnu-inst-gcc/$version --with-isl=/arch/x86-linux/gnu-inst-gcc/$version --with-cloog=/arch/x86-linux/gnu-inst-gcc/$version --with-ecj-jar=/downloads/sourceware.org-ecj/ecj-latest.jar make It fails like this: /home/bruno/build/gcc-4.9.0-build/./gcc/xgcc -B/home/bruno/build/gcc-4.9.0-build/./gcc/ -B/arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/bin/ -B/arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/lib/ -isystem /arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/include -isystem /arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/bin/ld: /home/bruno/build/gcc-4.9.0-build/./gcc/liblto_plugin.so: error in plugin cleanup (ignored) /usr/bin/ld: /home/bruno/build/gcc-4.9.0-build/./gcc/liblto_plugin.so: error loading plugin collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.so] error 1 make[3]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] error 2 make[2]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build' make[1]: *** [stage1-bubble] error 2 make[1]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build' make: *** [all] error 2 $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: i686-pc-linux-gnu Configured with: ../gcc-4.9.0/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu-inst-gcc/4.9.0 --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32 --with-gmp=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-mpc=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-libelf=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-isl=/arch/x86-linux/gnu-inst
[Bug tree-optimization/78895] [6 Regression] wrong code with -O1 when setting union twice since 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78895 --- Comment #3 from Richard Biener --- Duplicate of PR71055 (missed backport of a latent bug).
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #1 from bruno at clisp dot org --- The error is similar to the one in bug #63507. The differences are: - I'm not using the '--with-build-config=bootstrap-asan' option. - It fails building the "," directory of libgcc, not the "32" directory of libgcc.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #2 from Andrew Pinski --- Not a bug. You are trying to use a 64bit ld with a ld plugin that is just compiled as 32bit. You need to use the 32bit ld here too. Try using a chroot env rather than the hack you are doing.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- .
[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 09:07:33 2017 New Revision: 244050 URL: https://gcc.gnu.org/viewcvs?rev=244050&root=gcc&view=rev Log: PR tree-optimization/71563 * match.pd: Simplify X << Y into X if Y is known to be 0 or out of range value - has low bits known to be zero. * gcc.dg/tree-ssa/pr71563.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71563.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Hack that still works and I'm using daily is a directory with as, g++, gcc and ld files as follows: as: #!/bin/sh exec /usr/bin/as --32 "$@" g++: #!/bin/sh exec /usr/bin/g++ -m32 "$@" gcc: #!/bin/sh exec /usr/bin/gcc -m32 "$@" ld: #!/bin/sh case "$*" in --version) cat <<\EOF GNU ld version 2.20.52.0.1-10.fc17 20100131 Copyright 2012 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. EOF exit 0;; esac exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@" Then just PATH=/that/dir:$PATH i386 .../configure etc. The ld --version ensures the LTO plugin isn't built in the 32-bit bootstrap. Or you could replace as/ld here with ones from 32-bit build of binutils.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #6 from rguenther at suse dot de --- On Wed, 21 Dec 2016, eggert at gnu dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 > > --- Comment #5 from Paul Eggert --- > Just to clarify: 'main' (in the sample program) is just an example. The > problems developers are seeing when debugging Emacs almost all involve > functions other than 'main'. > > It should be OK for -Og to optimize significantly less than it does now, so > long as -Og remains better than -O0. As things stand, -Og is pretty much > useless for its stated purpose because GDB so often cannot display values of > locals, and I expect this partly explains why -Og is so rarely used in > practice. > > In Emacs, developers use -O0 for debugging, but this can be reeeaally slow > because -O0 does not inline and Emacs relies heavily on small inlined > functions. Although Emacs works around this problem by using macros instead of > functions, such workarounds have obvious drawbacks. For Emacs, it would be > nice > if -Og did not discard locals, but continued to inline. It doesn't really discard them, it just doesn't preserve their values at points they are no longer necessary... I presume you really want not only the inlining to happen but also at least _some_ of the optimization triggered by it as well (for Emacs). This is somewhat in conflict with the desire to preserve every value of every variable at any point in time during their lifetime ... But yes, for the testcase I can see what you expect and the expectation is of course reasonable, it's just somewhat hard to implement. I guess making every user variable set an association barrier might be a start.
[Bug tree-optimization/71563] [6/7 Regression] Regression in GCC-7.0.0's optimizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed on the trunk, not going to backport.
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Ian Lance Taylor --- > If the libstdc++ approach works and is acceptable, it seems to me we should do > the same for libgo. Fine with me: it has the advantage of solving both the libgo.a and libgo.so problems in the same way with a mechanism known to work and not harm other targets. I'll cook up a patch. Rainer
[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 --- Comment #3 from rguenther at suse dot de --- On Mon, 2 Jan 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||rguenth at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek --- > vectorizable_comparison has complicated code to deal with comparisons of > VECTOR_BOOLEAN_P operands, but vectorizable_condition does not have any of > this. > So, IMHO either we duplicate that (or partially move into helper functions), > e.g. the > /* Boolean values may have another representation in vectors > and therefore we prefer bit operations over comparison for > them (which also works for scalar masks). We store opcodes > to use in bitop1 and bitop2. Statement is vectorized as >BITOP2 (rhs1 BITOP1 rhs2) or >rhs1 BITOP2 (BITOP1 rhs2) > depending on bitop1 and bitop2 arity. */ > if (VECTOR_BOOLEAN_TYPE_P (vectype)) > stuff and the bitop1/bitop2 handling later on, or refuse to vectorize > COND_EXPR > if the comparison operands are VECTOR_BOOLEAN_TYPE_P (with the exception of > easy cases where rhs1 is the boolean itself or something easily transformable > into that (boolv != 0, boolv != 1, boolv == 0, boolv == 1) perhaps with > swapping rhs2 and rhs3. Or refuse to vectorize such COND_EXPRs and add > pattern > recognizer that replaces x = boolv1 op boolv2 ? rhs2 : rhs3; with > tmp = boolv1 op boolv2; > x = tmp ? rhs2 : rhs3; > and then vectorizable_comparison should be able to deal with the first stmt > and > vectorizable_condition with the latter. > Richard, any preferences? I believe the bool patterns were supposed to handle this case but at the time I fixed its time/size complexity issues we IIRC ended up effectively disabling them for x86 with no fallout -- this may be the fallout. So I'd figure out why the bool patterns stuff does not trigger here first. IIRC the "effective disabling" was due to some target optab/hook check that always returns true on x86 (and thus possibly needs to be changed to check for a bad "mix" of VECTOR_BOOLEAN kinds)
[Bug fortran/78976] [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and gfortran.dg/transfer_intrinsic_1.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/65206] Vectorized version of loop is removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206 --- Comment #9 from rguenther at suse dot de --- On Mon, 2 Jan 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206 > > --- Comment #8 from Jakub Jelinek --- > Adding some flag on the MASK_STORE or MASK_LOAD is not hard, it can be in > another argument, or some GF_*, whatever. But I don't understand here what is > the difference between originally pointer based and array based access. > Doesn't for non-masked stores or loads forwprop propagate array accesses into > pointer stores/loads anyway? The issue is that dependence analysis can't handle mixed pointer / array accesses (it would need to treat the array access as pointer-based, thus comment #5 which talks about always providing both sets of DR->indices variants). Yes, forwprop propagates the loads/stores but it correctly conservatively handles propagating p = &a[i] to *p (it doesn't propagate) or p = &a[1] to *p (it creates MEM[a, 4], not an array access). The "hack" forwards it as array access to make dependence analysis happy. The real fix is comment #5 computing (maybe lazily) a DR->indices variant for array accesses using get_inner_reference on the full reference and analyzing it as MEM[base + offset, bitoff], thus if it were *&ref. That makes more refs "compatible" for initialize_data_dependence_relation. Implementation-wise it's not that easy to implement this though :/
[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 --- Comment #4 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #3) > I believe the bool patterns were supposed to handle this case but > at the time I fixed its time/size complexity issues we IIRC ended up > effectively disabling them for x86 with no fallout -- this may be > the fallout. So I'd figure out why the bool patterns stuff does not > trigger here first. IIRC the "effective disabling" was due to > some target optab/hook check that always returns true on x86 > (and thus possibly needs to be changed to check for a bad "mix" of > VECTOR_BOOLEAN kinds) The bool patterns generally do something different, attempt to translate bool operations into integral operations of some reasonable size. That is not what is needed here. Anyway, before we talk about vect patterns, the first question is if vectorizable_condition should handle this by itself (increase its complexity), or fail. If the latter, then after it fails there is another question if we want to do something about it in tree-vect-patterns.c or not.
[Bug target/78974] STM32L4 CPU read burst access equal to or more than 9 registers to FMC returns corrupted data starting from the 9th read word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78974 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Richard Earnshaw --- Sorry, there's no such option. Nor is it practical to add one for one problematic board.
[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |7.0 --- Comment #6 from Richard Biener --- For reference: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00438.html Summary: the testcases are optimized better now (redundant tests removed) which confuses niter analysis
[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 --- Comment #5 from rguenther at suse dot de --- On Wed, 4 Jan 2017, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 > > --- Comment #4 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #3) > > I believe the bool patterns were supposed to handle this case but > > at the time I fixed its time/size complexity issues we IIRC ended up > > effectively disabling them for x86 with no fallout -- this may be > > the fallout. So I'd figure out why the bool patterns stuff does not > > trigger here first. IIRC the "effective disabling" was due to > > some target optab/hook check that always returns true on x86 > > (and thus possibly needs to be changed to check for a bad "mix" of > > VECTOR_BOOLEAN kinds) > > The bool patterns generally do something different, attempt to translate bool > operations into integral operations of some reasonable size. That is not what > is needed here. Anyway, before we talk about vect patterns, the first > question > is if vectorizable_condition should handle this by itself (increase its > complexity), or fail. If the latter, then after it fails there is another > question if we want to do something about it in tree-vect-patterns.c or not. Yes, the vectorizer should handle it (and I always prefer handling things in vectorizable_* rather than adding complexity to patterns).
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Wed Jan 4 10:54:59 2017 New Revision: 244051 URL: https://gcc.gnu.org/viewcvs?rev=244051&root=gcc&view=rev Log: Support exception propagation without lock-free atomic int 2017-01-04 Pauli Nieminen Jonathan Wakely PR libstdc++/64735 * acinclude.m4 (GLIBCXX_CHECK_EXCEPTION_PTR_SYMVER): Define. * config.h.in: Regenerate. * config/abi/pre/gnu.ver [HAVE_EXCEPTION_PTR_SINCE_GCC46] (GLIBCXX_3.4.15, GLIBCXX_3.4.21, CXXABI_1.3.3, CXXABI_1.3.5): Make exports for exception_ptr, nested_exception, and future conditional. [HAVE_EXCEPTION_PTR_SINCE_GCC46] (GLIBCXX_3.4.23, CXXABI_1.3.11): Add exports for exception_ptr, nested_exception, and future conditional. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_EXCEPTION_PTR_SYMVER. * include/std/future: Remove check for ATOMIC_INT_LOCK_FREE * libsupc++/eh_atomics.h: New file for internal use only. (__eh_atomic_inc, __eh_atomic_dec): New. * libsupc++/eh_ptr.cc (exception_ptr::_M_addref) (exception_ptr::_M_release) (__gxx_dependent_exception_cleanup) (rethrow_exception): Use eh_atomics.h reference counting helpers. * libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise. * libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise. * libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/exception_ptr.h: Likewise. * libsupc++/guard.cc: Include header for ATOMIC_INT_LOCK_FREE macro. * libsupc++/nested_exception.cc: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/nested_exception.h: Likewise. * src/c++11/future.cc: Likewise. * testsuite/18_support/exception_ptr/*: Remove atomic builtins checks. * testsuite/18_support/nested_exception/*: Likewise. * testsuite/30_threads/async/*: Likewise. * testsuite/30_threads/future/*: Likewise. * testsuite/30_threads/headers/future/types_std_c++0x.cc: Likewise. * testsuite/30_threads/packaged_task/*: Likewise. * testsuite/30_threads/promise/*: Likewise. * testsuite/30_threads/shared_future/*: Likewise. Added: trunk/libstdc++-v3/libsupc++/eh_atomics.h Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/libsupc++/eh_ptr.cc trunk/libstdc++-v3/libsupc++/eh_throw.cc trunk/libstdc++-v3/libsupc++/eh_tm.cc trunk/libstdc++-v3/libsupc++/exception trunk/libstdc++-v3/libsupc++/exception_ptr.h trunk/libstdc++-v3/libsupc++/guard.cc trunk/libstdc++-v3/libsupc++/nested_exception.cc trunk/libstdc++-v3/libsupc++/nested_exception.h trunk/libstdc++-v3/src/c++11/future.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/60612-unexpected.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/62258.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/current_exception.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/lifespan.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/make_exception_ptr.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/make_exception_ptr_2.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/move.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/requirements.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/requirements_neg.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/rethrow_exception.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/51438.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/62154.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/68139.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/cons.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/nested_ptr.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/rethrow_if_nested.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/rethrow_nested.cc trunk/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc trunk/libstdc++-v3/testsuite/30_threads/async/42819.cc trunk/libstdc++-v3/testsuite/30_threads/async/49668.cc trunk/libstdc++-v3/testsuite/30_threads/async/54297.cc trunk/libstdc++-v3/testsuite/30_threads/async/any.cc trunk/libstdc++-v3/testsuite/30_threads/async/async.cc trunk/libstdc++-v3/testsuite/30_threads/async/except.cc trunk/libstdc++-v3
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #12 from Jonathan Wakely --- This is fixed on trunk now, without pessimizing targets that already support exception propagation.
[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Jonathan Wakely --- > The Solaris header would be more correct if it did: > > #if __STDC_VERSION__ < 201112L && __cplusplus < 201402L > extern char *gets(char *) __ATTR_DEPRECATED; > #endif > > That would suppress the declaration for C++14, as the C++14 standard requires. > > You could use fixincludes to do that. I'm not sure how important it is, or if > we should just XFAIL the test. Indeed. I'll prepare a fixincludes patch and bring it up with Oracle, though I don't know what their plans are for C++14 support. Thanks. Rainer
[Bug tree-optimization/71055] [7 Regression] FAIL: gcc.dg/torture/pr53663-1.c -Os execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71055 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Jan 4 12:35:32 2017 New Revision: 244053 URL: https://gcc.gnu.org/viewcvs?rev=244053&root=gcc&view=rev Log: 2017-01-04 Richard Biener Backport from mainline 2016-05-11 Richard Biener PR tree-optimization/71055 * tree-ssa-sccvn.c (vn_reference_lookup_3): When native-interpreting sth with precision not equal to access size verify we don't chop off bits. * gcc.dg/torture/pr71055.c: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr71055.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/78895] [6 Regression] wrong code with -O1 when setting union twice since 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78895 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #6 from Hannes Hauswedell --- (In reply to Martin Sebor from comment #5) > (In reply to Hannes Hauswedell from comment #3) > > > > Great, let me know if it's merged, then I will try a newer snapshot! > > The patch has been committed (r244037). Please give it a try and let us > know how it goes. Thanks! I have checked out master via git and verified that it includes the fix. I then tried to tie this into the FreeBSD-port (to make use of the local patches and build flags), but unfortunately it still doesn't build. I normally don't build gcc myself so it would likely take me considerable time to track these build problems and fix them. The next weekly snapshot should be built on 20170108 and then land in the FreeBSD-ports very soon after. Can we wait for this, or are we in a hurry -- for when is the GCC7 release scheduled?
[Bug bootstrap/78880] [7 Regression] Revision 243196 breaks bootstrap on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78880 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |5.5
[Bug c++/78908] [6/7 Regression] lto1: internal compiler error: in lto_read_decls, at lto/lto.c:1814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908 Richard Biener changed: What|Removed |Added Keywords||lto Priority|P3 |P2 Component|lto |c++ Target Milestone|--- |6.4
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #7 from Jakub Jelinek --- (In reply to Hannes Hauswedell from comment #6) > (In reply to Martin Sebor from comment #5) > > (In reply to Hannes Hauswedell from comment #3) > > > > > > Great, let me know if it's merged, then I will try a newer snapshot! > > > > The patch has been committed (r244037). Please give it a try and let us > > know how it goes. > > Thanks! I have checked out master via git and verified that it includes the > fix. I then tried to tie this into the FreeBSD-port (to make use of the > local patches and build flags), but unfortunately it still doesn't build. > I normally don't build gcc myself so it would likely take me considerable > time to track these build problems and fix them. The next weekly snapshot > should be built on 20170108 and then land in the FreeBSD-ports very soon > after. > Can we wait for this, or are we in a hurry -- for when is the GCC7 release > scheduled? Could you in the mean time attach the preprocessed source + options (and confirm whether it is appendNumber in the preprocessed source or something else)? Then we can easily check if the patch actually changed anything or not.
[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 Richard Biener changed: What|Removed |Added Keywords||ra Priority|P3 |P2 Target Milestone|--- |5.5
[Bug c++/78589] g++ prints instead of a function name when warning in an OpenMP outlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Let me close this because the problematic code I was referring to was in the c++ front-end. If we want to track that we output internal and not-very-meaninful-for-the-user names when reporting warnings in OMP outlined functions, it will be much clearer if we file a new PR.
[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237 Richard Biener changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #7 from Richard Biener --- *** Bug 78961 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/78961] [7 Regression] FAIL: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times optimized "&a" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78961 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |7.0 --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 71237 ***
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #8 from Hannes Hauswedell --- (In reply to Jakub Jelinek from comment #7) > (In reply to Hannes Hauswedell from comment #6) > > (In reply to Martin Sebor from comment #5) > > > (In reply to Hannes Hauswedell from comment #3) > > > > > > > > Great, let me know if it's merged, then I will try a newer snapshot! > > > > > > The patch has been committed (r244037). Please give it a try and let us > > > know how it goes. > > > > Thanks! I have checked out master via git and verified that it includes the > > fix. I then tried to tie this into the FreeBSD-port (to make use of the > > local patches and build flags), but unfortunately it still doesn't build. > > I normally don't build gcc myself so it would likely take me considerable > > time to track these build problems and fix them. The next weekly snapshot > > should be built on 20170108 and then land in the FreeBSD-ports very soon > > after. > > Can we wait for this, or are we in a hurry -- for when is the GCC7 release > > scheduled? > > Could you in the mean time attach the preprocessed source + options (and > confirm whether it is appendNumber in the preprocessed source or something > else)? > Then we can easily check if the patch actually changed anything or not. This is the command line used for building test_random: cd /home/mi/h4nn3s/devel/seqan_local-build/release/tests/random && /usr/local/libexec/ccache/g++7 -DSEQAN_DISABLE_VERSION_CHECK -DSEQAN_ENABLE_TESTING=1 -DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1 -DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99=1 -D_LARGEFILE_SOURCE -I/home/mi/h4nn3s/devel/seqan_local/include -fdiagnostics-color -W -Wall -pedantic -fstrict-aliasing -Wstrict-aliasing -fopenmp -O3 -DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o CMakeFiles/test_random.dir/test_random.cpp.o -c /home/mi/h4nn3s/devel/seqan_local/tests/random/test_random.cpp Linking CXX executable ../../bin/test_random cd /home/mi/h4nn3s/devel/seqan_local-build/release/tests/random && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/test_random.dir/link.txt --verbose=1 /usr/local/libexec/ccache/g++7 -fdiagnostics-color -W -Wall -pedantic -fstrict-aliasing -Wstrict-aliasing -fopenmp -O3 CMakeFiles/test_random.dir/test_random.cpp.o -o ../../bin/test_random -lpthread -lexecinfo -lelf -lz -lbz2 I have attached gzipped .ii for both a build with "-O3" and with "-O3 -fno-printf-return-value". Is that what you require or by which other means would I get the preprocessed source? Thanks!
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #12 from Hannes Hauswedell --- Created attachment 40451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40451&action=edit intermediate for O3
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #13 from Hannes Hauswedell --- Created attachment 40452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40452&action=edit intermediate for O3 -fno-printf-return-value
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #14 from Hannes Hauswedell --- sorry, please ignore the attachments, bugzilla dropped me in a different issue than planned.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #9 from Hannes Hauswedell --- Created attachment 40453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40453&action=edit intermediate for O3
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #10 from Hannes Hauswedell --- Created attachment 40454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40454&action=edit intermediate for O3 -fno-printf-return-value
[Bug bootstrap/78985] New: [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 Bug ID: 78985 Summary: [7 Regression] profiledbootstrap failure by -Wuninitialized Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: build, diagnostic Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Target: s390x-*-* profiledbootstrap fails for me on s390x-linux for quite some time now (also on aarch64-linux in a similar way, but re-checking with current trunk didn't finish/fail yet). lab_over is obviously not uninitialized (but eventually jump threading gets in the way - I did not analyze this yet as I lack a way to extract a testcase at the moment). ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp --disable-libvtv --disable-libmpx --disable-libcc1 --enable-plugin --with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7 --disable-multilib --without-system-libunwind --with-tune=zEC12 --with-arch=z196 --with-long-double-128 --enable-decimal-float --build=s390x-suse-linux --host=s390x-suse-linux ... [ 4042s] ../../gcc/config/s390/s390.c: In function 'tree_node* s390_gimplify_va_ arg(tree, tree, gimple**, gimple**)': [ 4042s] ../../gcc/config/s390/s390.c:12296:52: error: 'lab_over' may be used un initialized in this function [-Werror=maybe-uninitialized] [ 4042s] gimple_seq_add_stmt (pre_p, gimple_build_label (lab_over)); [ 4042s] ~~~^~ ... [ 4044s] cc1plus: all warnings being treated as errors [ 4044s] make[3]: *** [Makefile:2221: s390.o] Error 1 [ 4044s] make[3]: *** Waiting for unfinished jobs [ 4045s] rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gfortran.pod gcc.pod gccgo.pod gcov-tool.pod [ 4045s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/gcc-7.0.0-r244052/obj-s390x-suse-linux/gcc' [ 4045s] make[2]: *** [Makefile:4725: all-stagefeedback-gcc] Error 2 [ 4045s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/gcc-7.0.0-r244052/obj-s390x-suse-linux'
[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug pch/78970] GCC crashes if input file is dash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970 --- Comment #2 from Martin Liška --- Ok, basic problem is in _cpp_save_file_entries, where we calculate md5sum of all inputs files. Providing '-' will cause to have input file as fd == 0 and ff = fdopen (f->fd, "rb"); md5_stream (ff, result->entries[count].sum); fclose (ff); will fail as fdopen fails for 0 fd. Thoughts? Another corner case is using --save-temps that will also confuse command line: cc1: error: unrecognized command line option ‘-.i’ ./cc1 -fpreprocessed -.i -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o -.s --output-pch= pes.pch
[Bug pch/78970] GCC crashes if input file is dash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970 --- Comment #3 from Martin Liška --- Created attachment 40455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40455&action=edit Untested patch
[Bug pch/78970] GCC crashes if input file is dash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970 --- Comment #4 from Martin Liška --- Created attachment 40456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40456&action=edit Untested patch
[Bug sanitizer/57507] gcc 4.8: thread sanitizer: std::thread false(?) positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jonathan Wakely --- This should no longer be a problem, because std::thread doesn't use std::shared_ptr these days.
[Bug c++/66735] [C++14] lambda init-capture fails for const references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66735 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nathan Sidwell --- Fixed trunk r244056.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 66735, which changed state. Bug 66735 Summary: [C++14] lambda init-capture fails for const references https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66735 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/66735] [C++14] lambda init-capture fails for const references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66735 --- Comment #6 from Nathan Sidwell --- Author: nathan Date: Wed Jan 4 15:23:40 2017 New Revision: 244056 URL: https://gcc.gnu.org/viewcvs?rev=244056&root=gcc&view=rev Log: cp/ PR c++/66735 * cp-tree.h (DECLTYPE_FOR_REF_CAPTURE): New. (lambda_capture_field_type): Update prototype. * lambda.c (lambda_capture_field_type): Add is_reference parm. Add referenceness here. (add_capture): Adjust lambda_capture_field_type call, refactor error checking. * pt.c (tsubst): Adjust lambda_capture_field_type call. testsuite/ PR c++/66735 * g++.dg/cpp1y/pr66735.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr66735.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/lambda.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/78932] [ARM] -O2 generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78932
--- Comment #2 from xqr4n54r1 at hotmail dot com ---
Created attachment 40457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40457&action=edit
memcpy instead of get_unaligned_be
* I wrote memcpy instead of get_unaligned_be{16|32} and I saw that solved the
problem. I think that the basic block reordering does not work correctly.
Attachment has following :
- filter_O2.{c|s} : Indicates that the problem has occurred.
- filter_memcpy.{c|s} : Indicates solution that compile memcpy instead
get_unaligned_be{16|32} I mentioned above.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #15 from Jonathan Wakely --- Author: redi Date: Wed Jan 4 15:41:19 2017 New Revision: 244057 URL: https://gcc.gnu.org/viewcvs?rev=244057&root=gcc&view=rev Log: PR78968 add configure check for __cxa_thread_atexit in libc PR libstdc++/78968 * config.h.in: Regenerate. * configure: Likewise. * configure.ac: Check for __cxa_thread_atexit. * libsupc++/atexit_thread.cc [_GLIBCXX_HAVE___CXA_THREAD_ATEXIT]: Don't define __cxa_thread_atexit if libc provides it. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/libsupc++/atexit_thread.cc
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #16 from Jonathan Wakely --- Trunk no longer defines __cxa_thread_atexit if it's found in libc. We might want to backport this to the gcc-5-branch and gcc-6-branch. I will try to test this in a FreeBSD 11 VM some time soon.
[Bug c++/78986] New: template inner classes are not affected by visibility specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
Bug ID: 78986
Summary: template inner classes are not affected by visibility
specifiers
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michele.caini at gmail dot com
Target Milestone: ---
Consider the following code:
class B { struct T {}; };
class D: B { template struct U: T {}; };
int main() {}
GCC accepts it, but it shouldn't for T is private in B and U cannot inherit
from it in D.
GCC correctly rejects the code below:
class B { struct T {}; };
class D: B { struct U: T {}; };
int main() {}
[Bug c/78987] New: Wrong location of a binary expression for -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78987
Bug ID: 78987
Summary: Wrong location of a binary expression for -Waddress
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from 4.8, where location description was added.
$ cat /tmp/wrong-conditions.c
void foo() {}
void bar() {}
void baz() {}
int main2(int argc, int argc2)
{
if (foo && bar && baz)
return 1;
return 0;
}
$ ./xgcc -B. /tmp/wrong-conditions.c -c -Wall
/tmp/wrong-conditions.c: In function ‘main2’:
/tmp/wrong-conditions.c:7:7: warning: the address of ‘foo’ will always evaluate
as ‘true’ [-Waddress]
if (foo && bar && baz)
^~~
/tmp/wrong-conditions.c:7:11: warning: the address of ‘bar’ will always
evaluate as ‘true’ [-Waddress]
if (foo && bar && baz)
^~
/tmp/wrong-conditions.c:7:18: warning: the address of ‘baz’ will always
evaluate as ‘true’ [-Waddress]
if (foo && bar && baz)
^~
Location of the first is correct, last 2 are wrong.
[Bug c++/78988] New: Wrong location of a binary expression for -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78988
Bug ID: 78988
Summary: Wrong location of a binary expression for -Waddress
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
This is C++ equivalent of PR78987
Starting from 4.8, where location description was added.
$ cat /tmp/wrong-conditions.c
void foo() {}
void bar() {}
void baz() {}
int main2(int argc, int argc2)
{
if (foo && bar && baz)
return 1;
return 0;
}
$ ./xg++ -B. /tmp/wrong-conditions.c -c -Wall
/tmp/wrong-conditions.c: In function ‘int main2(int, int)’:
/tmp/wrong-conditions.c:7:14: warning: the address of ‘void foo()’ will never
be NULL [-Waddress]
if (foo && bar && baz)
^~~
/tmp/wrong-conditions.c:7:14: warning: the address of ‘void bar()’ will never
be NULL [-Waddress]
/tmp/wrong-conditions.c:7:21: warning: the address of ‘void baz()’ will never
be NULL [-Waddress]
if (foo && bar && baz)
^~~
Where location of 'foo' is wrong and location for 'bar' is missing.
[Bug c/78987] Wrong location of a binary expression for -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78987 --- Comment #1 from Martin Liška --- C++ related issue: PR78988.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #5 from bruno at clisp dot org --- Thanks Jakub. The ld --version and "-m elf_i386 -L /usr/lib/" trick solves it! (I was already using the "as --32" trick.) Another way is to define a simpler ld32 script == ld32 = #!/bin/sh exec ld -m elf_i386 -L /usr/lib/ "$@" = specify this script through the --with-ld option, AND use the --disable-lto option.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #9) > Sounds good. I can give it a try in the following days or weeks and see if I > can get a C code with such large switch statements compiled. Building a patched version of gcc-7 now. Then I'll try whether the problem vanishes when using the -mlong-jump-table-offsets option.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #6 from Andreas Schwab --- Note that if you use --with-ld, -B no longer works.
[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899 Jakub Jelinek changed: What|Removed |Added Attachment #40403|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek --- Created attachment 40458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40458&action=edit gcc7-pr78899.patch WIP updated patch, but there is still some bug in the vops after slpeel_tree_duplicate_loop_to_edge_cfg.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
--- Comment #11 from Martin Sebor ---
Thanks. The preprocessed file is what we need. I see two snprintf calls being
optimized in the SEQAN_TEST_test_random_beta_write function:
On line 52569 substituting 3 for snprintf return value (output constant).
On line 52569 snprintf in-bounds return value in range [3, 8].
The line numbers correspond to the preprocessed file with #line directives and
empty lines removed and point to the template below:
inline typename Size::Type
appendNumber(TTarget & target, double source);
Of the two lines, the first one is the one that would affect the subsequent
write call. The source argument is 0.5 which is represented exactly in binary
and which snprintf formats as the three bytes "0.5" and that's also what GCC
assumes. The second line corresponds to the argument value of 0.3. 0.3 is not
represented exactly and how it's formatted depends on the rounding mode. When
rounded down, it's formatted as "0.29" (8 bytes), when up or to nearest
(the typical default) it's "0.3" (3 bytes). So GCC determines the return value
is [3, 8]. The range is not used in the subsequent write call but it could be
used if the return value of the function were used elsewhere. I checked
appendNumber callers and none uses it.
From the assertion in comment #0:
Assertion failed : CharString("~Beta(0.5,0.3)") == os.str() was: ~Beta(0.5,0.3)
!= ~Beta(0.5,0.3
[NON-XML-CHAR-0x8]
)
it looks as though the return value with your version of GCC is greater than 3
and the function ends up writing junk after the "0.3". You can see what GCC
thinks the return value is by compiling the file with
-fdump-tree-printf-return-value and looking in the output file (named something
like test_random.c.173t.printf-return-value2) for lines that start with the
text "On line " You should see the same two lines as above (with different
line numbers). When you look at the snprintf calls in the function body below
you should see something like this:
snprintf (&buffer, 32, "%g", 5.0e-1);
_204 = 3;
...
_355 = snprintf (&buffer, 32, "%g",
2.99988897769753748434595763683319091796875e-1);
len_356 = (size_t) _355;
showing that the first return value is optimized to the constant 3 and the
second return value is no optimized (it comes from the function call). If the
return value from the second call is optimized into a constant that would point
to a bug in GCC. If not, it would point to a bug in snprintf.
If this is too complicated please attach the output file produced by the
-fdump-tree-printf-return-value function to this report.
[Bug c/78989] New: Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989
Bug ID: 78989
Summary: Missing -Waddress warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Following test-case does not report warning:
$ cat /tmp/gimplify.ii
int
asan_poison_variables ()
{
return (asan_poison_variables &&
# 6 "gimplify.cpp" 3 4
__null
);
}
./xgcc -B. /tmp/gimplify.ii -Wall -c
[nothing]
While:
cat /tmp/gimplify.ii
int
asan_poison_variables ()
{
return (asan_poison_variables &&
__null
);
}
$ ./xgcc -B. /tmp/gimplify.ii -Wall -c
/tmp/gimplify.ii: In function ‘int asan_poison_variables()’:
/tmp/gimplify.ii:5:31: warning: the address of ‘int asan_poison_variables()’
will never be NULL [-Waddress]
__null
^~
It's somehow related to the location if *.ii file, but I don't know how.
Thanks
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/77284] [5/6/7 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Wed Jan 4 17:47:04 2017 New Revision: 244062 URL: https://gcc.gnu.org/viewcvs?rev=244062&root=gcc&view=rev Log: PR c++/77545 PR c++/77284 * constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT. * g++.dg/cpp0x/range-for32.C: New test. * g++.dg/cpp0x/range-for33.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/range-for32.C trunk/gcc/testsuite/g++.dg/cpp0x/range-for33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Jan 4 17:47:04 2017 New Revision: 244062 URL: https://gcc.gnu.org/viewcvs?rev=244062&root=gcc&view=rev Log: PR c++/77545 PR c++/77284 * constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT. * g++.dg/cpp0x/range-for32.C: New test. * g++.dg/cpp0x/range-for33.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/range-for32.C trunk/gcc/testsuite/g++.dg/cpp0x/range-for33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/77284] [5/6 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 Marek Polacek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE on |[5/6 Regression] ICE on |valid C++11 code using |valid C++11 code using |initializer list: in|initializer list: in |potential_constant_expressi |potential_constant_expressi |on_1, at|on_1, at |cp/constexpr.c:5480 |cp/constexpr.c:5480 --- Comment #6 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #7 from bruno at clisp dot org --- (In reply to Andreas Schwab from comment #6) > Note that if you use --with-ld, -B no longer works. Thanks Andreas. In fact, I've never used the -B option (except during gcc bootstrap). Some 20 years ago I used the options -V and -b, but over time I found it more reliable to not share anything between installed GCC binaries of different versions or targets, i.e. use a different --prefix each time.
[Bug c/78989] Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like -Wsystem-headers in action again. NULL is a macro defined in a system header...
[Bug c/78989] Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 Jakub Jelinek changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Dunno if we don't want to special case macros in system headers that expand to a single token or what other heuristics to use.
[Bug fortran/78990] New: ICE when assigning polymorphic array function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78990 Bug ID: 78990 Summary: ICE when assigning polymorphic array function result Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cmacmackin at gmail dot com Target Milestone: --- Created attachment 40459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40459&action=edit Minimal reproducer When a function returns a polymorphic array which is to be assigned to a local array (via defined assignment), gfortran experiences a segfault. I've attached a minimal example, which produces an ICE in gfortran 6.2.0 and 5.4.1 (both from the Ubuntu 16.04 repos, the former from the ubuntu-toolchain-r/test PPA). The error message is as follows: minimal.f90:36:0: v3 = return_t1(v1) internal compiler error: Segmentation fault 0xa71b9f crash_signal ../../src/gcc/toplev.c:333 0x696d84 gfc_conv_array_stride(tree_node*, int) ../../src/gcc/fortran/trans-array.c:2776 0x696d84 gfc_trans_preloop_setup ../../src/gcc/fortran/trans-array.c:3528 0x69793a gfc_start_scalarized_body(gfc_loopinfo*, stmtblock_t*) ../../src/gcc/fortran/trans-array.c:3586 0x6ed5cf gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../src/gcc/fortran/trans-stmt.c:476 0x68ef73 trans_code ../../src/gcc/fortran/trans.c:1768 0x6b25dc gfc_generate_function_code(gfc_namespace*) ../../src/gcc/fortran/trans-decl.c:6167 0x64a800 translate_all_program_units ../../src/gcc/fortran/parse.c:5915 0x64a800 gfc_parse_file() ../../src/gcc/fortran/parse.c:6121 0x68c1c2 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:201 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Note that I'm not 100% certain that this is legal code (I don't have access to any other compilers to check).
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- I haven't thought through the implementation challenges but defining the extended -Wunused-but-set-variabl rule that's being suggested here seems straightforward: every write to an object must be followed by another access to it (either read or write). If not, it's diagnosed. This seems analogous to the -Wuninitialized checker/rule that might be stated as: the first read of an object must be preceded by a write to it.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #8 from Andreas Schwab --- The binutils testsuite depends on it.
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 --- Comment #7 from Jakub Jelinek --- (In reply to Martin Sebor from comment #6) > I haven't thought through the implementation challenges but defining the > extended -Wunused-but-set-variabl rule that's being suggested here seems > straightforward: every write to an object must be followed by another access > to it (either read or write). If not, it's diagnosed. That is not straightforward at all. The FE doesn't have IL on which it can analyze write accesses being followed by something (no cfg, no SSA form), and in the middle end it is way too late for such a warning (because as soon as you optimize away something, you could optimize away those reads and warning just because the optimizers managed to optimize away some use are not really helpful).
[Bug tree-optimization/67955] tree-dse does not use pointer info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67955 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Wed Jan 4 19:22:44 2017 New Revision: 244067 URL: https://gcc.gnu.org/viewcvs?rev=244067&root=gcc&view=rev Log: PR tree-optimizatin/67955 * tree-ssa-alias.c (same_addr_size_stores_p): Check offsets first. Allow any SSA_VAR_P as the base objects. Use integer_zerop. Verify the points-to solution does not include pt_null. Use DECL_PT_UID unconditionally. PR tree-optimization/67955 * gcc.dg/tree-ssa/ssa-dse-28.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-28.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug c/78989] Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 --- Comment #3 from David Malcolm --- Looking at the PRs you filed about the locations (PR78987 and PR78988), perhaps the best approach here is for the location of the warning to be either this: return (asan_poison_variables && ~~^~ # 6 "gimplify.cpp" 3 4 __null ~~ ); or this: return (asan_poison_variables && # 6 "gimplify.cpp" 3 4 __null ^~ ); i.e. for the location to be a range starting at the LHS start, finishing at the RHS finish, with the caret at either the && or the RHS... ...and then for in_system_header_at to only reject the warning if *all* of the range of the location is fully within a system header, rather than just partially within a header?
[Bug c/78989] Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 --- Comment #4 from David Malcolm --- ...or to use a rich location to send two locations for the warning, giving: return (asan_poison_variables && ^~ # 6 "gimplify.cpp" 3 4 __null ~~ ); and for the logic that uses diagnostic_report_warnings_p to check all locations in the rich location, requiring all to be within a system header for the warning to be rejected.
[Bug target/78056] [7 Regression] build failure on Power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056 --- Comment #20 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Jan 4 20:03:00 2017 New Revision: 244068 URL: https://gcc.gnu.org/viewcvs?rev=244068&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2017-01-04 Kelvin Nilsen PR target/78056 * gcc.target/powerpc/pr78056-1.c: New test. * gcc.target/powerpc/pr78056-2.c: New test. * gcc.target/powerpc/pr78056-3.c: New test. * gcc.target/powerpc/pr78056-4.c: New test. * gcc.target/powerpc/pr78056-5.c: New test. * gcc.target/powerpc/pr78056-6.c: New test. * gcc.target/powerpc/pr78056-7.c: New test. * gcc.target/powerpc/pr78056-8.c: New test. * lib/target-supports.exp (check_effective_target_powerpc_popcntb_ok): New procedure to test whether the effective target supports the popcntb instruction. gcc/ChangeLog: 2017-01-04 Kelvin Nilsen PR target/78056 * doc/sourcebuild.texi (PowerPC-specific attributes): Add documentation of the powerpc_popcntb_ok attribute. * config/rs6000/rs6000.c (rs6000_option_override_internal): Add code to issue warning messages if a requested CPU configuration is not supported by the binary (assembler and loader) toolchain. (spe_init_builtins): Add two assertions to prevent ICE if attempt is made to define a built-in function that has been disabled. (paired_init_builtins): Add assertion to prevent ICE if attempt is made to define a built-in function that has been disabled. (altivec_init_builtins): Add comment explaining why definition of the DST built-in functions is not preceded by an assertion check. Add assertions to prevent ICE if attempts are made to define an altivec predicate or an abs* built-in function that has been disabled. (htm_init_builtins): Add comment explaining why definition of the htm built-in functions is not preceded by an assertion check. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr78056-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-3.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-4.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-5.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-6.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-7.c trunk/gcc/testsuite/gcc.target/powerpc/pr78056-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900 --- Comment #3 from Michael Meissner --- Fixed in trunk in subversion id 244044. I will hold the bug open until it is checked into the GCC 6 branch.
[Bug target/78953] Errors in compiling Spec 2006 for power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78953 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Meissner --- Fixed in subversion id 244044.
[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 20:05:14 2017 New Revision: 244070 URL: https://gcc.gnu.org/viewcvs?rev=244070&root=gcc&view=rev Log: PR c++/71182 * parser.c (cp_lexer_previous_token): Use vec_safe_address in the assertion, as lexer->buffer may be NULL. * g++.dg/cpp0x/pr71182.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr71182.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/71182] [6 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] parser.c |[6 Regression] parser.c |cp_lexer_previous_token |cp_lexer_previous_token |sanitizer detects member|sanitizer detects member |call on null pointer|call on null pointer --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug driver/78957] ICE: SIGSEGV with -fno-sso-struct=web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78957 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 20:25:13 2017 New Revision: 244072 URL: https://gcc.gnu.org/viewcvs?rev=244072&root=gcc&view=rev Log: PR driver/78957 * c.opt (fsso-struct=): Add RejectNegative. * gcc.dg/pr78957.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78957.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/testsuite/ChangeLog
[Bug driver/78957] ICE: SIGSEGV with -fno-sso-struct=web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78957 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug libstdc++/78991] New: std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991
Bug ID: 78991
Summary: std::sort and std::unique can not use std::function
with clang++ -std=c++14
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daiw at gmx dot net
Target Milestone: ---
The following two minimal examples both compile with
clang++ -std=c++11 main.cpp
but do not with
clang++ -std=c++14 main.cpp
// example 1
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function cmp = [](int x, int y)
{ return x < y; };
std::sort(std::begin(xs), std::end(xs), cmp);
}
// example 2
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function p = [](int x, int y)
{ return x == y; };
std::unique(std::begin(xs), std::end(xs), p);
}
The error message looks like this:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/algorithm:61:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:71:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/predefined_ops.h:123:31:
error: indirection requires pointer operand ('int' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }
The used version is the default one from the package manager in Ubuntu 16.04:
clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 --- Comment #10 from Pat Haugen --- (In reply to Jakub Jelinek from comment #9) > Any progress on this? Besides waiting for pr77536 to be fixed, I'm not sure what specifically can be done on this issue to fix the problem. I personally have not done anything wrt to trying to fix the vectorizer frequencies since I'm unfamiliar with the middle-end.
[Bug sanitizer/78992] New: Incorrect sigaction definition on 32-bit sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78992 Bug ID: 78992 Summary: Incorrect sigaction definition on 32-bit sparc Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jrtc27 at jrtc27 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 40460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40460&action=edit Patch forwarded upstream The attached patch is needed to fix the sanitizer build on 32-bit sparc. Forwarded upstream to https://reviews.llvm.org/D28309.
[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 21:30:35 2017 New Revision: 244074 URL: https://gcc.gnu.org/viewcvs?rev=244074&root=gcc&view=rev Log: PR c++/78693 * parser.c (cp_parser_simple_declaration): Only complain about inconsistent auto deduction if auto_result doesn't use auto. * g++.dg/cpp0x/pr78693.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr78693.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/78949] incorrect "unused variable" warning with SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78949 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Jan 4 21:34:27 2017 New Revision: 244075 URL: https://gcc.gnu.org/viewcvs?rev=244075&root=gcc&view=rev Log: PR c++/78949 * typeck.c (cp_build_unary_op): Call mark_rvalue_use on arg if it has vector type. * c-c++-common/Wunused-var-16.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wunused-var-16.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/78993] New: False positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Bug ID: 78993
Summary: False positive from -Wmaybe-uninitialized
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 40461
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40461&action=edit
Reproducer, based on input.c
As noted in the thread at:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00049.html
there's a false positive at -O3 from -Wmaybe-uninitialized in gcc's input.c
I'm attaching a minimized reproducer.
$ g++ (GCC) 7.0.0 20161221 (experimental)
$ g++ -c input.cc -O3 -Wall
input.cc: In function ‘void assert_char_at_range(location_t, int, int, int,
int)’:
input.cc:85:56: warning: ‘*((void*)& actual_range +4)’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
loc = get_location_from_adhoc_loc (line_table, loc);
^
input.cc:96:16: note: ‘*((void*)& actual_range +4)’ was declared here
source_range actual_range;
^~~~
input.cc:85:56: warning: ‘actual_range’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
loc = get_location_from_adhoc_loc (line_table, loc);
^
input.cc:96:16: note: ‘actual_range’ was declared here
source_range actual_range;
^~~~
This appears to be a false positive: to access fields of actual_range,
execution needs to get past:
const char *err = get_source_range_for_char (idx, &actual_range);
if (should_have_column_data_p (strloc))
{
if (err)
fail ();
}
else
return;
*access happens here*
Given that fail is no-return, the only way to reach the access is for "err" to
be NULL.
Looking at a gimple dump, get_source_range_for_char has been inlined.
This can only return NULL if actual_range is written to, but presumably during
optimization we somehow lose track of this invariant
(or I'm misreading the code...)
Also, the location for the warning is odd: it's reported as within
assert_char_at_range, but the location given is within
should_have_column_data_p.
[Bug c++/78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] Bogus |[6 Regression] Bogus |'inconsistent deduction for |'inconsistent deduction for |‘auto’' error when having a |‘auto’' error when having a |dependent initializer and a |dependent initializer and a |nondependent one in the |nondependent one in the |same declaration|same declaration --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far. Will file a new PR for the still present accepts-invalid in templates.
[Bug c++/78949] incorrect "unused variable" warning with SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78949 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/78993] False positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993 --- Comment #1 from David Malcolm --- Created attachment 40462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40462&action=edit Gimple dump from when warning is emitted
[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991 --- Comment #1 from Andrew Pinski --- How positive you are that this is a libstdc++ bug rather than a clang bug? It works correctly with GCC 5.4.0's front-end and GCC 7.0's libstdc++ and front-end.
[Bug tree-optimization/78910] Wrong print-return-value for a negative number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78910 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00264.html
