[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578 --- Comment #3 from Zhendong Su su at cs dot ucdavis.edu --- (because (c ^ 0L) -1 is true in 64-bit, so the code returns) Or perhaps not, as -1 should actually be promoted to signed long, so the comparison becomes 0L -1L, and is thus false and triggers the undefined behavior?
[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- But why do you think (c ^ 0L) -1 is 1 for 64-bit mode? From C99, 6.3.1.8, different paragraphs apply: Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type. Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. For 64-bit mode, the first cited paragraph applies, because 64-bit long int can represent all of values of 32-bit unsigned int, so it is (((long int) 0) ^ 0L) -1L and thus 0L -1L and therefore false. For 32-bit mode, the second cited paragraph applies, because 32-bit long int can't represent all of values of 32-bit unsigned int, so it is (((unsigned long int) 0) ^ 0UL) -1UL and thus 0UL -1UL and therefore true.
[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578 --- Comment #5 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #4) But why do you think (c ^ 0L) -1 is 1 for 64-bit mode? From C99, 6.3.1.8, different paragraphs apply: Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type. Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. For 64-bit mode, the first cited paragraph applies, because 64-bit long int can represent all of values of 32-bit unsigned int, so it is (((long int) 0) ^ 0L) -1L and thus 0L -1L and therefore false. For 32-bit mode, the second cited paragraph applies, because 32-bit long int can't represent all of values of 32-bit unsigned int, so it is (((unsigned long int) 0) ^ 0UL) -1UL and thus 0UL -1UL and therefore true. Thanks Jakub! Sorry for the invalid report.
[Bug tree-optimization/54733] Missing opportunity to optimize endian independent load/store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54733 Thomas Preud'homme thomas.preudhomme at arm dot com changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #2 from Thomas Preud'homme thomas.preudhomme at arm dot com --- A patch to fix this is currently under discussion on gcc-patches at: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00925.html
[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-19 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r199779.
[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32386 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32386action=edit gcc49-pr60572.patch Untested fix. Whether you want to fix it this way not sure.
[Bug lto/60571] FTBFS on hurd-i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60571 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 19 07:18:46 2014 New Revision: 208675 URL: http://gcc.gnu.org/viewcvs?rev=208675root=gccview=rev Log: PR lto/60571 * lto.c (wait_for_child): Define WCONTINUED if not defined to 0. Fix formatting. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug lto/60571] FTBFS on hurd-i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60571 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/60054] [c++1y] ICE with auto* cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60054 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Both testcases fixed by r208415.
[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, since r208415 is rejected as invalid.
[Bug c++/59114] [c++1y] ICE using auto in conversion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59114 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- This one got fixed with r208414.
[Bug c++/60579] New: Segmentation fault on variadic 'using' within variadic template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60579
Bug ID: 60579
Summary: Segmentation fault on variadic 'using' within variadic
template class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: charlie at charliedyson dot net
The following causes a segfault on gcc 4.8.1 and earlier versions:
template typename... Args
struct X
{
template typename Head, typename... Tail
using First = Head;
using Y = FirstArgs...;
};
Steps to reproduce: http://goo.gl/bBYNJU (GCC Explorer)
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32387 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32387action=edit unreduced testcase I've narrowed it down to a single file. Can't say I understand the issue fully yet. Bad: x4 kparts # g++ -c -O2 part.ii nm part.o | grep N6KParts13ReadWritePartD 4d50 T _ZN6KParts13ReadWritePartD0Ev 4d00 T _ZN6KParts13ReadWritePartD1Ev 4cd0 T _ZN6KParts13ReadWritePartD2Ev Good: x4 kparts # /var/tmp/gcc_test/usr/local/bin/g++ -c -O2 part.ii nm part.o | grep N6KParts13ReadWritePartD 4d70 T _ZN6KParts13ReadWritePartD0Ev 4d00 T _ZN6KParts13ReadWritePartD1Ev 4cd0 T _ZN6KParts13ReadWritePartD2Ev 4da0 T _ZThn16_N6KParts13ReadWritePartD0Ev 4d60 T _ZThn16_N6KParts13ReadWritePartD1Ev 4d90 T _ZTv0_n24_N6KParts13ReadWritePartD0Ev 4d50 T _ZTv0_n24_N6KParts13ReadWritePartD1Ev
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- --- part_good.s 2014-03-19 08:57:10.100342064 +0100 +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 @@ -13466,49 +13466,10 @@ .text .LHOTE151: .section.text.unlikely + .align 2 .LCOLDB152: .text .LHOTB152: - .p2align 4,,15 - .globl _ZTv0_n24_N6KParts13ReadWritePartD1Ev - .type _ZTv0_n24_N6KParts13ReadWritePartD1Ev, @function -_ZTv0_n24_N6KParts13ReadWritePartD1Ev: -.LFB6687: - .cfi_startproc - movq(%rdi), %r10 - addq-24(%r10), %rdi - jmp _ZN6KParts13ReadWritePartD1Ev - .cfi_endproc -.LFE6687: - .size _ZTv0_n24_N6KParts13ReadWritePartD1Ev, .-_ZTv0_n24_N6KParts13ReadWritePartD1Ev - .section.text.unlikely -.LCOLDE152: - .text -.LHOTE152: - .section.text.unlikely -.LCOLDB153: - .text -.LHOTB153: - .p2align 4,,15 - .globl _ZThn16_N6KParts13ReadWritePartD1Ev - .type _ZThn16_N6KParts13ReadWritePartD1Ev, @function -_ZThn16_N6KParts13ReadWritePartD1Ev: -.LFB6688: - .cfi_startproc - subq$16, %rdi - jmp _ZN6KParts13ReadWritePartD1Ev - .cfi_endproc -.LFE6688: - .size _ZThn16_N6KParts13ReadWritePartD1Ev, .-_ZThn16_N6KParts13ReadWritePartD1Ev - .section.text.unlikely -.LCOLDE153: - .text -.LHOTE153: - .section.text.unlikely - .align 2 -.LCOLDB154: - .text -.LHOTB154: .align 2 .p2align 4,,15 .globl _ZN6KParts13ReadWritePartD0Ev @@ -13529,53 +13490,14 @@ .LFE5572: .size _ZN6KParts13ReadWritePartD0Ev, .-_ZN6KParts13ReadWritePartD0Ev .section.text.unlikely -.LCOLDE154: - .text -.LHOTE154: - .section.text.unlikely -.LCOLDB155: - .text -.LHOTB155: - .p2align 4,,15 - .globl _ZTv0_n24_N6KParts13ReadWritePartD0Ev - .type _ZTv0_n24_N6KParts13ReadWritePartD0Ev, @function -_ZTv0_n24_N6KParts13ReadWritePartD0Ev: -.LFB6689: - .cfi_startproc - movq(%rdi), %r10 - addq-24(%r10), %rdi - jmp _ZN6KParts13ReadWritePartD0Ev - .cfi_endproc -.LFE6689: - .size _ZTv0_n24_N6KParts13ReadWritePartD0Ev, .-_ZTv0_n24_N6KParts13ReadWritePartD0Ev - .section.text.unlikely -.LCOLDE155: - .text -.LHOTE155: - .section.text.unlikely -.LCOLDB156: - .text -.LHOTB156: - .p2align 4,,15 - .globl _ZThn16_N6KParts13ReadWritePartD0Ev - .type _ZThn16_N6KParts13ReadWritePartD0Ev, @function -_ZThn16_N6KParts13ReadWritePartD0Ev: -.LFB6690: - .cfi_startproc - subq$16, %rdi - jmp _ZN6KParts13ReadWritePartD0Ev - .cfi_endproc -.LFE6690: - .size _ZThn16_N6KParts13ReadWritePartD0Ev, .-_ZThn16_N6KParts13ReadWritePartD0Ev - .section.text.unlikely ... .section.rodata .align 32 .type _ZZN6KParts13ReadWritePart11setModifiedEbE19__PRETTY_FUNCTION__, @object @@ -18015,8 +17937,8 @@ .quad _ZNK6KParts13ReadWritePart10metaObjectEv .quad _ZN6KParts13ReadWritePart11qt_metacastEPKc .quad _ZN6KParts13ReadWritePart11qt_metacallEN11QMetaObject4CallEiPPv - .quad _ZN6KParts13ReadWritePartD1Ev - .quad _ZN6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZN7QObject5eventEP6QEvent .quad _ZN7QObject11eventFilterEPS_P6QEvent .quad _ZN7QObject10timerEventEP11QTimerEvent @@ -18050,8 +17972,8 @@ .quad 16 .quad -16 .quad _ZTIN6KParts13ReadWritePartE - .quad _ZThn16_N6KParts13ReadWritePartD1Ev - .quad _ZThn16_N6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZN6KParts8PartBase16setComponentDataERK14KComponentData .quad _ZN6KParts8PartBase16setComponentDataERK14KComponentDatab .quad 0 @@ -18070,8 +17992,8 @@ .quad -32 .quad -32 .quad _ZTIN6KParts13ReadWritePartE - .quad _ZTv0_n24_N6KParts13ReadWritePartD1Ev - .quad _ZTv0_n24_N6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual .quad _ZNK13KXMLGUIClient6actionERK11QDomElement .quad _ZNK13KXMLGUIClient16actionCollectionEv .quad _ZNK13KXMLGUIClient13componentDataEv @@ -18137,5 +18059,5 @@ _ZN6KParts4Part25staticMetaObjectExtraDataE: .quad 0 .quad _ZN6KParts4Part18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv - .ident GCC: (GNU) 4.9.0 20140314 (experimental) + .ident GCC: (GNU) 4.9.0 20140318 (experimental) .section.note.GNU-stack,,@progbits
[Bug c++/60579] Segmentation fault on variadic 'using' within variadic template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60579 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This got fixed with r201469 on the trunk.
[Bug target/60580] New: aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580 Bug ID: 60580 Summary: aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer))) Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: chemobejk at gmail dot com Created attachment 32388 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32388action=edit Example C code used i the command lines We have a piece of code that we compile with -fomit-frame-pointer. The exception is one low-level function that *MUST NOT* rely on the SP register, i.e. that one function must be compiled with -fno-omit-frame-pointer. This works fine with the GCC ARM backend, i.e. we have in the C code the following function attribute: /* * This function calls XXX(), which modifies SP. This is incompatible to * -fomit-frame-pointer generated code as SP is used to access the frame. */ __attribute__ ((optimize(no-omit-frame-pointer))) void some_low_level_function() We are now trying to compile that piece of code with the aarch64 backend and get incorrect code that uses SP to access the frame. I tried with the following pre-compiled aarch64 toolchains: Linaro release 2014.02: COLLECT_GCC=gcc-linaro-aarch64-linux-gnu-4.8-2014.02_linux/bin/aarch64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/workarea/stefanb/playground/aarch64/gcc-linaro-aarch64-linux-gnu-4.8-2014.02_linux/bin/../libexec/gcc/aarch64-linux-gnu/4.8.3/lto-wrapper Target: aarch64-linux-gnu Configured with: /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/gcc-linaro-4.8-2014.02/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=aarch64-linux-gnu --prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install --with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc --enable-languages=c,c++,fortran --disable-multilib --enable-multiarch --with-arch=armv8-a --with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2014.02 - Linaro GCC 2014.02' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp --with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc --enable-c99 --enable-long-long Thread model: posix gcc version 4.8.3 20140203 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.02 - Linaro GCC 2014.02) Android AOSP: COLLECT_GCC=prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.8/bin/aarch64-linux-android-gcc COLLECT_LTO_WRAPPER=/workarea/stefanb/repos/tmake-only/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.8/bin/../libexec/gcc/aarch64-linux-android/4.8/lto-wrapper Target: aarch64-linux-android Configured with: /tmp/AOSP-toolchain/build/../gcc/gcc-4.8/configure --prefix=/tmp/toolchain-build-aarch64-linux-4.8/prefix --target=aarch64-linux-android --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --with-gmp=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --with-mpfr=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --with-mpc=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --with-cloog=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --with-isl=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --with-ppl=/tmp/toolchain-build-aarch64-linux-4.8/temp-install --disable-ppl-version-check --disable-cloog-version-check --disable-isl-version-check --enable-cloog-backend=isl --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-libssp --enable-threads --disable-nls --disable-libmudflap --disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --disable-tls --disable-libitm --enable-initfini-array --disable-nls --prefix=/tmp/toolchain-build-aarch64-linux-4.8/prefix --with-sysroot=/tmp/toolchain-build-aarch64-linux-4.8/prefix/sysroot --with-binutils-version=2.23
[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Will look into it.
[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561 --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Matthieu Patou from comment #3) volatile proto_tree *tmptree = NULL; Try proto_tree * volatile tmptree = NULL; It's the variable itself that needs to be volatile, not the memory it points to.
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug c/60581] New: gcc doesn't isssue a strict aliasing warning on a code that seems to break it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60581
Bug ID: 60581
Summary: gcc doesn't isssue a strict aliasing warning on a code
that seems to break it
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: galtgendo at o2 dot pl
The problem is described here: https://bugs.gentoo.org/show_bug.cgi?id=505026
The code to trigger comes from a launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1072650
As you may notice, it's acros distros and affects many compiler versions
(confirmed for 4.6.3 on ubuntu, 4.7.3 and 4.8.2 on Gentoo).
Following code (AFAICT) violates strict aliasing rules:
#include stdio.h
struct psuedo_hdr
{
int saddr;
int daddr;
char zero;
char protocol;
short len;
} __attribute__((packed));
int main()
{
unsigned int i;
unsigned int sum = 0;
struct psuedo_hdr hdr;
hdr.saddr = 0xaabbccdd;
hdr.daddr = 0x11223344;
hdr.zero = 0;
hdr.protocol = 6;
hdr.len = 2;
for (i = 0; i sizeof(hdr); i += 2)
sum += *(short *)((char *)(hdr) + i);
printf(0x%x\n, sum);
return 0;
}
however, '-O2 -Wall' doesn't result in the strict aliasing warning.
[Bug tree-optimization/60559] [4.9 Regression] g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 19 09:13:32 2014 New Revision: 208676 URL: http://gcc.gnu.org/viewcvs?rev=208676root=gccview=rev Log: PR tree-optimization/60559 * vectorizable_mask_load_store): Replace scalar MASK_LOAD with build_zero_cst assignment. * g++.dg/vect/pr60559.cc: New test. Added: trunk/gcc/testsuite/g++.dg/vect/pr60559.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Mar 19 09:22:15 2014 New Revision: 208677 URL: http://gcc.gnu.org/viewcvs?rev=208677root=gccview=rev Log: 2014-03-19 Richard Biener rguent...@suse.de PR lto/59543 * lto-streamer-in.c (input_function): In WPA stage do not drop debug stmts. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c
[Bug fortran/60582] New: gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582 Bug ID: 60582 Summary: gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dominiq at lps dot ens.fr, jvdelisle at gcc dot gnu.org Host: i386-pc-solaris2.9 Target: i386-pc-solaris2.9 Build: i386-pc-solaris2.9 As already reported in PR fortran/60128, the new gfortran.dg/fmt_en.f90 testcase FAILs on Solaris 9/x86: FAIL: gfortran.dg/fmt_en.f90 -O0 execution test FAIL: gfortran.dg/fmt_en.f90 -O1 execution test FAIL: gfortran.dg/fmt_en.f90 -O2 execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -g execution test FAIL: gfortran.dg/fmt_en.f90 -Os execution test Some analysis has already been done in that PR; I won't repeat it here. One additional data point: unlike Solaris 10+, Solaris 9 lacks fenv.h. Rainer
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/60582] gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- Rainer, can you test the following patch? --- _clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-04 17:51:04.0 +0100 +++ work/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-18 18:08:22.0 +0100 @@ -128,6 +128,9 @@ contains else if (i == 3) then write(s, fmt) real(x,kind=j(3)) else if (i == 4) then +! skip if real(16) are not rounded to nearest (Solaris 9/x86) +write(s, '(F3.1)') real(9.4905,kind=j(4)) +if (s /= '9.5') exit write(s, fmt) real(x,kind=j(4)) end if n_tst = n_tst + 1 This passes on both i386-pc-solaris2.9 and i386-pc-solaris2.11. Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #21) We can xfail the test case if we are certain of the problem. What I don't see is how to xfail only some tests for real(16). Anyway, Rainer could open a new PR for the solaris issue and close this one as FIXED? What we should do is break the test case into two test cases one for quad16 and the other for the rest. Then we XFAIL the quad16 one for solaris. I think we Agreed, that's better than silently exiting a test in certain conditions, making it seem that it works while it actually doesn't. also need a new PR that is platform specific. There may be some configury magic that needs to be done for Solaris to work correctly. I've now filed PR fortran/60582. Rainer
[Bug libstdc++/54316] [C++11] move constructor for stringstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- That would be very welcome, thanks, Howard. We hope to complete the C++11 library for the next major release after 4.9, but there's still quite a lot to do. I haven't even analysed what we need to do to add move support to our streams (maybe Paolo has done).
[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I can't reproduce it, in any case, this seems to have been broken before as well and starting with 208668 I get valgrind error about memcpy with overlapping arguments. The bug seems in: class.5._data.dim[0 ...] = at.dim[0 ...]; at apparently has dim FIELD_DECL as array of 2 (24-byte) structs, i.e. 48 bytes long, while the ARRAY_RANGE_REF around it accesses 7 24-byte structs, i.e. 168 bytes.
[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
struct A
{
void foo ();
struct
{
int i;
void bar () { i = 0; }
} s;
};
void A::foo () { s.bar (); }
[Bug c++/60574] [4.9 Regression] [c++1y] ICE with deduced return type in virtual function and LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60574 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, so maybe we should reject it again?
[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug c/60581] gcc doesn't isssue a strict aliasing warning on a code that seems to break it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60581 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||alias, diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The strict-aliasing warnings are broken - they are too easily to silence (the (char *) cast for example). Generally warning for TBAA violations is very hard if you want to avoid gazillions of false positives or gazillions of false negatives. The present warning code delivers neither :/
[Bug tree-optimization/60577] [4.9 Regression] inefficient FDO instrumentation code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|inefficient FDO |[4.9 Regression] |instrumentation code|inefficient FDO ||instrumentation code Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
at's dim array is created by:
#6 0x006fc242 in gfc_get_array_descriptor_base (dimen=2, codimen=0,
restricted=true, akind=GFC_ARRAY_ALLOCATABLE)
at ../../gcc/fortran/trans-types.c:1754
where the dimen=2 causes the dim array to be sized with 2 elements only, while
the larger ARRAY_REF comes from:
#4 0x00e58b85 in build4_stat (code=ARRAY_RANGE_REF, tt=array_type
0x719f0540, arg0=component_ref 0x71a08510,
arg1=integer_cst 0x718afa00, arg2=tree 0x0, arg3=tree 0x0) at
../../gcc/tree.c:4241
#5 0x006a8a72 in build4_stat_loc (loc=2692, code=ARRAY_RANGE_REF,
type=array_type 0x719f0540, arg0=component_ref 0x71a08510,
arg1=integer_cst 0x718afa00, arg2=tree 0x0, arg3=tree 0x0) at
../../gcc/tree.h:3499
#6 0x006a98ff in class_array_data_assign (block=0x7fffd810,
lhs_desc=component_ref 0x71a08390,
rhs_desc=var_decl 0x71a052f8 at, lhs_type=true) at
../../gcc/fortran/trans-expr.c:318
#7 0x006a9ef5 in gfc_conv_derived_to_class (parmse=0x7fffd9a0,
e=0x1cd0640, class_ts=..., vptr=tree 0x0, optional=false,
optional_alloc_ptr=false) at ../../gcc/fortran/trans-expr.c:427
#8 0x006b3d51 in gfc_conv_procedure_call (se=0x7fffdbe0,
sym=0x1ccc570, args=0x1c63760, expr=0x0, append_args=0x0)
at ../../gcc/fortran/trans-expr.c:4039
The bug is in there already in r189800:
./f951.189800 -quiet -O2 assumed_rank_7.f90 -mstringop-strategy=libcall;
gfortran -o assumed_rank_7{,.s}; valgrind ./assumed_rank_7; echo $?
==7529== Memcheck, a memory error detector
==7529== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7529== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==7529== Command: ./assumed_rank_7
==7529==
==7529== Source and destination overlap in memcpy(0xfff0001b8, 0xfff000168,
168)
==7529==at 0x4A0A403: memcpy@@GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7529==by 0x400F5B: MAIN__ (in /usr/src/gcc-test/obj/gcc/assumed_rank_7)
==7529==by 0x4007AC: main (in /usr/src/gcc-test/obj/gcc/assumed_rank_7)
and r189600 still rejected this code, so to me this doesn't look like a
regression, but miscompilation from the day one when this particular feature
has been enabled.
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org --- Good job reducing the testcase to something this small! Anyway, Jakub's analysis of what is going on is still correct and all the high level decisions that we do are IMHO correct too. The invocation of symtab_remove_unreachable_symbols that removes the callers is called with before_inlining_p set to false, even though that is not technically right, we are still in the middle of inlining because we are about to inline functions which are called only once. But the comment in function ipa_inline says this is deliberate because it helps to find the functions which are only called once. However, this means that when symtab_remove_unreachable_symbols correctly figures out that we can devirtualize to the offending thunk, it assumes that cannot lead to any further inlining. Because the thunk is keyed in another compilation unit, it decides it only needs to keep the symtab node but not the body. In its terminology, the node is in the boundary. The way the function cripples these boundary nodes is actually the problem because it removes all callees but not the thunk flag. This leaves us with a thunk with no callee, something that should not happen (and there is even a bit in the call graph verifier that checks it). Later on, we do perform this devirtualization during inlining of functions only called once and connect the crippled thunk to the call graph. The first time we want to follow through it, we segfault. I believe that we do not want to allow thunks with no callees. This would mean changing every user of cgraph_function_node so that it can cope with NULL return value and that is ugly and inconvenient. This leaves us with two options. Either we make symtab_remove_unreachable_symbols keep callees of thunks when it keeps the thunk or we simply clear the thunk_p flag. Given that thunks and aliases are quite similar and we do clear the alias flag, and that this should only ever affect nodes that we are not going to output, I tend to believe the second approach is OK and of course it is much simpler. But before I propose the following fix on the mailing list, I'll try to build some big C++ application with it: diff --git a/gcc/ipa.c b/gcc/ipa.c index 572dba1..164de0d 100644 --- a/gcc/ipa.c +++ b/gcc/ipa.c @@ -488,6 +488,7 @@ symtab_remove_unreachable_nodes (bool before_inlining_p, FILE *file) node-definition = false; node-cpp_implicit_alias = false; node-alias = false; + node-thunk.thunk_p = false; node-weakref = false; if (!node-in_other_partition) node-local.local = false;
[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||nathan at acm dot org
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
In 4.6 for some unknown reason we are able to disambiguate
*.LPBX1[0] and p_3(D)-buf and *D.1606_14
we built the static decls with !TREE_ADDRESSABLE, but starting with
4.7 we unconditionally set TREE_ADDRESSABLE on the decl (which formerly
was only set in case we asked for the address of it via
tree_coverage_counter_addr).
This happened with the big re-org in r181105 but undoing that change
does not fix the regression. This is because the TREE_ADDRESSABLE
flag is set again in canonicalize_constructor_val:
#0 0x00932775 in canonicalize_constructor_val (
cval=addr_expr 0x76d74900, from_decl=tree 0x0)
at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:207
#1 0x00798015 in record_reference (tp=0x76d73698,
walk_subtrees=0x7fffd858, data=0x7fffdb50)
at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:62
#2 0x00e6859f in walk_tree_1 (tp=0x76d73698,
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50,
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10921
#3 0x00e6892c in walk_tree_1 (tp=0x76d736d0,
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50,
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#4 0x00e6892c in walk_tree_1 (tp=0x76d78808,
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50,
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#5 0x00e6892c in walk_tree_1 (tp=0x76d788a0,
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50,
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#6 0x00798d82 in record_references_in_initializer (
decl=var_decl 0x76d78850 __gcov_.access_buf, only_vars=false)
at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:435
#7 0x00eac7fa in varpool_analyze_node (node=0x76d498f0)
at /space/rguenther/src/svn/trunk/gcc/varpool.c:398
thus we _do_ take the address of the variable, from the global
constructor of __gcov.access_buf which looks like
{.D.1783=*.LPBX0, .D.1784=1, .D.1785=4186437761, .D.1786=449688241,
.D.1787={{.D.1780=3, .D.1781=__gcov0.access_buf}, {.D.1780=1,
.D.1781=__gcov8.access_buf}}}
thus indeed p-buf may point to __gcov0.access_buf[1] and we can't optimize
those accesses. This object was simply not present in GCC 4.6 and thus
TREE_ADDRESSABLE was never set and thus we could optimize this.
Which means the revision cited doesn't cause the regression (I highly doubt
so at least), but instead whoever added code to build that record or
whoever added code to record references in initializers (and set
TREE_ADDRESSABLE in that path... - coverage.c fails to do that and builds
a lot of addresses from the counters in places).
The idea of canonicalize_constructor_value is that the result will end up
in actual stmts, thus the addressable flag is important. In this case
we only record references for the IPA references struct - thus setting
the flag there isn't important (well, that's not entirely true ... alias
disambiguation depends on the order of processing functions then).
Fixing both fixes the regression.
Index: gcc/coverage.c
===
--- gcc/coverage.c (revision 208642)
+++ gcc/coverage.c (working copy)
@@ -466,6 +466,8 @@ tree_coverage_counter_addr (unsigned cou
gcc_assert (no fn_n_ctrs[counter] - fn_b_ctrs[counter]);
no += fn_b_ctrs[counter];
+ TREE_ADDRESSABLE (fn_v_ctrs[counter]) = 1;
+
/* no here is an array index, scaled to bytes later. */
return build_fold_addr_expr (build4 (ARRAY_REF, gcov_type_node,
fn_v_ctrs[counter],
@@ -720,7 +722,6 @@ build_var (tree fn_decl, tree type, int
memcpy (buf + len, fn_name, fn_name_len + 1);
DECL_NAME (var) = get_identifier (buf);
TREE_STATIC (var) = 1;
- TREE_ADDRESSABLE (var) = 1;
DECL_ALIGN (var) = TYPE_ALIGN (type);
return var;
Index: gcc/gimple-fold.h
===
--- gcc/gimple-fold.h (revision 208642)
+++ gcc/gimple-fold.h (working copy)
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.
#ifndef GCC_GIMPLE_FOLD_H
#define GCC_GIMPLE_FOLD_H
+extern tree canonicalize_constructor_val_1 (tree, tree, bool);
extern tree canonicalize_constructor_val (tree, tree);
extern tree get_symbol_constant_value (tree);
extern void gimplify_and_update_call_from_tree (gimple_stmt_iterator *, tree);
Index:
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- This is just totally broken and not supportable with LTO. We'd need to amend toplevel asm syntax to list defined and used symbols, but that doesn't fix existing uses. The proper fix is to excempt these files from LTO or move those assembler functions to separate TUs (preferably assembler TUs...). Honza also had the idea of trying to parse the assembler string for obvious symbol definitions / uses.
[Bug c++/60583] New: Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583
Bug ID: 60583
Summary: Garbled data, temporary bound ... only persists until
the constructor exits, fine with clang++
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreaskem at web dot de
Created attachment 32389
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32389action=edit
Problematic code
Hello,
I have a problem with the following code (boiled down from a larger source file
exhibiting the problem):
//
#include iostream
using namespace std;
struct Vector {
double x;
double y;
double z;
};
class Baz {
private:
Vector r;
Vector u;
public:
Baz(const Vector p, const Vector v) : r{p.x,p.y,p.z}, u{v.x,v.y,v.z} {}
const Vector get_u() const {
return(u);
};
void write() const {
cout r: r.x , r.y , r.z ; u: u.x ,
u.y , u.z endl;
};
};
class Foo {
private:
const Baz b;
public:
Foo(const Baz b_) : b{b_} {}
void bar();
};
void Foo::bar() {
b.write();
int iters{10};
b.write();
}
int main(void) {
Baz b{Vector{0.5, 0.5, 0.5}, Vector{1e6, 0.1, 0.1}};
Foo f{b};
f.bar();
}
//
Compiling this with
---
$ g++ -Wall -Wextra -std=c++11 ~/test.cpp
---
leads to the following warnings:
---
***test.cpp: In constructor ‘Foo::Foo(const Baz)’:
***test.cpp:33:27: warning: a temporary bound to ‘Foo::b’ only persists until
the constructor exits [-Wextra]
***test.cpp: In member function ‘void Foo::bar()’:
***test.cpp:41:6: warning: unused variable ‘iters’ [-Wunused-variable]
---
and running the program shows that the data is garbled:
---
$ ./a.out
r: 6.95315e-310,2.07351e-317,0.5; u: 6.95315e-310,0.1,0.1
r: 6.95315e-310,2.07352e-317,0.5; u: 6.95315e-310,0.1,2.24932e-313
---
Using b(b_) instead of b{b_} seems to fix the first warning and the output. I
don't quite understand what is happening here. Moreover, clang++ (3.3 or 3.4)
does not print such a warning (it only complains about the unused iters
variable) and the output is not garbled:
---
$ clang++ -Wall -Wextra -std=c++11 ~/test.cpp; ./a.out
***test.cpp:41:6: warning: unused variable 'iters' [-Wunused-variable]
int iters{10};
^
1 warning generated.
r: 0.5,0.5,0.5; u: 1e+06,0.1,0.1
r: 0.5,0.5,0.5; u: 1e+06,0.1,0.1
---
What is going on here?
I tried two gcc versions, 4.7.2 and 4.8.2.
gcc version 4.7.2 (Debian 4.7.2-5)
(I am currently at work and have to use gcc 4.7.2 to create the .ii file
attached to my report)
I first noticed the problem on my home computer with
gcc version 4.8.2 20140206 (prerelease) (GCC)
Details:
gcc version 4.8.2 20140206 (prerelease) (GCC)
gcc version 4.7.2 (Debian 4.7.2-5)
clang version 3.4 (tags/RELEASE_34/final)
clang version 3.3 (tags/RELEASE_33/final)
Linux 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux
[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Works for me - any more specifics? Host/target?
[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- So - if we delay marking any decl addressable during IPA reference recording then we need an IPA pass that computes whether any of the taken IPA_REF_ADDR may leak into the IL. We need to do that conservatively before any alias queries (thus eventually again at WPA stage to optimize more). So if there isn't any reference to __gcov_.access_buf inside the program this would make us optimize things again. But there is one from .LPBX1 in the testcase which is refered to from .LPBX0 which is refered from _GLOBAL__sub_I_65535_0_access_buf, so it doesn't help ... (and it seems it really is necessary to have those addresses) Considering LTO-ing libgcov there is no way we can magically mark those decls to be disregarded from alias analysis either. Which leaves the possibility of more cleverly instrumenting the program in the first place ...
[Bug c++/60584] New: std::vector::emplace_back(...) use move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584 Bug ID: 60584 Summary: std::vector::emplace_back(...) use move constructor Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ruslan at mullakh dot com Created attachment 32390 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32390action=edit sample code the attached peace of code does not compile. complains on deleted move constructor. clang compile this sample, and as far as I understand standard it is valid c++11. build cmd: g++-4.8 -std=c++11 /tmp/test.cpp
[Bug c++/60584] std::vector::emplace_back(...) use move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584 --- Comment #1 from Ruslan Mullakhmetov ruslan at mullakh dot com --- Created attachment 32391 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32391action=edit compiler output
[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) Which leaves the possibility of more cleverly instrumenting the program in the first place ... Which shouldn't be so hard as we are in SSA form and have loop structures set up. But it's of course old code (profile.c:branch_prob) which was written with only a CFG in mind. Unfortunately the code chooses to instrument a non-latch edge in the testcase (loop latches would have been easy to special-case in gimple_gen_edge_profiler). This is the other edge out of a block with a loop exit - so we can special-case single-exit loops that have such edge instrumented where the edge source dominates the loop latch. Or find some even more clever way of placing the loads / stores (you can always use a scalar as counter and load/store in a dominating / post-dominating block of course, but that may have detrimental effects on register pressure ...). Maybe still do that, but only if the counter update is in a loop. Note that applying store motion here may introduce no-op load/store which may have issues with thread safety.
[Bug c++/60585] New: Virtual function related memory access errors with multiple virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Bug ID: 60585 Summary: Virtual function related memory access errors with multiple virtual inheritance Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Created attachment 32392 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32392action=edit Simplified C++ test example The attached reduced example causes valgrind to complain about access to uninitialized value when built with gcc-4.9.0 20140318 on Linux (both i86 and x86_64, included output is from 32 bit version): andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -O2 -Wall -Wextra virtual.cpp andpav@andris-HP-Z230:~/Tests/2014-03-18$ valgrind ./a.out ==10812== Memcheck, a memory error detector ==10812== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==10812== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==10812== Command: ./a.out ==10812== ==10812== Use of uninitialised value of size 4 ==10812==at 0x80484C6: virtual thunk to F::f() const (in /home/andpav/Tests/2014-03-18/a.out) ==10812==by 0x8048379: main (in /home/andpav/Tests/2014-03-18/a.out) ==10812== ==10812== ==10812== HEAP SUMMARY: ==10812== in use at exit: 0 bytes in 0 blocks ==10812== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==10812== ==10812== All heap blocks were freed -- no leaks are possible ==10812== ==10812== For counts of detected and suppressed errors, rerun with: -v ==10812== Use --track-origins=yes to see where uninitialised values come from ==10812== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -v Using built-in specs. COLLECT_GCC=g++-4.9 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.9.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.9-20140318/configure --program-suffix=-4.9 --enable-languages=c,c++ --enable-lto Thread model: posix gcc version 4.9.0 20140318 (experimental) (GCC) There are also ocasional crashes (SIGSEGV) in real software from which the reduced example has been created. Also reproduced with gcc-4.8 (Fedora 20 x86_64 and Ubuntu 13.10 i686) and gcc-4.7 (Ubuntu-13.10 i686). Does not happen with gcc-4.6 (Ubuntu 12.04) Also specifying -fno-inline-small-functions together with -O2 or -O3 for affected gcc versions make the problem not happen (both reduced example and real software)
[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Works for me - any more specifics? Host/target? gcc version 4.9.0 20140319, r208679. Target: x86_64-unknown-linux-gnu CentOS 6.5, glibc-2.12-1.132, binutils-2.20.51.0.2-5.36 Seems to be a problem of Binutils. If I use the current Binutils from binutils-gdb git (= 2.24.51.20140319), it works. The question is whether one can do something about it instead of ICEing. And whether the other PRs (PR56775, PR56963 and PR57715) might have the same problem.
[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Mar 19 12:25:04 2014 New Revision: 208681 URL: http://gcc.gnu.org/viewcvs?rev=208681root=gccview=rev Log: PR sanitizer/60569 * ubsan.c (ubsan_type_descriptor): Check that DECL_NAME is nonnull before accessing it. testsuite/ * g++.dg/ubsan/pr60569.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr60569.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32393 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32393action=edit hack Like this (hack alert). Applies store motion one level for a restricted set of loops. Requires us to add preheaders and record exits (and disambiguate multiple latches) and compute dominators.
[Bug middle-end/60586] New: [Cilk+] Parameters evaluation happens inside spawn worker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586
Bug ID: 60586
Summary: [Cilk+] Parameters evaluation happens inside spawn
worker
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: izamyatin at gmail dot com
Following test (compiled with eg -O2 -fcilkplus -lcilkrts)
#include stdio.h
#include cilk/cilk.h
#include unistd.h
int noop(int x)
{
return x;
}
int post_increment(int *x)
{
sleep(1);
return (*x)++;
}
int main(int argc, char *argv[])
{
int m = 5;
int n = m;
int r = cilk_spawn noop(post_increment(n));
int n2 = n;
cilk_sync;
printf(After sync: m = %d, n = %d, r = %d, n2 = %d\n, m, n, r, n2);
if (r != m || n2 != m + 1)
printf(FAILED\n);
else
printf(PASSED\n);
return 0;
}
outputs
After sync: m = 5, n = 6, r = 5, n2 = 5
FAILED
That happens because post_increment is called inside spawn worker which is
incorrect.
[Bug target/60580] aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
This is a complete mess, what aarch64 backend does is completely incompatible
with optimize attribute. I've tried to fix this up:
--- gcc/config/aarch64/aarch64.opt.jj2014-01-20 14:50:22.0 +0100
+++ gcc/config/aarch64/aarch64.opt2014-03-19 11:52:29.963772607 +0100
@@ -59,6 +59,11 @@ const char *aarch64_cpu_string
Variable
const char *aarch64_tune_string
+; Did we set flag_omit_frame_pointer just so aarch64_frame_pointer_required
+; would be called?
+Variable
+bool faked_omit_frame_pointer
+
mbig-endian
Target Report RejectNegative Mask(BIG_END)
Assume target CPU is configured as big endian
--- gcc/config/aarch64/aarch64.c.jj2014-03-18 12:26:13.0 +0100
+++ gcc/config/aarch64/aarch64.c2014-03-19 12:20:19.471504562 +0100
@@ -315,10 +315,6 @@ static GTY(()) int gty_dummy;
#define AARCH64_NUM_BITMASKS 5334
static unsigned HOST_WIDE_INT aarch64_bitmasks[AARCH64_NUM_BITMASKS];
-/* Did we set flag_omit_frame_pointer just so
- aarch64_frame_pointer_required would be called? */
-static bool faked_omit_frame_pointer;
-
typedef enum aarch64_cond_code
{
AARCH64_EQ = 0, AARCH64_NE, AARCH64_CS, AARCH64_CC, AARCH64_MI, AARCH64_PL,
@@ -5278,7 +5274,11 @@ aarch64_override_options (void)
static void
aarch64_override_options_after_change (void)
{
- faked_omit_frame_pointer = false;
+ if (global_options_set.x_flag_omit_frame_pointer)
+{
+ faked_omit_frame_pointer = false;
+ global_options_set.x_faked_omit_frame_pointer = false;
+}
/* To omit leaf frame pointers, we need to turn flag_omit_frame_pointer on
so
that aarch64_frame_pointer_required will be called. We need to remember
@@ -5288,6 +5288,9 @@ aarch64_override_options_after_change (v
{
flag_omit_frame_pointer = true;
faked_omit_frame_pointer = true;
+ global_options_set.x_faked_omit_frame_pointer
+= global_options_set.x_flag_omit_frame_pointer;
+ global_options_set.x_flag_omit_frame_pointer = false;
}
}
but while that fixes some of the cases, it doesn't fix everything, the problem
is that the non-TargetVariable Variables aren't actually Saved.
Now, i386 backend seems to handle it differently, instead of adding a
faked_omit_frame_pointer variable (which, as this PR suggests would need to be
handled as an Optimization Saved variable, but supposedly the opts framework
doesn't allow it yet), it clears omit_leaf_frame_pointer flag if
flag_omit_frame_pointer is true:
/* Keep nonleaf frame pointers. */
if (opts-x_flag_omit_frame_pointer)
opts-x_target_flags = ~MASK_OMIT_LEAF_FRAME_POINTER;
else if (TARGET_OMIT_LEAF_FRAME_POINTER_P (opts-x_target_flags))
opts-x_flag_omit_frame_pointer = 1;
but does that only in in override_options hook. That means that
say for -fomit-frame-pointer -momit-leaf-frame-pointer on the command line
supposedly that turns off TARGET_OMIT_LEAF_FRAME_POINTER and when some function
has __attribute__((optimize (no-omit-frame-pointer))) and is leaf, frame
pointer will not be omitted there. But for -fno-omit-frame-pointer
-momit-leaf-frame-pointer on the command line and __attribute__((optimize
(no-omit-frame-pointer))) supposedly it will not have frame pointer if it is
leaf.
The primary issue is that flag_omit_frame_pointer is Optimization Save flag,
while omit-leaf-frame-pointer is typcially Target Save, the former optimize
attribute thing, the latter target attribute thing.
Not sure what is the best way out of this, but I guess doing in aarch64 what
i386 does would be significant progress.
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- I've posted the patches but I'm curious if the 2nd change alone helps enough. The first is somewhat handwaving (because we also have type_non_common which breaks the argument of the former).
[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This got fixed with r207164 on the trunk, whether that change is backportable and desirable for 4.8 I'll leave to Jason.
[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- The change has been reverted, therefore the regression should be gone.
[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- As this is DR1288 it's a dup of PR50025
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org --- For the record, I think r207164 fixed this
[Bug tree-optimization/60559] [4.9 Regression] g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583 --- Comment #3 from andreaskem at web dot de --- Thank you. I looked around but did not find those reports. Sorry for that.
[Bug libstdc++/60584] std::vector::emplace_back(...) use move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c++ |libstdc++
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
I don't know what clang does to compile it, but the code is not valid.
vectorT::emplace_back requires that T is MoveInsertable into the vector. Foo
fails that requirement because it has a deleted copy constructor and deleted
move constructor, because NonCopyable has a user-provided copy constructor
defined as deleted.
If you want NonCopyable to be movable then you need to do this:
class NonCopyable
{
public:
NonCopyable(){}
NonCopyable(const NonCopyable ) = delete;
NonCopyable(NonCopyable ) = default;
};
With that move constructor the code works.
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- If the warning is present with .i but not with .c, then we can't do much about it without the .c file with its headers.
[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-19 Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.0
[Bug libstdc++/60587] New: debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587
Bug ID: 60587
Summary: debug-mode -std=c++11 vector::insert(pos, begin, end)
dereferences begin too eagerly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
At least on recent trunk (r208675),
$ cat test.cc
#define _GLIBCXX_DEBUG
#include vector
int main() {
std::vectorint a, b;
a.push_back(1);
a.insert(a.end(), b.begin(), b.end());
}
$ ~/gcc/trunk/inst/g++ -std=c++11 test.cc
$ ./a.out
~/gcc/trunk/inst/include/c++/4.9.0/debug/safe_iterator.h:261:
error: attempt to dereference a past-the-end iterator.
Objects involved in the operation:
iterator this @ 0x0x7fff0d764060 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPiNSt9__cxx19986vectorIiSaIiENSt7__debug6vectorIiS6_
(mutable iterator);
state = past-the-end;
references sequence with type `NSt7__debug6vectorIiSaIiEEE' @
0x0x7fff0d764be0
}
which
Index: libstdc++-v3/include/debug/macros.h
===
--- libstdc++-v3/include/debug/macros.h (revision 208675)
+++ libstdc++-v3/include/debug/macros.h (working copy)
@@ -106,7 +106,7 @@
#define __glibcxx_check_insert_range(_Position,_First,_Last) \
__glibcxx_check_valid_range(_First,_Last); \
__glibcxx_check_insert(_Position); \
-_GLIBCXX_DEBUG_VERIFY(__gnu_debug::__foreign_iterator(_Position,_First),\
+_GLIBCXX_DEBUG_VERIFY(_First==_Last||__gnu_debug::__foreign_iterator(_Position,_First),\
_M_message(__gnu_debug::__msg_insert_range_from_self)\
._M_iterator(_First, #_First) \
._M_iterator(_Last, #_Last) \
works around for me.
[Bug target/60588] New: AVR target does not support init_priority attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588 Bug ID: 60588 Summary: AVR target does not support init_priority attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: senthil_kumar.selvaraj at atmel dot com The AVR target does not support init_priority attribute. This makes it hard to control initialization order of global objects across translation units. Was originally requested at http://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg5.html
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) --- part_good.s 2014-03-19 08:57:10.100342064 +0100 +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 - .quad _ZN6KParts13ReadWritePartD1Ev - .quad _ZN6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual I have trouble believing this is causing the problem you are seeing; if something were actually calling through this vtable slot it would write pure virtual method called to stderr and then terminate.
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #4 from Martin Husemann martin at netbsd dot org --- Yes - I'm still trying to reduce it to a reasonable test case, but in general it works - so I am confused big time. Also Julio (the ATF author) claims the same test works on FreeBSD with a very similar compiler version.
[Bug other/60589] New: Parallel install fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60589 Bug ID: 60589 Summary: Parallel install fails Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: burnus at gcc dot gnu.org GCC parallel install has been broken for a couple of days. Symptoms: test -z /home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk || /bin/mkdir -p /home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk test -z /home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk || /bin/mkdir -p /home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk /usr/bin/install -c -m 644 /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_api.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_api_linux.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_stub.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_undocumented.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/common.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/holder.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/hyperobject_base.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/metaprogramming.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_file.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_list.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_max.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_min.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_min_max.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opadd.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opand.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opmul.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opor.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opxor.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_ostream.h /home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_string.h '/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk' /usr/bin/install -c -m 644 /home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk.h '/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk' /usr/bin/install: cannot change permissions of `/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/cilk.h': No such file or directory make[3]: *** [install-nodist_cilkincludeHEADERS] Error 1 make[3]: *** Waiting for unfinished jobs It looks like libcilkrts Makefile tries to install cilk.h twice in parallel (in install-nodist_cilkinclude_HEADERS and install-cilkincludeHEADERS) and runs into a conflict. The error was probably introduced in r208440. BTW could someone add libcilkrts to list of components?
[Bug testsuite/60590] New: Can't recreate the same executable in testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590 Bug ID: 60590 Summary: Can't recreate the same executable in testsuite Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux, one can't run the command found in testsuite/gcc/gcc.log to recreate the same executable since lib/target-libpath.exp sets LD_RUN_PATH, which makes ld to set DT_RPATH. But LD_RUN_PATH is recorded in testsuite/gcc/gcc.log. We may not set LD_RUN_PATH when run the command to recreate the same executable. As the result, the executable generated by hand doesn't have DT_RPATH.
[Bug other/60589] Parallel install fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60589 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Created attachment 32394 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32394action=edit Draft patch Perhaps it's enough to simply remove cilk.h from cilkinclude_HEADERS? Attaching draft patch.
[Bug libstdc++/54316] [C++11] move constructor for stringstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 --- Comment #8 from Howard Hinnant howard.hinnant at gmail dot com --- Here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.4.4%20-%20Class%20template%20basic_ios is a good list of what needs to be done. It is an old paper, so it needs to be cross-checked against N3936. But the differences (if any) should be few and minor. The changes in this part of the standard are confusing to understand, because of the use of virtual inheritance. However if one just blindly follows the recipe, backed up by a few unit tests, things will just work. The more difficult parts are the concrete streambufs: basic_filebuf and basic_streambuf. Once those are in place, the streams just fall into place with very little code.
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jason Merrill from comment #3) (In reply to Markus Trippelsdorf from comment #2) --- part_good.s 2014-03-19 08:57:10.100342064 +0100 +++ part_bad.s 2014-03-19 08:56:50.134141664 +0100 - .quad _ZN6KParts13ReadWritePartD1Ev - .quad _ZN6KParts13ReadWritePartD0Ev + .quad __cxa_pure_virtual + .quad __cxa_pure_virtual I have trouble believing this is causing the problem you are seeing; if something were actually calling through this vtable slot it would write pure virtual method called to stderr and then terminate. part.ii is part of a library called libkparts.so.4.12.3. When I compile part.cpp with a compiler before r208573 and link the library (all other objects files for the lib are unchanged) and then install the library to my system /usr/lib folder, Okular starts and works fine. If I compile part.cpp with a compiler _after_ r208573 and link the library and install it, Okular shows a popup Unable to find the Okular component.
[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding it to the testsuite.
[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.0 |4.8.3 Summary|[4.9 Regression] FAIL: |[4.8/4.9 Regression] FAIL: |gfortran.dg/assumed_rank_7. |gfortran.dg/assumed_rank_7. |f90 |f90
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Mar 19 15:37:28 2014 New Revision: 208682 URL: http://gcc.gnu.org/viewcvs?rev=208682root=gccview=rev Log: 2014-03-19 Richard Biener rguent...@suse.de PR middle-end/60553 * tree-core.h (tree_type_common): Re-order pointer members to reduce recursion depth during GC walks. lto/ * lto-tree.h (lang_tree_node): For types use TYPE_NEXT_VARIANT instead of TREE_CHAIN as chain_next. Modified: trunk/gcc/ChangeLog trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-tree.h trunk/gcc/tree-core.h
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) If I compile part.cpp with a compiler _after_ r208573 and link the library and install it, Okular shows a popup Unable to find the Okular component. So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and 4 thunks to those, and see if they are ever called during the startup of Okular? For the 2 dtors perhaps always look at the caller if it was a direct call or call through vtable?
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Looking at the library, the only difference are four additional symbols in the good version: _ZThn16_N6KParts13ReadWritePartD0Ev _ZThn16_N6KParts13ReadWritePartD1Ev _ZTv0_n24_N6KParts13ReadWritePartD0Ev _ZTv0_n24_N6KParts13ReadWritePartD1Ev
[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-19 Known to work||4.8.2 Version|unknown |4.9.0 Target Milestone|--- |4.9.0 Summary|debug-mode -std=c++11 |[4.9 Regression] debug-mode |vector::insert(pos, begin, |-std=c++11 |end) dereferences begin too |vector::insert(pos, begin, |eagerly |end) dereferences begin too ||eagerly Ever confirmed|0 |1
[Bug middle-end/60591] New: Report enum conversions as part of Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
Bug ID: 60591
Summary: Report enum conversions as part of Wconversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
enum xpto
{
A = 0,
B = 1,
X = 512
};
extern void print (unsigned int);
unsigned char bar (enum xpto a)
{
return a;
}
We don't get currently a warning for this return conversion if we use
--short-enums. With -O2 --short-enums, sizeof enum xpto == 2, but sizeof
unsigned char == 1, therefore we should warn the user there's loss of
precision.
[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 19 15:48:39 2014 New Revision: 208684 URL: http://gcc.gnu.org/viewcvs?rev=208684root=gccview=rev Log: 2014-03-19 Paolo Carlini paolo.carl...@oracle.com PR c++/60332 * g++.dg/cpp1y/pr60332.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr60332.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug other/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 mshawcroft at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mshawcroft at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from mshawcroft at gcc dot gnu.org --- Fixed for 4.9 and back ported for 4.8.3 by the commits Jakub listed above. Closed.
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) part.ii is part of a library called libkparts.so.4.12.3. When I compile part.cpp with a compiler before r208573 and link the library (all other objects files for the lib are unchanged) and then install the library to my system /usr/lib folder, Okular starts and works fine. If I compile part.cpp with a compiler _after_ r208573 and link the library and install it, Okular shows a popup Unable to find the Okular component. Just to be clear, you've tested specifically 208572 vs 208573? Recompiling just that one file? Looking at the library, the only difference are four additional symbols in the good version: _ZThn16_N6KParts13ReadWritePartD0Ev _ZThn16_N6KParts13ReadWritePartD1Ev _ZTv0_n24_N6KParts13ReadWritePartD0Ev _ZTv0_n24_N6KParts13ReadWritePartD1Ev These are thunks to the destructor, which are unneeded if the (constructor) vtable doesn't refer to them anymore. (In reply to Jakub Jelinek from comment #5) So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and 4 thunks to those, and see if they are ever called during the startup of Okular? Or with part_bad, put a breakpoint on __cxa_pure_virtual?
[Bug target/60568] lto1: internal compiler error: in insn_min_length, at config/i386/i386.md:1599
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60568 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Also, your command line lists -m32, but the preprocessed file is clearly 64-bit (-m64) produced. And, if it is only reproduceable with -flto, we need all *.ii files through which it can be reproduced (perhaps link with -r -nostdlib -flto and try to remove unneeded objects).
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #10 from Martin Liška marxin.liska at gmail dot com ---
Second part of suggested patch is sufficient.
ps auxf:
marxin 20293 0.0 0.0 8604 1200 pts/0S17:27 0:00 | \_
c++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L.
-Wl,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22Init
marxin 20294 0.0 0.0 8128 692 pts/0S17:27 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/collect2
-plugin /home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.
marxin 20295 1.1 7.2 3881556 1181360 pts/0 S17:27 0:03 |
\_
/home/marxin/Programming/bin/gcc/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld
-plugin /home/marxin/Programming/bi
marxin 20412 0.0 0.1 34448 27212 pts/0S17:28 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
@/tmp/ccw1zmZQ
marxin 20413 0.0 0.0 12060 4548 pts/0S17:28 0:00 |
\_ c++ @/tmp/ccH68rYD.args
marxin 20414 23.7 33.4 5533676 5489912 pts/0 t17:28 0:54 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x8
ps ax | grep 20414:
20414 pts/0t 0:54
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x86-64 -msse2
-mssse3 -msse -mmmx -m64 -mtune=generic -march=x86-64 -auxbase
chrome_initial.chrome_exe_main_aura -O3 -fno-trapv -fno-exceptions -fPIC
-fno-fat-lto-objects -fltrans-output-list=/tmp/ccqDrHsV.ltrans.out -fwpa=9
-fresolution=/tmp/ccufR16A.res @/tmp/cc13JyyZ
GDB:
#1409777 0x006b3b11 in gt_ggc_m_P9tree_node4htab (x_p=0x7f0f55752850)
at gtype-desc.c:3185
(gdb) p *x
$2 = {hash_f = 0x75a1f0 libfunc_decl_hash(void const*), eq_f = 0x75a200
libfunc_decl_eq(void const*, void const*), del_f = 0x0, entries =
0x7f0f54390a00, size = 61, n_elements = 17, n_deleted = 0, searches = 17,
collisions = 4,
alloc_f = 0x681250 ggc_cleared_alloc_ptr_array_two_args(unsigned long,
unsigned long), free_f = 0x549db0 ggc_free(void*), alloc_arg = 0x0,
alloc_with_arg_f = 0x0, free_with_arg_f = 0x0, size_prime_index = 3}
down iterations:
(gdb) p x-generic-base-code
$7 = FUNCTION_DECL
$8 = FUNCTION_TYPE
$9 = INTEGER_TYPE
$10 = INTEGER_CST
$11 = INTEGER_TYPE
$12 = INTEGER_CST
$13 = INTEGER_TYPE
$14 = POINTER_TYPE
$15 = POINTER_TYPE
$16 = POINTER_TYPE
$17 = POINTER_TYPE
$18 = POINTER_TYPE
$19 = INTEGER_TYPE
Hope it will help.
Martin
[Bug testsuite/60590] Can't recreate the same executable in testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Wed Mar 19 16:59:18 2014 New Revision: 208685 URL: http://gcc.gnu.org/viewcvs?rev=208685root=gccview=rev Log: Log environment variables in set_ld_library_path_env_vars GNU linker sets DT_RPATH from the environment variable LD_RUN_PATH. set_ld_library_path_env_vars sets a few environment variables including LD_RUN_PATH. This patch logs all environment variables set by set_ld_library_path_env_vars so that one can recreate the same executable as make check run. PR testsuite/60590 * lib/target-libpath.exp (set_ld_library_path_env_vars): Log LD_LIBRARY_PATH, LD_RUN_PATH, SHLIB_PATH, LD_LIBRARY_PATH_32, LD_LIBRARY_PATH_64 and DYLD_LIBRARY_PATH. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-libpath.exp
[Bug testsuite/60590] Can't recreate the same executable in testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug target/60556] tip of tree crash with mips compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556 --- Comment #14 from reed kotler reed.kotler at imgtec dot com --- (In reply to Andrew Pinski from comment #13) (In reply to reed kotler from comment #12) Do you know where the original line was that made it fail in the .ii? Yes: # 227 /home/rkotler/llvm_trunk/lib/ExecutionEngine/RTDyldMemoryManager.cpp if (Name == stat) return (uint64_t)stat; if (Name == fstat) return (uint64_t)fstat; if (Name == lstat) return (uint64_t)lstat; if (Name == stat64) return (uint64_t)stat64; if (Name == fstat64) return (uint64_t)fstat64; if (Name == lstat64) return (uint64_t)lstat64; if (Name == atexit) return (uint64_t)atexit; if (Name == mknod) return (uint64_t)mknod; # 254 /home/rkotler/llvm_trunk/lib/ExecutionEngine/RTDyldMemoryManager.cpp if (Name == __main) return (uint64_t)jit_noop; You can just cast them to unsigned long before casting them to uint64_t for the work around. Great! This code is from LLVM. By making this change I can build a working llvm using gcc cross and native. Do we have any idea when the gcc will be fixed so I don't need to this workaround?
[Bug target/60556] tip of tree crash with mips compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- This is related to PR 54037.
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jason Merrill from comment #7) (In reply to Markus Trippelsdorf from comment #4) part.ii is part of a library called libkparts.so.4.12.3. When I compile part.cpp with a compiler before r208573 and link the library (all other objects files for the lib are unchanged) and then install the library to my system /usr/lib folder, Okular starts and works fine. If I compile part.cpp with a compiler _after_ r208573 and link the library and install it, Okular shows a popup Unable to find the Okular component. Just to be clear, you've tested specifically 208572 vs 208573? Recompiling just that one file? Yes. I compile kdelibs with 208573 and recompile that single file with 208572 and this fixes the issue. (I also have to revert r208556 in both cases, otherwise kdelibs won't compile). Looking at the library, the only difference are four additional symbols in the good version: _ZThn16_N6KParts13ReadWritePartD0Ev _ZThn16_N6KParts13ReadWritePartD1Ev _ZTv0_n24_N6KParts13ReadWritePartD0Ev _ZTv0_n24_N6KParts13ReadWritePartD1Ev These are thunks to the destructor, which are unneeded if the (constructor) vtable doesn't refer to them anymore. (In reply to Jakub Jelinek from comment #5) So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and 4 thunks to those, and see if they are ever called during the startup of Okular? Or with part_bad, put a breakpoint on __cxa_pure_virtual? Not much luck with breakpoints thus far.
[Bug libstdc++/60592] New: std::array is unable to be brace/universally initialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592
Bug ID: 60592
Summary: std::array is unable to be brace/universally
initialized
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mjbshaw at hotmail dot com
After a QA on StackOverflow[1], it seems there is a bug in libstdc++ (though I
suppose it could be in the gcc front end instead of libstdc++; I'm assuming
libstdc++) that prevents std::array from being brace-initialized. Consider the
following:
std::arrayint, 2 a = {1, 2};
std::arrayint, 2 b{a}; // error: cannot convert ‘std::arrayint, 2u’ to
‘int’ in initialization std::arrayint, 2 b{a};
std::arrayint, 2 b(a); // works
b{a} is trying to initialize b by creating an initializer list with a in it
[2], as opposed to using brace/universal initialization (which would be
equivalent to b(a), which works as expected [3]).
b{a} ought to work, as far as I understand things, and this error represents a
bug.
[1]:
http://stackoverflow.com/questions/22495624/why-does-this-compile-with-visual-studio-2013-but-not-g-4-8-1
[2]: http://ideone.com/C3NJbA
[3]: http://ideone.com/zjyTr8
[Bug libstdc++/60592] std::array is unable to be brace/universally initialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1467
[Bug libstdc++/60592] std::array is unable to be brace/universally initialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- If it's that DR, then this is a dup of my PR51747
[Bug target/60568] lto1: internal compiler error: in insn_min_length, at config/i386/i386.md:1599
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60568 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Can you please post complete command line that triggers the bug, as outlined in [1]? Something like: g++ ... options ... -fpreprocessed TEncSbac.ii Please also use -march=some arch instead of -march=native. You can see which architecture -march=native is compiling for by adding -### to the command line. [1] http://gcc.gnu.org/bugs/
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED
[Bug fortran/60593] New: ICE with deferred length variable in FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593 Bug ID: 60593 Summary: ICE with deferred length variable in FORALL Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org
[Bug libstdc++/60592] std::array is unable to be brace/universally initialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- definitely the same issue *** This bug has been marked as a duplicate of bug 51747 ***
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||mjbshaw at hotmail dot com --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 60592 has been marked as a duplicate of this bug. ***
[Bug fortran/60593] ICE with deferred length variable in FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593 kargl at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.9.0 --- Comment #1 from kargl at gcc dot gnu.org --- % gfc4x -c -Wall h.f90 h.f90: In function 'c2fchar': h.f90:29:0: internal compiler error: Segmentation fault forall (i = 1:c_str_len) res(i:i) = string_p(i) ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. % cat h.f90 module stringhelper_m implicit none type :: string_t character(:), allocatable :: string end type interface len function strlen(s) bind(c,name='strlen') use iso_c_binding implicit none type(c_ptr), intent(in), value :: s integer(c_size_t) :: strlen end function end interface contains function C2FChar(c_charptr) result(res) use iso_c_binding type(c_ptr), intent(in) :: c_charptr character(:), allocatable :: res character(kind=c_char,len=1), pointer :: string_p(:) integer i, c_str_len c_str_len = int(len(c_charptr)) call c_f_pointer(c_charptr, string_p, [c_str_len]) allocate(character(c_str_len) :: res) forall (i = 1:c_str_len) res(i:i) = string_p(i) end function end module (gdb) run h.f90 Starting program: /home/sgk/work/4x/libexec/gcc/x86_64-unknown-freebsd11.0/4.9.0/f951 h.f90 c2fchar Program received signal SIGSEGV, Segmentation fault. 0x007abaf4 in contains_struct_check (__s=optimized out, __f=optimized out, __l=optimized out, __g=optimized out, __t=optimized out, __s=optimized out, __f=optimized out, __l=optimized out, __g=optimized out) at ../../gcc4x/gcc/tree.h:2822 2822 if (tree_contains_struct[TREE_CODE (__t)][__s] != 1) (gdb) bt #0 0x007abaf4 in contains_struct_check (__s=optimized out, __f=optimized out, __l=optimized out, __g=optimized out, __t=optimized out, __s=optimized out, __f=optimized out, __l=optimized out, __g=optimized out) at ../../gcc4x/gcc/tree.h:2822 #1 fold_convert_loc (loc=0, type=0x202c2d7e0, arg=0x0) at ../../gcc4x/gcc/fold-const.c:1956 #2 0x006501f3 in allocate_temp_for_forall_nest_1 (type=0x202d6a930, size=0x202d77130, block=0x7fffce40, ptemp1=0x7fffca50) at ../../gcc4x/gcc/fortran/trans-stmt.c:3288 #3 0x00650949 in allocate_temp_for_forall_nest ( nested_forall_info=optimized out, type=optimized out, inner_size=optimized out, inner_size_body=optimized out, block=optimized out, ptemp1=optimized out, nested_forall_info=optimized out, type=optimized out, inner_size=optimized out, inner_size_body=optimized out, block=optimized out, ptemp1=optimized out) at ../../gcc4x/gcc/fortran/trans-stmt.c:3319 #4 gfc_trans_assign_need_temp (expr1=0x2034ac300, expr2=0x2034ac540, wheremask=0x0, invert=false, nested_forall_info=0x2034d13c0, block=0x7fffce40) at ../../gcc4x/gcc/fortran/trans-stmt.c:3408 #5 0x0064ccb2 in gfc_trans_forall_1 (code=0x2034ac840, nested_forall_info=optimized out) at ../../gcc4x/gcc/fortran/trans-stmt.c:3886 #6 0x005eb15e in trans_code (code=optimized out, cond=0x0) at ../../gcc4x/gcc/fortran/trans.c:1786 #7 0x006127cc in gfc_generate_function_code (ns=0x20344b400) at ../../gcc4x/gcc/fortran/trans-decl.c:5610 #8 0x005eb5ae in gfc_generate_module_code (ns=optimized out) at ../../gcc4x/gcc/fortran/trans.c:1972 #9 0x0058eb95 in translate_all_program_units ( gfc_global_ns_list=optimized out, main_in_tu=optimized out) at ../../gcc4x/gcc/fortran/parse.c:4523 #10 gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4733 #11 0x005d72ea in gfc_be_parse_file () at ../../gcc4x/gcc/fortran/f95-lang.c:188 #12 0x00a0978a in compile_file () at ../../gcc4x/gcc/toplev.c:548 #13 0x00a0958b in do_compile () at ../../gcc4x/gcc/toplev.c:1914 #14 toplev_main (argc=2, argv=0x7fffd4d8) at ../../gcc4x/gcc/toplev.c:1990 #15 0x005134af in _start ()
[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
Seems to be a problem of Binutils. If I use the current Binutils from
binutils-gdb git (= 2.24.51.20140319), it works.
But only for the test case of comment 0. It still fails for the big program and
for the following test case. [I wonder whether you can reproduce this one.]
Using either CentOS 6's Binutils or the git-trunk of Binutils
(2.24.51.20140319), the following fails for me:
$ g++ -Wfatal-errors -std=c++11 -r -nostdlib -flto test15.ii
lto1: internal compiler error: in add_symbol_to_partition, at
lto/lto-partition.c:233
0x5b4d44 add_symbol_to_partition
../../gcc/lto/lto-partition.c:231
//--
#pragma implementation
#pragma interface
class MutableError { };
class MutableSelector { };
template class CONVERTER class MutableValueHolder {
virtual MutableError
isValidNativeValue(const typename CONVERTER::Value_t) const {}
};
class MutableNumericTaggedType : virtual public MutableSelector {
};
class MutableNumericType : public virtual MutableNumericTaggedType { };
class MutableIntegerConverter {
public:
typedef int Value_t;
};
class MutableIntegerValue
: public MutableNumericType,
protected MutableValueHolderMutableIntegerConverter {
virtual MutableError
isValidNativeValue(const MutableIntegerConverter::Value_t value) const {}
};
[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Running nm on all my libs shows: ... kde4/notepadpart.so U _ZThn16_N6KParts13ReadWritePartD0Ev ... kde4/okularpart.so U _ZThn16_N6KParts13ReadWritePartD0Ev ... libkatepartinterfaces.so U _ZThn16_N6KParts13ReadWritePartD0Ev libkatepartinterfaces.so.4 U _ZThn16_N6KParts13ReadWritePartD0Ev libkatepartinterfaces.so.4.12.3 U _ZThn16_N6KParts13ReadWritePartD0Ev ... libktexteditor.so U _ZThn16_N6KParts13ReadWritePartD0Ev libktexteditor.so.4 U _ZThn16_N6KParts13ReadWritePartD0Ev libktexteditor.so.4.12.3 U _ZThn16_N6KParts13ReadWritePartD0Ev So maybe okular and katepart just need to be recompiled? Let me try this.
