[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- kernel/printk/printk.o gets miscompiled. % gcc -Wp,-MD,kernel/printk/.printk.o.d -nostdinc -isystem /var/tmp/gcc_test_/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include -I/var/tmp/linux/arch/x86/include -Iarch/x86/include/generated -Iinclude -I/var/tmp/linux/arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I/var/tmp/linux/include/uapi -Iinclude/generated/uapi -include /var/tmp/linux/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mno-mmx -mno-sse -mpreferred-stack-boundary=3 -march=native -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(printk) -DKBUILD_MODNAME=KBUILD_STR(printk) -c -o kernel/printk/printk.o kernel/printk/printk.c --save-temps
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 31547 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31547action=edit testcase
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 31548 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31548action=edit printk_good assembly
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 31549 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31549action=edit printk_bad assembly
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- linux % diff -u kernel/printk/printk.o /var/tmp/linux/kernel/printk/printk.o --- kernel/printk/printk.o 2013-12-31 09:23:45.569490147 +0100 +++ /var/tmp/linux/kernel/printk/printk.o 2013-12-31 09:23:22.066697479 +0100 @@ -2517,19 +2517,16 @@ printk_emit: pushq %rbp movq%rsp, %rbp - pushq %r10 - leaq-56(%rbp), %rax - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%rbp), %r10 movq%r9, -16(%rbp) + leaq-56(%rbp), %rax leaq-80(%rbp), %r9 - movq%r10, -72(%rbp) movl$40, -80(%rbp) + movq%r10, -72(%rbp) movq%rax, -64(%rbp) callvprintk_emit - addq$72, %rsp - popq%r10 - popq%rbp + leave ret .size printk_emit, .-printk_emit .LCOLDE44: @@ -2680,28 +2677,25 @@ printk: pushq %rbp movq%rsp, %rbp - pushq %r10 - leaq-56(%rbp), %rax - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%rbp), %r10 movq%rsi, -48(%rbp) movq%rdx, -40(%rbp) movq%rcx, -32(%rbp) movq%r8, -24(%rbp) - xorl%ecx, %ecx + leaq-56(%rbp), %rax movq%r9, -16(%rbp) movq%rdi, %r8 leaq-80(%rbp), %r9 + xorl%ecx, %ecx xorl%edx, %edx orl $-1, %esi xorl%edi, %edi - movq%r10, -72(%rbp) movl$8, -80(%rbp) + movq%r10, -72(%rbp) movq%rax, -64(%rbp) callvprintk_emit - addq$72, %rsp - popq%r10 - popq%rbp + leave ret .size printk, .-printk .LCOLDE47: @@ -4052,7 +4046,6 @@ printk_sched: pushq %rbp movq%rsp, %rbp - pushq %r10 pushq %rbx leaq16(%rbp), %r10 subq$80, %rsp @@ -4105,7 +4098,6 @@ #NO_APP addq$80, %rsp popq%rbx - popq%r10 popq%rbp ret .size printk_sched, .-printk_sched @@ -4691,26 +4683,23 @@ dump_stack_set_arch_desc: pushq %rbp movq%rsp, %rbp - pushq %r10 - leaq-56(%rbp), %rax - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%rbp), %r10 movq%rsi, -48(%rbp) movq%rdx, -40(%rbp) movq%rcx, -32(%rbp) + leaq-56(%rbp), %rax movq%rdi, %rdx leaq-80(%rbp), %rcx movl$128, %esi movq$dump_stack_arch_desc_str, %rdi - movq%r10, -72(%rbp) movq%r8, -24(%rbp) movq%r9, -16(%rbp) movl$8, -80(%rbp) + movq%r10, -72(%rbp) movq%rax, -64(%rbp) callvsnprintf - addq$72, %rsp - popq%r10 - popq%rbp + leave ret .size dump_stack_set_arch_desc, .-dump_stack_set_arch_desc .LCOLDE92:
[Bug other/59648] New: -O2 compilation of xorg-server-1.15.0 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648 Bug ID: 59648 Summary: -O2 compilation of xorg-server-1.15.0 fails Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Created attachment 31550 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31550action=edit Gzipped preprocessed events.c file -O compilation is fine. Gcc 4.9.0 trunk. libtool: link: x86_64-pc-linux-gnu-gcc -std=gnu99 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/include -I../include -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/Xext -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/composite -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/damageext -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/xfixes -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/Xi -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/mi -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/miext/sync -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/miext/shadow -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/miext/damage -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/render -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/randr -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/fb -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dbe -I/var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/present -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -I/usr/include/libdrm -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow -flto=4 -Wl,-O1 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow -flto=4 -Wl,-z -Wl,lazy -o input input.o -Wl,--as-needed ./.libs/libxservertest.a -lnettle -ldl -ludev -lpciaccess -ldrm -lpixman-1 -lXfont -lXau -lxshmfence -lXdmcp -lGL -lpthread -lm /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/xkb/xkbInit.c:690:22: warning: type of 'XkbDfltAccessXOptions' does not match original declaration [enabled by default] extern unsigned char XkbDfltAccessXOptions; ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/xkb/xkbAccessX.c:58:16: note: previously declared here unsigned short XkbDfltAccessXOptions = ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/events.c: In function 'MatchForType': /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/events.c:3810:9: warning: 'grabtype' may be used uninitialized in this function [-Wmaybe-uninitialized] int grabtype; ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/events.c:3834:15: warning: 'evtype' may be used uninitialized in this function [-Wmaybe-uninitialized] tmp-type = evtype; ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/events.c:3811:9: note: 'evtype' was declared here int evtype; ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/events.c:3808:21: warning: 'match' may be used uninitialized in this function [-Wmaybe-uninitialized] enum MatchFlags match; ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/ptrveloc.c: In function 'AccelSetProfileProperty': /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/ptrveloc.c:204:35: warning: 'profile' may be used uninitialized in this function [-Wmaybe-uninitialized] if (GetAccelerationProfile(vel, profile) == NULL) ^ /var/tmp/portage/x11-base/xorg-server-1.15.0/work/xorg-server-1.15.0/dix/ptrveloc.c:188:9: note: 'profile' was declared here int profile, *ptr = profile; ^
[Bug other/59648] -O2 compilation of xorg-server-1.15.0 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Not a compiler bug. -Werror=array-bounds turns all array-bounds warnings into errors. So either fix those issues, or turn off -Werror=array-bounds.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #6 from janus at gcc dot gnu.org --- The ICE seems to be gone at r206252. Can we close this PR?
[Bug rtl-optimization/59649] New: [4.9 regression] conftest.c miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59649
Bug ID: 59649
Summary: [4.9 regression] conftest.c miscompiled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: build, wrong-code
Severity: critical
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
CC: nickc at gcc dot gnu.org
Blocks: 59613
Target: ia64-*-*
From ia64-suse-linux/libgomp/config.log:
configure:16188: /usr/local/gcc/test/Build/./gcc/xgcc
-B/usr/local/gcc/test/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -isystem
/usr/ia64-suse-linux/sys-include-o conftest -g -O2 -include confdefs.h
-include ../../../libgomp/config/linux/omp-lock.h conftest.c -lrt 5
configure:16188: $? = 0
configure:16188: ./conftest
configure:16188: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU OpenMP Runtime Library
| #define PACKAGE_TARNAME libgomp
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU OpenMP Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgomp/;
| #define PACKAGE libgomp
| #define VERSION 1.0
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR .libs/
| #define TIME_WITH_SYS_TIME 1
| #define STRING_WITH_STRINGS 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SEMAPHORE_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_GETLOADAVG 1
| #define HAVE_STRTOULL 1
| #define HAVE_PTHREAD_AFFINITY_NP 1
| #define HAVE_CLOCK_GETTIME 1
| #define HAVE_TLS 1
| #define HAVE_ATTRIBUTE_VISIBILITY 1
| #define HAVE_ATTRIBUTE_ALIAS 1
| #define HAVE_AS_SYMVER_DIRECTIVE 1
| #define HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1
| #define LIBGOMP_GNU_SYMBOL_VERSIONING 1
| #define HAVE_SYNC_BUILTINS 1
| /* end confdefs.h. */
|
| static long int longval () { return sizeof (omp_lock_t); }
| static unsigned long int ulongval () { return sizeof (omp_lock_t); }
| #include stdio.h
| #include stdlib.h
| int
| main ()
| {
|
| FILE *f = fopen (conftest.val, w);
| if (! f)
| return 1;
| if ((sizeof (omp_lock_t)) 0)
| {
| long int i = longval ();
| if (i != (sizeof (omp_lock_t)))
| return 1;
| fprintf (f, %ld, i);
| }
| else
| {
| unsigned long int i = ulongval ();
| if (i != (sizeof (omp_lock_t)))
| return 1;
| fprintf (f, %lu, i);
| }
| /* Do not output a trailing newline, as this causes \r\n confusion
| on some platforms. */
| return ferror (f) || fclose (f) != 0;
|
| ;
| return 0;
| }
configure:16191: error: unsupported system, cannot find sizeof (omp_lock_t)
The test program is miscompiled to always return 1.
(gdb) disass main
Dump of assembler code for function main:
0x4600 +0: [MMB] alloc r34=ar.pfs,7,4,0
0x4601 +1: addl r37=288,r1
0x4602 +2: nop.b 0x0
0x4610 +16:[MII] addl r36=280,r1
0x4611 +17:mov r33=b0
0x4612 +18:mov r35=r1;;
0x4620 +32:[MMI] nop.m 0x0
0x4621 +33:ld8 r37=[r37]
0x4622 +34:nop.i 0x0
0x4630 +48:[MMB] ld8 r36=[r36]
0x4631 +49:nop.m 0x0
0x4632 +50:br.call.sptk.many
b0=0x4540;;
0x4640 +64:[MMI] mov r1=r35
0x4641 +65:nop.m 0x0
0x4642 +66:mov r32=r8
0x4650 +80:[MII] mov r38=4
0x4651 +81:mov r36=r8;;
0x4652 +82:addl r37=296,r1;;
0x4660 +96:[MIB] ld8 r37=[r37]
0x4661 +97:nop.i 0x0
0x4662 +98:br.call.sptk.many
b0=0x45c0;;
0x4670 +112: [MIB] mov r1=r35
0x4671 +113: mov r36=r32
0x4672 +114: br.call.sptk.many
b0=0x4560;;
0x4680 +128: [MMI] mov r8=1
0x4681 +129: mov r1=r35
0x4682 +130: mov.i ar.pfs=r34;;
0x4690 +144: [MIB] nop.m 0x0
0x4691 +145: mov b0=r33
0x4692 +146: br.ret.sptk.many b0;;
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||hubicka at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- So, on this source file the only differences caused by r206243 are caused by the ix86_save_reg hunk, the 4 functions in question before pro_and_epilogue pass don't need dynamic stack realignment, drap_reg is set to r10 but isn't live at the beginning of the function, just used somewhere in the function. Previously we'd save/restore it anyway, I assume just in case it would be used by the epilogue if drap would be needed there (but it isn't), after my commit it isn't saved (r10 is call used register, so there is no point in saving/restoring it). So, I fail to see why this change is wrong, unless the kernel say calls one of those functions from assembly and mistakenly assumes r10 is not clobbered by the call. Note that if stack realignment would happen, then r10 would not be preserved even before the patch, in that case, while r10 is saved/restored, it is saved after it has been set to the DRAP value.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Dec 31 11:57:39 2013 New Revision: 206264 URL: http://gcc.gnu.org/viewcvs?rev=206264root=gccview=rev Log: PR tree-optimization/59622 * gimple-fold.c (gimple_fold_call): Don't replace OBJ_TYPE_REF call fndecl with 0 possible targets with BUILT_IN_UNREACHABLE, instead only for !inplace add a __builtin_unreachable () call before the call. * g++.dg/opt/pr59622.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr59622.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, ok, the #c12 testcase is indeed a different case, targets doesn't have length 0 in that case, but length 1, but targets[0]-decl is __cxa_pure_virtual function, which is similar to __builtin_unreachable in that it takes no arguments, has void return value and is noreturn. So, supposedly for the length 1 case gimple_fold_call should compare if the return type is compatible with the lhs type if it has lhs, for !inplace just punt (similarly for the case (always?) when the number of arguments is bigger than the called one), for inplace I guess we can replace it by a different call but would need to do for the lhs what I mentioned (if it has lhs and the lhs has gimple_reg_type, set it to zero after the noreturn call with void type). For other incompatibilities in the return value or arguments, perhaps we should just not try to fold it at all.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
From the printk.i:
38333 int printk_emit(int facility, int level,
38334 const char *dict, size_t dictlen,
38335 const char *fmt, ...)
38336 {
38337 va_list args;
38338 int r;
38339
38340 __builtin_va_start(args,fmt);
38341 r = vprintk_emit(facility, level, dict, dictlen, fmt, args);
38342 __builtin_va_end(args);
38343
38344 return r;
38345 }
38346 ;
38347 # 1676 kernel/printk/printk.c
38348 int printk(const char *fmt, ...)
38349 {
38350 va_list args;
38351 int r;
38352 # 1689 kernel/printk/printk.c
38353 __builtin_va_start(args,fmt);
38354 r = vprintk_emit(0, -1, ((void *)0), 0, fmt, args);
38355 __builtin_va_end(args);
38356
38357 return r;
38358 }
38359 ;
dump_stack_set_arch_desc is also a call wrapped by __builtin_va_start
__builtin_va_end.
[Bug rtl-optimization/59649] [4.9 regression] conftest.c miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59649 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- gen_int_mode(-1, BImode) returning (const_int 1) looks wrong.
[Bug rtl-optimization/59647] [4.8 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1597
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59647 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|c++ |rtl-optimization Version|unknown |4.8.2 Target Milestone|--- |4.8.3 Summary|[4.8] ICE in|[4.8 Regression] ICE in |simplify_const_unary_operat |simplify_const_unary_operat |ion, at simplify-rtx.c:1597 |ion, at simplify-rtx.c:1597 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r186147, went away with r202345, though given that the latter is a GIMPLE pass change, I'd bet it just went latent on the trunk.
[Bug target/58450] -fno-trapping-math causes decrease in performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- No reply, so going with H.J.'s analysis. *** This bug has been marked as a duplicate of bug 57954 ***
[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||ylow at graphlab dot com --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- *** Bug 58450 has been marked as a duplicate of this bug. ***
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 31 14:02:04 2013 New Revision: 206266 URL: http://gcc.gnu.org/viewcvs?rev=206266root=gccview=rev Log: 2013-12-31 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-30 Janus Weil ja...@gcc.gnu.org PR fortran/58998 * resolve.c (resolve_symbol): Check that symbol is not only flavorless but also untyped. 2013-12-31 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-30 Janus Weil ja...@gcc.gnu.org PR fortran/58998 * gfortran.dg/generic_28.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/generic_28.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from janus at gcc dot gnu.org --- Fixed for 4.9.0 and 4.8.3. Closing.
[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) Revision 181424 gives the following errors [...] revision 181425 gives the ICE. r181425 is Tobias' constructor patch.
[Bug tree-optimization/59650] New: Inefficient vector assignment code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59650
Bug ID: 59650
Summary: Inefficient vector assignment code
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie at witherden dot org
Consider the following snippet:
typedef double v4d __attribute__((vector_size(32)));
v4d set1(double *v)
{
v4d tmp = { v[0], v[1], v[2], v[3] };
return tmp;
}
v4d set2(double *v)
{
v4d tmp;
tmp[0] = v[0];
tmp[1] = v[1];
tmp[2] = v[2];
tmp[3] = v[3];
return tmp;
}
if my understanding of the vector extensions is correct they should both do the
same thing. Compiling with GCC 4.8.2 with -O3 -march=native on a Sandy Bridge
system gives:
_Z4set1Pd:
0: c5 fb 10 57 10 vmovsd 0x10(%rdi),%xmm2
5: c5 fb 10 1f vmovsd (%rdi),%xmm3
9: c5 e9 16 47 18 vmovhpd 0x18(%rdi),%xmm2,%xmm0
e: c5 e1 16 4f 08 vmovhpd 0x8(%rdi),%xmm3,%xmm1
13: c4 e3 75 18 c0 01 vinsertf128 $0x1,%xmm0,%ymm1,%ymm0
19: c3 retq
1a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
0020 _Z4set2Pd:
20: c5 fb 10 07 vmovsd (%rdi),%xmm0
24: c5 f9 28 c0 vmovapd %xmm0,%xmm0
28: c5 f9 28 c8 vmovapd %xmm0,%xmm1
2c: c5 f1 16 4f 08 vmovhpd 0x8(%rdi),%xmm1,%xmm1
31: c4 e3 7d 18 c1 00 vinsertf128 $0x0,%xmm1,%ymm0,%ymm0
37: c4 e3 7d 19 c1 01 vextractf128 $0x1,%ymm0,%xmm1
3d: c5 f1 12 4f 10 vmovlpd 0x10(%rdi),%xmm1,%xmm1
42: c4 e3 7d 18 c1 01 vinsertf128 $0x1,%xmm1,%ymm0,%ymm0
48: c4 e3 7d 19 c1 01 vextractf128 $0x1,%ymm0,%xmm1
4e: c5 f1 16 4f 18 vmovhpd 0x18(%rdi),%xmm1,%xmm1
53: c4 e3 7d 18 c1 01 vinsertf128 $0x1,%xmm1,%ymm0,%ymm0
59: c3 retq
where I note the functions are different. For set1 I note that four moves are
issued whereas I was expecting two 128-bit unaligned moves. The code for set2
also appears to be inefficient.
[Bug fortran/57042] [4.7/4.8 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |ICE/Segfault with |ICE/Segfault with |-fdump-parse-tree |-fdump-parse-tree --- Comment #5 from janus at gcc dot gnu.org --- The ICE on comment 0 has been fixed with r206237 on trunk (cf. PR 59612). I was not aware that this is a regression. Should I backport to 4.8 and 4.7?
[Bug fortran/57042] [4.7/4.8 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) I was not aware that this is a regression. The ICE on comment 0 happens only with 4.6 and later, due the fact that the ICE occurs on the COMPILER_OPTIONS symbol (which was implemented in 4.6).
[Bug tree-optimization/59651] New: Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
Bug ID: 59651
Summary: Vectorizer failing to spot dependence causes incorrect
code generation.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
Hi,
This patch (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01588.html) seems to
uncover a bug in the vectorizer where it fails to spot dependence.
When test case gcc.dg/torture/pr52943.c is compiled with -O3, the vectorizer
generates:
main ()
{
vector(2) int * vectp_a.10;
vector(2) int * vectp_a.9;
vector(2) int vect_cst_.8;
unsigned int tmp.7;
int tmp.6;
int b_lsm.5;
unsigned int patt_1;
int patt_3;
unsigned int ivtmp_4;
int _5;
_Bool _6;
int _7;
unsigned int ivtmp_8;
int b.1_9;
unsigned int ivtmp_10;
int _11;
int patt_12;
unsigned int patt_15;
int b.0_16;
int b.0_30;
unsigned int ivtmp_31;
int b.1_33;
unsigned int ivtmp_34;
int b.0_37;
unsigned int ivtmp_39;
unsigned int ivtmp_48;
bb 2:
_5 = a[3];
_6 = _5 1;
_7 = (int) _6;
vect_cst_.8_43 = {_7, _7};
vectp_a.10_44 = MEM[(void *)a + 8B];
bb 3:
# b.0_16 = PHI b.1_9(7), 3(2)
# ivtmp_4 = PHI ivtmp_10(7), 3(2)
# vectp_a.9_45 = PHI vectp_a.9_46(7), vectp_a.10_44(2)
# ivtmp_8 = PHI ivtmp_48(7), 0(2)
MEM[(int *)vectp_a.9_45] = vect_cst_.8_43;
b.1_9 = b.0_16 + -1;
ivtmp_10 = ivtmp_4 - 1;
vectp_a.9_46 = vectp_a.9_45 + 18446744073709551608;
ivtmp_48 = ivtmp_8 + 1;
if (ivtmp_48 1)
goto bb 7;
else
goto bb 6;
bb 4:
# b.0_30 = PHI b.1_33(5), 1(6)
# ivtmp_31 = PHI ivtmp_34(5), 1(6)
a[b.0_30] = _7;
b.1_33 = b.0_30 + -1;
ivtmp_34 = ivtmp_31 - 1;
if (ivtmp_34 != 0)
goto bb 5;
else
goto bb 8;
bb 5:
goto bb 4;
bb 6:
# b.0_37 = PHI b.1_9(3)
# ivtmp_39 = PHI ivtmp_10(3)
goto bb 4;
bb 7:
goto bb 3;
bb 8:
b = 0;
_11 = a[1];
if (_11 != 0)
goto bb 9;
else
goto bb 10;
bb 9:
abort ();
bb 10:
return 0;
}
From the above test, it seems that _7 is precalculated in BB 2 using
_5 = a[3];
_6 = _5 1;
_7 = (int) _6;
vect_cst_.8_43 = {_7, _7};
and stored everywhere without considering the dependence on a[3].
MEM[(int *)vectp_a.9_45] = vect_cst_.8_43;
...
# b.0_30 = PHI b.1_33(5), 1(6)
# ivtmp_31 = PHI ivtmp_34(5), 1(6)
a[b.0_30] = _7;
b.1_33 = b.0_30 + -1;
ivtmp_34 = ivtmp_31 - 1;
I observed this while running regressions on aarch64. My config is:
.../gcc/configure --target=aarch64-none-elf --prefix=.../install
--with-gmp=.../host-tools --with-mpfr=.../host-tools --with-mpc=.../host-tools
--with-pkgversion=unknown --disable-shared --disable-nls --disable-threads
--disable-tls --enable-checking=yes --enable-languages=c,c++ --with-newlib
[Bug rtl-optimization/59652] New: [4.8 Regression] ICE: in reload_cse_simpli fy_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59652
Bug ID: 59652
Summary: [4.8 Regression] ICE: in reload_cse_simpli
fy_operands, at postreload.c:411
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Created attachment 31551
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31551action=edit
Preprocessed source
/usr/lib/gcc/hppa-linux-gnu/4.8/cc1 -fpreprocessed xdvi.i -quiet -dumpbase xdvi
.c -auxbase-strip xdvi.o -g -O2 -Wimplicit -Wreturn-type
-Wdeclaration-after-sta
tement -Wno-unknown-pragmas -version -o xdvi.s
GNU C (Debian 4.8.2-10) version 4.8.2 (hppa-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.2, MPFR version
3.1.2-p
3, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (Debian 4.8.2-10) version 4.8.2 (hppa-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.2, MPFR version
3.1.2-p
3, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.1.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fb24f240bb689ce9d1ca4b08c9c74b8f
../../../texk/xdvik/xdvi.c: In function ‘run_dvi_file’:
../../../texk/xdvik/xdvi.c:3398:1: error: insn does not satisfy its
constraints:
}
^
(insn 5859 3068 5860 249 (set (reg:SI 28 %r28)
(reg/f:SI 2442)) ../../../texk/xdvik/xdvi.c:2722 40 {*pa.md:2211}
(nil))
../../../texk/xdvik/xdvi.c:3398:1: internal compiler error: in
reload_cse_simpli
fy_operands, at postreload.c:411
Problem occurs in handling reloads for following insn:
(insn 3071 3068 3072 249 (set (reg:SF 1959 [ resource.gamma ])
(mem/c:SF (plus:SI (reg/f:SI 2442)
(const_int 88 [0x58])) [9 resource.gamma+0 S4 A32]))
../../../te
xk/xdvik/xdvi.c:2722 79 {*pa.md:4386}
(expr_list:REG_EQUIV (mem/c:SF (plus:SI (reg/f:SI 2442)
(const_int 88 [0x58])) [9 resource.gamma+0 S4 A32])
(expr_list:REG_EQUAL (mem/c:SF (const:SI (plus:SI (symbol_ref:SI
(resou
rce) [flags 0x200] var_decl 0x4050c660 resource)
(const_int 88 [0x58]))) [9 resource.gamma+0 S4 A32])
(nil
Might be target issue but seems more likely to be a reload issue.
[Bug rtl-optimization/59652] [4.8 Regression] ICE: in reload_cse_simpli fy_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59652 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 31552 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31552action=edit rtl dump from reload pass
[Bug tree-optimization/59651] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #1 from Bingfeng Mei bmei at broadcom dot com ---
That is interesting. On x86-64, GCC does say it cannot determine dist vector
between a[3] a[b] and needs run-time aliasing test. In the end it gives up
due to too few iterations.
note: === vect_analyze_data_ref_dependences ===
(compute_affine_dependence
stmt_a: _5 = a[3];
stmt_b: a[b.0_16] = _7;
(analyze_overlapping_iterations
(chrec_a = 3)
(chrec_b = {3, +, -1}_1)
(analyze_siv_subscript
)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
(Dependence relation cannot be represented by distance vector.)
)
(compute_affine_dependence
stmt_a: _5 = a[3];
stmt_b: _5 = a[3];
(analyze_overlapping_iterations
(chrec_a = 3)
(chrec_b = 3)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
)
(compute_affine_dependence
stmt_a: a[b.0_16] = _7;
stmt_b: a[b.0_16] = _7;
(analyze_overlapping_iterations
(chrec_a = {3, +, -1}_1)
(chrec_b = {3, +, -1}_1)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
)
/projects/firepath_tools1_scratch/bmei/trunk/gcc/testsuite/gcc.dg/torture/pr52943.c:13:7:
note: versioning for alias required: bad dist vector for a[3] and a[b.0_16]
/projects/firepath_tools1_scratch/bmei/trunk/gcc/testsuite/gcc.dg/torture/pr52943.c:13:7:
note: mark for run-time aliasing test between a[3] and a[b.0_16]
[Bug tree-optimization/59651] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #2 from belagod at gcc dot gnu.org ---
Something simliar happens on aarch64, but later goes ahead and vectorizes it
anyway. How about trying to vectorize on x86 with -fno-vect-cost-model?
pr.c:13:7: note: === vect_analyze_data_ref_dependences ===
(compute_affine_dependence
stmt_a: _5 = a[3];
stmt_b: a[b.0_16] = _7;
(analyze_overlapping_iterations
(chrec_a = 3)
(chrec_b = {3, +, -1}_1)
(analyze_siv_subscript
)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
(Dependence relation cannot be represented by distance vector.)
)
(compute_affine_dependence
stmt_a: _5 = a[3];
stmt_b: _5 = a[3];
(analyze_overlapping_iterations
(chrec_a = 3)
(chrec_b = 3)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
)
(compute_affine_dependence
stmt_a: a[b.0_16] = _7;
stmt_b: a[b.0_16] = _7;
(analyze_overlapping_iterations
(chrec_a = {3, +, -1}_1)
(chrec_b = {3, +, -1}_1)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
)
pr.c:13:7: note: versioning for alias required: bad dist vector for a[3] and
a[b.0_16]
pr.c:13:7: note: mark for run-time aliasing test between a[3] and a[b.0_16]
[Bug rtl-optimization/59652] [4.8 Regression] ICE: in reload_cse_simpli fy_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59652
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
It looks to me like the problem arises because reload selected a
call clobbered register, %r1, for reg/f:SI 2442 and there is no way to
reconstitute reg/f:SI 2442 following a call:
(code_label 311 310 312 20 233 [3 uses])
(note 312 311 5353 20 [bb 20] NOTE_INSN_BASIC_BLOCK)
(insn 5353 312 5354 20 (set (reg:SI 1 %r1)
(high:SI (symbol_ref:SI (resource) [flags 0x200] var_decl
0x4050c660
resource))) ../../../texk/xdvik/xdvi.c:3003 52 {*pa.md:2686}
(nil))
(insn 5354 5353 315 20 (set (reg:SI 1 %r1)
(lo_sum:SI (reg:SI 1 %r1)
(symbol_ref:SI (resource) [flags 0x200] var_decl 0x4050c660
reso
urce))) ../../../texk/xdvik/xdvi.c:3003 55 {*pa.md:2766}
(nil))
(insn 315 5354 316 20 (set (reg/f:SI 28 %r28 [orig:949 resource.src_pos ]
[949])
(mem/f/c:SI (plus:SI (reg:SI 1 %r1)
(const_int 172 [0xac])) [5 resource.src_pos+0 S4 A32]))
../../..
/texk/xdvik/xdvi.c:3003 40 {*pa.md:2211}
(expr_list:REG_EQUIV (mem/f/c:SI (plus:SI (reg/f:SI 2442)
(const_int 172 [0xac])) [5 resource.src_pos+0 S4 A32])
(expr_list:REG_EQUAL (mem/f/c:SI (const:SI (plus:SI (symbol_ref:SI
(resource) [flags 0x200] var_decl 0x4050c660 resource)
(const_int 172 [0xac]))) [5 resource.src_pos+0 S4 A32])
(nil
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org --- Any chance the candidate patch can be submitted?
[Bug c++/59653] New: warn when non-const parameter or local variable is not modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59653 Bug ID: 59653 Summary: warn when non-const parameter or local variable is not modified Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mw_triad at users dot sourceforge.net Some coding styles specify that local variables that are not modified should be marked 'const' in order (in theory) to allow for compiler optimization. It would be great if gcc could omit a warning for violations of this rule. I imagine this would work by setting a flag on a non-const local variable instantiation that is cleared when the variable is used in a manner that requires that is not be 'const'. If the flag is not cleared when the variable goes out of scope (which presumably gcc knows, as it needs to invoke the dtor at this time if the type has one), a warning would be emitted. The same for function/method parameters, but likely as a separate warning, would also be desirable. Closely related to bug #59552; that one should probably be a different option, but the implementation is likely similar.
[Bug c++/59653] warn when non-const parameter or local variable is not modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59653 Matthew Woehlke mw_triad at users dot sourceforge.net changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/59651] [4.9 Regression] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.9.0 Summary|Vectorizer failing to spot |[4.9 Regression] Vectorizer |dependence causes incorrect |failing to spot dependence |code generation.|causes incorrect code ||generation.
[Bug tree-optimization/59651] [4.9 Regression] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #3 from Bingfeng Mei bmei at broadcom dot com ---
I can reproduce on aarch64. Still try to understand why. I constructed a
similar test but with positive loop step.
extern void abort (void);
int a[] = { 6, 0, 0, 0 };
int b;
int
main ()
{
for (;;)
{
b = 0;
for (; b3; b += 1)
a[b] = a[0] 1;
break;
}
if (a[2] != 0)
abort ();
return 0;
}
Actually GCC behaves similarly during vectorization and does vectorize the
loop. The only difference is around loop versioning.
pr52943.c
bb 10:
if (1 != 0)
goto bb 11;
else
goto bb 12;
bb 11 leads to vectorized version. So scalar version gets optimized out.
Above example:
bb 10:
if (0 != 0)
goto bb 11;
else
goto bb 12;
So vectorized version goes away and only scalar version remains.
[Bug rtl-optimization/59647] [4.8 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1597
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59647 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Dec 31 23:48:36 2013 New Revision: 206267 URL: http://gcc.gnu.org/viewcvs?rev=206267root=gccview=rev Log: PR rtl-optimization/59647 * cse.c (cse_process_notes_1): Don't substitute negative VOIDmode new_rtx into UNSIGNED_FLOAT rtxes. * g++.dg/opt/pr59647.C: New test. Added: trunk/gcc/ChangeLog-2013 trunk/gcc/testsuite/ChangeLog-2013 trunk/gcc/testsuite/g++.dg/opt/pr59647.C Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/59647] [4.8 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1597
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59647 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Dec 31 23:52:11 2013 New Revision: 206268 URL: http://gcc.gnu.org/viewcvs?rev=206268root=gccview=rev Log: PR rtl-optimization/59647 * cse.c (cse_process_notes_1): Don't substitute negative VOIDmode new_rtx into UNSIGNED_FLOAT rtxes. * g++.dg/opt/pr59647.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/opt/pr59647.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cse.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/59647] [4.8 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1597
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59647 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug fortran/59654] New: Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 Bug ID: 59654 Summary: Broken function table with complex OO use case Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Thomas.L.Clune at nasa dot gov Created attachment 31553 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31553action=edit Reproducer - single file. I have an application (pFUnit) which makes very heavy use of OO fortran features. A recent mod has revealed that the implementation is very fragile with regard to gfortran (4.8.1, 4.8.2, and 4.9.0).I have discussed this situation with Damian Rousson, and he is also somewhat surprised as to how sensitive the compiler is in this situation. (I should add, that this code and the various workarounds I've tried in the real application all appear to work correctly with both Intel and NAG compilers.) I am attaching a simplified reproducer that exhibits some of the symptoms as well as a UML diagram to help understand what is going on. The reproducer actually has very few executable lines, but involves the collaboration of at least 3 nontrivial design patterns. The reproducer compiles, but will self-diagnose an incorrect execution with the string 'Error - incorrect number of tests were run.' If the PRIVATE statement on line 144 is uncommented, then the code will run successfully producing the message 'Successful run'. Using gdb, it appears that the code somehow prematurely returns to main. In the full application (not attached), I've seen even more surprising behavior which still falls into the category of an apparently damaged function pointer table for at least one class. Namely, gdb is showing that the code is failing inside a method (type-bound procedure) that is not referenced _anywhere_ in the application! Various workarounds have moved the problem to at least 3 different methods that are never referenced. I have workarounds for the full application that run correctly but the slightest change brings problems right back, so I'm unwilling to commit to further development until I have a more robust solution. Note - I'm as happy with a robust workaround as I am with a compiler fix in this case.
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 tlcclt Thomas.L.Clune at nasa dot gov changed: What|Removed |Added CC||Thomas.L.Clune at nasa dot gov --- Comment #1 from tlcclt Thomas.L.Clune at nasa dot gov --- Created attachment 31554 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31554action=edit UML Class diagram for reproducer
[Bug c++/59655] New: incorrect diagnostic on templatized function with lambda parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59655 Bug ID: 59655 Summary: incorrect diagnostic on templatized function with lambda parameter Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pab at pabigot dot com Created attachment 31555 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31555action=edit Reproducing code The attached program uses tricks to produce a user-level diagnostic for function misuse through a static_assert without also producing diagnostics about the constraint that the static_assert checks. While this works correctly for normal types, an extra and incorrect diagnostic is produced when a lambda type is involved. Specifically, -fpermissive complains that a function is used but never defined, while pointing at the function's definition. llc[1082]$ g++ --version g++ (GCC) 4.9.0 20131210 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. llc[1083]$ g++ -DWITH_LAMBDA=0 -Wall -std=c++11 -c sabug.cc sabug.cc: In instantiation of ‘void useit(T1, T2) [with T1 = std::basic_stringchar; T2 = std::basic_stringwchar_t]’: sabug.cc:86:15: required from here sabug.cc:69:3: error: static assertion failed: cannot assign static_assert(template_types_ok::value, cannot assign); ^ llc[1084]$ g++ -DWITH_LAMBDA=1 -Wall -std=c++11 -c sabug.cc sabug.cc: In instantiation of ‘void useit(T1, T2) [with T1 = std::basic_stringchar; T2 = main()::lambda()]’: sabug.cc:84:30: required from here sabug.cc:69:3: error: static assertion failed: cannot assign static_assert(template_types_ok::value, cannot assign); ^ sabug.cc:53:6: error: ‘void useit_(T1, T2, std::false_type) [with T1 = std::basic_stringchar; T2 = main()::lambda(); std::false_type = std::integral_constantbool, false]’, declared using local type ‘main()::lambda()’, is used but never defined [-fpermissive] void useit_ (T1 t1, T2 t2, std::false_type template_ok) ^ llc[1085]$
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
--- Comment #10 from minktee minktee at hotmail dot com ---
Comment on attachment 31105
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31105
lightly tested patch.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 212a4bc..23dfc0e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -26547,6 +26547,7 @@ arm_expand_epilogue_apcs_frame (bool really_return)
num_regs = bit_count (saved_regs_mask);
if ((offsets-outgoing_args != (1 + num_regs)) || cfun-calls_alloca)
{
+ emit_insn (gen_blockage ());
/* Unwind the stack to just below the saved registers. */
emit_insn (gen_addsi3 (stack_pointer_rtx,
hard_frame_pointer_rtx,
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 --- Comment #11 from minktee minktee at hotmail dot com --- Comment on attachment 31083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31083 stripped from kernel 3.4 fs/dcache.c Created attachment 31083 [details] stripped from kernel 3.4 fs/dcache.c 2013-10-23 17:42 UTC, bcch...@android.com
[Bug target/58854] [4.8 regression] sub sp, fp, #40 hoisted above frame accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
--- Comment #12 from minktee minktee at hotmail dot com ---
Comment on attachment 31105
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31105
lightly tested patch.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 212a4bc..23dfc0e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -26547,6 +26547,7 @@ arm_expand_epilogue_apcs_frame (bool really_return)
num_regs = bit_count (saved_regs_mask);
if ((offsets-outgoing_args != (1 + num_regs)) || cfun-calls_alloca)
{
+1emit_insn (gen_blockage ());
/* Unwind the stack to just below the saved registers. */
emit_insn (gen_addsi3 (stack_pointer_rtx,
hard_frame_pointer_rtx,
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|major |normal --- Comment #2 from kargl at gcc dot gnu.org --- What command line do you use and what operating system? Can you run the application under valgrind?
[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158
--- Comment #12 from Tom Li biergaizi2009 at gmail dot com ---
And I just applied Aaro Koskinen's patch on gcc 4.8.2, recompile gcc and
resolve this issue.
Patch for 4.8.2:
--- gcc-4.8.2/gcc/config/mips/mips.md 2013-02-25 21:53:16.0 +0800
+++ gcc-4.8.2-fixed/gcc/config/mips/mips.md 2013-12-31 20:23:26.021484375
+0800
@@ -6715,6 +6715,9 @@
(match_operand:GPR 3 reg_or_0_operand)))]
ISA_HAS_CONDMOVE
{
+ if (!ISA_HAS_FP_CONDMOVE
+ GET_MODE_CLASS (GET_MODE (XEXP (operands[1], 0))) != MODE_INT)
+FAIL;
mips_expand_conditional_move (operands);
DONE;
})
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #3 from tlcclt Thomas.L.Clune at nasa dot gov --- I have testend under OS X (10.8.5) with gfortran 4.8.1 and 4.8.2. I've also tested under Linux (not sure which flavor) with 4.9.0. Command line is: % gfortran allinone.F90 % ./a.out Error - incorrect number of tests were run. % Although I've heard of valgrind, I've never used it. PS Sorry about how I set the Importance field. I assumed it was for the user's perspective.
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #4 from tlcclt Thomas.L.Clune at nasa dot gov --- OK - had a bit of time waiting for the New Year countdown … so read up a bit on valgrind. A vanilla run under Linux with 4.9.0 gave the following, which seems encouraging, albeit cryptic: % gfortran -O0 -g allinone.F90 % valgrind ./a.out ==4724== Memcheck, a memory error detector ==4724== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==4724== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==4724== Command: ./a.out ==4724== --4724-- WARNING: Serious error when reading debug info --4724-- When reading debug info from /gpfsm/dhome/tclune/a.out: --4724-- Ignoring non-Dwarf2/3 block in .debug_info ./a.out: error while loading shared libraries: libquadmath.so.0: cannot open shared object file: No such file or directory ==4724== Jump to the invalid address stated on the next line ==4724==at 0x4DE: ??? ==4724==by 0x400DEC7: _dl_signal_error (in /lib64/ld-2.11.1.so) ==4724==by 0x400CFD2: _dl_map_object_deps (in /lib64/ld-2.11.1.so) ==4724==by 0x40032B3: dl_main (in /lib64/ld-2.11.1.so) ==4724==by 0x4014979: _dl_sysdep_start (in /lib64/ld-2.11.1.so) ==4724==by 0x40013D0: _dl_start (in /lib64/ld-2.11.1.so) ==4724==by 0x4000B07: ??? (in /lib64/ld-2.11.1.so) ==4724== Address 0x4de is not stack'd, malloc'd or (recently) free'd ==4724== ==4724== ==4724== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==4724== Bad permissions for mapped region at address 0x4DE ==4724==at 0x4DE: ??? ==4724==by 0x400DEC7: _dl_signal_error (in /lib64/ld-2.11.1.so) ==4724==by 0x400CFD2: _dl_map_object_deps (in /lib64/ld-2.11.1.so) ==4724==by 0x40032B3: dl_main (in /lib64/ld-2.11.1.so) ==4724==by 0x4014979: _dl_sysdep_start (in /lib64/ld-2.11.1.so) ==4724==by 0x40013D0: _dl_start (in /lib64/ld-2.11.1.so) ==4724==by 0x4000B07: ??? (in /lib64/ld-2.11.1.so) ==4724== ==4724== HEAP SUMMARY: ==4724== in use at exit: 0 bytes in 0 blocks ==4724== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==4724== ==4724== All heap blocks were freed -- no leaks are possible ==4724== ==4724== For counts of detected and suppressed errors, rerun with: -v ==4724== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Thanks for helping with this!
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #5 from tlcclt Thomas.L.Clune at nasa dot gov --- Ignore that output from Valgind. I was logged out between building and running, and failed to reload the appropriate environment. With the correct environment, I get a clean run from valgrind: valgrind ./a.out ==9886== Memcheck, a memory error detector ==9886== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==9886== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==9886== Command: ./a.out ==9886== --9886-- WARNING: Serious error when reading debug info --9886-- When reading debug info from /gpfsm/dhome/tclune/a.out: --9886-- Ignoring non-Dwarf2/3 block in .debug_info --9886-- WARNING: Serious error when reading debug info --9886-- When reading debug info from /usr/local/other/SLES11.1/gcc/4.9/lib64/libgfortran.so.3.0.0: --9886-- Ignoring non-Dwarf2/3 block in .debug_info … --9886-- Ignoring non-Dwarf2/3 block in .debug_info --9886-- WARNING: Serious error when reading debug info --9886-- When reading debug info from /usr/local/other/SLES11.1/gcc/4.9/lib64/libquadmath.so.0.0.0: --9886-- Ignoring non-Dwarf2/3 block in .debug_info Error - incorrect number of tests were run. ==9886== ==9886== HEAP SUMMARY: ==9886== in use at exit: 1 bytes in 1 blocks ==9886== total heap usage: 22 allocs, 21 frees, 11,835 bytes allocated ==9886== ==9886== LEAK SUMMARY: ==9886==definitely lost: 0 bytes in 0 blocks ==9886==indirectly lost: 0 bytes in 0 blocks ==9886== possibly lost: 0 bytes in 0 blocks ==9886==still reachable: 1 bytes in 1 blocks ==9886== suppressed: 0 bytes in 0 blocks ==9886== Rerun with --leak-check=full to see details of leaked memory ==9886== ==9886== For counts of detected and suppressed errors, rerun with: -v ==9886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
[Bug fortran/59654] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Wed, Jan 01, 2014 at 05:02:53AM +, Thomas.L.Clune at nasa dot gov wrote: Ignore that output from Valgind. I was logged out between building and running, and failed to reload the appropriate environment. With the correct environment, I get a clean run from valgrind: I like the other trace better. It suggested a memory corruption problem. ;) The trace here suggests to me that gfortran is losing a pointer somewhere. Unfortunately, I don't know much about the OO parts of gfortran.
