[Bug c++/79590] ICE (internal compiler error) in nothrow_spec_p with generic lambda and `noexcept(noexcept(...))` expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79590 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 CC||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r241944.
[Bug ipa/79579] [5/6/7 Regression] ICE in ipa_write_node_info (ipa-prop.c:4931)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79579 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |7.0 Target Milestone|--- |5.5
[Bug c++/79580] [5/6 Regression] ICE in nested_anon_class_index, at cp/mangle.c:1604
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79580 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |6.3.0 Target Milestone|--- |5.5
[Bug tree-optimization/79621] [7 Regression] ICE in operator[], at vec.h:732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79621 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 CC||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r242075. I'm going to take a look.
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 --- Comment #6 from Jakub Jelinek --- That hunk has been added by Alexandre in r151312 with: (moveup_expr_cached): Don't use cache for debug insns that are heads of blocks. This has been posted to gcc-patches in http://gcc.gnu.org/ml/gcc-patches/2009-03/msg9.html The goal (which has not been accomplished in case of sel-sched as the only pass) is that the presence or lack thereof doesn't affect code generation in any way (i.e. scheduling of everything but DEBUG_INSNs is identical between -g and -g0), and otherwise DEBUG_INSNs are scheduled together with the code movements.
[Bug target/79593] [6/7 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-20 Target Milestone|--- |6.4 Summary|[Regression] Poor/Worse |[6/7 Regression] Poor/Worse |code generation for FPU on |code generation for FPU on |versions after 6|versions after 6 Ever confirmed|0 |1
[Bug target/79570] [5/6/7 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570 --- Comment #7 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #3) > --- gcc/sel-sched.c.jj2017-01-01 12:45:38.0 +0100 > +++ gcc/sel-sched.c 2017-02-17 14:14:06.493525368 +0100 > @@ -2529,6 +2529,7 @@ moveup_expr_cached (expr_t expr, insn_t > } > >if (DEBUG_INSN_P (EXPR_INSN_RTX (expr)) > + && BLOCK_FOR_INSN (EXPR_INSN_RTX (expr)) >&& (sel_bb_head (BLOCK_FOR_INSN (EXPR_INSN_RTX (expr))) > == EXPR_INSN_RTX (expr))) > /* Don't use cached information for debug insns that are heads of Note that such a patch passed bootstrap/regtest on x86_64-linux and i686-linux.
[Bug lto/79625] New: ICE in write_symbol, at lto-streamer-out.c:2567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79625 Bug ID: 79625 Summary: ICE in write_symbol, at lto-streamer-out.c:2567 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Knowing that passing -flto to a RTL test is ugly, but maybe we can somehow handle that. $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/rtl/x86_64/dfinit.c -flto 0x97671d write_symbol ../../gcc/lto-streamer-out.c:2565 0x97874c produce_symtab ../../gcc/lto-streamer-out.c:2684 0x97874c produce_asm_for_decls() ../../gcc/lto-streamer-out.c:2883 0x9c9adf write_lto ../../gcc/passes.c:2581 0x9cd126 ipa_write_summaries_1 ../../gcc/passes.c:2642 0x9cd126 ipa_write_summaries() ../../gcc/passes.c:2702 0x759f0c ipa_passes ../../gcc/cgraphunit.c:2368 0x759f0c symbol_table::compile() ../../gcc/cgraphunit.c:2462 0x75bbe4 symbol_table::compile() ../../gcc/cgraphunit.c:2595 0x75bbe4 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2621
[Bug tree-optimization/79594] -Waggressive-loop-optimizations incomplete and/or inconsistentt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79594 Richard Biener changed: What|Removed |Added Keywords||diagnostic CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- It only warns once per loop and the actual stmt that is warned on depends on what gets processed first... So IMHO this works as expected (even if it looks inconsistent).
[Bug c++/79595] Inconsistent grammar in diagnostic "partial specialization %q+D does not specialize"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79595 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- I would suggest to change the second sentence to "is not more constrainted than the primary template"?
[Bug c++/79607] [5/6 Regression] ICE with brace-initialization of static const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79607 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||7.0
[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 CC||marxin at gcc dot gnu.org Summary|[7 Regression] Wrong code |[6/7 Regression] Wrong code |w/ -O2 -floop-nest-optimize |w/ -O2 -floop-nest-optimize Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r230200.
[Bug c++/79626] New: ICE on invalid code in build_temp (call.c:6489)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79626
Bug ID: 79626
Summary: ICE on invalid code in build_temp (call.c:6489)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Reduced from a LLVM test-case, all releases I have are affected:
$ cat /tmp/ice.C
template struct b
{b() b(b &) b(b< a, a > }
void c(b< int, int >(b< int, int >())
./xg++ -B. /tmp/ice.C
/tmp/ice.C:2:12: error: expected ‘;’ at end of member declaration
{b() b(b &) b(b< a, a > }
^
/tmp/ice.C:2:19: error: expected ‘;’ at end of member declaration
{b() b(b &) b(b< a, a > }
^
/tmp/ice.C:2:33: error: expected ‘,’ or ‘...’ before ‘}’ token
{b() b(b &) b(b< a, a > }
^
/tmp/ice.C:2:33: error: expected ‘)’ before ‘}’ token
/tmp/ice.C:2:23: error: expected ‘;’ at end of member declaration
{b() b(b &) b(b< a, a > }
^
/tmp/ice.C:2:34: error: expected ‘;’ after struct definition
{b() b(b &) b(b< a, a > }
^
;
/tmp/ice.C:3:45: error: variable or field ‘c’ declared void
void c(b< int, int >(b< int, int >())
^
/tmp/ice.C: In instantiation of ‘struct b’:
/tmp/ice.C:3:44: required from here
/tmp/ice.C:2:21: error: invalid constructor; you probably meant ‘b
(const b&)’
{b() b(b &) b(b< a, a > }
^
xg++: internal compiler error: Segmentation fault (program cc1plus)
It's a stack overflow:
(gdb) bt
#0 0x00759282 in cp_build_qualified_type_real (type=0x76a06150,
type_quals=0, complain=3) at ../../gcc/cp/tree.c:1121
#1 0x00715976 in same_type_ignoring_top_level_qualifiers_p
(type1=, type2=0x76a06150) at ../../gcc/cp/typeck.c:1465
#2 0x00653a29 in is_properly_derived_from (derived=0x76a06150,
base=0x76a06150) at ../../gcc/cp/call.c:8946
#3 0x006547d6 in direct_reference_binding
(type=type@entry=0x76a06738, conv=0x5d399d0) at ../../gcc/cp/call.c:1495
#4 0x0065a1d3 in reference_binding (rto=0x76a06738,
rfrom=0x76a06150, expr=, c_cast_p=, flags=5,
complain=2) at ../../gcc/cp/call.c:1627
#5 0x006593ed in implicit_conversion (to=0x76a06738,
from=0x76a06150, expr=0x76884118, c_cast_p=, flags=5,
complain=2) at ../../gcc/cp/call.c:1837
#6 0x0065ab39 in add_function_candidate
(candidates=candidates@entry=0x7bfff368, fn=fn@entry=0x76a04900,
ctype=ctype@entry=0x76a06150, first_arg=,
args=0x75b469d8, access_path=access_path@entry=0x76a00a80,
conversion_path=0x76a00a80, flags=5, complain=3) at
../../gcc/cp/call.c:2197
#7 0x0065ba40 in add_candidates (fns=0x769ff820,
fns@entry=0x769ff860, first_arg=first_arg@entry=0x75b48100,
args=args@entry=0x75b469d8, return_type=return_type@entry=0x0,
explicit_targs=explicit_targs@entry=0x0,
template_only=template_only@entry=false, conversion_path=0x76a00a80,
access_path=0x76a00a80, flags=5, candidates=0x7bfff368, complain=3) at
../../gcc/cp/call.c:5504
#8 0x0065c1e0 in build_new_method_call_1 (complain=3, fn_p=0x0,
flags=5, conversion_path=0x76a00a80, args=0x75b48100,
fns=0x769ff860, instance=0x75b48100) at ../../gcc/cp/call.c:8684
#9 build_new_method_call (instance=instance@entry=0x75b48100,
fns=0x75b472a0, args=args@entry=0x7bfff468, conversion_path=, flags=flags@entry=5, fn_p=fn_p@entry=0x0, complain=3) at
../../gcc/cp/call.c:8884
#10 0x00655832 in build_special_member_call (instance=0x75b48100,
instance@entry=0x0, name=0x76891de0, args=args@entry=0x7bfff468,
binfo=0x76a00a80, binfo@entry=0x76a06150, flags=flags@entry=5,
complain=complain@entry=3)
at ../../gcc/cp/call.c:8415
#11 0x00656b5f in build_temp (complain=3, diagnostic_kind=, flags=5, type=0x76a06150, expr=0x76884118) at
../../gcc/cp/call.c:6489
#12 convert_like_real (convs=0x5d39860, expr=expr@entry=0x76884118,
fn=fn@entry=0x76a04700, argnum=argnum@entry=0, inner=inner@entry=0,
issue_conversion_warnings=issue_conversion_warnings@entry=true, c_cast_p=false,
complain=3) at ../../gcc/cp/call.c:6907
#13 0x0065d161 in build_over_call (cand=cand@entry=0x5d39890,
flags=flags@entry=5, complain=complain@entry=3) at ../../gcc/cp/call.c:7841
#14 0x0065c3a7 in build_new_method_call_1 (complain=3, fn_p=0x0,
flags=5, conversion_path=, args=0x75b480c0, fns=, instance=0x75b480c0) at ../../gcc/cp/call.c:8814
#15 build_new_method_call (instance=instance@entry=0x75b480c0,
fns=0x75b47270, args=args@entry=0x7f
[Bug target/79593] [6/7 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
That said, the reason why there is fld1 followed by fld %st(0) is that 1.0 is
used multiple times:
(insn 41 64 42 8 (set (reg:SF 114)
(mem/u/c:SF (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [4 S4 A32]))
"pr79593.c":17 125 {*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 42 41 43 8 (set (reg:XF 118 [ delta ])
(float_extend:XF (reg:SF 114))) "pr79593.c":17 153 {*extendsfxf2_i387}
(expr_list:REG_EQUAL (const_double:XF 1.0e+0 [0x0.8p+1])
(nil)))
...
(insn 69 65 47 9 (set (reg:XF 110 [ delta ])
(float_extend:XF (reg:SF 114))) "pr79593.c":17 153 {*extendsfxf2_i387}
(expr_list:REG_DEAD (reg:SF 114)
(expr_list:REG_EQUAL (const_double:XF 1.0e+0 [0x0.8p+1])
(nil
in multiple basic blocks with conditional jump in between, so the combiner
doesn't combine it into (set (reg:XF ...)) (const_double:XF 1.0e+0).
Still in *.peephole2 we have:
(insn 82 64 42 8 (set (reg:SF 10 st(2) [114])
(const_double:SF 1.0e+0 [0x0.8p+1])) "pr79593.c":17 125
{*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 42 82 83 8 (set (reg:XF 9 st(1) [orig:118 delta ] [118])
(float_extend:XF (reg:SF 10 st(2) [114]))) "pr79593.c":17 153
{*extendsfxf2_i387}
(expr_list:REG_EQUIV (const_double:XF 1.0e+0 [0x0.8p+1])
(nil)))
...
(insn 69 65 47 9 (set (reg:XF 8 st [orig:110 delta ] [110])
(float_extend:XF (reg:SF 10 st(2) [114]))) "pr79593.c":17 153
{*extendsfxf2_i387}
(expr_list:REG_DEAD (reg:SF 10 st(2) [114])
(expr_list:REG_EQUAL (const_double:XF 1.0e+0 [0x0.8p+1])
(nil
It is only the regstack pass that optimizes those 2 into 1, but that isn't able
to peephole or otherwise combine:
(insn:TI 82 64 42 7 (set (reg:SF 8 st)
(const_double:SF 1.0e+0 [0x0.8p+1])) "pr79593.c":17 125
{*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 1.0e+0 [0x0.8p+1])
(nil)))
(insn:TI 42 82 83 7 (set (reg:XF 8 st)
(float_extend:XF (reg:SF 8 st))) "pr79593.c":17 153 {*extendsfxf2_i387}
(expr_list:REG_EQUIV (const_double:XF 1.0e+0 [0x0.8p+1])
(nil)))
and there is no peephole2 pass afterwards, so either regstack itself would need
to do this, or the machine reorg pass.
Still no idea why this is considered a regression, I get with gcc 5.4.1
20160721
subl$12, %esp
fldz
movl16(%esp), %edx
movl20(%esp), %eax
cmpl%eax, (%edx)
jbe .L2
fldsglobal_data
fldsglobal_data+4
fxch%st(2)
fcomp %st(1)
fnstsw %ax
sahf
ja .L13
fxch%st(1)
fsubrs 4(%edx)
.L5:
fdivp %st, %st(1)
ftst
fnstsw %ax
sahf
jnb .L6
fstp%st(0)
fldz
.L6:
fld1
fld %st(0)
fcomp %st(2)
fnstsw %ax
sahf
jnb .L14
fstp%st(1)
jmp .L7
.p2align 4,,10
.p2align 3
.L14:
fstp%st(0)
.L7:
.L2:
addl$12, %esp
ret
[Bug c++/79241] error wen compiling -Os, OK with another optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79241 --- Comment #7 from night_ghost at ykoctpa dot ru --- Created attachment 40779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40779&action=edit testcase ii and console log. If I change from -Os to any other mode then it compiles OK
[Bug tree-optimization/79621] [7 Regression] ICE in operator[], at vec.h:732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79621 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Target Milestone|--- |6.4
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- GCC 4.8.1 is no longer supported, please try 5.4 or newer.
[Bug tree-optimization/79151] Missed BB vectorization with strided/scalar stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151 --- Comment #3 from Richard Biener --- The question is of course whether vector division has comparable latency / throughput as the scalar one.
[Bug c++/79627] New: ICE in expand_expr_real_1, at expr.c:9804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79627
Bug ID: 79627
Summary: ICE in expand_expr_real_1, at expr.c:9804
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Following test-case (reduced from llvm test-suite) fails:
$ cat /tmp/ice.C
long a;
void
b ()
{
long buffer[a];
[&] { __typeof(buffer) c; }();
}
$ ./xg++ -B. /tmp/ice.C
/tmp/ice.C: In lambda function:
/tmp/ice.C:6:26: internal compiler error: in expand_expr_real_1, at expr.c:9804
[&] { __typeof(buffer) c; }();
^
0x911fae expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9798
0x920584 expand_expr
../../gcc/expr.h:276
0x920584 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8301
0x830f0d expand_gimple_stmt_1
../../gcc/cfgexpand.c:3676
0x830f0d expand_gimple_stmt
../../gcc/cfgexpand.c:3737
0x832345 expand_gimple_basic_block
../../gcc/cfgexpand.c:5744
0x8371b6 execute
../../gcc/cfgexpand.c:6357
All releases I have ICE on that. As accepted by clang, I'm adding valid code
keyword.
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 --- Comment #2 from Sumit --- Thanks Richard for the quick response. I understand your point but actually it has been decided to be at 4.8.1 as far as our current project is concerned. Is it possible for you to at least give me some pointers which would have caused these errors? Thanks. Sumit
[Bug c++/79628] New: ICE on invalid code in tsubst, at cp/pt.c:13499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79628
Bug ID: 79628
Summary: ICE on invalid code in tsubst, at cp/pt.c:13499
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
$ cat /tmp/ice.C
template struct a
{
};
template void c (a...);
int d = c (a ())
$ ./xg++ -B. /tmp/ice.C
/tmp/ice.C: In substitution of ‘template void c(a...)
[with b = ]’:
/tmp/ice.C:5:29: required from here
/tmp/ice.C:5:29: internal compiler error: in tsubst, at cp/pt.c:13499
int d = c (a ())
^
0x6a010d tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13499
0x6a2220 unify_pack_expansion
../../gcc/cp/pt.c:19959
0x6949b4 unify
../../gcc/cp/pt.c:20713
0x6940f7 unify
../../gcc/cp/pt.c:20909
0x69496a unify
../../gcc/cp/pt.c:20705
0x5e29e7 try_class_unification
../../gcc/cp/pt.c:19731
0x694af2 unify
../../gcc/cp/pt.c:20742
0x6a1874 unify_one_argument
../../gcc/cp/pt.c:18988
0x6a206b unify_pack_expansion
../../gcc/cp/pt.c:19969
0x6a2b8f type_unification_real
../../gcc/cp/pt.c:19128
0x6a931f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/cp/pt.c:18493
0x65b33d add_template_candidate_real
../../gcc/cp/call.c:3170
0x65ba9c add_template_candidate
../../gcc/cp/call.c:3252
0x65ba9c add_candidates
../../gcc/cp/call.c:5494
0x65e4e1 perform_overload_resolution
../../gcc/cp/call.c:4148
0x65f95e build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/cp/call.c:4233
0x74034a finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2441
0x6efaaa cp_parser_postfix_expression
../../gcc/cp/parser.c:7017
0x6edcba cp_parser_unary_expression
../../gcc/cp/parser.c:8125
0x6f5f57 cp_parser_cast_expression
../../gcc/cp/parser.c:8802
All releases I have ICE.
[Bug tree-optimization/79151] Missed BB vectorization with strided/scalar stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151 --- Comment #4 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > The question is of course whether vector division has comparable latency / > throughput as the scalar one. On the cores that cavium produces the answer is yes for most vector types.
[Bug c++/79629] New: ICE on invalid code in tsubst_copy, at cp/pt.c:14477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79629
Bug ID: 79629
Summary: ICE on invalid code in tsubst_copy, at cp/pt.c:14477
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
We ICE on a LLVM test-case:
$ cat
/home/marxin/BIG/Programming/llvm-project/llvm/tools/clang/test/SemaCXX/enum-unscoped-nonexistent.cpp
// RUN: %clang_cc1 -std=c++11 -verify %s
struct Base {
static const int a = 1;
};
template struct S : Base {
enum E : int;
constexpr int f() const;
constexpr int g() const;
void h();
};
template<> enum S::E : int {}; // expected-note {{enum 'S::E' was
explicitly specialized here}}
template<> enum S::E : int { b = 2 };
template<> enum S::E : int { a = 4 };
template enum S::E : int { b = 8 };
// The unqualified-id here names a member of the non-dependent base class Base
// and not the injected enumerator name 'a' from the specialization.
template constexpr int S::f() const { return a; }
static_assert(S().f() == 1, "");
static_assert(S().f() == 1, "");
// The unqualified-id here names a member of the current instantiation, which
// bizarrely might not exist in some instantiations.
template constexpr int S::g() const { return b; } //
expected-error {{enumerator 'b' does not exist in instantiation of 'S'}}
static_assert(S().g() == 1, ""); // expected-note {{here}} expected-error
{{not an integral constant expression}}
static_assert(S().g() == 2, "");
static_assert(S().g() == 8, "");
// 'b' is type-dependent, so these assertions should not fire before 'h' is
// instantiated.
template void S::h() {
char c[S::b];
static_assert(b != 8, "");
static_assert(sizeof(c) != 8, "");
}
void f() {
S().h(); // ok, b == 2
}
$ g++
/home/marxin/BIG/Programming/llvm-project/llvm/tools/clang/test/SemaCXX/enum-unscoped-nonexistent.cpp
/home/marxin/BIG/Programming/llvm-project/llvm/tools/clang/test/SemaCXX/enum-unscoped-nonexistent.cpp:
In instantiation of ‘constexpr int S::g() const [with T = char]’:
/home/marxin/BIG/Programming/llvm-project/llvm/tools/clang/test/SemaCXX/enum-unscoped-nonexistent.cpp:26:26:
required from here
/home/marxin/BIG/Programming/llvm-project/llvm/tools/clang/test/SemaCXX/enum-unscoped-nonexistent.cpp:25:61:
internal compiler error: in tsubst_copy, at cp/pt.c:14477
template constexpr int S::g() const { return b; } //
expected-error {{enumerator 'b' does not exist in instantiation of 'S'}}
^
0x69b29c tsubst_copy
../../gcc/cp/pt.c:14477
0x69d128 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17872
0x698d68 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16419
0x698bf6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15680
0x698b83 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15896
0x697267 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:22840
0x78fc1d cxx_eval_call_expression
../../gcc/cp/constexpr.c:1493
0x791527 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:3971
0x79490f cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:4613
0x796586 maybe_constant_value(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:4828
0x782321 cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:1963
0x71b017 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/cp/typeck.c:5243
0x661726 build_new_op_1
../../gcc/cp/call.c:5982
0x66225e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/cp/call.c:6027
0x713192 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/cp/typeck.c:3930
0x6f6688 cp_parser_binary_expression
../../gcc/cp/parser.c:9060
0x6f6be0 cp_parser_assignment_expression
../../gcc/cp/parser.c:9190
0x6f6fc7 cp_parser_constant_expression
../../gcc/cp/parser.c:9460
0x6f70f8 cp_parser_static_assert
../../gcc/cp/parser.c:13607
0x706e98 cp_parser_block_declaration
../../gcc/cp/parser.c:12617
[Bug target/79619] store via pointer obtained from alternate address space offset 0 dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79619
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-20
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. GIMPLE DSE removes the store
# PT = null
_2 = MEM[(char * *)0B];
*_2 = 1;
but not here:
# PT = null
_2 = MEM[(char * *)0B];
*_2 = 1;
# PT = nonlocal escaped null
_4 = MEM[(char * *)8B];
*_4 = 1;
because it thinks the value is eventually used by the following load from 8B.
'PT = null' addresses are thought to be not global memory.
-f[no-]delete-null-pointer-checks controls this globally for all address
spaces.
The following fixes the testcase, but it looks to me like all
flag_delete_null_pointer_checks tests in the middle end should be replaced
by this (or some wrapper so eventually the target can specify which
address-spaces
may have objects at address zero):
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 245594)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -3407,7 +3407,10 @@ get_constraint_for_1 (tree t, vec
|| (TREE_CODE (t) == CONSTRUCTOR
&& CONSTRUCTOR_NELTS (t) == 0))
{
- if (flag_delete_null_pointer_checks)
+ if (flag_delete_null_pointer_checks
+ && (! POINTER_TYPE_P (TREE_TYPE (t))
+ || (TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (t)))
+ == ADDR_SPACE_GENERIC)))
temp.var = nothing_id;
else
temp.var = nonlocal_id;
accordingly the documentation of -fdelete-null-pointer-checks should be
adjusted to say it only affects the generic address space.
[Bug lto/79625] ICE in write_symbol, at lto-streamer-out.c:2567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79625 Richard Biener changed: What|Removed |Added Version|unknown |7.0.1 --- Comment #1 from Richard Biener --- Like, ignore -flto ... (or diagnose it as invalid).
[Bug lto/79625] ICE in write_symbol, at lto-streamer-out.c:2567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79625 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Good, I'll prepare patch for that.
[Bug c++/79535] [6/7 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79535 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I'll have a crack at it.
[Bug c++/79626] [5/6/7 Regression] ICE on invalid code in build_temp (call.c:6489)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79626 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Version|7.0.1 |unknown Keywords|ice-on-invalid-code | Last reconfirmed||2017-02-20 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE on invalid code in |[5/6/7 Regression] ICE on |build_temp (call.c:6489)|invalid code in build_temp ||(call.c:6489) Target Milestone|--- |5.5 --- Comment #1 from Jakub Jelinek --- Started with r166977, r166976 gives just: pr79626.C:2:12: error: expected ‘;’ at end of member declaration pr79626.C:2:19: error: expected ‘;’ at end of member declaration pr79626.C:2:33: error: expected ‘,’ or ‘...’ before ‘}’ token pr79626.C:2:33: error: expected ‘)’ before ‘}’ token cc1plus.166976: error: expected ‘;’ at end of member declaration pr79626.C:3:45: error: two or more data types in declaration of ‘c’ pr79626.C:3:45: error: expected ‘)’ at end of input while r166977: pr79626.C:2:12: error: expected ‘;’ at end of member declaration pr79626.C:2:19: error: expected ‘;’ at end of member declaration pr79626.C:2:33: error: expected ‘,’ or ‘...’ before ‘}’ token pr79626.C:2:33: error: expected ‘)’ before ‘}’ token cc1plus.166977: error: expected ‘;’ at end of member declaration pr79626.C:2:33: error: expected ‘;’ after struct definition pr79626.C:3:45: error: variable or field ‘c’ declared void pr79626.C: In instantiation of ‘b’: pr79626.C:3:44: instantiated from here pr79626.C:2:21: error: invalid constructor; you probably meant ‘b (const b&)’ Segmentation fault (core dumped)
[Bug c++/79628] ICE on invalid code in tsubst, at cp/pt.c:13499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79628 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Already r122875 gives: internal compiler error: tree check: expected class ‘expression’, have ‘type’ (integer_type) in unify_pack_expansion, at cp/pt.c:11845 (r122750 still rejects it because it doesn't support C++11 good enough).
[Bug c/79610] missing space in diagnostic: %qD must be a global variable in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79610 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- This is fixed on the trunk now.
[Bug c++/79627] Ice with type of VLA in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79627 --- Comment #1 from Jakub Jelinek --- This is nasty, all we have is a SAVE_EXPR that is evaluated both outside of the lambda and inside of it, so ideally we'd capture a temporary assigned that SAVE_EXPR and use it inside of the lambda. But no idea how to find out that the SAVE_EXPR actually is evaluated also outside of the lambda.
[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434 --- Comment #2 from Paul Thomas --- Author: pault Date: Mon Feb 20 09:42:48 2017 New Revision: 245595 URL: https://gcc.gnu.org/viewcvs?rev=245595&root=gcc&view=rev Log: 2017-02-20 Paul Thomas PR fortran/79434 * parse.c (check_component, parse_union): Whitespace. (set_syms_host_assoc): For a derived type, check if the module in which it was declared is one of the submodule ancestors. If it is, make the components public. Otherwise, reset attribute 'host_assoc' and set 'use-assoc' so that encapsulation is preserved. 2017-02-20 Paul Thomas PR fortran/79434 * gfortran.dg/submodule_25.f08 : New test. Added: trunk/gcc/testsuite/gfortran.dg/submodule_25.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug target/79581] VFP4 slower than VFP3 in C-ray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79581 --- Comment #3 from ktkachov at gcc dot gnu.org --- I can't reproduce the difference on my machine. Judging by your -mcpu option is this on a Cortex-A5? As far as codegen goes the major difference I can see is that the vfpv4 version generates vfma instructions instead of vmla ones. Also there are cases where the vfpv3 version will generate multiple vmls instructions whereas the vfpv4 one will generate an explicit vneg followed by vfma instructions
[Bug sanitizer/79589] ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-20
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed. It had been rejected before with
error: expected unqualified-id before ‘[’ token
etc., then starting with r242377 I see
/home/brq/mpolacek/decomp18.C:10:72: internal compiler error: in quick_push, at
vec.h:863
for (auto & [ b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s ] : a) //
{ dg-warning "decomposition declaration only available with" "" { target
c++14_down } }
^
0x88e4af vec::quick_push(tree_node* const&)
../../gcc/vec.h:863
0x88db2f vec::quick_push(tree_node* const&)
../../gcc/vec.h:1540
0x8d1da0 cp_parser_range_for
../../gcc/cp/parser.c:11503
0x8d19ac cp_parser_for
../../gcc/cp/parser.c:11424
0x8d3278 cp_parser_iteration_statement
../../gcc/cp/parser.c:11957
0x8cff51 cp_parser_statement
../../gcc/cp/parser.c:10551
0x8d0e3e cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11016
0x8d0d39 cp_parser_compound_statement
../../gcc/cp/parser.c:10970
0x8e43c5 cp_parser_function_body
../../gcc/cp/parser.c:21347
0x8e458e cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21383
0x8ed6ba cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26141
0x8ed4be cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26053
0x8dfe27 cp_parser_init_declarator
../../gcc/cp/parser.c:19099
0x8d49ce cp_parser_simple_declaration
../../gcc/cp/parser.c:12761
0x8d45ab cp_parser_block_declaration
../../gcc/cp/parser.c:12588
0x8d432e cp_parser_declaration
../../gcc/cp/parser.c:12485
0x8d3e80 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12361
0x8c2d02 cp_parser_translation_unit
../../gcc/cp/parser.c:4367
0x912757 c_parse_file()
../../gcc/cp/parser.c:38252
0xabc69e c_common_parse_file()
../../gcc/c-family/c-opts.c:1086
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
and then since r242828 the gimplify_expr.
[Bug sanitizer/79589] ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589 --- Comment #2 from Marek Polacek --- The problem seems to be that we've got a COMPOUND_EXPR with null: , SAVE_EXPR <__for_begin.0>;
[Bug c++/79629] ICE on invalid code in tsubst_copy, at cp/pt.c:14477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79629 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- ICEs starting with r166167, because it has been rejected because C++11 support wasn't good enough.
[Bug tree-optimization/79621] [7 Regression] ICE in operator[], at vec.h:732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79621
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #2 from Martin Liška ---
Leaving to Jeff, there's a looping BB (bb 4):
h6 (int zb, int e7)
{
int gv;
int b5.1_1;
int b5.2_2;
int _3;
int b5.4_4;
int _24;
int b5.2_25;
int b5.4_26;
[4.41%]:
b5.4_4 = b5;
if (b5.4_4 > 0)
goto ; [85.00%]
else
goto ; [15.00%]
[37.50%]:
b5.1_1 = b5.4_4;
[75.00%]:
# gv_20 = PHI <1(3), 1(5), gv_16(4)>
# e7_11 = PHI
b5.2_2 = b5;
_3 = b5.2_2 / e7_11;
b5 = _3;
gv_16 = gv_20 + 1;
if (gv_16 != 4)
goto ; [75.00%]
else
goto ; [25.00%]
[9.05%]:
if (zb_12(D) != 0)
goto ; [94.12%]
else
goto ; [5.88%]
[18.76%]:
# zb_5 = PHI <0(4)>
# e7_10 = PHI <0(4)>
b5.4_26 = b5;
if (b5.4_26 > 0)
goto ; [85.00%]
else
goto ; [15.00%]
[4.41%]:
return;
[75.00%]:
# gv_7 = PHI <1(6)>
# e7_9 = PHI <0(6)>
b5.2_25 = b5;
__builtin_trap ();
[75.00%]:
_24 = b5.2_2 / e7_11;
b5 = _3;
gv_19 = gv_20 + 1;
if (gv_16 != 4)
}
That repeatedly calls isolate_path in following context:
#0 isolate_path (bb=0x768824e0, duplicate=0x769cb340,
e=0x76883ee0, stmt=0x769bf000, op=0x76881d38, ret_zero=false) at
../../gcc/gimple-ssa-isolate-paths.c:144
#1 0x010459b0 in find_implicit_erroneous_behavior () at
../../gcc/gimple-ssa-isolate-paths.c:439
#2 0x01045cb3 in gimple_ssa_isolate_erroneous_paths () at
../../gcc/gimple-ssa-isolate-paths.c:578
#3 0x01045dad in (anonymous
namespace)::pass_isolate_erroneous_paths::execute (this=0x1dd74e0) at
../../gcc/gimple-ssa-isolate-paths.c:630
where duplicate->index == 8
(gdb) p debug_gimple_stmt(phi)
e7_11 = PHI
and i == 3.
[Bug sanitizer/79589] ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589 --- Comment #3 from Jakub Jelinek --- I'll have a look, as it is decomp related, it is most likely my fault.
[Bug target/59371] [5/6/7 Regression] Performance regression in GCC 4.8 and later versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #21 from Aldy Hernandez --- Assuming that changing the condition of the loop to !=, would fix the regression, could we use range info to determine this? For instance, right before the ivopts pass, we have: [15.00%]: # RANGE [0, 65535] NONZERO 65535 _19 = (int) c_11(D); if (_19 > 0) goto ; [85.00%] else goto ; [15.00%] [12.75%]: [85.00%]: # p_20 = PHI # i_21 = PHI # x_22 = PHI _1 = *p_20; x_13 = _1 + x_22; p_14 = p_20 + 4; # RANGE [0, 65535] i.1_2 = (unsigned short) i_21; # RANGE [0, 65535] _3 = i.1_2 + 1; i_15 = (short int) _3; # RANGE [-32768, 32767] _4 = (int) i_15; if (_4 < _19) goto ; [85.00%] else goto ; [15.00%] The range for the max value `c' (_19) is [0..65535]. So if we know that the induction variable `i' (_4) starts at the lower end of that (0), and we increment the IV by 1, then we could always replace the < by a !=, right? This would avoid having to do loop versioning. If this is acceptable, would we do this in the ivopts pass? If so, I guess we could start by explaining to the pass that _4 is an IV. Because right now I see that we determine that everything but _4 is an IV: i_21, i.1_2, _3, i_15. Thoughts/hints greatly appreciated :).
[Bug target/79619] store via pointer obtained from alternate address space offset 0 dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79619
--- Comment #3 from Richard Biener ---
Note that this fix doesn't properly ensure that ADDR_SPACE_CONVERT of 0 from
generic to non-generic address space "magically changes" from nothing_id to
nonlocal_id, thus if you hide the constant:
void bug(void)
{
unsigned long ptr = 0;
*(*(char*__seg_fs*)ptr) = 1;
}
you get, with -O -fno-tree-ccp -fno-tree-forwprop
[0.00%]:
# PT = null
_2 = MEM[(char * *)0B];
*_2 = 1;
again (-fno-tree-ccp -fno-tree-forwprop avoid propagating the literal zero
before points-to analysis runs, CSE later does this but it's too late).
After points-to we see
[0.00%]:
ptr_3 = 0;
# PT = null
_1 = (char * *) ptr_3;
# PT = null
_2 = *_1;
*_2 = 1;
note this isn't an ADDR_SPACE_CONVERT_EXPR but a NOP_EXPR (integer to pointer
conversion). points-to tracks pointers through integers (not treating
integers as general escape points) which then means that when using
non-generic address-spaces you have to treat integer zero as pointing to
any global... that's quite pessimizing for example for a memset (.., 0, ...).
IMHO it's advisable to not use objects at address zero even in non-generic
address-spaces.
As a workaround for the above we could simply treat non-generic address-spaces
as always pointing to anything (disabling PTA for non-generic address-space
pointers). Or only do this at such conversion sites.
[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397
--- Comment #26 from rguenther at suse dot de ---
On Fri, 17 Feb 2017, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397
>
> --- Comment #25 from Jeffrey A. Law ---
> "When doing so allows for simplification" is actually a pretty low bar here.
> We just have to prove the widening cast is a common subexpression. Once we do
> that, we know widening is a win. And that's relatively easy to discover. You
> go back to the SSA_NAME_DEF_STMT of the object you want to widen, then walk
> over its immediate uses to see if one is a proper widening op that dominates
> the expression we're trying to simplify.
>
> That's it, nothing else needed to prove profitability. We only get ~20 hits
> in
> a bootstrap, but I didn't expect this idiom to show up all that much.
I find this kind of "technique" of finding CSE opportunities quite ugly
and I'm not sure where you'd actually implement this...
>
> --
>
> Trying to do all the pattern matching in phi-opt and ultimately generate the
> min/max is going to be *hideous* because we're trying to do too many things
> at
> once. We have components of CSE, VRP and DCE that we'd have to bring into
> phi-opt, which seems wrong to me.
Well, we are pattern matching the overflow builtins as well. I think
it would be quite natural to pattern match saturating operations with
the premise to generate better code for them (either by generic expansion
to min/max or by utilizing CPU instructions -- I think SSE has saturating
ops for example). You don't really need CSE, VRP and DCE, you "simply"
pattern match the comparisons. You'd then replace the PHI node by
the saturated op and let DCE do the rest for you.
> Contrast that to simplifying the IL like my match.pd pattern does. We make a
> simple, profitable, change to the IL. That one profitable change in the IL
> has
> ripple effects that allow subsequent passes to do their jobs with the final
> result that the minmax detection code is presented with exactly the IL it
> knows
> how to transform.
>
> --
>
> Alternately (and I haven't prototyped this) we could try again to look at this
> as a redundancy elimination problem.
>
> Given X = A + B in DOM, where A comes from a narrowed operand (A'). Lookup a
> widened B in the expression table (B'). If found, then lookup A' + B'. If
> found (lhs), then replace X = A + B with X = (typeof X) ((lhs) & mask).
>
> That's essentially doing the same thing as the prototype match.pd pattern.
> Except that we know the operand widening as well as the widened arithmetic are
> both CSEs.
CSE already does similar stuff for loads, transparently adding
VIEW_CONVERT_EXPRs. I've added generic helpers for this
(vn_nary_build_or_lookup). The question is if it's worth it.
You'd basically add to the list of special patterns in visit_nary_op
where we already handle ops in different sign (you'd add "op in different
width" and possibly add two stmts instead of one - the conversion and
the masking).
Oh, happens to be a patch in my local tree only (no longer remember
what was the reason to invent it but surely the question is how
many of these special-cases are worth the extra lookups)
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 245417)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3453,17 +3493,78 @@ visit_copy (tree lhs, tree rhs)
static bool
visit_nary_op (tree lhs, gimple *stmt)
{
- bool changed = false;
tree result = vn_nary_op_lookup_stmt (stmt, NULL);
-
if (result)
-changed = set_ssa_val_to (lhs, result);
- else
-{
- changed = set_ssa_val_to (lhs, lhs);
- vn_nary_op_insert_stmt (stmt, lhs);
+return set_ssa_val_to (lhs, result);
+ else if (INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+ && (TYPE_PRECISION (TREE_TYPE (lhs))
+ == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (lhs
+ && is_gimple_assign (stmt))
+{
+ /* For operations on integers that have the same result independent
+ of the signedness of their operands try to lookup a result with
+opposite sign. */
+ enum tree_code code = gimple_assign_rhs_code (stmt);
+ switch (code)
+ {
+ case NEGATE_EXPR:
+ {
+ tree type = TREE_TYPE (lhs);
+ type = signed_or_unsigned_type_for (! TYPE_UNSIGNED (type),
type);
+ tree ops[3];
+ ops[0] = gimple_assign_rhs1 (stmt);
+ ops[0] = vn_nary_op_lookup_pieces (1, NOP_EXPR, type, ops,
NULL);
+ if (ops[0])
+ {
+ ops[0] = vn_nary_op_lookup_pieces (1, code, type,
+ ops, NULL);
+ if (ops[0])
+ {
+ result = vn_nary_build_or_lookup (NOP_EXPR,
+ TREE_TYPE (lhs),
ops);
+
[Bug c++/64488] [c++11] Expand initializer list with lambdas in variadic template. Reject valid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64488
Vittorio Romeo changed:
What|Removed |Added
CC||vittorio.romeo at outlook dot
com
--- Comment #3 from Vittorio Romeo ---
Further simplification:
template
void foo()
{
using arr = int(*[])();
(void) arr{[]{ return Is; }...};
}
int main() { foo<1,2,3>(); }
* clang++ 3.3 (up to 5.0) happily compiles the code with -std=c++11.
* g++ 4.7 (up to 7.0) fails to compile with -std=c++11 (or c++14/c++1z)
[Bug fortran/79382] DTIO ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382 --- Comment #8 from Paul Thomas --- Author: pault Date: Mon Feb 20 10:52:50 2017 New Revision: 245596 URL: https://gcc.gnu.org/viewcvs?rev=245596&root=gcc&view=rev Log: 2017-02-16 Paul Thomas PR fortran/79382 * decl.c (access_attr_decl): Test for presence of generic DTIO interface and emit error if not present. 2017-02-16 Paul Thomas PR fortran/79382 * io/transfer.c (check_dtio_proc): New function. (formatted_transfer_scalar_read): Use it. (formatted_transfer_scalar_write): ditto. 2017-02-16 Paul Thomas PR fortran/79382 * gfortran.dg/dtio_10.f90 : Change test of error message. * gfortran.dg/dtio_23.f90 : New test. * gfortran.dg/dtio_24.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/dtio_23.f90 trunk/gcc/testsuite/gfortran.dg/dtio_24.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dtio_10.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug sanitizer/79589] ICE in gimplify_compound_expr (gimplify.c:5712) with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40780&action=edit gcc7-pr79589.patch Untested fix.
[Bug fortran/71838] ICE with OpenCoarrays on submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838 --- Comment #7 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #6) > I get the ICE with the following trivial submodule > > submodule ( cgca_m3clvg ) m3clvg_sm3 > > implicit none > > contains > > module procedure cgca_clvgp > > end procedure cgca_clvgp > > end submodule m3clvg_sm3 > > !-( Dominique, This now produces: [pault@pc30 pr71838]$ ~/irun/bin/gfortran -static-libgfortran p*.f90 f951: Fatal Error: Module file ‘cgca_m3clvg.smod’ has not been generated, either because the module does not contain a MODULE PROCEDURE or there is an error in the module. compilation terminated. Is the original bug similarly fixed? Ciao Paul
[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to Jerry DeLisle from comment #3) > (In reply to janus from comment #2) > > (In reply to janus from comment #0) > > > It seems like the first character is being swallowed somewhere ... > > > > Moreover the EOF is supposed to be an EOR? > > I will start looking at this. I wonder off hand if we have an EOF because we > start reading one position off. I will see what I can figure out. Hi Jerry, I was just reviewing all the outstanding DTIO PRs. Did you get anywhere with this one? Cheers Paul
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
--- Comment #4 from Jakub Jelinek ---
Indeed, consider e.g.
// PR c++/79588
// { dg-do compile }
// { dg-options "-Wrestrict" }
void foo (char *__restrict, char *__restrict = __null);
template
void
bar (char **p)
{
foo (p[0], p[0]); // { dg-warning "to restrict-qualified parameter
aliases with" }
foo (p[0], p[N]); // { dg-warning "to restrict-qualified parameter
aliases with" }
}
void
baz (char **p)
{
bar<0> (p);
}
where there is no warning in the second foo invocation, because it is done too
early.
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 mpf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpf at gcc dot gnu.org
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Indeed, consider e.g.
> // PR c++/79588
> // { dg-do compile }
> // { dg-options "-Wrestrict" }
>
> void foo (char *__restrict, char *__restrict = __null);
>
> template
> void
> bar (char **p)
> {
> foo (p[0], p[0]); // { dg-warning "to restrict-qualified parameter aliases
> with" }
> foo (p[0], p[N]); // { dg-warning "to restrict-qualified parameter aliases
> with" }
> }
>
> void
> baz (char **p)
> {
> bar<0> (p);
> }
>
> where there is no warning in the second foo invocation, because it is done
> too early.
Ah, thanks for pointing out! I didn't realize the issue with templates.
Um, should the warning then be moved to middle-end instead (maybe as early
gimple pass) ?
Thanks,
Prathamesh
[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
--- Comment #6 from Richard Biener ---
For a testcase trying to show the issue:
double U[1024];
double V[1024];
void foo (void)
{
for (unsigned i = 1; i < 1023; ++i)
V[i] = U[i-1] + U[i] + U[i+1];
}
we get from PRE (.optimized, w/ IVO disabled):
[1.00%]:
pretmp_19 = U[0];
pretmp_21 = U[1];
[99.00%]:
# i_15 = PHI <_5(3), 1(2)>
# prephitmp_20 = PHI
# prephitmp_22 = PHI <_6(3), pretmp_21(2)>
# ivtmp_1 = PHI
_5 = i_15 + 1;
_6 = U[_5];
_17 = _6 + prephitmp_22;
_7 = _17 + prephitmp_20;
V[i_15] = _7;
ivtmp_18 = ivtmp_1 + 4294967295;
if (ivtmp_18 != 0)
goto ; [98.99%]
else
goto ; [1.01%]
[1.00%]:
return;
while predcom does the same transform but unrolls the loop:
[50.00%]:
# i_15 = PHI <1(2), _43(3)>
# ivtmp_18 = PHI <1022(2), ivtmp_49(3)>
# U_I_lsm0.3_30 = PHI <_33(2), _6(3)>
# U_I_lsm1.4_31 = PHI <_34(2), _44(3)>
# ivtmp_50 = PHI <1021(2), ivtmp_51(3)>
_5 = i_15 + 1;
_6 = U[_5];
_37 = U_I_lsm0.3_30 + U_I_lsm1.4_31;
_7 = _6 + _37;
V[i_15] = _7;
_43 = i_15 + 2;
_44 = U[_43];
_46 = U_I_lsm1.4_31 + _44;
_47 = _6 + _46;
V[_5] = _47;
ivtmp_49 = ivtmp_18 + 4294967294;
ivtmp_51 = ivtmp_50 + 4294967294;
if (ivtmp_51 > 1)
goto ; [98.00%]
else
goto ; [2.00%]
register pressure created by both are the same.
For the more complex testcase PRE misses the "combination chains" because
we exclude them as
Found partial redundancy for expression {plus_expr,_2,_3} (0012)
Skipping insertion of phi for partial redundancy: Looks like an induction
variable
when we mitigate that PRE can handle all cases where association is correct.
predictive commoning in addition to that does re-association of adds to
enable more chains (so the mitigation doesn't help for the original testcase).
Testcase that is helped this way:
double U[1024], W[1024];
double V[1024];
void foo (void)
{
for (unsigned i = 1; i < 1023; ++i)
V[i] = (U[i-1] + W[i-1]) + (U[i] + W[i]) + (U[i+1] + W[i+1]);
}
and PRE produces
[99.00%]:
# i_21 = PHI <_9(3), 1(2)>
# prephitmp_43 = PHI <_23(3), _42(2)>
# prephitmp_45 = PHI
# ivtmp_40 = PHI
_9 = i_21 + 1;
_10 = U[_9];
_11 = W[_9];
_23 = _10 + _11;
_1 = _23 + prephitmp_43;
_13 = _1 + prephitmp_45;
V[i_21] = _13;
ivtmp_38 = ivtmp_40 + 4294967295;
if (ivtmp_38 != 0)
goto ; [98.99%]
else
goto ; [1.01%]
note how we PRE U[] + W[] rather than U[] and W[].
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 245594)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -3008,7 +3008,9 @@ insert_into_preds_of_block (basic_block
EDGE_PRED (block, 1)->src);
/* Induction variables only have one edge inside the loop. */
if ((firstinsideloop ^ secondinsideloop)
- && expr->kind != REFERENCE)
+ && expr->kind != REFERENCE
+ && (expr->kind != NARY
+ || INTEGRAL_TYPE_P (PRE_EXPR_NARY (expr)->type)))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Skipping insertion of phi for partial
redundancy: Looks like an induction variable\n");
for the original testcase in this bug this removes two IVs (but the IV
detection is lame). What we mostly want to avoid here is creating
IVs for derived IVs, it might be enough to disregard
&& expr->kind == NARY
&& (PRE_EXPR_NARY (expr)->opcode == PLUS_EXPR
|| PRE_EXPR_NARY (expr)->opcode == POINTER_PLUS_EXPR
|| PRE_EXPR_NARY (expr)->opcode == MINUS_EXPR)
&& TREE_CODE (PRE_EXPR_NARY (expr)->op[1]) == INTEGER_CST)
but as said, a solution inside PRE might improve some cases but it won't
catch the cases needing re-association. Running pcom before PRE would
be best here but then we've been there before (and put pcom after
vectorization from previously before it).
[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 --- Comment #18 from mpf at gcc dot gnu.org --- Author: mpf Date: Mon Feb 20 12:07:06 2017 New Revision: 245599 URL: https://gcc.gnu.org/viewcvs?rev=245599&root=gcc&view=rev Log: Tighten condition for converting SUBREG reloads from OP_OUT to OP_INOUT gcc/ PR target/78660 * lra-constraints.c (curr_insn_transform): Tighten condition for converting SUBREG reloads from OP_OUT to OP_INOUT. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 --- Comment #17 from mpf at gcc dot gnu.org --- Author: mpf Date: Mon Feb 20 12:06:56 2017 New Revision: 245598 URL: https://gcc.gnu.org/viewcvs?rev=245598&root=gcc&view=rev Log: Handle WORD_REGISTER_OPERATIONS when reloading (subreg (reg)) gcc/ PR target/78660 * lra-constraints.c (curr_insn_transform): Handle WORD_REGISTER_OPERATIONS requirements when reloading SUBREGs. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 --- Comment #6 from mpf at gcc dot gnu.org --- Author: mpf Date: Mon Feb 20 12:07:23 2017 New Revision: 245601 URL: https://gcc.gnu.org/viewcvs?rev=245601&root=gcc&view=rev Log: Ensure the mode used to create split registers is suppported gcc/ PR target/78012 * lra-constraints.c (split_reg): Check requested split mode is supported by the register. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug tree-optimization/45397] [5/6/7 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397
--- Comment #27 from Richard Biener ---
patch misses some ops = {} and ops[1] = NULL_TREE; to avoid ICEing.
[Bug libstdc++/79114] [6 Regression] std::throw_with_nested("string literal") is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79114 --- Comment #10 from Jonathan Wakely --- FTR this was found by https://github.com/antlr/antlr4/issues/1608
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 --- Comment #6 from Jakub Jelinek --- Created attachment 40781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40781&action=edit gcc7-pr79588.patch Likely yes. In the mean time I've moved it at least to a better place in the C/C++ FE.
[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587
Martin Liška changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
Known to work||4.5.4, 4.6.4, 4.7.4, 4.8.5
Known to fail||4.9.4, 5.4.0, 6.3.0
--- Comment #5 from Martin Liška ---
Ok, there's a simple test-case:
unsigned long global = -1099511627775;
unsigned long
__attribute__((noinline))
test(unsigned long v, unsigned long v2)
{
unsigned long x = v % v2;
return x;
}
int main(int argc, char **argv)
{
unsigned long r = 0;
for (int i = 0; i < 100; i++)
r += test(argc, global);
return r;
}
Problem is that we use unsigned long type for instrumentation, but gcoc_type is
a signed type. Thus causing issues. I'll come up with a patch for the PR.
[Bug target/79568] ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Feb 20 12:52:21 2017 New Revision: 245602 URL: https://gcc.gnu.org/viewcvs?rev=245602&root=gcc&view=rev Log: PR target/79568 * config/i386/i386.c (ix86_expand_builtin): Handle OPTION_MASK_ISA_AVX512VL and OPTION_MASK_ISA_64BIT in ix86_builtins_isa[fcode].isa as a requirement of those flags and any other flag in the bitmask. (ix86_init_mmx_sse_builtins): Use 0 instead of ~OPTION_MASK_ISA_64BIT as mask. * config/i386/i386-builtin.def (__builtin_ia32_rdtsc, __builtin_ia32_rdtscp, __builtin_ia32_pause, __builtin_ia32_bsrsi, __builtin_ia32_rdpmc, __builtin_ia32_rolqi, __builtin_ia32_rolhi, __builtin_ia32_rorqi, __builtin_ia32_rorhi): Likewise. * gcc.target/i386/pr79568-1.c: New test. * gcc.target/i386/pr79568-2.c: New test. * gcc.target/i386/pr79568-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr79568-1.c trunk/gcc/testsuite/gcc.target/i386/pr79568-2.c trunk/gcc/testsuite/gcc.target/i386/pr79568-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-builtin.def trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/79568] ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/79593] [6/7 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593 --- Comment #3 from Katsunori Kumatani --- Hi, sorry I forgot to mention, I used Godbolt's Compiler Explorer to test it on GCC 5 and 7 as I only have version 6 deployed on this machine. On my end, it probably used march 'native' by default (?) but I omitted it for obvious reasons. The reason I find this important is because in your case, you have "sahf" and I see your code doesn't use "fcomi" instruction which means it targets an older architecture. Try compile with -march=core2 -m32 -Ofast -mfpmath=387 By the way I'm not talking about the fact that it is used multiple times, but that it "loads" it (pushes it on the stack) and then pops it in a bit without any effect in-between that requires this! Version 5 does not do this. It's not the "double load" that is the issue, but the "double load followed by a pop later", because it is useless and v5 does it better. Look at this following small example at the beginning (cut to make it shorter), try it on godbolt.org to see what I mean if you can't reproduce. If you compare them side-by-side you'll only notice this small difference: GCC 6: fldz sub esp, 20 mov eax, DWORD PTR [esp+24] mov edx, DWORD PTR [esp+28] cmp DWORD PTR [eax], edx jbe .L1 fld DWORD PTR global_data fld st(0) # this fld DWORD PTR global_data+4 fxchst(3) fucomip st, st(2) fstpst(1) # and this are useless/not in v5 GCC 5: fldz sub esp, 20 mov eax, DWORD PTR [esp+24] mov edx, DWORD PTR [esp+28] cmp DWORD PTR [eax], edx jbe .L2 fld DWORD PTR global_data fld DWORD PTR global_data+4 fxchst(2) fucomip st, st(1) ja .L20 fxchst(1) fsubr DWORD PTR [eax+4] As you can see, the only difference on this beginning part between version 5 and 6 is that 6 doubles the top of the stack, only to pop it later. I mean, even if it wanted to "store" the top on a different register on the stack, it could just use "fst" instruction, without the 'p' which implies a pop. This way, it could still do its logic but without having to duplicate the top of the stack needlessly. Thus it would get rid of the "fld st(0)" but not the fst if it needed it later in another register. Of course in this example the duplication isn't so bad, because it uses few registers. But it's a bad case for real code because it will have to spill st(7) on the stack (when stack is full) in order to duplicate it... IMO it wastes register stack space for no reason (even if the load is cheap). In any case is it possible to make it behave like Godbolt's version 5? (idk what settings it uses, though). I tested on it just to make sure it didn't always behave this way and I was right at least with certain options... BTW, any clue why version 7 does even worse in respect to that stack spill? In version 5 and 6, this part: ja .L20 fxchst(1) fsubr DWORD PTR [eax+4] Becomes this in v7: mov eax, DWORD PTR [eax+4] ja .L20 mov DWORD PTR [esp], eax fld DWORD PTR [esp] fsubrp st(2), st Which is obviously a quite big penalty just for subtracting a float from a long double (*two* extra memory operations, three in total). Thanks :)
[Bug target/79593] [6/7 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593 --- Comment #4 from Katsunori Kumatani --- I forgot to mention that in the particular above example, it is obvious the "fstp" is useless. If you remove the "fld st(0)" and then the 'p' from the fstp, you end up with "fst st(0)" which is basically a no-op. My reasoning was for different cases, though, where one might need the fst but not the fld.
[Bug target/79494] [5/6/7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79494 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- ICEs since r176705, guess we got wrong-debug before that.
[Bug fortran/79599] typo in diagnostic gfc_error ("DTIO dummy argument at %L be a scalar"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79599 --- Comment #1 from Paul Thomas --- Author: pault Date: Mon Feb 20 14:17:42 2017 New Revision: 245603 URL: https://gcc.gnu.org/viewcvs?rev=245603&root=gcc&view=rev Log: 2017-02-20 Paul Thomas PR fortran/79599 * interface.c (check_dtio_arg_TKR_intent): Supply 'must' missing from error message. 2017-02-20 Paul Thomas PR fortran/79523 * interface.c (gfc_find_typebound_dtio_proc): Guard test for flavor attribute by checking that symbol is resolved. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c
[Bug fortran/79523] [7 Regression] valgrind error for gcc/testsuite/gfortran.dg/dtio_13.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79523 --- Comment #2 from Paul Thomas --- Author: pault Date: Mon Feb 20 14:17:42 2017 New Revision: 245603 URL: https://gcc.gnu.org/viewcvs?rev=245603&root=gcc&view=rev Log: 2017-02-20 Paul Thomas PR fortran/79599 * interface.c (check_dtio_arg_TKR_intent): Supply 'must' missing from error message. 2017-02-20 Paul Thomas PR fortran/79523 * interface.c (gfc_find_typebound_dtio_proc): Guard test for flavor attribute by checking that symbol is resolved. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c
[Bug fortran/79599] typo in diagnostic gfc_error ("DTIO dummy argument at %L be a scalar"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79599 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Paul Thomas --- Thanks for the report. Fixed. Paul
[Bug fortran/79523] [7 Regression] valgrind error for gcc/testsuite/gfortran.dg/dtio_13.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79523 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Bill Schmidt --- So, fixed everywhere.
[Bug c++/52036] C++11 allows template parameters to have internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment #11 from Michel Morin ---
The internal linkage testcase
template class TestClass {
/* ... */
};
constexpr float pi = 3.14;
int main()
{
TestClass test;
}
compiles successfully from GCC 6.
However, Richard's testcase (i.e. testcase in the Standard)
template class X {
/* ... */
};
const char p[] = "Vivisectionist";
X x;
fails to compile even on GCC 7 (in C++11/14 modes) with this error message
error: the value of 'p' is not usable in a constant expression
X x;
^
note: 'p' was not declared 'constexpr'
const char p[] = "Vivisectionist";
As the message suggests, if `p` is declared as `constexpr` it compiles fine.
Note that in a C++1z mode (from GCC 5) it compiles fine without `constexpr`.
[Bug target/79494] [5/6/7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79494 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40782&action=edit gcc7-pr79494.patch Untested fix. The problem is that __morestack call is before the prologue, but the middle-end thinks it can do non-local gotos and then we have abnormal edges from both __morestack (before prologue) and the nested function call (after prologue) and CFI on those two edges can't match.
[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587 --- Comment #6 from Martin Liška --- Created attachment 40783 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40783&action=edit Untested patch Untested patch, can you please test building Python with the patch? Thanks
[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79537 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Mon Feb 20 15:05:53 2017 New Revision: 245604 URL: https://gcc.gnu.org/viewcvs?rev=245604&root=gcc&view=rev Log: PR middle-end/79537 * gimplify.c (gimplify_expr): Handle unused *&&L;. * gcc.dg/comp-goto-4.c: New. Added: trunk/gcc/testsuite/gcc.dg/comp-goto-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/79537] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:12009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79537 Marek Polacek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |gimplify_expr, at |gimplify_expr, at |gimplify.c:12009|gimplify.c:12009 --- Comment #8 from Marek Polacek --- Fixed on the trunk so far.
[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #19 from Tony Kelman --- The patch also applies and fixes the problem on the gcc-5-branch. I haven't tried with trunk.
[Bug tree-optimization/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79345 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I'll have a look.
[Bug sanitizer/79558] [5/6/7 Regression] ICE: Segfault in ubsan_type_descriptor, at ubsan.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79558 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Mon Feb 20 15:50:23 2017 New Revision: 245605 URL: https://gcc.gnu.org/viewcvs?rev=245605&root=gcc&view=rev Log: PR sanitizer/79558 * ubsan.c (ubsan_type_descriptor): Check if TYPE_MAX_VALUE is null. * c-c++-common/ubsan/bounds-14.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/bounds-14.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug sanitizer/79558] [5/6 Regression] ICE: Segfault in ubsan_type_descriptor, at ubsan.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79558 Marek Polacek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE: |[5/6 Regression] ICE: |Segfault in |Segfault in |ubsan_type_descriptor, at |ubsan_type_descriptor, at |ubsan.c:412 |ubsan.c:412 --- Comment #6 from Marek Polacek --- Fixed on the trunk so far.
[Bug target/79581] VFP4 slower than VFP3 in C-ray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79581 --- Comment #4 from PeteVine --- > Judging by your -mcpu option is this on a Cortex-A5? Yes, if you look at the results on a Cortex A53 running armv7 code, it doesn't reproduce either, and A5-codegen is king :) (hopefully due to in-order design or sth) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659#c12 A quick question regarding -mcpu=cortex-a5 codegen; is there a similar switch to llvm's `-slowfpvmlx` feature? (disable slow vmla/vmls), which the nice ARM guy divulged here: https://bugs.llvm.org//show_bug.cgi?id=26135#c9 or is it a non-issue in gcc?
[Bug tree-optimization/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79345 --- Comment #6 from Jakub Jelinek --- Created attachment 40784 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40784&action=edit gcc7-pr79345.patch Untested fix. That said, I think (most likely just for GCC8) it would be very much beneficial to walk_aliased_defs as the comment says, and if we run into aliased clobber that must overlap the read ref, warn (and if we don't find any aliased store too), with some cap on number of alias oracle queries.
[Bug target/78056] [7 Regression] build failure on Power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056 --- Comment #21 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon Feb 20 16:43:03 2017 New Revision: 245607 URL: https://gcc.gnu.org/viewcvs?rev=245607&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2017-02-20 Kelvin Nilsen PR target/78056 * gcc.target/powerpc/pr78056-8.c: Remove. Removed: trunk/gcc/testsuite/gcc.target/powerpc/pr78056-8.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/79151] Missed BB vectorization with strided/scalar stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151
--- Comment #5 from Thomas Koenig ---
(In reply to Richard Biener from comment #3)
> The question is of course whether vector division has comparable latency /
> throughput as the scalar one.
Here's a test case on a rather old CPU, a Core 2 Q8200:
$ cat foo.c
#include
double foo(double a, double b)
#ifdef SCALAR
{
return 1/a + 1/b;
}
#else
{
typedef double v2do __attribute__((vector_size (16)));
v2do x, y;
x[0] = a;
x[1] = b;
y = 1/x;
return y[0] + y[1];
}
#endif
#define NMAX 10
int main()
{
double a, b, s;
s = 0.0;
for (a=1.0; a
[Bug fortran/79617] missing space in diagnostic: IF clause without modifier at %L used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79617 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug ipa/79616] missing space in diagnostic: Inlined into %s which now has time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79616 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug c/79615] missing space in diagnostic: Substring out of bounds: lower bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79615 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug c/79613] missing space in diagnostic: GLOBAL CONST-PROP: Replacing reg %d in jump_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79613 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r245409.
[Bug fortran/79603] make diagnostics more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79603 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug c++/79608] missing space in error message "bepositive"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79608 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Roland Illig --- Fixed in r244245.
[Bug tree-optimization/79151] Missed BB vectorization with strided/scalar stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79151 --- Comment #6 from Thomas Koenig --- A few more test cases with a relatively recent trunk. POWER7: [tkoenig@gcc1-power7 ~]$ gcc -mcpu=power7 -O3 foo.c && time ./a.out 41.987257 real0m3.688s user0m3.685s sys 0m0.002s [tkoenig@gcc1-power7 ~]$ gcc -mcpu=power7 -DSCALAR -O3 foo.c && time ./a.out 41.987257 real0m7.317s user0m7.314s sys 0m0.003s Core(TM) i7-2600: tkoenig@gcc75:~$ gcc -march=native -O3 foo.c && time ./a.out 41.987257 real0m5.848s user0m5.848s sys 0m0.000s tkoenig@gcc75:~$ gcc -march=native -DSCALAR -O3 foo.c && time ./a.out 41.987257 real0m11.638s user0m11.640s sys 0m0.000s AMD Athlon(tm) II X4 640: tkoenig@gcc45:~$ gcc -O3 -march=native foo.c && time ./a.out 41.987257 real0m8.467s user0m7.648s sys 0m0.000s tkoenig@gcc45:~$ gcc -O3 -DSCALAR -march=native foo.c && time ./a.out 41.987257 real0m15.308s user0m14.284s sys 0m0.004s The exception is with aarch64, an AMD Opteron 1100: tkoenig@gcc117:~> gcc -O3 -march=native foo.c && time ./a.out 41.987257 real0m30.013s user0m30.010s sys 0m0.000s tkoenig@gcc117:~> gcc -O3 -DSCALAR -march=native foo.c && time ./a.out 41.987257 real0m30.013s user0m30.010s sys 0m0.000s Soo... not always profitable.
[Bug middle-end/79536] [5/6 Regression] ICE in fold_binary_loc, at fold-const.c:9060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79536 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Mon Feb 20 17:35:21 2017 New Revision: 245609 URL: https://gcc.gnu.org/viewcvs?rev=245609&root=gcc&view=rev Log: PR middle-end/79536 * fold-const.c (fold_negate_expr_1): Renamed from fold_negate_expr. (fold_negate_expr): New wrapper. * gcc.dg/torture/pr79536.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr79536.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/fold-const.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/79537] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:12009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79537 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Mon Feb 20 17:37:20 2017 New Revision: 245610 URL: https://gcc.gnu.org/viewcvs?rev=245610&root=gcc&view=rev Log: PR middle-end/79537 * gimplify.c (gimplify_expr): Handle unused *&&L;. * gcc.dg/comp-goto-4.c: New. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/comp-goto-4.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/gimplify.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/79536] [5/6 Regression] ICE in fold_binary_loc, at fold-const.c:9060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79536 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Fixed.
[Bug middle-end/79537] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:12009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79537 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Fixed.
[Bug sanitizer/79558] [5/6 Regression] ICE: Segfault in ubsan_type_descriptor, at ubsan.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79558 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Mon Feb 20 17:38:57 2017 New Revision: 245611 URL: https://gcc.gnu.org/viewcvs?rev=245611&root=gcc&view=rev Log: PR sanitizer/79558 * ubsan.c (ubsan_type_descriptor): Check if TYPE_MAX_VALUE is null. * c-c++-common/ubsan/bounds-14.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/bounds-14.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/ubsan.c
[Bug sanitizer/79558] [5/6 Regression] ICE: Segfault in ubsan_type_descriptor, at ubsan.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79558 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587 --- Comment #7 from Markus Trippelsdorf --- (In reply to Martin Liška from comment #6) > Created attachment 40783 [details] > Untested patch > > Untested patch, can you please test building Python with the patch? Thanks Works fine now, thanks.
[Bug c/79630] New: ICE in make_decl_rtl, at varasm.c:1311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79630 Bug ID: 79630 Summary: ICE in make_decl_rtl, at varasm.c:1311 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Version 5/6/7 (on x86_64 GNU/Linux) and files ./gcc.dg/nested-func-9.c ./gcc.target/i386/pr66817.c ./gcc.dg/torture/pr8081.c Maybe related to pr77383 -- but here not depending on -On. $ gcc-7-20170219 -mmpx -fcheck-pointer-bounds -c pr8081.c pr8081.c: In function 'main.chkp': pr8081.c:19:4: internal compiler error: in make_decl_rtl, at varasm.c:1311 a=retframe_block (); ~^~ 0xefe11e make_decl_rtl(tree_node*) ../../gcc/varasm.c:1307 0x8c4f03 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9765 0xf6c91d expand_normal ../../gcc/expr.h:282 0xf6c91d ix86_expand_builtin ../../gcc/config/i386/i386.c:36762 0x793166 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/builtins.c:6362 0x8c3dd4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10782 0x7a0bcd initialize_argument_information ../../gcc/calls.c:1589 0x7a3658 expand_call(tree_node*, rtx_def*, int) ../../gcc/calls.c:3275 0x8c29ac expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10785 0x8cffa6 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5552 0x8d1b90 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5321 0x7b785a expand_call_stmt ../../gcc/cfgexpand.c:2656 0x7b785a expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3571 0x7b785a expand_gimple_stmt ../../gcc/cfgexpand.c:3737 0x7b94ee expand_gimple_basic_block ../../gcc/cfgexpand.c:5744 0x7bf5b6 execute ../../gcc/cfgexpand.c:6357
[Bug c/79631] New: ICE tree check: expected integer_cst, have negate_expr in decompose, at tree.h:5255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79631 Bug ID: 79631 Summary: ICE tree check: expected integer_cst, have negate_expr in decompose, at tree.h:5255 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Version 5/6/7 (on x86_64 GNU/Linux) at -Os|1|2|3 and file ./gcc.dg/torture/pr71901.c $ gcc-7-20170219 -O2 -mmpx -fcheck-pointer-bounds -c pr71901.c pr71901.c: In function 'fn1.chkp': pr71901.c:5:6: internal compiler error: tree check: expected integer_cst, have negate_expr in decompose, at tree.h:5255 void fn1() ^~~ 0xea199c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9815 0x5e6764 tree_check(tree_node const*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3320 0x5e6764 wi::int_traits::decompose(long*, unsigned int, tree_node const*) ../../gcc/tree.h:5255 0xea6fa4 wi::int_traits::decompose(long*, unsigned int, tree_node const*) ../../gcc/tree.h:3267 0xea6fa4 wide_int_ref_storage::wide_int_ref_storage(tree_node const* const&, unsigned int) ../../gcc/wide-int.h:976 0xea6fa4 generic_wide_int >::generic_wide_int(tree_node const* const&, unsigned int) ../../gcc/wide-int.h:753 0xea6fa4 unsigned long wi::extract_uhwi(tree_node const* const&, unsigned int, unsigned int) ../../gcc/wide-int.h:3054 0xea6fa4 tree_int_cst_sign_bit(tree_node const*) ../../gcc/tree.c:7355 0xcbada2 chkp_is_constant_addr ../../gcc/tree-chkp-opt.c:244 0xcbd81a chkp_get_check_result ../../gcc/tree-chkp-opt.c:656 0xcbf4d5 chkp_remove_check_if_pass ../../gcc/tree-chkp-opt.c:699 0xcbf4d5 chkp_remove_constant_checks ../../gcc/tree-chkp-opt.c:829 0xcbf4d5 chkp_opt_execute ../../gcc/tree-chkp-opt.c:1288 0xcbf4d5 execute ../../gcc/tree-chkp-opt.c:1344
[Bug c/79632] New: params.def should not contain redundant comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79632 Bug ID: 79632 Summary: params.def should not contain redundant comments Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In params.def, PARAM_MAX_STORES_TO_SINK looks like this: /* Maximum number of conditional store pairs that can be sunk. */ DEFPARAM (PARAM_MAX_STORES_TO_SINK, "max-stores-to-sink", "Maximum number of conditional store pairs that can be sunk.", 2, 0, 0) The comment is an exact copy of the string literal. Therefore it is redundant and be removed. When fixing this, please check for similar occurrences in the same file.
[Bug c/79633] New: ICE in gimple_call_arg, at gimple.h:3163
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79633
Bug ID: 79633
Summary: ICE in gimple_call_arg, at gimple.h:3163
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
Version 5/6/7 (on x86_64 GNU/Linux) at -Os|1|2|3 and files
./gcc.target/i386/addr-space-1.c
./gcc.target/i386/addr-space-5.c
./gcc.target/i386/pr65523.c
./gcc.dg/torture/pr55890-2.c
./gcc.dg/torture/pr55890-3.c
$ cat pr55890-2.c
extern void *memcpy();
int main() { memcpy(); }
$ gcc-7-20170219 -O2 -mmpx -fcheck-pointer-bounds -c pr55890-2.c
pr55890-2.c: In function 'main.chkp':
pr55890-2.c:2:5: internal compiler error: in gimple_call_arg, at gimple.h:3163
int main() { memcpy(); }
^~~~
0xcbfc98 gimple_call_arg
../../gcc/gimple.h:3163
0xcbfc98 gimple_call_arg
../../gcc/gimple.h:3171
0xcbfc98 chkp_optimize_string_function_calls
../../gcc/tree-chkp-opt.c:981
0xcbfc98 chkp_opt_execute
../../gcc/tree-chkp-opt.c:1282
0xcbfc98 execute
../../gcc/tree-chkp-opt.c:1344
(gcc-5 backtrace differs)
[Bug c/79631] ICE tree check: expected integer_cst, have negate_expr in decompose, at tree.h:5255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79631 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
