[Bug tree-optimization/47004] missed optimization in length comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47004 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.19 08:55:31 CC||ebotcazou at gcc dot ||gnu.org Version|4.5.4 |4.6.0 Summary|missed optimization in |missed optimization in |comparison |length comparison Ever Confirmed|0 |1 Severity|minor |enhancement --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 08:55:31 UTC --- Still visible on the mainline. Maybe this could help other languages as well.
[Bug c++/47011] New: ICE when using attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011 Summary: ICE when using attribute optimize Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lcaste...@gmail.com Target: x86_64-linux-gnu When compiling the attached file with: g++ -O3 -c gcc-crash.cpp the following error is emitted: gcc-crash.cpp: In member function ‘virtual A B::m()’: gcc-crash.cpp:7: internal compiler error: in tree_nrv, at tree-nrv.c:143 This happens with gcc 4.4.5 and the current branch on SVN. It doesn't seem to happen on gcc 4.5.
[Bug c++/47011] ICE when using attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011 --- Comment #1 from Lorenzo Castelli lcastelli at gmail dot com 2010-12-19 10:18:34 UTC --- Created attachment 22819 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22819 Code to reproduce the error
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 10:53:47 UTC --- This PR seems to have been fixed at revision 168044 (likely r 168031). May be pr46974 was a duplicate of this PR. Could someone check this and close this PR if it is the case? TIA
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #12 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:14:23 UTC --- Author: davek Date: Sun Dec 19 11:14:19 2010 New Revision: 168047 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168047 Log: PR middle-end/46674 PR middle-end/46221 * varasm.c (symbol_alias_set_t): New typedef for derived pointer_set wrapper class. (symbol_alias_set_create): New wrapper function. (symbol_alias_set_destroy): Likewise. (symbol_alias_set_contains): Likewise. (symbol_alias_set_insert): Likewise. (compute_visible_aliases): Use the above and return symbol_alias_set_t, not a pointer_set. (remove_unreachable_alias_pairs): Adjust likewise to match. (finish_aliases_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 --- Comment #27 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:14:23 UTC --- Author: davek Date: Sun Dec 19 11:14:19 2010 New Revision: 168047 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168047 Log: PR middle-end/46674 PR middle-end/46221 * varasm.c (symbol_alias_set_t): New typedef for derived pointer_set wrapper class. (symbol_alias_set_create): New wrapper function. (symbol_alias_set_destroy): Likewise. (symbol_alias_set_contains): Likewise. (symbol_alias_set_insert): Likewise. (compute_visible_aliases): Use the above and return symbol_alias_set_t, not a pointer_set. (remove_unreachable_alias_pairs): Adjust likewise to match. (finish_aliases_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:17:27 UTC --- Fully fixed now, I trust.
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #28 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:18:37 UTC --- Problems (PR46674) with this fix now resolved.
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 11:24:34 UTC --- Yes, looks as duplicate of PR 46974. *** This bug has been marked as a duplicate of bug 46974 ***
[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 11:24:34 UTC --- *** Bug 34199 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/47008] [4.6 Regression] gfortran.dg/extends_{23}.f03 FAIL with -Os -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47008 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 11:34:22 UTC --- Yep, this indeed looks like aliasing bug...
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 11:35:14 UTC --- (In reply to comment #4) The standard says namelist IO will use whatever current decimal separator is. If locale sets the default to ',', then that is what should be used unless explicitly set by the user. I disagree: The standard says for the OPEN statement (9.5.6.7 DECIMAL= specifier in the OPEN statement, quote of F2008): If this specifier is omitted in an OPEN statement that initiates a connection, the default value is POINT. Thus, for unit-based I/O the answer is clear: A decimal POINT shall be used by default - independent of the LOCALE setting. For internal I/O: The initial value of a connection mode (9.5.2) is the value that would be implied by an initial OPEN statement without the corresponding keyword. -- Thus, DECIMAL=POINT is the default (which can be overridden by the DECIMAL= specifier in the data transfer statement - or [if a format specification is used] by the dp/dc edit descriptors).
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.19 11:43:48 Ever Confirmed|0 |1 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 11:43:48 UTC --- I finally got into some time to test the various solutions. easiest is probably the following: Index: predict.c === --- predict.c (revision 168047) +++ predict.c (working copy) @@ -126,7 +126,7 @@ maybe_hot_frequency_p (int freq) if (node-frequency == NODE_FREQUENCY_EXECUTED_ONCE freq = (ENTRY_BLOCK_PTR-frequency * 2 / 3)) return false; - if (freq BB_FREQ_MAX / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION)) + if (freq ENTRY_BLOCK_PTR-frequency / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION)) return false; return true; } It makes GCC to decide on cold basic blocks not based on the innermost loop nest but on the entry block frequency - so many conditoinals or EH renders BB cold but not the fact it is outside of very many BBs. Could you try if this solves the problem?
[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000 --- Comment #21 from Jan Hubicka hubicka at ucw dot cz 2010-12-19 11:49:53 UTC --- I'd like to wait for Honza's opinion before we just start trying random patches. Well, if H.J.'s proposed backport of the builtin cost sizes helps, I guess it is sane way to fix this. I will take a look why main inliner don't do the job when early inliner ignores the call. I am not sure how much of heuristics changes makes sense to backport to 4.5. Depends on importance of the regression I guess. Honza
[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000 --- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 11:53:32 UTC --- freq: 8000 size: 2 time: 2 D.13088_5480 = VIEW_CONVERT_EXPRvector int(D.8004_729); freq: 8000 size: 2 time: 2 D.13087_5481 = VIEW_CONVERT_EXPRvector int(a_5271); freq: 8000 size: 7 time: 16 D.13086_5482 = __builtin_ia32_paddd128 (D.13087_5481, D.13088_5480); obviously we also should count V_C_E as free like other conversions. Will test patch for that.
[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000 --- Comment #23 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 11:58:35 UTC --- sha256_4way.c:287:78: warning: called from here sha256_4way.c:50:23: warning: inlining failed in call to ‘ROTR’: --param inline-unit-growth limit reached so you could also workaround with --param inline-unit-growth=some sufficiently large number. Otherwise H.J.'s proposed backport seems like most sane way to solve the problem. I guess it can be backported. I am testing Index: tree-inline.c === --- tree-inline.c (revision 168047) +++ tree-inline.c (working copy) @@ -3281,6 +3281,7 @@ estimate_operator_cost (enum tree_code c CASE_CONVERT: case COMPLEX_EXPR: case PAREN_EXPR: +case VIEW_CONVERT_EXPR: return 0; /* Assign cost of 1 to usual operations. to solve the V_C_E problems.
[Bug libobjc/47012] New: nonatimic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 Summary: nonatimic Properties behave wrong Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org It seems nonatomic properties retain and autorelease the result, which is breaking existing code targeting the Apple runtime. This bug has been also in the GNUstep runtime and the Cocotron runtime, it seems this bug has been copied to the new GNU runtime now. The Apple doc says: If you specify nonatomic, then a synthesized accessor for an object property simply returns the value directly. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html I have written a property implementation which is known to be compatible to the Apple runtime which is quite short and I'd like to contribute. It is currently licensed under the QPL, but I plan to relicense it as GPL if you are interested. If you need a testcase, there is a test for properties included in ObjFW https://webkeks.org/hg/objfw, in src/PropertiesTests.m, which also fails. It works well with the Apple runtime and the included properties implementation in src/objc-properties.m - this is also the implementation I'd like to contribute. Let me know if you are interested. Direct links: Runtime I'd like to contribute: https://webkeks.org/hg/objfw/file/tip/src/objc_properties.m (Will relicense if there's interest!) Tests that fail: https://webkeks.org/hg/objfw/file/tip/tests/PropertiesTests.m
[Bug target/46729] Many 32-bit 30_threads execution tests fail on Solaris 10+/SPARC with as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 12:19:16 UTC --- Author: ebotcazou Date: Sun Dec 19 12:19:12 2010 New Revision: 168049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168049 Log: PR target/46729 * config/sparc/sparc.h (GLOBAL_OFFSET_TABLE_REGNUM): New macro. (PIC_OFFSET_TABLE_REGNUM): Rewrite in terms of above macro. * config/sparc/sparc.c (pic_helper_needed): Delete. (global_offset_table): Likewise. (pic_helper_symbol): Rename to... (got_helper_rtx): ...this. (global_offset_table_rtx): New global variable. (sparc_got_symbol): Likewise. (sparc_got): New static function. (check_pic): Use local variable and call sparc_got. (sparc_tls_symbol): Initialize to NULL_RTX. (sparc_tls_got): In non-PIC mode, reload the GOT register for Sun TLS and 32-bit ABI and copy the GOT symbol to a new register otherwise. (get_pc_thunk_name): Rename local variable. (gen_load_pcrel_sym): New wrapper around load_pcrel_sym{si,di}. (load_pic_register): Rename to... (load_got_register): ...this. Adjust and call gen_load_pcrel_sym. (sparc_expand_prologue): Do not test flag_pic. (sparc_output_mi_thunk): Use pic_offset_table_rtx directly. (sparc_file_end): Test got_helper_rtx instead of pic_helper_needed. Rename local variable and do not call get_pc_thunk_name again. * config/sparc/sparc.md (load_pcrel_sym): Add operand #3. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.h trunk/gcc/config/sparc/sparc.md
[Bug target/46729] Many 32-bit 30_threads execution tests fail on Solaris 10+/SPARC with as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 12:20:12 UTC --- Author: ebotcazou Date: Sun Dec 19 12:20:08 2010 New Revision: 168050 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168050 Log: PR target/46729 * config/sparc/sparc.h (GLOBAL_OFFSET_TABLE_REGNUM): New macro. (PIC_OFFSET_TABLE_REGNUM): Rewrite in terms of above macro. * config/sparc/sparc.c (pic_helper_needed): Delete. (global_offset_table): Likewise. (pic_helper_symbol): Rename to... (got_helper_rtx): ...this. (global_offset_table_rtx): New global variable. (sparc_got_symbol): Likewise. (sparc_got): New static function. (check_pic): Use local variable and call sparc_got. (sparc_tls_symbol): Initialize to NULL_RTX. (sparc_tls_got): In non-PIC mode, reload the GOT register for Sun TLS and 32-bit ABI and copy the GOT symbol to a new register otherwise. (get_pc_thunk_name): Rename local variable. (gen_load_pcrel_sym): New wrapper around load_pcrel_sym{si,di}. (load_pic_register): Rename to... (load_got_register): ...this. Adjust and call gen_load_pcrel_sym. (sparc_expand_prologue): Do not test flag_pic. (sparc_output_mi_thunk): Use pic_offset_table_rtx directly. (sparc_file_end): Test got_helper_rtx instead of pic_helper_needed. Rename local variable and do not call get_pc_thunk_name again. * config/sparc/sparc.md (load_pcrel_sym): Add operand #3. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/sparc/sparc.c branches/gcc-4_5-branch/gcc/config/sparc/sparc.h branches/gcc-4_5-branch/gcc/config/sparc/sparc.md
[Bug target/46729] 32-bit 30_threads execution tests fail on Solaris 10/SPARC with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 12:24:53 UTC --- They should pass now.
[Bug fortran/46797] libquadmath: make install relinks libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46797 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-19 12:27:49 UTC --- Closing as invalid. Issues resulting from the relinking behavior are tracked in PR 46607. Thanks.
[Bug target/46729] 32-bit 30_threads execution tests fail on Solaris 10/SPARC with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Version|4.6.0 |4.5.2 Target Milestone|--- |4.5.3
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 13:37:17 UTC --- Could you try if this solves the problem? The patch in comment #14 fixed the problem on x86_64-apple-darwin10 (I cannot say anything for AMD). I have run the polyhedron tests without noticing any slow down. I'll do a clean regstrap tonight. Thanks for the patch.
[Bug testsuite/29057] gcc.target/powerpc/ppc64-abi-1.c fails to compile on powerpc-apple-darwin8 at -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29057 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 13:50:41 UTC --- On powerpc-apple-darwin9 this seems to have been fixed between revisions 166105 and 166379. Could someone check on darwin8 if this PR is still there? TIA.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #6 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 13:54:58 UTC --- Created attachment 22820 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22820 Test case
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #7 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 13:58:35 UTC --- $ gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) libc6 version - 2.12.1. This is from Ubuntu 10.10 repo, it is called Embedded GNU C library there.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #8 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 14:13:24 UTC --- Created attachment 22821 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22821 Write namelist test case Here is also test case for writing namelist. It shows, that '.' is used whatever locale is selected. It is fun - i can generate namelist file on ru_RU with '.' as decimal, and then program will fail to read it on the same locale, because it expects ','. Moreover, ',' can't be used as decimal, because it is used to separate values in namelist.
[Bug testsuite/47013] New: FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013 Summary: FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded * Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: e...@il.ibm.com Target: powerpc*-*-* I believed that a PR has been opened for this failures, but I cannot find any. Since over a year (see http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02672.html to http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01632.html ) The following tests FAIL: gcc.dg/sms-2.c scan-rtl-dump-times sms SMS succeeded 1 FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms SMS succeeded 1 FAIL: gcc.dg/sms-5.c scan-rtl-dump-times sms SMS succeeded 1 FAIL: gcc.dg/sms-6.c scan-rtl-dump-times sms SMS succeeded 3 FAIL: gcc.dg/sms-7.c scan-rtl-dump-times sms SMS succeeded 3 FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 1 fail on powerpc*-*-* for both -m32 and -m64. In addition on powerpc-apple-darwin9 FAIL: gcc.dg/sms-3.c scan-rtl-dump-times sms SMS succeeded 1 also fails with -m32. The dumps for sms-2.c are [karma] f90/bug% less sms-2.c.180r.sms ;; Function fun (fun) (note 1 0 4 NOTE_INSN_DELETED) (note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 3 4 0 2 NOTE_INSN_FUNCTION_BEG) try_optimize_cfg iteration 1 ;; 1 loops found ;; ;; Loop 0 ;; header 0, latch 1 ;; depth 0, outer -1 ;; nodes: 0 1 2 ;; 2 succs { 1 } Reordered sequence: 2 compensation [1] (note 1 0 4 NOTE_INSN_DELETED) (note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 3 4 0 2 NOTE_INSN_FUNCTION_BEG) starting the processing of deferred insns ending the processing of deferred insns [karma] f90/bug% less sms-2.c.189r.sms ;; Function fun (fun) (note 1 0 4 NOTE_INSN_DELETED) (note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 3 4 0 2 NOTE_INSN_FUNCTION_BEG) try_optimize_cfg iteration 1 ;; 1 loops found ;; ;; Loop 0 ;; header 0, latch 1 ;; depth 0, outer -1 ;; nodes: 0 1 2 ;; 2 succs { 1 } Reordered sequence: 2 compensation [1] (note 1 0 4 NOTE_INSN_DELETED) (note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (note 3 4 0 2 NOTE_INSN_FUNCTION_BEG) starting the processing of deferred insns ending the processing of deferred insns
[Bug c++/47014] New: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47014 Summary: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: 1ze...@gmail.com Created attachment 22822 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22822 testcase I (unsuccessfully) tried passing a lambda as a template-parameter and resorted to reinterpret_casting it to a normal function-pointer, which caused an internal compiler error and gcc telling me to report it. $ gcc -v --save-temps -std=c++0x test.cpp Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-gold --enable-ld --with-gold --enable-lto --disable-multilib --enable-languages=c,c++,lto --enable-threads Thread model: posix gcc version 4.6.0 20101212 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -std=c++0x -fpch-preprocess -o test.ii ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++0x -version -o test.s GNU C++ (GCC) version 4.6.0 20101212 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101212 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.6.0 20101212 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0 20101212 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 1c7bc545debdfc2a0b314e4103e7e06d test.cpp:8:18: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I've attached test.cpp, which is very short and has almost the same contents as test.ii anyways.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.19 14:41:16 Ever Confirmed|0 |1 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 14:41:16 UTC --- I can reproduce this. It only occurs if one explicitly calls setlocale - as by default the locale for C programs is LC_ALL=C, which works. As the locale can be change all the time, one would need to do: char *cur_locale; cur_local = setlocale(LC_NUMERIC, NULL); setlocale(LC_NUMERIC, ); ... setlocale(LC_NUMERIC, cur_locale); around each and every READ transfer statement ...
[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2010-12-19 15:47:14 UTC --- This seems to be the problem : the front-end generates a transposed descriptor for a non-intrinsic function. If the function is an intrinsic, the descriptor is filled in the library, and it is not transposed.
[Bug testsuite/45342] FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 15:51:25 UTC --- Author: danglin Date: Sun Dec 19 15:51:22 2010 New Revision: 168060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168060 Log: PR testsuite/45342 * gcc.dg/tls/thr-cse-1.c: Fix match on hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tls/thr-cse-1.c
[Bug testsuite/45342] FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 15:56:25 UTC --- Fixed by patch.
[Bug target/46972] __thread storage class variable gets optimized out on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972 --- Comment #4 from Paulius Zaleckas paulius.zaleckas at gmail dot com 2010-12-19 16:07:15 UTC --- Created attachment 22823 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22823 diff with and without -fsection-anchors I have found out that it is -fsection-anchors optimization causing this bug. Attached -S assembler output diff with and without this option.
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 --- Comment #14 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2010-12-19 16:20:29 UTC --- Author: paolo Date: Sun Dec 19 16:20:25 2010 New Revision: 168063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168063 Log: 2010-12-19 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR libstdc++/46869 * testsuite/20_util/enable_shared_from_this/cons/constexpr.cc: Compile with -g0. * testsuite/20_util/shared_ptr/cons/constexpr.cc: Likewise. * testsuite/20_util/unique_ptr/cons/constexpr.cc: Likewise. * testsuite/20_util/weak_ptr/cons/constexpr.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/cons/constexpr.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/constexpr.cc trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/constexpr.cc trunk/libstdc++-v3/testsuite/20_util/weak_ptr/cons/constexpr.cc
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|bkoz at gcc dot gnu.org,| |paolo.carlini at oracle dot | |com | Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-19 16:22:39 UTC --- Committed.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-12-19 17:47:54 UTC --- Putting the Fortran standard aside for a moment, it seems reasonable to me that we do something about this bug, even if it is as an extension. I have assigned to myself and will give it some thought before I suggest a solution. Thanks for the report.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #11 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 18:04:04 UTC --- I was glad to help.
[Bug c++/47014] [C++0x] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47014 --- Comment #1 from 1zeeky at gmail dot com 2010-12-19 18:04:41 UTC --- The problem arises (or at least seems to) whenever you 'force' (i.e. via reinterpret_cast) a non-function as template-parameter (e.g. an int fails to compile with almost the same ICE). That would imply that a lambda is not regarded as a proper function, as the following fails as well with the same ICE as already posted: templatevoid (fn)() class LambdaFunctor { }; LambdaFunctor*[](){} functor;
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.19 18:31:43 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 18:31:43 UTC --- Hi Jonathan nice to hear from you again (we met at Fosdem a few years ago, not sure you remember me; I do remember you). ;-) You are right that the GNU runtime does [[x retain] autorelease] before returning the value for an object, nonatomic synthesized property . The reason everyone but Apple does it, I suppose, it is because everyone felt it is a bug in the Apple implementation. ;-) The additional retain/autorelease should make it safer (but slower) than the Apple implementation; I don't think it should cause it to behave differently (other than prevent the object from being released until the next autorelease pool is emptied). Do you have a testcase where an actual difference in behaviour (other than the object being safe to use for longer, and the implementation with autorelease/retain being obviously slower) can be seen ? I guess you're concerned about performance ? Do you have any evidence that Apple did that on purpose and it's not a bug ? If you have any such evidence [ie, they won't fix it at the next release and we'll suddenly be the broken ones ;-)], we should certainly change it to behave in the same way. Maybe we should change it to behave in the same way anyway ;-) Thanks PS: Your contribution to GCC's libobjc would be much appreciated. The existing implementation of properties accessors is fairly finished though -- http://gcc.gnu.org/viewcvs/trunk/libobjc/accessors.m?revision=165903view=markup It would be a one-liner to make the change if we want to.
[Bug libobjc/45953] Registering untyped selector mutates existing selector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.19 18:35:08 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 18:35:08 UTC --- Yes, it's confirmed. Thanks
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #2 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2010-12-19 18:49:39 UTC --- Hi Nicola, yes, I do remember our talk at FOSDEM and I plan to attend it next year again, since I unfortunately could not attend it this year. Well, I guess it's not really like this because everyone felt this is better, I guess it is because Cocotron was the first to implement it (IIRC), then GNUstep looked how they solved it and now GCC looked how GNUstep solved it ;). I think it's not a bug, but intended, as not only the Apple runtime handles it like that, but the doc also says it's just a return. So the documented behaviour and the real behaviour are in sync, I guess the name nonatomic was just a bad choice and the real idea was to have a way to create a lightweight accessor which is mostly used internally. There are several hints that nonatomic is thought for internal use in the formulations used by Apple. Plus, if you care that much about performance that the spinlock is too much for you, then autoreleasing would definitely also be a problem for you ;). I mostly use nonatomic in some special cases like exceptions where the object which caused the exception should not be retained and autoreleased to prevent exception-loops (for example, if autorelease caused the exception to be thrown, that'd be a problem here). In the code you linked, is that objc_mutex_t a spinlock? If not, this might be performance problem. Speaking of performance and contributing: I wrote my own runtime some time ago. The lookup is twice as fast as in libobjc in my tests (with ASM enabled even more). Maybe we could work on merging that into libobjc on next FOSDEM? I mostly wrote my runtime because there weren't any changes in the GNU runtime for a long time and I was happy to see that things finally changed with gcc 4.6 :). If you want to have a look: https://webkeks.org/hg/objfw-rt (Hint: Thread-safety is still missing, though the data structure for the lookup only needs a write-lock and no read-lock and can still be read while it is written and it's also missing exceptions (copying the exception.c from GNU libobjc works)) I think it would be great to also work with the guys from Clang. I think it would only make sense to have the same runtime on all non-Apple systems, regardless of the compiler.
[Bug c++/39511] Bad warning, with return type, switch and enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39511 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-19 18:55:30 UTC --- The URL for preprocessed source gives a 404 now. The enum has a range 0-7 and if you call parityToString(ParityType(5)) then control falls off the end of the function, so the warning is correct.
[Bug fortran/46520] [4.6 Regression] libquadmath: fails at link test on bare irons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 19:01:41 UTC --- Author: burnus Date: Sun Dec 19 19:01:38 2010 New Revision: 168069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168069 Log: 2010-12-19 Tobias Burnus bur...@net-b.de PR fortran/46520 * configure.ac: Do not call AC_CHECK_LIB for gcc_no_link. * configure: Regenerate Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/configure trunk/libquadmath/configure.ac
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:10:29 UTC --- Author: nicola Date: Sun Dec 19 19:10:26 2010 New Revision: 168070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168070 Log: In libobjc/: 2010-12-19 Nicola Pero nicola.p...@meta-innovation.com PR libobjc/47012 * accessors.m (objc_getProperty): If not atomic, do not retain/autorelease the returned value. (Problem reported by Modified: trunk/libobjc/ChangeLog trunk/libobjc/accessors.m
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:12:33 UTC --- Yes, I was actually thinking about this, and you're right - it makes sense not to use retain/autorelease! ;-) 'nonatomic' means that other threads are not involved. Which also means that the programmer calling the accessor has full control of what happens (there aren't alternative flows of execution that may jump in); he should do the retain/autorelease himself if there is a risk that something he does while using the object returned may call the accessor setter and trigger a release of the object; else, he can get away without a retain/autorelease and get a good speedup. And doing the same that Apple does is obviously helpful for portability. So I made the change in subversion. Thanks PS: GCC is currently in bug-fixing mode only for 4.6 so we can't accept non-bug-fix changes, but as soon as it reopens, you're very welcome to contribute. Faster method lookup sounds very exciting (and non-trivial).
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:14:49 UTC --- Fixed in trunk (will be GCC 4.6). Thanks
[Bug libobjc/47012] nonatomic Properties behave wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012 --- Comment #6 from js-gcc at webkeks dot org js-gcc at webkeks dot org 2010-12-19 19:19:33 UTC --- Well, I did not plan to get that included in 4.6. If you are interested in optimizing the lookup: The lookup could be greatly improved if we also change the ABI, which is currently the limitation as the current ABI does not allow for coherent inline caching etc. This needs changes in the compiler, therefore I did not do that - maintaining a runtime AND patchset for two compilers really is too much work for a single person ;). I'd love to work on that, will you visit FOSDEM next year? If so, we could meet up there and hack on that :). I'd really love to reduce the extremely huge speed difference between the GNU runtime and the Apple runtime. At the moment, dispatch is more than 5 times faster with GNU (at least that's what I measured some time ago on Leopard, I guess with Snow Leopard it might be even more).
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 --- Comment #3 from ak at gcc dot gnu.org 2010-12-19 19:36:29 UTC --- Author: ak Date: Sun Dec 19 19:36:25 2010 New Revision: 168071 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168071 Log: Fix -fno-lto (PR lto/46905) gcc/ 2010-12-19 Andi Kleena...@linux.intel.com PR lto/46905 * collect2.c (main): Handle -fno-lto. * opts.c (common_handle_option): Handle -fno-lto. Modified: trunk/gcc/ChangeLog trunk/gcc/collect2.c trunk/gcc/opts.c
[Bug target/46972] __thread storage class variable gets optimized out on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972 --- Comment #5 from Paulius Zaleckas paulius.zaleckas at gmail dot com 2010-12-19 19:39:07 UTC --- Did some testing through various GCC versions: 4.5.2 - buggy 4.4.5 - buggy 4.3.5 - OK, but does not have -fsection-anchors optimization for ARM
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #14 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 19:50:20 UTC --- Author: danglin Date: Sun Dec 19 19:50:17 2010 New Revision: 168072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168072 Log: Backport from mainline: 2010-12-18 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/46915 * config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead of next_real_insn. Search forward checking for both ASM_INPUT and ASM_OPERANDS asms until exit condition is found. (branch_needs_nop_p): Likewise. (use_skip_p): New function. (output_cbranch): Use use_skip_p. (output_bb, output_bvb): Likewise. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/pa/pa.c
[Bug ada/46950] Stage 3 ada bootstrap error on i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 20:11:52 UTC --- Introduced by following change: 2010-12-12 Jan Hubicka j...@suse.cz Rainer Orth r...@cebitec.uni-bielefeld.de * varasm.c (default_function_section): Check flag_reorder_functions and targetm.have_named_sections. * config/darwin.c (darwin_function_section): Check flag_reorder_functions.
[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 20:20:16 UTC --- The same revision caused pr46916. Could you try the patch in http://gcc.gnu.org/bugzilla/attachment.cgi?id=22787 ?
[Bug target/47015] New: gcc/gengtype.c: undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015 Summary: gcc/gengtype.c: undefined references Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: brooks.br...@gmail.com make fails, see attachment. Ubuntu 10.10 64-bit, checked out latest svn source as of Dec 19, noon.
[Bug target/47015] gcc/gengtype.c: undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015 --- Comment #1 from Brian Brooks brooks.brian at gmail dot com 2010-12-19 20:30:33 UTC --- Created attachment 22824 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22824 make log command: sudo make -j8
[Bug bootstrap/47016] New: bootstrap on darwin needs much more disk space than expected to complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016 Summary: bootstrap on darwin needs much more disk space than expected to complete Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: denis.excoff...@airbus.com Created attachment 22825 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22825 created during stage2-gcc, produces a huge temporary during compare-debug I have bootstraped GCC 4.5.2 on darwin (ppc 9.8.0) successfully, with all default options, in particular bootstrap-debug. Nevertheless i noticed that the disk space used is 2Gb more than expected. This is due to the - contrib/compare-debug script - that uses, in case of Darwin: ld -S -r -no_uuid xxx.o -o xxx.o.stripped (instead of a simple strip) - which produces: - for the host-darwin.o created during stage2 (with -gtoggle) - and also for the host-darwin.o created during stage3 (without -gtoggle) a huge host-darwin.o.stripped containing 1Gb with many many zeroes (all the other xxx.o in stage2-gcc or stage3-gcc are ok) As a coincidence, both host-darwin.o.stripped are exactly equal, therefore no failure in comparison of stage2 and stage3, and consequently no failure in bootstrap. Of course if you don't have such extra disk space, something will surely fail. I could suggest, in case this is not a local problem occurring only to my configuration, to add gcc/host-darwin.o in compare_exclusions (in the main ./configure). Attached stage2-gcc/host-darwin.o. I can also add stage2/host-darwin.o.stripped (ie `od -c`on it) if needed. I cannot say whether the host-darwin.o created for GCC 4.5.1 had the same problem. I suppose this could be also reported to Apple, but in case someone meets that very same problem, a bypass is given: increase free disk space.
[Bug c++/20478] poor parse error diagnostic with missing right paren in vecflow())))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-19 20:55:54 UTC --- 99% of the original code is irrelevant to the parse error. This seems to be a reasonable approximation of the testcase: templatetypename T struct opApi { opApi(const char*, int); }; templatetypename T struct vec { }; typedef int flow; int deDup(int); int pop(int, vecflow); int main() { opApiflow flowApis[2] = { opApiflow(, deDup( pop(0, vecflow())), opApiflow(, deDup( pop(0, vecflow( }; } then that can be further reduced to struct opApi { opApi(int); }; struct vec { }; int deDup(vec); int main() { opApi flowApis[2] = { opApi(deDup( vec()), opApi(deDup( vec())) }; } Current releases don't complain about a missing default constructor (presumably they stop after the earlier parse error).
[Bug c++/46901] Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Göran Uddeborg goeran at uddeborg dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Göran Uddeborg goeran at uddeborg dot se 2010-12-19 20:59:17 UTC --- Looks good in 4.6-b20101218.
[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677 --- Comment #15 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-12-19 21:21:30 UTC --- Author: amylaar Date: Sun Dec 19 21:21:26 2010 New Revision: 168075 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168075 Log: PR other/46677 http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02772.html gcc: * targhooks.c (pointer_size): New function. * cppbuiltin.c (define_builtin_macros_for_lp64): Use pointer_size. (define_builtin_macros_for_type_sizes): Likewise. * target.h (pointer_size): Declare. * cppbuiltin.c (define_builtin_macros_for_type_sizes): Use TYPE_PRECISION (char_type_node). gcc/c-family: c-common.c (c_common_nodes_and_builtins): Use pointer_size. gcc/java: * decl.c (java_init_decl_processing): Use pointer_size. * java-tree.h (JAVA_POINTER_SIZE): Define. * class.c (make_class_data): Use JAVA_POINTER_SIZE. (emit_register_classes): Likewise. * jcf-parse.c (handle_long_constant): Likewise. * constants.c (build_constants_constructor): Likewise. * builtins.c (UNMARSHAL3, UNMARSHAL4, UNMARSHAL5): Likewise. (compareAndSwapObject_builtin): Likewise. * boehm.c (get_boehm_type_descriptor): Likewise. (mark_reference_fields): Add log2_size parameter. Changed all callers. gcc/cp: * cvt.c (cp_convert_to_pointer): Use TYPE_PRECISION (ptr_type_node). gcc/fortran: * trans-types.c (gfc_init_kinds): Use pointer_size. gcc/lto: * lto-object.c (lto_obj_begin_section): Use pointer_size. ada: * gcc-interface/decl.c (gnat_to_gnu_entity): Replace pointer_size with pointer_size_t. Replace POINTER_SIZE with pointer_size (). (rest_of_type_decl_compilation_no_defer): Use pointer_size. (gnat_to_gnu_param, annotate_rep, make_type_from_size): Likewise. * gcc-interface/utils2.c: Include target.h . (maybe_wrap_malloc, maybe_wrap_free): Use pointer_size. * gcc-interface/targtyps.c: Include target.h . (get_target_pointer_size): Use pointer_size. Modified: branches/pr46489-20101217-branch/gcc/ChangeLog.46489 branches/pr46489-20101217-branch/gcc/ada/gcc-interface/decl.c branches/pr46489-20101217-branch/gcc/ada/gcc-interface/targtyps.c branches/pr46489-20101217-branch/gcc/ada/gcc-interface/utils2.c branches/pr46489-20101217-branch/gcc/c-family/c-common.c branches/pr46489-20101217-branch/gcc/cp/cvt.c branches/pr46489-20101217-branch/gcc/cppbuiltin.c branches/pr46489-20101217-branch/gcc/fortran/f95-lang.c branches/pr46489-20101217-branch/gcc/fortran/trans-types.c branches/pr46489-20101217-branch/gcc/java/boehm.c branches/pr46489-20101217-branch/gcc/java/builtins.c branches/pr46489-20101217-branch/gcc/java/class.c branches/pr46489-20101217-branch/gcc/java/constants.c branches/pr46489-20101217-branch/gcc/java/decl.c branches/pr46489-20101217-branch/gcc/java/java-tree.h branches/pr46489-20101217-branch/gcc/java/jcf-parse.c branches/pr46489-20101217-branch/gcc/lto/lto-object.c branches/pr46489-20101217-branch/gcc/target.h branches/pr46489-20101217-branch/gcc/targhooks.c
[Bug ada/47017] New: [4.6 Regression] gnatlib ICE on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017 Summary: [4.6 Regression] gnatlib ICE on sparc64-linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: laur...@guerby.net CC: ebotca...@gcc.gnu.org Host: sparc64-linux Target: sparc64-linux Build: sparc64-linux /home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/ -B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/ -B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/lib/ -isystem /n/62/guerby/\ install-trunk-64/sparc64-unknown-linux-gnu/include -isystem /n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg a-cdlili.adb -o a-cdlili.o +===GNAT BUG DETECTED==+ | 4.6.0 20101218 (experimental) [trunk revision 168022] (sparc64-unknown-linux-gnu) | | Storage_Error stack overflow (or erroneous memory access)| | Error detected at s-finroo.ads:53:4 | compilation abandoned make[7]: *** [a-cdlili.o] Error 1 make[7]: Leaving directory `/home/guerby/build/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/home/guerby/build/gcc/ada' make[5]: *** [gnatlib-shared-default] Error 2 make[5]: Leaving directory `/home/guerby/build/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/home/guerby/build/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/home/guerby/build/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/home/guerby/build/sparc64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 ../trunk/configure --prefix=/n/62/guerby/install-trunk-64 --disable-werror --enable-languages=c,fortran,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1-64 --\ with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64 export CC=gcc -m64
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 21:32:49 UTC --- Vaguely related: PR 35862 (rounding on input). Both PR 35862 and this PR seem to require writing a libgfortran-specific version of strtof/strtod/strtold/quadmath_strtopQ - currently, the system's version is called in convert_real. The only alternatives I see are: a) To reset the locale for every READ statement ('setlocale(LC_NUMERIC, C)') - and restore it afterwards. b) To use localeconv and convert the decimal sign appropriately in the string (as currently done for DECIMAL=comma) - again, this needs to happen for every READ statement c) Simply document (gfortran.texi) that messing around with setlocale might produce surprising results. [LC_ALL/LANG environment variables do not have any effect unless setlocale is explicitly called. Cf. http://www.opengroup.org/onlinepubs/007904875/functions/setlocale.html] I think (a) and (b) are (too) slow and cumbersome and regarding (c): No one reads the documentation.
[Bug target/46972] __thread storage class variable gets optimized out on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-19 21:53:14 UTC --- I think enumtls has been fixed on the trunk with respect of fsection-anchors. Can you try the trunk?
[Bug target/47015] gcc/gengtype.c: undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.19 21:56:59 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-19 21:56:59 UTC --- gengtype-lex.c:1: warning: ISO C forbids an empty translation unit Do you have GNU flex installed?
[Bug target/47015] gcc/gengtype.c: undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015 --- Comment #3 from Brian Brooks brooks.brian at gmail dot com 2010-12-19 22:05:42 UTC --- (In reply to comment #2) gengtype-lex.c:1: warning: ISO C forbids an empty translation unit Do you have GNU flex installed? Yes, under /usr/bin/flex
[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950 --- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-12-20 00:36:28 UTC --- On Sun, 19 Dec 2010, dominiq at lps dot ens.fr wrote: The same revision caused pr46916. Could you try the patch in http://gcc.gnu.org/bugzilla/attachment.cgi?id=22787 ? It resolves the ada build error. Dave
[Bug debug/47018] New: ICE: in pre_and_rev_post_order_compute, at cfganal.c:1047 with -fnon-call-exceptions -fvar-tracking -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47018 Summary: ICE: in pre_and_rev_post_order_compute, at cfganal.c:1047 with -fnon-call-exceptions -fvar-tracking -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22826 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22826 reduced testcase Compiler output: $ gcc -fnon-call-exceptions -fvar-tracking -g pr47018.C pr47018.C: In function 'void foo(float)': pr47018.C:12:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:1047 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x125c3a8 /mnt/svn/gcc-trunk/gcc/cfganal.c, line=1047, function=0x125c5c0 pre_and_rev_post_order_compute) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00724d27 in pre_and_rev_post_order_compute (pre_order=0x0, rev_post_order=0x19495c0, include_entry_exit=0 '\000') at /mnt/svn/gcc-trunk/gcc/cfganal.c:1047 #2 0x00bc7b41 in vt_find_locations () at /mnt/svn/gcc-trunk/gcc/var-tracking.c:6025 #3 0x00bc9475 in variable_tracking_main_1 () at /mnt/svn/gcc-trunk/gcc/var-tracking.c:8522 #4 variable_tracking_main () at /mnt/svn/gcc-trunk/gcc/var-tracking.c:8567 #5 0x00939d96 in execute_one_pass (pass=0x17bb680) at /mnt/svn/gcc-trunk/gcc/passes.c:1553 #6 0x0093a085 in execute_pass_list (pass=0x17bb680) at /mnt/svn/gcc-trunk/gcc/passes.c:1608 #7 0x0093a097 in execute_pass_list (pass=0x17b8180) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #8 0x0093a097 in execute_pass_list (pass=0x17b81e0) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #9 0x00a7a2a6 in tree_rest_of_compilation (fndecl=0x75d1c600) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #10 0x00c3f552 in cgraph_expand_function (node=0x75d1f2c0) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508 #11 0x00c41f1d in cgraph_output_in_order () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1661 #12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1822 #13 0x00c421aa in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031 #14 0x005b75bd in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:3974 #15 0x00a23b76 in compile_file (argc=16, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #16 do_compile (argc=16, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1874 #17 toplev_main (argc=16, argv=0x7fffdad8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1937 #18 0x76586bbd in __libc_start_main () from /lib/libc.so.6 #19 0x004fe711 in _start () Tested revisions: r168061 - crash 4.5 r168062 - crash 4.4 r168062 - crash
[Bug middle-end/47019] New: [4.6 Regression] ICE: in rename_uses, at sese.c:535 with -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47019 Summary: [4.6 Regression] ICE: in rename_uses, at sese.c:535 with -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22827 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22827 reduced testcase (from pr43097.f) Compiler output: $ gcc -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop pr47019.f pr47019.f: In function 'foo': pr47019.f:1:0: internal compiler error: in rename_uses, at sese.c:535 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x13aabe2 /mnt/svn/gcc-trunk/gcc/sese.c, line=535, function=0x13aae34 rename_uses) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x010aa42a in rename_uses (bb=value optimized out, region=0x1842bf0, next_e=value optimized out, iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:535 #2 graphite_copy_stmts_from_block (bb=value optimized out, region=0x1842bf0, next_e=value optimized out, iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:618 #3 copy_bb_and_scalar_dependences (bb=value optimized out, region=0x1842bf0, next_e=value optimized out, iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:638 #4 0x0102b4ba in translate_clast_user (region=value optimized out, context_loop=0x77ecfaa0, stmt=value optimized out, next_e=0x75ccea80, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=3, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:947 #5 translate_clast (region=value optimized out, context_loop=0x77ecfaa0, stmt=value optimized out, next_e=0x75ccea80, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=3, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1115 #6 0x0102b145 in translate_clast_for_loop (region=value optimized out, context_loop=0x77ecfa18, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=2, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1032 #7 translate_clast_for (region=value optimized out, context_loop=0x77ecfa18, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=2, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1065 #8 translate_clast (region=value optimized out, context_loop=0x77ecfa18, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=2, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1120 #9 0x0102b145 in translate_clast_for_loop (region=value optimized out, context_loop=0x77ecfe58, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=1, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1032 #10 translate_clast_for (region=value optimized out, context_loop=0x77ecfe58, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=1, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1065 #11 translate_clast (region=value optimized out, context_loop=0x77ecfe58, stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570, bb_pbb_mapping=0x1855710, level=1, params_index=0x1882c60) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1120 #12 0x0102c3d5 in gloog (scop=value optimized out, bb_pbb_mapping=0x1855710) at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1557 #13 0x010294d2 in graphite_transform_loops () at /mnt/svn/gcc-trunk/gcc/graphite.c:286 #14 0x00a15327 in graphite_transforms () at /mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:296 #15 0x0084f736 in execute_one_pass (pass=0x16b2a60) at /mnt/svn/gcc-trunk/gcc/passes.c:1553 #16 0x0084fa25 in execute_pass_list (pass=0x16b2a60) at /mnt/svn/gcc-trunk/gcc/passes.c:1608 #17 0x0084fa37 in execute_pass_list (pass=0x16b2ac0) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #18 0x0084fa37 in execute_pass_list (pass=0x16b2d60) at /mnt/svn/gcc-trunk/gcc/passes.c:1609 #19 0x0084fa37 in execute_pass_list (pass=0x16b1f20) at
[Bug c++/47020] New: [4.6 Regression] [C++0x] ICE: unexpected expression 'foo' of kind overload when storing address of overloaded function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47020 Summary: [4.6 Regression] [C++0x] ICE: unexpected expression 'foo' of kind overload when storing address of overloaded function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: ja...@gcc.gnu.org -- testcase.C -- bool foo (); bool foo (int); struct S { bool (*foo) (int); } s = { foo }; --- Compiler output: $ gcc -std=c++0x testcase.C testcase.C:8:1: internal compiler error: unexpected expression 'foo' of kind overload Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r168061 - crash 4.5 r168062 - OK
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 --- Comment #2 from Sebastian Pop spop at gcc dot gnu.org 2010-12-20 05:23:29 UTC --- I cannot reproduce the error on amd64-linux with ./cc1 -O3 bug.i Please report the exact flags and the architecture. However I can see several unrelated memory leaks (i.e., not the one reported) with valgrind --leak-check=full ./cc1 -O3 bug.i
[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002 --- Comment #3 from Sebastian Pop spop at gcc dot gnu.org 2010-12-20 05:25:00 UTC --- I tested tr...@168000.
[Bug tree-optimization/47021] New: graphite branch fails to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47021 Summary: graphite branch fails to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@gcc.gnu.org Last message error on the auto-tester is while building the libstdc++: libtool: compile: /n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/./gcc/xgcc -shared-libgcc -B/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/./gcc -nostdinc++ -L/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/bin/ -B/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/lib/ -isystem /n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/include -isystem /n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/sys-include -m32 -I/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -m32 -std=gnu++0x -c /n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc -fPIC -DPIC -o .libs/debug.o /n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc: In function ‘__gnu_cxx::__mutex {anonymous}::get_safe_base_mutex(void*)’: /n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc:45:3: internal compiler error: in scan_tree_for_params, at graphite-sese-to-poly.c:851 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/47022] New: ICE: in tsubst_copy, at cp/pt.c:11682
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47022 Summary: ICE: in tsubst_copy, at cp/pt.c:11682 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: silver...@gmail.com Created attachment 22828 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22828 reduced code from wxWidget trunk the trunk version of gcc ICEs when I try to build wxWidgets trunk $ mingw32-gcc -v -c ice.cpp Using built-in specs. COLLECT_GCC=mingw32-gcc COLLECT_LTO_WRAPPER=/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/mingw32/4.6.0/lto-wrapper Target: mingw32 Configured with: ../../../gcc_trunk/configure --target=mingw32 --prefix=/platform/cross-on-linux/mingw --with-build-time-tools=/platform/cross-on-linux/mingw --with-pkgversion='Cross MingW32 GCC 4.6' --enable-shared --enable-static --enable-threads=win32 --enable-version-specific-runtime-libs --disable-win32-registry --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --enable-languages=c,c++ --disable-nls --disable-libgcj --enable-lto --disable-lto-plugin --enable-sjlj-exceptions Thread model: win32 gcc version 4.6.0 20101219 (experimental) mingw-20090616 (Cross MingW32 GCC 4.6) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro' /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/mingw32/4.6.0/cc1plus -quiet -v -iprefix /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/ -D__MSVCRT_DLL__ ice.cpp -quiet -dumpbase ice.cpp -mtune=generic -march=pentiumpro -auxbase ice -version -o /tmp/ccVwSqFd.s GNU C++ (Cross MingW32 GCC 4.6) version 4.6.0 20101219 (experimental) mingw-20090616 (mingw32) compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/sys-include ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++ ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/mingw32 ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/backward ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include-fixed ignoring nonexistent directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/sys-include ignoring duplicate directory /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/include #include ... search starts here: #include ... search starts here: /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++ /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++/mingw32 /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++/backward /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include-fixed /home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/include End of search list. GNU C++ (Cross MingW32 GCC 4.6) version 4.6.0 20101219 (experimental) compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 77abd6679d94bf4b2788fa18297de959 ice.cpp: In function 'void foo(long double*, char*) [with _T = char, va_list = char*]': ice.cpp:12:25: instantiated from here ice.cpp:6:3: internal compiler error: in tsubst_copy, at cp/pt.c:11682 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. while gcc 4.4.3 (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)) gives: ice.cpp: In function ‘void bar(__va_list_tag*)’: ice.cpp:12: error: no matching function for call to ‘foo(long double*, __va_list_tag*)’