[Bug c++/60803] Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Which template argument deduction should be take, B or A?
[Bug c++/60803] Trivial example of overloading in the presence of inheritance fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60803 --- Comment #3 from Eric Niebler eric.niebler at gmail dot com --- B
[Bug c/54554] Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554 --- Comment #9 from Dominik Muth dominik.muth at gmx dot de --- Please note that in Bug 60791 no warning is given even with -O3 (except when using a legacy version of gcc).
[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:45:21 2014 New Revision: 209262 URL: http://gcc.gnu.org/viewcvs?rev=209262root=gccview=rev Log: Backport from mainline 2014-03-06 Jakub Jelinek ja...@redhat.com Meador Inge mead...@codesourcery.com PR target/58595 * config/arm/arm.c (arm_tls_symbol_p): Remove. (arm_legitimize_address): Call legitimize_tls_address for any arm_tls_referenced_p expression, handle constant addend. Call it before testing for !TARGET_ARM. (thumb_legitimize_address): Don't handle arm_tls_symbol_p here. 2014-03-06 Jakub Jelinek ja...@redhat.com PR target/58595 * gcc.dg/tls/pr58595.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/tls/pr58595.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/36282] [4.7/4.8 Regression] Spurious warning asm declaration ignored due to conflict with previous rename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:47:55 2014 New Revision: 209263 URL: http://gcc.gnu.org/viewcvs?rev=209263root=gccview=rev Log: Backport from mainline 2014-03-13 Jakub Jelinek ja...@redhat.com PR middle-end/36282 * c-pragma.c (apply_pragma_weak): Only look at TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) if DECL_ASSEMBLER_NAME_SET_P (decl). (maybe_apply_pending_pragma_weaks): Exit early if vec_safe_is_empty (pending_weaks) rather than only when !pending_weaks. (maybe_apply_pragma_weak): Likewise. If !DECL_ASSEMBLER_NAME_SET_P, set assembler name back to NULL afterwards. * c-c++-common/pr36282-1.c: New test. * c-c++-common/pr36282-2.c: New test. * c-c++-common/pr36282-3.c: New test. * c-c++-common/pr36282-4.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-1.c branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-2.c branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-3.c branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr36282-4.c Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c-pragma.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/60516] [4.7/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:49:02 2014 New Revision: 209264 URL: http://gcc.gnu.org/viewcvs?rev=209264root=gccview=rev Log: Backport from mainline 2014-03-17 Jakub Jelinek ja...@redhat.com PR target/60516 * config/i386/i386.c (ix86_expand_epilogue): Adjust REG_CFA_ADJUST_CFA note creation for the 2010-08-31 changes. * gcc.target/i386/pr60516.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr60516.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug debug/60603] [4.7/4.8 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:51:52 2014 New Revision: 209265 URL: http://gcc.gnu.org/viewcvs?rev=209265root=gccview=rev Log: Backport from mainline 2014-03-22 Jakub Jelinek ja...@redhat.com PR debug/60603 * c-opts.c (c_finish_options): Restore cb_file_change call to built-in. * cpp.c (gfc_cpp_init): Restore cb_change_file call to built-in. * gcc.dg/debug/dwarf2/dwarf2-macro2.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-macro2.c Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c-opts.c branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/cpp.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:54:08 2014 New Revision: 209267 URL: http://gcc.gnu.org/viewcvs?rev=209267root=gccview=rev Log: Backport from mainline 2014-03-28 Jakub Jelinek ja...@redhat.com PR c++/60689 * c-tree.h (c_build_function_call_vec): New prototype. * c-typeck.c (build_function_call_vec): Don't call resolve_overloaded_builtin here. (c_build_function_call_vec): New wrapper function around build_function_call_vec. Call resolve_overloaded_builtin here. (convert_lvalue_to_rvalue, build_function_call, build_atomic_assign): Call c_build_function_call_vec instead of build_function_call_vec. * c-parser.c (c_parser_postfix_expression_after_primary): Likewise. * c-decl.c (finish_decl): Likewise. * c-common.c (add_atomic_size_parameter): When creating new params vector, push the size argument first. * c-c++-common/pr60689.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr60689.c Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c-common.c branches/gcc-4_8-branch/gcc/c/ChangeLog branches/gcc-4_8-branch/gcc/c/c-decl.c branches/gcc-4_8-branch/gcc/c/c-parser.c branches/gcc-4_8-branch/gcc/c/c-tree.h branches/gcc-4_8-branch/gcc/c/c-typeck.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 07:57:09 2014 New Revision: 209268 URL: http://gcc.gnu.org/viewcvs?rev=209268root=gccview=rev Log: Backport from mainline 2014-03-28 Jakub Jelinek ja...@redhat.com PR target/60693 * config/i386/i386.c (ix86_copy_addr_to_reg): Call copy_addr_to_reg also if addr has VOIDmode. * gcc.target/i386/pr60693.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr60693.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/60516] [4.7 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 regression]: |[4.7 regression]: cc1plus |cc1plus crashes compiling a |crashes compiling a method |method with a huge struct |with a huge struct as |as argument |argument --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed also for 4.8.3+.
[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8.3+.
[Bug middle-end/36282] [4.7 Regression] Spurious warning asm declaration ignored due to conflict with previous rename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.3 Summary|[4.7/4.8 Regression]|[4.7 Regression] Spurious |Spurious warning asm |warning asm declaration |declaration ignored due to |ignored due to conflict |conflict with previous |with previous rename |rename | --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed also for 4.8.3+.
[Bug debug/60603] [4.7 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.3 Summary|[4.7/4.8 Regression]|[4.7 Regression] |.debug_macinfo/.debug_macro |.debug_macinfo/.debug_macro |has wrong line numbers for |has wrong line numbers for |built-in macros |built-in macros --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8.3+ too.
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #16 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Thu Apr 10 08:13:30 2014 New Revision: 209269 URL: http://gcc.gnu.org/viewcvs?rev=209269root=gccview=rev Log: Fix PR debug/60655 part 2. 2014-04-10 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR debug/60655 * config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define (arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's ameliorating the cases where it can be. 2014-04-10 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR debug/60655 * gcc.c-torture/compile/pr60655-2.c: Copy from pr60655-1.c without -fdata-sections. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr60655-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #10 from Akim Demaille akim.demaille at gmail dot com ---
Well, I have finally found a simple workaround for some of the cases: GCC seems
to be right in the order of evaluation when initializing an array so:
templateint... IS
int f1()
{
int i = 0;
swallow{ i = 10 * i + IS... };
return i;
}
fails, but
templateint... IS
int f2()
{
using swallow = int[];
int i = 0;
(void) swallow{ i = 10 * i + IS... };
return i;
}
succeeds. However, GCC's own libstdc++ is exposed to this bug, for instance
make_tuple.
$ cat foo.cc
#include iostream
#include tuple
struct swallow
{
templatetypename... Types
swallow(Types ...){}
};
int incr()
{
static int res = 2;
return res++;
}
templateint... IS
int f1()
{
int i = 0;
swallow{ i = 10 * i + IS... };
return i;
}
templateint... IS
int f2()
{
using swallow = int[];
int i = 0;
(void) swallow{ i = 10 * i + IS... };
return i;
}
int main()
{
// `i = i * 2 + 2' should be sequenced before `i = i * 3 + 3'
std::cerr f12, 3() '\t';
std::cerr f22, 3() '\t';
auto t = std::make_tuple(incr(), incr());
std::cerr std::get0(t) std::get1(t) '\n';
}
$ ./a.32
232323
$ ./a.33
232323
$ ./a.34
232323
$ ./a.35
232323
$ ./a.48
322332
$ ./a.49
322332
where 32...35 is clang++, and 48,49 is gcc.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to H.J. Lu from comment #8) (In reply to H.J. Lu from comment #7) (In reply to Igor Zamyatin from comment #6) Yes, I was going to post it after complete testing You should set DECL_SEEN_IN_BIND_EXPR_P when setting DECL_CONTEXT, similar to gimple_add_tmp_var. Or we can use create_tmp_var. That is much better idea, it will handle tons of other things, like setting DECL_ARTIFICIAL/DECL_IGNORED_P flags etc. In C++ FE, cp-array-notation.c apparently uses get_temp_regvar, which is also fine (but only defined in C++ FE).
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug debug/60805] New: Validate const expressions created by var-tracking / debug information across targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60805 Bug ID: 60805 Summary: Validate const expressions created by var-tracking / debug information across targets. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org While fixing PR60655 Jakub noted that the problem really was that var-tracking and debug info generation can play a bit fast and loose in the types of expressions that are generated. Particularly the problem is when const expressions involving sym_refs are created, targets need to be able to handle / given a chance to decide on what kinds of expressions are valid and what not. Additionally const_ok_for_output_1 and friends in dwarf2out.c don't necessarily have the entire information on this and require some guess work in this. For 4.10 we need to instrument the compiler to produce some traces of the typical kinds of debug expressions that are generated, for a variety of targets and attempt to handle these in a common manner and only allow the basic common subset and possibly allowing targets to enable further constants to be generated.
[Bug testsuite/60806] New: libstdc++ abi check should ignore missing TLS symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60806 Bug ID: 60806 Summary: libstdc++ abi check should ignore missing TLS symbols Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org baseline_symbols.txt is expected not to contain TLS symbols so that libstdc++ abi check won't complain about them missing in --disable-tls configurations. This is error prone since people forget to remote them from baseline_symbols.txt when updating it. The abi check should go the other way and ignore missing TLS symbols instead of ignoring added TLS symbols.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #10 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to Jakub Jelinek from comment #9) (In reply to H.J. Lu from comment #8) (In reply to H.J. Lu from comment #7) (In reply to Igor Zamyatin from comment #6) Yes, I was going to post it after complete testing You should set DECL_SEEN_IN_BIND_EXPR_P when setting DECL_CONTEXT, similar to gimple_add_tmp_var. Or we can use create_tmp_var. That is much better idea, it will handle tons of other things, like setting DECL_ARTIFICIAL/DECL_IGNORED_P flags etc. In C++ FE, cp-array-notation.c apparently uses get_temp_regvar, which is also fine (but only defined in C++ FE). Yes, I tried create_tmp_var but it was undefined so I thought it's not a good idea... Will try further with it then
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #15) This patch fixes the ICE by copying forced_by_abi as part of cgraph fixup in ipa visibility. I would like Jason to comment on this. I think fix at C++ FE side would be more appropriate if the thunk is indeed keyed. If not, I will update partitinoning predicate to always iterate the whole group and see if any of symbols is keyed. Index: ipa.c === --- ipa.c (revision 209170) +++ ipa.c (working copy) @@ -1032,6 +1032,7 @@ function_and_variable_visibility (bool w == DECL_COMDAT_GROUP (decl_node-decl)); gcc_checking_assert (node-same_comdat_group); } + decl_node-forced_by_abi = node-forced_by_abi; if (DECL_EXTERNAL (decl_node-decl)) DECL_EXTERNAL (node-decl) = 1; } Shouldn't that be the other way around though? node-forced_by_abi = decl_node-forced_by_abi; From what I understand, decl_node is the target of the thunk, and node is thunk, on this testcase decl_node-forced_by_abi is true originally, while node-forced_by_abi is false. So, if the thunks are supposed to inherit the flag from the thunk target, we should change node-forced_by_abi, similarly how we e.g. change DECL_EXTERNAL (node-decl).
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- You need to include gimple-expr.h header for that. But, if you look e.g. at c/c-typeck.c or c-family/cilk.c, it is already used in the FEs.
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- By the C++ FE change, do you mean something like: --- gcc/cp/method.c.jj2014-03-27 08:06:11.0 +0100 +++ gcc/cp/method.c2014-04-10 10:59:36.226288999 +0200 @@ -387,6 +387,7 @@ use_thunk (tree thunk_fndecl, bool emit_ thunk_node = cgraph_add_thunk (funcn, thunk_fndecl, function, this_adjusting, fixed_offset, virtual_value, virtual_offset, alias); + thunk_node-forced_by_abi = funcn-forced_by_abi; if (DECL_ONE_ONLY (function)) symtab_add_to_same_comdat_group (thunk_node, funcn); (which fixes this testcase too, but otherwise untested so far), or say change cgraph_add_thunk so that it has node-forced_by_abi = decl_node-forced_by_abi; (also untested).
[Bug fortran/60795] [4.7/4.8/4.9 Regression] Wrong length when allocating character array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795 --- Comment #4 from Kergonath kergonath at me dot com --- The slightly modified version: module m contains subroutine allocate_array(s_array) character(:), dimension(:), allocatable, intent(out) :: s_array allocate(character(2) :: s_array(10)) write(*,*) len(s_array), size(s_array) end subroutine end module program stringtest use m character(:), dimension(:), allocatable :: s4 call allocate_array(s4) write(*,*) len(s4), size(s4) end program gives the result: 0 10 0 10 when compiled with: gfortran -o stringtest stringtest.f90 but gives 0 10 32767 10 when using the -pg option. Using -Wall does only show the following warning, which looks similar to that in PR56670: stringtest.f90: In function 'allocate_array': stringtest.f90:7:0: warning: '.s_array' may be used uninitialized in this function [-Wmaybe-uninitialized] write(*,*) len(s_array), size(s_array) ^
[Bug tree-optimization/60502] [4.8 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 09:35:39 2014 New Revision: 209274 URL: http://gcc.gnu.org/viewcvs?rev=209274root=gccview=rev Log: Backport from mainline 2014-03-12 Jakub Jelinek ja...@redhat.com Marc Glisse marc.gli...@inria.fr PR tree-optimization/60502 * tree-ssa-reassoc.c (eliminate_not_pairs): Use build_all_ones_cst instead of build_low_bits_mask. * gcc.c-torture/compile/pr60502.c: New test. 2013-06-13 Marc Glisse marc.gli...@inria.fr * tree.c (build_all_ones_cst): New function. * tree.h (build_all_ones_cst): Declare it. 2013-05-10 Marc Glisse marc.gli...@inria.fr * tree.c (build_minus_one_cst): New function. * tree.h (build_minus_one_cst): Declare new function. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-reassoc.c branches/gcc-4_8-branch/gcc/tree.c branches/gcc-4_8-branch/gcc/tree.h
[Bug tree-optimization/60502] [4.8 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.3 Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8.3+ too.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #21 from John Marino gnugcc at marino dot st ---
Hi Eric,
When I tried to build the ARMv5 cross compiler (-march=armv5te) I get the
following error:
/tmp//cc5BKnWK.s: Assembler messages:
/tmp//cc5BKnWK.s:31: Error: selected processor does not support Thumb mode
`stmfd sp!,{r2,r3,lr}'
/tmp//cc5BKnWK.s:46: Error: lo register required -- `ldmfd sp,{r2,r3,pc}'
gmake[8]: *** [sigtramp-armdroid.o] Error 1
Does this mean effectively nothing lower than ARMv7 can build
arm-*-linux-androideabi? I don't know which ARM arch supports ldmfd
sp,{r2,r3,pc} but I assume ARMv5 and lower doesn't.
John
[Bug c++/60807] New: internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 Bug ID: 60807 Summary: internal compiler error (basic_string.tcc) Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tk at giga dot or.at Created attachment 32578 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32578action=edit Result of -save-temps When compiling gambatte r550 (http://sourceforge.net/projects/gambatte/files/gambatte/r550/gambatte_src-r550.tar.gz) on NetBSD-6.99.40/amd64 with the g++ coming with that version of NetBSD, a file in libgambatte/ triggers an internal compiler error: # g++ -v -save-temps -o src/cpu.o -c -Wall -Wextra -O2 -fomit-frame-pointer -fno-exceptions -fno-rtti -DHAVE_STDINT_H -Isrc -Iinclude -I/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common src/cpu.cpp Using built-in specs. COLLECT_GCC=g++ Target: x86_64--netbsd Configured with: /usr/src6/tools/gcc/../../external/gpl3/gcc/dist/configure --target=x86_64--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb1 20120916' --with-system-zlib --enable-__cxa_atexit --with-tune=nocona --with-mpc-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/amd64-x86_64/usr/src6/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src6/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src6/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src6/external/lgpl3/gmp/lib/libgmp/arch/x86_64 --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd6.0. --host=x86_64--netbsd --with-sysroot=/var/obj/mknative/amd64-x86_64/usr/src6/destdir.amd64 Thread model: posix gcc version 4.8.3 (NetBSD nb2 20140304) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'src/cpu.o' '-c' '-Wall' '-Wextra' '-O2' '-fomit-frame-pointer' '-fno-exceptions' '-fno-rtti' '-D' 'HAVE_STDINT_H' '-I' 'src' '-I' 'include' '-I' '/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common' '-shared-libgcc' '-mtune=nocona' '-march=x86-64' /usr/libexec/cc1plus -E -quiet -v -I src -I include -I /disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common -D HAVE_STDINT_H src/cpu.cpp -mtune=nocona -march=x86-64 -Wall -Wextra -fomit-frame-pointer -fno-exceptions -fno-rtti -O2 -fpch-preprocess -o cpu.ii #include ... search starts here: #include ... search starts here: src include /disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common /usr/include/g++ /usr/include/g++/backward /usr/include/gcc-4.8 /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'src/cpu.o' '-c' '-Wall' '-Wextra' '-O2' '-fomit-frame-pointer' '-fno-exceptions' '-fno-rtti' '-D' 'HAVE_STDINT_H' '-I' 'src' '-I' 'include' '-I' '/disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common' '-shared-libgcc' '-mtune=nocona' '-march=x86-64' /usr/libexec/cc1plus -fpreprocessed cpu.ii -quiet -dumpbase cpu.cpp -mtune=nocona -march=x86-64 -auxbase-strip src/cpu.o -O2 -Wall -Wextra -version -fomit-frame-pointer -fno-exceptions -fno-rtti -o cpu.s GNU C++ (NetBSD nb2 20140304) version 4.8.3 (x86_64--netbsd) compiled by GNU C version 4.2.1 Compatible Clang 3.5 (trunk 202566), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (NetBSD nb2 20140304) version 4.8.3 (x86_64--netbsd) compiled by GNU C version 4.2.1 Compatible Clang 3.5 (trunk 202566), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4054f87540345d4e138a62067c6e8c30 In file included from /usr/include/g++/string:53:0, from include/loadres.h:4, from src/mem/cartridge.h:22, from src/memory.h:22, from src/cpu.h:22, from src/cpu.cpp:19: /usr/include/g++/bits/basic_string.tcc: In copy constructor ‘std::basic_string_CharT, _Traits, _Alloc::basic_string(const std::basic_string_CharT, _Traits, _Alloc)’: /usr/include/g++/bits/basic_string.tcc:173:26: internal compiler error: Segmentation fault __str.get_allocator()) ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See http://www.NetBSD.org/Misc/send-pr.html for instructions. Starting cc1plus in gdb gives the following backtrace: (gdb) r -quiet -v -I src -I include -I /disk/3/archive/obj/wip/gambatte-dev/work.x86_64/gambatte_src-r550/common -D HAVE_STDINT_H src/cpu.cpp -quiet -dumpbase cpu.cpp -mtune=nocona
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #1 from Thomas Klausner tk at giga dot or.at --- This was first filed in the NetBSD bug tracker at http://gnats.netbsd.org/48731 where it was suggested to file this upstream.
[Bug ada/60411] Ada bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
When I tried to build the ARMv5 cross compiler (-march=armv5te) I get the
following error:
/tmp//cc5BKnWK.s: Assembler messages:
/tmp//cc5BKnWK.s:31: Error: selected processor does not support Thumb mode
`stmfd sp!,{r2,r3,lr}'
/tmp//cc5BKnWK.s:46: Error: lo register required -- `ldmfd sp,{r2,r3,pc}'
gmake[8]: *** [sigtramp-armdroid.o] Error 1
Does this mean effectively nothing lower than ARMv7 can build
arm-*-linux-androideabi?
Apparently so, but it should be quite easy to fix this in sigtramp-armdroid.c
by means of some preprocessor magic.
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org Severity|major |normal --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I cannot reproduce this ICE.
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Can't reproduce this on Linux/x86_64.
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-10 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Can't reproduce this, supposedly starting with r208382 when this is rejected as invalid use of _Cilk_spawn. So, do you have any testcases that ICE even with current trunk?
[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- Unfortunately, I could not replicate this with -Ofast -ffast-math (isn't -ffast-math part of -Ofast?) and trunk revision 209179.
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Doesn't ICE anymore in mainline. I'm adding the testcase and closing the bug.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #12) Also, perhaps to make the change conservative enough for 4.9, might be best to not append anything now, and only look at DECL_ABSTRACT_ORIGIN (recurse on it) if !DECL_LANG_SPECIFIC. More verbose printing can be perhaps deferred for stage1. I agree, mostly because... (In reply to Manuel López-Ibáñez from comment #13) It is not clear to me why you want to print clone at all. It is an internal detail. ...just printing clone really provides fairly little value. If we (hopefully from the next version on) manage to print details about properties of the particular clone, it will become useful.
[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you please bisect it to a particular gcc commit and/or single 178.galgel source file?
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- (In reply to lailavrazda1979 from comment #14) Why wait? I'm not hugely opposed, but bugfixes are bugfixes, and one more fixed bug makes a better 4.9 release, right? Because all changes risk introducing new bugs, and we're very close to 4.9 now.
[Bug target/60808] New: Typo in definition of ATxmega256A3BU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60808 Bug ID: 60808 Summary: Typo in definition of ATxmega256A3BU Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vonzeng at ibr dot cs.tu-bs.de Created attachment 32579 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32579action=edit typo fix There is a typo in gcc/config/avr/avr-mcus.de. The mmcpu definition of the ATxmega256A3BU is __AVR_ATxmega258A3BU__. This leads to errors while compiling the avr-libc, this is way I marked the bug critical. Attached is the very easy patch to fix it.
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 jimis jimis at gmx dot net changed: What|Removed |Added CC||jimis at gmx dot net --- Comment #5 from jimis jimis at gmx dot net --- I'm currently using this C99 feature. A warning would be nice if NULL or small arrays are passed.
[Bug c/60809] New: C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
Bug ID: 60809
Summary: C99 struct initialiser with embedded self assignment
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jimis at gmx dot net
For the following code, which was a typo from my side (full example attached):
pre
struct addrinfo query2 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
query2.ai_flags = AI_PASSIVE
};
/pre
1. A warning would be nice, something like suggest parentheses around
assignment
2. What is the C99 mandated behaviour? I'm not sure GCC is behaving properly.
Currently it sets ai_protocol to 1 because it is the next field after
ai_socktype. But it also sets ai_flags to 1, which I'd expect to be 0 after the
outer struct initialiser is executed.
See discussion, full example program and output, at
http://gcc.gnu.org/ml/gcc-help/2014-04/msg00033.html
[Bug c/50584] No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- I don't recommend this kind of usage of the static keyword. There was even the possibility of removing/deprecating this feature. Quoting from DR#205: There was a unanimous vote that the feature is ugly, and a good consensus that its incorporation into the standard at the 11th hour was an unfortunate decision.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin Jambor from comment #15) (In reply to Manuel López-Ibáñez from comment #13) It is not clear to me why you want to print clone at all. It is an internal detail. ...just printing clone really provides fairly little value. If we (hopefully from the next version on) manage to print details about properties of the particular clone, it will become useful. I'm not entirely convinced by the arguments given above. Templated C++ code in diagnostics is already convoluted enough to add stuff that is not even in the language and that users will have no idea about. Imagine (real G++ output): std::basic_ostream_CharT, _Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(std::basic_ostream_CharT, _Traits::__ostream_type (*)(std::basic_ostream_CharT, _Traits::__ostream_type)) [with _CharT = char, _Traits = std::char_traitschar, std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar] clone For developer/debug dumps, of course this doesn't apply, but this is not what this bug is about. (In reply to Marc Glisse from comment #14) Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone specializing a=0. If the function contains a comparison a=b, you might get a warning because the comparison is always true. As a user, I would be quite confused... This used to happen with template instantiations and it was considered a bug. That is, the compiler should not give that kind of warning for generated code if the original code does not show the same issue. If the original code shows the same issue, then we should give a warning for the original code. In general, there are at least two kinds of warnings: those for which there is a bug if we reach that code under certain conditions, and those for which the code looks suspicious but we cannot prove that there is a bug under any specific condition. Uninitialized warnings fall in the first category, whereas comparison is always true/false falls under the second one. The first kind of warnings would be improved by providing the exact conditions that may trigger the bug, whereas the second kind become noise if only triggered for specific conditions that are actually not present in the original code (like template specializations, macro expansion, and function cloning). For the first kind of bugs, if we explain the conditions better thanks to optimization, great, but saying: we warn because we created a clone of the function only leads to more questions: what is a clone? For the second kind, saying that we warn because we created a clone sounds more like an excuse than an actual analysis. ;-)
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I see nothing surprising here; an assignment expression has the value of the left operand after the assignment. So we 1) set query2.ai_flags to AI_PASSIVE, 2) use this value to initialize .ai_protocol. I'm not sure a warning here makes sense: an assignment-expression is perfectly valid initializer.
[Bug other/60589] Parallel install fails due to multiple cilk.h installs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60589 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Close as FIXED. Comment 5 should have fixed the problem. [Some other issues were fixed in commit r208847/r208847 (namely: the double cilk.h and the automatic inclusion of -lcilkrts).]
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 10 14:06:36 2014 New Revision: 209276 URL: http://gcc.gnu.org/viewcvs?rev=209276root=gccview=rev Log: 2014-04-10 Paolo Carlini paolo.carl...@oracle.com PR c++/52844 * g++.dg/cpp0x/variadic156.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic156.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #2 from jimis jimis at gmx dot net ---
(In reply to Marek Polacek from comment #1)
I see nothing surprising here; an assignment expression has the value of the
left operand after the assignment. So we 1) set query2.ai_flags to
AI_PASSIVE, 2) use this value to initialize .ai_protocol.
if the outer assignment runs last, shouldn't it overwrite the inner assignment?
Then it should be equivalent to that:
pre
struct addrinfo query3 = {
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
1
/pre
Which means that ai_flags should be 0.
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- 6.7.9 Initialization 23 The evaluations of the initialization list expressions are indeterminately sequenced with respect to one another and thus the order in which any side effects occur is unspecified.
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469 --- Comment #12 from Igor Zamyatin izamyatin at gmail dot com --- Thanks, will post a patch after the testing
[Bug c++/60807] internal compiler error (basic_string.tcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807 --- Comment #4 from Martin Husemann martin at netbsd dot org --- Neither can I on NetBSD/amd64 - will check with Thomas for differences on his system
[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Attachment #32577|0 |1 is obsolete|| --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org --- Created attachment 32580 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32580action=edit this one still fails with current trunk
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gereon.kremer at cs dot rwth-aache | |n.de| --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Indeed, this isn't a Dup, but note that the experiment in Comment 3 doesn't tell us much: confused by earlier errors, bailing out is an ICE for a compiler built with checks enabled.
[Bug target/60800] -Ofast -ffast-math miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- -O3 -fstack-arrays -ffast-math also fails on both i686 and x86-64.
[Bug target/60800] -O3 -fstack-arrays miscompiles 178.galgel in SPEC CPU 2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60800 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Summary|-Ofast -ffast-math |-O3 -fstack-arrays |miscompiles 178.galgel in |miscompiles 178.galgel in |SPEC CPU 2K |SPEC CPU 2K --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- -fstack-arrays needs more stack. 32MB stack limit works.
[Bug tree-optimization/55022] [4.8/4.9 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Mircea Namolaru mircea.namolaru at inria dot fr changed: What|Removed |Added CC||mircea.namolaru at inria dot fr --- Comment #17 from Mircea Namolaru mircea.namolaru at inria dot fr --- Vladimir Kargov, Tobias Grosser and me found that the problem is caused by incorrect folding of the floord operator. As a result Cloog translates the expression -4294967296*floord(_19-i_17,4294967296) to the tree-SSA expression 4294967296*floord(_19-i_17,-4294967296) This is wrong, in the first case floord is 0 and in the second is -1.
[Bug ipa/60761] [4.9 Regression] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 16:20:07 2014 New Revision: 209278 URL: http://gcc.gnu.org/viewcvs?rev=209278root=gccview=rev Log: PR ipa/60761 * error.c (dump_decl) case FUNCTION_DECL: If DECL_LANG_SPECIFIC is NULL, but DECL_ABSTRACT_ORIGIN is not, recurse on DECL_ABSTRACT_ORIGIN instead of printing built-in. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug ipa/60761] [4.9 RegrImprove dump_decl for clones
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P3 Summary|[4.9 Regression] Names of |[4.9 RegrImprove dump_decl |all function clones in g++ |for clones |are built-in, in both | |warnings and dumps | --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- No longer a regression, keeping open as enhancement request to improve the dumping for stage1.
[Bug rtl-optimization/60663] [4.9 Regression] Errors out on valid inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|Errors out on valid inline |[4.9 Regression] Errors out |asm |on valid inline asm Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly introduced by r203160 which made inline asm with no input operands appear as having zero cost. Alternate patch posted at http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00512.html
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809 --- Comment #4 from jimis jimis at gmx dot net --- Thanks Andreas, that's the reference I was looking for! I guess since this code triggers unspecified behaviour, a warning would be even more needed. :-)
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32581 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32581action=edit gcc49-pr60567.patch The ipa.c version (changing node-forced_by_abi instead of decl_node-forced_by_abi), also bootstrapped/regtested on i686-linux and bootstrapped on x86_64-linux with regtest still ongoing there.
[Bug fortran/60810] New: [4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Bug ID: 60810 Summary: [4.9 Regression] list directed io from array results in end of file Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: orion at cora dot nwra.com This program: program readstrlist character(len=80), dimension(2) :: ver integer :: a, b, c ver(1) = '285 383' ver(2) = '985' read( ver, *) a, b, c write ( *, *) a, b, c end Outputs: At line 8 of file readstrlist.f90 Fortran runtime error: End of file with: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.9.0-20140409/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.0-20140409/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.9.0 20140409 (Red Hat 4.9.0-0.9) (GCC) works with 4.8.2 and earlier and ifort version 14.0.2.
[Bug target/60811] New: arc/arc.c:2135: possible bad argument to abs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60811 Bug ID: 60811 Summary: arc/arc.c:2135: possible bad argument to abs Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Static analyser cppcheck says [trunk/gcc/config/arc/arc.c:2135]: (error) Invalid abs() argument nr 1. A non-boolean value is required. Source code is gcc_assert (epilogue_p || abs (*first_offset = 127)); Maybe better code might be gcc_assert (epilogue_p || abs (*first_offset) = 127);
[Bug c/60809] C99 struct initialiser with embedded self assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #5 from jimis jimis at gmx dot net ---
Andreas: On a second thought, this paragraph only talks about the order
*within* the initialisation list. But no matter of that order, the
initialisation list is always evaluated to:
{
.ai_family = AF_UNSPEC,
.ai_socktype = SOCK_STREAM,
AI_PASSIVE
};
The outer assignment to query2, should never set ai_flags, no matter what the
side-effects of the inner assignments are. Am I thinking right?
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #19) Created attachment 32581 [details] gcc49-pr60567.patch The ipa.c version (changing node-forced_by_abi instead of decl_node-forced_by_abi), also bootstrapped/regtested on i686-linux and bootstrapped on x86_64-linux with regtest still ongoing there. Regtested fine even on x86_64-linux.
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Apr 10 18:57:48 2014 New Revision: 209280 URL: http://gcc.gnu.org/viewcvs?rev=209280root=gccview=rev Log: PR lto/60567 * ipa.c (function_and_variable_visibility): Copy forced_by_abi flag from decl_node to node. * g++.dg/lto/pr60567_0.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr60567_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #16 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Thu Apr 10 20:13:23 2014 New Revision: 209282 URL: http://gcc.gnu.org/viewcvs?rev=209282root=gccview=rev Log: moved this ChangeLog entry to fortran/ChangeLog 2014-04-04 Bernd Edlinger bernd.edlin...@hotmail.de PR fortran/60191 * fortran/trans-types.c (gfc_get_function_type): In case of recursion build a variadic function type with empty argument list instead of a stdarg-like function type with incomplete argument list. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog
[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
This regtested/bootstrapped patch fixes it, but I'm not fully confident it's
the Right Place. The problem is that constructor_designated wasn't set
properly when entering pop_init_level from c_parser_braced_init, since
push_init_level called earlier set it to 0.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 65aad45..9813698 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -7750,6 +7750,7 @@ set_init_label (tree fieldname, struct obstack *
braced_init_obstack)
do
{
constructor_fields = TREE_VALUE (field);
+ constructor_designated = 1;
designator_depth++;
designator_erroneous = 0;
if (constructor_range_stack)
[Bug debug/60812] New: gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812
Bug ID: 60812
Summary: gcc -g -gpubnames statically linked produces a
.debug_pubnames that is wrong or corrupted
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: geir at cray dot com
gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or
corrupted:
$ gcc --version
gcc (GCC) 4.8.2 20131016 (Cray Inc.)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat getpid.c
#include unistd.h
int main() {
return getpid();
}
$ gcc -c -g -gpubnames getpid.c
$ gcc -o getpid getpid.o -static
$ readelf -wp getpid
Contents of the .debug_pubnames section:
Length: 33
Version: 2
Offset into .debug_info section: 0x77
Size of area in .debug_info section: 139
Offset Name
6f _IO_stdin_used
Length: 7091
Version: 2
Offset into .debug_info section: 0x102
Size of area in .debug_info section: 145
Offset Name
73 main
readelf: Warning: .debug_info offset of 0x6e65706f in .debug_pubnames section
does not point to a CU header.
readelf: Warning: Only DWARF 2 and 3 pubnames are currently supported
$
The .debug_pubnames section of the getpid.o object file is fine:
$ readelf -wp getpid.o
Contents of the .debug_pubnames section:
Length: 7091
Version: 2
Offset into .debug_info section: 0x0
Size of area in .debug_info section: 145
Offset Name
73 main
$
The .debug_pubnames section of a dynamically linked executable is also fine:
$ gcc -o getpid-dynamic getpid.o
$ readelf -wp getpid-dynamic
Contents of the .debug_pubnames section:
Length: 33
Version: 2
Offset into .debug_info section: 0x77
Size of area in .debug_info section: 139
Offset Name
6f _IO_stdin_used
Length: 7091
Version: 2
Offset into .debug_info section: 0x102
Size of area in .debug_info section: 145
Offset Name
73 main
$
Problem is severely impacting the operation of performance analysis tools that
need to use this information.
[Bug fortran/60813] New: [Coarray] substrings mishandled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60813 Bug ID: 60813 Summary: [Coarray] substrings mishandled Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic, rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following substring reference gives the bogus: Error: Rank mismatch in array reference at (1) (1/0) character(len=5), save :: str[*] print *, str(j:j) end While the following (array section) is rejected - but with the wrong error message. It should state that str is a scalar. (Correct syntax for a substring would be str[1](j:j).) character(len=5), save :: str[*] print *, str(j:j)[1] end
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #19 from Mircea Namolaru mircea.namolaru at inria dot fr --- The problem for many of these simple cases is with Graphite formulation of memory accesses constraints. For Fortran, or C (if arrays are declared as pointers), a memory access is not constrained enough (basically it is expressed as a function of a single induction variable). This may increase dramatically the number of the constraint solutions. The computation time for them could become prohibitive as well. But even worse, even if the computation finishes, part of the solutions found are false dependencies restricting possible legal transformations. The solution is to constrain more the memory access - as it is done for C arrays (similar code in C as this Fortran example don't create any problem). A possible solution is to express the access in terms of basic induction variable as in the original source code - maybe by modifying the front end. But other solutions are possible. For sure not a work for GCC 4.9.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #16 from lailavrazda1979 at gmail dot com --- Okay, no worries.
[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Apr 10 23:22:10 2014 New Revision: 209285 URL: http://gcc.gnu.org/viewcvs?rev=209285root=gccview=rev Log: 2014-04-10 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60769 * lra-constraints.c (simplify_operand_subreg): Force reload of paradoxical subreg if it is not in the class contents. 2014-04-10 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60769 * g++.dg/pr60769.C: New. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/pr60769.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/lra-constraints.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/58600] [c++11] ICE on wrong usage of alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58600 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug middle-end/60814] New: incorrect integer promotion when multiplying unsigned short values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60814 Bug ID: 60814 Summary: incorrect integer promotion when multiplying unsigned short values Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 32582 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32582action=edit incorrect integer promotion The attached program triggers an optimizer bug with -O2 or -O3 (it performs correctly with -O1 or -O0). The unsigned - unsigned long long promotion should be unsigned, but gcc incorrectly performs signed promotion. This bug seems to be architecture-independent, it was reproduced on: 4.7.2 (Debian 4.7.2-5) on i486-linux-gnu 4.7.2 (Debian 4.7.2-5) on ia64-linux-gnu 4.7.2 (Debian 4.7.2-5) on s390x-linux-gnu 4.7.3 on hppa-linux-gnu 4.8.2 on x86_64-unknown-linux-gnu (the bug is in 32-bit, 64-bit and x32 mode) 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1) on arm-linux-gnueabihf 4.8.2 (Debian 4.8.2-16) on alpha-linux-gnu The bug doesn't happen in gcc 4.6.4.
[Bug middle-end/60814] incorrect integer promotion when multiplying unsigned short values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60814 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is undefined code as 0x*0x overflows int. x * y is really ((int)x) * ((int)y) So if that overflows and since we know that both (int)x and (int)y are both positive integer since we are converting from unsigned short to int; the result of ((int)x) * ((int)y) will also be positive (since overflow of signed integer is undefined) we can remove the cast between int and unsigned int and go directly to unsigned long long in a valid way.
[Bug debug/60815] New: Inconsistent prologue line table location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
Bug ID: 60815
Summary: Inconsistent prologue line table location
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
CC: ccoutant at gcc dot gnu.org, echristo at gmail dot com
Host: x86_64
Target: x86_64
Given:
templatetypename T
void func() // prologue
{
}
template void funcint();
void f2()
{ // prologue
}
struct foo {
void f3() // GCC prologue
{
}
void f4();
};
void (foo::*x)() = foo::f3;
void foo::f4()
{ // prologue
}
GCC's line table shows the prologue of both of these functions as the line of
the function name, not the opening '{'. Yet if these functions are
non-templates or out-of-line, the prologue starts at the opening brace, not the
function name.
(backstory: Clang consistently uses the opening brace but fails some GDB tests
that rely on GCC's behavior, even though it's inconsistent (see
gdb.cp/cpexprs.exp for some examples). It'd be great if both GCC and Clang
could agree on this, one way or another, but if not, the GDB tests can of
course be made resilient to the difference by simply putting the '{' on the
same line as the function name)
[Bug debug/60815] Inconsistent prologue line table location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
--- Comment #1 from David Blaikie dblaikie at gmail dot com ---
Oh - and if we can confirm the direction you're going with this (if the
decision is that the prologue should start, like Clang, at the opening '{'
always, for example) I'll go ahead and update the GDB test suite to either be
agnostic or to KFAIL those tests under GDB, referencing this bug.
[Bug fortran/60810] [4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-11 CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Confirmed. Works on 4.6, fails on 4.7, 4.8, and 4.9. I have to think about this a bit. I could see an end-of-record message would be possibly the right behavior since each array element is treated as a record. On the other hand, ifort accepts this. So I wonder what other compilers do.
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
--- Comment #2 from Stuart Ambler sambler at alumni dot nd.edu ---
Using gdb on my code, it appears that the immediate problem is caused by what
gthr-default.h and/or gthr-posix.h do to detect whether a program is
multi-threaded, which they seem to assume is ok as a precondition for using
call_once. I think they do this with the code
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
# define GTHR_ACTIVE_PROXY__gthrw_(__pthread_key_create)
Just after that code is
static inline int
__gthread_active_p (void)
{
static void *const __gthread_active_ptr
= __extension__ (void *) GTHR_ACTIVE_PROXY;
return __gthread_active_ptr != 0;
}
This function is called by __gthread_once, which if __gthread_active_p()
returns false, does nothing other than return -1, which results in call_once
throwing a system_error.
__pthread_key_create is a function in libpthread, which my gcc command line
links with. It's possible to display the value of __gthread_active_ptr in
main, and it's 0 at a point before call_once is called and the error is thrown,
unless the this_thread::sleep_for code is uncommented, in which case
__gthread_active_ptr is not 0 and there is no problem.
It's not necessary for the this_thread::sleep to be executed to avoid the
problem. Putting that line in a function in the same source file as main also
results in nonzero __gthread_active_ptr and no problem, even if the function is
never called.
I thought it might depend on order of loading the libraries and gave gcc the
-static option to hopefully have more control over that. Giving gcc also -v
libpthread is listed before libstdc++. But with static linking,
__gthread_active_ptr is 0 and the problem occurs whether or not the
this_thread::sleep_for is present. So I gave up on static linking.
this_thread::sleep_for calls nano_sleep, which libpthread exports. I don't
know much about the linux linker, but it seems that somehow the existence of
this call to nano_sleep, even if not executed, causes libpthread to be loaded
in a way that gives a nonzero value for __gthread_active_ptr when it is
checked.
Though it may work differently on different systems, it seems like the problem
may revolve around an assumption that call_once won't be called except by a
multi-threaded program, and a perhaps somewhat fragile way of determining
whether it's a multi-threaded program.
If you still think I should report it to Ubuntu, I will.
Thanks.
[Bug other/60816] New: Optimzed arm code generates infinite loop via branch instruction branching to current program counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60816 Bug ID: 60816 Summary: Optimzed arm code generates infinite loop via branch instruction branching to current program counter Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: andrew.j.c.parker at gmail dot com Created attachment 32583 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32583action=edit Zip file containing repro cpp, compiler output, preprocessed file and GCC build script The bug is with GCC 4.8.3 compiler for ARM bare metal. It has been produced on both: build=linux (ubuntu) host=Windows target=arm build=osx host=osx target=arm The source comes from https://launchpad.net/gcc-arm-embedded/+download, specifically the q1 release https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-src.tar.bz2. I have also reproduced it with the Android NDK r9 and the arm 4.8 toolchain. The bug isn't present in 4.7.4. Attached is a simple cpp file attached to reproduce bug. Command line is: gcc -c -O3 compiler_bug.cpp The unlinked object file exhibits the problem. The generated assembly for the main function is: main: 0:eafe b0 main There are some comments in the code about what changes you can make to remove the bug. Also attached is the compiler output and the preprocessed .ii file.
[Bug fortran/60810] [4.9 Regression] list directed io from array results in end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Is that the r208591 (and for 4.8 r208595) change that changed the behavior?
[Bug other/60816] Optimzed arm code generates infinite loop via branch instruction branching to current program counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60816 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Adding: __builtin_printf(index1 = %d, index2 = %d.\n, iIndex - (i0or1 - 1), ( iIndex - i0or1 )); Shows the reason why it is optimized to an infinite loop: index1 = 1000, index2 = 999. You are accessing one outside the bounds of the array.
[Bug target/60817] New: gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817 Bug ID: 60817 Summary: gcc configure script misdetects TLS support on x86_64-pc-solaris* with gnu as Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: redlizard at redlizard dot nl Created attachment 32584 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32584action=edit Proposed patch. When building gcc = 4.7 on x86_64-pc-solaris2.11 --with-gnu-as, the gcc/configure script incorrectly decides that gnu as does not support real TLS, and so unnecessarily decides to activate emutls instead. The solaris-specific test checks this support by trying to assemble a piece of TLS-using assembly code, and it uses the same 32-bit code for this test both on 32-bit and 64-bit platforms. The solaris assembler will accept this, but gnu as fails on the 32 bit code when targeting x86_64-pc-solaris*, thus causing the detection to fail. Attached patch for 4.9 fixes the problem, and is trivially backported to 4.8 and 4.7.
