[Bug target/71989] aarch64 musl bootstrap fails for out-of-tree builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71989 Timo Teräs changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Timo Teräs --- Seems to be fixed in gcc 6.4.0. Likely duplicate of PR77455. *** This bug has been marked as a duplicate of bug 77455 ***
[Bug target/77455] [AArch64] eh_return implementation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77455 --- Comment #6 from Timo Teräs --- *** Bug 71989 has been marked as a duplicate of this bug. ***
[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 Timo Teräs changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Timo Teräs --- I can confirm this to be fixed in GCC 6.4.0. Likely duplicate of PR77455. *** This bug has been marked as a duplicate of bug 77455 ***
[Bug target/77455] [AArch64] eh_return implementation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77455 Timo Teräs changed: What|Removed |Added CC||timo.teras at iki dot fi --- Comment #5 from Timo Teräs --- *** Bug 71951 has been marked as a duplicate of this bug. ***
[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421 martin changed: What|Removed |Added CC||mfe at live dot de --- Comment #2 from martin --- Created attachment 41739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41739&action=edit runtime.lo.dep I'll added the requested file.
Re: sanitizer bug maybe.
On 07/10/2017 10:29 AM, George R Goffe via gcc-bugs wrote: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In function ‘int __sanitizer::TracerThread(void*)’: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined struct sigaltstack handler_stack; If you are doing a build using glibc mainline, then this is FSF GCC bug 81066. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 Jim
[Bug tree-optimization/81192] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 Tom de Vries changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Tom de Vries --- Committed the 2 patches to trunk. Backported first patch to 5,6,7 branches. Marking resolved-fixed.
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #25 from Timo Teräs --- (In reply to Andrew Pinski from comment #24) > >This works everywhere else, so I wonder if we could have the ada makefile > >check the abi somehow more reliably than pathname? > > Your patch is broken anyways because it makes your OS very incompatible with > most others. Note I think this is a YOCTO which I know very much is wrong > in doing that. YOCTO is not friendly to multi-libing with aarch32 and > aarch64 and ilp32. Cavium had to hack the YOCTO patches to get rid of that > brokenness. We have musl c-library so binary compatibility is limited anyways. We do ship /lib64 -> /lib symlink in compatibility packages, though. My concern is that there are valid reasons to change that path. Could it be tested against MULTILIB_OSDIRNAMES or have alternate test that is not based on the path?
[Bug tree-optimization/81192] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 --- Comment #19 from Tom de Vries --- Author: vries Date: Thu Jul 13 05:42:15 2017 New Revision: 250175 URL: https://gcc.gnu.org/viewcvs?rev=250175&root=gcc&view=rev Log: Backport "Fix sigsegv in find_same_succ_bb" 2017-07-13 Tom de Vries backport from mainline: 2017-07-03 Tom de Vries PR tree-optimization/81192 * tree-ssa-tail-merge.c (same_succ_flush_bb): Handle BB_SAME_SUCC (bb) == NULL. * gcc.dg/pr81192.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr81192.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-tail-merge.c
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #24 from Andrew Pinski --- >This works everywhere else, so I wonder if we could have the ada makefile >check the abi somehow more reliably than pathname? Your patch is broken anyways because it makes your OS very incompatible with most others. Note I think this is a YOCTO which I know very much is wrong in doing that. YOCTO is not friendly to multi-libing with aarch32 and aarch64 and ilp32. Cavium had to hack the YOCTO patches to get rid of that brokenness.
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #23 from Timo Teräs --- (In reply to Andrew Pinski from comment #22) > (In reply to Timo Teräs from comment #21) > > This caused a regression for non-multilib builds. Now my non-multilib lp64 > > build fails with: > > a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55 > > a-cfinve.ads:245:04: warning: types for unchecked conversion have different > > sizes > > > > Probably because the logic added in this patch to Makefile.in picks up > > 64-bit file only when multilib is enabled. > > On which branch? The logic for GCC 7 and GCC 8 are different as Makefile.in > changes are not used any more. Also did you modify anything as multilib > itself should be enabled anyways for aarch64 due to the use /lib64 GCC 6.4.0 with some patches. Should have looked how it detects the multilib type. We have the build hardwired to use /lib always with --- ./gcc/config/aarch64/t-aarch64-linux.orig +++ ./gcc/config/aarch64/t-aarch64-linux @@ -22,7 +22,7 @@ LIB1ASMFUNCS = _aarch64_sync_cache_range AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be) -MULTILIB_OSDIRNAMES = mabi.lp64=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu) +MULTILIB_OSDIRNAMES = mabi.lp64=../lib MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu) MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32 So it's conflict between this. This works everywhere else, so I wonder if we could have the ada makefile check the abi somehow more reliably than pathname?
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 --- Comment #22 from Andrew Pinski --- (In reply to Timo Teräs from comment #21) > This caused a regression for non-multilib builds. Now my non-multilib lp64 > build fails with: > a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55 > a-cfinve.ads:245:04: warning: types for unchecked conversion have different > sizes > > Probably because the logic added in this patch to Makefile.in picks up > 64-bit file only when multilib is enabled. On which branch? The logic for GCC 7 and GCC 8 are different as Makefile.in changes are not used any more. Also did you modify anything as multilib itself should be enabled anyways for aarch64 due to the use /lib64
[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117 Timo Teräs changed: What|Removed |Added CC||timo.teras at iki dot fi --- Comment #21 from Timo Teräs --- This caused a regression for non-multilib builds. Now my non-multilib lp64 build fails with: a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55 a-cfinve.ads:245:04: warning: types for unchecked conversion have different sizes Probably because the logic added in this patch to Makefile.in picks up 64-bit file only when multilib is enabled.
[Bug fortran/81296] derived type I/o problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81296 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I will have a look.
[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ian at airs dot com Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Should be fixed.
[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Thu Jul 13 03:44:14 2017 New Revision: 250174 URL: https://gcc.gnu.org/viewcvs?rev=250174&root=gcc&view=rev Log: PR go/81393 syscall: don't use GETREGS/SETREGS on s390 They were removed in recent glibc. Patch by Andreas Krebbel for GCC PR 81393. Reviewed-on: https://go-review.googlesource.com/48231 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/syscall/syscall_linux_s390.go trunk/libgo/go/syscall/syscall_linux_s390x.go
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-13 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #15 from Jerry DeLisle --- (In reply to jos...@codesourcery.com from comment #11) > I don't know what process Jakub and Tobias used (a) to identify relevant > files / changes in glibc and (b) to make all the changes to operate on > __float128 rather than long double. Roughly, it's > sysdeps/ieee754/ldbl-128, *plus* strtod-related files from stdlib/, *plus* > printf-related files from stdio-common, *plus* some functions (especially > functions) from math/, that are used in libquadmath and so may > need updating for changes made in glibc. Evidently we need to fix this. I will add to my list as assigned to me and get with Tobias for some hints.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 John Steele Scott changed: What|Removed |Added CC||toojays at toojays dot net --- Comment #14 from John Steele Scott --- FWIW Clang has this warning via -Wnon-pod-varargs.
[Bug tree-optimization/81423] New: Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423
Bug ID: 81423
Summary: Wrong code at -O2
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250140, x86_64.
Test case has no undefined behavior, but -O2 produces incorrect result.
> cat f.cpp
#include
unsigned long long int ll = 0;
unsigned long long int ull1 = 1ULL;
unsigned long long int ull2 = 12008284144813806346ULL;
unsigned long long int ull3;
void foo() {
ll = -5597998501375493990LL;
ll = unsigned(5677365550390624949L - ll) - (ull1 > 0);
ull3 = unsigned(2067854353L << (((ll + -2129105131L) ^
10280750144413668236ULL) - 10280750143997242009ULL)) >>
((2873442921854271231ULL | ull2) - 12098357307243495419ULL);
}
int main() {
foo();
std::cout << ull3 << " (expected 3998784)\n";
return 0;
}
> g++ f.cpp -O0 -o out; ./out
3998784 (expected 3998784)
> g++ f.cpp -O2 -o out; ./out
3493659712 (expected 3998784)
[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193 --- Comment #13 from Michael Meissner --- Author: meissner Date: Wed Jul 12 23:07:50 2017 New Revision: 250165 URL: https://gcc.gnu.org/viewcvs?rev=250165&root=gcc&view=rev Log: [gcc] 2017-07-12 Michael Meissner PR target/81193 * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If GLIBC provides the hardware capability bits, define the macro __BUILTIN_CPU_SUPPORTS__. * config/rs6000/rs6000.c (cpu_expand_builtin): Generate a warning if GLIBC does not provide the hardware capability bits. Add a gcc_unreachable call if the built-in cpu function is neither __builtin_cpu_is nor __builtin_cpu_supports. (rs6000_get_function_versions_dispatcher): Change the warning that an old GLIBC is used which does not export the capability bits to be an error. * doc/extend.texi (target_clones attribute): Document the restriction that GLIBC 2.23 or newer is needed on the PowerPC. (PowerPC built-in functions): Document that GLIBC 2.23 or newer is needed by __builtin_cpu_is and __builtin_cpu_supports. Document the macros defined by GCC if the newer GLIBC is available. [gcc/testsuite] 2017-07-12 Michael Meissner PR target/81193 * gcc.target/powerpc/bmi-andn-1.c: Add guard against using __builtin_cpu_supports with old GLIBC's. * gcc.target/powerpc/bmi-andn-2.c: Likewise. * gcc.target/powerpc/bmi-bextr-1.c: Likewise. * gcc.target/powerpc/bmi-bextr-2.c: Likewise. * gcc.target/powerpc/bmi-bextr-4.c: Likewise. * gcc.target/powerpc/bmi-bextr-5.c: Likewise. * gcc.target/powerpc/bmi-blsi-1.c: Likewise. * gcc.target/powerpc/bmi-blsi-2.c: Likewise. * gcc.target/powerpc/bmi-blsmsk-1.c: Likewise. * gcc.target/powerpc/bmi-blsmsk-2.c: Likewise. * gcc.target/powerpc/bmi-blsr-1.c: Likewise. * gcc.target/powerpc/bmi-blsr-2.c: Likewise. * gcc.target/powerpc/bmi-tzcnt-1.c: Likewise. * gcc.target/powerpc/bmi-tzcnt-2.c: Likewise. * gcc.target/powerpc/bmi2-bzhi32-1.c: Likewise. * gcc.target/powerpc/bmi2-bzhi64-1.c: Likewise. * gcc.target/powerpc/bmi2-mulx32-1.c: Likewise. * gcc.target/powerpc/bmi2-mulx32-2.c: Likewise. * gcc.target/powerpc/bmi2-mulx64-1.c: Likewise. * gcc.target/powerpc/bmi2-mulx64-2.c: Likewise. * gcc.target/powerpc/bmi2-pdep32-1.c: Likewise. * gcc.target/powerpc/bmi2-pdep64-1.c: Likewise. * gcc.target/powerpc/bmi2-pext32-1.c: Likewise. * gcc.target/powerpc/bmi2-pext64-1.c: Likewise. * gcc.target/powerpc/cpu-builtin-1.c: Likewise. [libgcc] 2017-07-12 Michael Meissner PR target/81193 * configure.ac (PowerPC float128 hardware support): Test whether we can use __builtin_cpu_supports before enabling the ifunc handler. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-bextr-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-bextr-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-bextr-4.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-bextr-5.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsi-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsi-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsmsk-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsmsk-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsr-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-blsr-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-tzcnt-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi-tzcnt-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-bzhi32-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-bzhi64-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-mulx32-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-mulx32-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-mulx64-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-mulx64-2.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-pdep32-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-pdep64-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-pext32-1.c trunk/gcc/testsuite/gcc.target/powerpc/bmi2-pext64-1.c trunk/gcc/testsuite/gcc.target/powerpc/cpu-builtin-1.c trunk/libgcc/ChangeLog trunk/libgcc/configure trunk/libgcc/configure.ac
[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421 --- Comment #1 from Ian Lance Taylor --- I can't recreate this and nobody else has reported it. runtime.lo should not depend on runtime.s-gox. What are the contents of BUILDDIR/TARGET/libgo/runtime.lo.dep?
[Bug c++/70570] Assembler error "symbol already defined" from nested lambdas and function-static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70570 --- Comment #3 from Jesse Haber-Kucharsky --- The .ii file is too large to attach. I hope the previous information I supplied is sufficient and helpful.
[Bug rtl-optimization/81422] New: [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81422
Bug ID: 81422
Summary: [aarch64] internal compiler error: in
update_equiv_regs, at ira.c:3425
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Reduced test:
---
struct DArray
{
__SIZE_TYPE__ length;
int* ptr;
};
void foo35(DArray)
{
static __thread int x[5];
foo35({5, (int*)&x});
}
---
during RTL pass: ira
test.cc: In function ‘void foo35(DArray)’:
test.cc:11:1: internal compiler error: in update_equiv_regs, at ira.c:3425
0xbe1223 update_equiv_regs
/build/aarch64-linux-gnu/build/gcc/ira.c:3425
0xbe6bf0 ira
/build/aarch64-linux-gnu/build/gcc/ira.c:5226
0xbe6bf0 execute
/build/aarch64-linux-gnu/build/gcc/ira.c:5581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/70570] Assembler error "symbol already defined" from nested lambdas and function-static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70570 Jesse Haber-Kucharsky changed: What|Removed |Added CC||jhaberku at scylladb dot com --- Comment #2 from Jesse Haber-Kucharsky --- I believe this bug manifested itself in Seastar (https://github.com/scylladb/seastar/commit/3d21ef5959bedb3ea15032d1632b0b2d7012044a). The original snippet from Nick causes the error on Fedora 23: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC) and on Ubuntu 16.04: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) On both platforms, the error is the same: g++ -std=c++14 test.cc -o test /tmp/ccTNkOnu.s: Assembler messages: /tmp/ccTNkOnu.s:34: Error: symbol `_ZL1x' is already defined On gcc 7.1.1, the error is not present: Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC) To reproduce the exact compilation error with Seastar: docker pull fedora:23 docker run -it --rm fedora:23 bash dnf install -y git cd opt && git clone https://github.com/scylladb/seastar git checkout a2be7a4f312a62c67c79cf818970d0c954f5fc15 git submodule update --init ./install-dependencies.sh ./configure.py --mode=debug ninja-build build/debug/tests/lowres_clock_test.o The error: g++ -MD -MT build/debug/tests/lowres_clock_test.o -MF build/debug/tests/lowres_clock_test.o.d -fsanitize=address -fsanitize=leak -fsanitize=undefined -fno-sanitize=vptr -DASAN_ENABLED -O0 -DDEBUG -DDEBUG_SHARED_PTR -DDEFAULT_ALLOCATOR -DSEASTAR_THREAD_STACK_GUARDS -I/opt/seastar/build/debug/gen -I/opt/seastar/build/debug/c-ares -std=gnu++1y -g -Wall -Werror -Wno-error=deprecated-declarations -fvisibility=hidden -pthread -I/opt/seastar -U_FORTIFY_SOURCE -I/opt/seastar/fmt -DBOOST_TEST_DYN_LINK -Wno-overloaded-virtual -Wno-maybe-uninitialized -DFMT_HEADER_ONLY -DHAVE_HWLOC -DHAVE
[Bug libstdc++/81413] overloaded new and delete might not be called when dynamically linked with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81413 --- Comment #1 from Jonathan Wakely --- The linker model on Windows is weird, there are already existing bugs about this (at least PR 77726 but others too). It works fine on other platforms.
[Bug go/81421] New: Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81421 Bug ID: 81421 Summary: Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: mfe at live dot de CC: cmang at google dot com Target Milestone: --- the exact version of GCC: gcc-7.1.0 the system type: NetgearReadyNAS Duo (http://netgear.nas-central.org/wiki/Category:ReadyNasDUO) the options given when GCC was configured/built: configure CC=/opt/gcc-4.6/bin/gcc CXX=/opt/gcc-4.6/bin/g++ --enable-languages=c,c++,go --prefix=/opt/gcc-7.1 --with-cpu=v7 --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-isl=/usr/local/ --disable-libstdcxx-pch the complete command line that triggers the bug; /usr/local/bin/make the compiler output (error messages, warnings, etc.); [...] /bin/mkdir -p container; dir=`echo container/heap.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo container/heap.lo.dep | sed -e 's/.dep$//'` $files > container/heap.lo.dep.tmp; if ! cmp container/heap.lo.dep.tmp container/heap.lo.dep >/dev/null 2>/dev/null; then rm -f `echo container/heap.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f container/heap.lo.dep.tmp container/heap.lo.dep /bin/mkdir -p compress; dir=`echo compress/zlib.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo compress/zlib.lo.dep | sed -e 's/.dep$//'` $files > compress/zlib.lo.dep.tmp; if ! cmp compress/zlib.lo.dep.tmp compress/zlib.lo.dep >/dev/null 2>/dev/null; then rm -f `echo compress/zlib.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f compress/zlib.lo.dep.tmp compress/zlib.lo.dep /bin/mkdir -p compress; dir=`echo compress/lzw.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo compress/lzw.lo.dep | sed -e 's/.dep$//'` $files > compress/lzw.lo.dep.tmp; if ! cmp compress/lzw.lo.dep.tmp compress/lzw.lo.dep >/dev/null 2>/dev/null; then rm -f `echo compress/lzw.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f compress/lzw.lo.dep.tmp compress/lzw.lo.dep /bin/mkdir -p compress; dir=`echo compress/gzip.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo compress/gzip.lo.dep | sed -e 's/.dep$//'` $files > compress/gzip.lo.dep.tmp; if ! cmp compress/gzip.lo.dep.tmp compress/gzip.lo.dep >/dev/null 2>/dev/null; then rm -f `echo compress/gzip.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f compress/gzip.lo.dep.tmp compress/gzip.lo.dep /bin/mkdir -p compress; dir=`echo compress/flate.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo compress/flate.lo.dep | sed -e 's/.dep$//'` $files > compress/flate.lo.dep.tmp; if ! cmp compress/flate.lo.dep.tmp compress/flate.lo.dep >/dev/null 2>/dev/null; then rm -f `echo compress/flate.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f compress/flate.lo.dep.tmp compress/flate.lo.dep /bin/mkdir -p compress; dir=`echo compress/bzip2.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo compress/bzip2.lo.dep | sed -e 's/.dep$//'` $files > compress/bzip2.lo.dep.tmp; if ! cmp compress/bzip2.lo.dep.tmp compress/bzip2.lo.dep >/dev/null 2>/dev/null; then rm -f `echo compress/bzip2.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f compress/bzip2.lo.dep.tmp compress/bzip2.lo.dep /bin/mkdir -p cmd/internal; dir=`echo cmd/internal/browser.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh ../../../gcc-7.1.0/libgo/match.sh --goarch=sparc --goos=linux --srcdir=../../../gcc-7.1.0/libgo/go/$dir --extrafiles="" `; /bin/sh ../../../gcc-7.1.0/libgo/godeps.sh `echo cmd/internal/browser.lo.dep | sed -e 's/.dep$//'` $files > cmd/internal/browser.lo.dep.tmp; if ! cmp cmd/internal/browser.lo.dep.tmp cmd/internal/browser.lo.dep >/dev/null 2>/dev/null; then rm -f `echo cmd/internal/browser.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f cmd/internal/browser.lo.dep.tmp cmd/internal/browser.lo.dep /bin/mkdir -p .; dir=`echo bytes.lo.dep | se
[Bug debug/81135] Extra debug info generated for unused extern declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135 Franklin "Snaipe" Mathieu changed: What|Removed |Added CC||snaipe at arista dot com --- Comment #2 from Franklin "Snaipe" Mathieu --- A patch for this has been sent: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00602.html
[Bug c++/81420] New: When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81420
Bug ID: 81420
Summary: When a reference is bound to a member in the base of a
temporary, lifetime of the temporary is not extended
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.brown at ableton dot com
Target Milestone: ---
This is a followup to bug #54293. The incorrect behavior can be seen by
modifying the test introduced for that bug [0] to use a base class:
int d;
struct A
{
int i;
~A() { ++d; };
};
struct B : A {};
int main()
{
{
const int &r = B().i;
if (d != 0)
return 1;
}
if (d != 1)
return 1;
}
This test passes for clang HEAD and fails for GCC HEAD.
[0]
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/g%2B%2B.dg/init/ref19.C?view=markup&pathrev=240819
[Bug lto/81406] ice in check_die, at dwarf2out.c:6185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81406 --- Comment #2 from David Binderman --- Created attachment 41738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41738&action=edit preprocessed C source code Flags -O2 -g -pipe -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -flto -fPIC required.
[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81303
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-07-12
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Wilco ---
Confirmed, on AArch64 bwaves is ~20% slower in SPEC2006 and ~30% slower in
SPEC2017. There are twice as many spills (outside the inner loop) and the
vectors are created in an inefficient way:
ldr d4, [x5,x27]
ld1r{v6.2d}, [x5]
mov v6.d[1], v4.d[0]
add x5, x5, x26
fmlav1.2d, v20.2d, v6.2d
[Bug c/81417] -Wsign-compare should print types being compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-12 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I'll look into this.
[Bug preprocessor/81419] New: GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419
Bug ID: 81419
Summary: GCC wrongly suggests function-like macro as fixit hint
for undefined object-like macro
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: egall at gwmail dot gwu.edu
CC: dmalcolm at redhat dot com
Target Milestone: ---
Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
Build: i386-apple-darwin9.8.0
Testcase:
$ cat macro_fixit.c
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
int foo(unsigned int argument);
int bar(void)
{
return foo(PTR_SIZE);
}
Compiling gives:
$ /usr/local/bin/gcc -c macro_fixit.c
macro_fixit.c: In function ‘bar’:
macro_fixit.c:7:13: error: ‘PTR_SIZE’ undeclared (first use in this function);
did you mean ‘ARRAY_SIZE’?
return foo(PTR_SIZE);
^~~~
ARRAY_SIZE
macro_fixit.c:7:13: note: each undeclared identifier is reported only once for
each function it appears in
However, making the replacement that the fixit hint suggests is invalid, and
still leads to another error:
$ /usr/local/bin/gcc -c macro_fixit.c
macro_fixit.c: In function ‘bar’:
macro_fixit.c:7:13: error: ‘ARRAY_SIZE’ undeclared (first use in this function)
return foo(ARRAY_SIZE);
^~
macro_fixit.c:7:13: note: each undeclared identifier is reported only once for
each function it appears in
IMO gcc should only suggest replacements as fixit hints when they actually fix
the problem being pointed out.
Version info:
$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170702 (experimental) (GCC)
[Bug preprocessor/49928] Only workaround for "-Wundef" is "defined(Macro) && Macro", but it is undefined behavior?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49928 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager --- -Wexpansion-to-defined now exists and should warn about this
[Bug tree-optimization/81418] New: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81418
Bug ID: 81418
Summary: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20170709 ICEs when compiling the following snippet w/ -O1
-ftree-loop-vectorize:
int
ol (int ku)
{
int zq = 0;
while (ku < 1)
{
int y6;
for (y6 = 0; y6 < 3; ++y6)
zq += (char)ku;
++ku;
}
return zq;
}
% gcc-8.0.0-alpha20170709 -O1 -ftree-loop-vectorize -c -w mndyhqic.c
during GIMPLE pass: vect
mndyhqic.c: In function 'ol':
mndyhqic.c:2:1: internal compiler error: in vect_get_vec_def_for_stmt_copy, at
tree-vect-stmts.c:1522
ol (int ku)
^~
(As a side note, when compiling this w/ -O2 or higher, -ftree-loop-vectorize
makes 8 branch generate something absolutely hilarious:
https://godbolt.org/g/R4YW3b).
[Bug c/81417] New: -Wsign-compare should print types being compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417
Bug ID: 81417
Summary: -Wsign-compare should print types being compared
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: egall at gwmail dot gwu.edu
Target Milestone: ---
Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
Build: i386-apple-darwin9.8.0
Simple testcase:
$ cat Wsign_compare.c
/* { dg-do compile } */
int foo(signed int a, unsigned int b)
{
return (a < b);
}
When compiled with gcc, it says:
$ /usr/local/bin/gcc -c -Wsign-compare Wsign_compare.c
Wsign_compare.c: In function ‘foo’:
Wsign_compare.c:5:12: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
return (a < b);
^
However, when compiled with clang, it gives more information:
$ /sw/opt/llvm-3.1/bin/clang -c -Wsign-compare Wsign_compare.c
Wsign_compare.c:5:12: warning: comparison of integers of different signs: 'int'
and 'unsigned int' [-Wsign-compare]
return (a < b);
~ ^ ~
1 warning generated.
In such a small file like this it might not matter much, but in bigger files
where the variables being compared are very far away from their declarations,
it can be hard to remember what types they are. Having the compiler remind me
of the types being compared would be helpful when deciding how to silence
warnings like these.
Version info:
$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170702 (experimental) (GCC)
[Bug fortran/81416] OpenMP craches if large arrays passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81416 --- Comment #1 from Andrew Pinski --- Try increasing your stack limit. I suspect it is too low. With -fopenmp turned on causes arrays to be always stored on the stack .
[Bug middle-end/59521] __builtin_expect not effective in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 Yuri Gribov changed: What|Removed |Added Attachment #41698|0 |1 is obsolete|| --- Comment #8 from Yuri Gribov --- Created attachment 41737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41737&action=edit New draft patch How about this? I added edge attribute for builtin_expect and later used it in emit_case_decision_tree to emit expected comparison prior to decision tree for other case values. With this patch GCC optimizes original example. If it's not too ugly I'll do proper testing and send to gcc-patches.
[Bug fortran/81416] New: OpenMP craches if large arrays passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81416 Bug ID: 81416 Summary: OpenMP craches if large arrays passed Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bz0815 at tirol dot com Target Milestone: --- gfortran crashes if OpenMP is activated and large arrays are passed: $ cat mod.f08 MODULE Mod USE OMP_LIB IMPLICIT NONE CONTAINS SUBROUTINE Print_Info(b) DOUBLE PRECISION,DIMENSION(:),INTENT(out) :: b b = 0.0 !$OMP PARALLEL PRINT *,'Hello' PRINT *,omp_get_num_threads() !$OMP END PARALLEL END SUBROUTINE Print_Info END MODULE Mod $ cat prog.f08 PROGRAM Prog USE Mod USE OMP_LIB IMPLICIT NONE INTEGER :: nthreads INTEGER,PARAMETER :: n = 131072 ! INTEGER,PARAMETER :: n = 262144 DOUBLE PRECISION,DIMENSION(n) :: b nthreads = 4 CALL OMP_SET_NUM_THREADS(nthreads) PRINT *,omp_get_num_procs() PRINT *,omp_get_max_threads() PRINT *,omp_get_num_threads() CALL Print_Info(b) END PROGRAM Prog If n is 131072 the program compiles and shows the expeced result: gfortran -Wall -O2 -std=f2008 -fcheck=all -fopenmp -c mod.f08 -o mod.o gfortran -Wall -O2 -std=f2008 -fcheck=all -fopenmp -o prog mod.o prog.f08 -lgomp $ ./prog 8 4 1 Hello 4 Hello 4 Hello 4 Hello 4 If n is 262144 the program compiles but craches: $ ./prog Segmentation fault (core dumped) The program runs if OpenMP is removed: gfortran -Wall -O2 -std=f2008 -fcheck=all -c mod.f08 -o mod.o gfortran -Wall -O2 -std=f2008 -fcheck=all -o prog mod.o prog.f08 -lgomp Wolfgang@DESKTOP ~/projects/test/openmp $ ./prog 8 4 1 Hello 1 The system used is: $ uname -a CYGWIN_NT-10.0 DESKTOP 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin The compiler used is: $ gfortran --version GNU Fortran (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING I experienced the same behavior also on other systems and other compler versions.
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 Tom de Vries changed: What|Removed |Added Attachment #41733|0 |1 is obsolete|| --- Comment #6 from Tom de Vries --- Created attachment 41736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41736&action=edit updated patch
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.2 --- Comment #9 from Georg-Johann Lay --- Fixed in 7.2. The respective parts are quoted now. The function name is not repeated in the diagnostics as that name preceeds all the messages like in: foo.c: In function 'main': foo.c:3:5: error: ... ... Only the diagnostic complaining about a missing "__vector" prefix repeats the function name, but for the other diagnostics (like wrong prototype) the very name doesn't actually matter. Also enclosed in WITH_AVRLIBC now because this is naming convention of AVR-LibC.
[Bug libgcc/81415] termio ioctl returns incorrect value for some characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81415 --- Comment #3 from Steven Pemberton --- $ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
[Bug libgcc/81415] termio ioctl returns incorrect value for some characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81415 --- Comment #2 from Steven Pemberton --- Created attachment 41735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41735&action=edit termio2.c Second test case, prints all 17 bindings.
[Bug libgcc/81415] termio ioctl returns incorrect value for some characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81415 --- Comment #1 from Steven Pemberton --- This is with the default gcc on Ubuntu 16.04.02
[Bug libgcc/81415] New: termio ioctl returns incorrect value for some characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81415
Bug ID: 81415
Summary: termio ioctl returns incorrect value for some
characters
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at pemberton dot nl
Target Milestone: ---
Created attachment 41734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41734&action=edit
termio.c calls ioctl to get erase, interrupt and suspend characters
When calling ioctl to request key bindings, it returns a random value for the
Suspend binding.
On my system, if I do a stty -a I get this:
$ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 =
M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
If I run the enclosed C program, which does an ioctl for TCGETA:
if (ioctl(0, TCGETA, (char*) &sgbuf) == 0) {
and then retrieves the key bindings for interrupt, erase, and suspend (^C, ^?,
and ^Z in the above output). It returns Interrupt and Erase correctly, but it
returns the wrong value for Suspend; each time I run the program it returns a
different value, though it consistently returns the same (wrong) value within
the program:
if ((int) sgbuf.c_cc[VSUSP] != 0377) {
printf("Suspend=%i\n", (int)sgbuf.c_cc[VSUSP]);
}
The program calls the ioctl three times to see if it always returns the same
value within the program. It does.
An example output:
Erase= 127, Interrupt=3, Suspend=31
Erase= 127, Interrupt=3, Suspend=31
Erase= 127, Interrupt=3, Suspend=31
but the next time I run it:
Erase= 127, Interrupt=3, Suspend=171
Erase= 127, Interrupt=3, Suspend=171
Erase= 127, Interrupt=3, Suspend=171
This is attachment termio.c
termios.h says there are 17 characters (0..16) in the c_cc buffer. If I print
them all out (here I've run it three times), it seems like 4 characters change
their value between calls: 8 (VSTART) 9 (VSTOP) 10 (VSUSP) 16 (VEOL2)
0:3 1:28 2:127 3:21 4:4 5:0 6:1 7:255 8: 18 9:122 10:99 11:255 12:127 13:0
14:0 15:0 16:134
0:3 1:28 2:127 3:21 4:4 5:0 6:1 7:255 8:215 9:152 10:145 11:255 12:127 13:0
14:0 15:0 16:129
0:3 1:28 2:127 3:21 4:4 5:0 6:1 7:255 8: 10 9:97 10:251 11:255 12:127 13:0
14:0 15:0 16:239
(This produced by attachment termio2.c)
The equivalent function from termios, namely tcgetattr, seems to give the right
results, consistently over calls.
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Wed Jul 12 15:31:22 2017 New Revision: 250157 URL: https://gcc.gnu.org/viewcvs?rev=250157&root=gcc&view=rev Log: gcc/ Backport from 2017-07-12 trunk r250156. PR target/79883 * config/avr/avr.c (avr_set_current_function): In diagnostic messages: Quote keywords and (parts of) identifiers. [WITH_AVRLIBC]: Warn for functions named "ISR", "SIGNAL" or "INTERRUPT". Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/avr/avr.c
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Wed Jul 12 15:25:07 2017 New Revision: 250156 URL: https://gcc.gnu.org/viewcvs?rev=250156&root=gcc&view=rev Log: PR target/79883 * config/avr/avr.c (avr_set_current_function): In diagnostic messages: Quote keywords and (parts of) identifiers. [WITH_AVRLIBC]: Warn for functions named "ISR", "SIGNAL" or "INTERUPT". Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug c/81405] [8 Regression] Invalid write of size 2 in line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1514)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81405 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-12 Version|7.0 |8.0 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing. Confirmed. Am investigating.
[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400 --- Comment #3 from Chris Severance --- Unless there's a security reason 0 should never be used as a canary value. Errant \0 should be caught 100% of the time. When I built malloc canaries for NPPTextFX I expressly avoided \0. data[SMASH_ALIGN]='f' should be caught by bounds checking or a shadow stack, not ssp. It doesn't overwrite any canaries. It only writes to icanary which is my canary, not a gcc canary. The only time it should be caught by ssp is when icanary is disabled and it overwrites CNRY at the top of the stack. For debug builds canaries should be placed between every stack variable and in the unused space of aligned but undersized variables. Is there such an option?
[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 --- Comment #5 from Tom de Vries --- Created attachment 41733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41733&action=edit tentative patch, starts neutering alap in nvptx_single > But in this case, we're extending the sese region being neutered to include > a branch that doesn't have to be neutered. I don't think there's a purpose in > doing that. This patch postpone insertion of the diverging branch to alap, by skipping over unconditional jumps at the start of nvptx_single. This allows the test-case to pass (because we don't run into the ptx bug).
[Bug target/81414] [6/7/8 Regression] ICE in fma steering on AArch64/cortex-a57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81414 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.4.1 Keywords||ice-on-valid-code Last reconfirmed||2017-07-12 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE in fma steering on |[6/7/8 Regression] ICE in |AArch64/cortex-a57 |fma steering on ||AArch64/cortex-a57 Target Milestone|--- |6.5 Known to fail||6.4.1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug target/81414] New: ICE in fma steering on AArch64/cortex-a57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81414
Bug ID: 81414
Summary: ICE in fma steering on AArch64/cortex-a57
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Hi,
Compiling below test case:
typedef __Float32x2_t float32x2_t;
__inline float32x2_t vdup_n_f32(float) {}
float32x2_t vfma_lane_f32(float32x2_t __a, float32x2_t __b) {
int __lane;
return __builtin_aarch64_fmav2sf(__b, vdup_n_f32(__lane), __a);
}
With options:
$ g++ x.cc -mcpu=cortex-a57 -O2 -o x.S
gives below ICE:
x.cc: In function ‘float32x2_t vfma_lane_f32(float32x2_t, float32x2_t)’:
x.cc:10:1: internal compiler error: in analyze, at
config/aarch64/cortex-a57-fma-steering.c:977
}
^
0x14198f8 func_fma_steering::analyze()
../../gcc/gcc/config/aarch64/cortex-a57-fma-steering.c:977
0x1419af3 func_fma_steering::execute_fma_steering()
../../gcc/gcc/config/aarch64/cortex-a57-fma-steering.c:1026
0x1419deb pass_fma_steering::execute(function*)
../../gcc/gcc/config/aarch64/cortex-a57-fma-steering.c:1062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
The Funds from Ester Hileman
Hi Your email (gcc-bugs@gcc.gnu.org) was used as the destination of the transfer. The Transfer should appear in 3 days. Access key is DfgpU7FRo. You need to enter it to be able to view the attached file. Ester Hileman e55b_Ester Hileman.docx Description: Attached file: e55b_Ester Hileman.docx
[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81407 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instantiate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073 --- Comment #12 from Georg-Johann Lay --- Thanks, (In reply to Jason Merrill from comment #9) > Created attachment 41711 [details] > patch to error on progmem with dynamic init > > Does this do what you had in mind? Hi, thanks. Used to implement PR81407. FYI, problem above was that the test was inside "if DECL_INITIAL == NULL". When moved out of that condition, it works as expected.
[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81407 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Wed Jul 12 13:58:34 2017 New Revision: 250151 URL: https://gcc.gnu.org/viewcvs?rev=250151&root=gcc&view=rev Log: PR target/81407 * config/avr/avr.c (avr_encode_section_info) [progmem && !TREE_READONLY]: Error if progmem object needs constructing. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81407 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Georg-Johann Lay --- Fixed in v8.
[Bug libquadmath/81412] roundq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81412 --- Comment #2 from Huang Zhibin --- Bug 65757 Status: UNCONFIRMED. How to fix this Bug?
[Bug c++/80287] C++ crash with __attribute((may_alias))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287 --- Comment #5 from Bernd Edlinger --- (In reply to Yvan Roux from comment #4) > Hi Bernd, > > gcc-6-branch is impacted by this issue (observed on AArch64 target at > r250109, with regression introduced at r234768). I can prepare the backport > if you whish. Yes, thanks, go ahead.
[Bug c++/80287] C++ crash with __attribute((may_alias))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287 Yvan Roux changed: What|Removed |Added CC||yroux at gcc dot gnu.org --- Comment #4 from Yvan Roux --- Hi Bernd, gcc-6-branch is impacted by this issue (observed on AArch64 target at r250109, with regression introduced at r234768). I can prepare the backport if you whish.
[Bug libstdc++/81413] New: overloaded new and delete might not be called when dynamically linked with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81413
Bug ID: 81413
Summary: overloaded new and delete might not be called when
dynamically linked with libstdc++
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: space_sk8er8 at hotmail dot com
Target Milestone: ---
new and delete operator overloading might or might not work when compiled using
different compilers and different c++ standards.
I used the following code to test the compilers.
#include
void * operator new(size_t size)
{
std::cout << "1\n";
return malloc(size);
}
void operator delete(void * ptr) noexcept
{
std::cout << "2\n";
free(ptr);
}
int main(void)
{
int *n1 = new int;
delete n1;
int *n2 = new int[10];
delete[] n2;
}
Here are the results I got from several compilers I have tested the code on.
mingw-w64 official build - x86_64-7.1.0-release-posix-seh-rt_v5-rev0.7z
c++11
1
2
c++14
1
clang x86_64 - v4.0.0 manually built without patches using the compiler above
c++11 and c++14
1
2
msvc - platform toolset v141 & sdk v10.0.15063.0
/std:c++14 & /std:c++latest
1
2
1
2
All tests are performed on Windows 7. I can't test compilers on GNU/Linux OS
because I don't have any VMs set up.
Apparently, if -static or -static-libstdc++ is specified, it outputs the
intended result.
c++11 and c++14
1
2
1
2
More discussions at
https://sourceforge.net/p/mingw-w64/bugs/634/
and
https://stackoverflow.com/questions/44907098/c-new-and-delete-overloading
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 Jakub Jelinek changed: What|Removed |Added CC||fjwyhzb at hotmail dot com --- Comment #14 from Jakub Jelinek --- *** Bug 81412 has been marked as a duplicate of this bug. ***
[Bug libquadmath/81412] roundq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81412 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 65757 ***
[Bug libquadmath/81412] New: roundq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81412
Bug ID: 81412
Summary: roundq
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: fjwyhzb at hotmail dot com
Target Milestone: ---
Created attachment 41732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41732&action=edit
roundq-bug.i
$ cat roundq-bug.c
#include
#include
int main(void)
{
double x = 2147483648.7;
printf("roundq(%.1f) = %.1f\n", x, (double)roundq(x));
}
$ gcc -save-temps -Wall -Wextra roundq-bug.c -lquadmath
$ ./a.out
roundq(2147483648.7) = 2147483648.7
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 7.1.1 20170621 (GCC)
[Bug c++/81410] [5/6/7/8 Regression] -O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 --- Comment #5 from Marc Glisse --- Seems related to vectorization. These lines look suspicious: vect__37.14_78 = MEM[(long int *)_30]; vect__37.15_72 = MEM[(long int *)_30 + 16B]; vect__37.16_70 = MEM[(long int *)_30 + 32B]; vect__37.17_68 = MEM[(long int *)_30 + 48B]; MEM[(long int *)_28] = vect__37.14_78; MEM[(long int *)_28 + 16B] = vect__37.15_72; MEM[(long int *)_28 + 32B] = vect__37.16_70; MEM[(long int *)_28 + 48B] = vect__37.17_68; where _30 is for b, _28 is for a, and I would expect to see gaps in the reads from b (+24, +48, +72 instead of +16, +32 and +48). But I haven't checked, this is only a first guess.
[Bug tree-optimization/81409] Inefficient loops generated from range-v3 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81409 --- Comment #1 from Marc Glisse --- The most obvious thing I notice is [100.00%] [count: INV]: # it$_M_current_23 = PHI _20 = _7 == it$_M_current_23; _5 = _20 | _53; if (_5 != 0) goto ; [7.36%] [count: INV] else goto ; [92.64%] [count: INV] [92.60%] [count: INV]: _27 = it$_M_current_23 + 4; if (_7 != _27) goto ; [3.75%] [count: INV] else goto ; [96.25%] [count: INV] where 7 -> 6 means that _7 == _27 == it$_M_current_23 so _5 != 0 has to be true. However, we do not thread that (at thread4 time, we go from 7 to 12 (empty latch) to 6 instead of directly to 6).
[Bug c++/81410] [5/6/7/8 Regression] -O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-12 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|O3 breaks code |[5/6/7/8 Regression] -O3 ||breaks code Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Confirmed, started with r209313.
[Bug fortran/81411] New: intrinsic polymorphic assignment run time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81411 Bug ID: 81411 Summary: intrinsic polymorphic assignment run time error Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ian at rhymneyconsulting dot co.uk Target Milestone: --- Created attachment 41731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41731&action=edit This is the total set of files. I get the following error at run time c:\document\fortran\fourth_edition\examples>ch2806_gfortran.exe calling display subroutine Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x #1 0x #2 0x #3 0x #4 0x #5 0x #6 0x #7 0x #8 0x #9 0x #10 0x #11 0x #12 0x #13 0x #14 0x
[Bug c++/81410] O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 --- Comment #3 from Sjors Gielen --- A trivial workaround is put inside the first loop: std::cout << ""; I suppose this prevents loop optimization by introducing potential side effects.
[Bug c++/81410] O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 Maurice Bos changed: What|Removed |Added CC||m-ou...@m-ou.se --- Comment #2 from Maurice Bos --- Created attachment 41730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41730&action=edit Test case without using any standard headers Here's a test case which fails in the same way (on x86_64, Gcc 7.1.1), but without using any standard headers. (No std::pair or std::vector.) Only fails with -O3, with any -std=.
[Bug c++/81410] O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 --- Comment #1 from Sjors Gielen --- This is on x86_64 by the way. Doesn't happen with -m32.
[Bug c++/81410] New: O3 breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81410 Bug ID: 81410 Summary: O3 breaks code Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at sjor dot sg Target Milestone: --- Created attachment 41729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41729&action=edit Minimal test case See attached code. Tested on Ubuntu's gcc 6.2.0, Debian's 6.3.0, Arch's 7.1.1. Testcase is about as minimal as I could get it. Compile with -O3 -std=c++11. As you see, it extracts data from a vector to two vectors. Then, it checks whether the vector.first and vector have the same values. If so, it exit(1)'s which confirms the bug is present.
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
amker at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6)
> And there's sample which started to be reported with Bin's revision r238641:
>
> namespace a {
> void b () __attribute__ ((__noreturn__));
> template struct d;
> template struct d
> {
> typedef e f;
> };
> struct g
> {
> template using i = h *;
> };
> }
> using a::d;
> template class k
> {
> j l;
>
> public:
> typename d::f operator* () {}
> void operator++ () { ++l; }
> j
> aa ()
> {
> return l;
> }
> };
> template
> bool
> operator!= (k o, k p2)
> {
> return o.aa () != p2.aa ();
> }
> struct p;
> namespace a {
> struct F
> {
> struct q
> {
> using ai = g::i;
> };
> using r = q::ai;
> };
> class H
> {
> public:
> k begin ();
> k end ();
> };
> int s;
> class I
> {
> public:
> void
> aq (char)
> {
> if (s)
> b ();
> }
> };
> class u : public I
> {
> public:
> void
> operator<< (u o (u))
> {
> o (*this);
> }
> u operator<< (void *);
> };
> template
> at
> av (au o)
> {
> o.aq ('\n');
> }
> u ax;
> }
> struct p
> {
> char *ay;
> };
> a::H t;
> void
> ShowHelpListCommands ()
> {
> for (auto c : t)
> a::ax << c.ay << a::av;
> }
Yes, it's very likely my fault. Thanks for reducing the test case. I will
investigate it.
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
--- Comment #6 from Martin Liška ---
And there's sample which started to be reported with Bin's revision r238641:
namespace a {
void b () __attribute__ ((__noreturn__));
template struct d;
template struct d
{
typedef e f;
};
struct g
{
template using i = h *;
};
}
using a::d;
template class k
{
j l;
public:
typename d::f operator* () {}
void operator++ () { ++l; }
j
aa ()
{
return l;
}
};
template
bool
operator!= (k o, k p2)
{
return o.aa () != p2.aa ();
}
struct p;
namespace a {
struct F
{
struct q
{
using ai = g::i;
};
using r = q::ai;
};
class H
{
public:
k begin ();
k end ();
};
int s;
class I
{
public:
void
aq (char)
{
if (s)
b ();
}
};
class u : public I
{
public:
void
operator<< (u o (u))
{
o (*this);
}
u operator<< (void *);
};
template
at
av (au o)
{
o.aq ('\n');
}
u ax;
}
struct p
{
char *ay;
};
a::H t;
void
ShowHelpListCommands ()
{
for (auto c : t)
a::ax << c.ay << a::av;
}
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-07-12
CC||amker at gcc dot gnu.org,
||glisse at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Martin Liška ---
Confirmed, I reduced one test-case:
$ cat pr81408.ii
template class d
{
b e;
public:
int operator* () {}
void operator++ () { ++e; }
b
base ()
{
return e;
}
};
template
bool
operator!= (d i, d j)
{
return i.base () - j.base ();
}
template class k;
template struct m;
template struct m>
{
using l = a *;
};
struct p : m>
{
d begin ();
d end ();
} n;
void
o ()
{
for (auto c : n)
;
}
Which started to be recognized with r242638. And I also noticed the original
unreduced test-case started to be diagnosed with r238641.
That said it's probably better optimizer work that shows more warnings, am I
right?
[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073
--- Comment #11 from Georg-Johann Lay ---
...oops, I missed the PROGMEM in PSTR definition. Should read:
// A string in flash
#define PSTR(str) \
(__extension__({ \
static const char __c[] PROGMEM = (str); \
&__c[0]; \
}))
but still no error.
[Bug tree-optimization/81409] New: Inefficient loops generated from range-v3 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81409
Bug ID: 81409
Summary: Inefficient loops generated from range-v3 code
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
Created attachment 41728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41728&action=edit
Preprocessed file for run_range()
The range-v3 (https://github.com/ericniebler/range-v3) function
long run_range(std::vector const &lengths, long to_find)
{
auto const found_index = ranges::distance(lengths
| ranges::view::transform(ranges::convert_to{})
| ranges::view::partial_sum()
| ranges::view::take_while([=](auto const i) {
return !(to_find < i);
}));
return found_index;
}
is generated as slow code with GCC, needing 3x the time to run compared to the
code generated by LLVM (when compiled with "-O3 -std=c++14 -DNDEBUG"). The
calculation done in run_range() is the equivalent of
long run_forloop(std::vector const &vec, long to_find)
{
long len = vec.end() - vec.begin();
const int *p = &vec[0];
long i, acc = 0;
for (i = 0; i < len; i++) {
acc += p[i];
if (to_find < acc)
break;
}
return i;
}
and LLVM manages to generate similar code for both functions, while GCC seems
to be confused by the run_range() loop and generates extra comparisions and a
somewhat messy code flow...
[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073
--- Comment #10 from Georg-Johann Lay ---
(In reply to Jason Merrill from comment #9)
> Created attachment 41711 [details]
> patch to error on progmem with dynamic init
>
> Does this do what you had in mind?
Some situations are diagnosed, but already something like in this PR passes
your test und dynamically initializes __c in .rodata:
#define PROGMEM __attribute__((__progmem__))
// A string in flash
#define PSTR(str) \
(__extension__({ \
static const char __c[] = (str); \
&__c[0]; \
}))
typedef struct { char id; const char *labl; } menu_t;
const menu_t* setup_Flash (void)
{
static const menu_t menu PROGMEM = { 123, PSTR ("in Flash") };
return &menu;
}
int main(){}
So either this should be diagnosed or deflate similar to
const menu_t* setup_RAM (void)
{
static const menu_t menu PROGMEM = { 123, "in RAM" };
return &menu;
}
[Bug lto/81406] ice in check_die, at dwarf2out.c:6185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81406 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-12 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please provide a pre-processed source file that was used to generate the module. As LTO ABI is not stabilized, it's impossible to bisect.
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #4 from Julian Andres Klode --- Note that apt has 1219 loops, so 134 is almost 11% of the loops causing the warning, compared to about 0.7% (8) before.
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #3 from Julian Andres Klode --- 7.1.0-9 corresponds to "SVN 20170705 (r250006) from the gcc-7-branch."
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #2 from Julian Andres Klode --- Build log with -v: Using built-in specs. COLLECT_GCC=/usr/bin/g++-7 OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.1.0-9' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --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 --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.1.0 (Debian 7.1.0-9) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE a.cc -mtune=generic -march=x86-64 -Wunsafe-loop-optimizations -O2 -fpch-preprocess -o a.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 /usr/include/c++/7/backward /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed a.ii -quiet -dumpbase a.cc -mtune=generic -march=x86-64 -auxbase a -O2 -Wunsafe-loop-optimizations -version -o a.s GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (Debian 7.1.0-9) version 7.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.1.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3681302eda59faba4e53a905eca4bf72 a.cc: In function ‘void ShowHelpListCommands(const std::vector&)’: a.cc:11:24: warning: missed loop optimization, the loop counter may overflow [-Wunsafe-loop-optimizations] for (auto const &c: Cmds) ^~~~ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o a.o a.s GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.28 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wunsafe-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 --- Comment #1 from Julian Andres Klode --- Created attachment 41727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41727&action=edit preprocessed source of a.cc
[Bug c++/81408] New: Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 Bug ID: 81408 Summary: Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6 Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: j...@jak-linux.org Target Milestone: --- Created attachment 41726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41726&action=edit Minimized example Compiling a recent apt with g++-7 causes a lot more unsafe loop optimizations warnings than g++ 6 did (134 vs 8). That's a massive regression. 7.1.0 build log: https://launchpadlibrarian.net/327296659/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz 6.3.0 build log: https://launchpadlibrarian.net/326714445/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz It seems these are for-each kind of loops. I attached a simple minimized example from one of the cases mentioned in the log.
[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400
Martin Liška changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
So there are 2 issue I can see:
1) Using -mstack-protector-guard=tls (which is default for recent glibc) causes
usage of %fs:40 as a canary value. However as it does not cooperate with
__guard_setup it has 0 as canary value. That's reason why your buffer overflow
is not caught (and one needs to assign a non-zero value: data[SMASH_ALIGN]='f';
I don't know how should be responsible for a set-up of the register as it's a
per thread value. Uros can you please help?
2) We have in gcc.c:
#ifndef LINK_SSP_SPEC
#ifdef TARGET_LIBC_PROVIDES_SSP
#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
"|fstack-protector-strong|fstack-protector-explicit:}"
#else
#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
"|fstack-protector-strong|fstack-protector-explicit" \
":-lssp_nonshared -lssp}"
#endif
#endif
That is wrong when one uses:
$ gcc smashme.c -fstack-protector-all -mstack-protector-guard=global
/tmp/ccq3aEcz.o: In function `smashme':
smashme.c:(.text+0xb): undefined reference to `__stack_chk_guard'
smashme.c:(.text+0x59): undefined reference to `__stack_chk_guard'
/tmp/ccq3aEcz.o: In function `main':
smashme.c:(.text+0x7b): undefined reference to `__stack_chk_guard'
smashme.c:(.text+0x94): undefined reference to `__stack_chk_guard'
collect2: error: ld returned 1 exit status
which should be fixed by:
diff --git a/gcc/gcc.c b/gcc/gcc.c
index e8e3d6687c3..0043f86d8d2 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -869,7 +869,8 @@ proper position among the other output files. */
#ifndef LINK_SSP_SPEC
#ifdef TARGET_LIBC_PROVIDES_SSP
#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
- "|fstack-protector-strong|fstack-protector-explicit:}"
+ "|fstack-protector-strong|fstack-protector-explicit:" \
+ "%{mstack-protector-guard=global:-lssp}}"
#else
#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
"|fstack-protector-strong|fstack-protector-explicit" \
[Bug tree-optimization/81388] Incorrect code generation with -O1 -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388 krister.walfridsson at gmail dot com changed: What|Removed |Added CC||krister.walfridsson at gmail dot c ||om --- Comment #5 from krister.walfridsson at gmail dot com --- Comment #1 says that "-fno-strict-overflow Does not effect Pointers", but the manual says for -fstrict-overflow: "This option also allows the compiler to assume strict pointer semantics: given a pointer to an object, if adding an offset to that pointer does not produce a pointer to the same object, the addition is undefined. This permits the compiler to conclude that p + u > p is always true for a pointer p and unsigned integer u. This assumption is only valid because pointer wraparound is undefined, as the expression is false if p + u overflows using twos complement arithmetic." At least I read this as -fno-strict-overflow permit pointer overflow too. Is that incorrect? If so, then I think the manual should be corrected/clarified...
[Bug target/81407] [avr] Diagnose if a variable in progmem needs constructing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81407 Georg-Johann Lay changed: What|Removed |Added Keywords||diagnostic Target||avr Priority|P3 |P5 Severity|normal |enhancement
[Bug target/81407] New: [avr] Diagnose if a variable in progmem needs constructing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81407 Bug ID: 81407 Summary: [avr] Diagnose if a variable in progmem needs constructing. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- avr-g++ might decide to pop up a constructor for a const variable in progmem, shredding the assumption that the object is not written to at run-time. Diagnose such situations as the object will reside in .rodata then instead of in .progmem.data.
[Bug lto/81406] New: ice in check_die, at dwarf2out.c:6185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81406 Bug ID: 81406 Summary: ice in check_die, at dwarf2out.c:6185 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 41725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41725&action=edit x86_64 object module The attached object module, when compiled by recent gcc, does this: $ /home/dcb/gcc/results/bin/gcc -g -flto -shareddp.o Duplicate attributes in DIE: DIE0: DW_TAG_subprogram (0x7f03e39ffd20) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "efidp_node_size.part.0" DW_AT_prototyped: 1 DW_AT_type: die -> 0 (0x7f03e3d30190) DW_AT_artificial: 1 DW_AT_inline: 3 DW_AT_artificial: 1 DIE0: DW_TAG_formal_parameter (0x7f03e39ffd70) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "dn" DW_AT_decl_file: "/home/dcb/rpmbuild/BUILD/efivar-31/src/include/efivar/ef ivar-dp.h" (0) DW_AT_decl_line: 821 DW_AT_type: die -> 0 (0x7f03e396c000) during IPA pass: inline In function ‘efidp_node_size.part.0’: lto1: internal compiler error: in check_die, at dwarf2out.c:6185 0x6e520e check_die ../../trunk/gcc/dwarf2out.c:6185 0x713d35 dwarf2out_abstract_function ../../trunk/gcc/dwarf2out.c:21672 0xbe0c42 expand_call_inline ../../trunk/gcc/tree-inline.c:4923
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #28 from Avi Kivity --- It's a combination of several things: 1. We use antlr to generate a parser. The generated code allocates many local variables in the same function 2. use-after-scope disabled -fstack-reuse=all 3. ASAN is quite liberal with stack padding 4. We also use user-level threads with just 128k of stack The combination of all four overflowed our poor stack.
[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-07-12 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, thanks for the example, I'll take a look.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #27 from Martin Liška --- (In reply to Avi Kivity from comment #26) > Thanks a lot for handling this issue. You're welcome, I'm happy that it's a known issue and I don't have to dig in the source base. It's quite large. Anyhow, do you know why I see the stack overflow with sanitizer? It is a known issue?
[Bug tree-optimization/81403] [8 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403 --- Comment #3 from Marc Glisse --- /* x & C -> x if we know that x & ~C == 0. */ Not clear where it is getting the bogus range/nonzero information from, I thought we had fixed all the places reusing SSA_NAMEs with stale information.
[Bug tree-optimization/81403] [8 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-12 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|wrong code at -O3 |[8 Regression] wrong code ||at -O3 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r247596.
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-12 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/81405] New: [8 Regression] Invalid write of size 2 in line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1514)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81405 Bug ID: 81405 Summary: [8 Regression] Invalid write of size 2 in line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1514) Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- Starting from David's r247548 I see: $ valgrind --leak-check=yes --trace-children=yes gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/init-excess-1.c -Wmissing-braces ... /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/init-excess-1.c:17:1: note: (near initialization for ‘a5[3]’) ==30671== Invalid write of size 2 ==30671==at 0x4C32D53: memmove (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30671==by 0x1414D2E: (anonymous namespace)::line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1514) ==30671==by 0x14171E4: print_trailing_fixits (diagnostic-show-locus.c:1558) ==30671==by 0x14171E4: print_line (diagnostic-show-locus.c:1780) ==30671==by 0x14171E4: diagnostic_show_locus(diagnostic_context*, rich_location*, diagnostic_t) (diagnostic-show-locus.c:1827) ==30671==by 0x6BA9D7: c_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (c-opts.c:166) ==30671==by 0x1411CF8: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:979) ==30671==by 0x141209E: diagnostic_impl(rich_location*, int, char const*, __va_list_tag (*) [1], diagnostic_t) (diagnostic.c:1099) ==30671==by 0x1412597: warning_at_rich_loc(rich_location*, int, char const*, ...) (diagnostic.c:1214) ==30671==by 0x61C031: pop_init_level(unsigned int, int, obstack*, unsigned int) (c-typeck.c:8069) ==30671==by 0x6474B9: c_parser_braced_init(c_parser*, tree_node*, bool, obstack*) (c-parser.c:4443) ==30671==by 0x64846C: c_parser_initializer(c_parser*) (c-parser.c:4365) ==30671==by 0x65575D: c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, oacc_routine_data*, bool*) (c-parser.c:1933) ==30671==by 0x65E4C3: c_parser_external_declaration(c_parser*) (c-parser.c:1470) ==30671== Address 0x644247c is 0 bytes after a block of size 12 alloc'd ==30671==at 0x4C2E2AF: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30671==by 0x147BB4C: xrealloc (xmalloc.c:179) ==30671==by 0x1414D01: ensure_capacity (diagnostic-show-locus.c:1432) ==30671==by 0x1414D01: (anonymous namespace)::line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1513) ==30671==by 0x14171E4: print_trailing_fixits (diagnostic-show-locus.c:1558) ==30671==by 0x14171E4: print_line (diagnostic-show-locus.c:1780) ==30671==by 0x14171E4: diagnostic_show_locus(diagnostic_context*, rich_location*, diagnostic_t) (diagnostic-show-locus.c:1827) ==30671==by 0x6BA9D7: c_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (c-opts.c:166) ==30671==by 0x1411CF8: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:979) ==30671==by 0x141209E: diagnostic_impl(rich_location*, int, char const*, __va_list_tag (*) [1], diagnostic_t) (diagnostic.c:1099) ==30671==by 0x1412597: warning_at_rich_loc(rich_location*, int, char const*, ...) (diagnostic.c:1214) ==30671==by 0x61C031: pop_init_level(unsigned int, int, obstack*, unsigned int) (c-typeck.c:8069) ==30671==by 0x6474B9: c_parser_braced_init(c_parser*, tree_node*, bool, obstack*) (c-parser.c:4443) ==30671==by 0x64846C: c_parser_initializer(c_parser*) (c-parser.c:4365) ==30671==by 0x65575D: c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, oacc_routine_data*, bool*) (c-parser.c:1933) ... And similar errors that eventually lead to memory corruption.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #26 from Avi Kivity --- Thanks a lot for handling this issue.
