[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59949 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2014-01-26 00:00:00 |2016-10-22 Severity|minor |normal
[Bug testsuite/60487] FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-generate -D_PROFILE_GENERATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60487 --- Comment #2 from Andrew Pinski --- Has this been fixed yet?
[Bug bootstrap/55496] False positive -Werror=uninitialized breaks profiledbootstrap and bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496 Andrew Pinski changed: What|Removed |Added Keywords||build --- Comment #3 from Andrew Pinski --- Does this still happen?
[Bug ipa/55499] [devirt] trunk fails to eliminate dead functions where all call sites were inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- This has been fixed. I can't remember which patch did it but it is the one which added CLOBBER statements to the deconstructors.
[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6 due to lack of return functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2012-12-13 00:00:00 |2016-10-22 Severity|normal |enhancement
[Bug ipa/63571] Local functions with only local aliases not regparm optimized on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63571 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-22 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- .
[Bug c/78074] New: gcc-6.2.0 miscompiles calloc reimplementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78074
Bug ID: 78074
Summary: gcc-6.2.0 miscompiles calloc reimplementation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: phelps at pobox dot com
Target Milestone: ---
For better or worse, tcsh provides its own malloc/calloc/realloc/free
functions. With gcc-6.2.0 (as supplied by Ubuntu-12.10, and also compiled from
sources), I'm seeing its realloc compiled into a infinite loop. Here is a
stripped down test case that loops indefinitely:
#include
#include
#include
void *calloc(size_t nmemb, size_t size)
{
void *p = malloc(nmemb * size);
if (p != NULL)
memset(p, 0, nmemb * size);
return p;
}
int main(int argc, char *argv[])
{
char *value = calloc(64, 1);
printf("value=%p\n", value);
exit(0);
}
With -O2, it looks like gcc is interpreting the call to malloc as a call to
calloc instead:
(gdb) disassemble calloc
Dump of assembler code for function calloc:
0x0760 <+0>: imul %rsi,%rdi
0x0764 <+4>: mov$0x1,%esi
0x0769 <+9>: jmpq 0x760
End of assembler dump.
There's clearly something special about the names here: replacing calloc with
xcalloc produces code that runs fine.
[Bug middle-end/78074] gcc-6.2.0 miscompiles calloc reimplementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78074 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Use -fno-builtin to remove this optimization that is so GCC does not recognize malloc/memset here. This optimization has been there since 2014.
[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033 Dominique d'Humieres changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #8 from Dominique d'Humieres --- *** Bug 71759 has been marked as a duplicate of this bug. ***
[Bug fortran/71759] [5/6/7 Regression] ICE in enforce_single_undo_checkpoint, at fortran/symbol.c:3478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71759 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Dominique d'Humieres --- Also fixed by the patch posted at https://gcc.gnu.org/ml/fortran/2016-10/msg00156.html Marking as duplicate of pr78033. *** This bug has been marked as a duplicate of bug 78033 ***
[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033
--- Comment #9 from Dominique d'Humieres ---
> Patch posted at
>
> https://gcc.gnu.org/ml/fortran/2016-10/msg00156.html
The patch regtested fine but for
FAIL: gfortran.dg/gomp/udr3.f90 -O (test for errors, line 16)
FAIL: gfortran.dg/gomp/udr3.f90 -O (test for excess errors)
Running the test manually I see
...
/opt/gcc/work/gcc/testsuite/gfortran.dg/gomp/udr3.f90:16:6:
!$omp declare reduction (baz:integer,real,integer & ! { dg-error "Redefinition
of !.OMP DECLARE REDUCTION|Previous" }
1
Error: Unclassifiable OpenMP directive at (1)
...
i.e., the error no longer matches the regexp.
[Bug tree-optimization/78060] [7 Regression] -O3 causes "error: type mismatch in binary expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78060 Martin Liška changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #3 from Martin Liška --- *** Bug 78072 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/78072] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78072 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Caused by loop splitting commit (r241374), I'm marking that as dup of PR78060. *** This bug has been marked as a duplicate of bug 78060 ***
[Bug c++/10619] Error message for no matching function calls does not list explicitly-specified template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eelis --- GCC now emits additional diagnostics explaining why the candidate f could not be used, which is exactly what I wanted. Thanks!
[Bug c++/42490] using-directive in namespace doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eelis --- Seems to be fixed, thanks!
[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033 --- Comment #10 from Dominique d'Humieres --- > The patch regtested fine but for > > FAIL: gfortran.dg/gomp/udr3.f90 -O (test for errors, line 16) > FAIL: gfortran.dg/gomp/udr3.f90 -O (test for excess errors) I have overlooked another failure FAIL: gfortran.dg/array_constructor_42.f90 -O (test for excess errors) /opt/gcc/work/gcc/testsuite/gfortran.dg/array_constructor_42.f90:15:24: vec = (/ real(a = 1), 1. /) 1 Error: Invalid type-spec at (1) /opt/gcc/work/gcc/testsuite/gfortran.dg/array_constructor_42.f90:21:26: print *,(/ real(a = 1) /) 1 Error: Invalid type-spec at (1)
[Bug fortran/61376] Error using private statement in polymorphic derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61376 --- Comment #2 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Oct 22 12:33:38 2016 New Revision: 241439 URL: https://gcc.gnu.org/viewcvs?rev=241439&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/51864 PR fortran/57117 PR fortran/61337 PR fortran/61376 * primary.c (gfc_expr_attr): For transformational functions on classes get the attrs from the class argument. * resolve.c (resolve_ordinary_assign): Remove error message due to feature implementation. Rewrite POINTER_ASSIGNS to ordinary ones when the right-hand side is scalar class object (with some restrictions). * trans-array.c (trans_array_constructor): Create the temporary from class' inner type, i.e., the derived type. (build_class_array_ref): Add support for class array's storage of the class object or the array descriptor in the decl saved descriptor. (gfc_conv_expr_descriptor): When creating temporaries for class objects add the class object's handle into the decl saved descriptor. (structure_alloc_comps): Use the common way to get the _data component. (gfc_is_reallocatable_lhs): Add notion of allocatable class objects. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Remove the only ref only when the expression's type is BT_CLASS. (gfc_trans_class_init_assign): Correctly handle class arrays. (gfc_trans_class_assign): Joined into gfc_trans_assignment_1. (gfc_conv_procedure_call): Support for class types as arguments. (trans_get_upoly_len): For unlimited polymorphics retrieve the _len component's tree. (trans_class_vptr_len_assignment): Catch all ways to assign the _vptr and _len components of a class object correctly. (pointer_assignment_is_proc_pointer): Identify assignments of procedure pointers. (gfc_trans_pointer_assignment): Enhance support for class object pointer assignments. (gfc_trans_scalar_assign): Removed assert. (trans_class_assignment): Assign to a class object. (gfc_trans_assignment_1): Treat class objects correctly. (gfc_trans_assignment): Propagate flags to trans_assignment_1. * trans-stmt.c (gfc_trans_allocate): Use gfc_trans_assignment now instead of copy_class_to_class. * trans-stmt.h: Function prototype removed. * trans.c (trans_code): Less special casing for class objects. * trans.h: Added flags to gfc_trans_assignment () prototype. gcc/testsuite/ChangeLog: 2016-10-22 Andre Vehreschild Forgot to add on original commit. * gfortran.dg/coarray_alloc_comp_2.f08: New test. 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/57117 PR fortran/61337 * gfortran.dg/alloc_comp_class_5.f03: New test. * gfortran.dg/class_allocate_21.f90: New test. * gfortran.dg/class_allocate_22.f90: New test. * gfortran.dg/realloc_on_assign_27.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_allocate_21.f90 trunk/gcc/testsuite/gfortran.dg/class_allocate_22.f90 trunk/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_27.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51864 --- Comment #3 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Oct 22 12:33:38 2016 New Revision: 241439 URL: https://gcc.gnu.org/viewcvs?rev=241439&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/51864 PR fortran/57117 PR fortran/61337 PR fortran/61376 * primary.c (gfc_expr_attr): For transformational functions on classes get the attrs from the class argument. * resolve.c (resolve_ordinary_assign): Remove error message due to feature implementation. Rewrite POINTER_ASSIGNS to ordinary ones when the right-hand side is scalar class object (with some restrictions). * trans-array.c (trans_array_constructor): Create the temporary from class' inner type, i.e., the derived type. (build_class_array_ref): Add support for class array's storage of the class object or the array descriptor in the decl saved descriptor. (gfc_conv_expr_descriptor): When creating temporaries for class objects add the class object's handle into the decl saved descriptor. (structure_alloc_comps): Use the common way to get the _data component. (gfc_is_reallocatable_lhs): Add notion of allocatable class objects. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Remove the only ref only when the expression's type is BT_CLASS. (gfc_trans_class_init_assign): Correctly handle class arrays. (gfc_trans_class_assign): Joined into gfc_trans_assignment_1. (gfc_conv_procedure_call): Support for class types as arguments. (trans_get_upoly_len): For unlimited polymorphics retrieve the _len component's tree. (trans_class_vptr_len_assignment): Catch all ways to assign the _vptr and _len components of a class object correctly. (pointer_assignment_is_proc_pointer): Identify assignments of procedure pointers. (gfc_trans_pointer_assignment): Enhance support for class object pointer assignments. (gfc_trans_scalar_assign): Removed assert. (trans_class_assignment): Assign to a class object. (gfc_trans_assignment_1): Treat class objects correctly. (gfc_trans_assignment): Propagate flags to trans_assignment_1. * trans-stmt.c (gfc_trans_allocate): Use gfc_trans_assignment now instead of copy_class_to_class. * trans-stmt.h: Function prototype removed. * trans.c (trans_code): Less special casing for class objects. * trans.h: Added flags to gfc_trans_assignment () prototype. gcc/testsuite/ChangeLog: 2016-10-22 Andre Vehreschild Forgot to add on original commit. * gfortran.dg/coarray_alloc_comp_2.f08: New test. 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/57117 PR fortran/61337 * gfortran.dg/alloc_comp_class_5.f03: New test. * gfortran.dg/class_allocate_21.f90: New test. * gfortran.dg/class_allocate_22.f90: New test. * gfortran.dg/realloc_on_assign_27.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_allocate_21.f90 trunk/gcc/testsuite/gfortran.dg/class_allocate_22.f90 trunk/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_27.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117 --- Comment #15 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Oct 22 12:33:38 2016 New Revision: 241439 URL: https://gcc.gnu.org/viewcvs?rev=241439&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/51864 PR fortran/57117 PR fortran/61337 PR fortran/61376 * primary.c (gfc_expr_attr): For transformational functions on classes get the attrs from the class argument. * resolve.c (resolve_ordinary_assign): Remove error message due to feature implementation. Rewrite POINTER_ASSIGNS to ordinary ones when the right-hand side is scalar class object (with some restrictions). * trans-array.c (trans_array_constructor): Create the temporary from class' inner type, i.e., the derived type. (build_class_array_ref): Add support for class array's storage of the class object or the array descriptor in the decl saved descriptor. (gfc_conv_expr_descriptor): When creating temporaries for class objects add the class object's handle into the decl saved descriptor. (structure_alloc_comps): Use the common way to get the _data component. (gfc_is_reallocatable_lhs): Add notion of allocatable class objects. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Remove the only ref only when the expression's type is BT_CLASS. (gfc_trans_class_init_assign): Correctly handle class arrays. (gfc_trans_class_assign): Joined into gfc_trans_assignment_1. (gfc_conv_procedure_call): Support for class types as arguments. (trans_get_upoly_len): For unlimited polymorphics retrieve the _len component's tree. (trans_class_vptr_len_assignment): Catch all ways to assign the _vptr and _len components of a class object correctly. (pointer_assignment_is_proc_pointer): Identify assignments of procedure pointers. (gfc_trans_pointer_assignment): Enhance support for class object pointer assignments. (gfc_trans_scalar_assign): Removed assert. (trans_class_assignment): Assign to a class object. (gfc_trans_assignment_1): Treat class objects correctly. (gfc_trans_assignment): Propagate flags to trans_assignment_1. * trans-stmt.c (gfc_trans_allocate): Use gfc_trans_assignment now instead of copy_class_to_class. * trans-stmt.h: Function prototype removed. * trans.c (trans_code): Less special casing for class objects. * trans.h: Added flags to gfc_trans_assignment () prototype. gcc/testsuite/ChangeLog: 2016-10-22 Andre Vehreschild Forgot to add on original commit. * gfortran.dg/coarray_alloc_comp_2.f08: New test. 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/57117 PR fortran/61337 * gfortran.dg/alloc_comp_class_5.f03: New test. * gfortran.dg/class_allocate_21.f90: New test. * gfortran.dg/class_allocate_22.f90: New test. * gfortran.dg/realloc_on_assign_27.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_allocate_21.f90 trunk/gcc/testsuite/gfortran.dg/class_allocate_22.f90 trunk/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_27.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/61337] Wrong indexing and runtime crash with unlimited polymorphic array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61337 --- Comment #5 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Oct 22 12:33:38 2016 New Revision: 241439 URL: https://gcc.gnu.org/viewcvs?rev=241439&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/51864 PR fortran/57117 PR fortran/61337 PR fortran/61376 * primary.c (gfc_expr_attr): For transformational functions on classes get the attrs from the class argument. * resolve.c (resolve_ordinary_assign): Remove error message due to feature implementation. Rewrite POINTER_ASSIGNS to ordinary ones when the right-hand side is scalar class object (with some restrictions). * trans-array.c (trans_array_constructor): Create the temporary from class' inner type, i.e., the derived type. (build_class_array_ref): Add support for class array's storage of the class object or the array descriptor in the decl saved descriptor. (gfc_conv_expr_descriptor): When creating temporaries for class objects add the class object's handle into the decl saved descriptor. (structure_alloc_comps): Use the common way to get the _data component. (gfc_is_reallocatable_lhs): Add notion of allocatable class objects. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Remove the only ref only when the expression's type is BT_CLASS. (gfc_trans_class_init_assign): Correctly handle class arrays. (gfc_trans_class_assign): Joined into gfc_trans_assignment_1. (gfc_conv_procedure_call): Support for class types as arguments. (trans_get_upoly_len): For unlimited polymorphics retrieve the _len component's tree. (trans_class_vptr_len_assignment): Catch all ways to assign the _vptr and _len components of a class object correctly. (pointer_assignment_is_proc_pointer): Identify assignments of procedure pointers. (gfc_trans_pointer_assignment): Enhance support for class object pointer assignments. (gfc_trans_scalar_assign): Removed assert. (trans_class_assignment): Assign to a class object. (gfc_trans_assignment_1): Treat class objects correctly. (gfc_trans_assignment): Propagate flags to trans_assignment_1. * trans-stmt.c (gfc_trans_allocate): Use gfc_trans_assignment now instead of copy_class_to_class. * trans-stmt.h: Function prototype removed. * trans.c (trans_code): Less special casing for class objects. * trans.h: Added flags to gfc_trans_assignment () prototype. gcc/testsuite/ChangeLog: 2016-10-22 Andre Vehreschild Forgot to add on original commit. * gfortran.dg/coarray_alloc_comp_2.f08: New test. 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/57117 PR fortran/61337 * gfortran.dg/alloc_comp_class_5.f03: New test. * gfortran.dg/class_allocate_21.f90: New test. * gfortran.dg/class_allocate_22.f90: New test. * gfortran.dg/realloc_on_assign_27.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_allocate_21.f90 trunk/gcc/testsuite/gfortran.dg/class_allocate_22.f90 trunk/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_27.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 --- Comment #18 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Oct 22 12:33:38 2016 New Revision: 241439 URL: https://gcc.gnu.org/viewcvs?rev=241439&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/51864 PR fortran/57117 PR fortran/61337 PR fortran/61376 * primary.c (gfc_expr_attr): For transformational functions on classes get the attrs from the class argument. * resolve.c (resolve_ordinary_assign): Remove error message due to feature implementation. Rewrite POINTER_ASSIGNS to ordinary ones when the right-hand side is scalar class object (with some restrictions). * trans-array.c (trans_array_constructor): Create the temporary from class' inner type, i.e., the derived type. (build_class_array_ref): Add support for class array's storage of the class object or the array descriptor in the decl saved descriptor. (gfc_conv_expr_descriptor): When creating temporaries for class objects add the class object's handle into the decl saved descriptor. (structure_alloc_comps): Use the common way to get the _data component. (gfc_is_reallocatable_lhs): Add notion of allocatable class objects. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): Remove the only ref only when the expression's type is BT_CLASS. (gfc_trans_class_init_assign): Correctly handle class arrays. (gfc_trans_class_assign): Joined into gfc_trans_assignment_1. (gfc_conv_procedure_call): Support for class types as arguments. (trans_get_upoly_len): For unlimited polymorphics retrieve the _len component's tree. (trans_class_vptr_len_assignment): Catch all ways to assign the _vptr and _len components of a class object correctly. (pointer_assignment_is_proc_pointer): Identify assignments of procedure pointers. (gfc_trans_pointer_assignment): Enhance support for class object pointer assignments. (gfc_trans_scalar_assign): Removed assert. (trans_class_assignment): Assign to a class object. (gfc_trans_assignment_1): Treat class objects correctly. (gfc_trans_assignment): Propagate flags to trans_assignment_1. * trans-stmt.c (gfc_trans_allocate): Use gfc_trans_assignment now instead of copy_class_to_class. * trans-stmt.h: Function prototype removed. * trans.c (trans_code): Less special casing for class objects. * trans.h: Added flags to gfc_trans_assignment () prototype. gcc/testsuite/ChangeLog: 2016-10-22 Andre Vehreschild Forgot to add on original commit. * gfortran.dg/coarray_alloc_comp_2.f08: New test. 2016-10-22 Andre Vehreschild PR fortran/43366 PR fortran/57117 PR fortran/61337 * gfortran.dg/alloc_comp_class_5.f03: New test. * gfortran.dg/class_allocate_21.f90: New test. * gfortran.dg/class_allocate_22.f90: New test. * gfortran.dg/realloc_on_assign_27.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03 trunk/gcc/testsuite/gfortran.dg/class_allocate_21.f90 trunk/gcc/testsuite/gfortran.dg/class_allocate_22.f90 trunk/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_27.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug ada/78066] Misleading error message about redundant Dynamic_Predicate incorrectly mentions "Valid"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78066 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-22 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.2.1, 7.0 --- Comment #1 from Eric Botcazou --- > The exact repetition of the range constraint on type T > in its Dynamic_Predicate leads to infinite recursion. > This is as predicted by a warning. However, the warning mentions > attribute Valid, whereas the source has a membership test. It's because the compiler (cleverly?) synthesizes 'Valid out of the test. > Also, the workaround shown in the commented line seems to be > checking membership in the same set of values, but compilation > and program do not exhibit the same behavior. > > (Is infinite recursion acceptable behavior when constraint > and Dynamic_Predicate are identical?) Of course not.
[Bug libstdc++/71322] [DR 2720] std::filesystem::permissions always follows symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71322 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #2 from Jonathan Wakely --- Fixed on trunk at r241418
[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78021 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 22 14:04:46 2016 New Revision: 241440 URL: https://gcc.gnu.org/viewcvs?rev=241440&root=gcc&view=rev Log: 2016-10-22 Thomas Koenig PR fortran/78021 * gfc_compare_functions: Strings with different lengths in argument lists compare unequal. 2016-10-22 Thomas Koenig PR fortran/78021 * gfortran.dg/string_length_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/string_length_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/60487] FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-generate -D_PROFILE_GENERATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60487 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Appears fixed.
[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033 --- Comment #11 from Steve Kargl --- On Sat, Oct 22, 2016 at 12:19:36PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033 > > --- Comment #10 from Dominique d'Humieres --- > > The patch regtested fine but for > > > > FAIL: gfortran.dg/gomp/udr3.f90 -O (test for errors, line 16) > > FAIL: gfortran.dg/gomp/udr3.f90 -O (test for excess errors) > > I have overlooked another failure > > FAIL: gfortran.dg/array_constructor_42.f90 -O (test for excess errors) > > /opt/gcc/work/gcc/testsuite/gfortran.dg/array_constructor_42.f90:15:24: > > vec = (/ real(a = 1), 1. /) > 1 > Error: Invalid type-spec at (1) > /opt/gcc/work/gcc/testsuite/gfortran.dg/array_constructor_42.f90:21:26: > > print *,(/ real(a = 1) /) > 1 > Error: Invalid type-spec at (1) > Yeah, I found that one in my final round of regression testing (ie., clean src/, bootstrap, regression test). What is weird is that the some of the changes in the version of match.c I have is not what I remember last writing to disk. Must have hit an undo edit before saving. The udr3.f90 failure is mystery at the moment.
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #33 from Eric Gallager --- I'm not sure if this is due to the patches from this bug report, or if it's due to some other change made to GCC recently, but my fork of Emacs now fails to build with LTO due to a bunch of undefined local symbols: /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_toggleFullScreen$.lto_priv.1027 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_window.lto_priv.394 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setFSValue$.lto_priv.1033 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_fsIsNative.lto_priv.1034 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidBecomeKey$.lto_priv.1035 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_4.lto_priv.333 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_deleteWorkingText.lto_priv.1043 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_frame.lto_priv.350 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillResize$toSize$.lto_priv.1039 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_screens.lto_priv.474 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_8.lto_priv.431 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_objectAtIndex$.lto_priv.358 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_mouseMoved$.lto_priv.1048 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_mouseDown$.lto_priv.1051 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isFullscreen.lto_priv.1046 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_toolbar.lto_priv.434 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_retain.lto_priv.405 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_release.lto_priv.312 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_subviews.lto_priv.1056 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_count.lto_priv.355 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_class.lto_priv.440 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_15.lto_priv.391 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isKindOfClass$.lto_priv.442 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_condemn.lto_priv.1059 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_judge.lto_priv.1057 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_updateFrameSize$.lto_priv.1032 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_display.lto_priv.399 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_Class_EmacsView.lto_priv.1044 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_viewDidEndLiveResize.lto_priv.1045 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_stringWithUTF8String$.lto_priv.323 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_3.lto_priv.285 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_dealloc.lto_priv.367 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_modifierFlags.lto_priv.472 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_keyDown$.lto_priv.464 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_visibleRect.lto_priv.1053 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_setOnMouseEntered$.lto_priv.1055 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_arrowCursor.lto_priv.480 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_27.lto_priv.1052 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_addCursorRect$cursor$.lto_priv.1054 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_UTF8String.lto_priv.294 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_objectEnumerator.lto_priv.304 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_nextObject.lto_priv.308 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_isEqualToString$.lto_priv.316 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_invalidate.lto_priv.331 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_ClassRefs_17.lto_priv.374 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_context.lto_priv.336 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowNumber.lto_priv.341 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_contentView.lto_priv.353 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillExitFullScreen$.lto_priv.1030 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowDidExitFullScreen$.lto_priv.1031 /var/tmp//ccaoPXbR.s:unknown:Undefined local symbol L_OBJC_SelRef_windowWillEnterFullScreen$.lto_priv.1028 /var/tm
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #34 from Iain Sandoe --- (In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: honestly, rather hard to tell from the info given, please can you identify what you've built (and what version) and on what Darwin etc. > I was figuring it might have something to do with this patch because this > patch messed with the "L_" prefixing of symbols. GCC's LTO worked with my > fork of Emacs a few months ago. yeah, it's possible - although if you look at the logic that adds the "L" onto objc local syms it wasn't touched (and they shouldn't pass equality test with "LC" either). Can you find any reproducer smaller than "emacs" ? I have a current build of 241437 under test with rebased patches and it doesn't show this in the LTO tests in the test-suite. However it might be being hidden by some other error. [I'll re-test with my work-around for instancetype applied].
[Bug c/78075] New: Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 Bug ID: 78075 Summary: Need a way to tell pthread_cancel don't to the forced unwind Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: baiyang at gmail dot com Target Milestone: --- I want pthread_cancel not throw __forced_unwind exception, and there is no need to do the cleanup in our case. e.g.: I just want terminate the thread immediately without ANY cleanup, like the TerminateThread Win32 API. As far as I known, behaviors of the musl-libc and CLang libc are both equal to the TerminateThread API. I understand __forced_unwind is very useful in some cases, but it is clearly unable to adapt to all situations. So could we add a new API, let user set the wanted behavior of pthread_cancel, like: pthread_setcancelmethod(PTHREAD_CANCEL_NO_UNWIND) ?
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 --- Comment #1 from BaiYang --- pthread_exit too, of course.
[Bug tree-optimization/78076] New: [7 Regression] Conditional jump or move depends on uninitialised value @ tree-vect-loop.c:2307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78076 Bug ID: 78076 Summary: [7 Regression] Conditional jump or move depends on uninitialised value @ tree-vect-loop.c:2307 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Created attachment 39868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39868&action=edit unreduced testcase markus@x4 tmp % valgrind --track-origins=yes --trace-children=yes gcc -c -O3 ptio.i ==23766== Memcheck, a memory error detector ==23766== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==23766== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==23766== Command: /var/tmp/gcc_test/usr/local/bin/gcc -c -O3 ptio.i ==23766== ==23779== Memcheck, a memory error detector ==23779== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==23779== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==23779== Command: /var/tmp/gcc_test/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1 -fpreprocessed ptio.i -quiet -dumpbase ptio.i -mtune=generic -march=x86-64 -auxbase ptio -O3 -o /tmp/ccrgJkXg.s ==23779== ==23779== Conditional jump or move depends on uninitialised value(s) ==23779==at 0xDD2F03: vect_analyze_loop(loop*) (tree-vect-loop.c:2307) ==23779==by 0xDEB42D: vectorize_loops() (tree-vectorizer.c:549) ==23779==by 0xA9BCB7: execute_one_pass(opt_pass*) (passes.c:2341) ==23779==by 0xA9C370: execute_pass_list_1(opt_pass*) (passes.c:2430) ==23779==by 0xA9C382: execute_pass_list_1(opt_pass*) (passes.c:2431) ==23779==by 0xA9C382: execute_pass_list_1(opt_pass*) (passes.c:2431) ==23779==by 0xA9C3CC: execute_pass_list(function*, opt_pass*) (passes.c:2441) ==23779==by 0x76F63D: cgraph_node::expand() (cgraphunit.c:2001) ==23779==by 0x770DEB: expand_all_functions (cgraphunit.c:2137) ==23779==by 0x770DEB: symbol_table::compile() [clone .part.47] (cgraphunit.c:2494) ==23779==by 0x7734C4: compile (cgraphunit.c:2587) ==23779==by 0x7734C4: symbol_table::finalize_compilation_unit() (cgraphunit.c:2584) ==23779==by 0xB70A7A: compile_file() (toplev.c:493) ==23779==by 0x5CDAA6: do_compile (toplev.c:2012) ==23779==by 0x5CDAA6: toplev::main(int, char**) (toplev.c:2146) ==23779== Uninitialised value was created by a stack allocation ==23779==at 0xCDBF5C: record_estimate(loop*, tree_node*, generic_wide_int > const&, gimple*, bool, bool, bool) (tree-ssa-loop-niter.c:2976) ==23779==
[Bug tree-optimization/71620] [7 regression] gcc.dg/vect/slp-45.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71620
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-10-22
CC||ebotcazou at gcc dot gnu.org
Summary|gcc.dg/vect/slp-45.c FAILs |[7 regression]
||gcc.dg/vect/slp-45.c FAILs
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
It's probably a duplicate of PR tree-opt/71491, the tests are almost the same:
--- gcc.dg/vect/slp-43.c2016-06-26 09:13:43.642038963 +0200
+++ gcc.dg/vect/slp-45.c2016-06-26 09:13:43.644039025 +0200
@@ -14,8 +14,8 @@
{ \
for (int j = 0; j < N; ++j) \
out[j] = in[j]; \
- in += s*N; \
- out += N; \
+ in += N; \
+ out += s*N; \
} \
}
[Bug testsuite/71491] [7 Regression] gcc.dg/vect/slp-43.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71491 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- PR tree-opt/71620 is probably a duplicate.
[Bug tree-optimization/71264] [5 Regression] ICE in convert_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #19 from Eric Botcazou --- Richard, can you make the testcase compile-only if it cannot be vectorized in the end (except for x86 by chance apparently)?
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #2 from Andrew Pinski --- This api is controlled by glibc, please report it there.
[Bug rtl-optimization/78029] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |7.0 Summary|ICE in |[7 Regression] ICE in |maybe_record_trace_start, |maybe_record_trace_start, |at dwarf2cfi.c:2285 |at dwarf2cfi.c:2285
[Bug lto/64543] gcc fails to build due to undefined references to functions in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-22 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Does this work now?
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #35 from Jack Howarth --- (In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: Did you actually add the patches for this bug report to your local gcc build? The patches haven't been posted to gcc-patches yet or committed into trunk.
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 --- Comment #3 from BaiYang --- (In reply to Andrew Pinski from comment #2) > This api is controlled by glibc, please report it there. Where is it? I need report it again at another bugzilla right?
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 --- Comment #4 from Andrew Pinski --- (In reply to BaiYang from comment #3) > (In reply to Andrew Pinski from comment #2) > > This api is controlled by glibc, please report it there. > > Where is it? I need report it again at another bugzilla right? Yes https://sourceware.org/bugzilla/ :)
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 BaiYang changed: What|Removed |Added Resolution|MOVED |FIXED --- Comment #5 from BaiYang --- (In reply to Andrew Pinski from comment #4) > Yes https://sourceware.org/bugzilla/ > > :) ok, thanks :)
[Bug c/78075] Need a way to tell pthread_cancel don't to the forced unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78075 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |MOVED
[Bug target/78077] New: gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077 Bug ID: 78077 Summary: gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: howarth.at.gcc at gmail dot com Target Milestone: --- The gcc 6.2.0 release fails to link temacs in the build of emacs-25.1 on x86_64-apple-darwin15 using the Xcode 8 linker. Configuring a build as... ../configure --without-ns CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-I/sw/include" LDFLAGS="-L/sw/lib" results in a build that fails at... CCLD temacs 0 0x1097875cc __assert_rtn + 144 1 0x10979a9df mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 3195 2 0x109792536 mach_o::relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 342 3 0x1097d3bac ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 824 4 0x1097d640b ld::tool::InputFiles::parseWorkerThread() + 495 5 0x7fff99bde99d _pthread_body + 131 6 0x7fff99bde91a _pthread_body + 0 A linker snapshot was created at: /tmp/temacs-2016-09-22-161008.ld-snapshot ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-274.1/src/ld/parsers/macho_relocatable_file.cpp, line 1893. collect2: error: ld returned 1 exit status
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #36 from Jack Howarth --- (In reply to Jack Howarth from comment #35) > (In reply to Eric Gallager from comment #33) > > I'm not sure if this is due to the patches from this bug report, or if it's > > due to some other change made to GCC recently, but my fork of Emacs now > > fails to build with LTO due to a bunch of undefined local symbols: > > Did you actually add the patches for this bug report to your local gcc > build? The patches haven't been posted to gcc-patches yet or committed into > trunk. I can't reproduce that particular failure in a build of emacs 25.1 against gcc 6.2.0 (with or without patchiest cf 240230 applied) because I run into a linker bug when linking temacs using the Xcode 8 linker). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
[Bug c/78078] New: error on ATOMIC_VAR_INIT with aggregate initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78078
Bug ID: 78078
Summary: error on ATOMIC_VAR_INIT with aggregate initializer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is the subject of C11 DR 485
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_485). The
ATOMIC_VAR_INIT macro is intended to be used to initialize objects of atomic
types, including structs. Unfortunately, the C specification suggests that the
macro accepts just one argument, making it unsuitable to initialize structs
with more than one member. The test case below shows the problem. As
indicated in the Committee Discussion section of the DR (and soon in the
Suggested Technical Corrigendum), the macro should be defined to take a
variable number of arguments so that code like in the test case below can be
correctly handled.
$ cat b.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall
-Wextra -Wpedantic b.c
#include
struct S { int a, b; };
_Atomic struct S s = ATOMIC_VAR_INIT ({ 1, 2 });
b.c:5:47: error: macro "ATOMIC_VAR_INIT" passed 2 arguments, but takes just 1
_Atomic struct S s = ATOMIC_VAR_INIT ({ 1, 2 });
^
b.c:5:22: error: ‘ATOMIC_VAR_INIT’ undeclared here (not in a function); did you
mean ‘ATOMIC_VAR_INIT’?
_Atomic struct S s = ATOMIC_VAR_INIT ({ 1, 2 });
^~~
ATOMIC_VAR_INIT
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 --- Comment #9 from PeteVine --- It seems the LPATHBench exhibits the same issue. https://raw.githubusercontent.com/logicchains/LPATHBench/master/c_fast.c compiled the following way: gcc -falign-functions=32 -std=gnu99 -O2 -mcpu=cortex-a5 -fomit-frame-pointer -mfpu=neon -ftree-vectorize -ffast-math c_fast.c -o c_fast is faster than a profiled version. (10 runs avg. shows about 4% slowdown) Once again division is present in the profiled assembly: bl __aeabi_idiv
[Bug c/78078] error on ATOMIC_VAR_INIT with aggregate initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78078 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Severity|normal |minor
[Bug c/78078] [DR485] error on ATOMIC_VAR_INIT with aggregate initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78078 Andrew Pinski changed: What|Removed |Added Keywords|rejects-valid | Summary|error on ATOMIC_VAR_INIT|[DR485] error on |with aggregate initializer |ATOMIC_VAR_INIT with ||aggregate initializer Severity|minor |normal
[Bug c/78078] [DR485] error on ATOMIC_VAR_INIT with aggregate initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78078 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2016-10-22 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Suspend until the Defect report gets resolved.
[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077 --- Comment #1 from Jack Howarth --- This Xcode 8 linker failure is suppressed when emacs 25.1 is built at -O0, but occurs for -O1, -O2, -Os and -O3.
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #37 from Jack Howarth --- (In reply to Eric Gallager from comment #33) > I'm not sure if this is due to the patches from this bug report, or if it's > due to some other change made to GCC recently, but my fork of Emacs now > fails to build with LTO due to a bunch of undefined local symbols: This issue exists in stock gcc 6.2.0 on x86_64-apple-darwin15. I can reproduce the issue building emacs 25.1 configured with... ../configure --without-ns --prefix=/Users/howarth/emacs-dist CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-I/sw/include" LDFLAGS="-flto -fno-pie -L/sw/lib" CFLAGS="-O0 -g -fno-pie -flto" which produces a build that fails at... CCLD temacs /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error: assembler local symbol 'L1' not defined ... /var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error: assembler local symbol 'L174' not defined
[Bug c/78079] New: implicit initialization overrides explicit designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78079
Bug ID: 78079
Summary: implicit initialization overrides explicit designated
initializer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In C11 DR 413
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_413) the
committee's resolution clarifies by adding an example the intent already
present in the standard that implicit initialization of struct members doesn't
override their explicit initialization.
When compiled using GCC the added example (below) aborts at runtime when it is
expected to run successfully to completion. (Clang does the right thing and
its output might help illuminate why. See below.)
$ cat b.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic b.c && ./a.out
typedef struct {
int k;
int l;
int a[2];
} T;
typedef struct {
int i;
T t;
} S;
T x = {.l = 43, .k = 42, .a[1] = 19, .a[0] = 18 };
int main (void)
{
S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
if (l.t.k != 42) __builtin_abort ();
}
Aborted (core dumped)
$ /build/llvm-trunk/bin/clang -Wall -Wextra -Wpedantic b.c && ./a.out
b.c:16:30: warning: subobject initialization overrides initialization of other
fields within its enclosing subobject [-Winitializer-overrides]
S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
^~~
b.c:16:25: note: previous initialization is here
S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
^
b.c:16:41: warning: subobject initialization overrides initialization of other
fields within its enclosing subobject [-Winitializer-overrides]
S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
^~
b.c:16:25: note: previous initialization is here
S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
^
2 warnings generated.
[Bug c/63944] [DR#413] Partial overriding of nonconstant struct/union initializers with designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63944 Andrew Pinski changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 78079 has been marked as a duplicate of this bug. ***
[Bug c/78079] [DR413] implicit initialization overrides explicit designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78079 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 63944. *** This bug has been marked as a duplicate of bug 63944 ***
[Bug target/78056] [7 Regression] build failure on Power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #12 from Martin Sebor --- I see the same ICE on RHEL 7.2 with Binutils 2.23.52.0.1-50.el7 20130226 and can confirm that switching to Binutils 2.27 lets the build proceed. Among the changes in auto-host.h between a 2.23 build and the successful 2.27 build that look related to Binutils I see these: HAVE_AS_COMPRESS_DEBUG1 -> 2 HAVE_AS_ENTRY_MARKERS undefined -> 1 HAVE_AS_POWER9undefined -> 1 HAVE_LD_COMPRESS_DEBUG1 -> 3 HAVE_LD_PUSHPOPSTATE_SUPPORT undefined -> 1 LD_COMPRESS_DEBUG_OPTION "" -> "--compress-debug-sections" POWERPC64_TOC_POINTER_ALIGNMENT undefined -> 256
[Bug c++/78080] New: chown command (sys/stat.h) fail to change the owner directory if the return value is not attributed to a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78080
Bug ID: 78080
Summary: chown command (sys/stat.h) fail to change the owner
directory if the return value is not attributed to a
variable.
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rosemberg at ymail dot com
Target Milestone: ---
Hi,
chown command (sys/stat.h) fail to change the owner directory if the return
value is not attributed to a variable.
Supposed the directory /home/user/tochange exists and the program is running
with administrator rights and tochange owner and group is not the same like its
parent directory .
example of success code:
#include
#include
#include
int main()
{
string sPath("/home/user/tochange");
struct stat info;
stat("/home/user",&info);
int iA = chown(sPath.c_str(), info.st_uid, info.st_gid);
cout << iA << endl;
return 0;
}
The result to iA will be 0 (success)
If I change the last 2 lines (before return 0;) to the follow code, the chown
command failed and cout will return -1 (nothing was changed):
cout << chown(sPath.c_str(), info.st_uid, info.st_gid) << endl;
it also happened with if statement.
Best regards,
M.Rosemberg
[Bug target/77837] missing -Wformat-length warning for %p with null argument on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77837 Martin Sebor changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Martin Sebor --- Turns out this was not fixed after all and the submitted patch is still necessary.
[Bug target/78056] [7 Regression] build failure on Power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #13 from Alan Modra ---
Thanks Martin, so it is HAVE_AS_POWER9 being undefined, which then results in
TARGET_P9_VECTOR and others being defined to zero. Kelvin's fix of not
defining the builtins when no power9 support is available sounds right to me
(but best to use derived TARGET_P9_VECTOR etc. rather than HAS_AS_POWER9).
I also think that invoking gcc with -mcpu=power9 ought to complain if
HAVE_AS_POWER9 is not defined, ie. tests like
if (TARGET_P9_VECTOR != ((rs6000_isa_flags & OPTION_MASK_P9_VECTOR) != 0))
error ("-mpower9-vector requires assembler support for power9");
be added to rs6000_override_options.
[Bug c/78081] New: -Wmaybe-initialized false-alarm regression for Emacs regex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78081 Bug ID: 78081 Summary: -Wmaybe-initialized false-alarm regression for Emacs regex.c Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eggert at gnu dot org Target Milestone: --- Created attachment 39869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39869&action=edit test program illustrating -Wmaybe-uninitialized false alarm I found this when compiling a test version of GNU Emacs with gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) on x86-64. The problem does not occur with gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) on x86-64 so this appears to be a regression. The problem caused the Emacs build to fail when configured with --enable-gcc-warnings, when compiling src/regex.c. I reduced the problem case to a relatively small source file u2.i (attached). Compile it with the command: gcc -S -Werror=maybe-uninitialized -O2 u2.i GCC will complain as follows and then fail: u2.i: In function 're_search_2': u2.i:59:42: error: 'offset2' may be used uninitialized in this function [-Werro\ r=maybe-uninitialized] if (string2) string2 = offset2 + new_base; ^~ This diagnostic is incorrect, as offset2 must be initialized, using the same reasoning that offset1 must be initialized (which GCC gets right).
[Bug target/78056] [7 Regression] build failure on Power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #14 from Segher Boessenkool ---
I used the following patch yesterday, and it works. Totally
hacky of course, it should be factored to its own function, etc.
===
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 654206f..667c169 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -17509,6 +17509,8 @@ altivec_init_builtins (void)
def_builtin (d->name, void_ftype_pcvoid_int_int, d->code);
/* Initialize the predicates. */
+if (TARGET_P9_VECTOR)
+{
d = bdesc_altivec_preds;
for (i = 0; i < ARRAY_SIZE (bdesc_altivec_preds); i++, d++)
{
@@ -17549,6 +17551,7 @@ altivec_init_builtins (void)
def_builtin (d->name, type, d->code);
}
+}
/* Initialize the abs* operators. */
d = bdesc_abs;
===
[Bug tree-optimization/78076] [7 Regression] Conditional jump or move depends on uninitialised value @ tree-vect-loop.c:2307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78076
--- Comment #1 from Markus Trippelsdorf ---
int a, b;
void fn1() {
for (; a < 0; ++a) {
b = 0;
for (; b < a; b++)
;
}
}
[Bug c/78082] New: [7 Regression] Conditional jump or move depends on uninitialised value @ c-format.c:3347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78082 Bug ID: 78082 Summary: [7 Regression] Conditional jump or move depends on uninitialised value @ c-format.c:3347 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le-unknown-linux-gnu Build: powerpc64le-unknown-linux-gnu Created attachment 39870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39870&action=edit unreduced testcase On ppc64le: trippels@gcc2-power8 linux % valgrind -q --track-origins=yes --trace-children=yes gcc -c -Wformat cpuacct.i ==126902== Conditional jump or move depends on uninitialised value(s) ==126902==at 0x409811C: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==126902==by 0xB80761F: ??? ==126902==by 0x102A34DB: get_corrected_substring (c-format.c:3347) ==126902==by 0x102A34DB: format_type_warning(substring_loc const&, source_range*, format_wanted_type*, tree_node*, tree_node*, format_kind_info const*, int, char) (c-format.c:3458) ==126902==by 0x102A87EF: check_format_types (c-format.c:3072) ==126902==by 0x102A87EF: argument_parser::check_argument_type(format_char_info const*, length_modifier const&, tree_node*&, char const*&, bool, unsigned long&, tree_node*&, int, char const*, char const*, unsigned int, char) [clone .part.31] (c-format.c:2672) ==126902==by 0x102AA133: check_argument_type (c-format.c:2709) ==126902==by 0x102AA133: check_format_info_main (c-format.c:2817) ==126902==by 0x102AA133: check_format_arg(void*, tree_node*, unsigned long) (c-format.c:1669) ==126902==by 0x10291E9F: check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) (c-common.c:5677) ==126902==by 0x102A515F: check_format_info (c-format.c:1402) ==126902==by 0x102A515F: check_function_format(tree_node*, int, tree_node**) (c-format.c:1063) ==126902==by 0x102927F7: check_function_arguments(unsigned int, tree_node const*, int, tree_node**) (c-common.c:5589) ==126902==by 0x101FD397: build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) (c-typeck.c:3113) ==126902==by 0x1022710F: c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr) (c-parser.c:8458) ==126902==by 0x1021AD37: c_parser_postfix_expression(c_parser*) (c-parser.c:8271) ==126902==by 0x1021E41B: c_parser_unary_expression(c_parser*) (c-parser.c:7089) ==126902== Uninitialised value was created by a heap allocation ==126902==at 0x4096784: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64le-linux.so) ==126902==by 0x112719E3: xrealloc (xmalloc.c:180) ==126902==by 0x11200407: maybe_grow (input.c:435) ==126902==by 0x11200407: read_data (input.c:448) ==126902==by 0x11200407: maybe_read_data(fcache*) (input.c:470) ==126902==by 0x11201033: get_next_line(fcache*, char**, long*) (input.c:487) ==126902==by 0x1120188B: goto_next_line (input.c:611) ==126902==by 0x1120188B: read_line_num (input.c:697) ==126902==by 0x1120188B: location_get_source_line(char const*, int, int*) (input.c:726) ==126902==by 0x1120349B: get_substring_ranges_for_loc(cpp_reader*, string_concat_db*, unsigned int, cpp_ttype, cpp_substring_ranges&) (input.c:1365) ==126902==by 0x1120401B: get_source_location_for_substring(cpp_reader*, string_concat_db*, unsigned int, cpp_ttype, int, int, int, unsigned int*) (input.c:1445) ==126902==by 0x102606F3: c_get_substring_location(substring_loc const&, unsigned int*) (c-common.c:862) ==126902==by 0x108D2A27: substring_loc::get_location(unsigned int*) const (substring-locations.c:194) ==126902==by 0x102A32FB: get_corrected_substring (c-format.c:3305) ==126902==by 0x102A32FB: format_type_warning(substring_loc const&, source_range*, format_wanted_type*, tree_node*, tree_node*, format_kind_info const*, int, char) (c-format.c:3458) ==126902==by 0x102A87EF: check_format_types (c-format.c:3072) ==126902==by 0x102A87EF: argument_parser::check_argument_type(format_char_info const*, length_modifier const&, tree_node*&, char const*&, bool, unsigned long&, tree_node*&, int, char const*, char const*, unsigned int, char) [clone .part.31] (c-format.c:2672) ==126902==by 0x102AA133: check_argument_type (c-format.c:2709) ==126902==by 0x102AA133: check_format_info_main (c-format.c:2817) ==126902==by 0x102AA133: check_format_arg(void*, tree_node*, unsigned long) (c-format.c:1669) ==126902== kernel/sched/cpuacct.c: In function ‘cpuacct_stats_show’: kernel/sched/cpuacct.c:298:25: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] seq_pr
[Bug c++/78083] New: wrong mangling for varargs lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78083
Bug ID: 78083
Summary: wrong mangling for varargs lambdas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
inline int f() {
auto a = [](...) { static int n; return ++n; };
auto b = []() { static int n; return ++n; };
return a() + b();
}
int k = f();
The lambdas should have closure-type-names of UlzE_ and UlvE_ in their
manglings respectively, but GCC mangles the second one incorrectly as UlvE0_.
EDG and (as of a few minutes ago) Clang get this right.
