[Bug c/50425] precedence rule for pre/post increamet/decreament and effect of white spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50425 Ganga Jaiswal grj017 at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #2 from Ganga Jaiswal grj017 at gmail dot com 2011-09-16 06:25:27 UTC --- Thanks Andy.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #23 from Carrot carrot at google dot com 2011-09-16 06:57:15 UTC --- (In reply to comment #21) All callee saved registers should never changed after function call. Here fp has been changed is not because it is after a function call, it is because it is after the target of non local goto. I'm not familiar with the implementation of non local goto, but I guess there is some convention/protocol defines which registers may be changed after the target of a non local goto. That's not the problem. The problem is that the blockage isn't honored. It seems postreload.c should be changed to the following to avoid combining --- postreload.c(revision 178904) +++ postreload.c(working copy) @@ -1312,7 +1312,7 @@ reload_combine (void) is and then later disable any optimization that would cross it. */ if (LABEL_P (insn)) last_label_ruid = reload_combine_ruid; - else if (BARRIER_P (insn)) + else if (BARRIER_P (insn) || BLOCKAGE_P (insn)) for (r = 0; r FIRST_PSEUDO_REGISTER; r++) if (! fixed_regs[r]) reg_state[r].use_index = RELOAD_COMBINE_MAX_USES; BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any available function/macro that implement this functionality?
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com 2011-09-16 07:12:52 UTC --- You asked where do I get such an enormous amount of invalid fortran code. Probably I was too terse in my answer. I created invalid codes to check corner or extreme cases. I do believe that to prevent is better than to cure.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #11 from Vittorio Zecca zeccav at gmail dot com 2011-09-16 07:22:09 UTC --- If you add character(9) s s=2.ip.8 gfortran, and g95, compile successfully. On the contrary gfortran fails to parse write(6,fmt=2.ip.8) To me, it looks like the parser does not handle correctly the format specification as a default-char-expression defined in fortran 95 R913 By the way, the following fails as well, should I open a new bug? write(6,fmt=1_'()') Again, in my opinion, recursive I/O, allowed or not, has nothing to do with parsing format specifications.
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #7 from janus at gcc dot gnu.org 2011-09-16 07:30:25 UTC --- (In reply to comment #6) You asked where do I get such an enormous amount of invalid fortran code. Probably I was too terse in my answer. Ok, I get it. I created invalid codes to check corner or extreme cases. I do believe that to prevent is better than to cure. Agreed. Your test cases certainly help to make gfortran more bullet-proof. Thanks a lot!
[Bug libobjc/50428] New: Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 Bug #: 50428 Summary: Consider changing semantics of +initialize so that it is inherited Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: nic...@gcc.gnu.org One of the remaining differences between the GNU Objective-C runtime and the Apple one is that +initialize methods are inherited in the Apple runtime but not in the GNU one. To reduce differences, we could change the GNU runtime to inherit them too. This is a change in behaviour and should be clearly advertised in the release notes. Thanks
[Bug libobjc/50428] Consider changing semantics of +initialize so that it is inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50428 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-16 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-09-16 08:04:13 UTC --- We should also document +initialize in the GCC Manual, no matter if we keep the existing semantics or change them. Thanks
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-16 08:20:16 UTC --- Bisection points to: 39f59e656681b198dfb1947b70f5d0dc4747 is the first bad commit commit 39f59e656681b198dfb1947b70f5d0dc4747 Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Apr 12 10:44:15 2011 + 2011-04-12 Richard Guenther rguent...@suse.de PR tree-optimization/46076 * gimple.h (struct gimple_statement_call): Add fntype field. (gimple_call_fntype): Adjust. (gimple_call_set_fntype): New function. * gimple.c (gimple_build_call_1): Set the call function type. * gimplify.c (gimplify_call_expr): Preserve the function type the frontend used for the call. (gimplify_modify_expr): Likewise. * lto-streamer-in.c (input_gimple_stmt): Input the call stmts function type. * lto-streamer-out.c (output_gimple_stmt): Output the call stmts function type. * tree-ssa.c (useless_type_conversion_p): Function pointer conversions are useless. * gcc.dg/tree-ssa/pr46076.c: Un-XFAIL. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@172310 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 08:33:30 UTC --- Quickdirty workaround for this problem: Index: lto-symtab.c === --- lto-symtab.c(revision 178757) +++ lto-symtab.c(working copy) @@ -141,11 +141,14 @@ lto_symtab_register_decl (tree decl, properties inconsistent with having external linkage. If any of these asertions fail, then the object file reader has failed to detect these cases and issue appropriate error messages. */ - gcc_assert (decl + if (decl TREE_PUBLIC (decl) (TREE_CODE (decl) == VAR_DECL || TREE_CODE (decl) == FUNCTION_DECL) - DECL_ASSEMBLER_NAME_SET_P (decl)); + DECL_ASSEMBLER_NAME_SET_P (decl)) +; + else +return; if (TREE_CODE (decl) == VAR_DECL DECL_INITIAL (decl)) gcc_assert (!DECL_EXTERNAL (decl) @@ -781,6 +784,9 @@ lto_symtab_prevailing_decl (tree decl) if (TREE_CODE (decl) == FUNCTION_DECL DECL_ABSTRACT (decl)) return decl; + if (!DECL_ASSEMBLER_NAME_SET_P (decl)) +return decl; + /* Ensure DECL_ASSEMBLER_NAME will not set assembler name. */ gcc_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 08:36:23 UTC --- With workaround I attached to PR50383 I can now build libsvx (and I did not try to get further, with bit of luck it will just work ;) W/o lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so textdata bss dec hex filename 7628075 637648 10433 8276156 7e48bc ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so With lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so textdata bss dec hex filename 6145323 635836 10384 6791543 67a177 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so Not too bad.
[Bug c++/50423] error: ‘getpid’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50423 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-16 09:34:31 UTC --- As documented at http://gcc.gnu.org/gcc-4.7/changes.html Avoid polluting the global namespace by inclusion of unistd.h.
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-16 09:44:21 UTC --- your final version exits immediately using 4.6.1, but not with 4.5 although it might finish eventually I do think this can be considered a bug
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 09:48:11 UTC --- Now it dies at /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld: warning: hidden symbol 'typeinfo for SolarMutexResettableGuard' in /abuild/jh/libreoffice/core/workdir/unxlngx6.pro/CxxObject/sfx2/source/appl/app.o is referenced by DSO /abuild/jh/libreoffice/core/solver/unxlngx6.pro/lib/libvcllo.so lto1: 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. lto-wrapper: /abuild/jh/trunk-install/bin/g++ returned 1 exit status I saw previously segfault in ipa-cp, so this might be same issue. Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 09:59:47 UTC --- OK, the error is ipa-cp trying to fold ctor reference as: #1 0x005d2fee in fold_ctor_reference (type=0x753501f8, ctor=0x77ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 2880 if (useless_type_conversion_p (type, TREE_TYPE (ctor)) (gdb) p debug_tree (type) pointer_type 0x753501f8 __vtbl_ptr_type type function_type 0x753502a0 type integer_type 0x77ec95e8 int public SI size integer_cst 0x77ecc240 constant 32 unit size integer_cst 0x77ecc260 constant 4 align 32 symtab 0 alias set 5 canonical type 0x77ec95e8 precision 32 min integer_cst 0x77ecc1e0 -2147483648 max integer_cst 0x77ecc200 2147483647 pointer_to_this pointer_type 0x77ed72a0 reference_to_this reference_type 0x71c7c930 QI size integer_cst 0x77ecc080 constant 8 unit size integer_cst 0x77ecc0a0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x753502a0 pointer_to_this pointer_type 0x753501f8 __vtbl_ptr_type public unsigned DI size integer_cst 0x77eb9ec0 type integer_type 0x77ec90a8 bitsizetype constant 64 unit size integer_cst 0x77eb9ee0 type integer_type 0x77ec9000 sizetype constant 8 align 64 symtab 0 alias set -1 canonical type 0x753591f8 pointer_to_this pointer_type 0x75350150 $2 = void (gdb) p debug_tree (ctor) error_mark 0x77ec0b10 $3 = void (gdb) bt #0 useless_type_conversion_p (outer_type=0x753501f8, inner_type=0x66686e6973615f6e) at ../../gcc/tree-ssa.c:1292 #1 0x005d2fee in fold_ctor_reference (type=0x753501f8, ctor=0x77ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 #2 0x005d3a6e in gimple_get_virt_method_for_binfo (token=960, known_binfo=optimized out) at ../../gcc/gimple-fold.c:3056 #3 0x00ae4cce in devirtualization_time_bonus (node=optimized out, known_csts=0x3622de0, known_binfos=0x3622d80) at ../../gcc/ipa-cp.c:1170 #4 0x00ae8b8c in estimate_local_effects (node=optimized out) at ../../gcc/ipa-cp.c:1401 #5 propagate_constants_topo (topo=optimized out) at ../../gcc/ipa-cp.c:1548 #6 ipcp_propagate_stage (topo=optimized out) at ../../gcc/ipa-cp.c:1631 #7 ipcp_driver () at ../../gcc/ipa-cp.c:2434 #8 0x006710a7 in execute_one_pass (pass=0x10916e0) at ../../gcc/passes.c:2063 #9 0x00671876 in execute_ipa_pass_list (pass=0x10916e0) at ../../gcc/passes.c:2430 #10 0x004ab3c4 in do_whole_program_analysis () at ../../gcc/lto/lto.c:2670 #11 0x004adf6d in lto_main () at ../../gcc/lto/lto.c:2796 #12 0x00704a32 in compile_file () at ../../gcc/toplev.c:548 #13 do_compile () at ../../gcc/toplev.c:1886 #14 toplev_main (argc=171, argv=0x11fe290) at ../../gcc/toplev.c:1962 #15 0x763efbc6 in __libc_start_main () from /lib64/libc.so.6 #16 0x004909e9 in _start () at ../sysdeps/x86_64/elf/start.S:113 Martin, is this optimized out binfo? I will try to reduce this mess, but it is huge, as you could expect
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 10:10:45 UTC --- OK, I guess the problem is that we don't stream initializer of extern variables. This leads to Martin's new devirtualization code to no longer be able to get the optimization done (and same way our folder). We should check for error_mark, but also get a testcase for missed optimization and probably start walking extern initializers when partitioning.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 10:14:09 UTC --- BTW we find only 1 devirtualization case on sfx: evans:/abuild/jh/libreoffice/:[0]# grep known target ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa* ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered an indirect call to a known target (transform/47233 - makeAny/46406), for stmt with uid 0 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered a virtual call to a known target (getStandardDate/24786 - ensureLoaded/57221), for stmt with uid 2
[Bug lto/50429] New: LibGOMP built with -flto will result in crash code for OpenMP program...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50429 Bug #: 50429 Summary: LibGOMP built with -flto will result in crash code for OpenMP program... Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: xunxun1...@gmail.com Host: *-*-mingw32 Target: *-*-mingw32 Build: *-*-mingw32 Created attachment 25301 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25301 OpenMP test program If I use -flto to build libgomp, and build one OpenMP program with this lib using -flto -fuse-linker-plugin, then the program running will crash. If I use -flto to build OpenMP program, then will be no problem, so this may be libgomp's lto compile issue. The issue locate the problem of parallel.c. gdb log: GNU gdb (pcx32) 7.3.50.20110709 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from e:\t\temp\a.exe...done. (gdb) run Starting program: e:\t\temp\a.exe [New Thread 6032.0x1468] Program received signal SIGSEGV, Segmentation fault. gomp_icv (write=false) at e:\new\gcc\gcc4.6\build\libgomp\libgomp.h:380 380 struct gomp_task *task = gomp_thread ()-task; (gdb) bt #0 gomp_icv (write=false) at e:\new\gcc\gcc4.6\build\libgomp\libgomp.h:380 #1 gomp_resolve_num_threads (specified=2, count=0) at e:\new\gcc\gcc4.6\build\libgomp\parallel.c:45 #2 0x00403088 in GOMP_parallel_start (fn=0x402950 main.$loopfn.0, data=0x28fe98, num_threads=2) at e:\new\gcc\gcc4.6\build\libgomp\parallel.c:107 #3 0x0040c18c in main () at e:\t\temp\main.c:29 (gdb) step Program received signal SIGSEGV, Segmentation fault. gomp_icv (write=false) at e:\new\gcc\gcc4.6\build\libgomp\libgomp.h:380 380 struct gomp_task *task = gomp_thread ()-task; (gdb) bt #0 gomp_icv (write=false) at e:\new\gcc\gcc4.6\build\libgomp\libgomp.h:380 #1 gomp_resolve_num_threads (specified=2, count=0) at e:\new\gcc\gcc4.6\build\libgomp\parallel.c:45 #2 0x00403088 in GOMP_parallel_start (fn=0x402950 main.$loopfn.0, data=0x28fe98, num_threads=2) at e:\new\gcc\gcc4.6\build\libgomp\parallel.c:107 #3 0x0040c18c in main () at e:\t\temp\main.c:29 (gdb) step [Inferior 1 (process 6032) exited with code 0305] Any ideas? Thanks.
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2011-09-16 10:25:31 UTC --- Created attachment 25302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25302 Potential fix for problem As far as I can tell, IRA misses this because it doesn't detect that the back end has generated RTL with pre-assigned general-purpose hard registers. Whether this technique is valid or not, it is also used in the avr backend for the same purpose (preparing to call a support routine that does not follow the standard ABI), though in that case the use is deeper in a parallel insn. The attached patch appears to fix the problem in my situation. I'd appreciate any comments and suggestions if there's a better solution.
[Bug lto/50429] LibGOMP built with -flto will result in crash code for OpenMP program...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50429 --- Comment #1 from xunxun xunxun1982 at gmail dot com 2011-09-16 10:29:50 UTC --- Created attachment 25303 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25303 The
[Bug lto/50429] LibGOMP built with -flto will result in crash code for OpenMP program...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50429 --- Comment #2 from xunxun xunxun1982 at gmail dot com 2011-09-16 10:31:14 UTC --- sorry, I put a wrong test program. The newer is right.
[Bug lto/50430] New: Constructors of static external vars are throwed away leading to missed optimizations (and ipa-cp ICE).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430 Bug #: 50430 Summary: Constructors of static external vars are throwed away leading to missed optimizations (and ipa-cp ICE). Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org The LTO streaming code deals only with ctors of finalized variables, however static external vars are useful for optimization. Vtables are common cases like this. Current mainline dies building libreoffice at: (gdb) bt #0 useless_type_conversion_p (outer_type=0x753501f8, inner_type=0x66686e6973615f6e) at ../../gcc/tree-ssa.c:1292 #1 0x005d77fc in fold_ctor_reference (type=0x753501f8, ctor=0x77ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 #2 0x005d7e38 in gimple_get_virt_method_for_binfo (token=15, known_binfo=0x72d39820) at ../../gcc/gimple-fold.c:3056 #3 0x00ae6fde in devirtualization_time_bonus (node=optimized out, known_csts=0x3625de0, known_binfos=0x3625d80) at ../../gcc/ipa-cp.c:1170 #4 0x00aeae9c in estimate_local_effects (node=optimized out) at ../../gcc/ipa-cp.c:1401 #5 propagate_constants_topo (topo=optimized out) at ../../gcc/ipa-cp.c:1548 #6 ipcp_propagate_stage (topo=optimized out) at ../../gcc/ipa-cp.c:1631 #7 ipcp_driver () at ../../gcc/ipa-cp.c:2434 #8 0x006733b7 in execute_one_pass (pass=0x10946e0) at ../../gcc/passes.c:2063 #9 0x00673b86 in execute_ipa_pass_list (pass=0x10946e0) at ../../gcc/passes.c:2430 #10 0x004ab3c4 in do_whole_program_analysis () at ../../gcc/lto/lto.c:2670 #11 0x004adf6d in lto_main () at ../../gcc/lto/lto.c:2796 #12 0x00706d42 in compile_file () at ../../gcc/toplev.c:548 #13 do_compile () at ../../gcc/toplev.c:1886 #14 toplev_main (argc=171, argv=0x1201290) at ../../gcc/toplev.c:1962 #15 0x763efbc6 in __libc_start_main () from /lib64/libc.so.6 #16 0x004909e9 in _start () at ../sysdeps/x86_64/elf/start.S:113 ctor passed to ctor_reference is error_mark indicating that the value has not been streamed. (gdb) p debug_tree (v) var_decl 0x7fffe55dc140 _ZTV11SfxVoidItem type array_type 0x75367e70 type pointer_type 0x753501f8 __vtbl_ptr_type type function_type 0x753502a0 public unsigned DI size integer_cst 0x77eb9ec0 constant 64 unit size integer_cst 0x77eb9ee0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x753591f8 pointer_to_this pointer_type 0x75350150 BLK size integer_cst 0x75366000 constant 1152 unit size integer_cst 0x75366080 constant 144 align 64 symtab 0 alias set 2 canonical type 0x75367e70 domain integer_type 0x75367f18 type integer_type 0x77ec9000 sizetype DI size integer_cst 0x77eb9ec0 64 unit size integer_cst 0x77eb9ee0 8 align 64 symtab 0 alias set -1 canonical type 0x77ec9738 precision 64 min integer_cst 0x77eb9f00 0 max integer_cst 0x753660a0 17 pointer_to_this pointer_type 0x74f41738 readonly public static ignored external virtual BLK file /abuild/jh/libreoffice/core/solver/unxlngx6.pro/inc/svl/poolitem.hxx line 352 col 0 size integer_cst 0x75366000 1152 unit size integer_cst 0x75366080 144 align 64 context record_type 0x753bb2a0 SfxVoidItem initial error_mark 0x77ec0b10 $2 = void I guess the following is correct fix for the ICE (to also avoid ICEs in case of invalid programs etc.) jan@linux-7ldc:~/trunk/gcc svn diff gimple-fold.c Index: gimple-fold.c === --- gimple-fold.c (revision 178905) +++ gimple-fold.c (working copy) @@ -3048,7 +3048,8 @@ gimple_get_virt_method_for_binfo (HOST_W if (TREE_CODE (v) != VAR_DECL || !DECL_VIRTUAL_P (v) - || !DECL_INITIAL (v)) + || !DECL_INITIAL (v) + || DECL_INITIAL (v) == error_mark_node) return NULL_TREE; gcc_checking_assert (TREE_CODE (TREE_TYPE (v)) == ARRAY_TYPE); size = tree_low_cst (TYPE_SIZE (TREE_TYPE (TREE_TYPE (v))), 1); but then we are missing optimization here. I guess extern static vars should go same way as extern inlines: i.e. be finalized to cgraph and then optimized out after devirtualization. Honza
[Bug lto/50429] LibGOMP built with -flto will result in crash code for OpenMP program...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50429 --- Comment #3 from xunxun xunxun1982 at gmail dot com 2011-09-16 10:36:21 UTC --- It's my fault. I think this is not libgomp and lto issue, and that's the libpthread's problem. Close it.
[Bug lto/50429] LibGOMP built with -flto will result in crash code for OpenMP program...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50429 xunxun xunxun1982 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from xunxun xunxun1982 at gmail dot com 2011-09-16 10:37:55 UTC --- It's invalid issue.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 11:02:07 UTC --- PR50430 now tracks the svx2 issue.
[Bug c++/50431] New: lambda bug for array size def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50431
Bug #: 50431
Summary: lambda bug for array size def
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhud...@163.com
This code is OK,
OK:
constexpr auto sz = []()-long { return 100L; };
int arr1[sz()];
int arr2[[]()-long { return 100L; }()];
But these code will failed for g++ compiler 4.6.1.
BUG1:
auto sz = []()-constexpr long { return 100L; };
int arr[[]()-long { return 100L; }];
BUG2:
//feature.cpp:51:38: internal compiler error: Segmentation fault
int arr[[]()-long { return 100L; }];
[Bug c++/50431] lambda bug for array size def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50431 --- Comment #1 from zhudiqi at 163 dot com 2011-09-16 11:36:15 UTC --- Created attachment 25304 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25304 lambda for array size def
[Bug c++/50431] lambda bug for array size def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50431
--- Comment #2 from zhudiqi at 163 dot com 2011-09-16 11:40:42 UTC ---
BUG1:
auto sz = []()-constexpr long { return 100L; };
int arr[sz()];
Why constexpr for lambda won't be compiled? Can i not use auto type for a
lambda variant?
[Bug c++/50431] [C++0x] bug in def array size with a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50431
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.0
Keywords||error-recovery,
||ice-on-invalid-code
Last reconfirmed||2011-09-16
CC||jason at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|bug in def array size with |[C++0x] bug in def array
|a lambda|size with a lambda
Known to fail||4.6.1
Severity|major |normal
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-16
11:50:50 UTC ---
This is not major severity because the code is invalid, so it's just error
handling.
(In reply to comment #0)
BUG1:
auto sz = []()-constexpr long { return 100L; };
This is invalid, constexpr is not part of the return type, it's a function
specifier. G++ correctly rejects it. The bailing out is due to the next
line:
int arr[[]()-long { return 100L; }];
This is also invalid, but shouldn't cause an ICE, and 4.7 doesn't get an ICE
here:
l.cc:2:38: error: size of array 'arr' has non-integral type 'lambda()'
4.6.1 segfaults here:
Program received signal SIGSEGV, Segmentation fault.
compute_array_index_type (name=0x2ac1e738, size=0x0, complain=3)
at ../../gcc-4.6.1/gcc/cp/decl.c:7561
7561 type = TREE_TYPE (size);
(gdb) bt
#0 compute_array_index_type (name=0x2ac1e738, size=0x0, complain=3)
at ../../gcc-4.6.1/gcc/cp/decl.c:7561
#1 0x004ab611 in create_array_type_for_decl (declarator=0x1327be0,
declspecs=0x7fffe1c0, decl_context=NORMAL, initialized=0,
attrlist=0x7fffe0c8) at ../../gcc-4.6.1/gcc/cp/decl.c:7825
[Bug lto/50432] New: lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 when build Qt4.7.4 rcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50432 Bug #: 50432 Summary: lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 when build Qt4.7.4 rcc Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: xunxun1...@gmail.com Host: *-*-mingw32 Target: *-*-mingw32 Build: *-*-mingw32 If I use gcc4.6.1 to build Qt4.7.4 with -flto -fuse-linker-plugin, it will result in an internal compiler error when building rcc: g++ -Wl,-s -flto -fuse-linker-plugin -Wl,-subsystem,console -o ../../../bin/rcc.exe tmp/obj/release_shared/rcc.o tmp/obj/release_shared/main.o -L'e:/new/GUI/Qt/qt-everywhere-opensource-src-4.7.4/src/tools/bootstrap/release' -lbootstrap -luser32 lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++ returned 1 exit status e:/mypack/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/bin/ld.exe: lto-wrapper failed collect2: ld returned 1 exit status Makefile.Release:75: recipe for target `../../../bin/rcc.exe' failed mingw32-make[2]: *** [../../../bin/rcc.exe] Error 1 mingw32-make[2]: Leaving directory `E:/new/GUI/Qt/qt-everywhere-opensource-src-4.7.4/src/tools/rcc' Makefile:34: recipe for target `release' failed mingw32-make[1]: *** [release] Error 2 mingw32-make[1]: Leaving directory `E:/new/GUI/Qt/qt-everywhere-opensource-src-4.7.4/src/tools/rcc' makefile:133: recipe for target `sub-rcc-make_default-ordered' failed mingw32-make: *** [sub-rcc-make_default-ordered] Error 2
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #12 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-09-16 12:44:37 UTC --- On Fri, Sep 16, 2011 at 07:22:09AM +, zeccav at gmail dot com wrote: To me, it looks like the parser does not handle correctly the format specification as a default-char-expression defined in fortran 95 R913 I posted a patch yesterday.
[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-16 Ever Confirmed|0 |1 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org 2011-09-16 12:59:12 UTC --- The miscompiled function seems to be evaluate_stmt or possibly the functions it is inlined to because the transformation happens in early SRA. Nevertheless, when we revert to the old behavior (enum type scalar replacements) when creating a replacement for val.lattice_val in this function the bootstrap finishes.
[Bug c++/50431] [C++0x] bug in def array size with a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50431
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-16
13:47:49 UTC ---
(In reply to comment #2)
BUG1:
auto sz = []()-constexpr long { return 100L; };
int arr[sz()];
Why constexpr for lambda won't be compiled? Can i not use auto type for a
lambda variant?
The closure type's function call operator can be const but not constexpr.
You can use auto for a lambda, you just can't have a constexpr lambda.
Why do you want it to work?
What advantage is there to using a lambda instead of named function? e.g.
constexpr long sz() { return 100L; };
int arr[sz()];
[Bug ada/50433] New: [4.7 Regression] acats tests FAIL: c460010 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50433 Bug #: 50433 Summary: [4.7 Regression] acats tests FAIL: c460010 on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: char...@act-europe.fr Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 The acats test c460010 fails on x86_64-apple-darwin10 at revision 178892 (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01560.html ) while it passed at revision 178834 (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01357.html). The failure is splitting /opt/gcc/build_w/gcc/testsuite/ada/acats/tests/c4/c460010.a into: c460010_0.ads c460010_1.ads c460010_2.ads c460010_2.adb c460010.adb BUILD c460010.adb gnatmake --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ -gnatws -O2 -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support c460010.adb -largs --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/build_w/gcc/xgcc -c -B/opt/gcc/build_w/gcc/ -gnatws -O2 -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support c460010.adb raised CONSTRAINT_ERROR : erroneous memory access gnatmake: c460010.adb compilation error FAIL: c460010 The failure is still there after a clean bootstrap of revision 178905 without any patch.
[Bug other/50434] New: genmodes.c hardcodes size of CCmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50434 Bug #: 50434 Summary: genmodes.c hardcodes size of CCmode Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com The size of CCmode is harcoded in genmodes.c as 4 bytes: case MODE_CC: /* Again, nothing more need be said. For historical reasons, the size of a CC mode is four units. */ validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET); m-bytesize = 4; m-ncomponents = 1; m-component = 0; break; However, this seems to work when the size of a byte is 8 bits, however, if this changes then things start to break. I have a backend where a byte is 16 bits (size of a word and unit and also size of int) and m-bytesize = 1; is the correct value. Paul Koning suggested making it equal to word size. Thread is : http://www.mail-archive.com/gcc@gcc.gnu.org/msg59864.html
[Bug lto/50432] lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 when build Qt4.7.4 rcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50432 --- Comment #1 from xunxun xunxun1982 at gmail dot com 2011-09-16 14:08:45 UTC --- Created attachment 25305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25305 -v output log Add -v output log
[Bug testsuite/50435] New: FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 Bug #: 50435 Summary: FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: i...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 On x86_64-apple-darwin10 the test gcc.dg/vect/bb-slp-25.c fails (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01560.html ). Looking for SLP in bb-slp-25.c.115t.slp I get 189: Failed to SLP the basic block. 189: not vectorized: failed to find SLP opportunities in basic block. 18: Failed to SLP the basic block. 18: not vectorized: failed to find SLP opportunities in basic block. 41: Failed to SLP the basic block. 41: not vectorized: failed to find SLP opportunities in basic block. 48: Failed to SLP the basic block. 48: not vectorized: failed to find SLP opportunities in basic block. indeed no basic block vectorized using SLP. However compiling the test with -ftree-vectorizer-verbose=2 returns ... Vectorizing loop at /opt/gcc/work/gcc/testsuite/gcc.dg/vect/bb-slp-25.c:16 16: created 2 versioning for alias checks. 16: vectorizing stmts using SLP. 16: LOOP VECTORIZED. ... I have applied r178880 on top of r178869 on powerpc-apple-darwin9 and the tests pass while I get the above results when I run them manually.
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #8 from Igor Zamyatin izamyatin at gmail dot com 2011-09-16 14:35:34 UTC --- I was checking coalescing part in IRA but it looks like coalescing is fine. Adding Vladimir, maybe he could give some advice here
[Bug lto/50430] Constructors of static external vars are throwed away leading to missed optimizations (and ipa-cp ICE).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 14:40:14 UTC --- Author: hubicka Date: Fri Sep 16 14:40:06 2011 New Revision: 178908 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178908 Log: PR lto/50430 * gimple-fold.c (gimple_get_virt_method_for_binfo): Do not ICE on error_mark_node in the DECL_INITIAL of vtable. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-16 14:41:19 UTC --- I have done a clean bootstrap of powerpc-apple-darwin9 and x86_64-apple-darwin10 with the patch in comment #5 with all languages except go. I have posted the results of the tests at http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01559.html and http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01560.html to be compared to the results posted at http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01360.html and http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01357.html . On powerpc-apple-darwin9 all the 22_locale/* failures are fixed without regression. On x86_64-apple-darwin10 there are two unrelated regressions (pr50433 and pr50435 that are still there if the patch is reverted). To be on the safe side it would be nice to do the same tests on powerpc*-linux-* (and to answer the questions in comment #6;-). Thanks for the patch.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #13 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-09-16 14:42:31 UTC ---
On Fri, Sep 16, 2011 at 12:44:37PM +, sgk at troutmask dot
apl.washington.edu wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #12 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-09-16 12:44:37 UTC ---
On Fri, Sep 16, 2011 at 07:22:09AM +, zeccav at gmail dot com wrote:
To me, it looks like the parser does not handle correctly the format
specification as a default-char-expression defined in fortran 95 R913
I posted a patch yesterday.
Updated patch to deal with
i = 42
print 1_'(i0)', i
end
Index: io.c
===
--- io.c(revision 178782)
+++ io.c(working copy)
@@ -2548,17 +2554,31 @@ match_dt_format (gfc_dt *dt)
if ((m = gfc_match_st_label (label)) == MATCH_YES)
{
- if (dt-format_expr != NULL || dt-format_label != NULL)
+ char c;
+
+ /* Need to check if the format label is actually either an operand
+ to a user-defined operator or is a kind type parameter. That is,
+ print 2.ip.8 ! .ip. is a user-defined operator return CHARACTER.
+ print 1_'(I0)', i ! 1_'(I0)' is a default character string. */
+
+ gfc_gobble_whitespace ();
+ c = gfc_peek_ascii_char ();
+ if (c == '.' || c == '_')
+gfc_current_locus = where;
+ else
{
- gfc_free_st_label (label);
- goto conflict;
-}
+ if (dt-format_expr != NULL || dt-format_label != NULL)
+{
+ gfc_free_st_label (label);
+ goto conflict;
+}
- if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
-return MATCH_ERROR;
+ if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
+return MATCH_ERROR;
- dt-format_label = label;
- return MATCH_YES;
+ dt-format_label = label;
+ return MATCH_YES;
+}
}
else if (m == MATCH_ERROR)
/* The label was zero or too large. Emit the correct diagnosis. */
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 14:45:07 UTC --- With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed?
[Bug lto/50430] Constructors of static external vars are throwed away leading to missed optimizations (and ipa-cp ICE).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 15:02:42 UTC --- Created attachment 25306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25306 testcase One will need to revert the gimple-fold.c patch mentioned above to get an error. Otherwise it is just missed optimization. /abuild/jh/trunk-install/bin/g++ -O2 -flto -fuse-linker-plugin -Ur -nostdlib *.ii -fpermissive -std=c++0x lto1: 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. lto-wrapper: /abuild/jh/trunk-install/bin/g++ returned 1 exit status
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-09-16 15:18:11 UTC
---
(In reply to comment #0)
indeed no basic block vectorized using SLP. However compiling the test with
-ftree-vectorizer-verbose=2 returns
...
Vectorizing loop at /opt/gcc/work/gcc/testsuite/gcc.dg/vect/bb-slp-25.c:16
16: created 2 versioning for alias checks.
16: vectorizing stmts using SLP.
16: LOOP VECTORIZED.
...
I understand that the loop vectorization somehow worked, so could you please
try the following patch to avoid it:
Index: bb-slp-25.c
===
--- bb-slp-25.c (revision 178880)
+++ bb-slp-25.c (working copy)
@@ -9,7 +9,7 @@
short src[N], dst[N];
-void foo (short * __restrict dst, short * __restrict src, int h, int stride)
+void foo (short * __restrict dst, short * __restrict src, int h, int stride,
int dummy)
{
int i;
h /= 16;
@@ -25,6 +25,8 @@ void foo (short * __restrict dst, short
dst[7] += A*src[7] + src[7+stride];
dst += 8;
src += 8;
+ if (dummy == 32)
+abort ();
}
}
@@ -41,7 +43,7 @@ int main (void)
src[i] = i;
}
- foo (dst, src, N, 8);
+ foo (dst, src, N, 8, 0);
for (i = 0; i N/2; i++)
{
I have applied r178880 on top of r178869 on powerpc-apple-darwin9 and the
tests
pass while I get the above results when I run them manually.
For PowerPC vect_element_align is false, while
/* { dg-final { scan-tree-dump-times basic block vectorized using SLP 1 slp
{ target vect_element_align } } } */
so we don't expect the basic block to get vectorized.
Thanks,
Ira
[Bug tree-optimization/34265] Missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265 --- Comment #35 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-16 15:42:15 UTC --- This pr (as well as pr49006) seems to have been fixed between revisions 176696 and 177649. I am closing pr49006 as fixed and I'll use this pr to track the remaining issues.
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-16 15:42:03 UTC --- This pr (as well as pr34265) seems to have been fixed between revisions 176696 and 177649: [macbook] lin/test% /opt/gcc/gcc4.7p-176696p1/bin/gfortran -O3 -ffast-math induct_v4.f90 -ftree-vectorizer-verbose=2 ... induct_v4.f90:1728: note: not vectorized: unsupported use in stmt. induct_v4.f90:1711: note: LOOP VECTORIZED. induct_v4.f90:1633: note: LOOP VECTORIZED. induct_v4.f90:1544: note: created 2 versioning for alias checks. induct_v4.f90:1544: note: LOOP VECTORIZED. induct_v4.f90:1449: note: vectorized 3 loops in function. induct_v4.f90:2095: note: LOOP VECTORIZED. induct_v4.f90:2018: note: LOOP VECTORIZED. induct_v4.f90:1925: note: created 2 versioning for alias checks. induct_v4.f90:1925: note: LOOP VECTORIZED. induct_v4.f90:1832: note: vectorized 3 loops in function. ... [macbook] lin/test% time a.out /dev/null 22.186u 0.023s 0:22.21 99.9%0+0k 0+3io 0pf+0w [macbook] lin/test% /opt/gcc/gcc4.7p-177649p2/bin/gfortran -O3 -ffast-math induct_v4.f90 -ftree-vectorizer-verbose=2 ... induct_v4.f90:1728: note: not vectorized: unsupported data-type complex(kind=8) induct_v4.f90:1757: note: LOOP VECTORIZED. induct_v4.f90:1711: note: LOOP VECTORIZED. induct_v4.f90:1633: note: LOOP VECTORIZED. induct_v4.f90:1544: note: created 2 versioning for alias checks. induct_v4.f90:1544: note: LOOP VECTORIZED. induct_v4.f90:1449: note: vectorized 4 loops in function. induct_v4.f90:2168: note: LOOP VECTORIZED. induct_v4.f90:2095: note: LOOP VECTORIZED. induct_v4.f90:2018: note: LOOP VECTORIZED. induct_v4.f90:1925: note: created 2 versioning for alias checks. induct_v4.f90:1925: note: LOOP VECTORIZED. induct_v4.f90:1832: note: vectorized 4 loops in function. ... [macbook] lin/test% time a.out /dev/null 12.657u 0.022s 0:12.68 99.9%0+0k 0+0io 0pf+0w I am closing this pr as fixed and I'll use pr34265 to track the remaining issues.
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-16 15:53:07 UTC --- I understand that the loop vectorization somehow worked, so could you please try the following patch to avoid it: Sorry, but after the patch I still have Running /opt/gcc/work/gcc/testsuite/gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/bb-slp-25.c scan-tree-dump-times slp basic block vectorized using SLP 1 FAIL: gcc.dg/vect/bb-slp-25.c -flto scan-tree-dump-times slp basic block vectorized using SLP 1 === gcc Summary for unix/-m32 === # of expected passes4 # of unexpected failures2 Running target unix/-m64 ... Running /opt/gcc/work/gcc/testsuite/gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/bb-slp-25.c scan-tree-dump-times slp basic block vectorized using SLP 1 FAIL: gcc.dg/vect/bb-slp-25.c -flto scan-tree-dump-times slp basic block vectorized using SLP 1 === gcc Summary for unix/-m64 === # of expected passes4 # of unexpected failures2 === gcc Summary === # of expected passes8 # of unexpected failures4 /opt/gcc/build_w/gcc/xgcc version 4.7.0 20110916 (experimental) [trunk revision 178905] (GCC) The loop is not vectorized: /opt/gcc/work/gcc/testsuite/gcc.dg/vect/bb-slp-25.c:12: note: vectorized 0 loops in function. and looking for SLP yields 189: Failed to SLP the basic block. 189: not vectorized: failed to find SLP opportunities in basic block. 43: Failed to SLP the basic block. 43: not vectorized: failed to find SLP opportunities in basic block. 50: Failed to SLP the basic block. 50: not vectorized: failed to find SLP opportunities in basic block.
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 --- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-09-16 16:18:37 UTC --- Well, at least the loop is not vectorized now :). Could you please attach the slp dump (-fdump-tree-slp-details)? Thanks, Ira
[Bug ada/24167] Visibility of private component of parent in child generic, generic compiles but instantiation doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24167 --- Comment #5 from simon at pushface dot org 2011-09-16 17:27:27 UTC --- Fixed in 4.6.0. Am I allowed/able to mark this RESOLVED?
[Bug ada/24167] Visibility of private component of parent in child generic, generic compiles but instantiation doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24167 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||charlet at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #6 from Arnaud Charlet charlet at gcc dot gnu.org 2011-09-16 17:30:48 UTC --- Fixing then, thanks.
[Bug testsuite/50435] FAIL: gcc.dg/vect/bb-slp-25.c (-flto)? scan-tree-dump-times slp basic block vectorized using SLP 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50435 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-16 17:37:17 UTC --- Created attachment 25307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25307 slp dump attached
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Summary|libgomp.h:87:5: error: |[4.7 Regression] |unnamed struct/union that |libgomp.h:87:5: error: |defines no instances|unnamed struct/union that ||defines no instances --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-09-16 18:07:40 UTC --- Warning doesn't occur with gcc version 4.4.7 20110530. There is something arm specific in these warnings as they don't occur on PA.
[Bug target/50358] AVR: Implement [u]maddqihi4 [u]msubqihi4 patterns on the enhanced core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50358 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-16 18:27:16 UTC --- Author: gjl Date: Fri Sep 16 18:27:10 2011 New Revision: 178912 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178912 Log: PR target/50358 * config/avr/avr.md (*ashiftqihi2.signx.1): New insn. (*maddqi4, *maddqi4.const): New insns. (*msubqi4, *msubqi4.const): New insns. * config/avr/avr.c (avr_rtx_costs): Record costs of above in cases PLUS:QI and MINUS:QI. Increase costs of multiply-add/-sub for HImode by 1 in the case of multiplying with a CONST_INT. Record cost of *ashiftqihi2.signx.1 in case ASHIFT:QI. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug target/50358] AVR: Implement [u]maddqihi4 [u]msubqihi4 patterns on the enhanced core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50358 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-16 18:33:59 UTC --- Resolved for 4.7.0 milestone.
[Bug c++/50436] New: Crash or hang on invalid template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436
Bug #: 50436
Summary: Crash or hang on invalid template code
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: za...@panix.com
This (invalid) test case causes gcc 4.6.1 to crash (segmentation fault).
Variations cause it to go into an infinite loop instead. I tripped over the
infinite loop while delta-minimizing a much, much larger test case for an
unrelated problem.
template bool struct VI {};
template typename T
struct IP
{
static const bool r = IPT::r;
};
template typename T struct V
{
VIIPT::r vi;
};
struct X;
struct Y
{
VX v;
};
[Bug c++/50436] Crash or hang on invalid template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436
--- Comment #1 from Zack Weinberg zackw at panix dot com 2011-09-16 19:13:13
UTC ---
Here's a variant that hangs.
template bool struct VI {};
template typename T
struct IP
{
static const bool r = IPT::r;
};
template typename T
struct V
{
static const bool r = IPT::r;
VIr vi;
};
struct X;
struct Y
{
VX v;
}
[Bug c++/50437] New: [C++0x] [4.7 regression] ICE for trivial use of lambda in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50437
Bug #: 50437
Summary: [C++0x] [4.7 regression] ICE for trivial use of lambda
in template function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The following trivial use of a lambda in a template function:
template typename T
void f()
{
auto g = [](T t){ return t == 0; };
g(T());
}
int main()
{
fint();
}
Gives the following ICE with GCC 4.7.0-20110910:
test.cpp: In instantiation of 'void f() [with T = int]':
test.cpp:10:12: required from here
test.cpp:5:5: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:459
GCC 4.6.1 compiles the code successfully.
[Bug c++/50361] [C++0x] [4.7 Regression] ICE with std::initializer_list and nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50361 --- Comment #8 from Jordan DeLong delong.j at fb dot com 2011-09-16 20:12:43 UTC --- Thanks!
[Bug fortran/50438] New: proc pointer to subroutine in structure constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50438 Bug #: 50438 Summary: proc pointer to subroutine in structure constructors Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dfra...@gcc.gnu.org CC: ja...@gcc.gnu.org [http://gcc.gnu.org/ml/fortran/2011-09/msg00080.html] The example below should be valid but is currently rejected: $ cat procpointer.f90 IMPLICIT NONE TYPE :: a PROCEDURE(proc), POINTER, NOPASS :: p END TYPE ABSTRACT INTERFACE SUBROUTINE proc END SUBROUTINE END INTERFACE TYPE(a), PARAMETER :: aa = a(aproc) ! --- CONTAINS SUBROUTINE aproc END SUBROUTINE END $ gfortran-svn -Wall -W -fimplicit-none procpointer.f90 TYPE(a), PARAMETER :: aa = a(aproc) ! --- 1 Error: Symbol 'aproc' at (1) has no IMPLICIT type $ gfortran-svn -v gcc version 4.7.0 20110915 (experimental) (GCC)
[Bug tree-optimization/50439] New: gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 Bug #: 50439 Summary: gfortran infinite loop with -floop-interchange Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: pthau...@gcc.gnu.org CC: berg...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux The following testcase (reduced from cpu2000 benchmark 200.sixtrack, comnul.f) results in gfortran looping when compiled with -floop-interchange. C gfortran -c -O3 -floop-interchange C--- subroutine comnul C--- implicit real*8 (a-h,o-z) parameter(zero=0.0d0,half=0.5d0,one=1.0d0) common/secom/rtc(9,18,10,5),rts(9,18,10,5) save C--- do 110 i1=1,9 do 110 i2=1,18 do 110 i3=1,10 do 110 i4=1,5 rtc(i1,i2,i3,i4)=zero rts(i1,i2,i3,i4)=zero 110 continue return end I stopped it a few times under the debugger and following appeared to be common chain in backtrace: #6 0x10d2b694 in Parma_Polyhedra_Library::PIP_Problem::solve (this=0x11689bd0) at /home/pthaugen/src/ppl-0.11.2/src/PIP_Problem.cc:215 #7 0x10d2b984 in Parma_Polyhedra_Library::PIP_Problem::is_satisfiable ( this=optimized out) at /home/pthaugen/src/ppl-0.11.2/src/PIP_Problem.cc:649 #8 0x10c1d864 in ppl_PIP_Problem_is_satisfiable (pip=optimized out) at /home/pthaugen/src/ppl-0.11.2/interfaces/C/ppl_c_implementation_common.cc:2298 #9 0x10ae2dd4 in ppl_powerset_is_empty (ps=0x115bcb40) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-ppl.c:553 #10 0x10adb2ac in build_lexicographical_constraint (direction=optimized out, offset=optimized out, tdim=optimized out, dim=optimized out, bag=optimized out) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:396 #11 dependence_polyhedron (original_scattering_p=optimized out, direction=optimized out, pdr2=optimized out, pdr1=optimized out) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:479 #12 new_poly_ddr (pdr1=optimized out, pdr2=0x114b80c0, direction=-1, original_scattering_p=optimized out) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:534 #13 0x10adc188 in graphite_legal_transform_dr (pdr2=optimized out, pdr1=optimized out) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:631 #14 graphite_legal_transform_bb (pbb2=optimized out, pbb1=optimized out) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:710 #15 graphite_legal_transform (scop=0x114c0200) at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:729 ... GCC configure: ~/install/gcc/trunk/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/pthaugen/install/gcc/trunk/bin/gcc COLLECT_LTO_WRAPPER=/home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64-linux/4.7.0/lto-wrapper Target: powerpc64-linux Configured with: /home/pthaugen/src/gcc/trunk/gcc/configure --prefix=/home/pthaugen/install/gcc/trunk --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --enable-secureplt --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking --with-lto --with-as=/home/wschmidt/binutils/install/bin/as --with-ld=/home/wschmidt/binutils/install/bin/ld --with-gmp=/home/pthaugen/install/gcc-host-libs --with-mpfr=/home/pthaugen/install/gcc-host-libs --with-mpc=/home/pthaugen/install/gcc-host-libs --with-ppl=/home/pthaugen/install/gcc-host-libs --with-cloog=/home/pthaugen/install/gcc-host-libs --with-host-libstdcxx=-Wl,-Bstatic,-L/home/pthaugen/install/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm --enable-languages=c,fortran,c++ --disable-bootstrap Thread model: posix gcc version 4.7.0 20110913 (experimental) [trunk revision 178814] (GCC) Using the following prereq libs: cloog-ppl-0.15.10 gmp-4.3.2 mpc-0.9 mpfr-3.0.0 ppl-0.11.2 gfortran also loops with -floop-interchange when building cpu2006 benchmark 416.gamess file mpcint.fppized.f.
[Bug rtl-optimization/50440] New: 128 bit unsigned int subtraction generates too many register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50440
Bug #: 50440
Summary: 128 bit unsigned int subtraction generates too many
register moves
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schnet...@gmail.com
I want to perform 128 bit integer arithmetic, and I am declaring my type like
this:
{{{
typedef unsigned int uint128_t __attribute__((mode(TI)));
uint128_t add (uint128_t x, uint128_t y) { return x+y; }
uint128_t sub (uint128_t x, uint128_t y) { return x-y; }
}}}
This is on an Intel Xeon processor in x86_64 mode. I build with the command
gcc-4.6.1 -O3 -march=native -S sub128.c
and I find that, while the add routine looks optimal, the sub routine has
several unnecessary register moves:
{{{
add:
movq%rdx, %rax
movq%rcx, %rdx
addq%rdi, %rax
adcq%rsi, %rdx
ret
sub:
movq%rsi, %r10
movq%rdi, %rsi
subq%rdx, %rsi
movq%r10, %rdi
sbbq%rcx, %rdi
movq%rsi, %rax
movq%rdi, %rdx
ret
}}}
[Bug c++/50424] G++ doesn't notice possible throw from default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50424 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-09-16 21:13:47 UTC --- Author: jason Date: Fri Sep 16 21:13:42 2011 New Revision: 178917 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178917 Log: PR c++/50424 * tree.c (bot_manip): Set cp_function_chain-can_throw. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/eh/defarg1.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/tree.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50424] G++ doesn't notice possible throw from default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50424 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-09-16 21:16:19 UTC --- Author: jason Date: Fri Sep 16 21:16:16 2011 New Revision: 178918 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178918 Log: PR c++/50424 * call.c (set_flags_from_callee): Split out from build_call_a. * cp-tree.h: Declare it. * tree.c (bot_manip): Call it. Added: trunk/gcc/testsuite/g++.dg/eh/defarg1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug ada/50433] [4.7 Regression] ACATS c460010 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50433 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-16 CC||ebotcazou at gcc dot ||gnu.org Summary|[4.7 Regression] acats |[4.7 Regression] ACATS |tests FAIL: c460010 on |c460010 fails to compile |x86_64-apple-darwin10 | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-16 21:18:52 UTC --- The acats test c460010 fails on x86_64-apple-darwin10 at revision 178892 (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01560.html ) while it passed at revision 178834 (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01357.html). This is very likely 2011-09-15 Jan Hubicka j...@suse.cz * ipa-inline-analysis.c (add_condition): Add conditions parameter; simplify obviously true clauses. (and_predicates, or_predicates): Add conditions parameter. (inline_duplication_hoook): Update. (mark_modified): New function. (unmodified_parm): New function. (eliminated_by_inlining_prob, (set_cond_stmt_execution_predicate, set_switch_stmt_execution_predicate, will_be_nonconstant_predicate): Use unmodified_parm. (estimate_function_body_sizes): Update. (remap_predicate): Update. I've already pinged Jan about it.
[Bug c++/50424] G++ doesn't notice possible throw from default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50424 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-09-16 21:21:39 UTC --- Fixed for 4.6.2.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-16 21:24:30 UTC --- It seems postreload.c should be changed to the following to avoid combining --- postreload.c(revision 178904) +++ postreload.c(working copy) @@ -1312,7 +1312,7 @@ reload_combine (void) is and then later disable any optimization that would cross it. */ if (LABEL_P (insn)) last_label_ruid = reload_combine_ruid; - else if (BARRIER_P (insn)) + else if (BARRIER_P (insn) || BLOCKAGE_P (insn)) for (r = 0; r FIRST_PSEUDO_REGISTER; r++) if (! fixed_regs[r]) reg_state[r].use_index = RELOAD_COMBINE_MAX_USES; BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any available function/macro that implement this functionality? volatile_insn_p would seem to be appropriate.
[Bug middle-end/50397] openssl crash due to incorrect codegen when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397 --- Comment #2 from Matt Hargett matt at use dot net 2011-09-16 22:00:25 UTC --- Verified this also happens on trunk with g++ (Ubuntu/Linaro 20110914-1) 4.7.0 20110914 (experimental) [trunk revision 178863]. Tried it with and without lto-partition=none. test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift Floating point exception (core dumped)
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Elias Pipping pipping at exherbo dot org 2011-09-16 22:04:55 UTC --- If you say it's a bug, it's a bug. :)
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 --- Comment #6 from Elias Pipping pipping at exherbo dot org 2011-09-16 22:08:16 UTC --- Created attachment 25308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25308 reduction for gcc 4.6.1 I used gcc 4.5 during reduction, assuming that a reduced test case would hang for all versions since the original code did. Here's a reduced version that makes gcc 4.6 hang (but not 4.4 or 4.5).
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-16 Ever Confirmed|0 |1 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-16 22:26:08 UTC --- great, thanks for reducing them
[Bug middle-end/50335] ICE in psct_dynamic_dim, at graphite-poly.h:659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335 --- Comment #1 from Gregory Maxwell gmaxwell at gmail dot com 2011-09-17 00:31:43 UTC --- Still failing in r178925.
[Bug c++/50441] New: [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Bug #: 50441 Summary: [C++0x] type_traits is missing GNU extension types Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: classixret...@gmail.com With -std=gnu++0x enabled, std::is_integral__uint128_t::value, std::is_integral__int128_t::value, and std::is_floating_point__float128::value should all be true. Unfortunately, they aren't. This is an extremely easy simple fix, I'd assume, but it's one that's needed, I think.
[Bug c++/50442] New: Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442
Bug #: 50442
Summary: Constructing T from implicit conversion to T
ambiguous in C++0x mode, not C++98
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: za...@panix.com
This test case ...
template typename T struct MoveRef { operator T () {} };
template typename T MoveRef T Move(T) {}
struct Thing {};
Thing foo(const Thing* p) { return Thing(Move(*p)); }
... generates these diagnostics from g++ 4.6.1 in c++0x/gnu++0x mode, but not
in c++98/gnu++98 mode:
t.cc: In function ‘Thing foo(const Thing*)’:
t.cc:4:50: error: call of overloaded ‘Thing(MoveRefconst Thing)’ is ambiguous
t.cc:4:50: note: candidates are:
t.cc:3:8: note: constexpr Thing::Thing(const Thing)
t.cc:3:8: note: constexpr Thing::Thing(Thing)
This is a regression from g++ 4.5.x and earlier.
