[Bug target/59625] New: asm goto and TARGET_FOUR_JUMP_LIMIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
Bug ID: 59625
Summary: asm goto and TARGET_FOUR_JUMP_LIMIT
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, rth at gcc dot gnu.org
On the following testcase (with 4.8 with say -O2 -mtune=generic, with 4.9
starting with r203012 with e.g. -O2 -mtune=atom) we generate extra .p2align
directives in between the asm goto.
#define EFAULT 14
#define put_user_try do {\
__label__ put_user_fail;\
stac();\
barrier();
#define put_user_catch(err)\
clac();\
if (0) {\
put_user_fail:\
clac();\
(err) = -EFAULT;\
}\
} while (0)
# define _ASM_EXTABLE_EX(from,to)\
.pushsection \__ex_table\,\a\\n \
.balign 8\n \
.long ( #from ) - .\n \
.long ( #to ) - . + 0x7ff0\n \
.popsection\n
#define __put_user_asm_ex(x, addr, itype, rtype, ltype)\
asm goto(1:movitype %rtype0,%1\n\
_ASM_EXTABLE_EX(1b, %l[put_user_fail])\
: : ltype(x), m (addr) : : put_user_fail)
int main(int argc, char **argv)
{
int err = 0;
put_user_try {
__put_user_asm_ex(0, argv[0], q, , er);
__put_user_asm_ex(0, argv[1], q, , er);
__put_user_asm_ex(0, argv[2], q, , er);
__put_user_asm_ex(0, argv[3], q, , er);
__put_user_asm_ex(0, argv[4], q, , er);
} put_user_catch(err);
return err;
}
This is from TARGET_FOUR_JUMP_LIMIT ix86_avoid_jump_mispredicts. Perhaps we
shouldn't count asm goto as a jump there (i.e. add
asm_noperands (PATTERN (insn)) 0
next to every JUMP_P (insn) in that routine)? Because while asm goto could
contain a jump, it can contain something completely different too (as in this
case), not to mention that we have to conservatively count the asm goto as
occupying 0 bytes in the cache line.
[Bug fortran/45586] [4.8/4.9 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #98 from David Kredba nheghathivhistha at gmail dot com --- It was not commited yet, or was it please? I still cannot compile scipy with -flto by trunk gcc.
[Bug target/59605] [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 30 08:48:25 2013 New Revision: 206242 URL: http://gcc.gnu.org/viewcvs?rev=206242root=gccview=rev Log: PR target/59605 * config/i386/i386.c (ix86_expand_set_or_movmem): Create jump_around_label only if it doesn't exist. * gcc.dg/pr59605.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr59605.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59501] [4.9 Regression] Vector Gather with GCC 4.9 2013-12-08 Snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 30 08:53:10 2013 New Revision: 206243 URL: http://gcc.gnu.org/viewcvs?rev=206243root=gccview=rev Log: PR target/59501 * config/i386/i386.c (ix86_save_reg): Don't return true for drap_reg if !crtl-stack_realign_needed. (ix86_finalize_stack_realign_flags): If drap_reg isn't live on entry and stack_realign_needed will be false, clear drap_reg and need_drap. Optimize leaf functions that don't need stack frame even if crtl-need_drap. * gcc.target/i386/pr59501-1.c: New test. * gcc.target/i386/pr59501-1a.c: New test. * gcc.target/i386/pr59501-2.c: New test. * gcc.target/i386/pr59501-2a.c: New test. * gcc.target/i386/pr59501-3.c: New test. * gcc.target/i386/pr59501-3a.c: New test. * gcc.target/i386/pr59501-4.c: New test. * gcc.target/i386/pr59501-4a.c: New test. * gcc.target/i386/pr59501-5.c: New test. * gcc.target/i386/pr59501-6.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59501-1.c trunk/gcc/testsuite/gcc.target/i386/pr59501-1a.c trunk/gcc/testsuite/gcc.target/i386/pr59501-2.c trunk/gcc/testsuite/gcc.target/i386/pr59501-2a.c trunk/gcc/testsuite/gcc.target/i386/pr59501-3.c trunk/gcc/testsuite/gcc.target/i386/pr59501-3a.c trunk/gcc/testsuite/gcc.target/i386/pr59501-4.c trunk/gcc/testsuite/gcc.target/i386/pr59501-4a.c trunk/gcc/testsuite/gcc.target/i386/pr59501-5.c trunk/gcc/testsuite/gcc.target/i386/pr59501-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug lto/59626] New: [4.9 lto] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626 Bug ID: 59626 Summary: [4.9 lto] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Coreutils-8.22 program 'cp' cannot be compiled with trunk gcc 4.9.0 with -O2 -ggdb -pipe -flto: CCLD src/cp /usr/include/bits/unistd.h: In function 'careadlinkat.constprop': /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining __NTH (readlinkat (int __fd, const char *__restrict __path, ^ /usr/include/bits/unistd.h:185:3: error: called from here return __readlinkat_alias (__fd, __path, __buf, __len); ^ make[3]: *** [/var/tmp/portage/sys-apps/coreutils-8.22/temp/ccoTpm79.ltrans9.ltrans.o] Error 1 make[3]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131228/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status Makefile:5419: recipe for target 'src/cp' failed Gcc-4.8.2 fails with -flto too: CCLD src/cp /usr/include/bits/unistd.h: In function 'careadlinkat.constprop.21': /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining __NTH (readlinkat (int __fd, const char *__restrict __path, ^ /usr/include/bits/unistd.h:185:3: error: called from here return __readlinkat_alias (__fd, __path, __buf, __len); ^ make[3]: *** [/var/tmp/portage/sys-apps/coreutils-8.22/temp/cctZ031y.ltrans8.ltrans.o] Error 1 make[3]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status Makefile:5419: recipe for target 'src/cp' failed Both versions are fine without -flto.
[Bug tree-optimization/59501] [4.9 Regression] Vector Gather with GCC 4.9 2013-12-08 Snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug other/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- if (targets.length () == 1) fndecl = targets[0]-decl; else fndecl = builtin_decl_implicit (BUILT_IN_UNREACHABLE); gimple_call_set_fndecl (stmt, fndecl); in gimple_fold_call is obviously wrong for the targets.length () == 0 case, __builtin_unreachable () has no arguments, not the arguments of the call, and no return value. So, IMNSHO, for targets.length () == 0 you want to punt if inplace is true, and otherwise not update the call itself, but replace the old call with a new stmt, __builtin_unreachable ();, and if the call had a lhs with gimple_reg_type, add lhs = 0 (build_zero_cst (TREE_TYPE (lhs))) after the __builtin_unreachable (), so that it is defined, it will be hopefully DCEd soon afterwards but we shouldn't let it being undefined, especially if it is e.g. anonymous SSA_NAME which can't be undefined.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31539 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31539action=edit gcc49-pr59622.patch Untested fix. I think just adding __builtin_unreachable () call before the call and not folding the call at all is best, no need to attempt to handle the lhs etc., DCE will do it's job later on.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- BTW, I wonder if we shouldn't issue a warning on this testcase, if the vtable (and virtual method) are in anonymous namespace and aren't defined in the current CU, they can't be defined anywhere else and thus it is a user error not to define them (or the class shouldn't be used where the vtable is needed). At -O0 on the testcase we end up with _ZTVN12_GLOBAL__N_11AE undefined symbol (that, again, can't be defined anywhere else), so that is at least link time error, but at -O2 we don't get that.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 59544, which changed state. Bug 59544 Summary: Vectorizing store with negative step http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59544 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/59544] Vectorizing store with negative step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59544 Bingfeng Mei bmei at broadcom dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bingfeng Mei bmei at broadcom dot com --- Patch checked in at r206148. It triggers pr59569 that is fixed by a separate patch (r206179).
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #31525|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31540 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31540action=edit gcc49-pr59591.patch Updated patch with runtime testcases. Unfortunately, I don't have access to any CPUs with AVX2 right now, so can't test whether it works there properly.
[Bug c++/59627] New: ICE with OpenMP declare reduction and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59627
Bug ID: 59627
Summary: ICE with OpenMP declare reduction and -flto
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled with -fopenmp -flto)
triggers an ICE on trunk since 2013-10-11:
==
struct A { int i; };
void foo()
{
A a;
#pragma omp declare reduction (+: A: omp_out.i += omp_in.i)
#pragma omp parallel reduction (+: a)
;
}
==
bug.cc:6:11: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1745
#pragma omp declare reduction (+: A: omp_out.i += omp_in.i)
^
0x73a658 discriminator_for_local_entity
../../gcc/gcc/cp/mangle.c:1745
0x73a658 write_local_name
../../gcc/gcc/cp/mangle.c:1833
0x73a658 write_name
../../gcc/gcc/cp/mangle.c:847
0x73a92b write_encoding
../../gcc/gcc/cp/mangle.c:714
0x743398 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3433
0x743577 get_mangled_id
../../gcc/gcc/cp/mangle.c:3455
0x743577 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3478
0xd91200 decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:600
0xd92c46 assign_assembler_name_if_neeeded(tree_node*)
../../gcc/gcc/tree.c:5505
0xdacf2e free_lang_data_in_cgraph
../../gcc/gcc/tree.c:5560
0xdacf2e free_lang_data
../../gcc/gcc/tree.c:5597
0xdacf2e execute
../../gcc/gcc/tree.c:5646
Please submit a full bug report, [etc.]
Jakub, this appeared right after your big OpenMP 4.0 patch
(where omp declare reduction was introduced):
2013-10-11 Jakub Jelinek ja...@redhat.com
* decl.c (duplicate_decls): Error out for redeclaration of UDRs.
(declare_simd_adjust_this): New function.
(grokfndecl): If omp declare simd attribute is present,
call declare_simd_adjust_this if needed and
c_omp_declare_simd_clauses_to_numbers.
[...]
Would you mind having a look?
[Bug c++/59628] New: ICE with invalid OpenMP declare reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59628
Bug ID: 59628
Summary: ICE with invalid OpenMP declare reduction clause
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -fopenmp)
triggers an ICE on trunk since 2013-10-11:
==
struct A { int i; };
void foo()
{
A a;
#pragma omp declare reduction (+: A: omp_out.i +: omp_in.i)
#pragma omp parallel reduction (+: a)
;
}
==
bug.cc: In function 'void foo()':
bug.cc:6:51: error: expected primary-expression before ':' token
#pragma omp declare reduction (+: A: omp_out.i +: omp_in.i)
^
bug.cc:6:51: error: expected ')' before ':' token
bug.cc:7:40: internal compiler error: Segmentation fault
#pragma omp parallel reduction (+: a)
^
0xb75baf crash_signal
../../gcc/gcc/toplev.c:336
0x713397 finish_omp_reduction_clause
../../gcc/gcc/cp/semantics.c:5023
0x713397 finish_omp_clauses(tree_node*)
../../gcc/gcc/cp/semantics.c:5751
0x686027 cp_parser_omp_all_clauses
../../gcc/gcc/cp/parser.c:28155
0x513e4e cp_parser_omp_parallel
../../gcc/gcc/cp/parser.c:29603
0x674827 cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:30723
0x674827 cp_parser_pragma
../../gcc/gcc/cp/parser.c:31228
0x67ac2c cp_parser_statement
../../gcc/gcc/cp/parser.c:9433
0x67b5c9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9740
0x67b73e cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9694
0x68f15b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18610
0x68f15b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18646
0x6934fe cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22678
0x694394 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22590
0x694394 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16588
0x69562f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11200
0x679003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11081
0x69fcd3 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10978
0x69e9c8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10864
0x6a02ba cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4018
Please submit a full bug report, [etc.]
Jakub, this appeared right after your big OpenMP 4.0 patch
(where omp declare reduction was introduced):
2013-10-11 Jakub Jelinek ja...@redhat.com
* decl.c (duplicate_decls): Error out for redeclaration of UDRs.
(declare_simd_adjust_this): New function.
(grokfndecl): If omp declare simd attribute is present,
call declare_simd_adjust_this if needed and
c_omp_declare_simd_clauses_to_numbers.
[...]
Would you mind having a look?
[Bug c++/59629] New: [4.9 Regression] [c++11] ICE with invalid use of auto in lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59629
Bug ID: 59629
Summary: [4.9 Regression] [c++11] ICE with invalid use of auto
in lambda function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code line (compiled with -std=c++11)
triggers an ICE on trunk:
==
void foo(int i = []{ auto 0; }());
==
bug.cc: In lambda function:
bug.cc:1:20: internal compiler error: in synthesize_implicit_template_parm, at
cp/parser.c:31615
void foo(int i = []{ auto 0; }());
^
0x697e43 synthesize_implicit_template_parm
../../gcc/gcc/cp/parser.c:31615
0x697e43 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:14499
0x677d95 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14375
0x68e8cf cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11542
0x695459 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11132
0x679003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11081
0x67a1b0 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10728
0x67a7fb cp_parser_statement
../../gcc/gcc/cp/parser.c:9462
0x67b5c9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9740
0x67ccc0 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9244
0x67ccc0 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8754
0x67ccc0 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4309
0x67e5da cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5969
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x68232f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x682821 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x682ce5 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8162
0x682ce5 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8372
0x684258 cp_parser_default_argument
../../gcc/gcc/cp/parser.c:18591
0x690f0e cp_parser_parameter_declaration
../../gcc/gcc/cp/parser.c:18517
Please submit a full bug report, [etc.]
Adam, this appeared right after your auto refactoring patch
2013-11-12 Adam Butcher a...@jessamine.co.uk
PR c++/58534
PR c++/58536
PR c++/58548
PR c++/58549
PR c++/58637
* parser.h (struct cp_parser): New members implicit_template_parms,
implicit_template_scope and auto_is_implicit_function_template_parm_p.
* parser.c (add_implicit_template_parms): Refactor as ...
(synthesize_implicit_template_parm): ... this to append a new template
type parm to the current template parameter list (introducing a new list
if necessary). Removed push_deferring_access_checks.
[...]
Would you mind having a look?
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
On x86-64 the problem is iteration of crossjumping and dwarf2cfi. We
introduce:
(insn:TI 559 558 2420 38 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp [orig:159 bs ] [159]))
../../../../libgo/go/encoding/binary/binary.go:263 66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil)))
(code_label 2420 559 2418 39 722 [1 uses])
(note 2418 2420 772 39 [bb 39] NOTE_INSN_BASIC_BLOCK)
(insn:TI 772 2418 773 39 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [6 S4
A32])
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 64 [0x40])) [57 %sfp+-220 S4 A32]))
../../../../libgo/go/encoding/binary/binary.go:273 66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 32 [0x20])
(nil)))
(call_insn:TI 773 772 774 39 (call (mem:QI (reg/f:SI 0 ax [orig:233 D.6194 ]
[233]) [0 S1 A8])
(const_int 32 [0x20]))
../../../../libgo/go/encoding/binary/binary.go:273 672 {*call}
(expr_list:REG_DEAD (reg/f:SI 0 ax [orig:233 D.6194 ] [233])
(nil))
(nil))
(insn:TI 774 773 100 39 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(insn 100 774 101 39 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 24 [0x18])) [57 %sfp+-232 S4 A32])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:272
90 {*movsi_internal}
(nil))
(insn 101 100 2682 39 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [57 %sfp+-244 S4 A32])
(const_int 2 [0x2])) ../../../../libgo/go/encoding/binary/binary.go:272
90 {*movsi_internal}
(nil))
(jump_insn:TI 2682 101 2683 39 (set (pc)
(label_ref 1634)) 667 {jump}
(nil)
- 1634)
dwarf2cfi is apparently not able to merge these calls since they have different
stack pointers at that time:
(gdb) p *ti-beg_row
$7 = {cfa = {offset = 316, base_offset = 0, reg = 4, indirect = 0, in_use = 0},
cfa_cfi = 0x0, reg_save = 0x76f7ecd0}
(gdb) p *cur_row
$8 = {cfa = {offset = 304, base_offset = 0, reg = 4, indirect = 0, in_use = 0},
cfa_cfi = 0x0, reg_save = 0x76f9f730}
(gdb)
I am not quite sure why they are different, since the calls both leads to
normal return and seem to expect sp to be sane.
[Bug middle-end/59630] New: [4.7/4.8/4.9 Regression] ICE converting the return type of a builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630
Bug ID: 59630
Summary: [4.7/4.8/4.9 Regression] ICE converting the return
type of a builtin function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled with -std=c99 -O)
triggers an ICE since GCC 4.7.0:
==
_Bool foo()
{
_Bool (*f)(int) = __builtin_abs;
return f(0);
}
==
bug.c: In function 'foo':
bug.c:3:21: warning: initialization from incompatible pointer type [enabled by
default]
_Bool (*f)(int) = __builtin_abs;
^
bug.c:5:1: error: non-trivial conversion at assignment
}
^
_Bool
int
_4 = 0;
bug.c:5:1: internal compiler error: verify_gimple failed
0x9f1726 verify_gimple_in_cfg(function*)
../../gcc/gcc/tree-cfg.c:4854
0x9195f2 execute_function_todo
../../gcc/gcc/passes.c:1850
0x919f43 execute_todo
../../gcc/gcc/passes.c:1884
Please submit a full bug report, [etc.]
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
First block is:
(insn:TI 551 2434 552 38 (set (mem/f/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 104 [0x68])) [17 MEM[(struct *)bs]+0 S4 A64])
(reg/f:SI 6 bp [orig:159 bs ] [159]))
../../../../libgo/go/encoding/binary/binary.go:263 90 {*movsi_internal}
(nil))
(insn 552 551 553 38 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 108 [0x6c])) [17 MEM[(struct *)bs + 4B]+0 S4 A32])
(const_int 2 [0x2])) ../../../../libgo/go/encoding/binary/binary.go:263
90 {*movsi_internal}
(nil))
(insn:TI 553 552 556 38 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 112 [0x70])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:263
90 {*movsi_internal}
(nil))
(insn 556 553 557 38 (set (mem:HI (reg/f:SI 7 sp) [49 S2 A16])
(reg/v:HI 1 dx [orig:202 v ] [202]))
../../../../libgo/go/encoding/binary/binary.go:263 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:202 v ] [202])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(insn:TI 557 556 558 38 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:263
66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 20 [0x14])
(nil)))
(insn 558 557 559 38 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(const_int 2 [0x2])) ../../../../libgo/go/encoding/binary/binary.go:263
66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 24 [0x18])
(nil)))
(insn:TI 559 558 2420 38 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp [orig:159 bs ] [159]))
../../../../libgo/go/encoding/binary/binary.go:263 66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil)))
Second is:
(code_label 2425 707 2423 54 723 [1 uses])
(note 2423 2425 760 54 [bb 54] NOTE_INSN_BASIC_BLOCK)
(insn:TI 760 2423 761 54 (set (mem/f/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 104 [0x68])) [17 MEM[(struct *)bs]+0 S4 A64])
(reg/f:SI 6 bp [orig:159 bs ] [159]))
../../../../libgo/go/encoding/binary/binary.go:273 90 {*movsi_internal}
(nil))
(insn 761 760 766 54 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 108 [0x6c])) [17 MEM[(struct *)bs + 4B]+0 S4 A32])
(const_int 2 [0x2])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 766 761 762 54 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil
(insn:TI 762 766 765 54 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 124 [0x7c])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 770 54 (set (mem:HI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(insn 770 765 2326 54 (set (reg:SI 2 cx [488])
(const_int 3 [0x3])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(expr_list:REG_EQUAL (const_int 3 [0x3])
(nil)))
(insn:TI 2326 770 2023 54 (set (reg:SI 4 si [487])
(plus:SI (reg/f:SI 7 sp)
(const_int 116 [0x74])))
../../../../libgo/go/encoding/binary/binary.go:273 258 {*leasi}
(nil))
(insn 2023 2326 771 54 (set (reg/f:SI 5 di [486])
(reg/f:SI 7 sp)) ../../../../libgo/go/encoding/binary/binary.go:273 90
{*movsi_internal}
(nil))
(insn:TI 771 2023 2693 54 (parallel [
(set (reg:SI 2 cx [488])
(const_int 0 [0]))
(set (reg/f:SI 5 di [486])
(plus:SI (ashift:SI (reg:SI 2 cx [488])
(const_int 2 [0x2]))
(reg/f:SI 5 di [486])))
(set (reg:SI 4 si [487])
(plus:SI (ashift:SI (reg:SI 2 cx [488])
(const_int 2 [0x2]))
(reg:SI 4 si [487])))
(set (mem:BLK (reg/f:SI 5 di [486]) [0 S12 A32])
(mem/c:BLK (reg:SI 4 si [487]) [17 bs+0 S12 A64]))
(use (reg:SI 2 cx [488]))
]) ../../../../libgo/go/encoding/binary/binary.go:273 921 {*rep_movsi}
(expr_list:REG_UNUSED (reg/f:SI 5 di [486])
(expr_list:REG_UNUSED (reg:SI 4
[Bug c++/59631] New: ICE using _Cilk_spawn without -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59631
Bug ID: 59631
Summary: ICE using _Cilk_spawn without -fcilkplus
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled *without* -fcilkplus)
triggers an ICE on trunk:
==
void foo()
{
_Cilk_spawn foo();
}
==
bug.cc: In function 'void foo()':
bug.cc:3:20: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.c:714
_Cilk_spawn foo();
^
0x762dab cp_gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**)
../../gcc/gcc/cp/cp-gimplify.c:712
0x9c674b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7350
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9c74ec gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5110
0x9c74ec gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7787
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9ccf7a gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8531
0x9cd579 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8684
0x85b927 analyze_function
../../gcc/gcc/cgraphunit.c:649
0x85cbdb analyze_functions
../../gcc/gcc/cgraphunit.c:1017
0x85e305 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2310
0x655b0e cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4431
Please submit a full bug report, [etc.]
Balaji, this appeared right after your patch
2013-12-11 Balaji V. Iyer balaji.v.i...@intel.com
* cp-tree.h (cilk_valid_spawn): New prototype.
(gimplify_cilk_spawn): Likewise.
(create_try_catch_expr): Likewise.
* decl.c (finish_function): Insert Cilk function-calls when a
_Cilk_spawn is used in a function.
* parser.c (cp_parser_postfix_expression): Added RID_CILK_SPAWN and
RID_CILK_SYNC cases.
[...]
Would you mind havin a look?
[Bug c++/59632] New: ICE with erroneous loop condition after #pragma GCC ivdep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59632
Bug ID: 59632
Summary: ICE with erroneous loop condition after #pragma GCC
ivdep
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE on trunk:
==
void foo()
{
#pragma GCC ivdep
while(foo()) {}
}
==
bug.cc: In function 'void foo()':
bug.cc:4:13: error: could not convert 'foo()' from 'void' to 'bool'
while(foo()) {}
^
bug.cc:1:6: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in fold_comparison, at fold-const.c:9316
void foo()
^
0xd8f855 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9243
0x93ef66 tree_class_check
../../gcc/gcc/tree.h:2830
0x93ef66 fold_comparison
../../gcc/gcc/fold-const.c:9316
0x941e1b fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:12953
0x96309a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:15194
0x93f64d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/gcc/fold-const.c:10181
0xba0e8c fold_cond_expr_cond()
../../gcc/gcc/tree-cfg.c:650
0xba996e make_edges
../../gcc/gcc/tree-cfg.c:780
0xba996e build_gimple_cfg
../../gcc/gcc/tree-cfg.c:260
0xba996e execute_build_cfg
../../gcc/gcc/tree-cfg.c:336
0xba996e execute
../../gcc/gcc/tree-cfg.c:374
Please submit a full bug report, [etc.]
Tobias, this appeared right after your patch
2013-10-30 Tobias Burnus bur...@net-b.de
PR other/33426
* cp-tree.h (RANGE_FOR_IVDEP): Define.
(cp_convert_range_for, finish_while_stmt_cond, finish_do_stmt,
finish_for_cond): Take 'bool ivdep' parameter.
* cp-array-notation.c (create_an_loop): Update call.
* init.c (build_vec_init): Ditto.
* pt.c (tsubst_expr): Ditto.
* parser.c (cp_parser_iteration_statement, cp_parser_for,
cp_parser_range_for, cp_convert_range_for): Update calls.
(cp_parser_pragma): Accept GCC ivdep for 'while' and 'do'.
* semantics.c (finish_while_stmt_cond, finish_do_stmt,
finish_for_cond): Optionally build ivdep annotation.
Would you mind having a look?
[Bug c++/59633] New: [4.7/4.8/4.9 Regression] ICE with __attribute((vector_size(...))) for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633
Bug ID: 59633
Summary: [4.7/4.8/4.9 Regression] ICE with
__attribute((vector_size(...))) for enum
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet triggers an ICE since GCC 4.4.0:
==
typedef enum { e } T __attribute__((vector_size(8)));
void foo(T t) {}
==
bug.cc:3:6: internal compiler error: Segmentation fault
void foo(T t) {}
^
0xb75baf crash_signal
../../gcc/gcc/toplev.c:336
0x734388 decl_mangling_context
../../gcc/gcc/cp/mangle.c:755
0x73a143 write_name
../../gcc/gcc/cp/mangle.c:794
0x73de43 write_class_enum_type
../../gcc/gcc/cp/mangle.c:2509
0x73de43 write_type
../../gcc/gcc/cp/mangle.c:1976
0x73dc6c write_type
../../gcc/gcc/cp/mangle.c:2047
0x73f897 write_method_parms
../../gcc/gcc/cp/mangle.c:2496
0x73fb9c write_bare_function_type
../../gcc/gcc/cp/mangle.c:2438
0x743398 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3433
0x743577 get_mangled_id
../../gcc/gcc/cp/mangle.c:3455
0x743577 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3478
0xd91200 decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:600
0xddccf1 make_decl_rtl(tree_node*)
../../gcc/gcc/varasm.c:1274
0xddd96d notice_global_symbol(tree_node*)
../../gcc/gcc/varasm.c:1548
0x859ed5 cgraph_finalize_function(tree_node*, bool)
../../gcc/gcc/cgraphunit.c:434
0x6feb1f expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:3981
0x693527 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22686
0x694394 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22590
0x694394 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16588
0x69562f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11200
Please submit a full bug report, [etc.]
The C-frontend compiles the code without issues.
[Bug c++/59633] [4.7/4.8/4.9 Regression] ICE with __attribute((vector_size(...))) for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- What makes you think the code is valid? From the doc, I think this should be rejected (with a proper error message).
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Dec 30 17:05:10 2013 New Revision: 206248 URL: http://gcc.gnu.org/viewcvs?rev=206248root=gccview=rev Log: PR tree-optimization/59591 * tree-vect-stmts.c (vectorizable_mask_load_store): Fix up handling of modifier = NARROW masked gathers. (permute_vec_elements): Use gimple_get_lhs instead of gimple_assign_lhs. * gcc.dg/vect/pr59591-1.c: New test. * gcc.dg/vect/pr59591-2.c: New test. * gcc.target/i386/pr59591-1.c: New test. * gcc.target/i386/pr59591-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr59591-1.c trunk/gcc/testsuite/gcc.dg/vect/pr59591-2.c trunk/gcc/testsuite/gcc.target/i386/pr59591-1.c trunk/gcc/testsuite/gcc.target/i386/pr59591-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 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 web/59634] New: Documentation (info/man page): lack of information for cache size parameters (--param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59634 Bug ID: 59634 Summary: Documentation (info/man page): lack of information for cache size parameters (--param) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: ytrezq at myopera dot com gcc have several --param for suggesting cache size (l1-cache-line-size l1-cache-size l2-cache-size) However some processors/SoC (like the BCM6358) have separates caches for instructions and data. The documentation don't say which size to consider. For example if you have a processor where you get those info with dmesg: Primary instruction cache 32kB, VIPT, 2-way, linesize 16 bytes and Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes You know the value for --param l1-cache-line-size is 16 but for l1-cache-size you don't know if it is 32Kb or 16Kb.
[Bug lto/59626] [4.9 lto] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-30
CC||trippels at gcc dot gnu.org
Known to work||4.7.3
Ever confirmed|0 |1
Known to fail||4.8.3, 4.9.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 % cat test.i
long __readlinkat_alias() __asm__(readlinkat);
__inline __attribute__((__always_inline__))
long readlinkat(int p1, const char *p2, char *p3, unsigned long p4) {
__readlinkat_alias();
}
int main() {
long (*b)(int, const char *, char *, unsigned long) = readlinkat;
return b(0, 0, 0, 0);
}
(4.7.3 is fine with -std=gnu99)
markus@x4 % /usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3/gcc -std=gnu99 -flto -r
-nostdlib test.i -O2 -o /dev/null
(4.9.0 fails)
markus@x4 % gcc -std=gnu99 -flto -r -nostdlib test.i -O2 -o /dev/null
test.i: In function ‘main’:
test.i:3:6: error: inlining failed in call to always_inline ‘readlinkat’:
recursive inlining
long readlinkat(int p1, const char *p2, char *p3, unsigned long p4) {
^
test.i:4:21: error: called from here
__readlinkat_alias();
^
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc returned 1 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
markus@x4 % gcc -std=gnu99 -r -nostdlib test.i -O2 -o /dev/null
markus@x4 %
[Bug c++/59635] New: [c++1y] ICE with auto and ... as lambda parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59635
Bug ID: 59635
Summary: [c++1y] ICE with auto and ... as lambda parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code line (compiled with -std=c++1y) triggers an
ICE on trunk:
===
auto i = [] (auto,...) { return 0; };
===
bug.cc:1:36: internal compiler error: tree check: expected function_decl, have
template_decl in maybe_add_lambda_conv_op, at cp/lambda.c:973
auto i = [] (auto,...) { return 0; };
^
0xd8f084 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9192
0x7736de tree_check
../../gcc/gcc/tree.h:2707
0x7736de maybe_add_lambda_conv_op(tree_node*)
../../gcc/gcc/cp/lambda.c:973
0x67cd8b cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8763
0x67cd8b cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4309
0x67e5da cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5969
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x68232f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x682821 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x682ce5 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8162
0x682ce5 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8372
0x693fc6 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16761
0x69562f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11200
0x679003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11081
0x69fcd3 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10978
0x69e9c8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10864
0x6a02ba cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4018
0x6a02ba c_parse_file()
../../gcc/gcc/cp/parser.c:31331
0x7c30f3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/59635] [c++1y] ICE with auto and ... as lambda parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59635 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||abutcher at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Adam, this looks like your domain, would you mind having a look?
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Mon Dec 30 17:33:21 2013 New Revision: 206249 URL: http://gcc.gnu.org/viewcvs?rev=206249root=gccview=rev Log: 2013-12-30 Janus Weil ja...@gcc.gnu.org PR fortran/58998 * resolve.c (resolve_symbol): Check that symbol is not only flavorless but also untyped. 2013-12-30 Janus Weil ja...@gcc.gnu.org PR fortran/58998 * gfortran.dg/generic_28.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/generic_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59636] New: [c++1y] ICE with missing template parameter in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59636
Bug ID: 59636
Summary: [c++1y] ICE with missing template parameter in lambda
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code line (compiled with -std=c++1y) triggers an
ICE on trunk:
===
auto i = []() { return []() {}; };
===
bug.cc: In lambda function:
bug.cc:1:26: internal compiler error: Segmentation fault
auto i = []() { return []() {}; };
^
0xb75baf crash_signal
../../gcc/gcc/toplev.c:336
0x6916ef cp_parser_template_parameter
../../gcc/gcc/cp/parser.c:13055
0x6916ef cp_parser_template_parameter_list
../../gcc/gcc/cp/parser.c:12882
0x67d322 cp_parser_lambda_declarator_opt
../../gcc/gcc/cp/parser.c:9027
0x67d322 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8751
0x67d322 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4309
0x67e5da cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5969
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x68232f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x682821 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x6847b4 cp_parser_expression
../../gcc/gcc/cp/parser.c:8274
0x67dce1 cp_parser_expression
../../gcc/gcc/cp/parser.c:8313
0x67dce1 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9223
0x67dce1 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8754
0x67dce1 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4309
0x67e5da cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5969
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x68232f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x682821 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x682ce5 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8162
Please submit a full bug report, [etc.]
Maybe the compiler chokes on the fact that there are more braces, brackets
and parentheses than letters in the code ;-)
[Bug c++/59636] [c++1y] ICE with missing template parameter in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59636 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||abutcher at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Adam, this looks like your domain. Would you mind having a look?
[Bug c++/59631] ICE using _Cilk_spawn without -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59631 --- Comment #1 from Nick Clifton nickc at gcc dot gnu.org --- Author: nickc Date: Mon Dec 30 17:37:08 2013 New Revision: 206250 URL: http://gcc.gnu.org/viewcvs?rev=206250root=gccview=rev Log: PR target/59631 * stor-layout.c (get_mode_bounds): Use GET_MODE_PRECISION instead of GET_MODE_BITSIZE. Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c
[Bug middle-end/52856] misuse of MODE_SIZE vice MODE_PRECISION in get_mode_bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 Nick Clifton nickc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Nick Clifton nickc at gcc dot gnu.org --- This is a duplicate of 59613. Closing this one because 59613 includes a test case. *** This bug has been marked as a duplicate of bug 59613 ***
[Bug target/59613] Incorrect code generation in MSP430 large model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613 Nick Clifton nickc at gcc dot gnu.org changed: What|Removed |Added CC||pab at pabigot dot com --- Comment #1 from Nick Clifton nickc at gcc dot gnu.org --- *** Bug 52856 has been marked as a duplicate of this bug. ***
[Bug target/59613] Incorrect code generation in MSP430 large model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613 Nick Clifton nickc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton nickc at gcc dot gnu.org --- This is a bug in the generic gcc code - get_mode_bounds() to be precise. It has now been fixed by this patch: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01950.html Cheers Nick
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) The ICE appeared between r199034 (2013-05-17, no ICE) and r199221 (2013-05-22, ICE). In this range are three committs for PR 48858, which might be to blame here: r199118, r199119, r199120. At first sight I suspect the middle one could be the culprit ...
[Bug c/59615] asm goto output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) Anyway, you definitely don't want to use inline asm in this case, if there is some code GCC doesn't optimize as good as you'd like to, just report that. One common similar case where people are tempted to use asm goto with an output operand is, on x86: compute a*b and check if it overflowed. x86 has flags for that but AFAIR they are not modeled in the .md files. (I was also interested in output operands for asm goto in PR52381, but there is no good example there)
[Bug c++/59637] New: [c++11] ICE with decltype and destructor call in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59637
Bug ID: 59637
Summary: [c++11] ICE with decltype and destructor call in
template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11) triggers an
ICE since GCC 4.7.0:
===
templatetypename T void foo(T* p)
{
p-decltype(T{})::~X();
};
===
bug.cc: In function 'void foo(T*)':
bug.cc:3:21: internal compiler error: Segmentation fault
p-decltype(T{})::~X();
^
0xb75baf crash_signal
../../gcc/gcc/toplev.c:336
0x6785d7 contains_struct_check
../../gcc/gcc/tree.h:2820
0x6785d7 cp_parser_unqualified_id
../../gcc/gcc/cp/parser.c:4926
0x68fd73 cp_parser_id_expression
../../gcc/gcc/cp/parser.c:4726
0x6993e8 cp_parser_postfix_dot_deref_expression
../../gcc/gcc/cp/parser.c:6529
0x67e729 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6186
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x68232f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x682821 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x6847b4 cp_parser_expression
../../gcc/gcc/cp/parser.c:8274
0x684fec cp_parser_expression
../../gcc/gcc/cp/parser.c:8313
0x684fec cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9617
0x67a818 cp_parser_statement
../../gcc/gcc/cp/parser.c:9468
0x67b5c9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9740
0x67b73e cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9694
0x68f15b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18610
0x68f15b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18646
0x6934fe cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22678
0x694394 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22590
0x694394 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16588
Please submit a full bug report, [etc.]
The code was wrongly rejected from GCC 4.3.0 (where decltype was introduced)
until GCC 4.6.4.
[Bug c/59615] asm goto output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Marc Glisse from comment #6) (In reply to Jakub Jelinek from comment #4) Anyway, you definitely don't want to use inline asm in this case, if there is some code GCC doesn't optimize as good as you'd like to, just report that. One common similar case where people are tempted to use asm goto with an output operand is, on x86: compute a*b and check if it overflowed. x86 has flags for that but AFAIR they are not modeled in the .md files. (I was also interested in output operands for asm goto in PR52381, but there is no good example there) They are modelled in the .md files now, we just don't have general purpose builtins for this yet in GCC 4.9, it is only used for -fsanitize=undefined right now.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) In this range are three committs for PR 48858, which might be to blame here: r199118, r199119, r199120. At first sight I suspect the middle one could be the culprit ... Actually the last one seem to be responsible instead. In particular reverting the resolve.c parts of r199120 makes the ICE go away.
[Bug c/59615] asm goto output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) They are modelled in the .md files now, we just don't have general purpose builtins for this yet in GCC 4.9, it is only used for -fsanitize=undefined right now. Ah, right, I thought you had only added an expander, nice that it is properly modeled now (thanks), though I am yet to find C code where combine (or other) ends up matching this pattern, which seems doable without a builtin. (well, we are still losing the high half of the product if we use that pattern, but that's less often needed) Sorry for the hijack, back to comment 5 as the real motivation.
[Bug c++/59638] New: [c++1y] ICE with pointer to function that has auto as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59638
Bug ID: 59638
Summary: [c++1y] ICE with pointer to function that has auto as
parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++1y)
triggers an ICE on trunk:
===
typedef void (*f)(auto);
struct A
{
int i;
};
===
bug.cc:1:23: error: template declaration of 'typedef void (* f)(auto:1)'
typedef void (*f)(auto);
^
bug.cc:5:7: error: data member 'i' cannot be a member template
int i;
^
bug.cc:5:7: internal compiler error: in poplevel, at cp/decl.c:568
0x58b398 poplevel(int, int, int)
../../gcc/gcc/cp/decl.c:568
0x5c5498 end_template_decl()
../../gcc/gcc/cp/pt.c:3799
0x6697a1 finish_fully_implicit_template
../../gcc/gcc/cp/parser.c:31759
0x6727a3 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20390
0x6759ec cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19935
0x6759ec cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19179
0x6759ec cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19406
0x6759ec cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14297
0x68e8cf cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11542
0x695459 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11132
0x679003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11081
0x69fcd3 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10978
0x69e9c8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10864
0x6a02ba cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4018
0x6a02ba c_parse_file()
../../gcc/gcc/cp/parser.c:31331
0x7c30f3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
Already the second error message is bogus, because i is not a template:
bug.cc:5:7: error: data member 'i' cannot be a member template
[Bug c++/59638] [c++1y] ICE with pointer to function that has auto as parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59638 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code CC||abutcher at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Adam, this looks like your domain. Would you mind havin a look?
[Bug tree-optimization/59639] New: Code in a cold basic block is not pushed to .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59639
Bug ID: 59639
Summary: Code in a cold basic block is not pushed to
.text.unlikely
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Consider the code:
[[gnu::cold]]
int slow_path();
int f()
{
asm goto ( : : : : cold);
return 1;
cold:
return slow_path();
}
since slow_path() is cold, the compiler can infer that the basic block
beginning with the cold: label is also cold, so it should be placed in
.text.unlikely. Yet it isn't:
_Z1fv:
0: b8 01 00 00 00 mov$0x1,%eax
5: c3 retq
6: e9 00 00 00 00 jmpq b _Z1fv+0xb
Adding a cold attribute to the label doesn't help.
Expected results: the jmpq instruction should be placed in .text.unlikely.
[Bug c++/59623] Segmentation fault, cc1plus, relative path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59623 --- Comment #1 from Morten Kristiansen millibit at gmail dot com --- Not a bug in GCC, after all. Caused by some mixup of cygwin dll's. Closing bug.
[Bug c++/59623] Segmentation fault, cc1plus, relative path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59623 Morten Kristiansen millibit at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Morten Kristiansen millibit at gmail dot com --- Closing.
[Bug rtl-optimization/59639] Code in a cold basic block is not pushed to .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59639 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |rtl-optimization --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The option you want is -freorder-blocks-and-partition but it only does something when there are real profiling info (aka -fprofile-generate/-fprofile-use).
[Bug c++/59631] ICE using _Cilk_spawn without -fcilkplus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59631 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- The patch in comment #1 was meant for PR 59613.
[Bug rtl-optimization/59639] Code in a cold basic block is not pushed to .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59639 --- Comment #2 from Avi Kivity a...@cloudius-systems.com --- (In reply to Andrew Pinski from comment #1) The option you want is -freorder-blocks-and-partition but it only does something when there are real profiling info (aka -fprofile-generate/-fprofile-use). No. The function slow_path() will be placed in .text.unlikely, without -freorder-blocks-and-partition, so gcc already knows about cold paths even without this option. Adding -freorder-blocks-and-partition does not change the output, even though gcc knows the probability even without profiling information. This is similar to __builtin_expect(), except that I cannot use __builtin_expect() with asm goto.
[Bug rtl-optimization/59639] Code in a cold basic block is not pushed to .text.unlikely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59639 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Avi Kivity from comment #2) (In reply to Andrew Pinski from comment #1) The option you want is -freorder-blocks-and-partition but it only does something when there are real profiling info (aka -fprofile-generate/-fprofile-use). No. The function slow_path() will be placed in .text.unlikely, without -freorder-blocks-and-partition, so gcc already knows about cold paths even without this option. Adding -freorder-blocks-and-partition does not change the output, even though gcc knows the probability even without profiling information. As I said before, you need to use -fprofile-generate/-fprofile-use with that option. See bug 26493 which this is a duplicate of that one. This is similar to __builtin_expect(), except that I cannot use __builtin_expect() with asm goto. *** This bug has been marked as a duplicate of bug 26493 ***
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 59639 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #9 from Kristis Makris mkgnu at mkgnu dot net --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=CZPr9mKgQTQfD3dYqy00b5qg This is an automated response.
[Bug c++/59640] New: templated conversion pointer type comparison causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59640
Bug ID: 59640
Summary: templated conversion pointer type comparison causes
segmentation fault
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc.gnu at adaptivetime dot com
Created attachment 31541
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31541action=edit
full example
a template conversion member function that is for a pointer type causes the
compiler to bail out completely if you compare two of that type. note:
function implementation not required to demonstrate issue.
class broken
{
public:
templatetypename anytype operator anytype*(void);
};
broken a, b;
if(a == b);
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #10 from Kristis Makris mkgnu at mkgnu dot net --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=BJ6WQBHg1LEYvkwLH6Hn02hK This is an automated response.
[Bug web/59634] Documentation (info/man page): lack of information for cache size parameters (--param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59634 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#index-param-935 l1-cache-line-size The size of cache line in L1 cache, in bytes. l1-cache-size The size of L1 cache, in kilobytes. l2-cache-size The size of L2 cache, in kilobytes. This is talking about data cache size.
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #11 from Kristis Makris mkgnu at mkgnu dot net --- I won't see, open or read your email. I won't even know you emailed me. If there's something you want me to do you have to use this: https://aimelia.com/res?id=wnVviP0qSkNXW1mtSIOKtdq5 This is an automated response.
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #23 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Author: mrs Date: Mon Dec 30 19:34:53 2013 New Revision: 206252 URL: http://gcc.gnu.org/viewcvs?rev=206252root=gccview=rev Log: PR c++/41090 * g++.dg/ext/label13.C: Update to not expect failures. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/label13.C
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #24 from Mike Stump mikestump at comcast dot net --- Thanks for the fix and the update guys.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 --- Comment #7 from janus at gcc dot gnu.org --- Created attachment 31542 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31542action=edit patch Here is a patch which removes the ICE, although I don't actually understand why (maybe someone else can see this). It corresponds to a partial reversion of r199120, namely the changes to 'gfc_verify_binding_labels'. It is the smallest subset of the above commit that I was able to find that removes the ICE. It regresses at least on some of the binding_label_tests_* in the testsuite.
[Bug web/59634] Documentation (info/man page): lack of information for cache size parameters (--param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59634 --- Comment #2 from ytrezq at myopera dot com --- Ok. So, does it worth to make a change to the documentation? An another possibility it to rename the parameter in this way: l1-cache-size--l1-data-cache-size l2-cache-size--l2-data-cache-size
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 --- Comment #8 from janus at gcc dot gnu.org --- I had a closer look at what actually changes with the patch in comment 7, and found out that the crucial part is that the patch does not set the 'ns' member of the gsymbol. This observation leads to a much simpler patch to fix the ICE: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 206249) +++ gcc/fortran/resolve.c(working copy) @@ -10164,7 +10164,6 @@ gfc_verify_binding_labels (gfc_symbol *sym) gsym-sym_name = sym-name; gsym-binding_label = sym-binding_label; gsym-binding_label = sym-binding_label; - gsym-ns = sym-ns; gsym-mod_name = module; if (sym-attr.function) gsym-type = GSYM_FUNCTION; Unfortunately I still don't really understand *why* this fixes the ICE. Moreover, it still fails on some binding_label_tests_*. (Btw, also one of the duplicate lines, which set the binding_label, should be removed.)
[Bug c++/59641] New: ICE with invalid expression in vector arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59641
Bug ID: 59641
Summary: ICE with invalid expression in vector arithmetic
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11)
triggers an ICE since GCC 4.8.0:
==
typedef int T __attribute__((vector_size(8)));
T foo(const T a, const T b)
{
constexpr T c = a b;
return c ? a : b;
}
==
bug.cc: In function 'T foo(const T, const T)':
bug.cc:5:23: error: 'a' is not a constant expression
constexpr T c = a b;
^
bug.cc:6:18: internal compiler error: tree check: expected vector_type, have
error_mark in build_conditional_expr_1, at cp/call.c:4495
return c ? a : b;
^
0xd8f084 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9192
0x58441c tree_check
../../gcc/gcc/tree.h:2707
0x58441c build_conditional_expr_1
../../gcc/gcc/cp/call.c:4495
0x5844bc build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc/gcc/cp/call.c:4931
0x6a8e53 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc/gcc/cp/typeck.c:6017
0x682b2c cp_parser_question_colon_clause
../../gcc/gcc/cp/parser.c:8080
0x682b2c cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8116
0x6847b4 cp_parser_expression
../../gcc/gcc/cp/parser.c:8274
0x67af3a cp_parser_expression
../../gcc/gcc/cp/parser.c:8313
0x67af3a cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:10677
0x67af3a cp_parser_statement
../../gcc/gcc/cp/parser.c:9370
0x67b5c9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9740
0x67b73e cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9694
0x68f15b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18610
0x68f15b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18646
0x6934fe cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22678
0x694394 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22590
0x694394 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16588
0x69562f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11200
0x679003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11081
Please submit a full bug report, [etc.]
Marc, vector arithmetic looks like your domain, would you mind having a look?
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, sched2 reorders:
(insn 762 761 765 50 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 112 [0x70])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 766 50 (set (mem:HI (reg/f:SI 7 sp) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(insn 766 765 2326 50 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil
to
(insn 766 761 762 54 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil
(insn:TI 762 766 765 54 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 124 [0x7c])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 770 54 (set (mem:HI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
Here insn 765 gets adjusted for insn766 wihtout updating REG_ARGS_SIZE. I
guess it is because REG_ARGS_SIZE is supposed to sit on insn adjust the stack.
Insn 765 looks as follows:
(insn 762 761 763 50 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 112 [0x70])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 763 762 764 50 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(insn 764 763 765 50 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil
(insn 765 764 766 50 (set (mem:HI (pre_modify:SI (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -4 [0xfffc]))) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 71 {*pushhi2}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
until CSA pass where it gets transformed as:
(insn 762 761 765 50 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 112 [0x70])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 766 50 (set (mem:HI (reg/f:SI 7 sp) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
My conclussion thus would be that CSA ought to remove the REG_ARGS_SIZE note
since it combines stack adjustment with call insn much earlier in the insn
stream:
(insn 749 746 750 50 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [6 S4 A32])
(mem/u/c:SI (plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref/i:SI (__go_tdn_uint16) var_decl
0x76f23850 __go_tdn_uint16)
] UNSPEC_GOT))) [58 S4 A8]))
../../../../libgo/go/encoding/binary/binary.go:271 66 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493 --- Comment #12 from Kristis Makris mkgnu at mkgnu dot net --- Please revise and resubmit. I can't tell clearly why whatever it is you are asking is important.
[Bug tree-optimization/59642] New: Performance regression (4.7/4.8) with -ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59642
Bug ID: 59642
Summary: Performance regression (4.7/4.8) with
-ftree-loop-distribute-patterns
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olle at liljenzin dot se
t.c:
void foo(int *v) {
int *p;
for(p = v; p v + 2; ++p) *p = 0;
for(p = v; p v + 2; ++p)
if(*p) *p = 1;
}
4.8.0/4.8.2 (fedora 19, x86_64):
% gcc -O3 -S t.c
movq$0, (%rdi)
movl4(%rdi), %eax
testl %eax, %eax
je .L1
movl$1, 4(%rdi)
.L1:
rep ret
4.7.3:
movl$0, (%rdi)
movl$0, 4(%rdi)
ret
With -fno-tree-loop-distribute-patterns 4.7 and 4.8 generate same code.
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am testing:
Index: combine-stack-adj.c
===
--- combine-stack-adj.c (revision 206233)
+++ combine-stack-adj.c (working copy)
@@ -567,6 +568,7 @@ combine_stack_adjustments_for_block (bas
try_apply_stack_adjustment (insn, reflist, 0,
-last_sp_adjust))
{
+ rtx note;
if (last2_sp_set)
maybe_move_args_size_note (last2_sp_set, last_sp_set, false);
else
@@ -576,6 +578,11 @@ combine_stack_adjustments_for_block (bas
reflist = NULL;
last_sp_set = NULL_RTX;
last_sp_adjust = 0;
+ /* We no longer adjust stack size. Whoever adjusted it earlier
+hopefully got the note right. */
+ note = find_reg_note (insn, REG_ARGS_SIZE, NULL_RTX);
+ if (note)
+ remove_note (insn, note);
continue;
}
}
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #13 from Igor Zamyatin izamyatin at gmail dot com --- I meant that with 3-stage gcc of r204980 testcase from the attachment was compiled and ran successfully, i.e. no infinite loop. Currently debugging shows that routine mul_double_wide_with_sign (which is actually inlined into aff_combination_scale) from double_int.c is miscompiled: in one case for a bad revision new_coef got value which is different from the value for new_coef for r204980
[Bug c++/59633] [4.7/4.8/4.9 Regression] ICE with __attribute((vector_size(...))) for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- What makes you think the code is valid? From the doc, I think this should be rejected (with a proper error message). Well, because the C-frontend compiles it, the C++-frontend used to compile it and even clang (3.2) compiles it, I was under the impression that this should compile (using the underlying type of the enum). OTOH, bool is rejected, so enums could be rejected as well. This would avoid the trouble of underlying types and (even more important) the missing arithmetic operations. About the docs: I'm not sure which docs you are referring to, but I don't think the wording in gcc.info (6.49 Using Vector Instructions through Built-in Functions) prohibits enums (it doesn't mention them explicitly): The `vector_size' attribute is only applicable to integral and float scalars, although arrays, pointers, and function return values are allowed in conjunction with this construct. Only sizes that are a power of two are currently allowed. IMHO enums are integral scalars. All the basic integer types can be used as base types, both as signed and as unsigned: `char', `short', `int', `long', `long long'. In addition, `float' and `double' can be used to build floating-point vector types. It's not clear whether this list is exhaustive or not. And of course, the docs are at least incomplete, if not inaccurate. E.g. the vector extension of the ternary operator ?: is missing in this chapter.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- About the warning, I think it would lead to false positives. We can specialize function for particular type and the type may not define a virtual method. User may have earlier correctly tested the dynamic type of the objects making the code path dead.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023
--- Comment #9 from janus at gcc dot gnu.org ---
The following patch is more reasonable, I think:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 206252)
+++ gcc/fortran/resolve.c(working copy)
@@ -2360,7 +2360,7 @@ resolve_global_procedure (gfc_symbol *sym, locus *
gfc_symbol *def_sym;
/* Resolve the gsymbol namespace if needed. */
- if (!gsym-ns-resolved)
+ if (!gsym-ns-resolved !gsym-binding_label)
{
gfc_dt_list *old_dt_list;
struct gfc_omp_saved_state old_omp_state;
However, it regresses on value_tests_f03.f90.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- My comment was about warning at a time we fold to unreachable. Higher level warning a-la clang is of course good idea.
[Bug c++/59349] [4.9 Regression] ICE on invalid: Segmentation fault toplev.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59349 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org --- *** Bug 58613 has been marked as a duplicate of this bug. ***
[Bug c++/54367] [meta-bug] lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 58613, which changed state. Bug 58613 Summary: [4.9 Regression] [c++1y] ICE with invalid lambda capture http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58613 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/58613] [4.9 Regression] [c++1y] ICE with invalid lambda capture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58613 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Duplicate of PR59349. *** This bug has been marked as a duplicate of bug 59349 ***
[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583
--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org ---
The second testcase is now also wrongly accepted, due to the fix for PR57887.
However, the following testcase still crashes with almost the same stacktrace:
===
templateint struct A
{
int i = (A0(), 0);
};
===
bug.cc: In constructor 'constexpr A0::A()':
bug.cc:1:22: internal compiler error: in tsubst_copy, at cp/pt.c:12863
templateint struct A
^
0x5f62a3 tsubst_copy
../../gcc/gcc/cp/pt.c:12863
0x5d35f2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15083
0x6d8523 perform_member_init
../../gcc/gcc/cp/init.c:537
0x6d8523 emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1096
0x6e310e synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:799
0x6532f4 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4779
0x580359 build_over_call
../../gcc/gcc/cp/call.c:7119
0x57bd35 build_new_method_call_1
../../gcc/gcc/cp/call.c:7818
0x57bd35 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7888
0x57ce17 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7444
0x6d5697 build_value_init(tree_node*, int)
../../gcc/gcc/cp/init.c:345
0x61ee49 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck2.c:1858
0x5d364e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14053
0x5d77a5 fold_non_dependent_expr_sfinae(tree_node*, int)
../../gcc/gcc/cp/pt.c:5111
0x5d77e9 build_non_dependent_expr(tree_node*)
../../gcc/gcc/cp/pt.c:21234
0x6a93e7 build_x_compound_expr(unsigned int, tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:6136
0x6847fb cp_parser_expression
../../gcc/gcc/cp/parser.c:8294
0x67bb3f cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4279
0x67e5da cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5969
0x681698 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
Please submit a full bug report, [etc.]
[Bug tree-optimization/59643] New: Predictive commoning unnecessarily punts on scimark2 SOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59643 Bug ID: 59643 Summary: Predictive commoning unnecessarily punts on scimark2 SOR Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org I've noticed GCC performs badly on scimark2 SOR compared to llvm 3.[34], and I believe the difference is in predictive commoning, which IMHO unnecessarily gives up on the loop. https://cmssdt.cern.ch/SDT/lxr/source/Validation/Performance/bin/SOR.c?v=Sat The inner loop is: for (j=1; jNm1; j++) Gi[j] = omega_over_four * (Gim1[j] + Gip1[j] + Gi[j-1] + Gi[j+1]) + one_minus_omega * Gi[j]; and the problem is that data ref doesn't know that Gim1[j] and Gip1[j] reads don't conflict with the Gi[j] write (they don't in the benchmark, but the compiler can't know that (unless -flto and some extra smart IPA analysis hints that, that is primarily a bad choice of data structures in the benchmark, instead of using array of pointers to double where each inner array is malloced separately, using two dimensional array might make it clear to the compiler there is no aliasing). When constructing components, pcom ignores read-read dependencies with offset that can't be determined, but in this case there is a write and thus all the data references are put into the same component and that component is unsuitable, because the offset can't be determined. For two writes with unknown dependencies, there is nothing that can be done, but I wonder if for the case of (suitable) write and some other read where we can't determine offset we really have to give up on both the data refs, rather than just the read. On this testcase, giving up on the Gim1[j] and Gip1[j] reads that could possibly overlap with Gi[j] write is IMHO fine, we just keep them as is and don't attempt to optimize them, and pcom doesn't optimize away writes either (or does it? then we'd need to say on the component that it shouldn't do it in that case). With the untested patch I'll attach scimark2 improved from SOR Mflops: 1135.50(1000 x 1000) to SOR Mflops: 1617.87(1000 x 1000)
[Bug tree-optimization/59643] Predictive commoning unnecessarily punts on scimark2 SOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59643 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31543 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31543action=edit gcc49-pr59643.patch Completely untested patch.
[Bug c++/58525] __cxa_throw_bad_array_new_length is generated with -fno-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||reichelt at gcc dot gnu.org --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org --- Alexander, Jason, can this bug be closed as fixed?
[Bug c++/59641] ICE with invalid expression in vector arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59641 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-30 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- In build_conditional_expr_1, we check error_operand_p (arg1) on the original arguments, but we don't check it again after force_rvalue, which we probably should do.
[Bug tree-optimization/59642] Performance regression (4.7/4.8) with -ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59642
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
I've noticed the same in other PRs, normally we manage to track the actual
value of *p, but we don't manage that when *p was written by __builtin_mem*,
which should still be doable:
int f(int*p){
__builtin_memset(p,0,4);
return *p;
}
gives the following .optimized:
__builtin_memset (p_2(D), 0, 4);
_4 = *p_2(D);
return _4;
(RTL fixes things later in this simple case)
[Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 Bug ID: 59644 Summary: [4.9 Regression] r206243 miscompiles Linux kernel Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Starting with r206243 the Linux kernel gets miscompiled. It just hangs very early during boot (before first printk).
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Weird, I thought the kernel is compiled even with -mno-sse, so there shouldn't be AVX used and thus no need for realignment anywhere. What arch is that? i?86 or x86_64? Can you bisect which *.o file matters for this, and attach the preprocessed source plus command line options? Perhaps start with comparison of *.o files between r206242 and r206243? I'd be really surprised if it on the kernel made a difference on many source files.
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 Dennis Brentjes d.brentjes at gmail dot com changed: What|Removed |Added CC||d.brentjes at gmail dot com --- Comment #5 from Dennis Brentjes d.brentjes at gmail dot com --- Created attachment 31544 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31544action=edit Testcase for bug 47226 I encountered this bug last week with gcc 4.8.1. I attached a minimal test case for this bug and was wondering if there is any progress on implementing this feature. As I understand parameter packs in combination with lambdas weren't implemented until bug 41933 was fixed in September this year. So I'm hoping somebody is working on this particular bug as well.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #10 from janus at gcc dot gnu.org --- Here is a variant which regtests cleanly: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 206252) +++ gcc/fortran/resolve.c(working copy) @@ -2351,6 +2351,7 @@ resolve_global_procedure (gfc_symbol *sym, locus * if ((sym-attr.if_source == IFSRC_UNKNOWN || sym-attr.if_source == IFSRC_IFBODY) gsym-type != GSYM_UNKNOWN + !gsym-binding_label gsym-ns gsym-ns-resolved != -1 gsym-ns-proc_name
[Bug c++/59645] New: [4.7/4.8/4.9 Regression] ICE with covariant return and volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59645
Bug ID: 59645
Summary: [4.7/4.8/4.9 Regression] ICE with covariant return and
volatile
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet triggers an ICE since GCC 4.6.0:
===
struct A { virtual ~A(); };
struct B { virtual ~B(); };
struct C : A, B {};
struct X
{
virtual B* foo(volatile int);
};
struct Y : X
{
virtual C* foo(volatile int);
};
C* Y::foo(volatile int) { return 0; }
===
bug.cc: In member function 'virtual C* Y::_ZTch0_h8_N1Y3fooEi(int)':
bug.cc:15:37: error: invalid argument to gimple call
C* Y::foo(volatile int) { return 0; }
^
D.2311
retval.0_3 ={v} Y::foo (this_2(D), D.2311);
bug.cc:15:37: internal compiler error: verify_gimple failed
0xba3116 verify_gimple_in_cfg(function*)
../../gcc/gcc/tree-cfg.c:4854
0xacafe2 execute_function_todo
../../gcc/gcc/passes.c:1850
0xacb933 execute_todo
../../gcc/gcc/passes.c:1884
Please submit a full bug report, [etc.]
[Bug c++/59646] New: [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646
Bug ID: 59646
Summary: [4.7/4.8/4.9 Regression] ICE with volatile in
initializer list
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following (invalid?) code snippet triggers an ICE since GCC 4.7.0:
===
#include initializer_list
struct A {};
std::initializer_listvolatile A x = {{}};
===
bug.cc:5:42: error: no matching function for call to 'A::A(volatile A)'
std::initializer_listvolatile A x = {{}};
^
bug.cc:5:42: note: candidates are:
bug.cc:3:8: note: constexpr A::A()
struct A {};
^
bug.cc:3:8: note: candidate expects 0 arguments, 1 provided
bug.cc:3:8: note: constexpr A::A(const A)
bug.cc:3:8: note: no known conversion for argument 1 from 'volatile A' to
'const A'
bug.cc:3:8: note: constexpr A::A(A)
bug.cc:3:8: note: no known conversion for argument 1 from 'volatile A' to
'A'
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:5:42: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:80
std::initializer_listvolatile A x = {{}};
^
0xd8f855 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9243
0x9a5f05 tree_class_check
../../gcc/gcc/tree.h:2830
0x9a5f05 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gcc/gimple-expr.c:80
0x9d2cf9 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4446
0x9c72fc gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7431
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9c74ec gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5110
0x9c74ec gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7787
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9c7aab gimplify_statement_list
../../gcc/gcc/gimplify.c:1405
0x9c7aab gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7839
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9cf6d3 gimplify_cond_expr
../../gcc/gcc/gimplify.c:3052
0x9c7333 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7387
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9cf6d3 gimplify_cond_expr
../../gcc/gcc/gimplify.c:3052
0x9c7333 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7387
0x9cb7b6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5334
0x9ccf7a gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8531
0x9cd579 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8684
Please submit a full bug report, [etc.]
Btw, clang 3.2 accepts the above code snippet.
Also the code is accepted if 'A' is replaced by 'int'.
[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158 --- Comment #11 from Tom Li biergaizi2009 at gmail dot com --- My Gentoo system is nearly broken because of this bug :( I'm going to report it to Loongson's mailing list.
[Bug c++/59647] New: [4.8] ICE in simplify_const_unary_operation, at simplify-rtx.c:1597
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59647
Bug ID: 59647
Summary: [4.8] ICE in simplify_const_unary_operation, at
simplify-rtx.c:1597
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/12262120
4.8 is broken, trunk does not fail (not sure whether the problem is fixed on
trunk, or merely masked by other changes).
void fn1i (int);
void fn1 ();
struct A
{
int m_fn1 () const
{
if (this-_M_impl._M_finish == 0)
return 1;
return 0;
}
unsigned m_fn2 ()
{
if (!this-m_fn1 ())
fn1 ();
return this-_M_impl._M_finish;
}
double operator[] (int);
struct B
{
int _M_finish;
};
B _M_impl;
};
void
fn2 (A p1)
{
unsigned b = p1.m_fn2 ();
fn1i (b - 1 - p1[p1.m_fn2 () - 1]);
}
gcc --version
gcc (GCC) 4.8.3 20131230 (prerelease)
Configured for x86_64.
gcc -c t.ii -m32 -fno-tree-vrp -mfpmath=sse -O2
t.ii: In function ‘void fn2(A)’:
t.ii:30:1: internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1597
}
^
0x891d5a simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/simplify-rtx.c:1597
0x888b2a simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/simplify-rtx.c:796
0xbfcbd6 fold_rtx
../../gcc/cse.c:3287
0xc01fd1 canonicalize_insn
../../gcc/cse.c:4396
0xc01fd1 cse_insn
../../gcc/cse.c:4490
0xc038e3 cse_extended_basic_block
../../gcc/cse.c:6405
0xc038e3 cse_main
../../gcc/cse.c:6583
0xc03d06 rest_of_handle_cse
../../gcc/cse.c:7433
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066 Solomon Gibbs solomon.gibbs.lists at gmail dot com changed: What|Removed |Added Attachment #29236|0 |1 is obsolete|| --- Comment #4 from Solomon Gibbs solomon.gibbs.lists at gmail dot com --- Created attachment 31545 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31545action=edit Shared header, C99 and C++ units. With workaround.
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622
--- Comment #10 from David Kredba nheghathivhistha at gmail dot com ---
Hello Jakub,
I tried your patch.
/var/tmp/portage/sys-devel/llvm-3.3-r2/work/llvm-3.3.src/lib/Transforms/Scalar/SimplifyLibCalls.cpp:
In member function ‘llvm::Value*
{anonymous}::LibCallOptimization::OptimizeCall(llvm::CallInst*, const
llvm::DataLayout*, const llvm::TargetLibraryInfo*, llvm::IRBuilder)’:
/var/tmp/portage/sys-devel/llvm-3.3-r2/work/llvm-3.3.src/lib/Transforms/Scalar/SimplifyLibCalls.cpp:63:10:
error: LHS in noreturn call
Value *OptimizeCall(CallInst *CI, const DataLayout *TD,
^
D.109494 = __cxa_pure_virtual (this, D.109498, CI, B);
/var/tmp/portage/sys-devel/llvm-3.3-r2/work/llvm-3.3.src/lib/Transforms/Scalar/SimplifyLibCalls.cpp:63:10:
internal compiler error: verify_gimple failed
Do you need a new reduced testcase?
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #11 from David Kredba nheghathivhistha at gmail dot com --- Without -m32 it not ICEs after patch applied.
[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066 Solomon Gibbs solomon.gibbs.lists at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Solomon Gibbs solomon.gibbs.lists at gmail dot com --- Sorry, I missed the request for more information. This is still broken for me under 4.8.1. In a nutshell, I think that differing assumptions about inline functions made by g++ and gcc are carrying over into object file output and preventing linking. Working from a shared header with a non-static inline function, gcc explicitly creates an implementation at the location of an extern inline On the other hand, g++ creates an implementation in every unit where the header was included, intending to throw away redundant definitions at link time. This gives us a definition in the C unit and the C++ unit. However, for some reason, possibly related to the difference in COFF data, the linker is unable to determine that the definitions are truly identical as it would if they both came from a non-static C++ inline. One workaround is to prevent the C++ definition from being created using the gnu_inline function attribute. I updated the original attachment to show the workaround and added a Makefile. Since this requires a shared header, C and C++ units to manifest, I did not paste all three files into the comment, but left them in the attachment archive. Please let me know if you still need something else to reproduce the issue. The relevant output is obtained from objdump as: $ objdump -x app-broken.o |grep -B1 -e 'COMDAT _problem_function' 3 .text$problem_function 000c 0180 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE, LINK_ONCE_DISCARD (COMDAT _problem_function 4) $ gcc -v Using built-in specs. COLLECT_GCC=C:\opt\MinGW-w64\x86-posix-dwarf\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/opt/mingw-w64/x86-posix-dwarf/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.8.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/tmp/x32-481-posix-dwarf-r5/mingw32 --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/tmp/mingw-prereq/i686-w64-mingw32-static --with-mpfr=/tmp/mingw-prereq/i686-w64-mingw32-static --with-mpc=/tmp/mingw-prereq/i686-w64-mingw32-static --with-isl=/tmp/mingw-prereq/i686-w64-mingw32-static --with-cloog=/tmp/mingw-prereq/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='rev5, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/tmp/x32-481-posix-dwarf-r5/libs/include -I/tmp/mingw-prereq/x32-zlib/include -I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/tmp/x32-481-posix-dwarf-r5/libs/include -I/tmp/mingw-prereq/x32-zlib/include -I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/tmp/x32-481-posix-dwarf-r5/libs/lib -L/tmp/mingw-prereq/x32-zlib/lib -L/tmp/mingw-prereq/i686-w64-mingw32-static/lib -L/tmp/x32-481-posix-dwarf-r5/mingw32/opt/lib -Wl,--large-address-aware' Thread model: posix gcc version 4.8.1 (rev5, Built by MinGW-W64 project) $ g++ -v Using built-in specs. COLLECT_GCC=C:\opt\MinGW-w64\x86-posix-dwarf\bin\g++.exe COLLECT_LTO_WRAPPER=c:/opt/mingw-w64/x86-posix-dwarf/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.8.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/tmp/x32-481-posix-dwarf-r5/mingw32 --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
[Bug sanitizer/58718] Invalid check in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Yury Gribov y.gribov at samsung dot com --- Works for me in Clang and GCC trunks.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #14 from Igor Zamyatin izamyatin at gmail dot com --- I meant new_coef from aff_combination_scale
[Bug tree-optimization/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #12 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 31546 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31546action=edit After patch ICE generating reduced preprocessed source file
