[Bug middle-end/67035] [6 Regression] FAIL: gcc.c-torture/compile/pr54713-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67035 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/67034] [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/67037] [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- gcc-5.2 and current trunk also generate code that segfaults (on cortex-a9).
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #9 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Tue Jul 28 06:54:50 2015 New Revision: 226298 URL: https://gcc.gnu.org/viewcvs?rev=226298root=gccview=rev Log: 2015-07-28 Thomas Preud'homme thomas.preudho...@arm.com PR tree-optimization/66828 * tree-ssa-math-opts.c (perform_symbolic_merge): Change type of inc from int64_t to uint64_t. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- gcc/haifa-sched.c:1164:24 gcc/haifa-sched.c:1442:26 gcc/sched-deps.c:112:20 are caused by the following macro definition in gcc/sched-int.h:243: #define UNKNOWN_DEP_COST (-119)
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 --- Comment #4 from Sujoy ssaraswati at gmail dot com --- (In reply to Markus Trippelsdorf from comment #3) gcc-4.8 isn't supported anymore. I cannot reproduce the issue with 4.9.3 or above. Thanks for checking. Yes, looks like this got fixed with PR65680.
[Bug target/67037] [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-28 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed on arm-none-linux-gnueabihf
[Bug target/67037] [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 Louis Krupp t56xjcu6dh at snkmail dot com changed: What|Removed |Added CC||t56xjcu6dh at snkmail dot com --- Comment #2 from Louis Krupp t56xjcu6dh at snkmail dot com --- Created attachment 36079 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36079action=edit Program to demonstrate the bug and test a patch
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, that doesn't look related to this warning at all. Thanks for checking.
[Bug other/67042] New: gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67042 Bug ID: 67042 Summary: gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: rsandifo at gcc dot gnu.org Target Milestone: --- bootstrap-ubsan shows: ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of 8589934588 by 32 places cannot be represented in type 'long int' ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -1 ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -10 ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -100 ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -1000 ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -113824 ../../gcc/gcc/hwint.h:250:19: runtime error: left shift of negative value -1009647616 ...
[Bug c++/53132] Missing top level in diagnostic's instantiation stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53132 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |INVALID --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Closing.
[Bug c++/67047] GCC accepts ill-formed program with enumerator not representable in uintmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- So the enum is an unsigned type so UINTMAX_MAX +1 is 0 as it is always representable due to the rules of unsigned types and wrapping. Unless I miss-understand how this is supposed to work and the wrapping rules for unsigned types don't come into play.
[Bug c++/67047] GCC accepts ill-formed program with enumerator not representable in uintmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047 --- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com --- It seems like the increment of the enumerator x triggered the use of the following compiler extension: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html This without any error messages. That is not ok! Remember that we used -pedantic-errors.
[Bug target/64375] m32c ICE building newlib in calls.cL3638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375 Yaakov Selkowitz yselkowi at redhat dot com changed: What|Removed |Added CC||yselkowi at redhat dot com --- Comment #1 from Yaakov Selkowitz yselkowi at redhat dot com --- Ditto for 5.2.0 m32c-elf at calls.c:3681.
[Bug c++/67047] New: GCC accepts ill-formed program with enumerator not representable in uintmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047
Bug ID: 67047
Summary: GCC accepts ill-formed program with enumerator not
representable in uintmax_t
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
#include cstdint
#include limits
enum { x = std::numeric_limitsstd::uintmax_t::max(), y };
int main() {}
Compile it with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
No error messages are given. The program is ill-formed by the last sentence of
the third list item of [dcl.enum]p5 (http://eel.is/c++draft/dcl.enum#5) so at
least one error message was expected.
I have tried this with gcc HEAD 6.0.0 20150728 here:
http://melpon.org/wandbox/permlink/8EVR4wM7TqLBTrVG
[Bug c++/67047] GCC accepts ill-formed program with enumerator not representable in uintmax_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67047 --- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com --- (In reply to Andrew Pinski from comment #1) So the enum is an unsigned type so UINTMAX_MAX +1 is 0 as it is always representable due to the rules of unsigned types and wrapping. Unless I miss-understand how this is supposed to work and the wrapping rules for unsigned types don't come into play. Incrementing enumerators never cause wrapping according to the c++ standard. This follows from this part of [dcl.enum]p5 (http://eel.is/c++draft/dcl.enum#5): Otherwise the type of the enumerator is the same as that of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type sufficient to contain the incremented value. If no such type exists, the program is ill-formed. If you test with static_assert(y != 0, ); you can also see that no wrapping has been done. The real cause of the bug can be seen by observing that the following static assert succeeds: static_assert(sizeof (y) sizeof(std::uintmax_t), );
[Bug c++/67019] [c++-concepts] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67019 Casey Carter Casey at Carter dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Casey Carter Casey at Carter dot net --- The fix for PR 67018 seems to have fixed this as well; I can no longer reproduce it with r226327. Moving to resolved until it reoccurs.
[Bug c/66963] __builtin_constant_p and __builtin_choose_expr do not agree on what is a constexpr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66963 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com --- This is by design. __builtin_choose_expr requires an integer constant expression which must be evaluated before the type of the result can be known; __builtin_constant_p is for optimization and evaluates, much later, whether something is folded to a constant (including constant arguments to inline functions).
[Bug c++/67021] [c++-concepts] ICE in finish_member_declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67021 Casey Carter Casey at Carter dot net changed: What|Removed |Added Keywords|ice-on-valid-code | --- Comment #1 from Casey Carter Casey at Carter dot net --- The test case no longer ICEs r226327, but it still fails to compile only when type_traits is included.
[Bug c++/66135] trailing return type error for generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
template typename T
void f()
{
[](auto arg) - decltype(*arg) {};
}
int main() {
fint();
}
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #15 from ktkachov at gcc dot gnu.org --- Yeah, that problem is fixed. Now bootstrap fails due to: gcc/vec.h:307:3: error: attempt to free a non-heap object 'intersecting' [-Werror=free-nonheap-object] ::free (v); ^ But that must be a different problem. Will analyze and file a separate PR...
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 --- Comment #3 from Louis Krupp t56xjcu6dh at snkmail dot com --- Created attachment 36080 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36080action=edit Proposed patch The problem is with substrings of allocatable string components of derived types. The code seems to be trying to get the string length from typespec of the derived type variable instead of from the component. The attached patch gets the component typespec from the reference chain. I don't understand the code well enough to have a lot of confidence in this patch, but it seems like a step in the right direction.
[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-28 Ever confirmed|0 |1
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #8 from Josh Kelley joshkel at gmail dot com --- Adding -mno-mmx prevents the error. Thank you very much for your help.
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #8) Patch submitted as http://reviews.llvm.org/D11552. Wow. Very nice speedup for such a simple patch. Would be great if could be cherry-picked directly.
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
--- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
Actually wait. I think this is invalid and clang is incorrect in not
rejecting it. Because you have a call to a non constexpr in a constexpr
function; does not matter if it is after a return or not.
My program is valid. Just having a call expression with a non-constexpr
function inside the body of a constexpr function is not in it self a reason for
the program to be ill-formed.
The c++ standard is quite permissive about what a function body of a constexpr
function can contain, see [dcl.constexpr]p3
(http://eel.is/c++draft/dcl.constexpr#3).
The program would however be ill-formed with no diagnostics required, if the
constexpr function could never be called without calling the non-constexpr
function. For details, see [dcl.constexpr]p5
(http://eel.is/c++draft/dcl.constexpr#5).
Also the program wold be ill-formed, if the constexpr function needs to be
called when evaluating an expression that needs to be a constant expression,
and that call would result in a call to the non-constexpr function. For
details, see [expr.const]p2 (http://eel.is/c++draft/expr.const#2) (item 2 in
the list).
I choose the return type void to avoid having to return a value in f. The test
case works with int as return type also.
void g() {}
constexpr int f() { return 0; g(); }
int main() {}
Anyways GCC supports the return type void for constexpr functions. Also relaxed
requirements on constexpr functions have been implemented since version 5 of
GCC according to this:
https://gcc.gnu.org/projects/cxx1y.html
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-28 Ever confirmed|0 |1 --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- Patch submitted as http://reviews.llvm.org/D11552.
[Bug tree-optimization/66851] support double reduction in parloops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66851 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from vries at gcc dot gnu.org --- Patch and test-case committed, marking resolved-fixed.
[Bug tree-optimization/66851] support double reduction in parloops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66851 --- Comment #4 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2015-07/msg01090.html Author: vries Date: Tue Jul 28 07:54:04 2015 New Revision: 226300 URL: https://gcc.gnu.org/viewcvs?rev=226300root=gccview=rev Log: Handle double reduction in parloops 2015-07-28 Tom de Vries t...@codesourcery.com * tree-parloops.c (reduc_stmt_res): New function. (initialize_reductions, add_field_for_reduction) (create_phi_for_local_result, create_loads_for_reductions) (create_stores_for_reduction, build_new_reduction): Handle case that reduc_stmt is a phi. (gather_scalar_reductions): Allow double_reduc reductions. * gcc.dg/autopar/uns-outer-4.c: Remove xfail on scan for parallelizing outer loop. * testsuite/libgomp.c/uns-outer-4.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/uns-outer-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/autopar/uns-outer-4.c trunk/gcc/tree-parloops.c trunk/libgomp/ChangeLog
[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 --- Comment #4 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Jul 29 03:45:35 2015 New Revision: 226336 URL: https://gcc.gnu.org/viewcvs?rev=226336root=gccview=rev Log: PR libstdc++/67015 * include/bits/regex_compiler.h (_Compiler::_M_expression_term, _BracketMatcher::_M_add_collating_element): Change signature to make checking the and of bracket expression easier. * include/bits/regex_compiler.tcc (_Compiler::_M_expression_term): Treat '-' as a valid literal if it's at the end of bracket expression. * testsuite/28_regex/algorithms/regex_match/cstring_bracket_01.cc: New testcases. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_compiler.h trunk/libstdc++-v3/include/bits/regex_compiler.tcc trunk/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/cstring_bracket_01.cc
[Bug target/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-29 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Hi Gary, I'll try to reproduce the problem tomorrow.
[Bug c++/66859] [cilk+] internal compiler error: in lower_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66859 JD t at sharklasers dot com changed: What|Removed |Added Known to fail||5.1.0, 5.2.0 --- Comment #1 from JD t at sharklasers dot com --- Same issue in version 5.2.0
[Bug c/66098] #pragma diagnostic 'ignored' not fully undone by pop for strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66098 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||steffen.muething at iwr dot uni-he ||idelberg.de --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 66711 has been marked as a duplicate of this bug. ***
[Bug c/66711] GCC does not correctly restore diagnostic state after pragma GCC diagnostic pop with -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66711 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Dup. Same patch fixes it. Testing it. *** This bug has been marked as a duplicate of bug 66098 ***
[Bug fortran/67044] New: ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67044 Bug ID: 67044 Summary: ICE on valid code Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- I see and ICE with the attached code. $ gfortran -c ice.f90 ice.f90:44:0: allocate( z%f , source=unpck(x)+unpck(y) ) ^ internal compiler error: in aggregate_value_p, bei function.c:2052 0x819313 aggregate_value_p(tree_node const*, tree_node const*) gcc/function.c:2052 0x6fa71a expand_call(tree_node*, rtx_def*, int) gcc/calls.c:2578 0x7dc16a expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) gcc/expr.c:10362 0x7e55c6 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) gcc/expr.c:5398 0x7e6aec expand_assignment(tree_node*, tree_node*, bool) gcc/expr.c:5170 0x709486 expand_call_stmt gcc/cfgexpand.c:2350 0x709486 expand_gimple_stmt_1 gcc/cfgexpand.c:3239 0x709486 expand_gimple_stmt gcc/cfgexpand.c:3400 0x70aa91 expand_gimple_basic_block gcc/cfgexpand.c:5412 0x70ef06 execute gcc/cfgexpand.c:6023 $ gfortran --version GNU Fortran (GCC) 6.0.0 20150727 (experimental) (I see the same problem with versions 5.1.0 and 4.9.2) module m implicit none public :: t_base, unpck private type, abstract :: t_base contains private generic, public :: operator(+) = add procedure(i_add), pass(x), deferred :: add end type t_base type, extends(t_base) :: t_cont class(t_base), allocatable :: f contains procedure, pass(x) :: add = cont_add end type t_cont abstract interface elemental function i_add(x,y) result(z) import :: t_base, t_cont implicit none class(t_base), intent(in) :: x, y type(t_cont) :: z end function i_add end interface contains pure recursive function unpck(x) result(y) class(t_base), intent(in) :: x class(t_base), allocatable :: y end function unpck elemental function cont_add(x,y) result(z) class(t_cont), intent(in) :: x class(t_base), intent(in) :: y type(t_cont) :: z allocate( z%f , source=unpck(x)+unpck(y) ) end function cont_add end module m
[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67043 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Does the testcase you reduced this from end up generating different code?
[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402 Yaakov Selkowitz yselkowi at redhat dot com changed: What|Removed |Added Version|4.9.2 |5.2.0 --- Comment #1 from Yaakov Selkowitz yselkowi at redhat dot com --- Same in 5.2.0, at cfganal.c:1033.
[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67043 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Does the testcase you reduced this from end up generating different code? No. (It was reduced from the Linux kernel: kernel/locking/rtmutex.c).
[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67043 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 36081 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36081action=edit unreduced testcase Unreduced testcase is attached. % gcc --save-temps -c -fno-partial-inlining -O3 -fcompare-debug rtmutex.i gcc: error: rtmutex.i: -fcompare-debug failure
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #22 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #21) Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong. OK, let's try something else. Are you positive transfer.4 is null? I don't see anything that would make it so. If it is transfer.10 that is null, I can see the call to __final_main_T2 that is suspicious; it seems to pass a descriptorless array to an argument expecting a descriptor. Draft patch, seems to fix it diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 218973d..7a9e275 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns, final-ts.type = BT_INTEGER; final-ts.kind = 4; final-attr.artificial = 1; + final-attr.always_explicit = 1; final-attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL; if (ns-proc_name-attr.flavor == FL_MODULE) final-module = ns-proc_name-name;
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #24 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Mikael Morin from comment #22) (In reply to rguent...@suse.de from comment #21) Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong. OK, let's try something else. Are you positive transfer.4 is null? I don't see anything that would make it so. I can confirm that this patch fixes Invalid read of size 8 valgrind memory error for gfortran.dg/class_allocate_18.f90.
[Bug debug/67043] New: [6 Regression] -fcompare-debug failure with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67043
Bug ID: 67043
Summary: [6 Regression] -fcompare-debug failure with -O3
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
% cat test.i
extern void rt_mutex_owner(void);
extern void rt_mutex_deadlock_account_lock(int);
extern void signal_pending(void);
__typeof__(int *) a;
int b;
int
try_to_take_rt_mutex(int p1) {
rt_mutex_owner();
if (b)
return 0;
rt_mutex_deadlock_account_lock(p1);
return 1;
}
void
__rt_mutex_slowlock(int p1) {
int c;
for (;;) {
c = ({
asm( : =r(a));
a;
});
if (try_to_take_rt_mutex(c))
break;
if (__builtin_expect(p1 == 0, 0))
signal_pending();
}
}
% gcc --save-temps -fcompare-debug -O3 -w -c test.i
gcc: error: test.i: -fcompare-debug failure
% diff -u test.gkd test.gk.gkd
--- test.gkd2015-07-28 12:25:03.890035508 +0200
+++ test.gk.gkd 2015-07-28 12:25:03.926034824 +0200
@@ -220,10 +220,10 @@
(code_label # 0 0 5 9 [2 uses])
(note # 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 5 (set (mem/f/c:DI (symbol_ref:DI (a) [flags 0x2] var_decl
# a) [ a+0 S8 A64])
-(reg:DI 3 bx [94])) test.i:19# {*movdi_internal}
+(reg:DI 3 bx [95])) test.i:19# {*movdi_internal}
(nil))
(insn # 0 0 5 (set (reg/f:DI 6 bp [orig:91 D. ] [91])
-(reg:DI 3 bx [94])) test.i:20# {*movdi_internal}
+(reg:DI 3 bx [95])) test.i:20# {*movdi_internal}
(nil))
(call_insn:TI # 0 0 5 (call (mem:QI (symbol_ref:DI (rt_mutex_owner) [flags
0x41] function_decl # rt_mutex_owner) [ rt_mutex_owner S1 A8])
(const_int 0 [0])) test.i:8# {*call}
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 notasas at gmail dot com changed: What|Removed |Added CC||notasas at gmail dot com --- Comment #5 from notasas at gmail dot com --- gcc 4.7.2, 4.8.2, 4.9.3 are also affected.
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #23 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 28 Jul 2015, mikael at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #22 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #21) Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong. OK, let's try something else. Are you positive transfer.4 is null? I don't see anything that would make it so. From inspecting registers and the assembly. The debugger cannot get at the artificial decls. If it is transfer.10 that is null, I can see the call to __final_main_T2 that is suspicious; it seems to pass a descriptorless array to an argument expecting a descriptor. Draft patch, seems to fix it diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 218973d..7a9e275 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns, final-ts.type = BT_INTEGER; final-ts.kind = 4; final-attr.artificial = 1; + final-attr.always_explicit = 1; final-attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL; if (ns-proc_name-attr.flavor == FL_MODULE) final-module = ns-proc_name-name; even better
[Bug middle-end/67027] [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67027 Nathan Sidwell nathan at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-28 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/67027] [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67027 Nathan Sidwell nathan at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell nathan at gcc dot gnu.org --- Fixed in r226310 * gimplify.c (oacc_default_clause): Always set GOVD_MAP if found in outer scope.
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Closing.
[Bug debug/67043] [6 Regression] -fcompare-debug failure with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67043 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-28 CC||thopre01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r223113.
[Bug c++/67048] New: GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67048
Bug ID: 67048
Summary: GCC rejects well-formed program using empty anonymous
enum specifier in a variable declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following well-formed program (prog.cc):
enum {} x;
int main() {}
Compile it with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
The following error message is given. I expected to get no error messages since
the program is well-formed.
prog.cc:1:6: error: ISO C++ forbids empty anonymous enum [-Wpedantic]
enum {} x;
^
I have tried this with gcc HEAD 6.0.0 20150728 here:
http://melpon.org/wandbox/permlink/BXXfLL4WOU5lBOfk
[Bug target/67049] New: sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049 Bug ID: 67049 Summary: sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001 Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yselkowi at redhat dot com Target Milestone: --- Host: x86_64-cygwin Target: sh64-elf Build: x86_64-cygwin The following occurred when building 5.2.0 --target=sh64-elf --without-headers: /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/xgcc -B/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/ -B/usr/sh64-elf/bin/ -B/usr/sh64-elf/lib/ -isystem /usr/sh64-elf/include -isystem /usr/sh64-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../.././gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/. -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/. -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include -o crtbeginS.o -MT crtbeginS.o -MD -MP -MF crtbeginS.dep -fPIC -c /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c: In function ‘deregister_tm_clones’: /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:303:1: internal compiler error: in df_uses_record, at df-scan.c:3001 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Makefile:990: recipe for target 'crtbeginS.o' failed make[4]: *** [crtbeginS.o] Error 1 /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/xgcc -B/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/build/sh64-elf/./gcc/ -B/usr/sh64-elf/bin/ -B/usr/sh64-elf/lib/ -isystem /usr/sh64-elf/include -isystem /usr/sh64-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../.././gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/. -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/. -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../gcc -I/usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../include -o crtendS.o -MT crtendS.o -MD -MP -MF crtendS.dep -fPIC -c /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c: In function ‘__do_global_ctors_aux’: /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/crtstuff.c:708:1: internal compiler error: in df_uses_record, at df-scan.c:3001 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Makefile:993: recipe for target 'crtendS.o' failed make[4]: *** [crtendS.o] Error 1 dest=../../.././gcc/include/tmp$$-unwind.h; \ cp unwind.h $dest; \ chmod a+r $dest; \ sh /usr/src/ports/cross-gcc/cross-gcc-5.2.0-1.x86_64/src/gcc-5.2.0/libgcc/../move-if-change $dest ../../.././gcc/include/unwind.h make[4]: Target 'all' not remade because of errors. make[4]: Leaving directory
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #10 from Alexander alm at sibmail dot ru --- Have you try to examine core (dwarf-4) produced with this gcc configuration? Trying this has no luck with gdb-7.x (it is not working at all) One solution for me is a globally fallback to dwarf-2 (and use gdb 6.3).
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #12 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Wed Jul 29 03:33:10 2015 New Revision: 226335 URL: https://gcc.gnu.org/viewcvs?rev=226335root=gccview=rev Log: 2015-07-28 Bill Schmidt wschm...@linux.vnet.ibm.com PR sanitizer/63927 * sanitizer_common/sanitizer_stacktrace.cc (BufferedStackTrace::FastUnwindStack): Fix code for PowerPC to find the link register at an offset of 16 from the base of the caller's stack frame. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Bill Schmidt wschmidt at gcc dot gnu.org --- Work is complete.
[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tim Shen timshen at gcc dot gnu.org --- Fixed in trunk and gcc5. Mark as fixed.
[Bug target/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 Gary Funck gary at intrepid dot com changed: What|Removed |Added CC||segher at gcc dot gnu.org Component|rtl-optimization|target --- Comment #2 from Gary Funck gary at intrepid dot com --- Regression hunt indicates that following patch, intended to fix PR target/66217, likely caused the regression described above. Author: segher Date: Mon Jul 20 16:30:56 2015 New Revision: 226005 URL: https://gcc.gnu.org/viewcvs?rev=226005root=gccview=rev Log: PR target/66217 * config/rs6000/constraints.md (S, T, t): Delete. Update available letters comment. * config/rs6000/predicates.md (mask_operand, mask_operand_wrap, mask64_operand, mask64_2_operand, any_mask_operand, and64_2_operand, and_2rld_operand): Delete. (and_operand): Adjust. (rotate_mask_operator): New. * config/rs6000/rs6000-protos.h (build_mask64_2_operands, includes_lshift_p, includes_rshift_p, includes_rldic_lshift_p, includes_rldicr_lshift_p, insvdi_rshift_rlwimi_p, extract_MB, extract_ME): Delete. (rs6000_is_valid_mask, rs6000_is_valid_and_mask, rs6000_is_valid_shift_mask, rs6000_is_valid_insert_mask, rs6000_insn_for_and_mask, rs6000_insn_for_shift_mask, rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and, rs6000_emit_2insn_and): New. * config/rs6000/rs6000.c (num_insns_constant): Adjust. (build_mask64_2_operands, includes_lshift_p, includes_rshift_p, includes_rldic_lshift_p, includes_rldicr_lshift_p, insvdi_rshift_rlwimi_p, extract_MB, extract_ME): Delete. (rs6000_is_valid_mask, rs6000_is_valid_and_mask, rs6000_insn_for_and_mask, rs6000_is_valid_shift_mask, s6000_insn_for_shift_mask, rs6000_is_valid_insert_mask, rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and, rs6000_emit_2insn_and): New. (print_operand) 'b', 'B', 'm', 'M', 's', 'S', 'W': Delete. (rs6000_rtx_costs) CONST_INT: Delete mask_operand and mask64_operand handling. NOT: Don't fall through to next case. AND: Handle the various rotate-and-mask cases directly. IOR: Always cost as one insn. * config/rs6000/rs6000.md (splitter for bswap:SI): Adjust. (andmode3): Adjust expander for the new patterns. (andmode3_imm, andmode3_imm_dot, andmode3_imm_dot2, andmode3_imm_mask_dot, andmode3_imm_mask_dot2): Adjust condition. (*andmode3_imm_dot_shifted): New. (*andmode3_mask): Delete, rewrite as ... (andmode3_mask): ... New. (*andmode3_mask_dot, *andmode3_mask_dot): Rewrite. (andsi3_internal0_nomc): Delete. (*andsi3_internal6): Delete. (*andmode3_2insn): New. (insv, insvsi_internal, *insvsi_internal1, *insvsi_internal2, *insvsi_internal3, *insvsi_internal4, *insvsi_internal5, *insvsi_internal6, insvdi_internal, *insvdi_internal2, *insvdi_internal3): Delete. (*rotlmode3_mask, *rotlmode3_mask_dot, *rotlmode3_mask_dot2, *rotlmode3_insert, *rotlmode3_insert_2, *rotlmode3_insert_3, *rotlmode3_insert_4, two splitters for multi-precision shifts, *iormode_mask): New. (extzv, extzvdi_internal, *extzvdi_internal1, *extzvdi_internal2, *rotlsi3_mask, *rotlsi3_mask_dot, *rotlsi3_mask_dot2, *ashlsi3_imm_mask, *ashlsi3_imm_mask_dot, *ashlsi3_imm_mask_dot2, *lshrsi3_imm_mask, *lshrsi3_imm_mask_dot, *lshrsi3_imm_mask_dot2): Delete. (ashrmode3): Delete expander. (*ashrmode3): Rename to ... (ashrmode3): ... This. (ashrdi3_no_power, *ashrdisi3_noppc64be): Delete. (*rotldi3_internal4, *rotldi3_internal5 and split, *rotldi3_internal6 and split, *ashldi3_internal4, ashldi3_internal5 and split, *ashldi3_internal6 and split, *ashldi3_internal7, ashldi3_internal8 and split, *ashldi3_internal9 and split): Delete. (*anddi3_2rld, *anddi3_2rld_dot, *anddi3_2rld_dot2): Delete. (splitter for loading a mask): Adjust. * doc/md.texi (Machine Constraints): Remove q, S, T, t constraints. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/doc/md.texi
[Bug bootstrap/67022] ia64-hpux failed to compile libcpp/charset.c with -O2 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67022 Alexander alm at sibmail dot ru changed: What|Removed |Added CC||alm at sibmail dot ru --- Comment #4 from Alexander alm at sibmail dot ru --- Created attachment 36083 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36083action=edit dwarf-2 by default and other patches also I has add note, so gdb-7.x does'nt work with dwarf-4 output, prodused by this compiller. I add full patch to disable (back to dwarf-2). Don't forget to add --with-dwarf2
[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 --- Comment #5 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Jul 29 04:30:25 2015 New Revision: 226337 URL: https://gcc.gnu.org/viewcvs?rev=226337root=gccview=rev Log: Backport from mainline 2015-07-29 Tim Shen tims...@google.com PR libstdc++/67015 * include/bits/regex_compiler.h (_Compiler::_M_expression_term, _BracketMatcher::_M_add_collating_element): Change signature to make checking the and of bracket expression easier. * include/bits/regex_compiler.tcc (_Compiler::_M_expression_term): Treat '-' as a valid literal if it's at the end of bracket expression. * testsuite/28_regex/algorithms/regex_match/cstring_bracket_01.cc: New testcases. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/regex_compiler.h branches/gcc-5-branch/libstdc++-v3/include/bits/regex_compiler.tcc branches/gcc-5-branch/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/cstring_bracket_01.cc
[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
--- Comment #32 from alalaw01 at gcc dot gnu.org ---
Is the SRA approach going to work? I have hacked up my SRA so that it generates
this:
foo ()
{
int sum;
int i;
const int a[8];
unsigned int i.0_7;
int _8;
unsigned int i.0_19;
bb 2:
MEM[(int[8] *)a] = 0;
MEM[(int[8] *)a + 4B] = 1;
MEM[(int[8] *)a + 8B] = 2;
MEM[(int[8] *)a + 12B] = 3;
MEM[(int[8] *)a + 16B] = 4;
MEM[(int[8] *)a + 20B] = 5;
MEM[(int[8] *)a + 24B] = 6;
MEM[(int[8] *)a + 28B] = 7;
i.0_19 = 0;
if (i.0_19 != 8)
goto bb 3;
else
goto bb 4;
bb 3:
# i_20 = PHI i_10(3), 0(2)
# sum_21 = PHI sum_9(3), 0(2)
_8 = a[i_20];
sum_9 = sum_21 + _8;
i_10 = i_20 + 1;
i.0_7 = (unsigned int) i_10;
if (i.0_7 != 8)
goto bb 3;
else
goto bb 4;
bb 4:
# sum_22 = PHI sum_9(3), 0(2)
a ={v} {CLOBBER};
return sum_22;
}
the vectorizer then transforms to:
...
bb 2:
MEM[(int[8] *)a] = 0;
MEM[(int[8] *)a + 4B] = 1;
MEM[(int[8] *)a + 8B] = 2;
MEM[(int[8] *)a + 12B] = 3;
MEM[(int[8] *)a + 16B] = 4;
MEM[(int[8] *)a + 20B] = 5;
MEM[(int[8] *)a + 24B] = 6;
MEM[(int[8] *)a + 28B] = 7;
bb 3:
# i_20 = PHI 0(2), i_10(4)
# sum_21 = PHI 0(2), sum_9(4)
# ivtmp_19 = PHI 8(2), ivtmp_22(4)
# vectp_a.1_1 = PHI a(2), vectp_a.1_2(4)
# vect_sum_9.4_17 = PHI { 0, 0, 0, 0 }(2), vect_sum_9.4_23(4)
# ivtmp_27 = PHI 0(2), ivtmp_28(4)
vect__8.3_18 = MEM[(int *)vectp_a.1_1];
_8 = a[i_20];
vect_sum_9.4_23 = vect__8.3_18 + vect_sum_9.4_17;
sum_9 = _8 + sum_21;
i_10 = i_20 + 1;
ivtmp_22 = ivtmp_19 - 1;
vectp_a.1_2 = vectp_a.1_1 + 16;
ivtmp_28 = ivtmp_27 + 1;
if (ivtmp_28 2)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
bb 5:
# sum_7 = PHI sum_9(3)
# vect_sum_9.4_24 = PHI vect_sum_9.4_23(3)
stmp_sum_9.5_25 = [reduc_plus_expr] vect_sum_9.4_24;
vect_sum_9.6_26 = stmp_sum_9.5_25 + 0;
a ={v} {CLOBBER};
return vect_sum_9.6_26;
}
and the optimized tree is:
foo ()
{
int vect_sum_9.6;
int stmp_sum_9.5;
vector(4) int vect_sum_9.4;
const vector(4) int vect__8.3;
const int a[8];
bb 2:
MEM[(int[8] *)a] = { 0, 1, 2, 3 };
MEM[(int[8] *)a + 16B] = { 4, 5, 6, 7 };
vect__8.3_20 = MEM[(int *)a];
vect__8.3_18 = MEM[(int *)a + 16B];
vect_sum_9.4_23 = vect__8.3_18 + vect__8.3_20;
stmp_sum_9.5_25 = [reduc_plus_expr] vect_sum_9.4_23;
vect_sum_9.6_26 = stmp_sum_9.5_25;
a ={v} {CLOBBER};
return vect_sum_9.6_26;
}
final assembly is:
ldr q1, .LC1
sub sp, sp, #32
ldr q0, .LC2
add sp, sp, 32
add v0.4s, v0.4s, v1.4s
addvs0, v0.4s
umovw0, v0.s[0]
ret
which is a slight improvement, but not really what we are looking for...
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #17 from ktkachov at gcc dot gnu.org --- (In reply to Marek Polacek from comment #16) Yeah, that doesn't look related to this warning at all. Thanks for checking. Yeah, turns out that was due to a private patch of mine. Clean trunk bootstraps ok. Sorry for the noise.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #4 from ctice at gcc dot gnu.org --- Created attachment 36082 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36082action=edit Tentative patch to fix this issue. I believe the attached patch will fix this problem. I would appreciate it if Eric would confirm that. ChangeLogs: gcc/cp/ChangeLog: * mangle.c : Add vtable-verify.h to include files. (get_mangled_vtable_map_var_name): If the DECL_ASSEMBLER_NAME is anon get the real mangled name for the class instead, and also store the real mangled name in a vector for use later. gcc/ChangeLog: * vtable-verify.c (vtbl_mangled_name_types, vtbl_mangled_name_ids): New global variables. (vtbl_find_mangled_name): New function. (vtbl_register_mangled_name): New function. (vtbl_map_get_node): If DECL_ASSEMBLER_NAME is anon, look up mangled name in mangled name vectors. (find_or_create_vtbl_map_node): Ditto. (var_is_used_for_virtual_call_p): Add recursion_depth parameter; update recursion_depth on function entry; pass it to every recursive call; automatically exit if depth 25 (give up looking at that point). (verify_bb_vtables): Initialize recursion_depth and pass it to var_is_used_for_virtual_call_p. * vtable-verify.h (vtbl_mangbled_name_types, vtbl_mangled_name_ids): New global variable decls. (vtbl_register_mangled_name): New extern function decl. libvtv/ChangeLog: * Makefile.am: Update to match latest tree. * Makefile.in: Regenerate. * testsuite/lib/libvtv: Brought up to date. * vtv_malloc.cc (VTV_DEBUG): Update function call to match renamed function (old bug!). * vtv_rts.cc (debug_functions, debug_init, debug_verify_vtable): Update initializations to work correctly with VTV_DEBUG defined.
[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 pbregener at gmail dot com changed: What|Removed |Added CC||pbregener at gmail dot com --- Comment #11 from pbregener at gmail dot com --- Any intention to include this fix in 5.x?
[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #33 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to alalaw01 from comment #32)
and the optimized tree is:
foo ()
{
int vect_sum_9.6;
int stmp_sum_9.5;
vector(4) int vect_sum_9.4;
const vector(4) int vect__8.3;
const int a[8];
bb 2:
MEM[(int[8] *)a] = { 0, 1, 2, 3 };
MEM[(int[8] *)a + 16B] = { 4, 5, 6, 7 };
vect__8.3_20 = MEM[(int *)a];
vect__8.3_18 = MEM[(int *)a + 16B];
So a missing constant prop here.
vect_sum_9.4_23 = vect__8.3_18 + vect__8.3_20;
Also most likely we don't have much constant folding for this.
stmp_sum_9.5_25 = [reduc_plus_expr] vect_sum_9.4_23;
Or even this.
But once those are resolved, this whole function will resolve itself :).
[Bug rtl-optimization/67045] New: [ICE][PPCLE64] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045
Bug ID: 67045
Summary: [ICE][PPCLE64] internal compiler error: in
choose_multiplier, at expmed.c:3373
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This issue may be related to bug #61047; it refers to a fix made on July 1, and
the regression described below seems to have appeared in the last month/so.
When bootstrapping trunk version 226240, using TARGET_CFLAGS='-O3' we see the
following bootstrap failure on PPCLE64 (gcc112).
/home/gfunck/gcc-trunk/bld/./gcc/xgcc -B/home/gfunck/gcc-trunk/bld/./gcc/
-B/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/bin/
-B/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/include -isystem
/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/sys-include-O2 -g3
-O3 -O2 -O2 -g3 -O3 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc
-I/home/gfunck/gcc-trunk/src/libgcc -I/home/gfunck/gcc-trunk/src/libgcc/.
-I/home/gfunck/gcc-trunk/src/libgcc/../gcc
-I/home/gfunck/gcc-trunk/src/libgcc/../include
-I/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/dpd
-I/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber -DHAVE_CC_TLS -o
decDouble.o -MT decDouble.o -MD -MP -MF decDouble.dep -c
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c
In file included from
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.h:68:0,
from
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c:33:
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decBasic.c: In function
‘__decDoubleFromInt32’:
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDoubleSymbols.h:24:28:
internal compiler error: in choose_multiplier, at expmed.c:3373
#define decDoubleFromInt32 __decDoubleFromInt32
^
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c:58:30: note: in
expansion of macro ‘decDoubleFromInt32’
#define decFloatFromInt32decDoubleFromInt32
^
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decBasic.c:2284:12: note: in
expansion of macro ‘decFloatFromInt32’
decFloat * decFloatFromInt32(decFloat *result, Int n) {
^
As background, one of our builds sets CFLAGS and TARGET_CFLAGS to '-O3', rather
than the default '-O2' for TARGET_CFLAGS. Further checks are set to
'--enable-checking=release'. The config options used were:
CFLAGS='-g3 -O3' \
CXXFLAGS='-g3 -O3' \
../src/configure \
--enable-bootstrap \
--enable-checking=release \
--disable-build-format-warnings \
--enable-languages=c,c++,lto
It may matter that checks are set to 'release'.
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #10) The fix was accepted and committed upstream in the LLVM compiler-rt project. Jakub, is applying this patch to GCC's libsanitizer ok? After proper testing it is preapproved, provided you write ChangeLog entry for it.
[Bug rtl-optimization/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 --- Comment #1 from Gary Funck gary at intrepid dot com --- Additional info, this failed when trying to build the stage 2 target libgcc. make[3]: Leaving directory '/home/gfunck/gcc-trunk/bld/powerpc64le-unknown-linu x-gnu/libgcc' Makefile:15864: recipe for target 'all-stage2-target-libgcc' failed
[Bug c++/67018] [c++-concepts] Failure to partially order function templates by constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67018 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jul 28 20:07:48 2015 New Revision: 226327 URL: https://gcc.gnu.org/viewcvs?rev=226327root=gccview=rev Log: PR c++/67018 * tree.c (cp_tree_equal): Allow local parameters to compare as equivalent even when comparing_specializations. Added: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/req17.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/tree.c
[Bug c++/67018] [c++-concepts] Failure to partially order function templates by constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67018 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/67018] [c++-concepts] Failure to partially order function templates by constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67018
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-07-28
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jason Merrill jason at gcc dot gnu.org ---
Reduced:
template typename T
constexpr bool Val = true;
template class I
concept bool InputIterator() {
return requires (I i) {
requires Val decltype(i++);
};
}
template class I
concept bool ForwardIterator() {
return InputIteratorI() true;
}
templateInputIterator
constexpr bool f() { return false; }
templateForwardIterator
constexpr bool f() { return true; }
static_assert(fint*());
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #10 from Bill Schmidt wschmidt at gcc dot gnu.org --- The fix was accepted and committed upstream in the LLVM compiler-rt project. Jakub, is applying this patch to GCC's libsanitizer ok?
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Brian Taylor from comment #0) The gfortran documentation for the RANDOM_NUMBER and RANDOM_SEED subroutines indicates that they are part of Fortran 95 and later. Well, they are part of Fortran 95 and later standards. In fact, they were included in the Fortran 90 standard. Which is irrelevant as gfortran started life with the ambitions to be a Fortran 95 compiler. You'll note that there isn't a -std=f90 nor -std=f77 mode. In fact, you'll find all intrinsic procedures in the documentation that are listed in the Fortran 95 and that also appear Fortran 90 are listed as Fortran 95 and later. The gfortran documentation for the SRAND subroutine, a GNU extension, includes in the Notes section the following: The Fortran 2003 standard specifies the intrinsic RANDOM_SEED to initialize the pseudo-random numbers generator and RANDOM_NUMBER to generate pseudo-random numbers. The reference here should be to the Fortran 90 standard, not 2003. Yeah, this could use some word smithing. It appears to be an attempt to discourage use of srand and rand in favor of the standard intrinsic subprograms. You also left out the most incorrect part of the documentation. gfortran uses 4 independent KISS generators, but implementation details should probably be removed here.
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- gcc-4.8 isn't supported anymore. I cannot reproduce the issue with 4.9.3 or above.
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Thomas Preud'homme from comment #7) (In reply to Thomas Preud'homme from comment #6) Created attachment 36078 [details] Use unsigned type for inc to have defined left shift Sorry for the delay, I got busy on some other bugs. Would you mind giving the patch attached to the PR a go? I tried reproducing the issue but couldn't. I did ran the regression testsuite though and it's all good. Well, the fix is obvious. So I would just commit it.
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Eric Niebler from comment #9) Jason, is there anything I can do in my code to avoid the quadratic explosion while we wait for Andrew to fix the bug? In concepts, !(A B) is not equivalent to !A || !B because the former is a single predicate, while the latter is a disjunction. So, converting A || B to !(!A !B) will avoid the explosion at the cost of limiting subsumption.
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #15) So, converting A || B to !(!A !B) will avoid the explosion at the cost of limiting subsumption. Or even !!(A || B).
[Bug preprocessor/67046] New: Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
Bug ID: 67046
Summary: Segmentation fault when a preprocessor directive
follows the argument to _Pragma
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: dsabogal.ufl at gmail dot com
Target Milestone: ---
This issue arises from the following (intricate) code. It works when the string
literal doesn't new begin on a newline.
Failing
===
_Pragma(
message(\msg\)
#
)
int main(void) { return 0; }
Working
===
_Pragma(message(\msg\)
#
)
int main(void) { return 0; }
Output
==
$ gcc -E test.c
# 1 test.c
# 1 built-in
# 1 command-line
# 1 /usr/include/stdc-predef.h 1 3 4
# 1 command-line 2
# 1 test.c
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
Version
===
This issue occurs on the few compilers that I've tried (4.9.2 and 5.2.0).
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC)
