[Bug target/54854] New: [avr] Deprecate and finally remove the -mshort-calls command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54854 Bug #: 54854 Summary: [avr] Deprecate and finally remove the -mshort-calls command line option Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr -mshort-calls uses RJMP/RCALL regardless of the flash size of the target device. This will lead to a linker error if a JMP/CALL target is out of reach of RJMP/RCALL: file.c:(.text+0x1234): relocation truncated to fit: R_AVR_13_PCREL against symbol `function' defined in in module.o The -mshort-calls option dates back to the times before the linker could relax JMP/CALL to RJMP/RCALL if the jump offset allows this. The above error message is a blocker and hard to understand for users. Instead of -mstort-calls, the compiler can be called with -mrelax or -Wl,--relax to direct the linker to use the shortest possible instruction.
[Bug target/54854] [avr] Deprecate and finally remove the -mshort-calls command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54854 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-08 Version|4.8.0 |4.7.2 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug fortran/54851] Compiling gfortran.dg/class_array_7.f03 with '-O1 -flto' gives an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54851 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2012-10-08 07:12:33 UTC --- The following variant even ICEs with -O0 -flto: module realloc implicit none type :: base_type end type contains character(20) function print_type (a) class(base_type), dimension(:), intent(in) :: a print_type = is base_type end function end module realloc program main use realloc implicit none type(base_type), dimension(:), allocatable :: a allocate (base_type :: a(2)) print *,print_type (a) end program main c0.f90: In function ‘MAIN__’: c0.f90:13:0: error: non-trivial conversion at assignment program main ^ struct array1_base_type struct array1_base_type class.2._data = a; c0.f90:13:0: internal compiler error: verify_gimple failed 0x96a00e verify_gimple_in_cfg(function*) /home/jweil/gcc48/trunk/gcc/tree-cfg.c:4727 0x85acfb execute_function_todo /home/jweil/gcc48/trunk/gcc/passes.c:1839 0x85a7cf do_per_function /home/jweil/gcc48/trunk/gcc/passes.c:1688 0x85ae1f execute_todo /home/jweil/gcc48/trunk/gcc/passes.c:1872 0x85b247 execute_one_ipa_transform_pass /home/jweil/gcc48/trunk/gcc/passes.c:2046 0x85b2e9 execute_all_ipa_transforms() /home/jweil/gcc48/trunk/gcc/passes.c:2074 0x5b7d06 expand_function /home/jweil/gcc48/trunk/gcc/cgraphunit.c:1594 0x5b853d output_in_order /home/jweil/gcc48/trunk/gcc/cgraphunit.c:1794 0x5b8c5d compile() /home/jweil/gcc48/trunk/gcc/cgraphunit.c:1998 0x51e0b7 lto_main() /home/jweil/gcc48/trunk/gcc/lto/lto.c:3340
[Bug fortran/54851] Compiling gfortran.dg/class_array_7.f03 with '-O1 -flto' gives an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54851 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-08 08:13:52 UTC --- The following variant even ICEs with -O0 -flto: ... This kind of ICEs disappear when gfortran is configured with --enable-checking=release, while the one reported in comment #0 does not.
[Bug c++/54853] (gcc4.7.2) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 08:26:47 UTC --- The ICE is gone with the http://gcc.gnu.org/viewcvs?root=gccview=revrev=189298 fix (PR50852), but there are lots of errors, so it is very likely ice-on-invalid-code.
[Bug other/54815] [avr] missed optimization with operations with constant operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54815 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-08 08:32:56 UTC --- Author: gjl Date: Mon Oct 8 08:32:46 2012 New Revision: 192198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192198 Log: PR target/54815 * config/avr/avr.md (*addmode3, addmode3, addpsi3): Make constraint alternative r,0,r slighly more expensive. (submode3, (andqi3, andhi3, andpsi3, andsi3): Ditto. (iorqi3, iorhi3, iorpsi3, iorsi3): Ditto. (xorhi3, xorpsi3, xorsi3): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 08:44:50 UTC --- That doesn't make much sense, as it wouldn't be tracked anyway, too much code would need to be changed to also track PARALLELs. I'd say the easiest fix would be just turn that gcc_assert into if (!assert_cond) return; and adjust the comment not to say that we assert something. Alex, what do you think?
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #9 from Sergey Ostanevich sergos.gnu at gmail dot com 2012-10-08 08:55:25 UTC --- Thanks for the reduced test, Dominique! I see that vectorized did not manage to generate MIN after the change. Also, it is looks pretty similar to what I posted at first: there was no prephitmp created for the xxtrt_[] ival2_15 = _85 prephitmp_266 ? ival2_10 : iva prephitmp_237 = MIN_EXPR _85, prephitmp_266; --- _86 = (integer(kind=8)) ival2_14; _87 = _86 + -1; _88 = *xxtrt_46(D)[_87]; ival2_15 = _85 _88 ? ival2_10 : ival2_14; I suspect that one of the iterator you removed - possibly VEC_iterate - made more traverse than that you created? I also double check that for the reduced test MIN did not generated and not appears in assembly. PMU measurements (Vtune) confirms that BBLOCKs missing min contributes the difference in clocks.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-08 09:25:53 UTC --- Note that somebody has still to post an updated patch to the library mailing list.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2012-10-08 09:29:13 UTC --- Author: dodji Date: Mon Oct 8 09:29:05 2012 New Revision: 192199 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192199 Log: PR c++/53528 C++11 attribute support This patch implements the c++-11 generalized attributes, described in the N2761 paper[1]. The idea is to modify the front-end to accept the new attribute syntax (including alignas expressions) and to build an internal representation similar to the one we already have for GNU attributes. This lets us re-use our existing GNU attribute mechanisms to support the generalized c++11 attributes. The patch does change the existing internal representation to support scoped attribute (aka attributes with namespaces), which is a concept that doesn't exist in GNU attributes. I have thus put all existing GNU extension attributes into the gnu namespace. For instance, in C++-11, the unused attribute would be represented as [[gnu::unused]]. Because there is no syntax for scoped attributes in C, writting __attribute__((unused)) unconditionnally refers to the unused attribute in the gnu namespace. Note that this patch follows a conservative understanding of the specification by disallowing attributes appertaining to types, unless they apply to a type definition. Tested on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf gcc/ * plugin.h (register_scoped_attributes): Declare new function. * tree.h (enu attribute_flags::ATTR_FLAG_CXX_11): New flag. (lookup_scoped_attribute_spec, cxx_11_attribute_p) (get_attribute_name, get_attribute_namespace): Declare new functions. (struct attribute_spec): Remove const qualifier from the members. * tree.c (comp_type_attributes, private_lookup_attribute) (lookup_ident_attribute, remove_attribute, merge_attribute) (attribute_hash_list, attribute_list_contained): Use get_attribute_name. * attribs.c (decl_attributes): Don't crash on error_mark_node. Forbid c++11 attributes appertaining to type-specifiers. (attribute_hash): Remove global variable. (attributes_table): New global variable. (find_attribute_namespace, register_scoped_attribute): New static functions. (register_scoped_attributes, lookup_scoped_attribute_spec) (cxx11_attribute_p, get_attribute_name, get_attribute_namespace): New public functions. (init_attributes): Register all the GNU attributes into the gnu namespace. (register_attribute): Use register_scoped_attribute to register the attribute into the gnu namespace. (lookup_attribute_spec): Use lookup_scoped_attribute_spec to lookup the attribute in the gnu namespace. (decl_attributes): Use new get_attribute_namespace and lookup_scoped_attribute_spec to consider attribute namespaces when looking up attributes. When operating in c++-11 mode, pass flag ATTR_FLAG_CXX11 to the spec handler. gcc/c-family/ * c-common.h (bitfield_p, cxx_fundamental_alignment_p): Declare new functions. * c-common.c (check_cxx_fundamental_alignment_constraints): New static function. (handle_aligned_attribute): In choose strictest alignment among many. Use new check_cxx_fundamental_alignment_constraints. (handle_transparent_union_attribute): In c++11 attribute syntax, don't look through typedefs. gcc/cp/ * cp-tree.h (enum cpp0x_warn_str::CPP0X_ATTRIBUTES): New member. (enum cp_decl_spec::ds_std_attribute): New enumerator. (struct cp_decl_specifier_seq::std_attributes): New field. (cxx_alignas_expr, warn_misplaced_attr_for_class_type): Declare new functions. (check_tag_decl): Take an extra parameter for explicit instantiations. * decl.c (warn_misplaced_attr_for_class_type): Extract from ... (check_tag_decl): ... here. Add check for c++11 attributes being applied to an explicit instantiation. Take an extra parameter for explicit instantiations. (grokdeclarator): Make sure a c++11 attribute after an array declarator appertains to the array, an attribute after a function declarator appertains to the function type, an attribute after a declarator-id appertains to the entity being declared, and an attribute after a pointer declarator appertains to the pointer. * decl2.c (is_late_template_attribute): Use get_attribute_name. * error.c (maybe_warn_cpp0x): Support CPP0X_GENERALIZED_ATTRIBUTES. * parser.c (cp_next_tokens_can_be_attribute_p) (cp_next_tokens_can_be_gnu_attribute_p) (cp_next_tokens_can_be_std_attribute_p) (cp_nth_tokens_can_be_attribute_p) (cp_nth_tokens_can_be_gnu_attribute_p) (cp_nth_tokens_can_be_std_attribute_p) (cp_parser_gnu_attribute_list,
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #9 from Simon Baldwin simonb at google dot com 2012-10-08 09:32:55 UTC --- (In reply to comment #1) Also reported here: http://gcc.gnu.org/ml/gcc/2012-10/msg00075.html To add a little more detail, here is one diff seen between two .mod files: $ diff omp_lib.mod.first omp_lib.mod 2c2 MD5:39fa3d71e0f92c936ff97e590e8d74cf -- If you edit this, you'll get what you deserve. --- MD5:893e632666abe58013fd14806b18696f -- If you edit this, you'll get what you deserve. 174,175d173 20 'lock' '' '' 19 ((VARIABLE INOUT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 DUMMY) (INTEGER 4 0 0 0 INTEGER ()) 0 0 () () 0 () () () 0 0) 177a176,177 20 'lock' '' '' 19 ((VARIABLE INOUT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 DUMMY) (INTEGER 4 0 0 0 INTEGER ()) 0 0 () () 0 () () () 0 0) This is an ordering difference in the output of write_symbol1, which traverses a pointer tree whose compare function compares pointers with greaterthan and lessthan. The tree is augmented during traversal, so there are repeated calls to write_symbol1 along with a 'written' marker at each node. Ordering by integer 'tag' assigned to each pointer may be problematic because new tags are assigned during traversals, meaning that the sequence in which tags arrive is itself partially a function of the pointer ordering. I'm wondering if a very naive hack like sorting .mod content (like in cat old.mod 1 | sort -s new.mod) could not paper over this problem sufficiently well to make it irrelevant in reality. Perhaps, but it would have to be less naive than this in practice. A .mod file is structured into sections that a simple sort could fragment. It also contains an MD5 checksum of its contents, but I'm not sure how important this is. If it's not critical, removing it might be an acceptable price to pay for simpler code elsewhere.
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 09:50:52 UTC --- (In reply to comment #11) I seem to be having this problem in GCC 4.5.4 , 4.6.3 and 4.7.2 :( Ys, as already stated in the comments above, this is only fixed on the trunk. There is already MPFR 3.1.1 version out, why GCC is not using it by default? GCC doesn't use any version of MPFR by default, it uses whichever version you supply. There is no advantage to GCC from using 3.1.x, so if it's a problem then just use an older version.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 10:06:11 UTC --- (In reply to comment #2) I think Jack is confused regarding --enable-libstdcxx-timer. From emailing me, he seems to be under the impression that '--enable-libstdcxx-timer' is equivalent to '--enable-libstdcxx-timer=no' ... if that is the case, then something is certainly wrong since --enable-libstdcxx-timer should be equivalent to '--enable-libstdcxx-timer=yes' ... It is equivalent. (N.B. time not timer) As for darwin ... we have sched_yield and nanosleep. We don't have clock_gettime. Why are you testing for posix timer support in your checks for sched_yield and nanosleep? See http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html for previous suggestions for having more fine-grained checks than the current one for --enable-libstdcxx-time (In reply to comment #13) Patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00696.html. Jack, I've asked you before, please send libstdc++ patches to the libstdc++ list. This patch is not acceptable, it doesn't fix anything, so consider it rejected. (In reply to comment #16) (In reply to comment #15) Note that the autoconf test is built by the C++ compiler, thus there is no real difference between timespec and struct timespec. Except that one is POSIX and one is not. Additionally, you shouldn't assume that g++ is being used. Hopefully, libstdc++ would be portable enough that one wouldn't need to bootstrap g++ to build it. But you do need a C++ compiler. All patches to that code are rejected unless they get sent to the right list, I'm not even going to review them otherwise, I'll just reject them. Testing changes to those configure checks on a single platform proves nothing about whether the change is correct.
[Bug target/54685] [SH] Improve unsigned int comparison with 0x7FFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54685 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-08 10:09:34 UTC --- Author: olegendo Date: Mon Oct 8 10:09:28 2012 New Revision: 192200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192200 Log: PR target/54685 * config/sh/sh.md (one_cmplsi2): Make insn_and_split. Add manual combine matching for an insn sequence where a ge:SI pattern can be used. PR target/54685 * gcc.target/sh/pr54685.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54685.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug target/54854] [avr] Deprecate and finally remove the -mshort-calls command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54854 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-08 10:14:01 UTC --- Author: gjl Date: Mon Oct 8 10:13:56 2012 New Revision: 192201 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192201 Log: PR target/54854 * doc/invoke.texi (AVR Options): Remove -mshort-calls. * config/avr/avr.opt (-mshort-calls): Remove option. * config/avr/avr.h (AVR_HAVE_JMP_CALL): Don't depend on TARGET_SHORT_CALLS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.opt trunk/gcc/doc/invoke.texi
[Bug target/54854] [avr] Deprecate and finally remove the -mshort-calls command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54854 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-10-08 10:27:26 UTC --- Author: gjl Date: Mon Oct 8 10:27:15 2012 New Revision: 192202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192202 Log: PR target/54854 * doc/invoke.texi (AVR Options): Deprecate -mshort-calls. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/doc/invoke.texi
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-08 10:35:46 UTC --- Created attachment 28384 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28384 Untested fix Per #c5.
[Bug middle-end/54848] -ftrapv doesn't work when assigning to an integer with smaller size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 10:43:53 UTC --- Confirmed. One of the many known issues with -ftrapv.
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/54837] [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54837 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug c++/54853] (gcc4.7.2) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54853
--- Comment #2 from Leonid Volnitsky leonid at volnitsky dot com 2012-10-08
10:54:17 UTC ---
but there are lots of errors
Below 1-line change commit which caused ICE
(http://github.com/lvv/scc/commit/33d60adcf9ea5307ccaf186f558c338424299a56):
//
diff --git c/chain_range.h w/chain_range.h
index 0d3c140..45f6f5e 100644
--- c/chain_range.h
+++ w/chain_range.h
@@ -242,7 +242,7 @@ struct chain_range : ref_containerRg {
templateclass U=Rg eIFhas_pop_backU() pop_back() {rg.pop_back();}
templateclass U=Rg eIFhas_pop_frontU() pop_front() {rg.pop_front();}
- auto operator[] (difference_type n) - decltype(rg[n]) { return rg[n]; }
+ templateclass R=decltype(rg[0]) R operator[] (difference_type n) {
return rg[n];}
// ADDED RG METHODS
templateclass U=Rg
//
I can not see were code is invalid. Maybe you can. I am not sure on what
branch the commit you mentioned is, but it is true, this code can not compiled
with gcc-4.8. Because of regression bug 54648 (caused by commit 191412), gcc
can not handle constexpr in this code. I am removing all constexpr code as
result (and clang is even worse in this regard).
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #25 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 10:59:46 UTC --- N.B. prior to POSIX 2008 nanosleep was part of the Timers option, if OS X supports that it should define _POSIX_TIMERS to 0, -1 or 200112L to indicate it's supported. POSIX 2008 moves the Timers functionality to the Base spec, and requires that _POSIX_TIMERS is defined to 200809L. In eiher case, a POSIX system supporting nanosleep should define _POSIX_TIMERS. The configure checks are based on well-documented, publicly-available standards, please try to understand them instead of proposing patches based on the misunderstanding that adding struct makes any difference to anything.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #26 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 11:17:26 UTC --- (In reply to comment #24) Except that one is POSIX and one is not. Additionally, you shouldn't assume that g++ is being used. Hopefully, libstdc++ would be portable enough that one wouldn't need to bootstrap g++ to build it. But you do need a C++ compiler. In fact, to *build* libstdc++ you definitely need G++. An installed libstdc++ *might* be usable with other compilers such as ICC and Clang that offer a sufficient level of GCC compatibility, but to install it in the first place you need to use GCC. If Apple or anyone else wants it to work otherwise they need to do the work, as GCC maintainers have no reason to do support building parts of GCC without GCC!
[Bug tree-optimization/54825] ICE with vector extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54825 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 11:58:08 UTC --- Author: rguenth Date: Mon Oct 8 11:58:03 2012 New Revision: 192205 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192205 Log: 2012-10-08 Richard Guenther rguent...@suse.de PR tree-optimization/54825 * tree-ssa-sccvn.c (vn_nary_length_from_stmt): Handle BIT_FIELD_REF. (init_vn_nary_op_from_stmt): Likewise. * tree-ssa-pre.c (compute_avail): Use vn_nary_op_lookup_stmt. * tree-ssa-sccvn.h (sizeof_vn_nary_op): Avoid overflow. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug tree-optimization/54825] ICE with vector extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54825 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 12:00:23 UTC --- Fixed.
[Bug middle-end/54843] [4.8 Regression] ada bootstrap failure on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54843 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking CC||rguenth at gcc dot gnu.org Component|ada |middle-end Target Milestone|--- |4.8.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 12:03:41 UTC --- You need checking enabled.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Target Milestone|--- |4.8.0 Summary|ice tsubst_copy, at |[4.8 Regression] ice |cp/pt.c:12352 |tsubst_copy, at ||cp/pt.c:12352 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 12:04:24 UTC --- Confirmed.
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -O2 -ftracer -fno-tree-dce -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/54828] [4.6/4.7/4.8 Regression] ICE in based_loc_descr at dwarf2out.c:10560 with -g -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54828 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Component|c++ |debug Known to work||4.5.3 Target Milestone|--- |4.6.4 Summary|[4.7 Regression] ICE in |[4.6/4.7/4.8 Regression] |based_loc_descr at |ICE in based_loc_descr at |dwarf2out.c:10560 with -g |dwarf2out.c:10560 with -g |-O0 |-O0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 12:06:36 UTC --- Confirmed.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
--- Comment #7 from dodji at seketeli dot org dodji at seketeli dot org
2012-10-08 12:06:48 UTC ---
Sorry Michal for getting to your comment this late.
ethouris at gmail dot com gcc-bugzi...@gcc.gnu.org a écrit:
Looks nice. Is that a big deal if you also make a standard [[noreturn]]
attribute simply an alias to [[gnu::noreturn]]?
The patch as it is focused on bringing in the core support for c++11
attributes. Supporting some attributes in particular is left as a
follow-up to come up later. An exception to this is that the patch also
supports alignas expressions, but that is just because it was needed to
complete the support of the attributes syntax.
As far as I know the standard, they should behave exactly the same
way.
I haven't looked at the details yet, but I think you are correct.
Another thing is that I think this should work, according to the standard:
void quit [[gnu::noreturn]] () { throw 0; }
And it doesn't with this patch.
I think it works with the version of the patch that I just committed.
Or maybe I don't understand what you mean by doesn't work.
Thanks for caring.
[Bug debug/54826] gdb test case failure (bs15503) due to gaps in lexical block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54826 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08 12:07:55 UTC --- Fixed.
[Bug c++/54844] [4.8 Regression] ice tsubst_copy, at cp/pt.c:12352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-08 12:10:26 UTC --- REAL_TYPE remains unhandled in tsubst_copy. First blush however, I'm not sure if we shouldn't be passing REAL_TYPEs at all, or it's just a trivial matter of adding to the switch.
[Bug c++/53528] Support C++11 generalized attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dodji Seketeli dodji at gcc dot gnu.org 2012-10-08 12:10:26 UTC --- Applied to trunk (4.8).
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #13 from Evren yurtesen eyurtese at abo dot fi 2012-10-08 12:16:48 UTC --- (In reply to comment #12) (In reply to comment #11) I seem to be having this problem in GCC 4.5.4 , 4.6.3 and 4.7.2 :( Ys, as already stated in the comments above, this is only fixed on the trunk. Considering that the fix is rather simple, why isnt it applied to 4.7.x and other supported versions? There is already MPFR 3.1.1 version out, why GCC is not using it by default? GCC doesn't use any version of MPFR by default, it uses whichever version you supply. There is no advantage to GCC from using 3.1.x, so if it's a problem then just use an older version. Perhaps I should have been clearer. The instructions at : http://gcc.gnu.org/wiki/InstallingGCC mention using ./contrib/download_prerequisites which downloads old versions from: ftp://gcc.gnu.org/pub/gcc/infrastructure/ such as MPFR 2.4.2 etc. What I meant was, why this download_prerequisites script, which is provided by GCC is not updated to use the latest MPFR etc.?
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 12:21:53 UTC --- Because 2.4.2 has received the most testing and is known to work and to be sufficient for GCC's needs.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 13:47:32 UTC --- The unistd.h header on darwin12 defines... #define _POSIX_TIMERS (-1)/* [TMR] */ From the documentation on --enable-libstdcxx-time... dnl Check for clock_gettime, nanosleep and sched_yield, used in the dnl implementation of 20.11.7 [time.clock], and 30.3.2 [thread.thread.this] dnl in the C++11 standard. dnl dnl --enable-libstdcxx-time dnl --enable-libstdcxx-time=yes dnlchecks for the availability of monotonic and realtime clocks, dnlnanosleep and sched_yield in libc and libposix4 and, if needed, dnllinks in the latter. dnl --enable-libstdcxx-time=rt dnlalso searches (and, if needed, links) librt. Note that this is dnlnot always desirable because, in glibc, for example, in turn it dnltriggers the linking of libpthread too, which activates locking, dnla large overhead for single-thread programs. dnl --enable-libstdcxx-time=no dnl --disable-libstdcxx-time dnldisables the checks completely it seems that --enable-libstdcxx-time defaults to 'no' which would seem to imply that it is effectively --disable-libstdcxx-time. The --enable-libstdcxx-time=yes check is too strict for darwin because it doesn't handle the case of _POSIX_TIMER defined to -1 for testing pre-POSIX 2008 nanosleep(). What would you consider to be an acceptable change to the test at... AC_MSG_CHECKING([for nanosleep]) AC_TRY_LINK( [#include unistd.h #include time.h ], [#if _POSIX_TIMERS 0 timespec tp; #endif nanosleep(tp, 0); ], [ac_has_nanosleep=yes], [ac_has_nanosleep=no]) AC_MSG_RESULT($ac_has_nanosleep) in libstdc++-v3/acinclude.m4 to solve this limitation? Again I would note that short-circuiting this test for _POSIX_TIMERS 0 introduces no regressions in the libstdc++-v3 test suite so the darwin nanosleep() appears to be sufficient. Or is the libstdc++-v3 testsuite currently incapable of properly testing this feature?
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-10-08 13:56:43 UTC --- Appears to have been introduced in revision 191493.
[Bug bootstrap/54837] [4.8 Regression] lto bootstrap error: ICE in expand_debug_source_expr, at cfgexpand.c:3538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54837 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-10-08 13:56:44 UTC --- This is caused by revision 192139: http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00261.html
[Bug tree-optimization/54855] New: Unnecessary duplication when performing scalar operation on vector element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
Bug #: 54855
Summary: Unnecessary duplication when performing scalar
operation on vector element
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drepper@gmail.com
Take the following code:
#include stdio.h
typedef double v2df __attribute__((vector_size(16)));
int
main(int argc, char *argv[])
{
v2df v = { 2.0, 2.0 };
v2df v2 = { 2.0, 2.0 };
while (argc-- 1)
{
v[0] -= 1.0;
v *= v2;
}
printf(%g\n, v[0] + v[1]);
return 0;
}
It compiles as C and C++, both compilers behave the same.
When compiling on x86-64 (therefore with SSE enabled) it generates for the loop
this code:
4003f0: 66 0f 28 c1 movapd %xmm1,%xmm0
4003f4: 83 e8 01sub$0x1,%eax
4003f7: f2 0f 5c c2 subsd %xmm2,%xmm0
4003fb: f2 0f 10 c8 movsd %xmm0,%xmm1
4003ff: 66 0f 58 c9 addpd %xmm1,%xmm1
400403: 75 eb jne4003f0 main+0x20
I.e., the value is pulled out of the vector, the subtraction is performed, and
then the scalar value is put back into the vector.
Instead the following sequence would have been completely sufficient:
sub$0x1,%eax
subsd %xmm2,%xmm1
addpd %xmm1,%xmm1
jne...back
The subsd instruction doesn't touch the high parts of the register.
I know this is a special case, it only works if the scalar operation is for the
element zero of the vector. But code can be designed like that. I have some
code which would work nicely like this. I don't know whether this translates
to other architectures as well.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #28 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 14:02:46 UTC --- It seems like there is only two possible patches here using the existing infrastructure in acinclude.m4 that would allow darwin's nanosleep() to be found when passing --enable-libstdcxx-time=yes. Either... Index: acinclude.m4 === --- acinclude.m4(revision 192206) +++ acinclude.m4(working copy) @@ -1249,7 +1249,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] [#include unistd.h #include time.h ], -[#if _POSIX_TIMERS 0 +[#if _POSIX_TIMERS != 0 timespec tp; #endif nanosleep(tp, 0); or Index: acinclude.m4 === --- acinclude.m4(revision 192206) +++ acinclude.m4(working copy) @@ -1249,10 +1249,8 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] [#include unistd.h #include time.h ], -[#if _POSIX_TIMERS 0 - timespec tp; - #endif - nanosleep(tp, 0); +[timespec tp; + nanosleep(tp, 0); ], [ac_has_nanosleep=yes], [ac_has_nanosleep=no]) AC_MSG_RESULT($ac_has_nanosleep) Or are you going to demand that the use of pre-2008 POSIX nanosleep() be only accepted on a target-specific basis?
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-08 14:10:25 UTC --- Marek, the patch looks good, thanks.
[Bug lto/54856] New: Corrupted LTO type merging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54856 Bug #: 54856 Summary: Corrupted LTO type merging Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Created attachment 28385 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28385 patch to trigger the ice Hi, with the patch attached that adds double check that when types are equivalent their argument types are equivalent, too. The GCC fails to compile sqlite: jan@linux-e0ml:~/trunk/build/gcc ./xgcc -B ./ -flto=24 -r -nostdlib -fno-fat-lto-objects -fPIC -pedantic -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -O3 -fomit-frame-pointer sqlite3.i /abuild/jh/mozilla-central2/mozilla-central/db/sqlite3/src/sqlite3.c:819:16: warning: ISO C90 does not support ‘long long’ [-Wlong-long] /abuild/jh/mozilla-central2/mozilla-central/db/sqlite3/src/sqlite3.c:820:26: warning: ISO C90 does not support ‘long long’ [-Wlong-long] ^A^Plto1: internal compiler error: in uniquify_nodes, at lto/lto.c:1971 0x51a5ac uniquify_nodes ../../gcc/lto/lto.c:1970 0x51ac0b lto_read_decls ../../gcc/lto/lto.c:2069 0x51b49b lto_file_finalize ../../gcc/lto/lto.c:2322 0x51b4e8 lto_create_files_from_ids ../../gcc/lto/lto.c:2332 0x51b60c lto_file_read ../../gcc/lto/lto.c:2372 0x51e07d read_cgraph_and_symbols ../../gcc/lto/lto.c:2939 0x51ec1a lto_main() ../../gcc/lto/lto.c:3344 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make: *** [/tmp/cchAJFdX.ltrans6.ltrans.o] Error 1 make: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug lto/54856] Corrupted LTO type merging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54856 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-08 14:17:32 UTC --- Created attachment 28386 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28386 preprocessed sqlite.
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org 2012-10-08 14:18:58 UTC --- Could you attach both dumps? (and use -fsched-verbose=5) Did your test include r191838?
[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-08
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-08
14:19:27 UTC ---
Confirmed. Does not work for + though, as -0.0 + 0.0 is 0.0. At least
if I remember the signed-zero mess correctly ;)
On the tree level we see in-memory v because of the component modification:
_7 = BIT_FIELD_REF v, 64, 0;
_8 = _7 - 1.0e+0;
BIT_FIELD_REF v, 64, 0 = _8;
v.0_10 = v;
v.1_11 = v.0_10 * { 2.0e+0, 2.0e+0 };
v = v.1_11;
so either lowering this differently in the first place or detecting
this kind of pattern would fix it.
Similar trick may be used for multiplication and division.
[Bug lto/54856] Corrupted LTO type merging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54856 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-08 14:25:37 UTC --- Created attachment 28387 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28387 My experiemnts with fixup
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 --- Comment #7 from dodji at seketeli dot org dodji at seketeli dot org 2012-10-08 14:26:37 UTC --- paolo.carlini at oracle dot com gcc-bugzi...@gcc.gnu.org a écrit: Dodji, time to ping? ;) Right: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00766.html. :)
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #29 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 14:32:42 UTC --- (In reply to comment #28) It seems like there is only two possible patches here using the existing infrastructure in acinclude.m4 that would allow darwin's nanosleep() to be found when passing --enable-libstdcxx-time=yes. Either... Index: acinclude.m4 === --- acinclude.m4(revision 192206) +++ acinclude.m4(working copy) @@ -1249,7 +1249,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] [#include unistd.h #include time.h ], -[#if _POSIX_TIMERS 0 +[#if _POSIX_TIMERS != 0 This is just wrong. See http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html#tag_13_80_03_02 for the meaning of the values. _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 means the Timers option is not supported. Or are you going to demand that the use of pre-2008 POSIX nanosleep() be only accepted on a target-specific basis? There are plenty of systems with a 2001 nanosleep that define _POSIX_TIMERS to 20112L, but darwin seems to support nanosleep without the rest of the Timers option. I don't want to remove the correct check for _POSIX_TIMERS just for one system's peculiarities.
[Bug debug/54796] [4.8 Regression] Non-addressable stack parameter debug quality regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796 --- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-08 14:37:53 UTC --- I'm a bit uncomfortable with this approach. On the one hand, it's quite simple, which is nice, but if all we get from it is the base term, we'll still have trouble given multiple sp-based non-overlapping memory regions, won't we? The patch in revision 188871 and others in that batch were meant to let alias analysis within vta figure out the relationship between argp, fp and sp and disambiguate accesses. I wonder why it didn't work in this case, with or without the still-pending patch to canonicalize stack pointer tracking. I'd rather go with the latter (even if with additional changes) because it would enable alias analysis, through more precise sp+offset tracking, to distinguish not only between argp and sp-based variables, but also between automatic varying-sized objects. Assuming my understanding of your patch is correct in that it adds information on whether some object is at an sp-relative offset but without making the offset available to alias analysis. Is that so?
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #3 from dave.anglin at bell dot net 2012-10-08 14:45:48 UTC --- On 8-Oct-12, at 10:18 AM, bernds at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #2 from Bernd Schmidt bernds at gcc dot gnu.org 2012-10-08 14:18:58 UTC --- Could you attach both dumps? (and use -fsched-verbose=5) Done. Did your test include r191838? No but the bug is still present with r191838. Dumps are from r191493. -- John David Anglindave.ang...@bell.net
[Bug middle-end/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #4 from dave.anglin at bell dot net 2012-10-08 14:45:51 UTC --- Created attachment 28389 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28389 20041113-1.c.224r.sched2.txt
[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #30 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 14:47:20 UTC --- Can we take a step back and determine what exactly this PR is about? Several of the comments make incorrect statements about the status quo, so I want to get the report clear. I don't understand comment 1. Contrary to comment 2, the configure check for sched_yield does *not* check _POSIX_TIMERS, so sched_yield should be used on darwin when --enable-libstdcxx-time is used. Is _GLIBCXX_USE_SCHED_YIELD defined on darwin when the --enable-libstdcxx-time option is used? That option *doesn't* enable the use of clock_gettime on darwin, because the function isn't available. That's unavoidable. That option does enable checking for nanosleep, but the check fails on darwin because nanosleep is available but darwin doesn't identify itself as supporting the Timers option (presumably because the rest of the option isn't supported.) If that's correct, could we change the bug description to be more accurate?
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #31 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 15:14:19 UTC --- (In reply to comment #30) Can we take a step back and determine what exactly this PR is about? Several of the comments make incorrect statements about the status quo, so I want to get the report clear. I don't understand comment 1. The struct business is a red-herring and can be ignored. The test case without struct is compiled by g++ fine on darwin. Contrary to comment 2, the configure check for sched_yield does *not* check _POSIX_TIMERS, so sched_yield should be used on darwin when --enable-libstdcxx-time is used. Is _GLIBCXX_USE_SCHED_YIELD defined on darwin when the --enable-libstdcxx-time option is used? I read libstdc++-v3/acinclude.m4 to imply that the check for sched_yield is only used when configure is passed --enable-libstdcxx-time=rt, I didn't bother with that case on darwin because Jeremy said CLOCK_REALTIME isn't supported in darwin, so I wouldn't expect it to work unless you had external implementation for the RT POSIX extension. ...off-list. That option *doesn't* enable the use of clock_gettime on darwin, because the function isn't available. That's unavoidable. That option does enable checking for nanosleep, but the check fails on darwin because nanosleep is available but darwin doesn't identify itself as supporting the Timers option (presumably because the rest of the option isn't supported.) If that's correct, could we change the bug description to be more accurate? Done. Note that the man page for darwin nanosleep() can be found at... https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/nanosleep.2.html and claims... The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX.1'').
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #32 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 15:31:30 UTC --- Would something simple like... Index: acinclude.m4 === --- acinclude.m4(revision 192212) +++ acinclude.m4(working copy) @@ -1236,7 +1236,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] [#include unistd.h #include time.h ], -[#if _POSIX_TIMERS 0 +[#if (_POSIX_TIMERS 0 || defined(__APPLE__)) timespec tp; #endif clock_gettime(CLOCK_REALTIME, tp); be acceptable? We have the options of __APPLE_CC__, __APPLE__ or __MACH__ from the preprocessor defines emitted by FSF gcc trunk on darwin.
[Bug other/54857] New: Superfluous NOPs on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54857
Bug #: 54857
Summary: Superfluous NOPs on Atom
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com
GCC [4.7.1 on Linux and 4.6.1 on Cygwin] generates a LOT of unnecessary
NOPs when the target is Atom. The following testcase shows the odd behaviour:
int func(float f) { return (int)f; };
The output is:
gcc -S -O2 -march=atom -mtune=atom test.cpp
.LFB0:
.cfi_startproc
cvttss2si%xmm0, %eax
nop
nop
nop
nop
nop
nop
ret
.cfi_endproc
When the target is e.g. Core2:
gcc -S -O2 -march=core2 -mtune=core2 test.cpp
it is simply:
.LFB0:
.cfi_startproc
cvttss2si%xmm0, %eax
ret
.cfi_endproc
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/mnt/local/a3d.gcc-4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.1/configure --prefix=/mnt/local/a3d.gcc-4.7.1
--with-gmp=/mnt/local/a3d.gcc-4.7.1/gcc-prerequisites
--with-mpfr=/mnt/local/a3d.gcc-4.7.1/gcc-prerequisites
--with-mpc=/mnt/local/a3d.gcc-4.7.1/gcc-prerequisites
--with-ppl=/mnt/local/a3d.gcc-4.7.1/gcc-prerequisites
--with-cloog=/mnt/local/a3d.gcc-4.7.1/gcc-prerequisites
--with-local-prefix=/mnt/local/a3d.gcc-4.7.1 --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 4.7.1 (GCC)
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 15:55:07 UTC --- (In reply to comment #31) (In reply to comment #30) Can we take a step back and determine what exactly this PR is about? Several of the comments make incorrect statements about the status quo, so I want to get the report clear. I don't understand comment 1. I meant comment 0 there. The struct business is a red-herring and can be ignored. The test case without struct is compiled by g++ fine on darwin. Of course, that's what Paolo has been saying. Contrary to comment 2, the configure check for sched_yield does *not* check _POSIX_TIMERS, so sched_yield should be used on darwin when --enable-libstdcxx-time is used. Is _GLIBCXX_USE_SCHED_YIELD defined on darwin when the --enable-libstdcxx-time option is used? I read libstdc++-v3/acinclude.m4 to imply that the check for sched_yield is only used when configure is passed --enable-libstdcxx-time=rt, I didn't bother with that case on darwin because Jeremy said CLOCK_REALTIME isn't supported in darwin, so I wouldn't expect it to work unless you had external implementation for the RT POSIX extension. ...off-list. You read it wrong. The sched_yield check is done for both --enable-libstdcxx-time=yes and --enable-libstdcxx-time=rt So is _GLIBCXX_USE_SCHED_YIELD defined on darwin? That option *doesn't* enable the use of clock_gettime on darwin, because the function isn't available. That's unavoidable. That option does enable checking for nanosleep, but the check fails on darwin because nanosleep is available but darwin doesn't identify itself as supporting the Timers option (presumably because the rest of the option isn't supported.) If that's correct, could we change the bug description to be more accurate? Done. Note that the man page for darwin nanosleep() can be found at... https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/nanosleep.2.html and claims... The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX.1''). The problem isn't finding nanosleep, it's finding what version of POSIX or X/Open or SUS is supported, so we know what the correct feature test macros is for nanosleep. Is _XOPEN_REALTIME defined? If so, to what value? What about _XOPEN_VERSION and _POSIX_C_VERSION? Maybe we can find some other combination of feature test macros that indicate the POSIX Realtime extensions (POSIX.1b) are supported.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #34 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 16:03:10 UTC --- (In reply to comment #32) Would something simple like... Index: acinclude.m4 === --- acinclude.m4(revision 192212) +++ acinclude.m4(working copy) @@ -1236,7 +1236,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] [#include unistd.h #include time.h ], -[#if _POSIX_TIMERS 0 +[#if (_POSIX_TIMERS 0 || defined(__APPLE__)) timespec tp; #endif clock_gettime(CLOCK_REALTIME, tp); be acceptable? We have the options of __APPLE_CC__, __APPLE__ or __MACH__ from the preprocessor defines emitted by FSF gcc trunk on darwin. You might as well just #define _GLIBCXX_USE_NANOSLEEP in config/os/bsd/darwin/os_defines.h
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor ian at airs dot com 2012-10-08 16:18:04 UTC --- What compiler are you using to build the stage 1 compiler? It looks like the problem is that libbacktrace is picking up the header files from the GCC you are building, not the header files from the compiler that is doing the build.
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #2 from Ian Lance Taylor ian at airs dot com 2012-10-08 16:19:25 UTC --- The error shows that libbacktrace is including ../gcc/include/unwind.h, but that file should not exist at the time that libbacktrace is built. I assume that it does exist, but why? Precisely how did you run configure?
[Bug fortran/54784] [4.7/4.8 Regression] [OOP] wrong code in polymorphic allocation with SOURCE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it 2012-10-08 16:22:42 UTC --- Hello, I have a different problem that is definitely related to this area, but may or may not be the same. I have (as usual :) a complex nesting of polymorphic derived types, and I have a need to handle reallocation and re-population of a vector of such containers. The type hierarchy is something like this type mld_d_base_solver_type end type type mld_d_base_smoother_type class(mld_d_base_solver_type), allocatable :: sv end type mld_d_onelev_type class(mld_d_base_smoother_type), allocatable :: sm end type type, extends(psb_dprec_type) :: mld_dprec_type type(mld_d_onelev_type), allocatable :: precv(:) end type Consider the following snippet of code: deallocate(p%precv,stat=info) if (info == 0) allocate(p%precv(newsz),stat=info) if (info /= 0) then info = -1 return end if do i=1, newsz if (info == 0) then if (i ==1) then allocate(p%precv(i)%sm,source=base_sm,stat=info) else if (i newsz) then allocate(p%precv(i)%sm,source=med_sm,stat=info) else allocate(p%precv(i)%sm,source=coarse_sm,stat=info) end if end if if (info /= 0) then info = -1 return end if write(0,*) 'Copy back at level',i do k=1,i write(0,*) ' level',k call p%precv(k)%sm%sv%descr(info,iout=0) if (info /= 0) return end do end do You would expect the allocate with source at I=4 to leave untouched the elements of p%precv(1:3), and yet this is the output I get with 4.7.2: Copy back at level 1 level 1 TLU: test a new solver kind Copy back at level 2 level 1 TLU: test a new solver kind level 2 TLU: test a new solver kind Copy back at level 3 level 1 TLU: test a new solver kind level 2 TLU: test a new solver kind level 3 TLU: test a new solver kind Copy back at level 4 level 1 Incomplete factorization solver: ILU(n) Fill level: 0 level 2 Incomplete factorization solver: ILU(n) Fill level: 0 level 3 Incomplete factorization solver: ILU(n) Fill level: 0 level 4 Incomplete factorization solver: ILU(n) Fill level: 0 Intermediate at level 1 Incomplete factorization solver: ILU(n) Fill level: 0 - This clearly does not make sense. I can send Janus the full code to reproduce the error. Does it seem related? Thanks Salvatore
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #35 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 16:31:11 UTC --- (In reply to comment #33) The problem isn't finding nanosleep, it's finding what version of POSIX or X/Open or SUS is supported, so we know what the correct feature test macros is for nanosleep. Is _XOPEN_REALTIME defined? If so, to what value? What about _XOPEN_VERSION and _POSIX_C_VERSION? Maybe we can find some other combination of feature test macros that indicate the POSIX Realtime extensions (POSIX.1b) are supported. On darwin12, unistd.h shows... #define _XOPEN_VERSION 600 /* [XSI] */ #if __DARWIN_C_LEVEL = 199506L /* This really should be XSI */ ... #define _XOPEN_REALTIME (-1)/* no q'ed signals, mq_* */ #define _XOPEN_REALTIME_THREADS (-1)/* no posix_spawn, et. al. */ ... #endif /* XSI */ #if __DARWIN_C_LEVEL = 199506L /* Really XSI */ ... #define _SC_XOPEN_REALTIME 111 /* Issue 6 */ #define _SC_XOPEN_REALTIME_THREADS 112 /* Issue 6 */ ... #define _SC_XOPEN_VERSION 116 #endif /* XSI */ /* _POSIX_VERSION and _POSIX2_VERSION from sys/unistd.h */ while sys/unistd.h doesn't have _POSIX_C_VERSION but it does have #define _POSIX_VERSION 200112L #define _POSIX2_VERSION 200112L
[Bug c++/54858] New: [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858
Bug #: 54858
Summary: [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Starting with http://gcc.gnu.org/viewcvs?root=gccview=revrev=144618
// { dg-do compile }
template int struct A {};
template typename T, T * struct B {};
template typename D struct C
{
A0 c0; BA0, C::c0 d0;// { dg-error could not convert template
argument }
A0 c1; BA0, C::c1 d1;// { dg-error could not convert template
argument }
A0 c2; BA0, C::c2 d2;// { dg-error could not convert template
argument }
A0 c3; BA0, C::c3 d3;// { dg-error could not convert template
argument }
A0 c4; BA0, C::c4 d4;// { dg-error could not convert template
argument }
A0 c5; BA0, C::c5 d5;// { dg-error could not convert template
argument }
A0 c6; BA0, C::c6 d6;// { dg-error could not convert template
argument }
A0 c7; BA0, C::c7 d7;// { dg-error could not convert template
argument }
A0 c8; BA0, C::c8 d8;// { dg-error could not convert template
argument }
A0 c9; BA0, C::c9 d9;// { dg-error could not convert template
argument }
A0 ca; BA0, C::ca da;// { dg-error could not convert template
argument }
A0 cb; BA0, C::cb db;// { dg-error could not convert template
argument }
};
Cint e;
ICEs in cp_tree_equal (prior to r149188 only two lines with dg-error are
actually needed to trigger it), no options needed.
[Bug c++/54858] [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 16:39:00 UTC --- Created attachment 28390 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28390 gcc48-pr54858.patch Untested fix.
[Bug c++/54858] [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-08 Target Milestone|--- |4.6.4 Ever Confirmed|0 |1
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #36 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 16:44:53 UTC --- (In reply to comment #33) So is _GLIBCXX_USE_SCHED_YIELD defined on darwin? Yes, passing --enable-libstdcxx-time=yes and allowing nanosleep() to be found on darwin also results in... ./c++/4.8.0/x86_64-apple-darwin12.2.0/bits/c++config.h:#define _GLIBCXX_USE_SCHED_YIELD 1 ./c++/4.8.0/x86_64-apple-darwin12.2.0/i386/bits/c++config.h:#define _GLIBCXX_USE_SCHED_YIELD 1
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Summary|--enable-libstdcxx-time=yes |--enable-libstdcxx-time=yes |doesn't find the functional |doesn't find the function |nanosleep() on darwin |nanosleep() on darwin Ever Confirmed|0 |1 --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 16:47:46 UTC --- (In reply to comment #36) (In reply to comment #33) So is _GLIBCXX_USE_SCHED_YIELD defined on darwin? Yes, passing --enable-libstdcxx-time=yes and allowing nanosleep() to be found on darwin also results in... ./c++/4.8.0/x86_64-apple-darwin12.2.0/bits/c++config.h:#define _GLIBCXX_USE_SCHED_YIELD 1 ./c++/4.8.0/x86_64-apple-darwin12.2.0/i386/bits/c++config.h:#define _GLIBCXX_USE_SCHED_YIELD 1 The check for sched_yield has nothing to do with nanosleep, that must have always ben defined.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #38 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 17:03:39 UTC --- I assume the option of using... Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h === --- libstdc++-v3/config/os/bsd/darwin/os_defines.h(revision 192213) +++ libstdc++-v3/config/os/bsd/darwin/os_defines.h(working copy) @@ -42,4 +42,8 @@ // Static initializer macro is buggy in darwin, see libstdc++/51906 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC +// Use nanosleep and sched_yield in libc for C++11 standard. +#define _GLIBCXX_USE_NANOSLEEP 1 +#define _GLIBCXX_USE_SCHED_YIELD 1 + #endif ...eliminates our ability to toggle this support off with --disable-libstdcxx-time, right? This is my only concern with this approach versus the patch in comment 32;
[Bug c++/54859] New: constexpr in template aliase rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859
Bug #: 54859
Summary: constexpr in template aliase rejected as non-constant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
clang-3.2 and gcc-4.7.2 compiles, gcc-4.8 rejects:
--
// enbale_if
template bool B, class T = void
struct enable_if { typedef T type; };
template class T
struct enable_iffalse, T {};
// template alias
templatebool Cnd, class T=void
using eIF = typename enable_if Cnd,T::type;
// f - this compiles
templatebool B=true
typename enable_if!B, int::type f() { return 20; }
// ff - error: integral expression ‘! B’ is not constant
templatebool B=true
eIF!B, int ff() { return 20; }
int main() {}
---
This seams to be related to bug 54648, where I found bad commit to be 191412
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #39 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 17:16:13 UTC --- Yes, but why do you want to disable it? Why does that patch define _GLIBCXX_USE_SCHED_YIELD? That is correctly detected anyway by configure, without any changes, as I said in comment 30 and again in comment 37
[Bug c++/54859] [4.8 Regression] constexpr in template aliase rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|constexpr in template |[4.8 Regression] constexpr |aliase rejected as |in template aliase rejected |non-constant|as non-constant Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 17:25:42 UTC --- Indeed, this started being rejected with http://gcc.gnu.org/viewcvs?root=gccview=revrev=191412 too.
[Bug target/54762] [SH] Utilize zero-displacement branches for conditional far branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54762 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-08 17:37:27 UTC --- When you do this, I'd recommend generating real labels in gcc based on %= (say, .L.fb%= instead of local labels, which should be left to the gcc user.
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-08 17:40:53 UTC --- Author: mpolacek Date: Mon Oct 8 17:38:13 2012 New Revision: 192218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192218 Log: PR54831. Added: trunk/gcc/testsuite/g++.dg/debug/pr54831.C Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug debug/54831] [4.8 Regression] ICE: in vt_add_function_parameter, at var-tracking.c:9412 with -O -fno-split-wide-types -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54831 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-08 17:41:19 UTC --- Fixed.
[Bug preprocessor/51776] fixincludes hacks around a C++ deficiency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51776 --- Comment #3 from bkorb at gnu dot org 2012-10-08 17:46:04 UTC --- (In reply to comment #2) adding ... PR as a dependency so Bruce gets prodded when it changes state Bruce has now been prodded. :) I will fix this in 3 weeks or so.
[Bug target/52480] SH Target: SH4A movua.l does not work for big endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52480 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-08 18:00:25 UTC --- Created attachment 28391 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28391 Proposed patch Hm, the line INTVAL (operands[3]) == -24 * (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN) in the extv and extzv expanders looks wrong. operands[3] is always zero, regardless of the endianess, for the cases in gcc/testsuite/gcc.target/sh/sh4a-bitmovua.c. Changing the check to == 0 seems to be a simple fix for this. Although I didn't dig any further. It might be that there are some more missed unaligned-load opportunities. I've queued up the attached patch for full testing.
[Bug target/52480] SH Target: SH4A movua.l does not work for big endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52480 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1
[Bug target/52480] SH Target: SH4A movua.l does not work for big endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52480
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Attachment #28391|0 |1
is obsolete||
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-08 18:04:14
UTC ---
Created attachment 28392
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28392
Proposed patch
Sorry, forgot to add -fno-inline to the compile options for the test.
I've only briefly tested the patch with
make -k check-gcc RUNTESTFLAGS=sh.exp=sh4a-bitmovua*
--target_board=sh-sim\{-m4a/-ml,-m4a/-mb}
[Bug target/54762] [SH] Utilize zero-displacement branches for conditional far branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54762 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-08 18:07:30 UTC --- (In reply to comment #1) When you do this, I'd recommend generating real labels in gcc based on %= (say, .L.fb%= instead of local labels, which should be left to the gcc user. Thanks for the hint! It would be a general issue in the SH port though. There are already a lot of places where local forward/backward labels are used in the output asm...
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #40 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 2012-10-08 18:33:37 UTC --- (In reply to comment #25) N.B. prior to POSIX 2008 nanosleep was part of the Timers option, if OS X supports that it should define _POSIX_TIMERS to 0, -1 or 200112L to indicate it's supported. POSIX 2008 moves the Timers functionality to the Base spec, and requires that _POSIX_TIMERS is defined to 200809L. In eiher case, a POSIX system supporting nanosleep should define _POSIX_TIMERS. It is defined to -1 because OS X does not support all that _POSIX_TIMERS entails. I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems that don't have it, the tests will simply fail because timespec or nanosleep are undefined. The configure checks are based on well-documented, publicly-available standards, please try to understand them instead of proposing patches based on the misunderstanding that adding struct makes any difference to anything. I very much understand the standards, and I've provided a link to them. The standard itself does not require _POSIX_TIMERS to be defined for nanosleep to be supported, and it specifically states 'struct timespec' in the function prototype. (In reply to comment #26) If Apple or anyone else wants it to work otherwise they need to do the work, as GCC maintainers have no reason to do support building parts of GCC without GCC! Apple is fully committed to libc++. If anyone wants libstdc++ to work on Darwin, it is clear that it will need to be a community effort. (In reply to comment #29) _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 means the Timers option is not supported. Yes, it is not *fully* supported. Or are you going to demand that the use of pre-2008 POSIX nanosleep() be only accepted on a target-specific basis? There are plenty of systems with a 2001 nanosleep that define _POSIX_TIMERS to 20112L, but darwin seems to support nanosleep without the rest of the Timers option. I don't want to remove the correct check for _POSIX_TIMERS just for one system's peculiarities. It's not one system. You are misreading the spec. _POSIX_TIMERS 0 implies that all the functionality is available. That is the only thing you can deduce from that check. It is perfectly valid to have a conforming nanosleep with _POSIX_TIMERS = -1. Why are you even othering to put that code inside of a _POSIX_TIMERS 0 check. If _POSIX_TIMERS 0, you're guaranteed (by the standard) to have that functionality, so there's no point in checking... if you want to support all platforms, it's better to just check for nanosleep directly without the _POSIX_TIMERS check. (In reply to comment #39) Yes, but why do you want to disable it? Why does that patch define _GLIBCXX_USE_SCHED_YIELD? I think his patch has no effect on _GLIBCXX_USE_SCHED_YIELD ... I think he wasn't seeing _GLIBCXX_USE_SCHED_YIELD before because of a mistype he was having with the configure option. With Rob's patch, I see both _GLIBCXX_USE_SCHED_YIELD and _GLIBCXX_USE_NANOSLEEP defined to 1. That is correctly detected anyway by configure, without any changes, as I said in comment 30 and again in comment 37 Yes, it is.
[Bug middle-end/54685] [SH] Improve unsigned int comparison with 0x7FFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54685 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-08 18:36:14 UTC --- The symptoms on SH have been fixed by the patch in rev 192200. I'd like to change this to a middle-end issue, since the actual problem seems to be in the initial expansion of the comparison. I haven't checked it out but it might also be a problem on other targets.
Do not make a single move until you read about it; here!
Donors, This Weekend Our Pink Pick Is: SM_A A SM_A A Receives High Line Automotive Franchise Approval 10/1/2012 - Market Wire Unexplored, under valued SM_A A has quietly expanded a revolutionary lead generation algorythm for virtual automobile dealers, which has, just last week, gained approval from Lexus; with BMW and Mercedes coming in Q4. Date: October, 8 OTC BB: SM_A A TARGET APPRECIATION: 270% - 957% RECOMMENDATION: Strong Speculative Buy ALL GAUGES POINT TO A SOLID BREAKOUT.
[Bug other/54857] Superfluous NOPs on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54857 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-08 18:50:47 UTC --- This was done by design for Atom see http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01104.html : On Atom, the function return address isn't ready until 4 cycles after function is entered.
[Bug c++/54858] [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 19:40:01 UTC --- Author: jakub Date: Mon Oct 8 19:39:56 2012 New Revision: 192220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192220 Log: PR c++/54858 * tree.c (cp_tree_equal): Handle FIELD_DECL. * g++.dg/template/pr54858.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr54858.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54858] [4.6/4.7/4.8 Regression] ICE in cp_tree_equal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08 19:42:12 UTC --- Author: jakub Date: Mon Oct 8 19:42:06 2012 New Revision: 192221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192221 Log: PR c++/54858 * tree.c (cp_tree_equal): Handle FIELD_DECL. * g++.dg/template/pr54858.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/pr54858.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 19:50:21 UTC --- (In reply to comment #40) I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems that don't have it, the tests will simply fail because timespec or nanosleep are undefined. The existence of a function called nanosleep doesn't mean it's the right one, or that it will be found at link time, or available at run-time. Checking _POSIX_TIMERS 0 means the functionality is actually usable, without checking sysconf() at run-time as described by POSIX.1b-2001. The configure checks are based on well-documented, publicly-available standards, please try to understand them instead of proposing patches based on the misunderstanding that adding struct makes any difference to anything. I very much understand the standards, and I've provided a link to them. (That was a link to clock_nanosleep not nanosleep, which was a different option, not Timers ;) That comment wasn't aimed at you... The standard itself does not require _POSIX_TIMERS to be defined for nanosleep to be supported, and it specifically states 'struct timespec' in the function prototype. ... but you do still seem to doubt that the struct is unnecessary in C++. Maybe you've noticed how you don't need to say: class std::string str = a string; ^ to use C++ classes. It's the same for structs. (In reply to comment #26) If Apple or anyone else wants it to work otherwise they need to do the work, as GCC maintainers have no reason to do support building parts of GCC without GCC! Apple is fully committed to libc++. If anyone wants libstdc++ to work on Darwin, it is clear that it will need to be a community effort. Again, there's a difference between *working* (i.e. being usable) on darwin and being able to build libstdc++ with a different compiler. There is no requirement to be able to configure libstdc++ with anything other than G++, but in any case I assure you that clang++ doesn't require the 'struct' keyword either. It's not one system. You are misreading the spec. No I'm not, my words you quoted carefully made the distinction of saying -1 means the Timers option is not supported, not that nanosleep is not supported: _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 means the Timers option is not supported. (I was admittedly less careful in comment 25, sorry) I'd be happy to improve the test to support other systems, but the patches posted to this PR so far have been unacceptable due to failing to understand the existing checks, failing to meet libstdc++'s configury conventions, or adding support for a single system rather than for any systems which provide nanosleep without the rest of the Timers option. In the absence of a decent patch I suggest defining the HAVE_NANOSLEEP macro in os_defines.h and moving on. Why are you even othering to put that code inside of a _POSIX_TIMERS 0 check. If _POSIX_TIMERS 0, you're guaranteed (by the standard) to have that functionality, so there's no point in checking... The existence of a preprocessor symbol doesn't tell you whether you need to link to a particular library to use the function. The check is AC_TRY_LINK which will ensure not only is the function declared but the symbol is found, having added -lposix4 or -lrt to the link line if earlier checks indicate they're needed. if you want to support all platforms, it's better to just check for nanosleep directly without the _POSIX_TIMERS check. If _POSIX_TIMERS is defined to 0 the code might compile but not work at run-time. I didn't write those checks, but I'm not inclined to remove the tests of the POSIX option macros just to fix this PR. That is correctly detected anyway by configure, without any changes, as I said in comment 30 and again in comment 37 Yes, it is. Gread, thanks for confirming that.
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 19:55:28 UTC --- Thanks for the report, Zoltan, it's on my list to look at asap.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #42 from Jeremy Huddleston Sequoia jeremyhu at macports dot org 2012-10-08 20:10:26 UTC --- (In reply to comment #41) (In reply to comment #40) I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems that don't have it, the tests will simply fail because timespec or nanosleep are undefined. The existence of a function called nanosleep doesn't mean it's the right one, or that it will be found at link time, or available at run-time. Checking _POSIX_TIMERS 0 means the functionality is actually usable, without checking sysconf() at run-time as described by POSIX.1b-2001. Right, but as we see here, the converse is not true. ie: This is true: (_POSIX_TIMERS 0) = (nanosleep is the one you want) This is not true: (nanosleep is the one you want) = (_POSIX_TIMERS 0) You want to find an test such that: (your test) = (nanosleep is the one you want) (That was a link to clock_nanosleep not nanosleep, which was a different option, not Timers ;) Aww sorry. I copy-linked the wrong one, but meh. ... but you do still seem to doubt that the struct is unnecessary in C++. No. I don't doubt that. I admitted in comment #20 that C++ is not a strength of mine, so thanks for letting me know about this detail. Maybe you've noticed how you don't need to say: class std::string str = a string; ^ to use C++ classes. It's the same for structs. Yeah, I knew about class, but I didn't know about that for structs. I thought it wasn't possible to drop 'struct' in C++ as it's not possible to drop it in C (although most users will typedef). Thanks for teaching me something new. Again, there's a difference between *working* (i.e. being usable) on darwin and being able to build libstdc++ with a different compiler. There is no requirement to be able to configure libstdc++ with anything other than G++, but in any case I assure you that clang++ doesn't require the 'struct' keyword either. I don't doubt it. I was just trying to make the usage strictly match the POSIX spec. It's not one system. You are misreading the spec. No I'm not, my words you quoted carefully made the distinction of saying -1 means the Timers option is not supported, not that nanosleep is not supported: Ok. I'd be happy to improve the test to support other systems, but the patches posted to this PR so far have been unacceptable due to failing to understand the existing checks, failing to meet libstdc++'s configury conventions, or adding support for a single system rather than for any systems which provide nanosleep without the rest of the Timers option. In the absence of a decent patch I suggest defining the HAVE_NANOSLEEP macro in os_defines.h and moving on. Why are you even othering to put that code inside of a _POSIX_TIMERS 0 check. If _POSIX_TIMERS 0, you're guaranteed (by the standard) to have that functionality, so there's no point in checking... The existence of a preprocessor symbol doesn't tell you whether you need to link to a particular library to use the function. Ah, I forgot you were checking for library linkage as well. That makes sense. The check is AC_TRY_LINK which will ensure not only is the function declared but the symbol is found, having added -lposix4 or -lrt to the link line if earlier checks indicate they're needed. That makes sense. if you want to support all platforms, it's better to just check for nanosleep directly without the _POSIX_TIMERS check. If _POSIX_TIMERS is defined to 0 the code might compile but not work at run-time. I didn't write those checks, but I'm not inclined to remove the tests of the POSIX option macros just to fix this PR. Ok, what about just using _POSIX_TIMERS 0 || defined(__APPLE__)? That may miss some other OSs in the same boat, but they can always add similar checks.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 20:31:01 UTC --- Both OpenBSD and FreeBSD seem to have nanosleep calls documented as... The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX'') like Apple's. On the other hand, using a patch like... Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h === --- libstdc++-v3/config/os/bsd/darwin/os_defines.h(revision 19) +++ libstdc++-v3/config/os/bsd/darwin/os_defines.h(working copy) @@ -42,4 +42,9 @@ // Static initializer macro is buggy in darwin, see libstdc++/51906 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC +// Use nanosleep and sched_yield in libc for time.clock and +// thread.thread.this in C++11 standard. +#define _GLIBCXX_USE_NANOSLEEP 1 +#define _GLIBCXX_USE_SCHED_YIELD 1 + #endif will effectively default darwin to --enable-libstdcxx-time=yes and eliminates a configure option.
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 20:42:22 UTC --- (In reply to comment #42) You want to find an test such that: (your test) = (nanosleep is the one you want) That's why I was asking about other feature test macros that would allow us to detect systems supporting the POSIX.1b-1993 Realtime Extensions, but not the later Timers option, or the POSIX-2008 Base. Ok, what about just using _POSIX_TIMERS 0 || defined(__APPLE__)? That may miss some other OSs in the same boat, but they can always add similar checks. Because we generally try to avoid littering acinclude.m4 with such checks. The other OSs can add defines to their own os_defines.h files if needed. (In reply to comment #43) will effectively default darwin to --enable-libstdcxx-time=yes and eliminates a configure option. That's a *good* thing. If the platform unconditionally supports the feature and doesn't need a configure check why would you want to prevent using it? All that achieves is an incomplete libstdc++ with missing functionality.
[Bug middle-end/54400] recognize haddpd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2012-10-08 20:46:04
UTC ---
Author: glisse
Date: Mon Oct 8 20:45:56 2012
New Revision: 192223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192223
Log:
2012-10-08 Marc Glisse marc.gli...@inria.fr
gcc/
PR target/54400
* config/i386/i386.md (type attribute): Add sseadd1.
(unit attribute): Add support for sseadd1.
(memory attribute): Likewise.
* config/i386/athlon.md: Likewise.
* config/i386/core2.md: Likewise.
* config/i386/atom.md: Likewise.
* config/i386/ppro.md: Likewise.
* config/i386/bdver1.md: Likewise.
* config/i386/sse.md (sse3_hplusminus_insnv2df3): split into...
(sse3_haddv2df3): ... expander.
(*sse3_haddv2df3): ... define_insn. Accept permuted operands.
(sse3_hsubv2df3): ... define_insn.
(*sse3_haddv2df3_low): New define_insn.
(*sse3_hsubv2df3_low): New define_insn.
gcc/testsuite/
PR target/54400
* gcc.target/i386/pr54400.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr54400.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/athlon.md
trunk/gcc/config/i386/atom.md
trunk/gcc/config/i386/bdver1.md
trunk/gcc/config/i386/core2.md
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/ppro.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gcc.target/i386/pr54400.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.target/i386/pr54400.c
('svn:keywords' added)
[Bug middle-end/54860] New: [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 Bug #: 54860 Summary: [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent attribute changes in core gcc Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: do...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 28393 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28393 Repeat with gccobj/./gcc/f951 conftest.f -ffixed-form A patch in the revision range (last_known_working:first_known_failing) 192197:192199 caused the build for cris-elf to fail as follows: ... checking whether the /tmp/build20121008/gccobj/./gcc/gfortran -B/tmp/build20121008/gccobj/./gcc/ -nostdinc -B/tmp/build20121008/gccobj/cris-elf/newlib/ -isystem /tmp/build20121008/gccobj/cris-elf/newlib/targ-include -isystem /tmp/build20121008/gcc/newlib/libc/include -B/tmp/build20121008/gccobj/cris-elf/libgloss/cris -L/tmp/build20121008/gccobj/cris-elf/libgloss/libnosys -L/tmp/build20121008/gcc/libgloss/cris -B/tmp/build20121008/pre/cris-elf/bin/ -B/tmp/build20121008/pre/cris-elf/lib/ -isystem /tmp/build20121008/pre/cris-elf/include -isystem /tmp/build20121008/pre/cris-elf/sys-includelinker (/tmp/build20121008/gccobj/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /tmp/build20121008/gccobj/cris-elf/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/tmp/build20121008/gccobj' In that config.log: configure:12882: /tmp/build20121008/gccobj/./gcc/gfortran -B/tmp/build20121008/gccobj/./gcc/ -nostdinc -B/tmp/build20121008/gccobj/cris-elf/newlib/ -isystem /tmp/build20121008/gccobj/cris-elf/newlib/targ-include -isystem /tmp/build20121008/gcc/newlib/libc/include -B/tmp/build20121008/gccobj/cris-elf/libgloss/cris -L/tmp/build20121008/gccobj/cris-elf/libgloss/libnosys -L/tmp/build20121008/gcc/libgloss/cris -B/tmp/build20121008/pre/cris-elf/bin/ -B/tmp/build20121008/pre/cris-elf/lib/ -isystem /tmp/build20121008/pre/cris-elf/include -isystem /tmp/build20121008/pre/cris-elf/sys-include-c -g conftest.f 5 f951: internal compiler error: Segmentation fault 0x89f135 crash_signal /tmp/build20121008/gcc/gcc/toplev.c:335 0xbcd90a htab_mod /tmp/build20121008/gcc/libiberty/hashtab.c:272 0xbcd90a htab_find_with_hash /tmp/build20121008/gcc/libiberty/hashtab.c:602 0xbd0068 lookup_scoped_attribute_spec(tree_node const*, tree_node const*) /tmp/build20121008/gcc/gcc/attribs.c:325 0xa69645 comp_type_attributes(tree_node const*, tree_node const*) /tmp/build20121008/gcc/gcc/tree.c:4353 0xa69a10 build_type_attribute_qual_variant(tree_node*, tree_node*, int) /tmp/build20121008/gcc/gcc/tree.c:4302 0x564203 build_library_function_decl_1 /tmp/build20121008/gcc/gcc/fortran/trans-decl.c:2650 0x56437c gfc_build_library_function_decl_with_spec(tree_node*, char const*, tree_node*, int, ...) /tmp/build20121008/gcc/gcc/fortran/trans-decl.c:2692 0x5644e3 gfc_build_builtin_function_decls() /tmp/build20121008/gcc/gcc/fortran/trans-decl.c:3067 0x545b7d gfc_create_decls /tmp/build20121008/gcc/gcc/fortran/f95-lang.c:175 0x545b7d gfc_be_parse_file /tmp/build20121008/gcc/gcc/fortran/f95-lang.c:190 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. configure:12882: $? = 1 configure: failed program was: | program main | | end Configure-test-code and command-line attached. Author of only suspect patch in revision range CC:ed. Just configure for --target=cris-elf and make all-gcc to produce f951.
[Bug middle-end/54400] recognize vector reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Summary|recognize haddpd|recognize vector reductions --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2012-10-08 21:02:56 UTC --- Renaming since the specific x86 case is done, and this is now a middle-end PR.
[Bug c++/54861] New: std::atomic_signal_fence(std::memory_order_seq_cst) issues unnecessary mfence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
Bug #: 54861
Summary: std::atomic_signal_fence(std::memory_order_seq_cst)
issues unnecessary mfence
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ozabl...@gmail.com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 28394
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28394
Preprocessed source
#include atomic
void f() { std::atomic_signal_fence(std::memory_order_seq_cst); }
f():
.LFB321:
.cfi_startproc
mfence # == unnecessary mfence
ret
.cfi_endproc
The reason is that std::atomic_signal_fence() (in bits/atomic_base.h) simply
calls std::atomic_thread_fence(), where mfence is indeed necessary.
C++11 29.8.8 says:
extern C void atomic_signal_fence(memory_order order) noexcept;
Effects: equivalent to atomic_thread_fence(order), except that the resulting
ordering constraints are established only between a thread and a signal handler
executed in the same thread.
8 Note: compiler optimizations and reorderings of loads and stores are
inhibited in the same way as with atomic_thread_fence, but the hardware fence
instructions that atomic_thread_fence would have inserted are not emitted.
C11 7.17.4.2 has an identical language.
===
$ g++-4.7 -v -save-temps --std=c++0x -O2 -c atomic_fences.cpp
Using built-in specs.
COLLECT_GCC=g++-4.7
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.0-7ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --disable-bootstrap --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 (Ubuntu/Linaro 4.7.0-7ubuntu3)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-O2' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE atomic_fences.cpp -mtune=generic -march=x86-64
-std=c++11 -O2 -fpch-preprocess -fstack-protector -o atomic_fences.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.7
/usr/include/c++/4.7/x86_64-linux-gnu
/usr/include/c++/4.7/backward
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-O2' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -fpreprocessed atomic_fences.ii
-quiet -dumpbase atomic_fences.cpp -mtune=generic -march=x86-64 -auxbase
atomic_fences -O2 -std=c++11 -version -fstack-protector -o atomic_fences.s
GNU C++ (Ubuntu/Linaro 4.7.0-7ubuntu3) version 4.7.0 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.7.0-7ubuntu3) version 4.7.0 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 33e4f0c75e4f7f1ac5eae22180dee261
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-O2' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
as --64 -o atomic_fences.o atomic_fences.s
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-O2' '-c' '-shared-libgcc'
[Bug libstdc++/54861] std::atomic_signal_fence(std::memory_order_seq_cst) issues unnecessary mfence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|c++ |libstdc++ Severity|normal |enhancement
[Bug middle-end/54860] [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-08 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2012-10-08 21:58:09 UTC --- I am looking at it.
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 --- Comment #3 from Zoltan Glozik zoltan at epochcapital dot com.au 2012-10-08 22:11:26 UTC --- Thanks Jon, how weird to communicate with you on the gcc mailing lists... I hope you are doing well. Cheers, Zoltan -Original Message- From: redi at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Tuesday, 9 October 2012 6:55 AM To: zol...@epochcapital.com.au Subject: [Bug libstdc++/54562] mutex and condition variable timers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added -- -- Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-08 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08 19:55:28 UTC --- Thanks for the report, Zoltan, it's on my list to look at asap. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #142 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-08 22:19:55 UTC --- After updating Mozilla this weekend, I definitely bloat up 8GB machine. The pak in TOP is around 9-10GB. I checked malloc usage and there are not many surprises. It is about 300MB, mostly GGC overhead, pointer maps and such. Most memory is actually the GGC, about 7GB. Here 5GB survives type and decl merging and is distributed as follows: cgraph.c:722 (cgraph_allocate_init_indirect_info1671240: 0.0% 0: 0.0%8202960: 0.2% 0: 0.0% 246855 tree.c:1226 (build_int_cst_wide) 625825208:12.3% 0: 0.0% 10437744: 0.2%4863752: 3.1% 325009 ipa-prop.h:471 (ipa_check_create_edge_args) 0: 0.0% 0: 0.0% 16777216: 0.3% 0: 0.0% 1 ipa-inline-analysis.c:3697 (inline_read_section) 0: 0.0% 28298904: 1.6% 21095504: 0.4%1064480: 0.7% 423701 tree.c:1561 (build_string) 16526800: 0.3% 0: 0.0% 21695715: 0.4%3395427: 2.2% 864326 ipa-prop.c:3393 (ipa_read_node_info) 0: 0.0%4302088: 0.2% 25029448: 0.5% 119192: 0.1% 246788 stringpool.c:75 (alloc_node) 0: 0.0% 0: 0.0% 27817760: 0.5% 0: 0.0% 695444 ipa-ref.c:51 (ipa_record_reference) 0: 0.0% 188442816:10.3% 28443272: 0.6%2114424: 1.4%1256259 stringpool.c:58 (stringpool_ggc_alloc)0: 0.0% 0: 0.0% 34673092: 0.7%2619412: 1.7% 695444 lto/lto.c:2279 (create_subid_section_table) 275832: 0.0% 0: 0.0% 40363416: 0.8%8051472: 5.2% 3978 tree-streamer-in.c:895 (lto_input_ts_constructor 171812232: 3.4% 192568640:10.6% 42205992: 0.8%1425072: 0.9% 947082 ipa-prop.c:3380 (ipa_read_node_info) 0: 0.0% 35825488: 2.0% 58764528: 1.1% 659704: 0.4% 909232 tree-streamer-in.c:488 (streamer_alloc_tree) 129846168: 2.6% 0: 0.0% 75997752: 1.5% 7072: 0.0%2063753 tree.c:1263 (build_int_cst_wide) 237791264: 4.7% 0: 0.0% 90464320: 1.8% 0: 0.0% 10257987 ipa-inline-analysis.c:3709 (inline_read_section) 0: 0.0% 133938484: 7.4% 101874268: 2.0%1606480: 1.0%1099389 lto-section-in.c:361 (lto_new_in_decl_state) 3240: 0.0% 0: 0.0% 107452560: 2.1% 0: 0.0% 895465 cgraph.c:653 (cgraph_create_edge_1) 0: 0.0% 0: 0.0% 135509816: 2.6% 0: 0.0%1302979 ggc-common.c:253 (ggc_cleared_alloc_ptr_array_tw 2040: 0.0% 866397160:47.6% 190623368: 3.7% 263888: 0.2% 11459 lto/lto.c:267 (lto_read_in_decl_state) 3024: 0.0% 0: 0.0% 225743280: 4.4% 41057176:26.5%6268255 ipa-inline-analysis.c:931 (inline_summary_alloc) 0: 0.0% 0: 0.0% 268435464: 5.2% 8: 0.0% 1 cgraph.c:362 (cgraph_allocate_node) 0: 0.0% 0: 0.0% 515473640:10.1% 0: 0.0%1741465 toplev.c:953 (realloc_for_line_map) 0: 0.0% 358955168:19.7% 1074790424:21.0%184: 0.0% 19 tree-streamer-in.c:499 (streamer_alloc_tree) 3668091656:72.1% 0: 0.0% 1995384408:38.9% 87485792:56.5% 46580224 Total5089831352 1821058652 5124870115154815271 91384962 source location GarbageFreed Leak OverheadTimes I.e. 20% are now linemaps, 38% trees read by the streamer, 10% cgraph nodes, 5% inline summaries, 4% streamer table converting UIDs to decls (that can be freed). The trees are distributed as follows: Kind Nodes Bytes --- decls20489087 -1105370640 types10321297 1733977896 blocks1020128160960 stmts 0 0 refs 442971806000 exprs8205133 264995952 constants11667038 376994197 identifiers 695444 27817760 vecs 325009 626535448 binfos 2063753 205829776 ssa names 0 0 constructors 3698868877264 random kinds 7039351 281574472 lang_decl kinds0 0 lang_type kinds0 0 omp clauses0 0 --- Total61322307 -1863768211 --- Code Nodes I think all the blocks read to WPA are bugs. We may also do better on sharing constants. identifier_node
[Bug middle-end/54860] [4.8 Regression]: build fails on cris-elf configuring libgfortran due to recent attribute changes in core gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860 --- Comment #2 from dodji at seketeli dot org dodji at seketeli dot org 2012-10-08 22:23:25 UTC --- hp at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org a écrit: Just configure for --target=cris-elf and make all-gcc to produce f951. So I did this on my system (a Fedora 17). config.log says: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ /home/dodji/devel/git/gcc/cur/configure --target=cris-elf --enable-langages=c,c++,fortran I am getting the f951 binary. Created attachment 28393 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28393 Repeat with gccobj/./gcc/f951 conftest.f -ffixed-form But then when I do: /home/dodji/devel/git/gcc/cur/build/gcc $ cat ../../prtests/test.f program main end $ ./f951 -quiet ../../prtests/test.f -ffixed-form $ I am not seeing the crash. What else am I missing to reproduce the issue?
[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #45 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08 22:27:08 UTC --- I can confirm the existence of sched_yield() back to Libc-166 in 1997 on darwin. http://opensource.apple.com/source/Libc/Libc-166/pthreads.subproj/sched.h The nanosleep() call appears at least by Libc-262.2.12 in 2003 on darwin... http://opensource.apple.com/source/Libc/Libc-262.2.12/include/time.h and probably goes back further but the archived Libc don't show the time.h header before then.
