[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty
--- Comment #10 from paolo dot carlini at oracle dot com 2009-11-29 08:34 --- Stefan is right. The issue, in full generality, isn't trivial at all, there is now a new discussion on the library reflector. I'm under the impression that for C++0x we are not going to standardize the minimum load factor suggested by Matt, seems much more likely that erase will be just changed to return void, there is a growing consensus about that. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-29 08:34:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug tree-optimization/42211] New: Segmentation fault with graphite -floop-interchange
gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc45/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc45/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.2.0 Configured with: ../gcc/configure --prefix=/usr/local/gcc45 --enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw --with-mpfr=/sw --with-ppl=/sw --with-cloog=/sw --with-libelf=/sw --disable-nls --disable-bootstrap LDFLAGS=/usr/lib/libiconv.dylib --enable-languages=c,c++,lto,objc,obj-c++ Thread model: posix gcc version 4.5.0 20091129 (experimental) (GCC) Using r154734. With attached source: gcc -O3 -floop-interchange -S graphite_crash.i graphite_crash.i: In function 'border_mirror_480': graphite_crash.i:17:6: 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. It doesn't happen reliably to me with -v -Q, so I can't check with gdb. Valgrind gives: ==12758== Invalid read of size 8 ==12758==at 0x1004AE4A3: lst_do_interchange_1 (graphite-interchange.c:709) ==12758==by 0x1004AE525: lst_do_interchange (graphite-interchange.c:730) ==12758==by 0x1004AE58A: lst_do_interchange (graphite-interchange.c:734) ==12758==by 0x1004AE5CA: scop_do_interchange (graphite-interchange.c:748) ==12758==by 0x1004AF4C7: apply_poly_transforms (graphite-poly.c:260) ==12758==by 0x1004A01A1: graphite_transform_loops (graphite.c:276) ==12758==by 0x100736B09: graphite_transforms (tree-ssa-loop.c:300) ==12758==by 0x10057D522: execute_one_pass (passes.c:1522) ==12758==by 0x10057D7CC: execute_pass_list (passes.c:1577) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) ==12758==by 0x1006AAA80: tree_rest_of_compilation (tree-optimize.c:408) ==12758== Address 0x141c25210 is 16 bytes inside a block of size 24 free'd ==12758==at 0x140EB88DC: free (vg_replace_malloc.c:325) ==12758==by 0x1004AE00C: lst_try_interchange (graphite-poly.h:704) ==12758==by 0x1004AE49F: lst_do_interchange_1 (graphite-interchange.c:710) ==12758==by 0x1004AE525: lst_do_interchange (graphite-interchange.c:730) ==12758==by 0x1004AE58A: lst_do_interchange (graphite-interchange.c:734) ==12758==by 0x1004AE5CA: scop_do_interchange (graphite-interchange.c:748) ==12758==by 0x1004AF4C7: apply_poly_transforms (graphite-poly.c:260) ==12758==by 0x1004A01A1: graphite_transform_loops (graphite.c:276) ==12758==by 0x100736B09: graphite_transforms (tree-ssa-loop.c:300) ==12758==by 0x10057D522: execute_one_pass (passes.c:1522) ==12758==by 0x10057D7CC: execute_pass_list (passes.c:1577) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) ==12758== ==12758== Invalid read of size 8 ==12758==at 0x1004AE534: lst_do_interchange (graphite-interchange.c:732) ==12758==by 0x1004AE58A: lst_do_interchange (graphite-interchange.c:734) ==12758==by 0x1004AE5CA: scop_do_interchange (graphite-interchange.c:748) ==12758==by 0x1004AF4C7: apply_poly_transforms (graphite-poly.c:260) ==12758==by 0x1004A01A1: graphite_transform_loops (graphite.c:276) ==12758==by 0x100736B09: graphite_transforms (tree-ssa-loop.c:300) ==12758==by 0x10057D522: execute_one_pass (passes.c:1522) ==12758==by 0x10057D7CC: execute_pass_list (passes.c:1577) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) ==12758==by 0x1006AAA80: tree_rest_of_compilation (tree-optimize.c:408) ==12758==by 0x100866F56: cgraph_expand_function (cgraphunit.c:1178) ==12758== Address 0x141c25210 is 16 bytes inside a block of size 24 free'd ==12758==at 0x140EB88DC: free (vg_replace_malloc.c:325) ==12758==by 0x1004AE00C: lst_try_interchange (graphite-poly.h:704) ==12758==by 0x1004AE49F: lst_do_interchange_1 (graphite-interchange.c:710) ==12758==by 0x1004AE525: lst_do_interchange (graphite-interchange.c:730) ==12758==by 0x1004AE58A: lst_do_interchange (graphite-interchange.c:734) ==12758==by 0x1004AE5CA: scop_do_interchange (graphite-interchange.c:748) ==12758==by 0x1004AF4C7: apply_poly_transforms (graphite-poly.c:260) ==12758==by 0x1004A01A1: graphite_transform_loops (graphite.c:276) ==12758==by 0x100736B09: graphite_transforms (tree-ssa-loop.c:300) ==12758==by 0x10057D522: execute_one_pass (passes.c:1522) ==12758==by 0x10057D7CC: execute_pass_list (passes.c:1577) ==12758==by 0x10057D7DE: execute_pass_list (passes.c:1578) -- Summary: Segmentation fault with graphite -floop-interchange Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: astrange at ithinksw dot com GCC build triplet: x86_64-apple
[Bug tree-optimization/42211] Segmentation fault with graphite -floop-interchange
--- Comment #1 from astrange at ithinksw dot com 2009-11-29 09:38 --- Created an attachment (id=19175) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19175action=view) somewhat-reduced source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42211
[Bug testsuite/42212] New: [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.
Between revisions 154648 and 154667, the following error appeared: ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp. ERROR: unmatched open brace in list (see http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02500.html and http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02531.html). -- Summary: [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn- gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp. Product: gcc Version: 4.5.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=42212
[Bug ada/42213] New: GCC chkstk clash with Microsoft version
The Win64 version of the libkernel32.a import library defined ___chkstk. This routine is also defined in i386/cygwin.asm. The later preserve important registers whereas the Microsoft version probably does not. Anyway, this has proved to create a breakage into the GNAT compiler. It seems that this name clash is quite dangerous and should be avoided. A possible solution would be to rename the GCC version to ___gcc_chkstk. Would this work? Before summiting a patch I'd like your input about this. Thanks. -- Summary: GCC chkstk clash with Microsoft version Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot obry at wanadoo dot fr GCC host triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug inline-asm/42214] New: gcc generates broken code with -O=1 for x86_64 after an asm call
When using -O=1, gcc uses the wrong register for the inline assembly below. In
my actual usecase, it even does
bswap %eax
xorl %eax, %eax
so it instantly threw away the value. When using -m32, it seems to generate
correct code.
== CODE FILES ==
asgard:/tmp$ cat x.c
#include stdint.h
uint32_t
x()
{
return 0x11223344;
}
asgard:/tmp$ cat test.c
#include stdint.h
#include stdio.h
extern uint32_t x();
static inline __attribute__((always_inline))
bswap32(uint32_t i)
{
asm(bswap %0 : =q(i) : q(i));
return i;
}
int
main()
{
printf(%08X\n, bswap32(x()));
return 0;
}
== OUTPUT ==
asgard:/tmp$ gcc test.c x.c
asgard:/tmp$ ./a.out
44332211
asgard:/tmp$ gcc -O1 test.c x.c
asgard:/tmp$ ./a.out
381E625D
== ASSEMBLY OUTPUT (only important parts) ==
asgard:/tmp$ gcc -S test.c
asgard:/tmp$ cat test.s
[
]
movl$0, %eax
callx
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
#APP
# 9 test.c 1
bswap %eax
# 0 2
#NO_APP
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edx
movl$.LC0, %eax
movl%edx, %esi
movq%rax, %rdi
movl$0, %eax
callprintf
[
]
asgard:/tmp$ gcc -S -O1 test.c
asgard:/tmp$ cat test.s
[
]
movl$0, %eax
callx
#APP
# 9 test.c 1
bswap %edx
# 0 2
#NO_APP
movl$.LC0, %esi
movl$1, %edi
movl$0, %eax
call__printf_chk
[
]
--
Summary: gcc generates broken code with -O=1 for x86_64 after an
asm call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: js-gcc at webkeks dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42214
[Bug middle-end/42193] [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-27 10:36:38 |2009-11-29 12:24:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42193
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-29 12:31 --- (In reply to comment #2) On darwin, the errors appear only in 32 bit mode. Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the fortran testsuite for the fortran-dev branch on darwin, but saw no failures. Here is a reduced test case: module m implicit none type foo end type type ,extends(foo) :: bar end type contains function new_bar() class(foo) ,pointer :: new_bar allocate(bar :: new_bar) end function end module Important: This only happens inside a module. If I remove the module m/end module in the example, the error goes away. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2009-11-29 12:31:41 date|| Summary|Compile-time errors on typed|[OOP] Compile-time errors on |allocation and pointer |typed allocation and pointer |function result assignment |function result assignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug tree-optimization/42215] New: [4.5 Regression] internal compiler error: verify_stmts failed with -O2 -ftree-loop-distribution
Compiler flags: -O2 -ftree-loop-distribution
Tested revisions:
trunk r154706 (20091127) - crash
trunk r153685 (20091028) - crash
4.4 r153668, r154724 - OK
file.c
extern int A[];
extern int B[];
void f(int i)
{
while (i-- 0) {
A[i] = 0;
B[i] = 0;
}
}
=
$ /mnt/svn/gcc-trunk/binary-154706-lto/bin/gcc -O2 -ftree-loop-distribution -c
file.c -o tmp.o -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-154706-lto/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-154706-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,lto
--prefix=/mnt/svn/gcc-trunk/binary-154706-lto
Thread model: posix
gcc version 4.5.0 20091127 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-ftree-loop-distribution' '-c' '-o' 'tmp.o' '-v'
'-mtune=generic'
/mnt/svn/gcc-trunk/binary-154706-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-quiet -v file.c -quiet -dumpbase file.c -mtune=generic -auxbase-strip tmp.o
-O2 -version -ftree-loop-distribution -o /tmp/ccGTZYvH.s
GNU C (GCC) version 4.5.0 20091127 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091127 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/mnt/svn/gcc-trunk/binary-154706-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/mnt/svn/gcc-trunk/binary-154706-lto/include
/mnt/svn/gcc-trunk/binary-154706-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include
/mnt/svn/gcc-trunk/binary-154706-lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.5.0 20091127 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091127 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6ceb3c4a53027ce4dbc9ea8fb31afa70
file.c: In function #8216;f#8217;:
file.c:4:6: error: type mismatch in binary expression
long unsigned int
unnamed-signed:64
long unsigned int
D.2734_16 = D.2733_15 - D.2730_10;
file.c:4:6: error: type mismatch in binary expression
long unsigned int
unnamed-signed:64
long unsigned int
D.2742_24 = D.2741_23 - D.2738_20;
file.c:4:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.5 Regression] internal compiler error: verify_stmts
failed with -O2 -ftree-loop-distribution
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42215
[Bug tree-optimization/42215] [4.5 Regression] internal compiler error: verify_stmts failed with -O2 -ftree-loop-distribution
--- Comment #1 from zsojka at seznam dot cz 2009-11-29 12:41 --- Created an attachment (id=19176) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19176action=view) source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42215
[Bug tree-optimization/42209] missed optimization leads to several times slower code
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:54 --- GCC has to weight code-size and compile-time increase against performance improvements when deciding on inlining functions. For the call in the loop GCC assumes it is more beneficial to do the inlining compared to the calls outside of the loop. With the calls outside of the loop the limits set for overall unit or function growth are reached. You can get diagnostics about this when you declare the function inline and use -Winline. If you are sure that always inlining a function is beneficial you can declare it with __attribute__((always_inline)). You can also force all calls in a function to be inlined by declaring that function with __attribute__((flatten)). GCC 4.5 inlines all calls if switch_case is declared inline, 4.4 produces $ g++-4.4 -O3 t.C -Winline t.C: In function void slow(unsigned int*, const unsigned int*): t.C:36: warning: inlining failed in call to word_t switch_case(op_t, word_t, word_t, word_t) [with word_t = unsigned int]: call is unlikely and code size would grow t.C:67: warning: called from here t.C:36: warning: inlining failed in call to word_t switch_case(op_t, word_t, word_t, word_t) [with word_t = unsigned int]: call is unlikely and code size would grow t.C:79: warning: called from here As 4.5 works it's unlikely to be fixed unless some of the profile fixes also apply to 4.4 - Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c++ |tree-optimization Keywords||missed-optimization Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
[Bug testsuite/42212] [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42212
[Bug target/42213] GCC chkstk clash with Microsoft version
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:58 --- Please try to verify if the issue has been addressed in GCC 4.4 or GCC 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|x86_64-pc-mingw32 | GCC target triplet||x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug testsuite/42212] [4.5 Regression] ERROR: tcl error sourcing /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp.
--- Comment #1 from dominiq at lps dot ens dot fr 2009-11-29 13:01 --- See also http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02574.html for powerpc64-unknown-linux-gnu. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||janis187 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42212
[Bug inline-asm/42214] gcc generates broken code with -O=1 for x86_64 after an asm call
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 13:03 --- well, asm(bswap %0 : =q(i) : q(i)); is wrong. You probably want asm(bswap %0 : =q(i) : 0(i)); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42214
[Bug tree-optimization/42215] [4.5 Regression] internal compiler error: verify_stmts failed with -O2 -ftree-loop-distribution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42215
[Bug target/42213] GCC chkstk clash with Microsoft version
--- Comment #2 from pascal dot obry at wanadoo dot fr 2009-11-29 13:08 --- Subject: Re: GCC chkstk clash with Microsoft version Le 29/11/2009 13:58, rguenth at gcc dot gnu dot org a écrit : --- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 12:58 --- Please try to verify if the issue has been addressed in GCC 4.4 or GCC 4.5. Nothing has changed in this area. The symbol __chkstk is still defined in latest GCC sources. Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug tree-optimization/42216] New: [4.5 Regression] 464.h265ref peak regressed 20%
See http://gcc.opensuse.org/SPEC/CINT/sb-balakirew-head-64-2006/recent.html First bad rev. is 154713, last good is 154686. It's quite obvious that either the regrename.c changes have code generation differences or that removing the vec_interleave_* expanders caused this regression. Richard - you removed all vec_interleave_* expanders but the vectorizer still checks for optab_for_tree_code (VEC_INTERLEAVE_*_EXPR) which ends up looking at vec_interleave_*_optab. Either this code is all dead now or you caused the vectorization no longer to apply. I'll check if reverting your revision gets back performance. -- Summary: [4.5 Regression] 464.h265ref peak regressed 20% Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug tree-optimization/42216] [4.5 Regression] 464.h265ref peak regressed 20%
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug target/42210] avr: optimizing assignment to a bit field
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-11-29 14:35
---
Same on 4.5 Head.
The backend patterns match against MEM AND singlebit.
Combine never considers this.
Incoming RTL and Combine pass dump file extract:
;; Pred edge ENTRY [100.0%] (fallthru)
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 rot.c:25 (set (reg/v:QI 41 [ flag ])
(reg:QI 24 r24 [ flag ])) 4 {*movqi} (expr_list:REG_DEAD (reg:QI 24 r24
[ flag ])
(nil)))
(note 3 2 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 3 8 2 rot.c:26 (set (reg:QI 43)
(and:QI (reg/v:QI 41 [ flag ])
(const_int 1 [0x1]))) 43 {andqi3} (expr_list:REG_DEAD (reg/v:QI 41
[ flag ])
(nil)))
(insn 8 7 9 2 rot.c:26 (set (reg:QI 44)
(ashift:QI (reg:QI 43)
(const_int 6 [0x6]))) 59 {*ashlqi3} (expr_list:REG_DEAD (reg:QI 43)
(nil)))
(insn 9 8 10 2 rot.c:26 (set (reg:QI 45)
(mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])) 4 {*movqi} (nil))
(insn 10 9 11 2 rot.c:26 (set (reg:QI 46)
(and:QI (reg:QI 45)
(const_int -65 [0xffbf]))) 43 {andqi3} (expr_list:REG_DEAD
(reg:QI 45)
(nil)))
(insn 11 10 12 2 rot.c:26 (set (reg:QI 47)
(ior:QI (reg:QI 46)
(reg:QI 44))) 46 {iorqi3} (expr_list:REG_DEAD (reg:QI 46)
(expr_list:REG_DEAD (reg:QI 44)
(nil
(insn 12 11 0 2 rot.c:26 (set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(reg:QI 47)) 4 {*movqi} (expr_list:REG_DEAD (reg:QI 47)
(nil)))
;; End of basic block 2 - ( 1)
Trying 2 - 7:
Successfully matched this instruction:
(set (reg:QI 43)
(and:QI (reg:QI 24 r24 [ flag ])
(const_int 1 [0x1])))
deferring deletion of insn with uid = 2.
modifying insn i3 7 r43:QI=r24:QI0x1
REG_DEAD: r24:QI
deferring rescan insn with uid = 7.
Trying 7 - 8:
Failed to match this instruction:
(set (reg:QI 44)
(and:QI (ashift:QI (reg:QI 24 r24 [ flag ])
(const_int 6 [0x6]))
(const_int 64 [0x40])))
Trying 9 - 10:
Failed to match this instruction:
(set (reg:QI 46)
(and:QI (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(const_int -65 [0xffbf])))
Trying 8 - 11:
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (ashift:QI (reg:QI 43)
(const_int 6 [0x6]))
(reg:QI 46)))
Trying 10 - 11:
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (and:QI (reg:QI 45)
(const_int -65 [0xffbf]))
(reg:QI 44)))
Trying 7, 8 - 11:
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (and:QI (ashift:QI (reg:QI 24 r24 [ flag ])
(const_int 6 [0x6]))
(const_int 64 [0x40]))
(reg:QI 46)))
Failed to match this instruction:
(set (reg:QI 44)
(and:QI (ashift:QI (reg:QI 24 r24 [ flag ])
(const_int 6 [0x6]))
(const_int 64 [0x40])))
Trying 9, 10 - 11:
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (and:QI (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(const_int -65 [0xffbf]))
(reg:QI 44)))
Failed to match this instruction:
(set (reg:QI 46)
(and:QI (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(const_int -65 [0xffbf])))
Trying 10, 8 - 11:
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (and:QI (reg:QI 45)
(const_int -65 [0xffbf]))
(ashift:QI (reg:QI 43)
(const_int 6 [0x6]
Successfully matched this instruction:
(set (reg:QI 46)
(ashift:QI (reg:QI 43)
(const_int 6 [0x6])))
Failed to match this instruction:
(set (reg:QI 47)
(ior:QI (and:QI (reg:QI 45)
(const_int -65 [0xffbf]))
(reg:QI 46)))
Trying 11 - 12:
Failed to match this instruction:
(set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(ior:QI (reg:QI 46)
(reg:QI 44)))
Trying 8, 11 - 12:
Failed to match this instruction:
(set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(ior:QI (ashift:QI (reg:QI 43)
(const_int 6 [0x6]))
(reg:QI 46)))
Successfully matched this instruction:
(set (reg:QI 47)
(ashift:QI (reg:QI 43)
(const_int 6 [0x6])))
Failed to match this instruction:
(set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(ior:QI (reg:QI 47)
(reg:QI 46)))
Trying 10, 11 - 12:
Failed to match this instruction:
(set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(ior:QI (and:QI (reg:QI 45)
(const_int -65 [0xffbf]))
(reg:QI 44)))
Successfully matched this instruction:
(set (reg:QI 47)
(and:QI (reg:QI 45)
(const_int -65 [0xffbf])))
Failed to match this instruction:
(set (mem/s/j:QI (const_int 35 [0x23]) [0 S1 A8])
(ior:QI (reg:QI 47)
(reg:QI 44)))
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global set_flag_good
.type set_flag_good, @function
set_flag_good:
/* prologue:
[Bug middle-end/42217] New: [4.5 Regression] ICE with zero-length bit-field
The following valid code snippet triggers an ICE on trunk:
==
struct A
{
int : 0;
};
A a = A();
==
bug.cc:6:9: internal compiler error: in int_or_pointer_precision, at
tree.c:10593
Please submit a full bug report, [etc.]
--
Summary: [4.5 Regression] ICE with zero-length bit-field
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
[Bug middle-end/42217] [4.5 Regression] ICE with zero-length bit-field
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
[Bug c++/42218] New: [4.5 Regression] Broken diagnostic: 'tree_vec' not supported by pp_c_expression
A broken diagnostic is issued for the following invalid code snippet on trunk:
templateint struct A
{
templateint struct B;
};
int i = A0::B0::X::Y;
bug.cc:6:21: error: 'A0::B#'tree_vec' not supported by pp_c_expression#,
#'tree_vec' not supported by pp_c_expression#::X' has not been declared
GCC 4.3.x and 4.4.x issue a sensible error message:
bug.cc:6: error: 'A::B::X' has not been declared
GCC 4.2.x issues an even better error message:
bug.cc:6: error: 'struct A0::B0::X' has not been declared
--
Summary: [4.5 Regression] Broken diagnostic: 'tree_vec' not
supported by pp_c_expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
[Bug c++/42218] [4.5 Regression] Broken diagnostic: 'tree_vec' not supported by pp_c_expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
[Bug c++/42218] [4.5 Regression] Broken diagnostic: 'tree_vec' not supported by pp_c_expression
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 15:42 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-11-29 15:42:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42218
[Bug c++/42217] [4.5 Regression] ICE with zero-length bit-field
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 15:45 --- Confirmed. C++ issue. It calls convert_to_integer with #9 0x082b3dd6 in ocp_convert (type=0xb7d48ba0, expr=0xb7cac5b8, convtype=15, flags=35) at /home/richard/src/trunk/gcc/cp/cvt.c:700 700 return fold_if_not_in_template (convert_to_integer (type, e)); (gdb) p e $1 = (tree) 0xb7cac5b8 (gdb) call debug_tree ($1) integer_cst 0xb7cac5b8 type integer_type 0xb7cc02a0 int constant 0 (gdb) p type $2 = (tree) 0xb7d48ba0 (gdb) call debug_tree ($2) integer_type 0xb7d48ba0 QI size integer_cst 0xb7cac138 type integer_type 0xb7cc0060 bit_size_type constant 8 unit size integer_cst 0xb7cac150 type integer_type 0xb7cc unsigned int constant 1 align 8 symtab 0 alias set -1 canonical type 0xb7d48ba0 precision 0 min integer_cst 0xb7d425b8 -2147483648 max integer_cst 0xb7d42b88 2147483647 thus an integer type with TYPE_PRECISION zero. That's invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |c++ Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-11-29 15:45:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42217
[Bug c++/42038] [4.3/4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #6 from reichelt at gcc dot gnu dot org 2009-11-29 15:56 --- The ICE happens since GCC 4.2.0. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||error-recovery, monitored Summary|ICE: tree check: expected |[4.3/4.4/4.5 Regression] |class 'type', have |ICE: tree check: expected |'exceptional' (error_mark) |class 'type', have |in useless_type_conversion_p|'exceptional' (error_mark) ||in useless_type_conversion_p Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42038
[Bug c++/42219] New: [4.5 Regression] ICE with const void as parameter type
The following invalid code snippet triggers an ICE on trunk:
=
void foo(const void);
void bar()
{
void (*pf)() = foo;
}
=
bug.cc:1:16: error: 'anonymous' has incomplete type
bug.cc:1:20: error: invalid use of 'const void'
bug.cc: In function 'void bar()':
bug.cc:5:18: error: invalid conversion from 'void (*)(type error)' to 'void
(*)()'
bug.cc:5:18: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1426
Please submit a full bug report, [etc.]
--
Summary: [4.5 Regression] ICE with const void as parameter type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug c++/42219] [4.5 Regression] ICE with const void as parameter type
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug c++/42219] [4.5 Regression] ICE with const void as parameter type
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug target/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #9 from vlad at demoninsight dot com 2009-11-29 16:04 --- Well, I think my scheme worked: I have succeeded in reverse engineering the 4.4.2 fink scripts into something I could use to build 4.5 trunk against the prerequisite libs installed via fink. Indeed, 4.5 trunk does not appear to have this issue: [10:00:53] TEMPg++-4.5 -v -save-temps test.cpp -o crash Using built-in specs. COLLECT_GCC=g++-4.5 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../src/configure --prefix=/sw/lib/gcc4.5.trunk --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 Thread model: posix gcc version 4.5.0 20091128 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic' /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/cc1plus -E -quiet -v -D__DYNAMIC__ test.cpp -fPIC -mmacosx-version-min=10.6.2 -mtune=generic -fpch-preprocess -o test.ii ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../x86_64-apple-darwin10/include #include ... search starts here: #include ... search starts here: /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0/x86_64-apple-darwin10 /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../../include/c++/4.5.0/backward /sw/lib/gcc4.5.trunk/include /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/include /sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic' /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/cc1plus -fpreprocessed test.ii -fPIC -quiet -dumpbase test.cpp -mmacosx-version-min=10.6.2 -mtune=generic -auxbase test -version -o test.s GNU C++ (GCC) version 4.5.0 20091128 (experimental) (x86_64-apple-darwin10) compiled by GNU C version 4.5.0 20091128 (experimental), GMP version 4.3.1, MPFR version 2.4.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.5.0 20091128 (experimental) (x86_64-apple-darwin10) compiled by GNU C version 4.5.0 20091128 (experimental), GMP version 4.3.1, MPFR version 2.4.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f85e2aae35d4b378debe824f8e82886d COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic' as -arch x86_64 -force_cpusubtype_ALL -o test.o test.s COMPILER_PATH=/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/ LIBRARY_PATH=/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/:/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic' /sw/lib/gcc4.5.trunk/libexec/gcc/x86_64-apple-darwin10/4.5.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.2 -weak_reference_mismatches non-weak -o crash -lcrt1.10.5.o -L/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0 -L/sw/lib/gcc4.5.trunk/lib/gcc/x86_64-apple-darwin10/4.5.0/../../.. test.o -lstdc++ -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o' 'crash' '-shared-libgcc' '-mtune=generic' [10:01:04] TEMP./crash CAUGHT -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
[Bug middle-end/42220] New: [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
On at revision 154712 I see the following failures: FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test [karma] f90/bug% gfc -m64 -O3 -funroll-loops /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 [karma] f90/bug% a.out check4: z=.000 + I .83298129 zref=.38187021 + I 1.0719848 Diff: -.38187021 + I*-.23900348 eps=.23841858E-06 Abort [karma] f90/bug% gfc -m64 -O3 -funroll-all-loops /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 [karma] f90/bug% a.out check4: z=.000 + I .83298129 zref=.38187021 + I 1.0719848 Diff: -.38187021 + I*-.23900348 eps=.23841858E-06 Abort The last successful revision is 154405 (configured with my build of mpc, while the failing one use the fink package). -- Summary: [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=42220
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #33 from ghazi at gcc dot gnu dot org 2009-11-29 16:12 --- The flag -frtl-abstract-sequences was removed and the relevant testcases deleted. Should we resolve this PR as WONTFIX ? http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-11-29 16:21 --- This testcase was fixed here: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01134.html Can we close this one? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #5 from dominiq at lps dot ens dot fr 2009-11-29 16:21 --- (In reply to comment #3) So how do I switch to 64-bit mode? On x86_64-apple-darwin* it is the default, so I assume you are using i686-apple-darwin*. In this case you need a multlib build and you compile with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 16:33 --- So this is a mpc / fink bug, not a gcc one. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-29 16:34 --- Rainer, I believe this bug has been appropriatly analyzed and diagnosed. You have the affected system and can test, are you working on a fix? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-29 16:34:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-11-29 16:34 --- Wontfix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/31549] Documentation for -frtl-abstract-sequences is in the wrong place
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 16:35 --- -frtl-abstract-sequences has been removed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31549
[Bug rtl-optimization/36240] PIC and -frtl-abstract-sequences
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 16:35 --- -frtl-abstract-sequences has been removed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36240
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-11-29 16:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Known to fail|4.2.3 4.3.0 4.4.0 |4.2.3 4.3.0 Known to work|4.1.3 |4.1.3 4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug rtl-optimization/34320] -O3 -fsee -fno-regmove causes ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-29 16:51 --- -fsee has been removed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34320
[Bug rtl-optimization/27469] zero extension not eliminated
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27469
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #2 from dominiq at lps dot ens dot fr 2009-11-29 16:56 --- So this is a mpc / fink bug, not a gcc one. I have forgotten to say that the failure occurs only with -funroll*-loops, -O[1-3], and -m64 options. Without -funroll*-loops the test pass. BTW I do not see any loop in the code. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-29 17:15 --- I have forgotten to say that the failure occurs only with -funroll*-loops, -O[1-3], and -m64 options. Without -funroll*-loops the test pass. BTW I do not see any loop in the code. Very likely revision 154688: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00911.html Can you attach the files generated by -fdump-rtl-ce3 -fdump-rtl-rnreg-details? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c/42221] New: ICE from '-Os -fgraphite-identity'
gcc -v -B. -r -nostdlib -Wall -Wextra -Os -fgraphite-identity md4.i; echo EXIT: $? Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --with-mpfr=/usr/local --with-gmp=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --with-mpc=/usr/local --with-libelf=/usr/local --enable-languages=c,c++ --enable-__cxa_atexit --enable-targets=all Thread model: posix gcc version 4.5.0 20091129 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-B.' '-r' '-nostdlib' '-Wall' '-Wextra' '-Os' '-fgraphite-identity' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -fpreprocessed md4.i -quiet -dumpbase md4.i -mtune=generic -auxbase md4 -Os -Wall -Wextra -version -fgraphite-identity -o /tmp/ccR7BjWO.s GNU C (GCC) version 4.5.0 20091129 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091129 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20091129 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091129 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 89b3c82a0e7a4c9be3065ee229d764cd md4.c: In function md4step: md4.c:106:13: error: incorrect sharing of tree nodes var.35_1139 = X[D.3485_1099]; X[D.3485_1099] md4.c:106:13: error: incorrect sharing of tree nodes wp_437 = X[D.3485_1099]; X[D.3485_1099] md4.c:106:13: internal compiler error: verify_stmts failed -- Summary: ICE from '-Os -fgraphite-identity' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b3timmons at speedymail dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42221
[Bug c/42221] ICE from '-Os -fgraphite-identity'
--- Comment #1 from b3timmons at speedymail dot org 2009-11-29 17:25 --- Created an attachment (id=19177) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19177action=view) preprocessed source triggering failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42221
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #4 from dominiq at lps dot ens dot fr 2009-11-29 17:27 --- Created an attachment (id=19178) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19178action=view) ce3 file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #5 from dominiq at lps dot ens dot fr 2009-11-29 17:29 --- Created an attachment (id=19179) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19179action=view) rnreg file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42193] [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3
--- Comment #4 from irar at gcc dot gnu dot org 2009-11-29 17:30 --- Subject: Bug 42193 Author: irar Date: Sun Nov 29 17:30:20 2009 New Revision: 154738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154738 Log: PR tree-optimization/42193 * tree-vect-stmts.c (vectorizable_operation): Set vectorization factor to 1 in case of basic block SLP. (vectorizable_load): Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr42193.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42193
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #6 from dominiq at lps dot ens dot fr 2009-11-29 17:30 --- Can you attach the files generated by -fdump-rtl-ce3 -fdump-rtl-rnreg-details? I have reduced the test to module test implicit none real(4), parameter :: eps4 = epsilon(0.0_4)*2.0_4 real(8), parameter :: eps8 = epsilon(0.0_8)*2.0_8 interface check procedure check4 end interface check contains SUBROUTINE check4(z, zref) complex(4), intent(in) :: z, zref if (abs (real(z)-real(zref)) eps4 .or.abs (aimag(z)-aimag(zref)) eps4) then print '(a,/,2((2g0, + I ,g0),/))', check4:, z=,z,'zref=',zref print '(a,g0, + I*,g0, eps=,g0)', 'Diff: ', real(z)-real(zref), aimag(z)-aimag(zref), eps4 ! call abort() end if END SUBROUTINE check4 end module test PROGRAM ArcTrigHyp use test IMPLICIT NONE complex(4), volatile :: z4 ! ZERO !! ! z = 0 z4 = cmplx(0.0_4, 0.0_4, kind=4) ! Exact: 0 call check(asin(z4), cmplx(0.0_4, 0.0_4, kind=4)) ! Exact: Pi/2 = 1.5707963267948966192313216916397514 call check(acos(z4), cmplx(1.57079632679489661920_4, 0.0_4, kind=4)) ! Exact: 0 call check(atan(z4), cmplx(0.0_4, 0.0_4, kind=4)) ! Exact: 0 call check(asinh(z4), cmplx(0.0_4, 0.0_4, kind=4)) ! Exact: I*Pi/2 = I*1.5707963267948966192313216916397514 call check(acosh(z4), cmplx(0.0_4, 1.57079632679489661920_4, kind=4)) ! Exact: 0 call check(atanh(z4), cmplx(0.0_4, 0.0_4, kind=4)) ! POSITIVE NUMBERS !! ! z = tanh(1.0) z4 = cmplx(0.76159415595576488811945828260479359_4, 0.0_4, kind=4) ! Numerically: 0.70502684355523799494171984544790700*I call check(acosh(z4), cmplx(0.0_4, 0.70502684355523799494171984544790700_4, kind=4)) ! Exact: 1 call check(atanh(z4), cmplx(1.0_4, 0.0_4, kind=4)) ! z = I*tanh(1.0) z4 = cmplx(0.0_4, 0.76159415595576488811945828260479359_4, kind=4) ! Numerically: I*0.70239670712987482778422106260749699 call check(asin(z4), cmplx(0.0_4, 0.70239670712987482778422106260749699_4, kind=4)) END PROGRAM ArcTrigHyp Note that the errors fluctuate, depending on the check lines commented. I'll attach the asked files for this reduced test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug tree-optimization/42209] missed optimization leads to several times slower code
--- Comment #2 from gb-0001 at xsim dot com 2009-11-29 17:34 --- [For the call in the loop GCC assumes it is more beneficial] And in this case it is: the inner loop code is yet simpler than the prologue/eiplogue code. [If you are sure it is always beneficial...] It is not always beneficial. It is close enough to always if the op parameter is a compile-time constant, and op usually is a compile-time constant. Taking advantage of that would require annotating the call site with a conditional inlining information. Is that possible in GCC? [It is unlikely fixed in 4.4] This is not important (for me) to fix in 4.4 -- the code is not yet public and even when it is, it is not clear anybody else will use it. My principal concerns are it would be nice if my code were faster, and this may represent a class of lost optimizations for others. I filed this ticket at reduced severity to reflect that, feel free to adjust priority/severity to reflect that (or tell me what to change). [As 4.5 works...] My reading is 4.5 inlines it if told to always_inline, but inlining is a loss when op is a runtime variable -- it would inline the code up to about 20 times without being able to optimize any inlined copy. Is there a way to annotate inline if op is a compile-time constant? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
[Bug target/42213] GCC chkstk clash with Microsoft version
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29 17:36 --- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9 and discussion of http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html I think that patch should go into 4.5 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug target/42213] GCC chkstk clash with Microsoft version
--- Comment #4 from pascal dot obry at wanadoo dot fr 2009-11-29 17:43 --- Subject: Re: GCC chkstk clash with Microsoft version Le 29/11/2009 18:36, dannysmith at users dot sourceforge dot net a écrit : --- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29 17:36 --- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9 and discussion of http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html I think that patch should go into 4.5 Agreed, the proposed patch is what I had in mind. Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug tree-optimization/42216] [4.5 Regression] 464.h265ref peak regressed 20%
--- Comment #1 from rth at gcc dot gnu dot org 2009-11-29 17:58 --- The vec_interleave_*_optab should still be populated. It's just that what was once sse2_punpcklwd is now vec_interleave_lowv8hi directly. If this patch *is* attributable to a regression, then perhaps there's a typo somewhere in the substitutions... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug c++/42222] New: GCC ooms when building KDE
I'm trying to build KDE, namely kdelibs directory, which is located at: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/ When building the following file: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/khtml/svg/SVGNames.cpp, 'cc1plus' process starts eating memory. It can eat 1,5G of memory and then the system hangs and I see the login window. The file SVGNames.o is never built. My machine has got 2Gb of RAM and 2Gb of swap space.I had built this very directory and file a lot of times before and there vere no problems. The exact version string for GCC is gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7). -- Summary: GCC ooms when building KDE Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ragnarokk91 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug tree-optimization/42209] missed optimization leads to several times slower code
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-29 18:21 --- With 4.5 it works when the function is declared inline (not always_inline). It's not possible to annotate call-sites with inline information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Component|c |tree-optimization Keywords||wrong-code Priority|P3 |P2 Summary|ICE from '-Os -fgraphite- |[4.5 Regression] ICE from '- |identity' |Os -fgraphite-identity' Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42221
[Bug c++/42069] [4.5 Regression] fails on class template specialization with default parameter
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-29 18:39
---
Shorter testcase (without default parameter):
=
struct A
{
static const int N = 0;
};
templateint struct B {};
templatetypename T, int
struct C
{
typedef T U;
BU::N b;
};
templatetypename T
struct CT*, 0
{
BT::N b;
};
CA*, 0 c;
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #19 from dodji at gcc dot gnu dot org 2009-11-29 19:19 --- Subject: Bug 36408 Author: dodji Date: Sun Nov 29 19:19:06 2009 New Revision: 154742 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154742 Log: Really fix PR c++/36408 gcc/cp/ChangeLog: PR c++/36408 * semantics.c (empty_expr_stmt_p): Handle void_zero_node and fix bad indentation. * pt.c (tsubst_copy_and_build): Fix typo. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-29 19:36 --- Created an attachment (id=19180) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19180action=view) Hopefully final patch This patch moves the number of elements patch up front so that the error is given almost immediately. Previously, with one of Dominique's test cases, it would take over 15 minutes on my machine here before one find's out there is a problem. I use gfc_fatal_error because compilation at that this early stage continues on happily before quitting. Can be very annoying for programs with large array constructors. Testing continues. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Attachment #19170|0 |1 is obsolete|| Attachment #19172|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug c++/42069] [4.5 Regression] ICE on class template specialization
--- Comment #3 from dodji at gcc dot gnu dot org 2009-11-29 19:42 --- Mine. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-16 19:57:52 |2009-11-29 19:42:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
[Bug c++/36408] [4.3/4.4/4.5 regression] ICE with statement expression in template
--- Comment #20 from dodji at gcc dot gnu dot org 2009-11-29 20:43 --- OK, it should really be fixed in 4.5 now. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug preprocessor/41943] include search path composition is bogus
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-29 20:47:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug fortran/42223] New: OSX gfortran command line compile illegal instruction
This is my test program named hello.f90 ! The standard Hello World demo (f90) program hello write (*,*) Hello World! end program hello Tried to compile using the Macs terminal utility Had just installed Wiki MAC PPC Binaries from dmg-20090203 HDWR = PowerBook G4 running OSX 10.5.8 = McFurby:Source herman$ McFurby:Source herman$ gfortran -v -save-temps hello.f90 Driving: gfortran -mmacosx-version-min=10.5.8 -v -save-temps hello.f90 -lgfortranbegin -lgfortran -shared-libgcc Using built-in specs. Target: powerpc-apple-darwin9.6.0 Configured with: /var/tmp/gfortran-20090203/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,c++,fortran --with-gmp=/var/tmp/gfortran-20090203/gfortran_libs --enable-bootstrap --with-included-gettext Thread model: posix gcc version 4.4.0 20090203 (experimental) [trunk revision 143897] (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-v' '-save-temps' '-shared-libgcc' /usr/local/gfortran/libexec/gcc/powerpc-apple-darwin9.6.0/4.4.0/f951 hello.f90 -fPIC -quiet -dumpbase hello.f90 -mmacosx-version-min=10.5.8 -auxbase hello -version -fintrinsic-modules-path /usr/local/gfortran/lib/gcc/powerpc-apple-darwin9.6.0/4.4.0/finclude -o hello.s GNU Fortran (GCC) version 4.4.0 20090203 (experimental) [trunk revision 143897] (powerpc-apple-darwin9.6.0) compiled by GNU C version 4.4.0 20090203 (experimental) [trunk revision 143897], GMP version 4.2.3, MPFR version 2.4.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 built-in:0: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. McFurby:Source herman$ -- Summary: OSX gfortran command line compile illegal instruction Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hharrison at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42223
[Bug fortran/42223] OSX gfortran command line compile illegal instruction
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-29 21:30 --- We do not distribute binaries and they probably were built with a configuration incompatible to your CPU. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42223
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #21 from dominiq at lps dot ens dot fr 2009-11-29 22:10 --- With the patch in comment #20, I get several new failures: gcc/testsuite/gfortran.dg/actual_array_constructor_3.f90 pr20923 and friends pr34554 IIRC when the constructors are used as initialization or in statements, they are expanded at compile time when possible if the length is less than 2^16, otherwise they are computed at run time. I think this behavior should be kept. The only cases for which the fatal error should be triggered is for PARAMETERS as in pr19925 that must be computed at compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-29 22:23
---
Reduced testcase:
templatevoid (*)() struct A {};
templatetypename void foo();
templatetypename T AfooT bar();
void baz()
{
barint();
}
Versions before GCC 4.4.0 just crash on the code snippet.
Since GCC 4.4.0 the compiler issues a sorry:
bug.cc:5:33: sorry, unimplemented: mangling template_id_expr
Is this an ABI defect, or can we make mangling work in this case?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|WAITING |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, rejects-
||valid
Last reconfirmed|-00-00 00:00:00 |2009-11-29 22:23:42
date||
Summary|Internal compiler error |Trouble mangling
|(ICE) Segmentation fault|template_id_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug c/42224] New: 32bit pointers to 32bit pointers abort on 64bit VMS
This is a major bug on VMS, it prevents gnatlib compilation. Please fix.
Ubuntu Linux Desktop 8.04 LTS
Target: ia64-hp-openvms8_3
Configured with: ../gcc-head-src/configure --target=ia64-hp-openvms8_3
--prefix=/vmsbuild/gcc/gnatxx --with-local-prefix=/vmsbuild/gcc/gnatxx/local
--with-gnu-as --enable-threads=posix --disable-shared --disable-nls
--disable-multilib --disable-libssp --disable-libada --disable-decimal-float
--disable-fixed-point --enable-checking=release --enable-languages=c
--with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib
--with-mpfr-include=/us/local/include --with-mpfr-lib=/usr/local/lib
Thread model: posix
gcc version 4.5.0 20091129 (experimental) (GCC)
--
$ ./cc1 foo.c
to_ptr32 to_int to_ptr32_ptr32
foo.c: In function 'to_ptr32_ptr32':
foo.c:28:3: internal compiler error: in int_or_pointer_precision, at
tree.c:10583
-- Reproducer:
$ cat foo.c
typedef char* __char_ptr32 __attribute__ (( mode (SI) ));
typedef __char_ptr32 *__char_ptr_char_ptr32 __attribute__ ((mode (SI)));
void to_ptr32 (int x)
{
__char_ptr32 ptr = (__char_ptr32) x;
}
void to_int (__char_ptr32 ptr)
{
int x = (int) ptr;
}
__char_ptr_char_ptr32
to_ptr32_ptr32 (char **ptr64)
{
int argc;
__char_ptr_char_ptr32 short_argv;
for (argc=0; ptr64[argc]; argc++);
short_argv = (__char_ptr_char_ptr32) malloc32
(sizeof (__char_ptr32) * (argc + 1));
for (argc=0; ptr64[argc]; argc++)
short_argv[argc] = (__char_ptr32) strdup32 (ptr64[argc]);
short_argv[argc] = (__char_ptr32) 0;
return short_argv;
}
--
Summary: 32bit pointers to 32bit pointers abort on 64bit VMS
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rupp at gnat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: ia64-hp-openvms8_3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42224
[Bug c++/41961] Internal error with -O3 and -ftree-parallelize-loops
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-29 23:04
---
Reduced testcase:
=
struct A
{
char c[17];
void foo();
};
void A::foo()
{
for (int i = 0; i 17; ++i)
c[i] = 0;
}
=
The bug is fixed in GCC 4.4.0.
(Because -ftree-parallelize-loops was introcuded in GCC 4.3.0,
the crash in GCC 4.3.x is not a regression.)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |RESOLVED
Keywords||ice-on-valid-code
Resolution||FIXED
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41961
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-29 23:25 --- It may be related to PR 42202. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/42069] [4.5 Regression] ICE on class template specialization
--- Comment #4 from dodji at gcc dot gnu dot org 2009-11-29 23:42 --- Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01630.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42069
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-29 23:50 --- Is this related to PR38600? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-29 23:52 --- Oops, I meant PR38712 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug middle-end/41183] [4.4 Regression] ICE compiling chromium
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-30 00:37
---
Reduced testcase (crashes with -O2 on i686-pc-linux-gnu):
==
void foo(const char*);
templateint* struct A
{
templatetypename T A(const int, T);
int i;
};
templateint* X templatetypename T AX::A(const int j, T) : i(j)
{
foo(0);
foo(0);
foo(__PRETTY_FUNCTION__);
}
int N;
struct B
{
B();
AN a;
};
B::B() : a(N, 0) {}
==
The crash only happens on the 4.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Component|c++ |middle-end
Keywords||ice-on-valid-code, monitored
Known to fail||4.4.0 4.4.1 4.4.2
Known to work|4.5.0 |4.3.4 4.5.0
Summary|internal compiler error:|[4.4 Regression] ICE
|Segmentation fault compiling|compiling chromium
|chromium|
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41183
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #6 from damian at rouson dot net 2009-11-30 00:51 --- (In reply to comment #5) (In reply to comment #3) So how do I switch to 64-bit mode? On x86_64-apple-darwin* it is the default, so I assume you are using i686-apple-darwin*. In this case you need a multlib build and you compile with -m64. Switching to x86_64-apple-darwin9 worked! What does the 9 mean? Since I'm running OS X 10.5.8, I first tried 10.5.8 and 10, but neither worked. Damian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug c++/41183] [4.4 Regression] ICE compiling chromium
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-30 01:03 --- lvalue_or_else is C++ front-end function ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41183
[Bug target/42224] 32bit pointers to 32bit pointers abort on 64bit VMS
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42224
[Bug c++/41961] Internal error with -O3 and -ftree-parallelize-loops
--- Comment #4 from hjl at gcc dot gnu dot org 2009-11-30 01:12 --- Subject: Bug 41961 Author: hjl Date: Mon Nov 30 01:11:50 2009 New Revision: 154748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154748 Log: 2009-11-29 H.J. Lu hongjiu...@intel.com PR tree-optimization/41961 * g++.dg/tree-ssa/pr41961.C: New. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr41961.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41961
[Bug c++/42222] GCC ooms when building KDE
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-30 01:12 --- gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7) is not an official FSF GCC release, you should report this directly to redhat unless you can reproduce this in an official gcc release like 4.4.2. Or even try the trunk of gcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug tree-optimization/42209] missed optimization leads to several times slower code
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-30 01:15 --- I have seen this also with code like switch_case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #7 from damian at rouson dot net 2009-11-30 01:16 --- Janus, Although the new reduced case compiles fine in 64-bit mode, I run into linking problems as soon as I add program main; end program to the end of it: Undefined symbols: _vtab$bar.1550, referenced from: ___m_MOD_new_bar in ccQEi2ET.o ld: symbol(s) not found collect2: ld returned 1 exit status Looking back through my e-mails, I see that you told me on 11/21 that Paul's TBP patch had not yet been applied to the branch or the trunk. From the above results, I assume that's still the case. Damian (In reply to comment #4) (In reply to comment #2) On darwin, the errors appear only in 32 bit mode. Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the fortran testsuite for the fortran-dev branch on darwin, but saw no failures. Here is a reduced test case: module m implicit none type foo end type type ,extends(foo) :: bar end type contains function new_bar() class(foo) ,pointer :: new_bar allocate(bar :: new_bar) end function end module Important: This only happens inside a module. If I remove the module m/end module in the example, the error goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug target/3195] STL warning on Solaris with GCC 3.0
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-30 01:58 --- I believe I fixed this issue in Sept 2006 in gcc-4.0.4, see: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01032.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01163.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01194.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01225.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01317.html and finally this testcase: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01233.html and later refinements to it ensure pthread macros work everywhere. Results for solaris that don't contain pthread-init-*.c failures: solaris2.6: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00680.html solaris2.7: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00420.html solaris2.9: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01482.html solaris2.10: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01551.html solaris2.11: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01835.html I recall there was some issue with solaris8 where the macro definition could get out of sync with the structure definition based on what solaris patches where installed. The macro was defined in a different header than the structure and individual solaris patches updated the two files independently, which made it hard (impossible?) to synchronize. And indeed I see a failure in solaris2.8: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00523.html Other than that, all supported versions of solaris are okay. So I think we can close this 8-year-old PR. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Severity|enhancement |trivial Status|NEW |ASSIGNED Last reconfirmed|2005-01-13 01:04:59 |2009-11-30 01:58:10 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3195
[Bug target/3195] STL warning on Solaris with GCC 3.0
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-11-30 02:00 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3195
[Bug tree-optimization/42209] missed optimization leads to several times slower code
--- Comment #5 from gb-0001 at xsim dot com 2009-11-30 02:14 --- [It works in 4.5 with inline, always_inline not needed.] Ah, I misunderstood -- seems good to me. I'd say fixed in 4.5 unless somebody else cares. Digression: this suggests an attribute such as inline_if_reduces which inlines if the inlined (callee) code is simplified, but otherwise keeps it out of line. In other words, code growth is okay, but not when the savings is only call/return reduction. For switch_case(), inline_if_reduces_50 (inline if the inlined callee is under 50% of the out-of-line version) would be good: here, inlining reduces the dynamic code path by about 80% and the inlined code size (at each caller) is under 5% of the size before inline simplification. Except for a slight increase in code size, it is a big enough win in this case (once the compiler knows some code expansion is okay) to set a crude threshold that does not need to be precise (what's the size of an x86 instruction vs. a MIPS instruction, etc.), yet mostly avoids false positives (inlining that hurts because the simplification is at best minor). In my experience, the biggest win from inlining with code growth is cases that get a lot better -- when the difference is small, out of line is either almost as good or is better. (End of digression.) Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42209
[Bug c++/42219] [4.5 Regression] ICE with const void as parameter type
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-30 03:39 --- It is caused by revision 150519: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-30 03:39:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42219
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-11-30 03:59
---
Ok, if I back up one step and leave the error message in trans-array.c and use
gfc_fatal_error we get a usable patch. One thing this is showing is that the
expansion is being done in the parsing/matching phase of compilation and also
in the resolution phase. I do not yet understand why the ICE is triggered
after the error: (with the changes I have made elsewhere.)
if (c-iterator)
{
/* Problems occur when we get something like
integer :: a(lots) = (/(i, i=1, lots)/) */
gfc_error_now (The number of elements in the array constructor
at %L requires an increase of the allowed %d
upper limit. See -fmax-array-constructor
option, expr-where,
gfc_option.flag_max_array_constructor);
return NULL_TREE;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug c++/42225] New: GCC 4.5 ICE (segfault) on C++ templated code
Hi, I ran into a ICE (segmentation fault) with GCC 4.5 (20091126) when building some C++ templated code. The platform is GNU/Linux, x86-64. Please find attached the preprocessed source: product_small.ii.bz2 I have compressed it because it was really huge (this codes uses a C++ template library). Below is the compiler output for the g++ that generated that .ii file. Scroll to the end to see the ICE. # 22:58:34 ~/build/eigen/test$ /usr/bin/g++-4.5 -v -save-temps -DHAS_GSL -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fexceptions -fno-check-new -fno-common -fstrict-aliasing -Wextra -pedantic -g2 -g0 -O2 -fno-inline-functions -I/home/bjacob/build/eigen/test -I/home/bjacob/eigen/test -I/home/bjacob/eigen -I/home/bjacob/build/eigen -I/usr/include/QtGui -I/usr/include/QtCore-DEIGEN_TEST_FUNC=product_small -DEIGEN_TEST_PART_1=1 -o CMakeFiles/test_product_small_1.dir/product_small.cpp.o -c /home/bjacob/eigen/test/product_small.cpp Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-tune=generic --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.5.0 20091126 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAS_GSL' '-DQT_DLL' '-DQT_GUI_LIB' '-DQT_CORE_LIB' '-DQT_NO_DEBUG' '-Wnon-virtual-dtor' '-Wno-long-long' '-ansi' '-Wundef' '-Wcast-align' '-Wchar-subscripts' '-Wall' '-W' '-Wpointer-arith' '-Wwrite-strings' '-Wformat-security' '-fexceptions' '-fno-check-new' '-fno-common' '-fstrict-aliasing' '-Wextra' '-pedantic' '-g2' '-g0' '-O2' '-fno-inline-functions' '-I/home/bjacob/build/eigen/test' '-I/home/bjacob/eigen/test' '-I/home/bjacob/eigen' '-I/home/bjacob/build/eigen' '-I/usr/include/QtGui' '-I/usr/include/QtCore' '-DEIGEN_TEST_FUNC=product_small' '-DEIGEN_TEST_PART_1=1' '-o' 'CMakeFiles/test_product_small_1.dir/product_small.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus -E -quiet -v -I/home/bjacob/build/eigen/test -I/home/bjacob/eigen/test -I/home/bjacob/eigen -I/home/bjacob/build/eigen -I/usr/include/QtGui -I/usr/include/QtCore -D_GNU_SOURCE -DHAS_GSL -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -DEIGEN_TEST_FUNC=product_small -DEIGEN_TEST_PART_1=1 /home/bjacob/eigen/test/product_small.cpp -mtune=generic -ansi -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wextra -pedantic -fexceptions -fno-check-new -fno-common -fstrict-aliasing -fno-inline-functions -O2 -fpch-preprocess -o product_small.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/bjacob/build/eigen/test /home/bjacob/eigen/test /home/bjacob/eigen /home/bjacob/build/eigen /usr/include/QtGui /usr/include/QtCore /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include/c++ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include/c++/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include/c++/backward /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list.
[Bug c++/42225] GCC 4.5 ICE (segfault) on C++ templated code
--- Comment #1 from jacob dot benoit dot 1 at gmail dot com 2009-11-30 04:17 --- Created an attachment (id=19181) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19181action=view) Preprocessed C++ source triggering this ICE To uncompress do: bunzip2 product_small.ii.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42225
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- Comment #18 from hp at gcc dot gnu dot org 2009-11-30 07:13 --- Subject: Bug 40086 Author: hp Date: Mon Nov 30 07:13:21 2009 New Revision: 154751 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154751 Log: PR rtl-optimization/40086 * reorg.c (relax_delay_slots): When looking for redundant insn at the branch target, use next_real_insn, not next_active_insn. Modified: trunk/gcc/ChangeLog trunk/gcc/reorg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- Comment #19 from hp at gcc dot gnu dot org 2009-11-30 07:19 --- a comment -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug fortran/42131] Weird translation of DO loops
--- Comment #20 from tkoenig at gcc dot gnu dot org 2009-11-30 07:31 --- Created an attachment (id=19182) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182action=view) Patch that works for unrolling It also passes do_3.F90. I'll submit just in time for meeting the phase 4 deadline tonight (hopefully). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #19159|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug rtl-optimization/41812] [4.5 Regression] test 20071030-1.c fails execution on powerpc64
--- Comment #7 from bonzini at gnu dot org 2009-11-30 07:35 --- Subject: Bug 41812 Author: bonzini Date: Mon Nov 30 07:34:55 2009 New Revision: 154753 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154753 Log: 2009-11-30 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/41812 * fwprop.c (local_md, local_lr): New globals. (process_defs, process_uses): Remove local_md argument. Never consider dead pseudos to have singleton def-use chains. (single_def_use_enter_block): Perform LR simulation. (build_single_def_use_links): Remove local_md local variable. Add DF_NOTE. Allocate local_lr. (fwprop_done): Do not remove DF_CHAIN, we do not use it anymore. * df-problems.c (df_md_scratch): New. (df_md_alloc, df_md_free): Allocate/free it. (df_md_local_compute): Only include live registers in init. (df_md_transfer_function): Prune the in-set computed by the confluence function, and the gen-set too. (df_simulate_one_insn_forwards): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41812
[Bug target/42224] 32bit pointers to 32bit pointers abort on 64bit VMS
--- Comment #1 from rupp at gnat dot com 2009-11-30 07:42 --- Fails in same manner on s390x-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42224
[Bug middle-end/41183] [4.4 Regression] ICE compiling chromium
--- Comment #5 from hjl dot tools at gmail dot com 2009-11-30 07:56 --- It is caused by revision 139945: http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00103.html and fixed by revision 147852: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00829.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41183
