[Bug c++/39321] G++ remove cv qualifiers from typedefs during template instantiation
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-28 08:09 --- This is related to bug 37806. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321
[Bug target/39291] _Unwind_Backtrace fails.
--- Comment #5 from pluto at agmk dot net 2009-02-28 10:43 --- (In reply to comment #4) Created an attachment (id=17376) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17376action=view) [edit] testcase executable built on mingw32 testcase executable built on mingw32 attached yours u.exe works, but yours u.exe has differents size: 118 167 u-dw2.exe 115 557 u.exe u-dw2.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 54c4 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0030 00407000 00407000 5a00 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rdata0c28 00408000 00408000 5c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 0538 00409000 00409000 2**5 ALLOC 4 .idata0558 0040a000 0040a000 6a00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .CRT 0034 0040b000 0040b000 7000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .tls 0008 0040c000 0040c000 7200 2**2 CONTENTS, ALLOC, LOAD, DATA (...debug sections...) u.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 42f4 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0020 00406000 00406000 4800 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rdata0d30 00407000 00407000 4a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 00c8 00408000 00408000 2**3 ALLOC 4 .idata0374 00409000 00409000 5800 2**2 CONTENTS, ALLOC, LOAD, DATA (...debug sections...) as you can see my u-dw2.exe has more sections, so i assume that we're using different win32 crt. i'm using mingw-w64/svn compiled with i486-pc-mingw-gcc (solution proposed by K.Tietz). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39291
[Bug testsuite/39324] New: [4.4 Regression] FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O[1-3] -m64
At revision 144466 I see the following failures on powerpc-apple-darwin9: Running target unix/-m64 FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O1 FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O2 FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O3 -g FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -Os The tests passed at revision 144372. If I run the tests manually they pass: [karma] f90/bug% gcc44 -w -m64 -O3 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c -lm [karma] f90/bug% a.out [karma] f90/bug% gcc44 -w -m64 -O3 -fomit-frame-pointer -funroll-loops /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c -lm [karma] f90/bug% a.out The log file shows: Executing on host: /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/gcc/ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c -w -O0 -lm -m64 -o /opt/gcc/darwin_buildw/gcc/testsuite/gcc/nestfunc-3.x0 (timeout = 300) PASS: gcc.c-torture/execute/nestfunc-3.c compilation, -O0 Setting LD_LIBRARY_PATH to :/opt/gcc/darwin_buildw/gcc::/opt/gcc/darwin_buildw/gcc PASS: gcc.c-torture/execute/nestfunc-3.c execution, -O0 Executing on host: /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/gcc/ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c -w -O1 -lm -m64 -o /opt/gcc/darwin_buildw/gcc/testsuite/gcc/nestfunc-3.x1 (timeout = 300) PASS: gcc.c-torture/execute/nestfunc-3.c compilation, -O1 Setting LD_LIBRARY_PATH to :/opt/gcc/darwin_buildw/gcc::/opt/gcc/darwin_buildw/gcc FAIL: gcc.c-torture/execute/nestfunc-3.c execution, -O1 ... -- Summary: [4.4 Regression] FAIL: gcc.c-torture/execute/nestfunc- 3.c execution, -O[1-3] -m64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39324
[Bug middle-end/39318] internal compiler error: verify_stmts failed
--- Comment #5 from dominiq at lps dot ens dot fr 2009-02-28 11:17 --- The compilation flags in comment #2 should be gfc -c -fopenmp -fcray-pointer -fexceptions -O2 -ftree-vectorize adw_trajsp.f in order to get the ICE. The code compiles without -fopenmp. The code compiles with the flags in comments #0 or with -c -fopenmp -fcray-pointer -fexceptions -O2 -ftree-vectorize on powerpc-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug testsuite/39325] New: FAIL: gcc.misc-tests/linkage.c link
The last failure for gcc I have on i686-apple-darwin9 is with -m64: FAIL: gcc.misc-tests/linkage.c link The log file shows: Running /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.misc-tests/linkage.exp ... Executing on host: /Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc -B/Volumes/MacBook/opt/gcc/i686-darwin/gcc/ -w -c -m64 -o linkage-x.o /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.misc-tests/linkage-x.c(timeout = 300) cc -c /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.misc-tests/linkage-y.c /dev/null Executing on host: /Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc -B/Volumes/MacBook/opt/gcc/i686-darwin/gcc/ linkage-y.o linkage-x.o -lm -m64 -o linkage.exe(timeout = 300) ld warning: in linkage-y.o, file is not of required architecture^M Undefined symbols:^M _main, referenced from:^M start in crt1.10.5.o^M ld: symbol(s) not found^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: ld warning: in linkage-y.o, file is not of required architecture^M Undefined symbols:^M _main, referenced from:^M start in crt1.10.5.o^M ld: symbol(s) not found^M collect2: ld returned 1 exit status^M FAIL: gcc.misc-tests/linkage.c link testcase /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.misc-tests/linkage.exp completed in 0 seconds I don't understand why native_cflags is not set to -m64 (it is for -m32 and in both cases on powerpc-apple-darwin9). -- Summary: FAIL: gcc.misc-tests/linkage.c link Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39325
[Bug ada/39264] gnat.dg/pack3.adb fails on powerpc64/s390x
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-02-28 11:38 --- Is there a 64-bit GDB around on the machine? ebotca...@gcc40:~$ gdb pack3 GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux-gnu.../home/ebotcazou/pack3: not in executable format: File format not recognized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39264
[Bug testsuite/37578] Testsuite cannot tell systems with REAL(10) and REAL(16) apart
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-28 11:38 ---
Define an effective-target keyword xxx via check_effective_target_xxx in
gcc/testsuite/lib/target-supports.exp.
The only test I see is check_effective_target_fortran_large_real and it does
not distinguishes between real(10) and real(16):
# Return 1 if the target supports Fortran real kinds larger than real(8),
# 0 otherwise.
#
# When the target name changes, replace the cached result.
proc check_effective_target_fortran_large_real { } {
return [check_no_compiler_messages fortran_large_real executable {
! Fortran
integer,parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: x
x = cos (x)
end
}]
}
Using precision(x) in similar tests could be used for
check_effective_target_fortran_real_10 and
check_effective_target_fortran_real_16: precision(x)==18 for real(10) and is
larger than 30 for real(16) (31 on powerpc-apple-darwin9, 33 with ifort).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37578
[Bug ada/39264] gnat.dg/pack3.adb fails on powerpc64/s390x
--- Comment #4 from laurent at guerby dot net 2009-02-28 12:34 --- No debian lenny doesn't seem to provide one, I've compiling one in /opt/cfarm/gdb-6.8-64/bin but it doesn't work with the same messages than the one on sparc64... My question on the GDB list: http://sourceware.org/ml/gdb/2009-02/msg00175.html -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39264
[Bug ada/39264] gnat.dg/pack3.adb fails on powerpc64/s390x
--- Comment #5 from laurent at guerby dot net 2009-02-28 13:27 --- I recompiled gdb as 64 bits on gcc40 (same dir) and now it seems to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39264
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #21 from rob1weld at aol dot com 2009-02-28 14:10 --- (In reply to comment #20) Created an attachment (id=13766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13766action=view) [edit] Patch main configure script to use mpfr 2.2.1, also detect mpfr library and header version mismatch - submitted to gcc-patc...@gcc.gnu.org This also affects 'lto' (since the patch submitted was never applied). # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) # touch delete.c # gcc/xgcc -v -I/usr/local/include -B/usr/src/lto_build/prev-gcc/ delete.c 21 | head -29 | tail #include ... search starts here: /usr/src/lto_build/./prev-gcc/include /usr/src/lto_build/./prev-gcc/include-fixed /usr/local/include /usr/include End of search list. GNU C (lto merged with rev 144262) version 4.4.0 20090218 (experimental) [lto revision 144460] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.4.1-p1. warning: GMP header version 4.2.4 differs from library version 4.2.2. warning: MPFR header version 2.4.1-p1 differs from library version 2.3.1. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug c/39326] New: Segmentation fault with -O1, out of memory with -O2
I was trying to compile autogenerated by 'spiral' 'gap_TlnLv4.c' file (to be attached). Trying to compile it with /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -march=native -c /tmp/spiral-sergei/gap_TlnLv4.c -o gap_TlnLv4.o1 command line I got this: /tmp/spiral-sergei/gap_TlnLv4.c: In function âRDFT_49152_1â: /tmp/spiral-sergei/gap_TlnLv4.c:172282: internal compiler error: Segmentation fault Please submit a full bug report, . Before that, trying to compile it with /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O2 -fomit-frame-pointer -malign-double -fstrict-aliasing -march=native -c /tmp/spiral-sergei/gap_TlnLv4.c command I got this: cc1: out of memory allocating 4184025948 bytes after a total of 205533184 bytes . -- Summary: Segmentation fault with -O1, out of memory with -O2 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #1 from sergstesh at yahoo dot com 2009-02-28 15:29 --- Created an attachment (id=17377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377action=view) source file causing the failure The source is not preprocessed, it has only standard #include math.h in it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #2 from sergstesh at yahoo dot com 2009-02-28 15:32 --- My OS: Linux amdam2 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 i686 athlon i386 GNU/Linux - SUSE 10.3 in simple English; 'gcc' is self-built 'gcc-4.3.3'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #3 from sergstesh at yahoo dot com 2009-02-28 15:34 --- There is no failure with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug middle-end/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #10 from amylaar at gcc dot gnu dot org 2009-02-28 16:30 --- I appears the haifa scheduler doesn't know what to do with the lone use of (symbol_ref ap) so it ends up clogging the end of a basic block. Mike, as far as I can tell, you originally (in 1997) added the code to rs6000.md which is now in rs6000.c:rs6000_emit_move and emits a USE for SYMBOL_REFS that are the source of a move. (Search for Emit a USE operation). What is wrong with deleting constants that are not used? -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||meissner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #17 from bkorb at gnu dot org 2009-02-28 16:39 --- Bruce Korb left Veritas 3 years ago. It's called Symantec now anyway. -- bkorb at gnu dot org changed: What|Removed |Added CC|bkorb at veritas dot com|bkorb at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/39327] New: Incorrect addsub patterns in sse.md
SSE addsubpX does
Adds odd-numbered single-precision floating-point values of the first source
operand
(second operand) with the corresponding single-precision floating-point values
from
the second source operand (third operand); stores the result in the
odd-numbered
values of the destination operand (first operand). Subtracts the even-numbered
single-precision floating-point values from the second source operand from the
corresponding single-precision floating values in the first source operand;
stores the
result into the even-numbered values of the destination operand.
They are implemented as
(define_insn sse3_addsubv4sf3
[(set (match_operand:V4SF 0 register_operand =x)
(vec_merge:V4SF
(plus:V4SF
(match_operand:V4SF 1 register_operand 0)
(match_operand:V4SF 2 nonimmediate_operand xm))
(minus:V4SF (match_dup 1) (match_dup 2))
(const_int 5)))]
TARGET_SSE3
addsubps\t{%2, %0|%0, %2}
[(set_attr type sseadd)
(set_attr prefix_rep 1)
(set_attr mode V4SF)])
We have
@item (vec_merge:@var{m} @var{vec1} @var{vec2} @var{items})
This describes a merge operation between two vectors. The result is a vector
of mode @var{m}; its elements are selected from either @var{vec1} or
@var{vec2}. Which elements are selected is described by @var{items}, which
is a bit mask represented by a @code{const_int}; a zero bit indicates the
corresponding element in the result vector is taken from @var{vec2} while
a set bit indicates it is taken from @var{vec1}.
Is item bit reversed?
--
Summary: Incorrect addsub patterns in sse.md
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39327
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #4 from sergstesh at yahoo dot com 2009-02-28 17:23 --- FWIW, 'gcc-3.4.6', when run as /mnt/sdb8/sergei/AFSWD_debug/install/gcc-3.4.6/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -c /tmp/spiral-sergei/gap_TlnLv4.c -o gap_TlnLv4.o , fails with cc1: out of memory allocating 182853324 bytes after a total of 14716928 bytes message, not with segmentation fault like 'gcc-4.3.3'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug lto/39317] [lto] - cannot compute suffix of object files - cannot represent relocation type BFD_RELOC_64
--- Comment #6 from rob1weld at aol dot com 2009-02-28 17:34 --- I rebooted Debian and chose the 32-bit Kernel, then re-configured in an _identical_ manner. I rebuilt gcc (using un-modified source) with no extra effort with the 32-Bit Kernel. Host Compiler: # gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) Broken on 64-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Works on 32-bit: # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: i686-pc-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-multilib --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144460] (lto merged with rev 144262) Broken: x86_64-pc-linux-gnu Works: i686-pc-linux-gnu Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39317
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-28 17:48 --- I can't test your precompiled code, because c++ has changed in an incompatible way. Could you attach a current precompiled version using gcc4.4 of it? Is the problem still present on 4.4.0 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-28 17:57 --- Try -fno-move-loop-invariants. This is probably a killer on alias-improvements branch as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||compile-time-hog, memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-28 18:00 --- As this seems to be autogenerated from ! The SPL Program: (compose (sparse (coords (...12288 x 2 ...))(values (...1 x 12288 ...)))(compose (conjugate (..)(..))(compose (..)(.. ! node size: 12288 X 12288 can you produce a testcase with an order of magnitude less loads/stores? (thus likely just node size: 1228 x 1228)? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-28 18:10 --- One problem seems to be that we blow up the stack during GC recursing following the VUSE - def_stmt links. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug target/39327] Incorrect addsub/unpck patterns in sse.md
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-28 18:27 --- Item selectors in 256bit unpck patterns are also incorrect. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|Incorrect addsub patterns in|Incorrect addsub/unpck |sse.md |patterns in sse.md http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39327
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-02-28 18:33 --- Subject: Bug 37861 Author: jamborm Date: Sat Feb 28 18:33:27 2009 New Revision: 144491 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144491 Log: 2009-02-28 Martin Jambor mjam...@suse.cz Backport from mainline: 2008-12-02 Martin Jambor mjam...@suse.cz PR middle-end/37861 * tree-ssa-forwprop.c (forward_propagate_addr_into_variable_array_index): Check that the offset is not computed from a MULT_EXPR if element size is one. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug target/39327] Incorrect addsub/unpck patterns in sse.md
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39327
[Bug target/39327] Incorrect addsub/unpck patterns in sse.md
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-28 18:40 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01268.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg01268.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39327
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-28 18:41 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01267.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg01267.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug target/39146] Unnecessary stack alignment
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-28 18:51 --- (In reply to comment #12) Created an attachment (id=17305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17305action=view) [edit] New patch attached Test finished. No regression with emx_avx_sim. Wait to checkin to 4.5 Joey, please submit it for review, targeting gcc 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-28 18:55 --- Subject: Bug 39315 Author: hjl Date: Sat Feb 28 18:55:06 2009 New Revision: 144492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144492 Log: gcc/ 2009-02-28 H.J. Lu hongjiu...@intel.com PR middle-end/39315 * cfgexpand.c (expand_one_stack_var_at): Change alignment limit to MAX_SUPPORTED_STACK_ALIGNMENT. gcc/testsuite/ 2009-02-28 H.J. Lu hongjiu...@intel.com PR middle-end/39315 * gcc.target/i386/pr39315-1.c: New. * gcc.target/i386/pr39315-2.c: Likewise. * gcc.target/i386/pr39315-3.c: Likewise. * gcc.target/i386/pr39315-4.c: Likewise. * gcc.target/i386/pr39315-check.c: Likewise. Added: branches/stack/gcc/testsuite/gcc.target/i386/pr39315-1.c branches/stack/gcc/testsuite/gcc.target/i386/pr39315-2.c branches/stack/gcc/testsuite/gcc.target/i386/pr39315-3.c branches/stack/gcc/testsuite/gcc.target/i386/pr39315-4.c branches/stack/gcc/testsuite/gcc.target/i386/pr39315-check.c Modified: branches/stack/gcc/ChangeLog.stackalign branches/stack/gcc/cfgexpand.c branches/stack/gcc/testsuite/ChangeLog.stackalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug c/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-28 20:01 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01274.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg01274.html Target Milestone|4.4.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39323
[Bug debug/39267] gdb testusite regressions
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-02-28 21:34 --- Subject: Bug 39267 Author: hubicka Date: Sat Feb 28 21:34:23 2009 New Revision: 144496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144496 Log: PR debug/39267 * cgraph.h (varpool_output_debug_info): Remove. * cgraphunit.c (varpool_output_debug_info): Remove. * dwarf2out.c (deferred_locations_struct): New struct (deferred_locations): New type. (deferred_locations_list): New static var. (deffer_location): New function. (gen_variable_die): Use it. (decls_for_scope): Output info on local static vars. (dwarf2out_finish): Process deferred locations. * varpool.c (varpool_output_debug_info): Remove. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/static1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varpool.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39267
[Bug target/39146] Unnecessary stack alignment
--- Comment #15 from hjl dot tools at gmail dot com 2009-02-28 21:43 --- (In reply to comment #14) (In reply to comment #12) Created an attachment (id=17305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17305action=view) [edit] New patch attached Test finished. No regression with emx_avx_sim. Wait to checkin to 4.5 Joey, please submit it for review, targeting gcc 4.5. Joey, please also include a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39327] Incorrect addsub/unpck patterns in sse.md
--- Comment #3 from hjl at gcc dot gnu dot org 2009-02-28 22:29 --- Subject: Bug 39327 Author: hjl Date: Sat Feb 28 22:29:25 2009 New Revision: 144498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144498 Log: 2009-02-28 H.J. Lu hongjiu...@intel.com PR target/39327 * config/i386/sse.md (avx_addsubv8sf3): Correct item bits. (avx_addsubv4df3): Likewise. (*avx_addsubv4sf3): Likewise. (sse3_addsubv4sf3): Likewise. (*avx_addsubv2df3): Likewise. (sse3_addsubv2df3): Likewise. (avx_unpckhps256): Correct item selectors. (avx_unpcklps256): Likewise. (avx_unpckhpd256): Likewise. (avx_unpcklpd256): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39327
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
--- Comment #14 from jamborm at gcc dot gnu dot org 2009-02-28 22:46 --- Fixed with revision 144491: te: Sat Feb 28 18:33:27 2009 New Revision: 144491 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144491 Log: 2009-02-28 Martin Jambor mjam...@suse.cz Backport from mainline: 2008-12-02 Martin Jambor mjam...@suse.cz PR middle-end/37861 * tree-ssa-forwprop.c (forward_propagate_addr_into_variable_array_index): Check that the offset is not computed from a MULT_EXPR if element size is one. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-forwprop.c -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug c++/39328] New: ambiguous implicit declaration of template friend function
The following code generates two different, ambiguous declarations of foo. I
guess this is regression, as other compilers accept the code.
I am using gcc 4-3-3
templateclass A,templateclassclass B void foo(BA)
{
}
templateclass class bar
{
templateclass A,templateclassclass B friend void foo(BA);
};
int main(int num_arguments, char* arguments[])
{
foo(barint());
/*error: call of overloaded 'foo(barint)' is ambiguous
n:298: note: candidates are: void foo(BA) [with A = int, B = bar]
n:303: note: void foo(BA) [with A = int, B = bar,
template-parameter-1-1 = int]*/
}
--
Summary: ambiguous implicit declaration of template friend
function
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrhelt at yahoo dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39328
[Bug target/39329] New: x86 -Os could use mulw for (uint16 * uint16)16
Using 'gcc -Os -fomit-frame-pointer -march=core2 -mtune=core2' for
unsigned short mul_high_c(unsigned short a, unsigned short b)
{
return (unsigned)(a * b) 16;
}
unsigned short mul_high_asm(unsigned short a, unsigned short b)
{
unsigned short res;
asm(mulw %w2 : =d(res),+a(a) : rm(b));
return res;
}
I get
_mul_high_c:
subl$12, %esp
movzwl 20(%esp), %eax
movzwl 16(%esp), %edx
addl$12, %esp
imull %edx, %eax
shrl$16, %eax
ret
_mul_high_asm:
subl$12, %esp
movl16(%esp), %eax
mulw 20(%esp)
addl$12, %esp
movl%edx, %eax
ret
mulw puts its outputs in dx:ax, and dx contains (dx:ax)16, so the shift is
avoided.
Ignoring the weird Darwin stack adjustment code, the version with mulw is
somewhat shorter and avoids a movzwl. I'm not sure what the performance
difference is; mulw is listed in Agner's tables as fairly low latency, but
requires a length changing prefix for memory.
This type of operation is useful in fixed-point math, such as embedded audio
codecs or arithmetic coders.
--
Summary: x86 -Os could use mulw for (uint16 * uint16)16
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC build triplet: i?86-*-*
GCC host triplet: i?86-*-*
GCC target triplet: i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39329
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #8 from sergstesh at yahoo dot com 2009-03-01 03:03 --- Created an attachment (id=17378) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378action=view) a smaller file with hopefully the same pattern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #9 from sergstesh at yahoo dot com 2009-03-01 03:06 --- (In reply to comment #6) As this seems to be autogenerated from ! The SPL Program: (compose (sparse (coords (...12288 x 2 ...))(values (...1 x 12288 ...)))(compose (conjugate (..)(..))(compose (..)(.. ! node size: 12288 X 12288 can you produce a testcase with an order of magnitude less loads/stores? (thus likely just node size: 1228 x 1228)? Thanks! I've uploaded a smaller file: gap_bzAJWH.c.gz . These are intermediated files which are deleted upon successful compilation. So, I've decreased the number the points and managed to catch this one. It is: node size: 1536 X 1536. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #10 from sergstesh at yahoo dot com 2009-03-01 03:09 --- I am not sure whether it's clear - the smaller 'gap_bzAJWH.c.gz' file can be found as http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378action=view attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #11 from sergstesh at yahoo dot com 2009-03-01 03:54 --- (In reply to comment #5) Try -fno-move-loop-invariants. This is probably a killer on alias-improvements branch as well. Still segfault: gap_TlnLv4.c: In function âRDFT_49152_1â: gap_TlnLv4.c:172282: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. real33m52.152s user16m47.843s sys 0m9.333s [1] Exit 1 time /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -fno-move-loop-invariants -c gap_TlnLv4.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39330] New: Bad program bahavior with -O2 optimization in plain C
There is a bug in the gcc compiler for the C code that changes the behavior of a simple program with -O2 optimizations, but not with -O1 or -O0. The attached code is a small implementation of the qsort algorithm over an array of 5 elements of 64bits; compared using only 32bits of those 64bits. This simple code exposes a bug in the compiler in the first call to this function. The problem COULD be with a variable optimized out caching and old value. There are two test cases. One with debug information (printf of some values) and other smaller, minimal test case. In both test cases, the qsort algorithm should sort a vector of five elements: 5 4 3 2 1. In the first iteration the algorithm divides the vector in 1 (left part), 2 (pivot) and 3 4 5 (right part, already in the right order). There is a detailed explanation (a the end of this description) that explains why this is an incorrect behavior of the compiler. The problem is that in the second iteration of a while loop, a comparation vcp vp where vcp is 1 and vp is 2 get false as result, probably because the vcp variable was optimized, and in the first iteration it's value was 5. Some strange things: * A printf(%d, vcp); at the right place fixes the bug, probably because vcp is not cached in a registry anymore. I can confirm the same bug in a x86_64 architecture with the same version (ubuntu 8.04.2). /** Explanation: * There are 3 pointers: bp, cp and ep. * The parameters b and e define a buffer in memory (begin and end). * There are 2 values: vp and vcp. * - vp is the value of the pivot and is written only once in the function * - vcp is the value of the cp pointer (not *cp !). * A value is a variable of type tipoval which is used to compare elements * of type tipo. * In this case, we have a datatype of 8bytes (tipo), and we compare them * by the first 4bytes (tipoval) value. * * For the first call: * The difference e-b is 5 (five uint64 elements) * vp = 2; (as shown in the debug output) * bp = b; cp = b; and ep = e; at the begin [1]. * * At the point [1]: (shown in debug output) * * cp = b+0, bp = b+0, and ep = b+5 * * vector values are 5 4 3 2 1 * * Since the value of ep-1 is 1 (the last value of the vector), * the while loop between [1] and [2] executes no iteration. 2 1 is false. * Until here the compiled program is ok. * * At the point [2]: (shown in debug output) * * the state is the same as in [1]. * * Then, we enter in the second while loop for the first time: * while(cp ep) since cp=b+0 and ep=b+5. * At the first iteration, vcp = 5 (the first value in the vector). * Here we compare three options: [3] vcp vp; [4] vcp == vp; or in other case [5] vcp vp. * Since vcp == 5 and vp == 2, we enter in the third case ( Ref [5] ). * ep is decremented and now ep = b+4, and the elements at positions 0 and 4 swapped * (remember, cp is b+0). The new values of vector order is 1 4 3 2 5 * Note: The invariant here is: Everything between [ep , e) (as a range left * closed but right open) is strictly greater than the pivot vp. * * The while loop inside the [5] case is identical to the first one in the * function. Again it doesn't enter because the value of ep-1 is VL(b+3) * which is now 2, the same as the pivot vp. Then, 2 2 is false. * We exit from the if case [5] and iterate again the main while loop, back * to point [2]. * * We enter again in the main while loop at point [2] because cp == b+0 * and ep = b+4. * Remembering, vector values are 1 4 3 2 5; so now vcp is 1. * Note: Until here I can check the correctness of the binary file with a debugger *(gdb), but print vcp fails because No symbol vcp in current context. *Optimizations here have done something. *Take in mind that from the las iteration, cp was not change, but *cp was *swapped with the last value of the vector. * Backing to the code, vcp = 1 and vp = 2, so we are in the case [3] (vcp vp) * In this case, no value is swapped because bp == cp, but both bp and cp are * incremented. * Note: The invariant here is all the values in [b, bp) a strictly lower than * the pivot vp. * * BUT! That's not what the code does. HERE IS THE BUG (or at least, the symptom). * * The code apparently enters in the case[5], since ep is decremented according * the debugger. Indeed, cp at the end of the main while loop (Ref [6]) is still * cp=b, so the never reaches the cases [3] or [4], because in both cases cp is * incremented. * * IMHO, the problem is that vcp was not properly updated in the second iteration * and it probably stil is 5. * * Work-around: * * * If you put a printf(%u\n, vcp); inside the main while loop, *the bug is not expressed and the program works well. * * * If you remove the __attribute__((always_inline)) for the function *VL, again the bug is not expressed. * * * If you replace the function VL with a #define, the bug is also *present. This doesn't fix the
[Bug c/39330] Bad program bahavior with -O2 optimization in plain C
--- Comment #1 from adeymo at dc dot uba dot ar 2009-03-01 05:05 --- Created an attachment (id=17379) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17379action=view) Testcase with debug information and explanation Compile with: gcc -save-temps -O2 -Wall -Werror xqsort.c -o xqsort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39330
[Bug c/39330] Bad program bahavior with -O2 optimization in plain C
--- Comment #2 from adeymo at dc dot uba dot ar 2009-03-01 05:06 --- Created an attachment (id=17380) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17380action=view) Testcase smaller and simpler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39330
[Bug c/39330] Bad program bahavior with -O2 optimization in plain C
--- Comment #3 from adeymo at dc dot uba dot ar 2009-03-01 05:08 --- (From update of attachment 17380) Compile with: gcc -save-temps -O2 -Wall -Werror xqsort-small.c -o xqsort-small Run with: ./xqsort-small echo ok If compiled with -O1 , the echo command must be executed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39330
