[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. It seems weird to drop the initializer.
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 --- Comment #6 from Jakub Jelinek --- (In reply to Alan Modra from comment #4) > Created attachment 35342 [details] > prototype patch > > This seems to cure the testcase. I haven't bootstrapped it, and it probably > isn't ideal since I haven't poked at debug insns a lot.. > Still, it points out where the problem is, in move_insn_for_shrink_wrap. Can't you use DF infrastructure for that (before actually moving the insn)? I think pro_and_epilogue pass doesn't compute DF_DU_CHAINs, but perhaps something along the lines of DCE reset_unmarked_insns_debug_uses? I.e. not perform it at all if !MAY_HAVE_DEBUG_INSNS, and use DF infrastructure to find out if the debug insn references the register. Of course, unlike DCE, we aren't looking at debug instructions referencing unmarked insns, but debug instructions referencing a particular hard register. Note that live_edge_for_reg is called multiple times and thus could move across more than one basic block, so perhaps you'd need to remember the sequence of basic blocks to scan during the /* At this point we are committed to moving INSN, but let's try to move it as far as we can. */ loop.
[Bug sanitizer/64741] Incorrect size of UBSan type descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Yury Gribov --- .
[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547 Yury Gribov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Yury Gribov --- .
[Bug debug/65771] [5/6 Regression] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 07:44:30 2015 New Revision: 222166 URL: https://gcc.gnu.org/viewcvs?rev=222166&root=gcc&view=rev Log: PR debug/65771 * dwarf2out.c (loc_list_from_tree): Return NULL for DEBUG_EXPR_DECL. * gcc.dg/debug/pr65771.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/pr65771.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/65771] [5/6 Regression] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 07:45:46 2015 New Revision: 222167 URL: https://gcc.gnu.org/viewcvs?rev=222167&root=gcc&view=rev Log: PR debug/65771 * dwarf2out.c (loc_list_from_tree): Return NULL for DEBUG_EXPR_DECL. * gcc.dg/debug/pr65771.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/debug/pr65771.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/dwarf2out.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #23 from Richard Biener ---
When doing LTO early-debug work I stumbled over one reason we can crash here
which I fixed with
Index: dwarf2out.c
===
*** dwarf2out.c (revision 222165)
--- dwarf2out.c (working copy)
*** resolve_addr (dw_die_ref die)
*** 23950,23957
&& DECL_EXTERNAL (tdecl)
&& DECL_ABSTRACT_ORIGIN (tdecl) == NULL_TREE)
{
! force_decl_die (tdecl);
! tdie = lookup_decl_die (tdecl);
}
if (tdie)
{
--- 23950,23964
&& DECL_EXTERNAL (tdecl)
&& DECL_ABSTRACT_ORIGIN (tdecl) == NULL_TREE)
{
! /* Creating a full DIE for tdecl is overly expensive and
! at this point (with early debug active) even wrong
! as it can end up generating new type DIEs we didn't
! output. */
! tdie = new_die (DW_TAG_subprogram, comp_unit_die (),
NULL_TREE);
! add_AT_flag (tdie, DW_AT_external, 1);
! add_AT_flag (tdie, DW_AT_declaration, 1);
! add_linkage_attr (tdie, tdecl);
! equate_decl_number_to_die (tdecl, tdie);
}
if (tdie)
{
change the comment to "at this point (with LTO) even wrong" and it still
applies. The point is, if we didn't create a DIE for the external decl
it isn't a good idea to create a full DIE for it for the reference. Just
create a DIE with enough info for the debugger (I suppose that's the
linkage name? I really didn't check whether that's ok for the purpose
of DW_TAG_GNU_call_site - Jakub? (not sure if we have guality checks
that cover this very case)
ISTR that for the case I ran into the call was to some builtin function.
The above patch fixes this bug.
[Bug debug/65771] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771 Jakub Jelinek changed: What|Removed |Added Summary|[5/6 Regression] ICE (in|ICE (in loc_list_from_tree, |loc_list_from_tree, at |at dwarf2out.c:14964) on |dwarf2out.c:14964) on |arm-linux-gnueabihf |arm-linux-gnueabihf | --- Comment #12 from Jakub Jelinek --- No longer a regression, keeping this open for the #c9 fix (for trunk only).
[Bug c++/65790] compilation error : receive std::index_sequnece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65790
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-17
Ever confirmed|0 |1
Known to fail||4.8.3, 4.9.2, 5.0, 6.0
--- Comment #1 from Jonathan Wakely ---
Confirmed, Clang and EDG accept this:
extern "C" int printf(const char* ...);
namespace std
{
typedef decltype(sizeof(0)) size_t;
template
struct integer_sequence
{
typedef _Tp value_type;
static constexpr size_t size() { return sizeof...(_Idx); }
};
template
using index_sequence = integer_sequence;
}
void g(std::size_t a, std::size_t b, std::size_t c)
{
printf("%zu, %zu, %zu\n", a, b, c);
}
template
void f(std::index_sequence)
{
g(Seq...);
}
int main()
{
f(std::index_sequence<0, 1, 2>());
}
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 Richard Biener changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Richard Biener --- Can't reproduce with r222165 and -O3 -funroll-loops -ffast-math.
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #24 from Richard Biener --- Which means that -gstrict-dwarf should be a workaround for this and the dups.
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #25 from Avi Kivity --- It's not a latent bug for me: lto1: internal compiler error: Segmentation fault 0xa2f1af crash_signal ../../gcc/toplev.c:383 0x1129f20 htab_hash_string ../../libiberty/hashtab.c:839 0x6d264f external_ref_hasher::hash(external_ref const*) ../../gcc/dwarf2out.c:7763 0x6d264f hash_table::find_slot(external_ref const*, insert_option) ../../gcc/hash-table.h:652 0x6d264f lookup_external_ref ../../gcc/dwarf2out.c:7791 0x6d26ed optimize_external_refs_1 ../../gcc/dwarf2out.c:7829 0x6d2718 optimize_external_refs_1 ../../gcc/dwarf2out.c:7833 0x6d2b56 optimize_external_refs ../../gcc/dwarf2out.c:7882 0x6d2d8d output_comp_unit ../../gcc/dwarf2out.c:9122 0x6f8c69 dwarf2out_finish ../../gcc/dwarf2out.c:24801 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. lto-wrapper: fatal error: /home/avi/gcc5/bin/g++5 returned 1 exit status compilation terminated. g++5 (GCC) 6.0.0 20150417 (experimental)
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #26 from Richard Biener --- Created attachment 35343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35343&action=edit patch Patch I am testing.
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #27 from Avi Kivity --- Patch fixes the problem for me (though the linker still fails)
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 --- Comment #5 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2015-04/msg00371.html : Author: vries Date: Fri Apr 17 09:26:59 2015 New Revision: 222173 URL: https://gcc.gnu.org/viewcvs?rev=222173&root=gcc&view=rev Log: Postpone expanding va_arg until pass_stdarg 2015-04-17 Tom de Vries Michael Matz * gimple-iterator.c (update_modified_stmts): Remove static. * gimple-iterator.h (update_modified_stmts): Declare. * gimplify.c (gimplify_modify_expr): Handle IFN_VA_ARG. (gimplify_va_arg_internal): New function. (gimplify_va_arg_expr): Use IFN_VA_ARG. * gimplify.h (gimplify_va_arg_internal): Declare. * internal-fn.c (expand_VA_ARG): New unreachable function. * internal-fn.def (VA_ARG): New DEF_INTERNAL_FN. * tree-stdarg.c (gimple_call_ifn_va_arg_p, expand_ifn_va_arg_1) (expand_ifn_va_arg): New function. (pass_data_stdarg): Add PROP_gimple_lva to properties_provided field. (pass_stdarg::execute): Call expand_ifn_va_arg. (pass_data_lower_vaarg): New pass_data. (pass_lower_vaarg): New gimple_opt_pass. (pass_lower_vaarg::gate, pass_lower_vaarg::execute) (make_pass_lower_vaarg): New function. * cfgexpand.c (pass_data_expand): Add PROP_gimple_lva to properties_required field. * passes.def (all_passes): Add pass_lower_vaarg. * tree-pass.h (PROP_gimple_lva): Add define. (make_pass_lower_vaarg): Declare. * gcc.dg/tree-ssa/stdarg-2.c: Change f15 scan-tree-dump for target x86_64-*-*. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/gimple-iterator.c trunk/gcc/gimple-iterator.h trunk/gcc/gimplify.c trunk/gcc/gimplify.h trunk/gcc/internal-fn.c trunk/gcc/internal-fn.def trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-2.c trunk/gcc/tree-pass.h trunk/gcc/tree-stdarg.c
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 --- Comment #6 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2015-04/msg00372.html : Author: vries Date: Fri Apr 17 09:27:08 2015 New Revision: 222174 URL: https://gcc.gnu.org/viewcvs?rev=222174&root=gcc&view=rev Log: Set PROP_gimple_lva for functions without IFN_VA_ARG 2015-04-17 Tom de Vries * gimplify.c (gimplify_function_tree): Tentatively set PROP_gimple_lva in cfun->curr_properties. (gimplify_va_arg_expr): Clear PROP_gimple_lva in cfun->curr_properties if we generate an IFN_VA_ARG. * tree-inline.c (expand_call_inline): Reset PROP_gimple_lva in dest function if PROP_gimple_lva is not set in src function. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/tree-inline.c
[Bug tree-optimization/65791] New: Postpone expand_ifn_va_arg till after optimize_va_list_gpr_fpr_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65791
Bug ID: 65791
Summary: Postpone expand_ifn_va_arg till after
optimize_va_list_gpr_fpr_size
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
After the fix for PR64950 - postpone expanding va_arg till pass_stdarg, there's
this TODO pass_stdarg::execute:
...
unsigned int
pass_stdarg::execute (function *fun)
{
/* TODO: Postpone expand_ifn_va_arg till after
optimize_va_list_gpr_fpr_size. */
expand_ifn_va_arg (fun);
if (flag_stdarg_opt
/* This optimization is only for stdarg functions. */
&& fun->stdarg != 0)
optimize_va_list_gpr_fpr_size (fun);
return 0;
}
...
Essentially, we want to rewrite optimize_va_list_gpr_fpr_size to work on
ifn_va_arg.
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from vries at gcc dot gnu.org --- Patch series retested and committed. Filed spinoff PR 65791 - Postpone expand_ifn_va_arg till after optimize_va_list_gpr_fpr_size, for the TODO to rewrite optimize_va_list_gpr_fpr_size to work on ifn_va_arg. Marking resolved, fixed.
[Bug other/51153] OpenACC implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153 Bug 51153 depends on bug 64950, which changed state. Bug 64950 Summary: postpone expanding va_arg till pass_stdarg https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/65791] Postpone expand_ifn_va_arg till after optimize_va_list_gpr_fpr_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65791 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-17 Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2015-02/msg00115.html : ... > [ We're still expanding ifn_va_arg before the va_list_gpr/fpr_size > optimization. ] Yeah, and the point of the exercise was of course to change that ;) ...
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #28 from Richard Biener --- So the context I put the stub DIE in is technically wrong. Thus some more analysis results. The reason why we end up populating the limbo_die_list from the force_decl_die path is because we refuse to put the context (the __lambda2 type) into its context (the main function which we forced a DIE for) because of /* A declaration DIE doesn't count; nested types need to go in the specification. */ if (context_die && is_declaration_die (context_die)) context_die = NULL;
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 --- Comment #4 from vries at gcc dot gnu.org --- stage1 ping: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00861.html
[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65186
Jonathan Wakely changed:
What|Removed |Added
Known to fail||4.8.3, 4.9.2, 5.0, 6.0
Severity|minor |normal
--- Comment #3 from Jonathan Wakely ---
This seems to hit the same ICE, without template aliases:
template struct integral_constant {};
template class> struct Sort;
template class Comparator>
struct Sort
{
template struct less_than:
integral_constant::value> {};
};
int main() {}
[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65186 --- Comment #4 from Jonathan Wakely --- In fact comment 3 doesn't even need C++11, it's valid C++03. It came from http://stackoverflow.com/a/29696258/981959
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #61 from Jakub Jelinek ---
(In reply to Richard Biener from comment #60)
> Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
So, what about just use the workaround automatically for the default
--enable-stage1-checking (of course, if somebody uses something explicitly, he
is on his own)?
Like:
--- configure.ac.jj2015-03-27 18:32:41.0 +0100
+++ configure.ac2015-04-17 13:01:30.117314053 +0200
@@ -3482,7 +3482,19 @@ AC_ARG_ENABLE(stage1-checking,
[choose additional checking for stage1 of the compiler])],
[stage1_checking=--enable-checking=${enable_stage1_checking}],
[if test "x$enable_checking" = xno || test "x$enable_checking" = x; then
- stage1_checking=--enable-checking=yes,types
+ # For --disable-checking or implicit --enable-checking=release, avoid
+ # setting --enable-checking=gc in the default stage1 checking for LTO
+ # bootstraps. See PR62077.
+ stage1_checking=--enable-checking=release,misc,gimple,rtlflag,tree,types
+ case $BUILD_CONFIG in
+*lto*)
+ if test "x$enable_checking" = x && \
+ test -d ${srcdir}/gcc && \
+ test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
+stage1_checking=--enable-checking=yes,types
+ fi;;
+*) stage1_checking=--enable-checking=yes,types;;
+ esac
else
stage1_checking=--enable-checking=$enable_checking,types
fi])
I've so far successfully bootstrapped GCC 5 branch with
../configure --prefix=/tmp/blah --with-gnu-as --with-gnu-ld
--enable-languages=all,go --disable-multilib --disable-nls --with-arch=haswell
--with-tune=haswell --with-build-config=bootstrap-lto
--enable-stage1-checking=release,misc,gimple,rtlflag,tree,types
so it indeed is the gc checking that breaks the LTO bootstrap comparison.
release,misc,gimple,rtlflag,tree,types I believe enables everything yes,types
enables, except for gc checking.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #62 from Richard Biener --- Works for me. Of course we should hunt down IL differences that appear with GC. It's just a lurking bug that can hit the non-GC checking path as well. But all this is exceptionally hard to track down :/
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 H.J. Lu changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #3 from H.J. Lu --- (In reply to Richard Biener from comment #2) > Can't reproduce with r222165 and -O3 -funroll-loops -ffast-math. But my bug report is against -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin not -O3 -funroll-loops -ffast-math. r222168 still has the same bug.
[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 --- Comment #4 from rguenther at suse dot de --- On Fri, 17 Apr 2015, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788 > > H.J. Lu changed: > >What|Removed |Added > > Status|WAITING |ASSIGNED > > --- Comment #3 from H.J. Lu --- > (In reply to Richard Biener from comment #2) > > Can't reproduce with r222165 and -O3 -funroll-loops -ffast-math. > > But my bug report is against > > -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver > -fuse-linker-plugin > > not -O3 -funroll-loops -ffast-math. r222168 still has the same bug. My bad - I uses -O3 -funroll-loops -ffast-math -flto=jobserver linker-plugin gets used automatically for me and -fwhole-program should be a no-op with linker-plugin. I can re-double-check that on Monday though.
[Bug c++/64527] Constructor for empty struct not called in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64527 --- Comment #3 from ppalka at gcc dot gnu.org --- Author: ppalka Date: Fri Apr 17 12:14:24 2015 New Revision: 222176 URL: https://gcc.gnu.org/viewcvs?rev=222176&root=gcc&view=rev Log: Fix PR c++/64527 gcc/ PR c++/64527 * gimplify.c (gimplify_init_constructor): Always emit a side-effecting constructor. gcc/testsuite/ PR c++/64527 * g++.dg/init/pr64527.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/pr64527.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57965] [F03] Allocation of derived type containing an allocatable character component segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57965 Bug 57965 depends on bug 55932, which changed state. Bug 55932 Summary: [F03] ICE for structure constructor with scalar allocatable component https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/55932] [F03] ICE for structure constructor with scalar allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominique d'Humieres --- This is fixed on 5.0.1 and trunk (6.0). Closing.
[Bug fortran/65792] New: allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 Bug ID: 65792 Summary: allocation of scalar elemental function with structure constructor fails Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr The following test (extracted from the extended test in pr61831 comment 41) program main implicit none integer, parameter :: n = 2 type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type :: string_container_t type(string_t) :: comp end type string_container_t type(string_t) :: prt_in, tmp, tmpa(n) type(string_container_t) :: tmpc, tmpca(n) integer :: i, j, k do i=1,16 ! scalar elemental function with structure constructor prt_in = string_t(["D"]) tmpc = new_prt_spec2 (string_container_t(prt_in)) deallocate (prt_in%chars) deallocate(tmpc%comp%chars) end do contains impure elemental function new_prt_spec2 (name) result (prt_spec) type(string_container_t), intent(in) :: name type(string_container_t) :: prt_spec prt_spec = name end function new_prt_spec2 end program main fails at run time with a.out(88248,0x7fff7a4fc300) malloc: *** mach_vm_map(size=18446603339116310528) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. For 4.6 up to 4.9.0, the failure is of the kind a.out(45086) malloc: *** error for object 0x100201010: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug
[Bug libstdc++/65793] New: Libstdc++ docs on _GLIBCXX_CONCEPT_CHECKS are duplicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65793 Bug ID: 65793 Summary: Libstdc++ docs on _GLIBCXX_CONCEPT_CHECKS are duplicated Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org The docs at https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_compile_checks.html and https://gcc.gnu.org/onlinedocs/libstdc++/manual/concept_checking.html seem to have started life identically and diverged. They should be de-duplicated, maybe with a cross-reference. The link at https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html might require updating afterwards.
[Bug libstdc++/65793] Libstdc++ docs on _GLIBCXX_CONCEPT_CHECKS are duplicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65793 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-17 Ever confirmed|0 |1
[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275 Dominique d'Humieres changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Dominique d'Humieres --- > If nobody objects, I'll close the PR as FIXED again. No objection after almost a month. Closing.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #55 from boger at us dot ibm.com --- Created attachment 35344 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35344&action=edit Increment the pc in the callback routine for backtrace_full Always increment the pc in the callback, knowing that it was decremented during the unwind function to find the line number number of the call instruction. This leaves the pc with the correct value for the call stack. If a signal had occurred, and it wasn't a call instruction, the pc will get incremented when it hadn't been decremented during unwind but that is OK for this fix.
[Bug c++/64527] Constructor for empty struct not called in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64527 ppalka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from ppalka at gcc dot gnu.org --- Fixed. Thanks for the comprehensive test case.
[Bug other/65794] New: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794 Bug ID: 65794 Summary: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o' Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Host: i386-mingw32 Target: x86_64-linux-gnu Build: x86_64-linux-gnu GCC configured as: ../../gcc.gnu.org/trunk/configure --build=x86_64-linux-gnu --host=i386-mingw32 --enable-languages=c,c++ --target=x86_64-linux-gnu --prefix=/home/georg/gnu/install/gcc-64-32-cross with empty build and empty install directory. Building the compiler aborts: ... /usr/bin/msgfmt --statistics -o po/zh_TW.gmo ../../../gcc.gnu.org/trunk/gcc/po/zh_TW.po 3519 translated messages, 6759 fuzzy translations, 904 untranslated messages. TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h config/linux-android.h config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh tm.h TARGET_CPU_DEFAULT="" \ HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh tm_p.h TARGET_CPU_DEFAULT="" \ HEADERS="auto-build.h ansidecl.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh bconfig.h make[2]: *** No rule to make target `auto-build.h', needed by `build/genmddeps.o'. Stop. make[2]: Leaving directory `/data/home/georg/gnu/build/gcc-64-32-cross/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/data/home/georg/gnu/build/gcc-64-32-cross' make: *** [all] Error 2 The system has a i386-mingw32 toolchain installed, but presumably the above problem occurs also with other crossback configuration with build = target != host
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 --- Comment #8 from Uroš Bizjak --- (In reply to vries from comment #7) > Marking resolved, fixed. So, can PR41089 hack [1] finally be reverted? [1] https://gcc.gnu.org/ml/gcc-patches/2010-08/msg00072.html
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #29 from Jason Merrill --- (In reply to Jakub Jelinek from comment #17) > Lambda functions aren't really nested functions in the tree-nested.c sense, > but still are so closely related to the functions they are nested in that > IMHO it would be desirable not to split them off into separate partitions, > not just temporarily for GCC 5 for debug info reasons. Agreed. decl_function_context of the lambda function should give you the containing function.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #46 from Dominique d'Humieres --- > > And I haven't looked yet at Dominique's feedback in comment #43. > > The test in comment #41 fails at run time when compiled with > -fsanitize=address. > If I take the "complement" of the reduced test posted in comment #43, > everything works fine, but for one builtin_free less. > > I did not investigated what is wrong with the test in comment #43 (will do). The problem occurs even with a clean tree. I have filed PR65792 for it. The test in comment 41 runs without error if compiled with -fsanitize=address and no valgrind error if I remove/comment the lines 58 and 62: tmpc = new_prt_spec2 (string_container_t(prt_in)) and deallocate(tmpc%comp%chars) > The patch (without the above hunk) fixes a lot of problems and makes > the code simpler. IMO it should be submitted and the few left issues > can be deferred (with new PRs). I have bootstrapper 4.9.3 with the patch and I am currently regtesting gfortran. I am planing to do that same for 5.0.1.
[Bug target/65612] Multiversioning doesn't work with DSO nor PIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65612 --- Comment #7 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Apr 17 12:58:07 2015 New Revision: 222178 URL: https://gcc.gnu.org/viewcvs?rev=222178&root=gcc&view=rev Log: Hide __cpu_indicator_init/__cpu_model from linker We shouldn't call external function, __cpu_indicator_init, while an object is being relocated since its .got.plt section hasn't been updated. It works for non-PIE since no update on .got.plt section is required. This patch creates libgcc.so as a linker script, hides __cpu_indicator_init and __cpu_model in libgcc.so.1 from linker, forces linker to resolve __cpu_indicator_init and __cpu_model to their hidden definitions in libgcc.a while providing backward binary compatibility. gcc/testsuite/ PR target/65612 * g++.dg/ext/mv18.C: New test. * g++.dg/ext/mv19.C: Likewise. * g++.dg/ext/mv20.C: Likewise. * g++.dg/ext/mv21.C: Likewise. * g++.dg/ext/mv22.C: Likewise. * g++.dg/ext/mv23.C: Likewise. libgcc/ PR target/65612 * config.host (tmake_file): Add t-slibgcc-libgcc for Linux/x86. * config/i386/cpuinfo.c (__cpu_model): Initialize. (__cpu_indicator_init@GCC_4.8.0): New. (__cpu_model@GCC_4.8.0): Likewise. * config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Add -DUSE_ELF_SYMVER. Added: trunk/gcc/testsuite/g++.dg/ext/mv18.C trunk/gcc/testsuite/g++.dg/ext/mv19.C trunk/gcc/testsuite/g++.dg/ext/mv20.C trunk/gcc/testsuite/g++.dg/ext/mv21.C trunk/gcc/testsuite/g++.dg/ext/mv22.C trunk/gcc/testsuite/g++.dg/ext/mv23.C Modified: trunk/gcc/testsuite/ChangeLog trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/config/i386/cpuinfo.c trunk/libgcc/config/i386/t-linux
[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
--- Comment #2 from Marek Polacek ---
What happens here is that pop_init_level returns error_mark_node because
initializing a zero-length array member with {} is discarded:
7565 /* Silently discard empty initializations. The parser will
7566 already have pedwarned for empty brackets. */
7567 if (integer_zerop (constructor_unfilled_index))
7568 constructor_type = NULL_TREE;
thus ret.value is NULL:
7718 if (ret.value == 0 && constructor_stack == 0)
7719 ret.value = error_mark_node;
7720 return ret;
output_init_element then sees that value == error_mark_node, so it marks the
ctor as erroneous:
8388 if (type == error_mark_node || value == error_mark_node)
8389 {
8390 constructor_erroneous = 1;
8391 return;
8392 }
And because the ctor is erroneous, we don't build a CONSTRUCTOR for it:
7668 if (constructor_erroneous)
7669 ret.value = error_mark_node;
7670 else
7671 {
7672 ret.value = build_constructor (constructor_type,
7673 constructor_elements);
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #56 from boger at us dot ibm.com --- Here is a bit more detail. Now that I think I understand all the considerations, I'm proposing this simple fix for gcc 5. Maybe longer term a more thorough solution could be done but not sure it is worth changing multiple functions to add an additional argument and changing external header files in gcc 5. The problems to be fixed are: - the pc in the call stack returned by runtime_callers is wrong for some platforms, such as Power and Z and possibly others - the pc adjustment and line number that is looked up in go/runtime/pprof.go sometimes provides the wrong line number if based on the bad pc The proposed fix is to increment the pc in the callback routine that is passed to backtrace_full when trying to find the runtime_callers all the time. During the unwind the pc was decremented for the normal call case. If it was a signal, the pc would not have been decremented so it is being incremented unnecessarily for that situation but I think that is OK since the line number will be right and the pc will still refer to the signalling instruction. As far as the change to the pprof code, at least in gccgo for Power and Z the pc and the line number should be correct so no adjustment is even needed, but my understanding from previous posts is that in the gc compiled case an adjustment is needed and this code is common for gc and gccgo? With the pprof code that is there now, the pprof code is OK for Power, i.e., the line number in the pprof testcase matches the expected line number. For Z, I think that the amount to decrement should be the minimum size for a call instruction (not sure what that value is) and then the tracepc value would refer to the previous instruction. Note that the pprof testcase does not yet work even with this fix because there is a new problem that fails on all platforms with gccgo described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683.
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 boger at us dot ibm.com changed: What|Removed |Added CC||boger at us dot ibm.com --- Comment #10 from boger at us dot ibm.com --- I see this same failure on ppc64le & ppc64. I found that this particular failure started with commit id 221230. It passes with commit id 220481.
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #5 from Bill Schmidt --- Updated patch at https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00883.html.
[Bug target/65612] Multiversioning doesn't work with DSO nor PIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65612 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #8 from H.J. Lu --- Fixed for 6.0.
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Fri Apr 17 13:54:16 2015 New Revision: 222179 URL: https://gcc.gnu.org/viewcvs?rev=222179&root=gcc&view=rev Log: PR target/65296 * config/avr/gen-avr-mmcu-specs.c (*avrlibc_startfile): Adjust to new AVR-LibC file layout (bug #44574). (*avrlibc_devicelib): Same. * config/avr/avr-mcus.def: Adjust comments. * config/avr/avr.opt (nodevicelib): Adjust help. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 vries at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from vries at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #8) > (In reply to vries from comment #7) > > > Marking resolved, fixed. > > So, can PR41089 hack [1] finally be reverted? > > [1] https://gcc.gnu.org/ml/gcc-patches/2010-08/msg00072.html [ Adding alpha maintainer to cc. ] AFAIU, yes. Thanks, - Tom
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |5.2
[Bug debug/65771] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 14:16:30 2015 New Revision: 222181 URL: https://gcc.gnu.org/viewcvs?rev=222181&root=gcc&view=rev Log: PR debug/65771 * dwarf2out.c (mem_loc_descriptor): For CONST, fallback to trying mem_loc_descriptor on XEXP (rtl, 0). Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Fri Apr 17 14:50:50 2015 New Revision: 222182 URL: https://gcc.gnu.org/viewcvs?rev=222182&root=gcc&view=rev Log: [gcc] 2015-04-17 Bill Schmidt PR target/65787 * config/rs6000/rs6000.c (rtx_is_swappable_p): Handle case where vec_extract operation is wrapped in a PARALLEL with a CLOBBER. (adjust_extract): Likewise. [gcc/testsuite] 2015-04-17 Bill Schmidt PR target/65787 * gcc.target/powerpc/pr65787.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr65787.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/rs6000.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #7 from Bill Schmidt --- Jakub pointed out that this is actually a general problem with how I'm handling PARALLELs elsewhere, which I had missed. Testing a slightly different patch now.
[Bug fortran/65795] New: Segfault (invalid write) for ALLOCATE statement involving COARRAYS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65795 Bug ID: 65795 Summary: Segfault (invalid write) for ALLOCATE statement involving COARRAYS Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Created attachment 35345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35345&action=edit Long test case The program below fails with a segfault at run time. The segfault is in the ALLOCATE line. Valgrind talks about: Invalid write of size 8 at 0x40075F: MAIN__ (test.f90:16) It fails here with both -fcoarray=single and -fcoarray=lib and with GCC 4.8, 4.9 and 5. At a glance, the original dump looks okay, but I likely missed something. Attachment: Some longer version; the idea was to use it for testing that reallocation is properly done for coarrays. It still needs some refinement - after the main bug has been fixed. ! Compile with -fcoarray=single or -fcoarray=lib use iso_c_binding, only: c_intptr_t, c_loc implicit none type t2 integer, allocatable :: x end type t2 type t3 type(t2), allocatable :: caf[:] end type t3 type(t3), save, target :: c, d integer :: stat allocate(c%caf[*], stat=stat) end
[Bug fortran/65795] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65795 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-17 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed also for trunk (6.0).
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #37 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #35)
> (In reply to torvald from comment #32)
> > (In reply to James Greenhalgh from comment #28)
> > > This also gives us an easier route to fixing any issues with the
> > > acquire/release __sync primitives (__sync_lock_test_and_set and
> > > __sync_lock_release) if we decide that these also need to be stronger than
> > > their C++11 equivalents.
> >
> > I don't think we have another case of different __sync vs. __atomics
> > semantics in case of __sync_lock_test_and_set. The current specification
> > makes it clear that this is an acquire barrier, and how it describes the
> > semantics (ie, loads and stores that are program-order before the acquire op
> > can move to after it) , this seems to be consistent with the effects C11
> > specifies for acquire MO (with perhaps the distinction that C11 is clear
> > that acquire needs to be paired with some release op to create an ordering
> > constraint).
>
> I think that the question is which parts of a RMW operation with
> MEMMODEL_ACQUIRE semantics is ordered. My understanding is that in C++11
> MEMMODEL_ACQUIRE only applies to the "load" half of the operation. So an
> observer to:
>
> atomic_flag_test_and_set_explicit(foo, memory_order_acquire)
> atomic_store_exlicit (bar, 1, memory_model_relaxed)
That depends on your observer. When reasoning about C11, please let's use
complete examples (and ideally, run them through cppmem). For example, if the
observation is done by a pair of relaxed-MO loads, bar==1 && foo==0 can be
observed:
int main() {
atomic_int foo = 0;
atomic_int bar = 0;
{{{ {
r1 = cas_strong(foo, 0, 1);
bar.store(1, memory_order_relaxed);
} ||| {
r2 = bar.load(memory_order_relaxed).readsvalue(1);
r3 = foo.load(memory_order_relaxed).readsvalue(0);
} }}};
return 0; }
> Is permitted to observe a write to bar before a write to foo (but not before
> the read from foo).
How does one observe a load in C11 (ie, so that "before the read from foo" is
defined)? You can constrain the reads-from of a load, but the load itself is
not observable as an effect.
I think I get what you're trying to say regarding the "load half" but I would
phrase it differently: If there could be another release store to foo that the
CAS/TAS reads-from, then moving the store to bar before the load would risk
creating a cycle between inter-thread happens-before and
sequenced-before-created intra-thread happens-before. (Note that the later
isn't visible to other threads though, except through additional inter-thread
synchronization.)
Perhaps one could also say that moving the store to bar before the store to foo
could result in the CAS/TAS not being atomic -- but this is just reliably
observable if the foo observation is a CAS/TAS by itself (so it's totally
ordered with the other CAS), or if there is a inter-thread happens-before
between the observation of bar and the store to bar (which means using a
release store for bar).
I'm discussing these aspects because I think it matters which observations are
actually possible in a reliable way. It matters for C11, and it may matter for
the __sync semantics as well because while the __sync functions promise TSO, we
don't really do so for all (nonatomic) loads or stores anywhere else in the
program...
IOW, can we actually come up with reliable and correct counter-examples (either
using the C11 or __sync interfaces) for the guarantees we think ARM might not
provide?
> My reading of the Itanium ABI is that the acquire barrier applies to the
> entire operation (Andrew, I think you copied these over exactly backwards in
> comment 34 ;) ):
>
> "Disallows the movement of memory references to visible data from
>after the intrinsic (in program order) to before the intrinsic (this
>behavior is desirable at lock-acquire operations, hence the name)."
>
> The definition of __sync_lock_test_and_set is:
>
> "Behavior:
>• Atomically store the supplied value in *ptr and return the old value
> of *ptr. (i.e.)
>{ tmp = *ptr; *ptr = value; return tmp; }
>• Acquire barrier."
Hmm. I don't think this list is meant to be a sequence; __sync_lock_release
has two items, first the assignment to the memory location, and *second* a
release barrier. If this were supposed to be a sequence, it wouldn't be
correct for lock releases. It rather seems that, somehow, the whole intrinsic
is supposed to be a barrier, and be atomic. Similarly, the __sync RMW ops just
have a single full barrier listed under behavior.
> So by the strict letter of the specification, no memory references to
> visible data should be allowed to move from after the entire body of the
> intrinsic to before it. That is to say in:
>
> __sync_lock_test_and_set (foo, 1)
> bar = 1
>
> an observer should not be able to observe the write to bar before the write
> to f
[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180 --- Comment #2 from boger at us dot ibm.com --- We've been putting most of the discussion on this in the bugzilla mentioned in the previous comment. However there is a simple fix for Power which I will add here: ndex: libgo/runtime/go-callers.c === --- libgo/runtime/go-callers.c (revision 222128) +++ libgo/runtime/go-callers.c (working copy) @@ -83,8 +83,20 @@ callback (void *data, uintptr_t pc, const char *fi } loc = &arg->locbuf[arg->index]; - loc->pc = pc; + /* On the call to backtrace_full the pc value was most likely decremented + if there was a normal call, since the pc referred to the instruction + where the call returned and not the call itself. This was done so that + the line number referred to the call instruction. To make sure + the actual pc from the call stack is used, it is incremented here. + + In the case of a signal, the pc was not decremented by backtrace_full but + still incremented here. That doesn't really hurt anything since the line + number is right and the pc refers to the same instruction. + */ + + loc->pc = pc+1; + /* The libbacktrace library says that these strings might disappear, but with the current implementation they won't. We can't easily allocate memory here, so for now assume that we can save a Since 64999 was written against Z there might be an additional change needed to make that work.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #38 from torvald at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #34) > > However, I guess some people relying on data races in their programs could > > (mis?)understand the __sync_lock_release semantics to mean that it is a > > means to get the equivalent of a C11 release *fence* -- which it is not > > because the fence would apply to the (erroneously non-atomic) store after > > the barrier, which could one lead to believe that if one observes the store > > after the barrier, the fence must also be in effect. Thoughts? > > before we get too carried away, maybe we should return to what we *think* > __sync are suppose to do. It represents a specific definition by intel.. > From the original documentation for __sync "back in the day", and all legacy > uses of sync should expect this behaviour: The problem I see with that is that I don't think that just looking at the psABI gives you enough information to really reason about what you are allowed to do or not. Strictly speaking, the psABI doesn't give you guarantees about normal memory accesses that are not data-race-free (through use of the __sync builtins). Nonetheless, legacy code does use them in a combination with the __sync builtins. Also, if you look at the IA-64 __sync_lock_release vs. GCC docs' __sync_lock_release, the latter is like x86/TSO. Do you have any info on which other semantics __sync was supposed to adhere to? One potential way to solve it would be to just require code that uses __sync to more or less implement an IA-64 or x86 memory model, modulo allowing compiler-reordering and optimization between adjacent non-__sync memory accesses. This could be inefficient on ARM (see James' examples) and perhaps Power too (or not -- see Jakub's comments).
[Bug fortran/58754] [4.8/4.9/5/6 Regression] ICE on allocating character array with source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 --- Comment #7 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #6) > > This fixes the problem. > > Confirmed. > > > However, it will produce multiple evaluations of function results > > and expressions. I will introduce a temporary to cover those cases. > > Is it obvious? > > > PS It's a pity I did not clock this before the RC! > > No RC yet! What, really? Paul
[Bug fortran/58754] [4.8/4.9/5/6 Regression] ICE on allocating character array with source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 --- Comment #8 from Dominique d'Humieres --- > > No RC yet! > > What, really? Now yes. 5.1 should be available in the middle of next week.
[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #36 from Jeffrey A. Law --- Patch in c#35 is approved.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #17 from Jürgen Reuter --- I applied the patch, and did a make in the built folder. I still get the ICE. Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely new built of the gcc/gfortran compiler suite?
[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #37 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Apr 17 16:23:24 2015 New Revision: 222184 URL: https://gcc.gnu.org/viewcvs?rev=222184&root=gcc&view=rev Log: Properly handle uninitialized common symbol Uninitialized common symbol behavior in executables is target and linker dependent. default_binds_local_p_3 is made public and updated to take an argument to indicate if the linker can guarantee that an uninitialized common symbol in the executable will still be defined (through COPY relocation) in the executable. If common symbol is local to executable, default_binds_local_p_3 will treat non-external variable as defined locally. default_binds_local_p_2 is changed to treat common symbol as local for non-PIE binaries. For i386, common symbol is local only for non-PIE binaries. For x86-64, common symbol is local only for non-PIE binaries or linker supports copy reloc in PIE binaries. If a target treats common symbol as local only for non-PIE binaries, it can define TARGET_BINDS_LOCAL_P as default_binds_local_p_2. gcc/ PR target/65780 * output.h (default_binds_local_p_3): New. * varasm.c (default_binds_local_p_3): Make it public. Take an argument to indicate if common symbol may be local. If common symbol may be local, treat non-external variable as defined locally. (default_binds_local_p_2): Pass !flag_pic to default_binds_local_p_3. (default_binds_local_p_1): Pass false to default_binds_local_p_3. * config/i386/i386.c (ix86_binds_local_p): New. (TARGET_BINDS_LOCAL_P): Replace default_binds_local_p_2 with ix86_binds_local_p. gcc/testsuite/ PR target/65780 * gcc.dg/pr65780-1.c: New test. * gcc.dg/pr65780-2.c: Likewise. * gcc.target/i386/pr32219-9.c: Likewise. * gcc.target/i386/pr32219-1.c (xxx): Make it initialized common symbol. * gcc.target/i386/pr64317.c (c): Initialize. Added: trunk/gcc/testsuite/gcc.dg/pr65780-1.c trunk/gcc/testsuite/gcc.dg/pr65780-2.c trunk/gcc/testsuite/gcc.target/i386/pr32219-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/output.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr32219-1.c trunk/gcc/testsuite/gcc.target/i386/pr64317.c trunk/gcc/varasm.c
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 H.J. Lu changed: What|Removed |Added Summary|[5/6 Regression]|[5 Regression] |Uninitialized common|Uninitialized common |handling in executables |handling in executables --- Comment #38 from H.J. Lu --- Fixed on trunk so far.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #39 from Jakub Jelinek --- Please commit it to the branch too, I'll do another RC tomorrow.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #18 from Dominique d'Humieres --- > I applied the patch, and did a make in the built folder. I still get the ICE. Did you do "make install"? > Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely > new built of the gcc/gfortran compiler suite? It is always safer to do a clean bootstrap, but it should not be necessary. When patching gfortran I usually doe "touch gcc/fortran/*" which forces to rebuild fortran at all stages and rebuild libgfortran.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 --- Comment #40 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Apr 17 16:36:22 2015 New Revision: 222185 URL: https://gcc.gnu.org/viewcvs?rev=222185&root=gcc&view=rev Log: Properly handle uninitialized common symbol Uninitialized common symbol behavior in executables is target and linker dependent. default_binds_local_p_3 is made public and updated to take an argument to indicate if the linker can guarantee that an uninitialized common symbol in the executable will still be defined (through COPY relocation) in the executable. If common symbol is local to executable, default_binds_local_p_3 will treat non-external variable as defined locally. default_binds_local_p_2 is changed to treat common symbol as local for non-PIE binaries. For i386, common symbol is local only for non-PIE binaries. For x86-64, common symbol is local only for non-PIE binaries or linker supports copy reloc in PIE binaries. If a target treats common symbol as local only for non-PIE binaries, it can define TARGET_BINDS_LOCAL_P as default_binds_local_p_2. gcc/ PR target/65780 * output.h (default_binds_local_p_3): New. * varasm.c (default_binds_local_p_3): Make it public. Take an argument to indicate if common symbol may be local. If common symbol may be local, treat non-external variable as defined locally. (default_binds_local_p_2): Pass !flag_pic to default_binds_local_p_3. (default_binds_local_p_1): Pass false to default_binds_local_p_3. * config/i386/i386.c (ix86_binds_local_p): New. (TARGET_BINDS_LOCAL_P): Replace default_binds_local_p_2 with ix86_binds_local_p. gcc/testsuite/ PR target/65780 * gcc.dg/pr65780-1.c: New test. * gcc.dg/pr65780-2.c: Likewise. * gcc.target/i386/pr32219-9.c: Likewise. * gcc.target/i386/pr32219-1.c (xxx): Make it initialized common symbol. * gcc.target/i386/pr64317.c (c): Initialize. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65780-1.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65780-2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr32219-9.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.c branches/gcc-5-branch/gcc/output.h branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr32219-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr64317.c branches/gcc-5-branch/gcc/varasm.c
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #41 from H.J. Lu --- Fixed for 5.1.
[Bug target/65689] [5/6 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 16:43:28 2015 New Revision: 222186 URL: https://gcc.gnu.org/viewcvs?rev=222186&root=gcc&view=rev Log: PR target/65689 * genpreds.c (struct constraint_data): Add maybe_allows_reg and maybe_allows_mem bitfields. (maybe_allows_none_start, maybe_allows_none_end, maybe_allows_reg_start, maybe_allows_reg_end, maybe_allows_mem_start, maybe_allows_mem_end): New variables. (compute_maybe_allows): New function. (add_constraint): Use it to initialize maybe_allows_reg and maybe_allows_mem fields. (choose_enum_order): Sort the non-is_register/is_const_int/is_memory/ is_address constraints such that those that allow neither mem nor reg come first, then those that only allow reg but not mem, then those that only allow mem but not reg, then the rest. (write_allows_reg_mem_function): New function. (write_tm_preds_h): Call it. * stmt.c (parse_output_constraint, parse_input_constraint): Use the generated insn_extra_constraint_allows_reg_mem function instead of always setting *allows_reg = true; *allows_mem = true; for unknown extra constraints. * gcc.target/aarch64/c-output-template-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/c-output-template-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/genpreds.c trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/65796] New: unnecessary stack spills during complex numbers function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796
Bug ID: 65796
Summary: unnecessary stack spills during complex numbers
function calls
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
following function calling cabsf exhibits poor performance when compiled with
gcc:
#include
using namespace std;
void __attribute__((noinline)) v(int nCor, complex * inp, complex
* out)
{
for (int icorr = 0; icorr < nCor; icorr++) {
float amp = abs(inp[icorr]);
if (amp > 0.f) {
out[icorr] = amp * inp[icorr];
}
else {
out[icorr] = 0.;
}
}
with gcc 4.9 and 5 (20150208) on x86_64 produces:
g++- test.cc -O2 -c -S
.L15:
movss4(%rsp), %xmm2
addq$8, %rbx
addq$8, %rbp
movss(%rsp), %xmm1
mulss%xmm0, %xmm2
mulss%xmm0, %xmm1
movss%xmm2, -8(%rbx)
movss%xmm1, -4(%rbx)
cmpq%r12, %rbx
je.L14
.L7:
movss0(%rbp), %xmm2
movss4(%rbp), %xmm1
movss%xmm2, 8(%rsp)
movss%xmm1, 12(%rsp)
movq8(%rsp), %xmm0
movss%xmm2, 4(%rsp)
movss%xmm1, (%rsp)
callcabsf
pxor%xmm3, %xmm3
ucomiss%xmm3, %xmm0
ja.L15
note the spills of xmm[12] onto the stack and reloading it into xmm0
instead of spilling to the stack one could use unpcklps to prepare xmm0
with a simple benchmark on 5000 floats this would speed up the function by
about 30% on an intel core2 and an i5 which is quite significant given the
expensive cabs call that is also done in it.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 Jakub Jelinek changed: What|Removed |Added Summary|[5/6 Regression][AArch64] S |[5 Regression][AArch64] S |constraint fails for inline |constraint fails for inline |asm at -O0 |asm at -O0 --- Comment #10 from Jakub Jelinek --- Should be fixed on the trunk now, queued for 5.2 if it is fine on the trunk.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #63 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 17:09:20 2015 New Revision: 222187 URL: https://gcc.gnu.org/viewcvs?rev=222187&root=gcc&view=rev Log: PR bootstrap/62077 * configure.ac (--enable-stage1-checking): Default to release,misc,gimple,rtlflag,tree,types if --disable-checking or --enable-checking is not specified and DEV-PHASE is not experimental. * configure: Regenerated. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #64 from Jakub Jelinek --- Author: jakub Date: Fri Apr 17 17:10:27 2015 New Revision: 222189 URL: https://gcc.gnu.org/viewcvs?rev=222189&root=gcc&view=rev Log: PR bootstrap/62077 * configure.ac (--enable-stage1-checking): Default to release,misc,gimple,rtlflag,tree,types if --disable-checking or --enable-checking is not specified and DEV-PHASE is not experimental. * configure: Regenerated. Modified: branches/gcc-5-branch/ChangeLog branches/gcc-5-branch/configure branches/gcc-5-branch/configure.ac
[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354 --- Comment #6 from Dominique d'Humieres --- AFAICT this PR is fixed at 4.9.2. Any reason why it is not closed?
[Bug fortran/58754] [4.8/4.9/5/6 Regression] ICE on allocating character array with source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 --- Comment #9 from paul.richard.thomas at gmail dot com --- Ah that's a pity. I thought that 5.0 had closed when Tobias was panicking about his co-array patch. I didn't think to check. Cheers Paul On 17 April 2015 at 18:03, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 > > --- Comment #8 from Dominique d'Humieres --- >> > No RC yet! >> >> What, really? > > Now yes. 5.1 should be available in the middle of next week. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/42112] overloaded function with allocatable result problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112 --- Comment #9 from Dominique d'Humieres --- This seems to have been fixed at least for 4.8.4.
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 --- Comment #6 from Andreas Tobler --- Author: andreast Date: Fri Apr 17 17:50:46 2015 New Revision: 222192 URL: https://gcc.gnu.org/viewcvs?rev=222192&root=gcc&view=rev Log: PR target/65535 * config.gcc: Exit with a comment when we do not have a major version number for the FreeBSD target. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #39 from Andrew Macleod --- (In reply to torvald from comment #38) > (In reply to Andrew Macleod from comment #34) > > > However, I guess some people relying on data races in their programs could > > > (mis?)understand the __sync_lock_release semantics to mean that it is a > > > means to get the equivalent of a C11 release *fence* -- which it is not > > > because the fence would apply to the (erroneously non-atomic) store after > > > the barrier, which could one lead to believe that if one observes the > > > store > > > after the barrier, the fence must also be in effect. Thoughts? > > > > before we get too carried away, maybe we should return to what we *think* > > __sync are suppose to do. It represents a specific definition by intel.. > > From the original documentation for __sync "back in the day", and all legacy > > uses of sync should expect this behaviour: > > The problem I see with that is that I don't think that just looking at the > psABI gives you enough information to really reason about what you are > allowed to do or not. Strictly speaking, the psABI doesn't give you > guarantees about normal memory accesses that are not data-race-free (through > use of the __sync builtins). Nonetheless, legacy code does use them in a > combination with the __sync builtins. > > Also, if you look at the IA-64 __sync_lock_release vs. GCC docs' > __sync_lock_release, the latter is like x86/TSO. Do you have any info on > which other semantics __sync was supposed to adhere to? > no, __sync was simply an implementation of psABI back when it was new... I'm not aware of any additions, enhancements or guarantees that were added when it was ported to other arch's. Terminology was much looser 14 years ago :-) That's one of the reasons we want to migrate to __atomic... it is supposedly more precisely defined, whereas __sync had some hand-waving. We're now experiencing some different interpretations of that.Regardless of the documentation, we didn't think we'd be supporting something stronger than SEQ_CST since they were suppose to be equivalent... when rth gets back he may have some opinion as well. > One potential way to solve it would be to just require code that uses __sync > to more or less implement an IA-64 or x86 memory model, modulo allowing > compiler-reordering and optimization between adjacent non-__sync memory > accesses. This could be inefficient on ARM (see James' examples) and > perhaps Power too (or not -- see Jakub's comments).
[Bug go/65755] incorrect reflection of struct fields with gccgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65755 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 18:19:44 2015 New Revision: 222194 URL: https://gcc.gnu.org/viewcvs?rev=222194&root=gcc&view=rev Log: PR go/65755 compiler, runtime, reflect: Use reflection string for type comparisons. Change the runtime and reflect libraries to always use only the type reflection string to determine whether two types are equal. It previously used the PkgPath and Name values for a type name, but that required a PkgPath that did not match the gc compiler. Change the compiler to use the same PkgPath value as the gc compiler in all cases. Change the compiler to put the receiver type in the reflection string for a type defined inside a method. Modified: trunk/gcc/go/gofrontend/types.cc trunk/libgo/go/reflect/type.go trunk/libgo/runtime/go-typedesc-equal.c
[Bug go/65755] incorrect reflection of struct fields with gccgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65755 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Fixed on mainline and GCC 5 branch.
[Bug tree-optimization/47679] [4.8/4.9/5/6 Regression] Strange uninitialized warning after SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #19 from Jeffrey A. Law --- Author: law Date: Fri Apr 17 19:24:17 2015 New Revision: 222195 URL: https://gcc.gnu.org/viewcvs?rev=222195&root=gcc&view=rev Log: PR tree-optimization/47679 * Makefile.in (OBJS); Add tree-ssa-scopedtables.o. * tree-ssa-scopedtables.c: New file. * tree-ssa-scopedtables.h: New file. * tree-ssa-dom.c: Include tree-ssa-scopedtables.h. (const_and_copies): Change name/type. (record_const_or_copy): Move into tree-ssa-scopedtables.c (record_const_or_copy_1): Similarly. (restore_vars_to_original_value): Similarly. (pass_dominator::execute): Create and destroy const_and_copies table. (thread_across_edge): Update passing of const_and_copies. (record_temporary_equivalence): Use method calls rather than manipulating const_and_copies directly. (record_equality, cprop_into_successor_phis): Similarly. (dom_opt_dom_walker::before_dom_children): Similarly. (dom_opt_dom_walker::after_dom_children): Similarly. (eliminate_redundant_computations): Similarly. * tree-ssa-threadedge.c (remove_temporary_equivalences): Delete. (record_temporary_equivalence): Likewise. (invalidate_equivalences): Likewise. (record_temporary_equivalences_from_phis): Update due to type change of const_and_copies. Use method calls rather than manipulating the stack directly. (record_temporary_equivalences_from_stmts_at_dest): Likewise. (thread_through_normal_block, thread_across_edge): Likewise. (thread_across_edge): Likewise. * tree-ssa-threadedge.h (thread_across_edge): Update prototype. * tree-vrp.c: Include tree-ssa-scopedtables.h. Change type of equiv_stack. (identify_jump_threads): Update due to type change of equiv_stack. (finalize_jump_threads): Delete the equiv_stack when complete. Added: trunk/gcc/tree-ssa-scopedtables.c trunk/gcc/tree-ssa-scopedtables.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-loop-ch.c trunk/gcc/tree-ssa-threadedge.c trunk/gcc/tree-ssa-threadedge.h trunk/gcc/tree-vrp.c
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #57 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 19:29:28 2015 New Revision: 222196 URL: https://gcc.gnu.org/viewcvs?rev=222196&root=gcc&view=rev Log: PR go/64999 PR go/65180 runtime: Adjust libbacktrace PC value to what runtime.Callers expects. >From Lynn Boger. Modified: trunk/libgo/runtime/go-callers.c
[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 19:29:43 2015 New Revision: 222197 URL: https://gcc.gnu.org/viewcvs?rev=222197&root=gcc&view=rev Log: PR go/64999 PR go/65180 runtime: Adjust libbacktrace PC value to what runtime.Callers expects. >From Lynn Boger. Modified: branches/gcc-5-branch/libgo/runtime/go-callers.c
[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 19:29:28 2015 New Revision: 222196 URL: https://gcc.gnu.org/viewcvs?rev=222196&root=gcc&view=rev Log: PR go/64999 PR go/65180 runtime: Adjust libbacktrace PC value to what runtime.Callers expects. >From Lynn Boger. Modified: trunk/libgo/runtime/go-callers.c
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #58 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 19:29:43 2015 New Revision: 222197 URL: https://gcc.gnu.org/viewcvs?rev=222197&root=gcc&view=rev Log: PR go/64999 PR go/65180 runtime: Adjust libbacktrace PC value to what runtime.Callers expects. >From Lynn Boger. Modified: branches/gcc-5-branch/libgo/runtime/go-callers.c
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- The problem is the initialization of string_container_t.6.comp in the dump. The array itself (the data component) is properly initialized, but not the array bounds.
[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor --- This aspect of the problem should be fixed, I think.
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 --- Comment #2 from Mikael Morin --- Created attachment 35346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35346&action=edit draft patch, untested
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 Andreas Tobler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #7 from Andreas Tobler --- Fixed.
[Bug target/65787] [5 Regression] Miscompile due to bad vector swap optimization for little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 --- Comment #8 from Bill Schmidt --- Author: wschmidt Date: Fri Apr 17 20:35:59 2015 New Revision: 222198 URL: https://gcc.gnu.org/viewcvs?rev=222198&root=gcc&view=rev Log: 2015-04-17 Bill Schmidt PR target/65787 * config/rs6000/rs6000.c (rtx_is_swappable_p): Remove previous fix; ensure that a subsequent SH_NONE operand does not overwrite an existing *special value. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
[Bug tree-optimization/65797] New: [5.0 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
Bug ID: 65797
Summary: [5.0 regression] IPA ICF causes function to be emitted
with no debug line info
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: hubicka at ucw dot cz
Reporter: ian at airs dot com
This stand alone test case is boiled down from libgo/runtime/go-make-slice.c.
typedef unsigned int uintptr_t __attribute__ ((mode (pointer)));
typedef unsigned int uint64_t __attribute__ ((mode (DI)));
extern int f1 (char *, uintptr_t, uintptr_t);
int
f2 (char *p, uintptr_t s)
{
return f1 (p, s, s);
}
int
f4 (char *p, uint64_t s1, uint64_t s2)
{
uintptr_t t1, t2;
t1 = (uintptr_t) s1;
if ((uint64_t) t1 != s1)
return 0;
t2 = (uintptr_t) s2;
if ((uint64_t) t2 != s2)
return 0;
return f1 (p, t1, t2);
}
int
f3 (char *p, uint64_t s)
{
return f4 (p, s, s);
}
When I compile this -g -O2 -fno-optimize-sibling-calls on x86_64 f2 is
converted into a function that does nothing but call f3. From the standpoint
of execution that is fine. What is not fine is that f2 is emitted with no
debug line information. When compiling for x86_64, the .s output is:
.p2align 4,,15
.globl f2
.type f2, @function
f2:
.LFB4:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callf3
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE4:
.size f2, .-f2
Note the absence of any .loc directives.
This is causing a failure in the libgo testsuite (runtime/pprof on x86_64).
The failure is, essentially, a failure of the stack backtrace to determine the
name of the function f2. In the absence of line information the library is
unable to know the name of the function.
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #11 from Ian Lance Taylor --- This bug may have the same symptoms but it has a completely different cause. Next time, please do not reopen the bug unless you are certain it has the same cause. Please open a new bug instead. Thanks. The immediate cause of this problem is PR 65797. That bug is causing libbacktrace to fail to determine the name of the __go_make_slice1 function, which causes the runtime/pprof package to fail to see that the stack frame is a Go runtime stack frame which should not be reported, which causes the test to fail because an extra unexpected stack frame is being reported.
[Bug go/65798] New: runtime.Caller returns ok=true when return data is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798 Bug ID: 65798 Summary: runtime.Caller returns ok=true when return data is invalid Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at us dot ibm.com CC: cmang at google dot com Target: ppc64le, x86_64, s390x Created attachment 35347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35347&action=edit Don't return ok=true from runtime.Caller if the pc is 0 or the filename has 0 len. This came from a user trying to build Docker on Fedora 22 using gccgo. The they found when calling runtime.Caller, the return value for ok could be true even though the other returned values could be invalid. Because ok was true they assumed the data was valid and tried to use those return values from runtime.Caller to pass onto runtime.FuncForPC which then resulted in the signal 11 displayed below. The failure occurs on every platform they tried to use with gccgo. Here is the original information: Description of problem: docker using gcc-go crashes Version-Release number of selected component (if applicable): gcc-5.0.1-0.1.fc22 How reproducible: Always(reproduced on x86_64, ppc64le, s390x, but expecting ppc64 too) Steps to Reproduce: 1.install docker from https://repos.fedorapeople.org/repos/jcajka/docker-gccgo/ (ppc64(le), s390x) or https://copr.fedoraproject.org/coprs/jcajka/docker-gccgo/ (x86_64) 2.systemctl start docker 3.mkdir /root/dir 4.chcon -Rt svirt_sandbox_file_t /root/dir/ (just in case) 5.1 for x86: docker run fedora -itv /root/dir/:/root/dir/ /bin/bash 5.2 for ppc64(le),s390x(replace arch in docker.io/jcajka/fedora22-...): docker run docker.io/jcajka/fedora22-ppc64 -itv /root/dir/:/root/dir/ /bin/bash Actual results on ppc64le/x86: docker run docker.io/jcajka/fedora22-ppc64le -itv /root/dir/:/root/dir/ /bin/bash panic: runtime error: invalid memory address or nil pointer dereference on ppc64le: [signal 0xb code=0x1 addr=0x8] on x86_64: [signal 0xb code=0x1 addr=0x0] goroutine 16 [running]: github_com_docker_libcontainer_stacktrace.NewFrame /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/stacktrace/frame.go:12 github_com_docker_libcontainer_stacktrace.Capture /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/stacktrace/capture.go:18 libcontainer.newSystemError /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/generic_error.go:48 libcontainer.$nested4 /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/factory_linux.go:212 github_com_docker_libcontainer.StartInitialization.pN43_github_com_docker_libcontainer.LinuxFactory /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/vendor/src/github.com/docker/libcontainer/factory_linux.go:224 native.initializer /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/_build/src/github.com/docker/docker/daemon/execdriver/native/init.go:35 github_com_docker_docker_pkg_reexec.Init /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/_build/src/github.com/docker/docker/pkg/reexec/reexec.go:26 main.main /builddir/build/BUILD/docker-1dcc59a0b40f7d29ab2e0b8fdeb0adf537dbcbaf/docker/docker.go:29 goroutine 18 [finalizer wait]: created by runtime_createfing ../../../libgo/runtime/mgc0.c:2572 goroutine 19 [syscall]: goroutine in C code; stack unavailable created by os_signal..import ../../../libgo/go/os/signal/signal_unix.go:25 Expected results: docker run docker.io/jcajka/fedora22-s390x -itv /root/dir/:/root/dir/ /bin/bash FATA[] Error response from daemon: Cannot start container fb6ed2f3efd57fa07ddf5c4d8576408d0f4cb95fe645a335063f7bed014a0654: [8] System error: exec: "-itv": executable file not found in $PATH Additional info: Crash seems to be triggered by creating new Frame using invalid pc/filename/line in libcontainer(seen this crash from time to time, but haven't got reliable reproducer, until now). As libgo's runtime.Caller(capture.go:14) returns seemingly invalid data(0,"",0) later used in runtime.FuncForPC/parseFunctionName(frame.go). This could be workaround by extending/fixing check in capture.go:15, but I think that runtime.Caller shouldn't return ok state when returned data seems invalid. Patch in attachment prevents this crash. -- I'm attaching their suggested patch.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Dominique d'Humieres changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #42 from Dominique d'Humieres ---
Revision r222184 breaks bootstrap on x86_64-apple-darwin14:
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.3.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0
-I/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common -DHAVE_CONFIG_H -I. -Icp -I../../work/gcc -I../../work/gcc/cp
-I../../work/gcc/../include -I./../intl -I../../work/gcc/../libcpp/include
-I/opt/mp-new/include -I../../work/gcc/../libdecnumber
-I../../work/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../work/gcc/../libbacktrace -I/opt/mp-new/include -o cp/optimize.o -MT
cp/optimize.o -MMD -MP -MF cp/.deps/optimize.TPo ../../work/gcc/cp/optimize.c
../../work/gcc/config/i386/i386.c:51747:1: error: 'bool
ix86_binds_local_p(const_tree)' defined but not used [-Werror=unused-function]
ix86_binds_local_p (const_tree exp)
^
cc1plus: all warnings being treated as errors
Makefile:2071: recipe for target 'i386.o' failed
make[3]: *** [i386.o] Error 1
Bootstrap is restored if I comment the block
static bool
ix86_binds_local_p (const_tree exp)
{
return default_binds_local_p_3 (exp, flag_shlib != 0, true, true,
(!flag_pic
|| (TARGET_64BIT
&& HAVE_LD_PIE_COPYRELOC != 0)));
}
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #12 from boger at us dot ibm.com --- Sorry I did not intend to reopen a closed bugzilla, I must not have looked carefully enough and thought it was still open. Just wanted to document what I found since their log output was the same. I will be more careful.
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #13 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 21:29:08 2015 New Revision: 222199 URL: https://gcc.gnu.org/viewcvs?rev=222199&root=gcc&view=rev Log: PR go/64683 runtime/pprof: Assume function with no name is in runtime. GCC PR 65797 causes some of the runtime functions to be compiled with no name in the debug info. This in turn causes the runtime/pprof test to fail as reported in GCC PR 64683. There are no good choices when a function has no name in the debug info, but here we assume that if we see such a function while reading the runtime functions, we assume that it is also a runtime function. Modified: branches/gcc-5-branch/libgo/go/runtime/pprof/pprof.go
[Bug tree-optimization/65797] [5.0 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 21:29:08 2015 New Revision: 222199 URL: https://gcc.gnu.org/viewcvs?rev=222199&root=gcc&view=rev Log: PR go/64683 runtime/pprof: Assume function with no name is in runtime. GCC PR 65797 causes some of the runtime functions to be compiled with no name in the debug info. This in turn causes the runtime/pprof test to fail as reported in GCC PR 64683. There are no good choices when a function has no name in the debug info, but here we assume that if we see such a function while reading the runtime functions, we assume that it is also a runtime function. Modified: branches/gcc-5-branch/libgo/go/runtime/pprof/pprof.go
[Bug tree-optimization/65797] [5.0 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 17 21:29:20 2015 New Revision: 00 URL: https://gcc.gnu.org/viewcvs?rev=00&root=gcc&view=rev Log: PR go/64683 runtime/pprof: Assume function with no name is in runtime. GCC PR 65797 causes some of the runtime functions to be compiled with no name in the debug info. This in turn causes the runtime/pprof test to fail as reported in GCC PR 64683. There are no good choices when a function has no name in the debug info, but here we assume that if we see such a function while reading the runtime functions, we assume that it is also a runtime function. Modified: trunk/libgo/go/runtime/pprof/pprof.go
