[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jb at gcc dot gnu.org Resolution||WONTFIX --- Comment #5 from Janne Blomqvist 2012-06-06 07:48:30 UTC --- Based on the discussion here, 4.7+ already does what the reporter wants. For 4.6 and older releases, as it isn't a regression we shouldn't change the behavior. Hence, closing as wontfix.
[Bug c++/53585] template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-06-06 07:48:59 UTC --- This looks like a clang extension to me, even though I must say that the standard is currently not as clear as it could be (Keeping in mind that the core language is currently considering to extend the valid forms of non-type template parameters). The relevant wording from 14.3.2 p1 here is: "A template-argument for a non-type, non-template template-parameter shall be one of: [..] — a pointer to member expressed as described in 5.3.1." I interpret this conservatively such that only an unary expression of the form &qualified-id is valid here as described in p3+4 of 5.3.1.
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 --- Comment #4 from Jonathan Wakely 2012-06-06 08:03:28 UTC --- Did you try the instructions at http://gcc.gnu.org/wiki/InstallingGCC ?
[Bug c/53467] xgcc:Internal error: Bus error (program cc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467 martin changed: What|Removed |Added Status|WAITING |RESOLVED Version|4.7.0 |4.3.0 Resolution||WORKSFORME --- Comment #7 from martin 2012-06-06 08:24:52 UTC --- After experimenting with diffrent configure parameters I successfully build gcc 4.3.0 on my Netgear Readynas Duo sparc with ../gcc-4.3.0/configure --build='sparc-linux' --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --enable-shared --with-system-zlib --enable-nls --enable-clocale=gnu --enable-debug --with-cpu=v7 --enable-objc-gc Building gcc 4.7.0 with the same configure parameter crashes with an other error. I have to look at this more closely.
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 --- Comment #5 from ravish 2012-06-06 08:36:13 UTC --- (In reply to comment #4) > Did you try the instructions at http://gcc.gnu.org/wiki/InstallingGCC ? Yes, Jonathan.. I am suspecting on gmp compilation because if I configure gmp with ABI=32 got same error and for even ABI=64. Where as If I --disable-libjava or disable-multilib option for gcc(configure), building will go smoothly without any issue.. I am struggling with "mypath/gmp/lib/libgmp.so: could not read symbols: File in wrong format" error.. Please provide us a solution to move further? Regards, Ravish
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 --- Comment #6 from Jonathan Wakely 2012-06-06 08:51:08 UTC --- The linked PRs say you need both 32-bit and 64-bit gmp, not only one or the other.
[Bug c++/53582] [4.6 regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53582 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.4 Resolution||FIXED Target Milestone|--- |4.6.4 Summary|[4.6 regression, fixed in |[4.6 regression] ICE on |4.7, I think] ICE on valid |valid code |code| Known to fail||4.6.3 --- Comment #1 from Richard Guenther 2012-06-06 09:19:13 UTC --- Confirmed for 4.6.3, works on the 4.6 branch head. Probably a dup.
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #10 from Richard Guenther 2012-06-06 09:45:33 UTC --- Author: rguenth Date: Wed Jun 6 09:45:27 2012 New Revision: 188261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188261 Log: 2012-06-06 Richard Guenther PR tree-optimization/53081 * tree-data-ref.h (adjacent_store_dr_p): Rename to ... (adjacent_dr_p): ... this and make it work for reads, too. * tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMCPY. (struct partition_s): Change main_stmt to main_dr, add secondary_dr member. (build_size_arg_loc): Change to date data-reference and not gimplify here. (build_addr_arg_loc): New function split out from ... (generate_memset_builtin): ... here. Use it and simplify. (generate_memcpy_builtin): New function. (generate_code_for_partition): Adjust. (classify_partition): Streamline pattern detection. Detect memcpy. (ldist_gen): Adjust. (tree_loop_distribution): Adjust seed statements for memcpy recognition. * gcc.dg/tree-ssa/ldist-20.c: New testcase. * gcc.dg/tree-ssa/loop-19.c: Add -fno-tree-loop-distribute-patterns. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-20.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-19.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Richard Guenther 2012-06-06 09:45:33 UTC --- Author: rguenth Date: Wed Jun 6 09:45:27 2012 New Revision: 188261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188261 Log: 2012-06-06 Richard Guenther PR tree-optimization/53081 * tree-data-ref.h (adjacent_store_dr_p): Rename to ... (adjacent_dr_p): ... this and make it work for reads, too. * tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMCPY. (struct partition_s): Change main_stmt to main_dr, add secondary_dr member. (build_size_arg_loc): Change to date data-reference and not gimplify here. (build_addr_arg_loc): New function split out from ... (generate_memset_builtin): ... here. Use it and simplify. (generate_memcpy_builtin): New function. (generate_code_for_partition): Adjust. (classify_partition): Streamline pattern detection. Detect memcpy. (ldist_gen): Adjust. (tree_loop_distribution): Adjust seed statements for memcpy recognition. * gcc.dg/tree-ssa/ldist-20.c: New testcase. * gcc.dg/tree-ssa/loop-19.c: Add -fno-tree-loop-distribute-patterns. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-20.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-19.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-loop-distribution.c --- Comment #11 from Richard Guenther 2012-06-06 09:46:24 UTC --- Fixed.
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #11 from Richard Guenther 2012-06-06 09:46:24 UTC --- Fixed.
[Bug middle-end/29174] does not recognize memcpy and optimize it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29174 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Richard Guenther 2012-06-06 09:53:51 UTC --- Fixed for GCC 4.8 with -O3 or -ftree-loop-distribute-patterns. See also PR53081.
[Bug tree-optimization/31677] gcc.dg/memcpy-1.c tree dump scan fails on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31677 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther 2012-06-06 09:58:42 UTC --- Fixed I suppose (looking at gcc-testresults).
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-06 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-06-06 10:05:57 UTC --- Confirmed with -Os on trunk (4.8). With -O2 we unroll completely to f: .LFB0: .cfi_startproc movq$0, (%rdi) movq$0, 8(%rdi) movq$0, 16(%rdi) movq$0, 24(%rdi) movq$0, 32(%rdi) movq$0, 40(%rdi) movq$0, 48(%rdi) movq$0, 56(%rdi) movq$0, 64(%rdi) movq$0, 72(%rdi) ret which lacks the size optimization to use a zeroed %rax. Likewise for -Os which now looks like 0: 48 8d 57 30 lea0x30(%rdi),%rdx 4: 48 c7 07 00 00 00 00movq $0x0,(%rdi) b: 48 c7 47 08 00 00 00movq $0x0,0x8(%rdi) 12: 00 13: 48 c7 47 10 00 00 00movq $0x0,0x10(%rdi) 1a: 00 1b: 48 c7 47 18 00 00 00movq $0x0,0x18(%rdi) 22: 00 23: b9 08 00 00 00 mov$0x8,%ecx 28: 48 c7 47 20 00 00 00movq $0x0,0x20(%rdi) 2f: 00 30: 48 c7 47 28 00 00 00movq $0x0,0x28(%rdi) 37: 00 38: 31 c0 xor%eax,%eax 3a: 48 89 d7mov%rdx,%rdi 3d: f3 ab rep stos %eax,%es:(%rdi) 3f: c3 retq I suppose with -Os we use rep stosl because that's one byte smaller ...(?) I suppose doing the $0x0 optimization should be done post-reload.
[Bug middle-end/33103] Redundant multiplications for memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33103 Richard Guenther changed: What|Removed |Added Last reconfirmed|2007-08-18 09:02:38 |2012-06-06 --- Comment #2 from Richard Guenther 2012-06-06 10:11:41 UTC --- Re-confirmed.
[Bug middle-end/36598] Failed optimisation of return of struct argment in memcpy-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther 2012-06-06 10:15:42 UTC --- Fixed for avr and ppc at least.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
Depends on||16427
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Richard Guenther 2012-06-06
10:20:05 UTC ---
The memset DSE is PR16427.
Still we should represent this as a = {}; on the tree level, thus re-confirmed.
And mine.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #5 from Ruben Van Boxem 2012-06-06 10:25:26 UTC --- This is not only a problem, but also turns up with `std::unique_ptr` (so the header ) on Windows. This error is caught by Clang in c++11 mode: http://llvm.org/bugs/show_bug.cgi?id=12707
[Bug rtl-optimization/41455] memcpy not tail called if it's a struct assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41455 Richard Guenther changed: What|Removed |Added Target|arm-elf |arm-elf, x86_64-*-* Last reconfirmed|2009-09-24 06:29:30 |2012-06-06 6:29:30 --- Comment #2 from Richard Guenther 2012-06-06 10:29:39 UTC --- Re-confirmed. Can be reproduced on x86_64 with -Os -mstringop-strategy=libcall
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #6 from Jonathan Wakely 2012-06-06 10:43:22 UTC --- That's because ext/concurrence.h is included throughout the library. I plan to add __gthread_recursive_mutex_destroy on trunk but any fix on the release branches will have to be less intrusive.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-06 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 Ever Confirmed|0 |1
[Bug lto/51205] -flto discards memset/memcpy when only referenced by g++ generated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51205 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-06 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-06-06 10:54:36 UTC --- Can you try if this is fixed with GCC 4.7.x when using binutils 2.22 or newer and using the linker plugin?
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 --- Comment #7 from ravish 2012-06-06 11:00:20 UTC --- Hi, Yes that is true we need to build gmp which supports 32bit and 64bit.. My problem is that one how to build gmp with supporting both 32bit and 64bit. As per my knowledge the configure option we can pass as either ABI=32 or ABI=64.. How to set for both 32bit and 64bit? Same comment I saw in Bug-ID 42750(no comments for that). Please provide a solution for this issue..
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #10 from Richard Guenther 2012-06-06 11:00:31 UTC --- This is a dup of PR50417 *** This bug has been marked as a duplicate of bug 50417 ***
[Bug tree-optimization/50417] regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 Richard Guenther changed: What|Removed |Added CC||jay.foad at gmail dot com --- Comment #2 from Richard Guenther 2012-06-06 11:00:31 UTC --- *** Bug 52415 has been marked as a duplicate of this bug. ***
[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52861 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-06 Component|middle-end |fortran Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-06-06 11:10:00 UTC --- memset recognition is confused by the memcpy the frontend emits for ZSPM(IS) = ' '. data-reference/dependence analysis does not hande this. Why does the frontend not emit an assignment for this? Thus, simply *D.1909_46 = ""; ?
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #7 from Ruben Van Boxem 2012-06-06 11:10:34 UTC --- Changing this line: static typename __enable_if::__type to read: static typename __enable_if(sizeof(&_Rm::sema)), void>::__type makes the unique_ptr problem go away (see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/021863.html).
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #8 from Jonathan Wakely 2012-06-06 11:21:30 UTC --- Yes I know, but I want to get rid of that code entirely on trunk, and even a small tweak to fix the narrowing conversion might not be suitable for the release branches as it's not a GCC regression. But I'll try to get it fixed on the 4.6 and 4.7 branches.
[Bug bootstrap/53583] gcc 4.6.2 build issue..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53583 --- Comment #8 from Jonathan Wakely 2012-06-06 11:22:21 UTC --- I've already suggested you use the gcc-help mailing list not bugzilla.
[Bug other/53587] New: [manual] Option -mms-bitfields not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53587 Bug #: 53587 Summary: [manual] Option -mms-bitfields not documented Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@morous.org The web page about changes in 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html) mentions the option -mms-bitfields, but manual for 4.7 does not document it (at least the chapter "Option summary" misses it).
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #12 from Joost VandeVondele 2012-06-06 11:32:08 UTC --- It doesn't quite seem to work for this simple Fortran testcase yet SUBROUTINE S(a,N) INTEGER :: N,a(N) a=1 END SUBROUTINE S (works for memset to 0)
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #13 from rguenther at suse dot de 2012-06-06 11:39:25 UTC --- On Wed, 6 Jun 2012, Joost.VandeVondele at mat dot ethz.ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 > > --- Comment #12 from Joost VandeVondele ethz.ch> 2012-06-06 11:32:08 UTC --- > It doesn't quite seem to work for this simple Fortran testcase yet > > SUBROUTINE S(a,N) > INTEGER :: N,a(N) > a=1 > END SUBROUTINE S > > (works for memset to 0) Well, you can't transform this to a memset ;)
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 --- Comment #14 from Joost VandeVondele 2012-06-06 11:54:22 UTC --- (In reply to comment #13) > Well, you can't transform this to a memset ;) blush things work as advertised for correct testcases... thanks!
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 --- Comment #8 from rguenther at suse dot de 2012-06-06 11:55:32 UTC --- On Tue, 5 Jun 2012, jason at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 > > Jason Merrill changed: > >What|Removed |Added > > CC||jason at gcc dot gnu.org > > --- Comment #7 from Jason Merrill 2012-06-05 > 18:07:14 UTC --- > OK, here's the problem: > > free_lang_data_in_type clears TYPE_CONTEXT of Holder. > gen_tagged_type_die tries to emit an enclosing class first, but since > TYPE_CONTEXT is null, it thinks Holder isn't a nested class. > gen_struct_or_union_type_die calls scope_die_for, which forces out > ExtensionCord, which also generates a DIE for Holder. > gen_struct_or_union_type_die contiues to generate what is now a duplicate DIE > for Holder. > > What is the rationale for clearing TYPE_CONTEXT of Holder? It seems quite > deliberate, but there's no comment explaining why it would be a good idea. All of the clearing is done to push down memory usage and/or cause types to be referenced that are otherwise unused. A way to retain the latter would be to not recurse into TYPE_CONTEXT during find_decls_types_r and in free_lang_data_in_type only reset TYPE_CONTEXT when that is not in fld.pset (thus we didn't visit it, aka, it is unused). Not sure if this will reliably fix this kind of ICEs. Note that the fundamental issue with running free-lang-data with -g0 and lto1 with -g is that free-lang-data with -g0 assumes we won't generate debug information. I think the case in question is the only remaining case we do different things -g0 vs. -g in free-lang-data - and we should definitely remove that inconsistency. Thus, I suppose even the simple Index: tree.c === --- tree.c (revision 188260) +++ tree.c (working copy) @@ -4575,10 +4575,9 @@ free_lang_data_in_type (tree type) free_lang_data_in_one_sizepos (&TYPE_SIZE (type)); free_lang_data_in_one_sizepos (&TYPE_SIZE_UNIT (type)); - if (debug_info_level < DINFO_LEVEL_TERSE - || (TYPE_CONTEXT (type) - && TREE_CODE (TYPE_CONTEXT (type)) != FUNCTION_DECL - && TREE_CODE (TYPE_CONTEXT (type)) != NAMESPACE_DECL)) + if (TYPE_CONTEXT (type) + && TREE_CODE (TYPE_CONTEXT (type)) != FUNCTION_DECL + && TREE_CODE (TYPE_CONTEXT (type)) != NAMESPACE_DECL) TYPE_CONTEXT (type) = NULL_TREE; } should be ok at the expense of extra memory/disk space usage at -g0 (note we walk TYPE_CONTEXT for all types in find_decls_types_r, so even the restriction above looks odd - either we should restrict recursion as well or never clear TYPE_CONTEXT). Richard.
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 --- Comment #16 from Richard Guenther 2012-06-06 12:22:25 UTC --- Author: rguenth Date: Wed Jun 6 12:22:16 2012 New Revision: 188264 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188264 Log: 2012-06-06 Fabien Chene PR c++/52841 * parser.c (cp_parser_alias_declaration): Return earlier if an error occured. * g++.dg/cpp0x/pr52841.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr52841.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52841] [4.7 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 Richard Guenther changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] error: |[4.7 Regression] error: |type 'Solvable' is not a|type 'Solvable' is not a |base type for type |base type for type |'Resolvable'|'Resolvable' --- Comment #16 from Richard Guenther 2012-06-06 12:22:25 UTC --- Author: rguenth Date: Wed Jun 6 12:22:16 2012 New Revision: 188264 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188264 Log: 2012-06-06 Fabien Chene PR c++/52841 * parser.c (cp_parser_alias_declaration): Return earlier if an error occured. * g++.dg/cpp0x/pr52841.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr52841.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog --- Comment #17 from Richard Guenther 2012-06-06 12:23:00 UTC --- Fixed for trunk for now.
[Bug c++/52841] [4.7 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 Richard Guenther changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] error: |[4.7 Regression] error: |type 'Solvable' is not a|type 'Solvable' is not a |base type for type |base type for type |'Resolvable'|'Resolvable' --- Comment #17 from Richard Guenther 2012-06-06 12:23:00 UTC --- Fixed for trunk for now.
[Bug tree-optimization/53588] New: [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53588 Bug #: 53588 Summary: [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com Target: i686 Failing report: New failures: FAIL: gfortran.dg/vect/pr32380.f -O scan-tree-dump-times vect "vectorized 7 loops" 1 Happened after fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081. Test fails at least for i686 with -march=core2
[Bug tree-optimization/53081] memcpy/memset loop recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #15 from Igor Zamyatin 2012-06-06 12:43:09 UTC --- Fix causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53588
[Bug tree-optimization/53588] [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53588 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-06 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-06-06 12:50:40 UTC --- Mine.
[Bug rtl-optimization/53589] New: [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589
Bug #: 53589
Summary: [4.7/4.8 Regression] ICE in maybe_record_trace_start
with asm goto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
extern void foo (void) __attribute__ ((__noreturn__));
void
bar (int x)
{
if (x < 0)
foo ();
if (x == 0)
return;
__asm goto ("" : : : : lab);
lab:;
}
ICEs on x86_64-linux:
LC_ALL=C ./cc1 -O2 rh829247.c -quiet
rh829247.c: In function 'bar':
rh829247.c:12:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2193
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The problem is that we end up with asm goto that branches to the fallthru label
and shrink-wrapping wants to redirect the edge, but leaves broken CFG around.
[Bug tree-optimization/53588] [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53588 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2012-06-06 12:53:41 UTC --- Fixed.
[Bug fortran/32380] misaligned stores don't get vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380 --- Comment #11 from Richard Guenther 2012-06-06 12:53:35 UTC --- Author: rguenth Date: Wed Jun 6 12:53:30 2012 New Revision: 188266 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188266 Log: 2012-06-06 Richard Guenther PR testsuite/32380 * gfortran.dg/vect/pr32380.f: Adjust number of expected vectorized loops. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/pr32380.f
[Bug rtl-optimization/53589] [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-06 Known to work||4.6.2 Target Milestone|--- |4.7.1 Ever Confirmed|0 |1 Known to fail||4.7.0, 4.8.0 --- Comment #1 from Jakub Jelinek 2012-06-06 13:11:30 UTC --- Started with -fshrink-wrap addition http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179553
[Bug ada/53590] New: new compiler generates both SISD and SIMD instructions for parallel operations of a "pure" function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 Bug #: 53590 Summary: new compiler generates both SISD and SIMD instructions for parallel operations of a "pure" function Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: bauh...@futureapps.de The Ada compiler of 4.8.0 on Intel will either - produce 2 DIVSD and also 1 DIVPD (redundance), or - produce 2 DIVSD (no measurable parallelism) for the following function f that divides two pairs of 64 bit FPT types and returns one pair. The expectation is just 1 DIVPD. Other versions of the Ada compiler, and the C compiler, and the C++ compiler of the same version produce 1 DIVPD instruction, as expected. The line marked --! below switches between the two cases listed above. package Autovect is pragma Pure (Autovect); type Fpt is new Long_Float; type Vec is array (0 .. 1) of Fpt; --pragma Machine_Attribute (Vec, "vector_type"); --! --pragma Machine_Attribute (Vec, "may_alias"); function F (X0, X1, Y0, Y1 : Fpt) return Vec; private pragma Assert (Fpt'Size = 64); pragma Assert (Vec'Alignment = 16); end Autovect; package body Autovect is function F (X0, X1, Y0, Y1 : Fpt) return Vec is begin return (X0 / Y0, X1 / Y1); end F; end Autovect; Result: 0010 : 10:66 0f 28 e8 movapd %xmm0,%xmm5 14:66 0f 28 f2 movapd %xmm2,%xmm6 18:66 0f 14 e9 unpcklpd %xmm1,%xmm5 1c:66 0f 14 f3 unpcklpd %xmm3,%xmm6 20:f2 0f 5e c2 divsd %xmm2,%xmm0 24:66 0f 28 e5 movapd %xmm5,%xmm4 28:66 0f 5e e6 divpd %xmm6,%xmm4 2c:f2 0f 5e cb divsd %xmm3,%xmm1 30:66 0f 29 64 24 e8movapd %xmm4,-0x18(%rsp) 36:f2 0f 10 44 24 e8movsd -0x18(%rsp),%xmm0 3c:f2 0f 10 4c 24 f0movsd -0x10(%rsp),%xmm1 42:c3 retq 43:66 66 66 66 2e 0f 1f data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 4a:84 00 00 00 00 00 With "vector_type" machine attribute: 0010 : 10:f2 0f 5e c2 divsd %xmm2,%xmm0 14:f2 0f 5e cb divsd %xmm3,%xmm1 18:66 0f 14 c1 unpcklpd %xmm1,%xmm0 1c:c3 retq 1d:0f 1f 00 nopl (%rax) gnatchop -r -w autovect.ada && gnatmake -gnatwa -W -O3 -fno-inline -fomit-frame-pointer -msse3 -march=core2 -gnatp -gnata -v autovect.adb splitting autovect.ada into: autovect.ads autovect.adb GNATMAKE 4.8.0 20120525 (experimental) Copyright (C) 1995-2012, Free Software Foundation, Inc. "autovect.ali" being checked ... -> "autovect.ads" time stamp mismatch gcc -c -gnatwa -W -O3 -fno-inline -fomit-frame-pointer -msse3 -march=core2 -gnatp -gnata autovect.adb End of compilation Linux newnews 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Intel E6750 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/bauhaus/mine/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/bauhaus/src/gcc/trunk/configure --prefix=/home/bauhaus/mine --disable-nls --disable-libstdcxx-pch --enable-languages=c,ada,c++ Thread model: posix gcc version 4.8.0 20120525 (experimental) (GCC)
[Bug rtl-optimization/53589] [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589 --- Comment #2 from Jakub Jelinek 2012-06-06 13:16:53 UTC --- Created attachment 27562 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27562 gcc48-pr53589.patch Untested fix.
[Bug ada/53590] new compiler generates both SISD and SIMD instructions for parallel operations of a "pure" function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590
--- Comment #1 from Georg Bauhaus 2012-06-06
13:29:36 UTC ---
For comparison, consider this, giving expected results (1 DIVPD).
-- 8< --
typedef double fpt;
typedef fpt Vec[2];
struct ArrayWrap {
Vec _;
};
struct ArrayWrap f (fpt x0, fpt x1, fpt y0, fpt y1) {
return (struct ArrayWrap) { ._ = { x0 / y0, x1 / y1 } };
}
-- >8 --
(The corresponding Ada is
type ArrayWrap is record
Data : Vec;
end record;
(and
function F (X0, X1, Y0, Y1 : Fpt) return ArrayWrap is
begin
return (Data => (X0 / Y0, X1 / Y1));
end F;
giving the same results as originally reported, i.e. two DIVSD and
in addition one DIVPD.)
The C compiler (from the same build), when run with the same options,
$ gcc -c -W -O3 -fno-inline -fomit-frame-pointer -msse3 -mfpmath=sse
-march=core2 autovect.c
produces
:
0:66 0f 14 c1 unpcklpd %xmm1,%xmm0
4:66 0f 14 d3 unpcklpd %xmm3,%xmm2
8:66 0f 5e c2 divpd %xmm2,%xmm0
c:66 0f 29 44 24 e8movapd %xmm0,-0x18(%rsp)
12:f2 0f 10 4c 24 f0movsd -0x10(%rsp),%xmm1
18:f2 0f 10 44 24 e8movsd -0x18(%rsp),%xmm0
1e:c3 retq
Which has one DIVPD, as expected.
[Bug fortran/53591] New: Front-end optimize empty string assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53591 Bug #: 53591 Summary: Front-end optimize empty string assignments Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: tkoe...@gcc.gnu.org Based on PR 52861. I think it would be useful to front-end optimize (frontend-passes.c's optimize_assignment, utilizing empty_string()): character(len=5) :: str str = ' ' [That will create a memmove/memcpy followed by a memset.] to either str = '' (RHS length = 0) [This will use a memset] or to str = ' ' (RHS length = LHS length) [That will use an assignment] Currently, the middle-end likes a direct assignment better than a memset, but everything which avoids memmove/memcpy is good. Cf. also trans-expr.c's gfc_trans_string_copy.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #5 from Richard Guenther 2012-06-06
14:11:07 UTC ---
Created attachment 27563
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27563
proposed patch
Not as easy when the initialized struct contains padding ...
The following testcase is reduced from a fail of
gcc.target/x86_64/abi/test_struct_returning.c
where SRA messes up information in the padding. With s = {} being
a memset SRA would not do anything.
The question in general would be whether memcpy/memset affect padding
in a well-defined way, thus, if memset (&s, 0, sizeof (s)) is equivalent
to s = {} and if memcpy (&s, &r, sizeof (s)) is equivalent to s = r.
We at least assume that in the way we currently fold memcpy.
struct S { char c; long long i; };
struct S __attribute__((noinline,noclone))
foo (void)
{
struct S s = {};
s.c = 42;
return s;
}
void __attribute__((noinline,noclone))
keepit (struct S *s)
{
__builtin_memset (s, -1, sizeof (struct S));
}
void __attribute__((noinline,noclone))
clobberstack ()
{
struct S s;
keepit (&s);
}
int main ()
{
struct S s1, s2 = { 42, 0 };
clobberstack();
s1 = foo();
if (__builtin_memcmp (&s1, &s2, sizeof (struct S)) != 0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 Richard Guenther changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #6 from Richard Guenther 2012-06-06 14:13:15 UTC --- Joseph, Jason - any opinion on the question of equivalence between memcpy/memset and an aggregate assignment/init (also consider anonymous memory)?
[Bug ada/53592] New: ICE when hitting assigment to component of SSE vector_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592 Bug #: 53592 Summary: ICE when hitting assigment to component of SSE vector_type Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: georg...@googlemail.com Created attachment 27564 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27564 complete source text (ssa_view.ada) The subject line is a guess from GCC's final error message: gnatchop -w ssa_view.ada && gnatmake -gnatwa ssa_view.adb splitting ssa_view.ada into: ssa_view.ads ssa_view.adb gcc -c -gnatwa ssa_view.adb ssa_view.adb:4:36: warning: formal parameter "x1" is not referenced ssa_view.adb: In function 'Ssa_View.Test_View_Ssa_Lhs': ssa_view.adb:11:1: error: conversion of an SSA_NAME on the left hand side VIEW_CONVERT_EXPR(result_2); VIEW_CONVERT_EXPR(result_2)[0] = x0_1(D); +===GNAT BUG DETECTED==+ | 4.8.0 20120525 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | verify_gimple failed | | Error detected around ssa_view.adb:11:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). ssa_view.adb ssa_view.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:432 gnatmake: "ssa_view.adb" compilation error Compilation exited abnormally with code 4 at Wed Jun 6 16:16:34 Linux newnews 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/bauhaus/mine/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/bauhaus/src/gcc/trunk/configure --prefix=/home/bauhaus/mine --disable-nls --disable-libstdcxx-pch --enable-languages=c,ada,c++ Thread model: posix gcc version 4.8.0 20120525 (experimental) (GCC)
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Ed Smith-Rowland <3dw4rd at verizon dot net> changed: What|Removed |Added CC||jason at redhat dot com --- Comment #18 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-06-06 15:03:16 UTC --- Jason, Could you check out the trail starting here and render an opinion. I'll make sure the patch still works. I wanted to get this in 4.7.1 but it'll have to wait until 4.7.2 - I just didn't have time. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Thanks, Ed
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 --- Comment #9 from Jason Merrill 2012-06-06 15:27:02 UTC --- (In reply to comment #8) > All of the clearing is done to push down memory usage and/or cause > types to be referenced that are otherwise unused. A way to retain the > latter would be to not recurse into TYPE_CONTEXT during find_decls_types_r > and in free_lang_data_in_type only reset TYPE_CONTEXT when > that is not in fld.pset (thus we didn't visit it, aka, it is unused). If a type is nested inside another type, using the inner type necessarily uses the outer type; we need to at least declare the outer type so we have some place to put the inner type. So I don't think there's any optimization opportunity here. > Note that the fundamental issue with running free-lang-data with -g0 > and lto1 with -g is that free-lang-data with -g0 assumes we won't > generate debug information. Yes, but that isn't the problem with this PR; in this case cc1plus and lto1 are both run with -g. free_lang_data_in_type is clearing TYPE_CONTEXT even though we want full debug information, and this lying to the debugging back end results in the ICE.
[Bug fortran/45602] Reject coarrays for move_alloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45602 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus 2012-06-06 15:34:23 UTC --- This PR effectively superseded by PR 53526. *** This bug has been marked as a duplicate of bug 53526 ***
[Bug fortran/53526] [Coarray] (lib) Properly handle MOVE_ALLOC for coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53526 --- Comment #3 from Tobias Burnus 2012-06-06 15:34:23 UTC --- *** Bug 45602 has been marked as a duplicate of this bug. ***
[Bug c/53580] Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-06 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2012-06-06 16:05:51 UTC --- Created attachment 27565 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27565 gcc48-pr53580.patch Untested 4.8 patch.
[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470 Jason Merrill changed: What|Removed |Added CC|jason at redhat dot com | --- Comment #10 from Jason Merrill 2012-06-06 16:09:59 UTC --- I wish bugzilla were clever enough not to add me to CC if my other email address is already there...
[Bug c/53593] New: #pragma prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53593 Bug #: 53593 Summary: #pragma prefetch Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: li...@graasmilk.net I would like to request a prefetch pragma like icc provides ( see: http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/cref_cls/common/cppref_pragma_prefetch_noprefetch.htm ) I know about the intrinsics, but the pragma, to me, seems more abstract and easier to handle.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 --- Comment #7 from Jason Merrill 2012-06-06 16:36:31 UTC --- (In reply to comment #6) > Joseph, Jason - any opinion on the question of equivalence between > memcpy/memset and an aggregate assignment/init (also consider anonymous > memory)? The transformation seems safe to me. Aggregate assignment/init leave anonymous bit-fields and padding with unspecified contents, but I imagine GCC initializes/copies them anyway. In C++ any class that would be affected by the difference is not trivially copyable, so using memset/memcpy is already undefined behavior.
[Bug c++/53585] template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585 --- Comment #2 from Simon Hill 2012-06-06 16:43:41 UTC --- Thats... really odd but OK. I guess I read it as you do, the key words being "expressed as". I wonder whether that was the intent, and if so, what their rationale was. IMO it's very arbitrary and unintuitive, and for the life of me I can't think of a reason. Do you think it would be worth requesting a confirmation/clarification of this from the C++ standard working group or similar? (I have no idea what that would entail). Thanks for checking this out. For the moment I guess the workaround is to instead use a type-parameter and require the type to contain a constexpr pointer-to-member.
[Bug c++/53594] New: [C++11Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594
Bug #: 53594
Summary: [C++11Spurious -Wuninitialized warning for member with
NSDMI
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
template
class Range
{
const T min = Min;
};
Range r;
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Summary|[C++11Spurious |[C++11] Spurious |-Wuninitialized warning for |-Wuninitialized warning for |member with NSDMI |member with NSDMI --- Comment #1 from Jonathan Wakely 2012-06-06 16:52:00 UTC --- $ g++-4.7 -std=c++11 c.cc -c -Wuninitialized -c c.cc: In instantiation of 'class Range': c.cc:7:15: required from here c.cc:4:19: warning: non-static const member 'const int Range::min' in class without a constructor [-Wuninitialized] The test in class.c:check_bases_and_members doesn't appear to look for NSDMIs
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594
--- Comment #2 from Jonathan Wakely 2012-06-06
16:56:12 UTC ---
Reduced:
class Range
{
const int min = 1;
};
[Bug c/53580] Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 Jakub Jelinek changed: What|Removed |Added Attachment #27565|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek 2012-06-06 17:41:45 UTC --- Created attachment 27566 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27566 gcc48-pr53580.patch Updated 4.8 patch.
[Bug c/53580] Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 --- Comment #5 from Jakub Jelinek 2012-06-06 17:50:42 UTC --- Created attachment 27567 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27567 gcc47-pr53580.patch Untested 4.7 patch.
[Bug fortran/53509] exp and log function give unexpected results when called with numbers as arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53509 --- Comment #3 from Fedor Baart 2012-06-06 17:55:54 UTC --- Thanks, I managed to solve this by recompiling gmp using gcc 4.5 instead of clang, which is the default in macports.
[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52861
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Thomas Koenig 2012-06-06
18:08:10 UTC ---
This should be rather simple. Not-yet-regression-tested patch:
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 188138)
+++ frontend-passes.c (Arbeitskopie)
@@ -37,6 +37,7 @@ static bool optimize_comparison (gfc_expr *, gfc_i
static bool optimize_trim (gfc_expr *);
static bool optimize_lexical_comparison (gfc_expr *);
static void optimize_minmaxloc (gfc_expr **);
+static bool empty_string (gfc_expr *e);
/* How deep we are inside an argument list. */
@@ -734,11 +735,17 @@ optimize_assignment (gfc_code * c)
lhs = c->expr1;
rhs = c->expr2;
- /* Optimize away a = trim(b), where a is a character variable. */
-
if (lhs->ts.type == BT_CHARACTER)
-remove_trim (rhs);
+{
+ /* Optimize away a = trim(b), where a is a character variable. */
+ remove_trim (rhs);
+ /* Replace a = ' ' by a = '' to optimize away a memcpy. */
+
+ if (empty_string(rhs))
+ rhs->value.character.length = 0;
+}
+
if (lhs->rank > 0 && gfc_check_dependency (lhs, rhs, true) == 0)
optimize_binop_array_assignment (c, &rhs, false);
[Bug c/53593] #pragma prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53593 --- Comment #1 from Andrew Pinski 2012-06-06 18:17:28 UTC --- This pragma is a control for the equivalent of the option -fprefetch-loop-arrays . You might want to try out -fprefetch-loop-arrays out.
[Bug libgomp/52993] gomp_init_nest_lock_25: possible bad call to memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52993 --- Comment #2 from Jakub Jelinek 2012-06-06 18:31:13 UTC --- Author: jakub Date: Wed Jun 6 18:31:06 2012 New Revision: 188276 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188276 Log: PR libgomp/52993 * config/linux/lock.c (gomp_init_nest_lock_25): Fix up last argument to memset call. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config/linux/lock.c
[Bug libgomp/52993] gomp_init_nest_lock_25: possible bad call to memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52993 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek 2012-06-06 18:32:45 UTC --- Not a big deal, since this is a Linux only file, and on Linux LIBGOMP_GNU_SYMBOL_VERSIONING should be defined, therefore the code isn't compiled in. Fixed onthe trunk anyway, not worth backporting.
[Bug c++/53586] Internal compiler errors on cp/pt.c:12077 and expr.c:9147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53586
--- Comment #2 from Paulo Torrens 2012-06-06
18:43:13 UTC ---
(In reply to comment #1)
> What happens if you use decltype instead of typeof ?
template auto ptr2bitmap(T *bitmap, int width, int depth = 3) ->
decltype(decltype(unsigned char[depth])[width]) *{
return bitmap;
};
int main() {
void *x;
auto a = ptr2bitmap(x, 100);
};
test.cpp:2:10: error: expected primary-expression before 'decltype'
test.cpp:2:10: error: expected ')' before 'decltype'
test.cpp:2:1: error: expected type-specifier before 'decltype'
test.cpp:2:1: error: expected initializer before 'decltype'
And without decltype and typeof at all:
template auto ptr2bitmap(T *bitmap, int width, int depth = 3) ->
unsigned char[depth][width] *{
return bitmap;
};
int main() {
void *x;
auto a = ptr2bitmap(x, 100);
};
test.cpp:2:15: error: use of parameter 'depth' outside function body
test.cpp:2:22: error: use of parameter 'width' outside function body
test.cpp:2:29: error: expected initializer before '*' token
[Bug rtl-optimization/53595] New: Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 Bug #: 53595 Summary: Code size increase of +10% between two 4.7.1 snapshot Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Created attachment 27568 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27568 C source This problem report is about a +10% of code size increase between the following two 4.7.1 versions of gcc: V1: SVN 185693 gcc-4_7-branch from 2012-03-22, 4.7.1 (prerelease) V2: SVN 188257 gcc-4_7-branch from 2012-06-06, 4.7.1 (prerelease) The attached test case is a reduced test case out of many other sources that suffer from the same problem, so that the overall performance degradation is unpleasant. The RTL dumps show that the first pass that differs is IRA. == Command line == $ avr-gcc -mmcu=atmega168 -c -std=gnu99 -Os -mstrict-X -ffixed-2 -ffixed-3 -dp -fdump-rtl-ira-details -fdump-rtl-reload-details -fdump-rtl-postreload-details bresenham-i.c -o bresenham-i-1.o -save-temps=obj resp. with -o bresenham-i-2.o for the second 4.7.1 snapshot. == GCC configure == Target: avr Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 Thread model: single gcc version 4.7.1 20120606 (prerelease) (GCC) GNU C (GCC) version 4.7.1 20120606 (prerelease) (avr) compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 It's a canadian cross, but that surely does not matter here...
[Bug c++/53596] New: g++-4.7 -Wall shouldn't complain for non-virtual protected dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596
Bug #: 53596
Summary: g++-4.7 -Wall shouldn't complain for non-virtual
protected dtor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kim.wali...@gmail.com
Created attachment 27569
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27569
g++-4.7 -Wall produces erronous [-Wdelete-non-virtual-dtor] warning
g++-4.7 shouldn't complain for non-virtual protected dtor if the base class has
virtual functions. Previous versions of g++ do not warn, other compilers (msvc
/W4, sunCC +w2) do not warn.
terminal log:
[walki@walki Desktop]$ g++-4.7 -Wall test.cpp
test.cpp: In function ‘int main()’:
test.cpp:19:10: warning: deleting object of polymorphic class type ‘Derived’
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/
// file: test.cpp
#include
class Base {
public:
virtual void foo() = 0;
protected:
~Base() { } // legal C++ code
};
class Derived : public Base {
public:
virtual void foo() { std::cout << "Derived::foo()" << std::endl; }
~Derived() { std::cout << "Derived::~Derived()" << std::endl; }
};
int main() {
Derived* derived = new Derived();
derived->foo();
delete derived; // legal, there must be no warning!
return 0;
}
/
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #1 from Georg-Johann Lay 2012-06-06 19:54:34 UTC --- Created attachment 27570 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27570 ira dump of older version (good)
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #2 from Georg-Johann Lay 2012-06-06 19:55:49 UTC --- Created attachment 27571 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27571 ira dump of newer version (+10%)
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #3 from Georg-Johann Lay 2012-06-06 19:56:57 UTC --- Created attachment 27572 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27572 reload dump of older version (good)
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #4 from Georg-Johann Lay 2012-06-06 19:58:10 UTC --- Created attachment 27573 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27573 reload dump of newer version (+10%)
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek 2012-06-06 20:01:06 UTC --- That's not very narrow interval. Please bisect what affected it (or what affected it most).
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #6 from Georg-Johann Lay 2012-06-06 20:05:02 UTC --- And here is the first part of the diff of the reload dumps that shows that something weird is going on: --- bresenham-i-1.198r.reloadWed Jun 6 19:59:24 2012 +++ bresenham-i-2.198r.reloadWed Jun 6 19:59:26 2012 @@ -273,123 +273,378 @@ changing reg in insn 251 changing reg in insn 249 changing reg in insn 252 +Spilling for insn 40. +Using reg 30 for reload 0 +Spilling for insn 44. +Using reg 26 for reload 0 +Spilling for insn 45. +Using reg 28 for reload 0 Spilling for insn 65. +Using reg 28 for reload 0 Spilling for insn 68. +Using reg 28 for reload 0 Spilling for insn 71. +Using reg 28 for reload 0 Spilling for insn 75. +Using reg 28 for reload 0 Spilling for insn 76. +Using reg 28 for reload 0 Spilling for insn 78. +Using reg 26 for reload 0 +Spilling for insn 248. +Using reg 30 for reload 0 +Spilling for insn 249. +Using reg 30 for reload 0 Spilling for insn 202. +Using reg 30 for reload 0 Spilling for insn 203. +Using reg 30 for reload 0 +Spilling for insn 96. +Using reg 30 for reload 0 +Spilling for insn 204. +Using reg 30 for reload 0 +Spilling for insn 205. +Using reg 30 for reload 0 +Spilling for insn 108. +Using reg 28 for reload 0 +Spilling for insn 112. +Using reg 28 for reload 0 +Spilling for insn 114. +Using reg 28 for reload 0 Spilling for insn 142. +Using reg 28 for reload 0 Spilling for insn 143. +Using reg 30 for reload 0 Spilling for insn 144. +Using reg 30 for reload 0 Spilling for insn 145. +Using reg 30 for reload 0 Spilling for insn 146. +Using reg 30 for reload 0 +Spilling for insn 154. +Using reg 30 for reload 0 +Spilling for insn 159. +Using reg 30 for reload 0 +Spilling for insn 165. +Using reg 30 for reload 0 +Spilling for insn 170. +Using reg 30 for reload 0 Spilling for insn 176. +Using reg 30 for reload 0 Spilling for insn 179. +Using reg 30 for reload 0 +Spilling for insn 40. +Using reg 30 for reload 0 +Spilling for insn 44. +Using reg 26 for reload 0 +Spilling for insn 45. +Using reg 28 for reload 0 +Spilling for insn 65. +Using reg 28 for reload 0 +Spilling for insn 68. +Using reg 28 for reload 0 +Spilling for insn 71. +Using reg 28 for reload 0 +Spilling for insn 75. +Using reg 28 for reload 0 +Spilling for insn 76. +Using reg 28 for reload 0 +Spilling for insn 78. +Using reg 26 for reload 0 +Spilling for insn 248. +Using reg 30 for reload 0 +Spilling for insn 249. +Using reg 30 for reload 0 +Spilling for insn 202. +Using reg 30 for reload 0 +Spilling for insn 203. +Using reg 30 for reload 0 +Spilling for insn 96. +Using reg 30 for reload 0 +Spilling for insn 204. +Using reg 30 for reload 0 +Spilling for insn 205. +Using reg 30 for reload 0 +Spilling for insn 108. +Using reg 28 for reload 0 +Spilling for insn 112. +Using reg 28 for reload 0 +Spilling for insn 114. +Using reg 28 for reload 0 +Spilling for insn 142. +Using reg 28 for reload 0 +Spilling for insn 143. +Using reg 30 for reload 0 +Spilling for insn 144. +Using reg 30 for reload 0 +Spilling for insn 145. +Using reg 30 for reload 0 +Spilling for insn 146. +Using reg 30 for reload 0 +Spilling for insn 154. +Using reg 30 for reload 0 +Spilling for insn 159. +Using reg 30 for reload 0 +Spilling for insn 165. +Using reg 30 for reload 0 +Spilling for insn 170. +Using reg 30 for reload 0 +Spilling for insn 176. +Using reg 30 for reload 0 +Spilling for insn 179. +Using reg 30 for reload 0
[Bug c++/53585] template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585 --- Comment #3 from Daniel Krügler 2012-06-06 20:06:56 UTC --- (In reply to comment #2) > I wonder whether that was the intent, and if so, what their rationale was. > IMO it's very arbitrary and unintuitive, and for the life of me I can't think > of a reason. Yes, this was the intend, it is exactly the same wording as in C++03. When C++11 was finished everyone was aware that the final rule where still overly constraining and that relaxation of the current constraints is under investigation. > Do you think it would be worth requesting a confirmation/clarification of this > from the C++ standard working group or similar? (I have no idea what that > would > entail). I don't think that a clarification is needed. There is already active work to relax the existing rules, but that is not C++11 as specified.
[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53595 --- Comment #7 from Georg-Johann Lay 2012-06-06 20:12:19 UTC --- (In reply to comment #5) > That's not very narrow interval. Please bisect what affected it (or what > affected it most). The only changes to 4_7-branch in the IRA/reload area was for PR52804. Will take until friday to before I can look deeper into it.
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 Brent W. Barker changed: What|Removed |Added CC||b.w.barker at gmail dot com --- Comment #16 from Brent W. Barker 2012-06-06 20:19:57 UTC --- I found that the following nested deallocation program still fails in 4.6.3. Sorry it's so long, I don't have time to think about how to shorten it right now. It compiles and runs without error with ifort 12.1.4 20120410, and I didn't try it with 4.7. $ gfortran --version GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ... $ uname -a Linux hostname 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gfortran testdealloc.F90 $ ./a.out *** glibc detected *** ./a.out: double free or corruption (top): 0x01edb0a0 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x7fadbf3b1626] ./a.out[0x400fa7] ./a.out[0x401029] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fadbf35476d] ./a.out[0x400709] === Memory map: 0040-00402000 r-xp 08:05 132394 /home/barker/sandbox/a.out 00601000-00602000 r--p 1000 08:05 132394 /home/barker/sandbox/a.out 00602000-00603000 rw-p 2000 08:05 132394 /home/barker/sandbox/a.out 01ed8000-01ef9000 rw-p 00:00 0 [heap] 7fadbebed000-7fadbec02000 r-xp 08:05 7340318 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fadbec02000-7fadbee01000 ---p 00015000 08:05 7340318 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fadbee01000-7fadbee02000 r--p 00014000 08:05 7340318 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fadbee02000-7fadbee03000 rw-p 00015000 08:05 7340318 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fadbee03000-7fadbeefc000 r-xp 08:05 7340241 /lib/x86_64-linux-gnu/libm-2.15.so 7fadbeefc000-7fadbf0fb000 ---p 000f9000 08:05 7340241 /lib/x86_64-linux-gnu/libm-2.15.so 7fadbf0fb000-7fadbf0fc000 r--p 000f8000 08:05 7340241 /lib/x86_64-linux-gnu/libm-2.15.so 7fadbf0fc000-7fadbf0fd000 rw-p 000f9000 08:05 7340241 /lib/x86_64-linux-gnu/libm-2.15.so 7fadbf0fd000-7fadbf132000 r-xp 08:05 393626 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fadbf132000-7fadbf331000 ---p 00035000 08:05 393626 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fadbf331000-7fadbf332000 r--p 00034000 08:05 393626 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fadbf332000-7fadbf333000 rw-p 00035000 08:05 393626 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fadbf333000-7fadbf4e6000 r-xp 08:05 7340313 /lib/x86_64-linux-gnu/libc-2.15.so 7fadbf4e6000-7fadbf6e5000 ---p 001b3000 08:05 7340313 /lib/x86_64-linux-gnu/libc-2.15.so 7fadbf6e5000-7fadbf6e9000 r--p 001b2000 08:05 7340313 /lib/x86_64-linux-gnu/libc-2.15.so 7fadbf6e9000-7fadbf6eb000 rw-p 001b6000 08:05 7340313 /lib/x86_64-linux-gnu/libc-2.15.so 7fadbf6eb000-7fadbf6f rw-p 00:00 0 7fadbf6f-7fadbf804000 r-xp 08:05 393401 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fadbf804000-7fadbfa04000 ---p 00114000 08:05 393401 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fadbfa04000-7fadbfa05000 r--p 00114000 08:05 393401 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fadbfa05000-7fadbfa07000 rw-p 00115000 08:05 393401 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fadbfa07000-7fadbfa29000 r-xp 08:05 7340317 /lib/x86_64-linux-gnu/ld-2.15.so 7fadbfc04000-7fadbfc08000 rw-p 00:00 0 7fadbfc26000-7fadbfc29000 rw-p 00:00 0 7fadbfc29000-7fadbfc2a000 r--p 00022000 08:05 7340317 /lib/x86_64-linux-gnu/ld-2.15.so 7fadbfc2a000-7fadbfc2c000 rw-p 00023000 08:05 7340317 /lib/x86_64-linux-gnu/ld-2.15.so 7fff13969000-7fff1398b000 rw-p 00:00 0 [stack] 7fff139d5000-7fff139d6000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted (core dumped) module class_Foo implicit none type :: SubFoo integer :: num end type type :: Foo class(SubFoo), allocatable :: aSubFoo end type Foo type :: SuperFoo type(Foo), allocatable, dimension(:) :: foos end type end module class_Foo program testdealloc use class_Foo implicit none type(SuperFoo) :: mySuperFoo type(Foo), allocatable, dimension(:) :: myFoos type(SubFoo) :: mySubFoo mySubFoo=SubFoo(1) allocate(myFoos(10)) allocate
[Bug fortran/53597] New: [4.6/4.7/4.8 Regression] F95/F2003 constraint no longer triggers: un-SAVED default-initialized module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53597 Bug #: 53597 Summary: [4.6/4.7/4.8 Regression] F95/F2003 constraint no longer triggers: un-SAVED default-initialized module variable Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Based on the discussion at https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/7QfDs7wtKVY The following check in resolve.c does not trigger as attr.save == SAVE_IMPLICIT: if (!(sym->value || no_init_flag) && sym->ns->proc_name && sym->ns->proc_name->attr.flavor == FL_MODULE && !sym->ns->save_all && !sym->attr.save && !sym->attr.pointer && !sym->attr.allocatable && gfc_has_default_initializer (sym->ts.u.derived) && gfc_notify_std (GFC_STD_F2008, "Fortran 2008: Implied SAVE for " "module variable '%s' at %L, needed due to " "the default initialization", sym->name, when compiling the following program with -std=f95 or -std=f2003: MODULE somemodule IMPLICIT NONE TYPE sometype INTEGER :: i DOUBLE PRECISION, POINTER, DIMENSION(:,:) :: coef => NULL() END TYPE sometype TYPE(sometype) :: somevariable END MODULE somemodule Possible patches: a) Check for (sym->attr.save == SAVE_EXPLICIT || sym->value) b) Use the patch below: --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -3810,8 +3810,9 @@ match_attr_spec (void) } } - /* Module variables implicitly have the SAVE attribute. */ - if (gfc_current_state () == COMP_MODULE && !current_attr.save) + /* Since Fortran 2008 module variables implicitly have the SAVE attribute. */ + if (gfc_current_state () == COMP_MODULE && !current_attr.save + && (gfc_option.allow_std & GFC_STD_F2008) != 0) current_attr.save = SAVE_IMPLICIT; colon_seen = 1;
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 --- Comment #17 from janus at gcc dot gnu.org 2012-06-06 20:58:18 UTC --- (In reply to comment #16) > I found that the following nested deallocation program still fails in 4.6.3. I can confirm that it fails with 4.6.3. However, it works for me with 4.7.0 and 4.8 trunk.
[Bug other/53598] New: missed diagnostics / equality comparison result unused.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53598
Bug #: 53598
Summary: missed diagnostics / equality comparison result
unused.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
i've found in my codebase a hidden typo bug.
#include
void foo( std::list::const_iterator& i, std::list const& l )
{
if ( ++i == l.end() )
i == l.begin(); <=== here
}
g++ with -Wall -Wextra doesn't warn about this while clang++ wins:
noop-if.cpp:5:5: warning: equality comparison result unused
[-Wunused-comparison]
i == l.begin();
~~^~~~
noop-if.cpp:5:5: note: use '=' to turn this equality comparison into an
assignment
i == l.begin();
^~
=
1 warning generated.
[Bug rtl-optimization/51938] missed optimization: 2 comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #3 from Marc Glisse 2012-06-06 21:22:59 UTC --- Note that if I replace: if(x<0) return NEG; with: if(!(x>=0)) return NEG; then ifcombine recognizes the pattern and optimizes it (the generated code is slightly different since that changes the behavior for NaN). No time to investigate right now, but I wanted to add this note to the PR.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug c++/53599] New: gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 Bug #: 53599 Summary: gcc-4.7.1_rc20120606 segfaults compiling boost.karma Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@s-e-f-i.de The attached preprocessed source makes the first release candidate of gcc-4.7 segfault, gcc-4.7.0 was fine. No additional compilation options are required. I have just spotted this and not begun to try to reduce the testcase.
[Bug c++/53599] gcc-4.7.1_rc20120606 segfaults compiling boost.karma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599 --- Comment #1 from Philipp 2012-06-06 21:45:30 UTC --- Created attachment 27574 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27574 Preprocessed source
[Bug libgomp/53600] New: Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53600 Bug #: 53600 Summary: Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1). Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: pascu...@me.com I was able to successfully install the family of gcc compiles in Cygwin. I tried to compile a Fortran90 code with the option -fopenmp and I got the following error message (the program uses OpenMP directives): Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1). No such file or directory Thank you very much for all your help.
[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596
--- Comment #1 from Jonathan Wakely 2012-06-06
22:43:23 UTC ---
The warning is valid, the fact Base is protected is irrelevant, you're not
using delete with a Base* operand.
Consider:
class MoreDerived : public Derived {
public:
~Derived() { std::cout << "MoreDerived::~MoreDerived()" << std::endl;
}
};
int main() {
Derived* morederived = new MoreDerived();
morederived->foo();
delete morederived; // undefined behaviour
}
Now the warning is entirely correct, you are deleting a Derived* which is a
polymorphic type without a virtual destructor, so the program has undefined
behaviour. That's substantially the same as your example, on the line:
delete derived;
the compiler doesn't know that the Derived* points to a Derived or a
MoreDerived, so it warns you it might cause undefined behaviour.
N.B. Clang (known for much better diagnostics than MSVC or Sun CC) also warns
for your example:
w.cc:19:3: warning: delete called on 'Derived' that has virtual functions but
non-virtual destructor [-Wdelete-non-virtual-dtor]
delete derived; // legal, there must be no warning!
^
1 warning generated.
[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596 --- Comment #2 from Jonathan Wakely 2012-06-06 22:45:00 UTC --- The reason previous versions of GCC do not warn is because GCC has been improved and now issues a warning for unsafe code that it didn't diagnose before. This is a good thing.
[Bug c++/53567] "ICE: Error reporting routines re-entered" on missing enum entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567 --- Comment #3 from paolo at gcc dot gnu.org 2012-06-06 23:01:52 UTC --- Author: paolo Date: Wed Jun 6 23:01:45 2012 New Revision: 188283 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188283 Log: /cp 2012-06-06 Paolo Carlini PR c++/53567 * typeck.c (cp_perform_integral_promotions): New, like perform_integral_promotions but also takes a tsubst_flags_t parameter. (pointer_diff): Add tsubst_flags_t parameter. (decay_conversion, cp_default_conversion, cp_build_array_ref, cp_build_binary_op, cp_build_unary_op, build_static_cast_1, build_reinterpret_cast_1, cp_build_modify_expr, convert_for_assignment): Adjust. * optimize.c (build_delete_destructor_body): Adjust. * init.c (expand_virtual_init, expand_default_init, build_new_1, build_new, build_vec_delete_1, build_vec_init, build_delete): Adjust. (construct_virtual_base): Adjust LOOKUP_COMPLAIN -> 0. * class.c (build_base_path): Adjust. * decl.c (compute_array_index_type, finish_destructor_body): Likewise. * method.c (synthesized_method_walk): Adjust flag and complain. * rtti.c (ifnonnull): Add tsubst_flags_t parameter. (build_typeid, build_dynamic_cast_1): Adjust. * except.c (initialize_handler_parm): Likewise. * typeck2.c (process_init_constructor_record): Likewise. * pt.c (tsubst_friend_class): Don't change flags. * semantics.c (finish_goto_stmt, handle_omp_for_class_iterator, finish_static_assert): Likewise. * parser.c (cp_parser_lookup_name): Just pass 0 as flags to lookup_name_real. * call.c (build_op_delete_call): Add tsubst_flags_t parameter. (convert_like_real, convert_arg_to_ellipsis, convert_for_arg_passing): Adjust. (standard_conversion): Adjust LOOKUP_COMPLAIN -> 0. (implicit_conversion): Mask out tf_error with a FIXME. (build_user_type_conversion_1, build_new_op_1, build_over_call): Use complain & tf_error instead of flags & LOOKUP_COMPLAIN. * cvt.c (cp_convert_to_pointer, convert_to_pointer_force, build_up_reference, convert_to_reference, cp_convert, cp_convert_and_check, ocp_convert, convert_force): Add tsubst_flags_t parameter. (convert_to_reference, ocp_convert): Use complain & tf_error instead of flags & LOOKUP_COMPLAIN. (convert_force): Adjust LOOKUP_COMPLAIN -> 0. * name-lookup.c (identifier_type_value_1, lookup_qualified_name, lookup_name_real, lookup_function_nonclass, lookup_name, lookup_name_prefer_type): Adjust LOOKUP_COMPLAIN -> 0. * cp-tree.h: Adjust prototypes; remove LOOKUP_COMPLAIN. /testsuite 2012-06-06 Paolo Carlini PR c++/53567 * g++.dg/cpp0x/alias-decl-19.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/decl.c trunk/gcc/cp/except.c trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/optimize.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/rtti.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53567] "ICE: Error reporting routines re-entered" on missing enum entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Paolo Carlini 2012-06-06 23:11:58 UTC --- Should be fixed.
[Bug c++/51214] [4.7/4.8 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 --- Comment #3 from fabien at gcc dot gnu.org 2012-06-07 05:36:23 UTC --- Author: fabien Date: Thu Jun 7 05:36:18 2012 New Revision: 188294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188294 Log: gcc/testsuite/ChangeLog 2012-06-07 Fabien Chêne PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-06-07 Fabien Chêne PR c++/51214 * cp-tree.h (insert_late_enum_def_into_classtype_sorted_fields): Declare. * class.c (insert_into_classtype_sorted_fields): New. (add_enum_fields_to_record_type): New. (count_fields): Adjust the comment. (add_fields_to_record_type): Likewise. (finish_struct_1): Move the code that inserts the fields for the sorted case, into insert_into_classtype_sorted_fields, and call it. (insert_late_enum_def_into_classtype_sorted_fields): Define. * decl.c (finish_enum_value_list): Call insert_late_enum_def_into_classtype_sorted_fields if a late enum definition is encountered. Added: trunk/gcc/testsuite/g++.dg/cpp0x/forw_enum11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/53580] Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 --- Comment #6 from Jakub Jelinek 2012-06-07 06:37:00 UTC --- Author: jakub Date: Thu Jun 7 06:36:55 2012 New Revision: 188298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188298 Log: PR middle-end/53580 * omp-low.c (scan_omp): Change first argument to gimple_seq *, call walk_gimple_seq_mod instead of walk_gimple_seq. (scan_sharing_clauses, scan_omp_parallel, scan_omp_task, scan_omp_for, scan_omp_sections, scan_omp_single, execute_lower_omp): Adjust callers. (scan_omp_1_stmt): Likewise. If check_omp_nesting_restrictions returns false, replace stmt with GIMPLE_NOP. (check_omp_nesting_restrictions): Instead of issuing warnings, issue errors and return false if any errors were reported. * gcc.dg/gomp/nesting-1.c: Expect errors rather than warnings. * gcc.dg/gomp/critical-4.c: Likewise. * gfortran.dg/gomp/appendix-a/a.35.1.f90: Likewise. * gfortran.dg/gomp/appendix-a/a.35.3.f90: Likewise. * gfortran.dg/gomp/appendix-a/a.35.4.f90: Likewise. * gfortran.dg/gomp/appendix-a/a.35.6.f90: Likewise. * c-c++-common/gomp/pr53580.c: New test. * testsuite/libgomp.c/pr26943-2.c: Remove #pragma omp barrier, use GOMP_barrier () call instead. * testsuite/libgomp.c/pr26943-3.c: Likewise. * testsuite/libgomp.c/pr26943-4.c: Likewise. * testsuite/libgomp.fortran/vla4.f90: Remove !$omp barrier, call GOMP_barrier instead. * testsuite/libgomp.fortran/vla5.f90: Likewise. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr53580.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gomp/critical-4.c trunk/gcc/testsuite/gcc.dg/gomp/nesting-1.c trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.35.1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.35.3.f90 trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.35.4.f90 trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.35.6.f90 trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c/pr26943-2.c trunk/libgomp/testsuite/libgomp.c/pr26943-3.c trunk/libgomp/testsuite/libgomp.c/pr26943-4.c trunk/libgomp/testsuite/libgomp.fortran/vla4.f90 trunk/libgomp/testsuite/libgomp.fortran/vla5.f90
