[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2012-03-17 04:57:55 UTC --- (In reply to comment #1) > > Ideally, we'd just accept long identifiers, but the maximum name length is > hard-coded (GFC_MAX_SYMBOL_LEN) and already way too large. I want to change > this to string pointers (probably using a string pool, maybe the GCC common > implementation, TBD). The OP used -std=f95, the max identifier is 31. gfortran's behavior is already ideal in that she correctly reports an error. If the OP finds the run-on diagnostics confusing, then OP should use -fmax-errors=1.
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #1 from Marc Glisse 2012-03-17 01:05:57 UTC --- Note that {1,2,0,3} seems harder, I need one extra vpermilpd. Actually, it looks like every v4df shuffle can be realized as a vblendpd of a vpermilpd and a vpermilpd+vperm2f128. For v8sf, it also seems true but may require the version of vpermilps that takes its controls from a register/memory.
[Bug target/52607] New: v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 Bug #: 52607 Summary: v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2} Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org Hello, this is really just a follow-up to PR52568. The permutations {0,2,1,3} and {1,3,0,2} can be realized with a very similar technique. Starting from 0123: vpermilpd+vperm2f128->3210 vblendpd(0123,3210)->0213 or: vpermilpd->1032 vperm2f128->2301 vblendpd(1032,2301)->1302 I am not sure if there is a nice way to generalize this or if the function expand_vec_perm_vperm2f128_vblend should be cloned a few times and slightly modified. (these permutations are less important to me than 1230 was)
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #4 from Steven Bosscher 2012-03-17 00:05:48 UTC --- (In reply to comment #3) > Jakub, please do not forget about this one for stage1 GCC 4.7. Jakub, please do not forget about this one for stage1 GCC 4.8.
[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Steven Bosscher 2012-03-17 00:04:49 UTC --- Issues mentioned here are solved (at least, sufficiently so for me).
[Bug other/52438] [4.7 Regression] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 Steven Bosscher changed: What|Removed |Added Summary|Some files still GPLv2 |[4.7 Regression] Some files ||still GPLv2 --- Comment #1 from Steven Bosscher 2012-03-17 00:02:43 UTC --- Regression -- well for some definition of regression anyway, namely releasing code with two different licenses -- to bring on radar for RMs.
[Bug middle-end/41004] missed merge of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004 --- Comment #8 from Steven Bosscher 2012-03-16 23:59:41 UTC --- Ehm, why does tree tail-merge not run at -Os? It's a size optimization, after all!
[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|NEW CC||ramana at gcc dot gnu.org --- Comment #26 from Steven Bosscher 2012-03-16 23:53:14 UTC --- (In reply to comment #25) > (In reply to comment #24) > > Unfortunately, there is still no word from the FSF on what they did with our > > Copyright Assignment. > > As already mentioned in PR 38785, I've posted the patch here: > http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html > > It is also integrated in the milepost-branch. I am not working on this, but Ramana is working on partial-partial PRE and may be interested in porting over that patch from comment #25.
[Bug middle-end/45579] Re-enable IPA-CP for "fn spec"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579 Steven Bosscher changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org
[Bug c/52283] "error: case label does not reduce to an integer constant" for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #25 from Manuel López-Ibáñez 2012-03-16 23:26:08 UTC --- (In reply to comment #24) > > I think you need to add a Changelog and submit it to gcc-patches. Both 4.6.3 > > and 4.7.0 are about to be released, so you may need to wait until they are > > (or > > not, I am not following closely the current status) > > OK, do you have an entry that comes with your patch (stmt,c and convert.c) ? Feel free to write whatever you like in the ChangeLog. > I'll submit the whole thing to gcc-patches. Thanks!
[Bug c/31893] Please provide an "inout" attribute for function parameters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893 Manuel López-Ibáñez changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Manuel López-Ibáñez 2012-03-16 23:22:35 UTC --- (In reply to comment #5) > There is no support for this in the middle-end anyway. Not even for Fortran. And with GCC 4.7.0, there is, and FORTRAN is using it. See PR43665 and http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00895.html but there is no external interface exposing this functionality in C/C++. That thread includes some suggestions. If you are still interested, you could try to submit a patch implementing some of the suggestions.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #1 from Steven Bosscher 2012-03-16 23:18:26 UTC --- Someting as trivial as the following would perhaps already help (not tested): Index: match.c === --- match.c(revision 185477) +++ match.c(working copy) @@ -546,8 +546,8 @@ gfc_match_name (char *buffer) if (i > gfc_option.max_identifier_length) { - gfc_error ("Name at %C is too long"); - return MATCH_ERROR; + gfc_error_now ("Name at %C is too long"); + goto too_long_or_done; } old_loc = gfc_current_locus; @@ -555,6 +555,7 @@ gfc_match_name (char *buffer) } while (ISALNUM (c) || c == '_' || (gfc_option.flag_dollar_ok && c == '$')); +too_long_or_done: if (c == '$' && !gfc_option.flag_dollar_ok) { gfc_error ("Invalid character '$' at %C. Use -fdollar-ok to allow it " Ideally, we'd just accept long identifiers, but the maximum name length is hard-coded (GFC_MAX_SYMBOL_LEN) and already way too large. I want to change this to string pointers (probably using a string pool, maybe the GCC common implementation, TBD).
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-16 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #15 from Jonathan Wakely 2012-03-16 21:46:05 UTC --- (In reply to comment #14) > (I thought perhaps that the change had been made between > N3290 and the released standard, but apparently that's not the case.) See the text in bold at the top of the issues list: "Issues with DR and WP status are NOT part of the International Standard for C++." > The fact that C90 required the keyword further weakens my previous > argument. > > So the diagnostic is necessary, but I'd still suggest that a warning > would be more appropriate, and would still meet the current standard's > requirements. The current standard is C++11, that change is only in the current *draft* and that's not a standard. > (I should mention that I have no need for this myself; I don't even take > advantage of the permission to use "(void)" rather than "()".) Good, it's an abomination!
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #14 from Keith Thompson 2012-03-16 21:41:18 UTC --- On re-reading DR 577, I agree that it implies the current standard says that only "(void)" is allowed, and in particular that a typedef is not. I might have interpreted it differently myself, but I defer to the committee. (I thought perhaps that the change had been made between N3290 and the released standard, but apparently that's not the case.) The fact that C90 required the keyword further weakens my previous argument. So the diagnostic is necessary, but I'd still suggest that a warning would be more appropriate, and would still meet the current standard's requirements. (I should mention that I have no need for this myself; I don't even take advantage of the permission to use "(void)" rather than "()".)
[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476 --- Comment #5 from François Dumont 2012-03-16 21:03:24 UTC --- Author: fdumont Date: Fri Mar 16 21:03:15 2012 New Revision: 185476 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185476 Log: 2012-03-15 François Dumont PR libstdc++/52476 * include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux): Add. (_Hashtable<>::_M_rehash): Use the latter. * testsuite/23_containers/unordered_multimap/insert/52476.cc: New. * testsuite/23_containers/unordered_multiset/insert/52476.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/52476.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/52476.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #10 from Jakub Jelinek 2012-03-16 20:52:47 UTC --- Ah, sorry, you're right, fixed up gcc-4.7/changes.html.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #9 from Jakub Jelinek 2012-03-16 20:50:14 UTC --- What in the release notes should be updated? The standard says that for 180_degrees the compiler should try to call operator "" _degrees (180ULL) (if operator "" _degrees (unsigned long long) exists), or operator "" _degrees ("180") (if operator "" _degrees (const char *) exists), or operator "" _degrees <'1', '8', '0'> () (if literal operator template exists). So your testcase is invalid.
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 --- Comment #8 from wwieser at gmx dot de 2012-03-16 20:44:54 UTC --- @Georg-Johann Lay: Thank you very much for that quick response. > Obviously, the toolchain you use comes with bad patches. > I agree.
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 Jonathan Wakely changed: What|Removed |Added Keywords|diagnostic |rejects-valid Summary|[DR 577] Bad C++ error on |[DR 577] allow typedefs for |invalid code:|void in empty parameter |has incomplete type |list --- Comment #13 from Jonathan Wakely 2012-03-16 20:37:33 UTC --- (In reply to comment #10) > I agree that the C++ standard's wording is ambiguous, and *could* > be read as requiring the keyword "void", but I believe the intent > is to permit a typedef. (And if you want to argue that the use of > a typedef is silly, I agree completely.) > > I believe that the resolution of DR 577: > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577 > confirms this. No, that issue confirms quite clearly that before that change (which only happened last month and is not part of C++98, C++03 or C++11) the code was definitely invalid: "The C99 formulation allows typedefs for void, while C++ (and C90) accept only the keyword itself in this role." The language was not ambiguous and the intent wasn't clarified by DR 577, the rule was changed so previously invalid code is now valid. Subject and keywords changed to match the new status.
[Bug c++/33101] [DR 577] Bad C++ error on invalid code: has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 Jonathan Wakely changed: What|Removed |Added Summary|Bad C++ error on invalid|[DR 577] Bad C++ error on |code: has |invalid code: |incomplete type |has incomplete type --- Comment #12 from Jonathan Wakely 2012-03-16 20:17:02 UTC --- (In reply to comment #10) > I believe that the resolution of DR 577: > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577 > confirms this. The resolution, as of August, 2011, suggests changing > the wording to refer to the *type* void rather than the keyword. > (That change doesn't appear in the N3270 draft; I don't know whether > it appears in the final ISO C++ 2011 standard.) It doesn't, the DR says [Voted into the WP at the February, 2012 meeting.] i.e. after the 2011 standard. > At the very least, since there is (unfortunately) real-world code that > depends on this, I suggest changing it from a fatal error to a warning, > though I think removing the diagnostic altogether would be better. Since GCC, Clang and EDG all reject it today I'm surprised such real-world code hasn't been changed already.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #8 from Andy Webber 2012-03-16 20:06:52 UTC --- Ah, that fixes it. It could be good to update the release notes to match. Thanks to Ed Smith-Rowland, G++ now implements C++11 user-defined literals. // Not actually a good approximation. :) constexpr long double operator"" _degrees (long double d) { return d * 0.0175; } long double pi = 180_degrees; long double pi = 180.0_degrees;
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #7 from Marc Glisse 2012-03-16 19:39:14 UTC --- (In reply to comment #6) > constexpr long double operator"" _degrees(long double d) > { >return d * 0.0175; > } > > int main() > { >long double pi = 180_degrees; >std::cout << pi << std::endl; > } There is no dot in 180, so it is looking for an unsigned long long overload (which you could provide). 180._degrees works.
[Bug c++/33101] Bad C++ error on invalid code: has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #11 from Keith Thompson 2012-03-16 19:30:17 UTC --- And since the C++ code is valid, the title of this bug should be changed.
[Bug c++/33101] Bad C++ error on invalid code: has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 Keith Thompson changed: What|Removed |Added CC||Keith.S.Thompson at gmail ||dot com --- Comment #10 from Keith Thompson 2012-03-16 19:26:45 UTC --- This came up in a question on stackoverflow.com: http://stackoverflow.com/q/9742135/827263 I believe the code is valid. Here's a simpler test case: typedef void VOID; int main(VOID) { } which g++ 4.5.2 rejects with the following: void_test.cpp:2:10: error: ‘’ has incomplete type void_test.cpp:2:14: error: invalid use of ‘VOID’ Quoting N3290, a draft of the 2011 ISO C++ standard, section 8.3.5 [dcl.fct]: The parameter-declaration-clause determines the arguments that can be specified, and their processing, when the function is called. [ ... ] If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter list. Except for this special case, void shall not be a parameter type (though types derived from void, such as void*, can). Earlier versions of the standard have similar or identical wording. The last sentence implies that "void" here is being used as a type name, not as some special-case syntactic use of the keyword. I believe the phrase "special case" is meant to exclude declarations like void foo(void, int); or void bar(void param); not to prohibit the use of a typedef. Since a typedef creates an *alias* for an existing type, the name "VOID" should be usable as a replacement for "void" whenever it's used as a type name. Note that the syntax for a parameter-declaration does not refer specifically to the "void" keyword; rather, "void" is valid in that context because it's a type name. Practically speaking, the purpose of allowing "void" as a parameter declaration is for compatibility with C. Quoting the latest draft of the C standard, N1570 6.7.6.3p10: The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters. It refers to the *type* void, not the keyword, implying that a typedef is acceptable in this context -- and gcc 4.5.2 accepts the above program without complaint when compiling it as C. I agree that the C++ standard's wording is ambiguous, and *could* be read as requiring the keyword "void", but I believe the intent is to permit a typedef. (And if you want to argue that the use of a typedef is silly, I agree completely.) I believe that the resolution of DR 577: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577 confirms this. The resolution, as of August, 2011, suggests changing the wording to refer to the *type* void rather than the keyword. (That change doesn't appear in the N3270 draft; I don't know whether it appears in the final ISO C++ 2011 standard.) At the very least, since there is (unfortunately) real-world code that depends on this, I suggest changing it from a fatal error to a warning, though I think removing the diagnostic altogether would be better.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 Andy Webber changed: What|Removed |Added CC||andy at aligature dot com --- Comment #6 from Andy Webber 2012-03-16 19:23:18 UTC --- I've been playing around with a gcc 4.7.0 RC2 build and it seems like the user defined literals might not be working at all now. Building: #include #include constexpr long double operator"" _degrees(long double d) { return d * 0.0175; } int main() { long double pi = 180_degrees; std::cout << pi << std::endl; } Result: literal.cpp: In function ‘int main()’: literal.cpp:11:21: error: unable to find numeric literal operator ‘operator"" _degrees’
[Bug fortran/52606] New: Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Bug #: 52606 Summary: Confusing diagnostics for long identifiers Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: anl...@gmx.de Excessively long identifiers can produce quite confusing diagnostics. Perhaps error recovery could be improved. Example: module gfcbug118 implicit none interface foo module procedure very_long_identifier_beyond_31char end interface contains subroutine very_long_identifier_beyond_31char () end subroutine very_long_identifier_beyond_31char end module gfcbug118 % gfc gfcbug118.f90 -std=f95 gfcbug118.f90:4.54: module procedure very_long_identifier_beyond_31char 1 Error: Name at (1) is too long gfcbug118.f90:7.45: subroutine very_long_identifier_beyond_31char () 1 Error: Name at (1) is too long gfcbug118.f90:8.5: end subroutine very_long_identifier_beyond_31char 1 Error: Expecting END MODULE statement at (1) gfcbug118.f90:9.20: end module gfcbug118 1 Error: Fortran 2008: CONTAINS statement without FUNCTION or SUBROUTINE statement at (1) % gfc gfcbug118.f90 -fmax-identifier-length=31 gfcbug118.f90:4.54: module procedure very_long_identifier_beyond_31char 1 Error: Name at (1) is too long gfcbug118.f90:7.45: subroutine very_long_identifier_beyond_31char () 1 Error: Name at (1) is too long gfcbug118.f90:8.5: end subroutine very_long_identifier_beyond_31char 1 Error: Expecting END MODULE statement at (1)
[Bug middle-end/51752] trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Aldy Hernandez 2012-03-16 18:44:53 UTC --- The committed patch on trunk and on the 4.7 branch resolves all the known issues. I can't come up with any more reproducible testcases for publication safety. If we find any, let's open a new PR naming the offending pass.
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2012-03-16 16:54:43 UTC --- Fixed.
[Bug middle-end/52603] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2012-03-16 16:48:58 UTC --- Fixed.
[Bug middle-end/52603] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 --- Comment #1 from Richard Guenther 2012-03-16 16:48:38 UTC --- Author: rguenth Date: Fri Mar 16 16:48:31 2012 New Revision: 185474 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185474 Log: 2012-03-16 Richard Guenther PR tree-optimization/52603 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Clarify comment. Revert 2012-03-14 Richard Guenther PR tree-optimization/52571 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move flag_section_anchors check ... (vect_can_force_dr_alignment_p): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #7 from Richard Guenther 2012-03-16 16:48:38 UTC --- Author: rguenth Date: Fri Mar 16 16:48:31 2012 New Revision: 185474 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185474 Log: 2012-03-16 Richard Guenther PR tree-optimization/52603 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Clarify comment. Revert 2012-03-14 Richard Guenther PR tree-optimization/52571 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move flag_section_anchors check ... (vect_can_force_dr_alignment_p): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug lto/52605] New: LTO -g ICE when looking up context of VMTs of classes defined within functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52605 Bug #: 52605 Summary: LTO -g ICE when looking up context of VMTs of classes defined within functions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Host: x86_64-linux-gnu Target: x86_64-linux-gnu Created attachment 26905 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26905 Testcase When compiling the attached testcase with -flto and -g, I get the following ICE: lto1: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘record_type’ in lookup_decl_die, at dwarf2out.c:5118 This is the same problem I first encountered when LTOing Firefox and which I reported in the mailing list a while ago (http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00551.html) but this testcase is close to minimal. The reason why we do not hit this wrong use of decl_function_context without LTO is that the function dwarf2out_decl is never called on VMTs when not doing LTO.
[Bug c/52602] false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-16 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez 2012-03-16 15:32:04 UTC --- I know it is a pain in the ass to generate a (minimal) preprocessed testcase, but this report is not very useful without it: http://gcc.gnu.org/bugs/ There are at least as many explanations for this as bugs are listed for PR24639.
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #1 from Laurent Aflonsi 2012-03-16 15:25:23 UTC --- I would propose to fix as follows : - Set the _M_Key=NULL when calling the freelist desctuctor. - Testing the NULL Key before using it with setspecific. see patch below : === --- libstdc++-v3/src/mt_allocator.cc(revision 2486) +++ libstdc++-v3/src/mt_allocator.cc(working copy) @@ -47,6 +47,7 @@ if (_M_thread_freelist_array) { __gthread_key_delete(_M_key); + _M_key = NULL; ::operator delete(static_cast(_M_thread_freelist_array)); } } @@ -639,7 +640,8 @@ } } - __gthread_setspecific(freelist._M_key, (void*)_M_id); + if (freelist._M_key) + __gthread_setspecific(freelist._M_key, (void*)_M_id); } return _M_id >= _M_options._M_max_threads ? 0 : _M_id; } === Let me know what you think Thanks very much Laurent Alfonsi
[Bug libstdc++/52604] New: mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 Bug #: 52604 Summary: mt allocator crashes on multi-threaded Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: laurent.alfo...@st.com Created attachment 26904 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26904 Testcase to reproduce There's a problem with mt_allocator when using multi-threads. see example attached (g++ -lpthread). At exit time, - the __freelist destructor is called. which does a __gthread_key_delete(_M_key). - and then afterwards, the std::list<> destructor is called. This finally have for effect to use that thread key with gthread_setspecific. Valgrind reports : = ==5212== Invalid read of size 8 ==5212==at 0x4CA009D: __gnu_cxx::__pool::_M_get_thread_id() (in ../gcc-4.6.3/lib64/libstdc++.so.6.0.16) ==5212==by 0x4CA0173: __gnu_cxx::__pool::_M_reclaim_block(char*, unsigned long) (in ../gcc-4.6.3/lib64/libstdc++.so.6.0.16) ==5212==by 0x401989: __gnu_cxx::__mt_alloc, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate(std::_List_node*, unsigned long) (in /tmp/a.out) ==5212==by 0x401847: std::_List_base > >::_M_put_node(std::_List_node*) (in /tmp/a.out) ==5212==by 0x40168C: std::_List_base > >::_M_clear() (in /tmp/a.out) ==5212==by 0x40151A: std::_List_base > >::~_List_base() (in /tmp/a.out) ==5212==by 0x401BB1: std::list > >::~list() (in /tmp/a.out) ==5212==by 0x3814E30C94: exit (in /lib64/tls/libc-2.3.4.so) ==5212==by 0x3814E1C411: (below main) (in /lib64/tls/libc-2.3.4.so) ==5212== Address 0x5b5ce88 is 24 bytes inside a block of size 65,536 free'd ==5212==at 0x4A077EC: operator delete(void*) (vg_replace_malloc.c:457) ==5212==by 0x3814E30C94: exit (in /lib64/tls/libc-2.3.4.so) ==5212==by 0x3814E1C411: (below main) (in /lib64/tls/libc-2.3.4.so) = I ve seen a quite close bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309), that is already fixed in 4.0.0. This apparently leaded to re-write a part of mt_allocate (Jakub Jelinek). But this was not sufficient for the current bug report i m reporting. Thanks in advance. Laurent Alfonsi
[Bug middle-end/52603] New: Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 Bug #: 52603 Summary: Test failures in gcc.dg/vect: vectorizing unaligned access Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: rguent...@suse.de Target: arm-none-eabi The patch for PR52571 causes the testsuite failures on arm in gcc.dg/vect tests related to vectorizing unaligned access. FAIL: gcc.dg/vect/vect-109.c scan-tree-dump-times vect "Vectorizing an unaligned access" 3 FAIL: gcc.dg/vect/vect-13.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-17.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-18.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-19.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-2-big-array.c scan-tree-dump-times vect "Vectorizing an unaligned acce FAIL: gcc.dg/vect/vect-2.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-20.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-21.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-22.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-27.c scan-tree-dump-times vect "Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-29.c scan-tree-dump-times vect "Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-3.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-4.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-5.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-56.c scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gcc.dg/vect/vect-7.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-72.c scan-tree-dump-times vect "Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-73-big-array.c scan-tree-dump-times vect "Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-73.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-77-global.c scan-tree-dump-times vect "Vectorizing an unaligned access FAIL: gcc.dg/vect/vect-78-global.c scan-tree-dump-times vect "Vectorizing an unaligned access FAIL: gcc.dg/vect/vect-86.c scan-tree-dump-times vect "Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-97-big-array.c scan-tree-dump-times vect "Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-97.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/vect-all-big-array.c scan-tree-dump-times vect "Alignment of access forced FAIL: gcc.dg/vect/vect-all.c scan-tree-dump-times vect "Alignment of access forced using peel FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect "Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Alignment of access forced u FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect "Alignment of access forced using p FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect "Alignment of access forced using peelin XFAIL->XPASS: XPASS: gcc.dg/vect/vect-60.c scan-tree-dump-times vect "Vectorizing an unaligned access" 2 XPASS: gcc.dg/vect/vect-56.c scan-tree-dump-times vect "Vectorizing an unaligned access" 2 XPASS: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Alignment of access forced Trunk r185380 http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00972.html Configured with --target=arm-eabi --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #2 from Richard Guenther 2012-03-16 14:49:11 UTC --- Author: rguenth Date: Fri Mar 16 14:49:05 2012 New Revision: 185468 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185468 Log: 2012-03-16 Richard Guenther PR middle-end/52584 * fold-const.c (fold_ternary_loc): Fold vector typed BIT_FIELD_REFs of vector constants and constructors. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug target/52593] Builtin sqrt on x86 is not correctly rounded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 --- Comment #6 from Rich Felker 2012-03-16 14:23:09 UTC --- The 387 FPU ensures correct rounding for the currently selected precision mode, which per the ABI is always extended precision. As for the usefulness of fixing this, I found the bug while working on my correct sqrt implementation in musl libc, because despite the existence of a correct version of the function, I was still getting wrong results. It turned out gcc was replacing it with a buggy builtin. I don't think "glibc gets it wrong anyway" is a reason not to fix the problem, especially now that glibc seems to be under new maintainership and actually fixing longstanding WONTFIX bugs. Folks who just care about speed and want to throw correctness away should already be using -ffast-math and similar. Actually since this bug is rounding-related, perhaps it would suffice to make -frounding-math turn off the builtin sqrt when using 387 math...?
[Bug c/52602] false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 --- Comment #1 from asmwarrior 2012-03-16 14:06:08 UTC --- BTW: here is the discussion in gdb's patch mail list. http://sourceware.org/ml/gdb-patches/2012-03/msg00585.html
[Bug c/52602] New: false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 Bug #: 52602 Summary: false compilation warning of uninitialized variable Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: asmwarr...@gmail.com Hi, when building gdb, I found a false warning, the code is below: static void print_one_vtable (struct gdbarch *gdbarch, struct value *value, int max_voffset, struct value_print_options *opts) { int i; struct type *type = check_typedef (value_type (value)); struct value *vtable; CORE_ADDR vt_addr; vtable = gnuv3_get_vtable (gdbarch, type, value_address (value) + value_embedded_offset (value)); vt_addr = value_address (value_field (vtable, vtable_field_virtual_functions)); printf_filtered (_("vtable for '%s' @ %s (subobject @ %s):\n"), TYPE_SAFE_NAME (type), paddress (gdbarch, vt_addr), paddress (gdbarch, (value_address (value) + value_embedded_offset (value; for (i = 0; i <= max_voffset; ++i) { struct value *vfn; CORE_ADDR addr; volatile struct gdb_exception ex; printf_filtered ("[%d]: ", i); vfn = value_subscript (value_field (vtable, vtable_field_virtual_functions), i); if (gdbarch_vtable_function_descriptors (gdbarch)) vfn = value_addr (vfn); TRY_CATCH (ex, RETURN_MASK_ERROR) { addr = value_as_address (vfn); } if (ex.reason < 0) printf_filtered (_(""), ex.message); else print_function_pointer_address (gdbarch, addr, gdb_stdout, opts->addressprint); printf_filtered ("\n"); } } in GDB's source: gnu-v3-abi.c, the warning is: .../../gdb/gdb/gnu-v3-abi.c: In function 'print_one_vtable.isra.2': .../../gdb/gdb/gnu-v3-abi.c:892:33: error: 'addr' may be used uninitialized in this function [-Werror=uninitialized] and the bug is workaround by this patch: http://sourceware.org/ml/gdb-cvs/2012-03/msg00203.html Simply use: CORE_ADDR addr = 0; Yuanhui Zhang
[Bug bootstrap/52601] Gcc build fails at "Making all in tools" with "find: bad option -path" and "find: path-list predicate-list"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-16 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-03-16 13:38:21 UTC --- GCC 4.4.x are no longer supported. I suggest you try GCC 4.6.x and follow the install instructions for Solaris 2 closely.
[Bug middle-end/34212] spurious warning: value computed is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212 --- Comment #14 from Jonathan Liu 2012-03-16 13:38:18 UTC --- Created attachment 26903 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26903 Test case This test case gives a spurious 'warning: value computed is not used [-Wunused-value]' message when compiled with -Wall.
[Bug bootstrap/52601] New: Gcc build fails at "Making all in tools" with "find: bad option -path" and "find: path-list predicate-list"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 Bug #: 52601 Summary: Gcc build fails at "Making all in tools" with "find: bad option -path" and "find: path-list predicate-list" Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com Machine Details: 1) uname -a SunOS slimsol9t4 5.9 Generic_122300-30 sun4u sparc SUNW,Sun-Fire-V240 2) isainfo -kv 64-bit sparcv9 kernel modules 3) ./config.guess sparc-sun-solaris2.9 Downloaded gcc-4.4.4.tar.gz, gmp-4.1.tar and mpfr-2.4.0.tar. configured, make and make install the gmp and mpfr successfully but received error while executing the make command for gcc-4.4.4 echo $LD_LIBRARY_PATH /usr/bin:/usr/local/lib:/usr/ccs/lib:/els/install/gcc-3.4.5/lib:/els/install/jdk1.6.0_16/jre/lib/sparc/:/els/install/jdk1.6.0_16/jre/lib/sparc/client:/els/install/staf/lib:/els/install/staf/lib/JSTAF.zip:/els/install/staf/lib/JSTAF.jar:/els/install/staf/services/STAFHTTP.jar:/els/install/staf/lib/java12:/usr/openwin/lib echo $PATH /els/install/jdk1.6.0_16/bin/:/els/install/gcc-3.4.5/bin:/els/install/staf/bin:/els/install/staf/services/STAFHTTP.jar:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/dt/bin:/usr/platform/SUNW,Sun-Fire-V240/sbin:/opt/sun/bin:/opt/VRTS/bin:/etc/vx/bin:/opt/SUNWexplo/bin:/opt/SUNWsneep/bin Configured gcc with following command: ../../biru/gcc444/gcc-4.4.4/configure --prefix=/els/install/biru/local/gcc --build=sparc-sun-solaris2.9 --with-gmp=/els/install/biru/local/gmp --with-mpfr=/els/install/biru/local/mpfr and then executed: make Below are the error message received: make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/scripts' Making all in tools make[6]: Entering directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/tools' Makefile:841: warning: overriding commands for target `gjdoc' Makefile:776: warning: ignoring old commands for target `gjdoc' find ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/external/asm -name '*.java' -print > asm.lst find ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/gnu/classpath/tools \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/javadoc \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/doclets \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javadoc \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javac \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javah \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/sun/rmi/rmic \ -path '*gnu/classpath/tools/gjdoc' pattern -prune -o -path '*gnu/classpath/tools/doclets' pattern -prune -o GtternJDOC_EX = -path '*gnu/classpath/tools/gjdoc' pattern -prune -o -path '*gnu/classpath/tools/taglets' pattern -prune -o -path '*com/sun/javadoc' pattern -prune -o -path '*com/sun/tools/doclets' pattern -prune -o -path '*com/sun/tools/javadoc' pattern -prune -o \ -name '*.java' -print > classes.lst find: bad option -path find: path-list predicate-list make[6]: *** [tools.zip] Error 1 make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/tools' make[6]: Entering directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' true DO=all multi-do # make make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/els/install/gccbuild/gcc4' make: *** [all] Error 2 Thanks, -Biru
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-16 Ever Confirmed|0 |1
[Bug middle-end/48814] [4.5/4.6/4.7 Regression] Incorrect scalar increment result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|4.5.4 |4.8.0 Summary|[4.5/4.6/4.7/4.8|[4.5/4.6/4.7 Regression] |Regression] Incorrect |Incorrect scalar increment |scalar increment result |result Known to fail||4.7.1 --- Comment #13 from Richard Guenther 2012-03-16 11:49:39 UTC --- Fixed. Deliberately not backporting.
[Bug middle-end/48814] [4.5/4.6/4.7/4.8 Regression] Incorrect scalar increment result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814 --- Comment #12 from Richard Guenther 2012-03-16 11:48:54 UTC --- Author: rguenth Date: Fri Mar 16 11:48:48 2012 New Revision: 185465 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185465 Log: 2012-03-16 Richard Guenther Kai Tietz PR middle-end/48814 * gimplify.c (gimplify_self_mod_expr): Evaluate postfix side-effects completely in the pre-queue and use a temporary for the result. * gcc.c-torture/execute/pr48814-1.c: New test. * gcc.c-torture/execute/pr48814-2.c: New test. * gcc.dg/tree-ssa/assign-1.c: New test. * gcc.dg/tree-ssa/assign-2.c: New test. * gcc.dg/tree-ssa/assign-3.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #4 from Jos de Kloe 2012-03-16 11:36:48 UTC --- > I am lost. The way around that I mentioned was for gcc 4.7+ (so I cannot test this right away, but will upgrade as soon as it is feasible for me). Anyway, thanks for your thoughts.
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #3 from Tobias Burnus 2012-03-16 11:13:17 UTC --- (In reply to comment #2) > Thanks for your answer. > Using stop 0 or stop 1 would indeed be a way around I am lost. With GCC 4.6 and an explicit -fbacktrace, I *do* get a backtrace for any nonzero integer/exit status in STOP/ERROR STOP. (And none for zero.) In GCC 4.7 and 4.8 (which have -fbacktrace already implicitly), I *do* *not* get a backtrace for STOP/ERROR STOP, independent whether the integer is nonzero or not. > Anyway, this bug is just a feature request, so it is up to you developers to > decide if you want to implement this or not. I still believe that GCC 4.7 and 4.8 handle it - by default - as you would like. (Cf. http://gcc.gnu.org/wiki/GFortranBinaries ; if you are under Linux, your distribution will likely have some 4.7 packages available - either in some special branch or in their development version, cf. also http://gcc.gnu.org/wiki/GFortranDistros)
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #10 from Uros Bizjak 2012-03-16 11:05:33 UTC --- (In reply to comment #8) > I'm now running into > > --- FAIL: net.TestMulticastListener (0.00 seconds) > sockoptip.go:118: "224.0.0.254:12345" not found in RIB > > still looking what's going on here. And the Please see [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00639.html
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 11:03:28 UTC --- > I'm now running into > > --- FAIL: net.TestMulticastListener (0.00 seconds) > sockoptip.go:118: "224.0.0.254:12345" not found in RIB > > still looking what's going on here. And the No wonder this doesn't work: the code ultimately calls interfaceMulticastAddrTable, but Solaris uses interface_stub.go, and none of the other implementations are remotely usable. I concoct something using the SIOCGLIFNUM and SIOCGLIFCONF ioctls. Rainer
[Bug c/52600] New: OpenMP: declaration as structured block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52600 Bug #: 52600 Summary: OpenMP: declaration as structured block Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: openmp, rejects-valid Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Found at http://openmp.org/forum/viewtopic.php?f=10&t=1329&sid=58cf62c9cbfc7fee81768f053e079615 ... and there believed to be valid. GCC rejects the following: #pragma omp task int x = foo(); with error: expected expression before ‘int’ While the following, syntactically identical (?), is accepted: #pragma omp task { int x = foo(); }
[Bug target/52593] Builtin sqrt on x86 is not correctly rounded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Target||i?86-*-* Status|WAITING |NEW Version|unknown |4.6.4 --- Comment #5 from Richard Guenther 2012-03-16 10:53:12 UTC --- Confirmed. I think sqrt is special (compared to sin, cos, etc.) because it's one of the core IEEE arithmetic functions. I suppose correct rounding is only ensured for 80bit long double. It will of course be an unexpected performance drop for most people with no additional benefit as the libm implementation is wrong as well :/
[Bug c++/52599] ICE on illegal constexpr constructor declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Paolo Carlini changed: What|Removed |Added CC|mickael.guene at st dot com |jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-03-16 10:39:42 UTC --- Actually, the gcc_assert triggering is that in build_data_member_initialization: t is a TRY_BLOCK (of course) at that point. Not sure at the moment if we should diagnose the issue here or earlier. Maybe Jason has tips..
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #15 from Pawel Sikora 2012-03-16 10:27:53 UTC --- (In reply to comment #14) > > Now, if something got broken lately, like those sed, I have no idea, certainly > I didn't change that. But, please post and discuss the issue and tentative > fixes on the libstdc++ mailing list, not here. ok, sent: http://gcc.gnu.org/ml/libstdc++/2012-03/msg00103.html
[Bug c++/52599] ICE on illegal constexpr constructor declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-16 Summary|illegal constexpr |ICE on illegal constexpr |constructor declaration |constructor declaration |make g++ assert instead of | |returning an error | Ever Confirmed|0 |1
[Bug c++/52599] New: illegal constexpr constructor declaration make g++ assert instead of returning an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Bug #: 52599 Summary: illegal constexpr constructor declaration make g++ assert instead of returning an error Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mickael.gu...@st.com Created attachment 26902 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26902 This test make g++ to assert when compiling attach file with 'g++ -std=c++0x test.cpp' compiler assert in build_constexpr_constructor_member_initializers function from cp/semantics.c. g++ should instead return an error since construct is illegal.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 Paolo Carlini changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #14 from Paolo Carlini 2012-03-16 10:00:38 UTC --- To be clear: the way the thing is supposed to work, **only** basic_string should be special, because **only** the extern template for basic_string are guarded by "#if _GLIBCXX_EXTERN_TEMPLATE > 0" instead of "#if _GLIBCXX_EXTERN_TEMPLATE". If something special is happening elsewhere then it's an unintended bug. Now, if something got broken lately, like those sed, I have no idea, certainly I didn't change that. But, please post and discuss the issue and tentative fixes on the libstdc++ mailing list, not here. Benjamin, any idea about those sed?
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 09:55:26 UTC --- I've found that this failure on Solaris --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:67: First ListenMulticastUDP failed: setsockopt: Invalid argument is caused by Solaris using sockoptip_linux.go, which passes an int to setsockopt for IP_MULTICAST_LOOP, where Solaris expects and unsigned char. I'm fixing this by using a new sockoptip_solaris.go which does this right. I'm now running into --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:118: "224.0.0.254:12345" not found in RIB still looking what's going on here. And the pollServer WaitFD: select: Bad file number errors here and in net/http and net/http/httputil remain. Rainer
[Bug c++/52597] [C++11] missing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597 --- Comment #1 from Jonathan Wakely 2012-03-16 08:59:29 UTC --- With 4.7.0 you get t.cc:4:16: error: decltype cannot resolve address of overloaded function t.cc: In member function ‘void A::bar1()’: t.cc:6:49: error: decltype cannot resolve address of overloaded function t.cc:6:52: error: invalid type in declaration before ‘;’ token t.cc: In member function ‘void A::bar2()’: t.cc:9:43: error: decltype cannot resolve address of overloaded function t.cc:9:46: error: invalid type in declaration before ‘;’ token t.cc: At global scope: t.cc:14:25: error: decltype cannot resolve address of overloaded function t.cc:14:28: error: invalid type in declaration before ‘;’ token
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|[4.7 Regression] [C++11]|[4.7/4.8 Regression] |internal compiler error: in |[C++11] internal compiler |lvalue_kind, at |error: in lvalue_kind, at |cp/tree.c:153 |cp/tree.c:153 --- Comment #2 from Jakub Jelinek 2012-03-16 08:46:23 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174499
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #7 from Uros Bizjak 2012-03-16 08:44:50 UTC --- (In reply to comment #6) > Thanks for looking at this. > > The first step is to run readelf --debug=line FILE to make sure that the line > number information is recorded correctly. Which of course it probably is. If > you have trouble parsing the --debug=line output, try --debug=decodedline. > > The place that Go is reading that information is > libgo/go/debug/dwarf/line.go. > Most likely something is going wrong in the way that it gathers the > information, but I don't know what. Something happens at line 48 (is_stmt is briefly toggled and Discriminator is set): Special opcode 9: advance Address by 0 to 0x120004dd8 and Line by 4 to 47 Special opcode 76: advance Address by 20 to 0x120004dec and Line by 1 to 48 Special opcode 18: advance Address by 4 to 0x120004df0 and Line by -1 to 47 Special opcode 20: advance Address by 4 to 0x120004df4 and Line by 1 to 48 Extended opcode 4: set Discriminator to 2 Set is_stmt to 0 Special opcode 33: advance Address by 8 to 0x120004dfc and Line by 0 to 48 Extended opcode 4: set Discriminator to 2 Set is_stmt to 1 Special opcode 118: advance Address by 32 to 0x120004e1c and Line by 1 to 49 Extended opcode 4: set Discriminator to 2 Special opcode 18: advance Address by 4 to 0x120004e20 and Line by -1 to 48 Extended opcode 4: set Discriminator to 2 Special opcode 20: advance Address by 4 to 0x120004e24 and Line by 1 to 49 Extended opcode 4: set Discriminator to 2 Special opcode 116: advance Address by 32 to 0x120004e44 and Line by -1 to 48 Also --debug=decodedline says: log_test.go 47 0x120004dd8 log_test.go 48 0x120004dec log_test.go 47 0x120004df0 log_test.go 48 0x120004df4 UNKNOWN: length 2 log_test.go 48 0x120004dfc UNKNOWN: length 2 log_test.go 49 0x120004e1c It is probably this UNKNOWN that disturbs decoding.
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #2 from Jos de Kloe 2012-03-16 08:28:11 UTC --- Thanks for your answer. Using stop 0 or stop 1 would indeed be a way around, but the awkward thing is that I do have some requirements to produce different values for the exit status for different error conditions. So using stop 1 everywhere is no solution for me. Anyway, this bug is just a feature request, so it is up to you developers to decide if you want to implement this or not.
[Bug target/52568] suboptimal __builtin_shuffle on cycles with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52568 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-03-16 07:40:13 UTC --- Should be fixed on the trunk. For -mavx2 we now generate vpermpd, for -mavx vpermilpd + vperm2f128 + vblendpd.