[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Jeff King changed: What|Removed |Added CC||peff at peff dot net --- Comment #2 from Jeff King --- I can confirm the problem here (as well as a real world case found while building git). I bisected and found that revision 186969 introduces the problem: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=186969
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #7 from Nicholas --- What a pleasant surprise to see your name, Matt. This dropped off my radar for a bit, but I'm pretty close now to getting a properly organized patch ready. Details to follow within 5 days.
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Jun 10 06:05:22 2014 New Revision: 211397 URL: http://gcc.gnu.org/viewcvs?rev=211397&root=gcc&view=rev Log: PR fortran/60928 * omp-low.c (lower_rec_input_clauses) : Set lastprivate_firstprivate even if omp_private_outer_ref langhook returns true. : When calling omp_clause_default_ctor langhook, call unshare_expr on new_var and call build_outer_var_ref to get the last argument. gcc/c-family/ * c-pragma.c (omp_pragmas_simd): Move PRAGMA_OMP_TASK... (omp_pragmas): ... back here. gcc/fortran/ * f95-lang.c (gfc_init_builtin_functions): Handle -fopenmp-simd like -fopenmp. * openmp.c (resolve_omp_clauses): Remove allocatable components diagnostics. Add associate-name and intent(in) pointer diagnostics for various clauses, diagnose procedure pointers in reduction clause. * parse.c (match_word_omp_simd): New function. (matchs, matcho): New macros. (decode_omp_directive): Change match macros to either matchs or matcho. Handle -fopenmp-simd. (next_free, next_fixed): Handle -fopenmp-simd like -fopenmp. * scanner.c (skip_free_comments, skip_fixed_comments, include_line): Likewise. * trans-array.c (get_full_array_size): Rename to... (gfc_full_array_size): ... this. No longer static. (duplicate_allocatable): Adjust caller. Add NO_MEMCPY argument and handle it. (gfc_duplicate_allocatable, gfc_copy_allocatable_data): Adjust duplicate_allocatable callers. (gfc_duplicate_allocatable_nocopy): New function. (structure_alloc_comps): Adjust g*_full_array_size and duplicate_allocatable caller. * trans-array.h (gfc_full_array_size, gfc_duplicate_allocatable_nocopy): New prototypes. * trans-common.c (create_common): Call gfc_finish_decl_attrs. * trans-decl.c (gfc_finish_decl_attrs): New function. (gfc_finish_var_decl, create_function_arglist, gfc_get_fake_result_decl): Call it. (gfc_allocate_lang_decl): If DECL_LANG_SPECIFIC is already allocated, don't allocate it again. (gfc_get_symbol_decl): Set GFC_DECL_ASSOCIATE_VAR_P on associate-names. * trans.h (gfc_finish_decl_attrs): New prototype. (struct lang_decl): Add scalar_allocatable and scalar_pointer bitfields. (GFC_DECL_SCALAR_ALLOCATABLE, GFC_DECL_SCALAR_POINTER, GFC_DECL_GET_SCALAR_ALLOCATABLE, GFC_DECL_GET_SCALAR_POINTER, GFC_DECL_ASSOCIATE_VAR_P): Define. (GFC_POINTER_TYPE_P): Remove. * trans-openmp.c (gfc_omp_privatize_by_reference): Don't check GFC_POINTER_TYPE_P, instead test GFC_DECL_GET_SCALAR_ALLOCATABLE, GFC_DECL_GET_SCALAR_POINTER or GFC_DECL_CRAY_POINTEE on decl. (gfc_omp_predetermined_sharing): Associate-names are predetermined. (enum walk_alloc_comps): New. (gfc_has_alloc_comps, gfc_omp_unshare_expr_r, gfc_omp_unshare_expr, gfc_walk_alloc_comps): New functions. (gfc_omp_private_outer_ref): Return true for scalar allocatables or decls with allocatable components. (gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op, gfc_omp_clause_dtor): Fix up handling of allocatables, handle also OMP_CLAUSE_REDUCTION, handle scalar allocatables and decls with allocatable components. (gfc_trans_omp_array_reduction_or_udr): Don't handle allocatable arrays here. (gfc_trans_omp_reduction_list): Call gfc_trans_omp_array_reduction_or_udr even for allocatable scalars. (gfc_trans_omp_do_simd): If -fno-openmp, just expand it as OMP_SIMD. (gfc_trans_omp_parallel_do_simd): Likewise. * trans-types.c (gfc_sym_type): Don't set GFC_POINTER_TYPE_P. (gfc_get_derived_type): Call gfc_finish_decl_attrs. gcc/testsuite/ * gfortran.dg/gomp/allocatable_components_1.f90: Remove dg-error directives. * gfortran.dg/gomp/associate1.f90: New test. * gfortran.dg/gomp/intentin1.f90: New test. * gfortran.dg/gomp/openmp-simd-1.f90: New test. * gfortran.dg/gomp/openmp-simd-2.f90: New test. * gfortran.dg/gomp/openmp-simd-3.f90: New test. * gfortran.dg/gomp/proc_ptr_2.f90: New test. libgomp/ * testsuite/libgomp.fortran/allocatable9.f90: New test. * testsuite/libgomp.fortran/allocatable10.f90: New test. * testsuite/libgomp.fortran/allocatable11.f90: New test. * testsuite/libgomp.fortran/allocatable12.f90: New test. * testsuite/libgomp.fortran/alloc-comp-1.f90: New test. * testsuite/libgomp.fortran/alloc-comp-2.f90: New test. * testsuite/libgomp.fortran/alloc-comp-3.f90: New test. * testsuite/libgomp.fortran/associate1.f90: New test. * testsuite/libgomp.fortran/associate2.f90: New test. * testsuite/libgomp.fortran/procptr1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/associate1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/intentin1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/openmp-simd-1.f90 trunk/gcc/testsu
[Bug c/61416] incorrect struct tag in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61416 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think dup and/or related to PR56980.
[Bug c/60988] "transparent_union" doesn't appear in the gcc manual index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60988 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c/60988] "transparent_union" doesn't appear in the gcc manual index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60988 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Tue Jun 10 05:09:59 2014 New Revision: 211396 URL: http://gcc.gnu.org/viewcvs?rev=211396&root=gcc&view=rev Log: PR c/60988 * doc/extend.texi: Add cindex for transparent_union. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug fortran/59438] DWARF: Fortran mishandles ALLOCATABLE/ASSOCIATED in debug output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59438 --- Comment #2 from Tobias Burnus --- Regarding (a), see also https://gcc.gnu.org/ml/fortran/2014-06/msg00113.html
[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Dominique d'Humieres from comment #1) > Could you please test the patch at > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02524.html? It works, thanks, my bad for not checking the mailing list. > If it works, could > you pre-approve it? (Nit: nobody can *pre-*approve it, now that it's seen... I guess you've got the terminology confused and ask for the usual approval.) Sorry, I don't have approval powers. Thanks for the quick response though.
[Bug fortran/61459] [4.7/4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-09 CC||pault at gcc dot gnu.org Summary|segfault when assigning to |[4.7/4.8/4.9/4.10 |allocatable function result |Regression] segfault when |from matmul result |assigning to allocatable ||function result from matmul ||result Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- The code gives the expected output up to r167173 (2010-11-26), an ICE from r167380 (2010-12-02) up to r184438 (2012-02-21), and a segmentation fault from r184852 (2012-03-03) up to trunk (4.10.0, r211378). The first change may be due to r167220 (pr35810). The second one may be due to r184651 (pr52386). Both are wild guesses.
[Bug c++/19200] Friend declaration misinterpreted as constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19200 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Known to fail|| --- Comment #3 from Paolo Carlini --- Mine.
[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 --- Comment #6 from fabien at gcc dot gnu.org --- (In reply to Jason Merrill from comment #5) > Any news? I looked into it but did not manage to get it fixed. I will have another try this week. Thanks for the reminder.
[Bug fortran/61459] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- Version 4.5.2 works, version 4.6.0 fails. Clearly a regression.
[Bug c/60988] "transparent_union" doesn't appear in the gcc manual index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60988 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-09 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Looks trivial.
[Bug fortran/61459] New: segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Bug ID: 61459 Summary: segfault when assigning to allocatable function result from matmul result Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: johnww at tds dot net Created attachment 32913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32913&action=edit Output for "gfortran -v -Wall -Wextra -std=f2003" (compiler version 4.7.2) In a function with an allocatable array as result variable, an assigment statement with the result variable on the LHS segfaults when the value assigned is generated by matmul. This behavior is observed with versions 4.7.2, 4.8.0, and 4.9.0. With version 4.6.2, an ICE occurs at the same assignment statement. Similar code worked with version 4.4.5, so there appears to be a regression. The source code below illustrates the problem and shows a workaround. Code like the example which worked with version 4.4.5 started failing when compiled after an OS upgrade (Debian) installed 4.7.2. Coincidentally colleagues using the same code on OS X upgraded from 4.4.x to gfortran 4.8.0 and 4.9.0, and likewise encountered segfaults with new compilations. Since the segfault occurs with multiple versions under two operating systems, I suspect that the problem is not due to something that Debian or whoever packaged the Apple version did. gdb reports that the segfault is detected within matmul. No problem if the result variable is not allocatable. I tried some other intrinsics in place of matmul; no problem. With -Wall -Wextra -std=f2003 there are no warnings, errors, or any other output from the compiler. (In our production code, the arguments to matmul are a slice of an allocatable integer array and an allocatable real(kind=real64) array, but the problem occurs without these embellishments, as the example code shows.) Example source code: module a implicit none private public :: f_segfault, f_workaround integer, dimension(2,2) :: b = reshape([1,-1,1,1],[2,2]) contains function f_segfault(x) real, dimension(:), allocatable :: f_segfault real, dimension(:), intent(in) :: x allocate(f_segfault(2)) f_segfault = matmul(b,x) end function f_segfault function f_workaround(x) real, dimension(:), allocatable :: f_workaround real, dimension(:), intent(in) :: x real, dimension(:), allocatable :: tmp allocate(f_workaround(2),tmp(2)) tmp = matmul(b,x) f_workaround = tmp end function f_workaround end module a program main use a implicit none real, dimension(2) :: x = 1.0 print *, "f_workaround(x) =", f_workaround(x) print *, "f_segfault(x) =", f_segfault(x) end program main
[Bug middle-end/61456] Bogus "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456 --- Comment #3 from Andrew Pinski --- There is some aliasing issue going on here. FRE (correctly) removes: # .MEM_7 = VDEF <.MEM_8> MEM[(struct *)&fp + 8B] = 0; So it was being done by: # .MEM_4 = VDEF <.MEM_3> fp.__delta = 0; Already. Somehow DCE1 decides that is fully dead. >Note that there is no '__delta' in the original source, so the error message Well that is partly the front-end issue as it is pointer to member functions are implemented using a struct.
[Bug c/36446] unexplained warning in struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug c/36446] unexplained warning in struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Mon Jun 9 20:33:51 2014 New Revision: 211388 URL: http://gcc.gnu.org/viewcvs?rev=211388&root=gcc&view=rev Log: PR c/36446 * c-typeck.c (error_init): Call inform instead of error_at. (pedwarn_init): Call inform instead of pedwarn. (warning_init): Call inform instead of warning_at. * gcc.dg/Wcxx-compat-6.c: Change dg-warning to dg-message. * gcc.dg/array-2.c: Likewise. * gcc.dg/array-const-2.c: Likewise. * gcc.dg/ucnid-8.c: Likewise. * gcc.dg/vla-init-1.c: Likewise. * gcc.dg/array-const-3.c: Change dg-error to dg-message. * gcc.dg/c99-flex-array-7.c: Likewise. * gcc.dg/init-bad-1.c: Likewise. * gcc.dg/init-bad-3.c: Likewise. * gcc.dg/init-bad-2.c: Change dg-error and dg-warning to dg-message. * gcc.dg/pedwarn-init.c: Add dg-warning. * gcc.dg/pr53119.c: Remove dg-excess-errors. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Wcxx-compat-6.c trunk/gcc/testsuite/gcc.dg/array-2.c trunk/gcc/testsuite/gcc.dg/array-const-2.c trunk/gcc/testsuite/gcc.dg/array-const-3.c trunk/gcc/testsuite/gcc.dg/c99-flex-array-7.c trunk/gcc/testsuite/gcc.dg/init-bad-1.c trunk/gcc/testsuite/gcc.dg/init-bad-2.c trunk/gcc/testsuite/gcc.dg/init-bad-3.c trunk/gcc/testsuite/gcc.dg/pedwarn-init.c trunk/gcc/testsuite/gcc.dg/pr53119.c trunk/gcc/testsuite/gcc.dg/ucnid-8.c trunk/gcc/testsuite/gcc.dg/vla-init-1.c
[Bug libstdc++/61458] New: std::aligned_storage is bigger than expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458 Bug ID: 61458 Summary: std::aligned_storage is bigger than expected Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org #include static_assert(sizeof(std::aligned_storage<4>::type) == 4, ""); so.cc: In function ‘int main()’: so.cc:5:3: error: static assertion failed: static_assert(sizeof(std::aligned_storage<4>::type) == 4, ""); ^ I think this is conforming, but it would be more useful if it passed. We use the maximum alignment supported for any type, where we should use the maximum alignment supported for types less than 4 bytes
[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532 Jason Merrill changed: What|Removed |Added CC||pubby.8 at gmail dot com --- Comment #4 from Jason Merrill --- *** Bug 51373 has been marked as a duplicate of this bug. ***
[Bug c++/51373] [C++0x] ICE for static pointer to member initialized in-class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51373 Jason Merrill changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Jason Merrill --- Fixed by r196852. *** This bug has been marked as a duplicate of bug 54532 ***
[Bug c++/61457] New: Inaccurately refusing non-ODR usage of type with no linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61457
Bug ID: 61457
Summary: Inaccurately refusing non-ODR usage of type with no
linkage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32912&action=edit
testcase.cpp
enum { X };
struct A { static constexpr auto val = X; };
int main () {
int x = A::val;
}
-
`gcc` is inaccurately rejecting `testcase.cpp` with the following diagnostic:
> testcase.cpp:3:34: error: ‘constexpr const A::val’, declared
> using anonymous type, is used but never defined [-fpermissive]
> struct A { static constexpr auto val = X; };
> ^
-
A detailed answer was provided by me at
http://stackoverflow.com/a/24019645/1090079
It is stated that an unnamed enum has no linkage in [basic.link]p8, but we must
also remember the following which is also stated in [basic.link]p8:
> A type without linkage shall not be used as the type of a variable
> or function with external linkage unless:
>- the entity has C language linkage (7.5), or
>- the entity is declared within an unnamed namespace (7.3.1), or
>- the entity is not odr-used (3.2) or is defined in the same translation
unit
`clang` correctly accepts the snippet.
[Bug c++/61134] [4.7/4.8 Regression][C++11] bogus "no matching function for call..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Jun 9 19:56:21 2014 New Revision: 211387 URL: http://gcc.gnu.org/viewcvs?rev=211387&root=gcc&view=rev Log: PR c++/61134 * pt.c (pack_deducible_p): Handle canonicalization. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/variadic158.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/61134] [4.7/4.8 Regression][C++11] bogus "no matching function for call..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.8.4 --- Comment #4 from Jason Merrill --- Fixed for 4.8.4/4.9.1.
[Bug middle-end/61199] [trans-mem] _cxa_free_exception is not transaction safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199 --- Comment #1 from Jason Merrill --- Since we have a TM wrapper for __cxa_allocate_exception, it seems reasonable to have one for __cxa_free_exception as well. In the testcase, we free the allocated 'bar' exception when the copy constructor throws an 'int' exception, and then the 'int' exception propagates out of foo.
[Bug fortran/61406] [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61406 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- I think that this PR can be closed now. Thanks for the report Adam. Cheers Paul
[Bug c++/61380] [4.8 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61380 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.0 --- Comment #4 from Jason Merrill --- ...and we generally don't fix ice-on-invalid in older releases.
[Bug c++/61343] [C++11] Missing default initialization for class with default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Jun 9 19:29:17 2014 New Revision: 211386 URL: http://gcc.gnu.org/viewcvs?rev=211386&root=gcc&view=rev Log: PR c++/61343 * decl.c (check_initializer): Maybe clear DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/tls/thread_local9.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl.c
[Bug c++/61343] [C++11] Missing default initialization for class with default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.9.1 --- Comment #2 from Jason Merrill --- Fixed for 4.9.1.
[Bug c++/22556] extern array: compatible declaration at function scope refused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22556 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini --- Fixed for 4.10.0.
[Bug c++/22556] extern array: compatible declaration at function scope refused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22556 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Jun 9 19:28:37 2014 New Revision: 211385 URL: http://gcc.gnu.org/viewcvs?rev=211385&root=gcc&view=rev Log: /cp 2014-06-09 Paolo Carlini PR c++/22556 * name-lookup.c (pushdecl_maybe_friend_1): Use comptypes. /testsuite 2014-06-09 Paolo Carlini PR c++/22556 * g++.dg/other/redecl3.C: New. Added: trunk/gcc/testsuite/g++.dg/other/redecl3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59483] A nested lambda fails to find a protected name with qualified name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #4 from Jason Merrill --- Fixed on trunk.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 61148, which changed state. Bug 61148 Summary: Cannot access protected members from a lambda capturing this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61148 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 59483, which changed state. Bug 59483 Summary: A nested lambda fails to find a protected name with qualified name https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/61148] Cannot access protected members from a lambda capturing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61148 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #5 from Jason Merrill --- Fixed on trunk.
[Bug middle-end/61456] Bogus "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
Teresa Johnson changed:
What|Removed |Added
CC||tejohnson at google dot com
--- Comment #2 from Teresa Johnson ---
I have another small test case that manifests as a seg fault at runtime, but I
believe it is likely the same issue.
test.cc:
class MyClass {
public:
virtual void Method1() const {}
virtual void Method2() const {}
virtual ~MyClass() {}
};
int main(void) {
MyClass *d = new MyClass;
struct MethodStruct {
void (MyClass::*method)() const;
};
const MethodStruct kTest[] = {
{&MyClass::Method1},
{&MyClass::Method2},
};
for (int i = 0; i < 2; ++i) {
(d->*kTest[i].method)();
}
delete d;
}
Compiled with "g++ -O2 test.cc -std=gnu++11" it seg faults when trying to
invoke method in the for loop. If I make this change:
22c22,23
< (d->*kTest[i].method)();
---
> const auto ptmf = kTest[i].method;
> (d->*ptmf)();
the test case passes.
I found that the following initializations of the function pointers in kTest
are being eliminated by cddce1, and if that is disabled, then they are
eliminated by dce1:
[test.cc : 19:3] # .MEM_12 = VDEF <.MEM_10>
kTestD.2288[0].methodD.2287.__pfnD.2284 = 1B;
[test.cc : 19:3] # .MEM_13 = VDEF <.MEM_12>
kTestD.2288[0].methodD.2287.__deltaD.2285 = 0;
[test.cc : 19:3] # .MEM_14 = VDEF <.MEM_13>
kTestD.2288[1].methodD.2287.__pfnD.2284 = 9B;
[test.cc : 19:3] # .MEM_15 = VDEF <.MEM_14>
kTestD.2288[1].methodD.2287.__deltaD.2285 = 0;
[Bug middle-end/61456] Bogus "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov --- Google ref: b/15089262 > error: ‘fp.int* (Funcs::* const)()::__delta’ is used uninitialized ... Note that there is no '__delta' in the original source, so the error message is exceedingly confusing to the end user, in addition to being bogus.
[Bug middle-end/61456] New: Unnecesary "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
Bug ID: 61456
Summary: Unnecesary "may be used uninitialized" warning
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
This test case:
problem.cc
==
int rand ();
class Funcs
{
public:
int *f1 ();
int *f2 ();
};
typedef decltype (&Funcs::f1) pfunc;
static int Set (Funcs * f, const pfunc & fp)
{
(f->*fp) ();
}
void
Foo ()
{
pfunc fp = &Funcs::f1;
if (rand ())
fp = &Funcs::f2;
Set (0, fp);
}
compiled with trunk compiler:
g++ ./problem.cc -O2 -std=c++0x -c -Werror=uninitialized
./problem.cc: In function ‘void Foo()’:
./problem.cc:13:15: error: ‘fp.int* (Funcs::* const)()::__delta’ is used
uninitialized in this function [-Werror=uninitialized]
(f->*fp) ();
^
./problem.cc:19:11: note: ‘fp.int* (Funcs::* const)()::__delta’ was declared
here
pfunc fp = &Funcs::f1
With -fdump-tree-all, the dce1 pass is deleting the statement:
fp.__delta = 0;
even though this is later used with the following gimple sequence:
_22 = fp.__delta;
_24 = (struct Funcs *) _22;
iftmp.2_25 (_24);
[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||bviyer at gmail dot com, ||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- cc'ing Balaji since he's done CilkPlus work most recently IIRC.
[Bug c++/22556] extern array: compatible declaration at function scope refused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22556 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 Known to fail|| --- Comment #2 from Paolo Carlini --- Mine.
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- Fixed on trunk.
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Mon Jun 9 16:41:10 2014 New Revision: 211380 URL: http://gcc.gnu.org/viewcvs?rev=211380&root=gcc&view=rev Log: 2014-05-18 John David Anglin PR middle-end/61141 * emit-rtl.c (reset_all_used_flags): In a sequence, check that XVECEXP (pat, 0, i) is an INSN before calling reset_insn_used_flags. (verify_rtl_sharing): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c
[Bug target/61431] Powerpc tests pack01.c and p8vector-int128-2.c fail on little endian power8 systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61431 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Michael Meissner --- Fixed in subversion id 211329 in the Trunk, 211331 in the 4.9 branch, and 211332 in the 4.8 branch.
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #8 from Rich Felker --- There's already the GNU C __alignof__ which is free to do whatever GCC prefers, so I fail to see the usefulness of making _Alignof do something nonstandard (and IMO, utterly illogical) that might conflict with future standards. I would prefer that __Alignof(expr) produce either an error, or __Alignof(__typeof__(expr)).
[Bug c/61447] _Alignof returns incorrect results for some types/archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447 --- Comment #7 from joseph at codesourcery dot com --- I think _Alignof (expr) should, for example, return the larger alignment chosen with _Alignas in the case of a declaration using _Alignas, rather than just being based on the type.
[Bug c++/54442] Const overloads resolution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442 --- Comment #3 from Marc Glisse --- Author: glisse Date: Mon Jun 9 15:07:24 2014 New Revision: 211377 URL: http://gcc.gnu.org/viewcvs?rev=211377&root=gcc&view=rev Log: 2014-06-09 Marc Glisse PR c++/54442 gcc/ * tree.c (build_qualified_type): Use a canonical type for TYPE_CANONICAL. gcc/testsuite/ * g++.dg/pr54442.C: New file. Added: trunk/gcc/testsuite/g++.dg/pr54442.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #8 from Georg Koppen --- While I am still unable to compile/test Firefox 24 with clang trunk I managed to compile it with clang's r196090 which is the one r205695 merged. And there the problem occurs as well. Thus, we know at least that it is not a GCC specific issue. Not sure about the problem in comment 3 yet which is probably better tracked in a different bug. I'll open one as soon as my build machine is not occupied anymore with bisecting the things related to the crash mentioned in the description.
[Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359 --- Comment #2 from Kenneth Platz --- I attempted to build the gcc-4.9.0 release, and it bombs out in libquadmath: gmake[4]: Leaving directory `/nfshomes/platzk/gnu/gcc-build/4.9.0/hppa2.0w-hp-hpux11.23/libffi/include' Making all in testsuite In file included from ../../../../gcc-4.9.0/libquadmath/math/x2y2m1q.c:19:0: ../../../../gcc-4.9.0/libquadmath/quadmath-imp.h:55:3: error: #error "No way!" # error "No way!" This appears to occur when there is no UINT_64 detected. This is on a PA-RISC 2.0 system, so the "unsigned long long" data type is available.
[Bug fortran/61406] [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61406 --- Comment #4 from Paul Thomas --- Author: pault Date: Mon Jun 9 14:45:32 2014 New Revision: 211375 URL: http://gcc.gnu.org/viewcvs?rev=211375&root=gcc&view=rev Log: 2014-06-09 Paul Thomas PR fortran/61406 * trans-stmt.c (trans_associate_var): Check that array constructors are constant for direct reference. 2014-06-09 Paul Thomas PR fortran/61406 * gfortran.dg/associate_17.f90 : New test Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/associate_17.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/trans-stmt.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/61455] Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target||x86_64-unknown-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-09 CC||jgreenhalgh at gcc dot gnu.org Component|middle-end |c++ Ever confirmed|0 |1 --- Comment #1 from jgreenhalgh at gcc dot gnu.org --- Confirmed. Issue is present whether compiling the testcase as a C file or a C++ file. Possibly related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
[Bug regression/61436] [4.10 Regression]: g++.dg/tls/diag-1.C ICE (emutls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61436 --- Comment #3 from Dominique d'Humieres --- > it seems that get_emutls_init_templ_addr just create the comdat too early > and we trigger sanity check that symbols are static and not automatic > variables. > > I have busy day tomorrow, so won't beat if anyone beats me in testing if > this fix works. ... The fix works for me (x86_64-apple-darwin13).
[Bug fortran/61406] [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61406 --- Comment #3 from Paul Thomas --- Author: pault Date: Mon Jun 9 11:55:55 2014 New Revision: 211374 URL: http://gcc.gnu.org/viewcvs?rev=211374&root=gcc&view=rev Log: 2014-06-09 Paul Thomas PR fortran/61406 * trans-stmt.c (trans_associate_var): Check that array constructors are constant for direct reference. 2014-06-09 Paul Thomas PR fortran/61406 * gfortran.dg/associate_17.f90 : New test Added: trunk/gcc/testsuite/gfortran.dg/associate_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61455] New: Internal compiler error, and other confused errors, when using array notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61455 Bug ID: 61455 Summary: Internal compiler error, and other confused errors, when using array notation Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nick.tomlinson at arm dot com Created attachment 32911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32911&action=edit A minimal reproducer When building a simple, though incorrect, CilkPlus program using array notation, it is possible to trigger an internal compiler error. Steps to reproduce [*] Build this file with: g++ -fcilkplus -O3 -c bug.cpp [*] Comment out incorrect_error() and unprintable_error(), and retry. Notes: [*] Observed on ArchLinux with a locally built x86_64 GCC: r211050 (x86_64-unknown-linux-gnu-g++) as an internal fault. [*] Observed on ArchLinux with package maintainer's x86_64 GCC 4.9 (g++) as a confused by previous errors message. [*] I have confirmed the bug is still present in revision r211365. What I expected to happen [*] No internal compiler error. [*] A (non-internal fault) error should be produced for internal_fault(), as it should not be possible to assign an int[2] expression to an int lvalue. [*] The compilation of incorrect_error() should not result in an error suggesting the rhs is an expression of type int. [*] The compilation of unprintable_error() should not result in "not supported by dump_decl" output. What actually happened I get the following output: r211050 gcc output with all three $ x86_64-unknown-linux-gnu-g++ -fcilkplus -O3 -c bug.cpp bug.cpp: In function 'void incorrect_error()': bug.cpp:46:5: error: incompatible types in assignment of 'int' to 'int [2]' b = a[:]; ^ bug.cpp: In function 'void unprintable_error()': bug.cpp:57:8: error: 'b' cannot be scalar when 'a[#'integer_cst' not supported by dump_decl#:#'integer_cst' not supported by dump_decl#:#'integer_cst' not supported by dump_decl#]' is not b = a[:]; ^ bug.cpp: In function 'void internal_fault()': bug.cpp:38:12: internal compiler error: in gimplify_expr, at gimplify.c:8263 int b = a[:]; ^ 0xa03a58 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:8263 0x9ff8b0 gimplify_modify_expr /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:4529 0xa01758 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:7547 0xa05776 gimplify_stmt(tree_node**, gimple_statement_base**) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:5375 0xa13fc9 gimplify_and_add /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:384 0xa13fc9 gimplify_decl_expr /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:1378 0xa02065 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:7740 0xa05776 gimplify_stmt(tree_node**, gimple_statement_base**) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:5375 0xa02303 gimplify_statement_list /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:1431 0xa02303 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:7962 0xa05776 gimplify_stmt(tree_node**, gimple_statement_base**) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:5375 0xa06646 gimplify_bind_expr /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:1098 0xa01d17 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:7744 0xa05776 gimplify_stmt(tree_node**, gimple_statement_base**) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:5375 0xa06f76 gimplify_body(tree_node*, bool) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:8654 0xa07576 gimplify_function_tree(tree_node*) /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/gimplify.c:8807 0x887a37 analyze_function /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/cgraphunit.c:650 0x888ce9 analyze_functions /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/cgraphunit.c:1028 0x88a575 finalize_compilation_unit() /home/nicholas/GCCCilk/native/native/gcc-4.9.0/gcc/cgraphunit.c:2331 0x679aee cp_write_global_declarations() /home/nicholas/GCCC
[Bug fortran/61454] ICE in simplification of initialization expression with array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-09 Blocks||31392 Ever confirmed|0 |1
[Bug fortran/61454] New: ICE in simplification of initialization expression with array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454 Bug ID: 61454 Summary: ICE in simplification of initialization expression with array Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org The following code: integer :: i real, parameter :: arr2(2) = [ 1., 2. ] integer, parameter :: l = ceiling(sum(arr2)) end makes the compiler segfault in expr.c:gfc_check_init_expr(gfc_expr*). The backtrace is as follows: * frame #0: f951`gfc_check_init_expr(gfc_expr*) + 56 at expr.c:1958 frame #1: f951`gfc_check_init_expr(e=0x000141b1da90) + 1053 frame #2: f951`gfc_reduce_init_expr(expr=0x000141b1da90) + 56 at expr.c:2632 frame #3: f951`gfc_match_init_expr(result=0x7fff5fbff668) + 74 at expr.c:2671 frame #4: f951`gfc_match_data_decl() + 3471 at decl.c:2031
[Bug fortran/36096] F2008 Bessel: Documentation/diagnostic errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Francois-Xavier Coudert --- Documentation for BESSEL is fixed, and transformational variants of BESSEL_JN and BESSEL_YN have been implemented since the PR was created. I've checked the other doc issues reported, and they have all been fixed at some point. Thus: closing this issue.
[Bug fortran/33197] Fortran 2008: math functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197 Bug 33197 depends on bug 36096, which changed state. Bug 36096 Summary: F2008 Bessel: Documentation/diagnostic errors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 36096, which changed state. Bug 36096 Summary: F2008 Bessel: Documentation/diagnostic errors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/61062] vzip and vuzp execution tests fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062 --- Comment #5 from Alan Lawrence --- Should be fixed by rev 211369.
[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Could you please test the patch at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02524.html? If it works, could you pre-approve it? If it does not work, could you post the result of grep myBindC bind_c_array_params_2.s w/wo -flto?
[Bug fortran/36096] F2008 Bessel: Documentation/diagnostic errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36096 --- Comment #3 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Jun 9 09:49:01 2014 New Revision: 211368 URL: http://gcc.gnu.org/viewcvs?rev=211368&root=gcc&view=rev Log: PR fortran/36096 * intrinsic.texi: Fix documentation of BESSEL_J0, BESSEL_J1, BESSEL_Y0, and BESSEL_Y1. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug c/36446] unexplained warning in struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #7 from Marek Polacek --- The bogus warning was fixed recently and I'm testing a patch for error/warning -> inform change.
[Bug fortran/45187] ICE with CRAY pointer in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |4.8.5 --- Comment #5 from Francois-Xavier Coudert --- Fixed on trunk, waiting a bit before backporting to 4.9 and 4.8 branches (as per Paul Thomas' request).
[Bug fortran/45187] ICE with CRAY pointer in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187 --- Comment #4 from Francois-Xavier Coudert --- Author: fxcoudert Date: Mon Jun 9 09:25:14 2014 New Revision: 211367 URL: http://gcc.gnu.org/viewcvs?rev=211367&root=gcc&view=rev Log: PR fortran/45187 * trans-decl.c (gfc_create_module_variable): Don't create Cray-pointee decls twice. * gfortran.dg/cray_pointers_10.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/61283] [4.10 regression] SEGV in pass_ipa_comdats::execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61283 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-09 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka --- Mine, seems like the symbol is not removed for reason not seen by the dataflow.
[Bug regression/61436] [4.10 Regression]: g++.dg/tls/diag-1.C ICE (emutls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61436
--- Comment #2 from Jan Hubicka ---
Hi,
it seems that get_emutls_init_templ_addr just create the comdat too early
and we trigger sanity check that symbols are static and not automatic
variables.
I have busy day tomorrow, so won't beat if anyone beats me in testing if
this fix works.
Honza
Index: tree-emutls.c
===
--- tree-emutls.c(revision 211363)
+++ tree-emutls.c(working copy)
@@ -250,10 +250,10 @@ get_emutls_init_templ_addr (tree decl)
DECL_WEAK (to) = DECL_WEAK (decl);
if (DECL_ONE_ONLY (decl))
{
- make_decl_one_only (to, DECL_ASSEMBLER_NAME (to));
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_PUBLIC (to) = TREE_PUBLIC (decl);
DECL_VISIBILITY (to) = DECL_VISIBILITY (decl);
+ make_decl_one_only (to, DECL_ASSEMBLER_NAME (to));
}
else
TREE_STATIC (to) = 1;
