[Bug tree-optimization/88014] New: Restrict/C2X/N2260 Restricted function argument

[mcccs at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88014

Bug ID: 88014
   Summary: Restrict/C2X/N2260 Restricted function argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

N2260 ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf )
has been integrated to C2X, according to
https://gustedt.wordpress.com/2018/11/12/c2x/ .

Code taken from the paper above:


#include 
void g(int **a, int *b)
{
*a = b;
}
int foo(int * restrict p, int *q)
{
g(&q, p); // effectively q = p
*p = 1;
*q = 2;
return *p + *q;
}
int main()
{
int x, y;
printf("%d", foo(&x, &y));
return 0;
}

Args: -O0

Result: 4 (correct)

Args: -fno-inline -O3

Result: 3 (incorrect)

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-14
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug tree-optimization/88015] New: [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015

Bug ID: 88015
   Summary: [9 Regression] ICE in dump_printf_loc, at
dumpfile.c:1287
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

That would be for David I guess:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/gomp/pr25990.c
-floop-nest-optimize -O3 -c
during GIMPLE pass: graphite
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/gomp/pr25990.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/gomp/pr25990.c:30:5: internal
compiler error: in dump_printf_loc, at dumpfile.c:1287
   30 | int main(int argc , char * argv[])
  | ^~~~
0x835297 dump_printf_loc(dump_flag, dump_location_t const&, char const*, ...)
/home/marxin/Programming/gcc/gcc/dumpfile.c:1287
0x1c8f934 translate_isl_ast_to_gimple::scop_to_isl_ast(scop*)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:1415
0x1c8fb50 graphite_regenerate_ast_isl(scop*)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:1474
0x1c89526 graphite_transform_loops()
/home/marxin/Programming/gcc/gcc/graphite.c:413
0x1c8977f graphite_transforms
/home/marxin/Programming/gcc/gcc/graphite.c:476
0x1c898a5 execute
/home/marxin/Programming/gcc/gcc/graphite.c:553

[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007

--- Comment #2 from rguenther at suse dot de  ---
On Tue, 13 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #1 from Jakub Jelinek  ---
> This is because parse_optimize_options has:
>   r = q = (char *) ggc_alloc_atomic (len2 + 3);
> and constructs in there the whole option, like "-falign-functions=16" , and
> then options processing comes and points arg into that string (so "16").
> As gcc_options is marked GTY, the const char * fields in there thus need to be
> either not GC memory at all, or they need to point at the start of a GC chunk,
> or into the middle of STRING_CST, everything else is disallowed.
> 
> So, either we need to pass down to the option processing info that the options
> are GC allocated and if we'd have arg pointing into the middle of such a
> string, ggc_strdup it, or maybe c-common.c should use XOBNEWVEC 
> (&opts_obstack,
> char, len2 + 3); instead of (char *) ggc_alloc_atomic (len2 + 3) ?

Using the opts_obstack sounds reasonable to me.

[Bug ipa/88016] New: [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474 since r262375

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88016

Bug ID: 88016
   Summary: [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474
since r262375
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Started with my commit:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr84100.c --param
ggc-min-expand=0 --param ggc-min-heapsize=0
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr84100.c: In function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr84100.c:15:1: internal
compiler error: in gt_ggc_m_S, at ggc-page.c:1474
   15 | }
  | ^
0x5f4fc3 gt_ggc_m_S(void const*)
/home/marxin/Programming/gcc/gcc/ggc-page.c:1474
0xabdc57 gt_ggc_mx_cl_optimization(void*)
/dev/shm/objdir/gcc/gtype-desc.c:1471
0x7b52de gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:487
0x7b4e28 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:294
0xa54a15 ggc_mark_root_tab
/home/marxin/Programming/gcc/gcc/ggc-common.c:77
0xa54c2c ggc_mark_roots()
/home/marxin/Programming/gcc/gcc/ggc-common.c:94
0x88f885 ggc_collect()
/home/marxin/Programming/gcc/gcc/ggc-page.c:2201
0x912851 cgraph_node::finalize_function(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cgraphunit.c:492
0x7b135f finish_function()
/home/marxin/Programming/gcc/gcc/c/c-decl.c:9596
0x81084c c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2369
0x81785f c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1651
0x8180a9 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1532
0x8180a9 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:19609
0x86aab0 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1150

[Bug ipa/88016] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474 since r262375

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88016

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-14
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Mine.

[Bug sanitizer/88017] New: ICE in expand_call, at calls.c:4220

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88017

Bug ID: 88017
   Summary: ICE in expand_call, at calls.c:4220
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Quite old one:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4b.c
-mabi=ms -fsanitize=thread
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4b.c:9:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h:50:1:
note: The ABI for passing parameters with 64-byte alignment has changed in GCC
4.6
   50 | bar (__m128 a1, __m512d a2, __m128i a3, va_list va_arglist)
  | ^~~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h:50:1:
warning: AVX512F vector argument without AVX512F enabled changes the ABI
[-Wpsabi]
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80969-4.h:51:1:
internal compiler error: in expand_call, at calls.c:4220
   51 | {
  | ^
0x8c4d41 expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:4218
0x8b4f15 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/marxin/Programming/gcc/gcc/builtins.c:8330
0x9e7ca7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10944
0x8d7528 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:279
0x8d7528 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2713
0x8d7528 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3650
0x8d7528 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3809
0x8d917f expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5845
0x8ddf17 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6450

[Bug sanitizer/88017] ICE in expand_call, at calls.c:4220

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88017

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-14
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Let me take it.

[Bug rtl-optimization/88018] New: [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88018

Bug ID: 88018
   Summary: [8/9 Regression] ICE in insert_insn_on_edge at
cfgrtl.c:1952 since r255066
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr69667.C
-fsanitize=thread -fno-ipa-pure-const -O1 -fno-inline-functions-called-once
...
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr69667.C: In function ‘int
bracket_and_solve_root_01(F, T, bool, Tol, unsigned int, Policy) [with F =
D; T = long double; Tol = void (*)(); Policy = A]’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr69667.C:83:1: internal
compiler error: Segmentation fault
   83 | }
  | ^
0xf1d35f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb1217c insert_insn_on_edge(rtx_def*, edge_def*)
/home/marxin/Programming/gcc/gcc/cfgrtl.c:1952
0xb1526f fixup_abnormal_edges()
/home/marxin/Programming/gcc/gcc/cfgrtl.c:3343
0xe8d2ad convert_regs
/home/marxin/Programming/gcc/gcc/reg-stack.c:3260
0xe8d2ad reg_to_stack
/home/marxin/Programming/gcc/gcc/reg-stack.c:3371
0xe8d2ad rest_of_handle_stack_regs
/home/marxin/Programming/gcc/gcc/reg-stack.c:3426
0xe8d2ad execute
/home/marxin/Programming/gcc/gcc/reg-stack.c:3457

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88018

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-14
  Known to work||7.3.0
   Target Milestone|--- |8.3
  Known to fail||8.2.0, 9.0

[Bug tree-optimization/88019] [9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5779

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88019

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Last reconfirmed||2018-11-14
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Martin Liška  ---
Most likely 9 regression.

[Bug tree-optimization/88019] New: [9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5779

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88019

Bug ID: 88019
   Summary: [9 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5779
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr68251.f90
-floop-nest-optimize -ftrapv -fno-tree-ch -O3 -fno-tree-ccp -fno-tree-forwprop
during GIMPLE pass: graphite
f951: internal compiler error: in gimplify_modify_expr, at gimplify.c:5779
0x64182e gimplify_modify_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:5778
0xb155fe gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12358
0xb1c0d6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6641
0xb2048f gimplify_cond_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:4111
0xb15622 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12315
0xb1c0d6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6641
0xb1fe83 gimplify_cond_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:4008
0xb15622 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:12315
0xb1345f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13089
0xb300bc force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:78
0xb3016f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:115
0x96c563 create_empty_if_region_on_edge(edge_def*, tree_node*)
/home/marxin/Programming/gcc/gcc/cfgloopmanip.c:703
0x1582668 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:745
0x1582956 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:897
0x1582875 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:859
0x15823d5 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:623
0x1582692 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:751
0x1582875 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:859
0x1582c64 graphite_regenerate_ast_isl(scop*)
/home/marxin/Programming/gcc/gcc/graphite-isl-ast-to-gimple.c:1505
0x157f053 graphite_transform_loops()
/home/marxin/Programming/gcc/gcc/graphite.c:413

[Bug middle-end/49774] [meta-bug] restrict qualification aliasing issues

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
Bug 49774 depends on bug 88014, which changed state.

Bug 88014 Summary: Restrict/C2X/N2260 Restricted function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88014

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/88014] Restrict/C2X/N2260 Restricted function argument

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88014

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
This has been fixed on the GCC 8 branch already.

*** This bug has been marked as a duplicate of bug 87610 ***

[Bug middle-end/87610] [7 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87610

Richard Biener  changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #6 from Richard Biener  ---
*** Bug 88014 has been marked as a duplicate of this bug. ***

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm
 Blocks||53947

--- Comment #2 from Richard Biener  ---
On x86_64 we manage to vectorize this with quite absymal code (for core-avx2)
with a vectorization factor of 32:

.L4:
vmovdqu (%rax), %ymm1
vmovdqu 64(%rax), %ymm4
addq$32, %rcx
addq$96, %rax
vmovdqu -64(%rax), %ymm5
vpshufb %ymm14, %ymm1, %ymm0
vpermq  $78, %ymm0, %ymm2
vpshufb %ymm13, %ymm1, %ymm0
vpshufb %ymm12, %ymm5, %ymm3
vpor%ymm2, %ymm0, %ymm0
vpshufb %ymm11, %ymm4, %ymm2
vpor%ymm3, %ymm0, %ymm0
vpermq  $78, %ymm2, %ymm3
vpshufb .LC5(%rip), %ymm4, %ymm2
vpshufb .LC4(%rip), %ymm0, %ymm0
vpor%ymm3, %ymm2, %ymm2
vpshufb .LC6(%rip), %ymm1, %ymm3
vpermq  $78, %ymm3, %ymm15
vpor%ymm2, %ymm0, %ymm0
vpshufb .LC7(%rip), %ymm1, %ymm3
vpshufb .LC8(%rip), %ymm5, %ymm2
vpor%ymm15, %ymm3, %ymm3
vpshufb .LC11(%rip), %ymm4, %ymm15
vpshufb .LC14(%rip), %ymm5, %ymm5
vpor%ymm2, %ymm3, %ymm3
vpshufb .LC9(%rip), %ymm4, %ymm2
vpermq  $78, %ymm2, %ymm2
vpshufb %ymm10, %ymm3, %ymm3
vpor%ymm2, %ymm15, %ymm2
vpor%ymm2, %ymm3, %ymm3
vpshufb .LC12(%rip), %ymm1, %ymm2
vpshufb .LC13(%rip), %ymm1, %ymm1
vpermq  $78, %ymm2, %ymm2
vpor%ymm2, %ymm1, %ymm2
vpshufb .LC15(%rip), %ymm4, %ymm1
vpshufb .LC16(%rip), %ymm4, %ymm4
vpermq  $78, %ymm1, %ymm1
vpor%ymm5, %ymm2, %ymm2
vpor%ymm1, %ymm4, %ymm4
vpshufb %ymm10, %ymm2, %ymm2
vpmovzxbw   %xmm0, %ymm1
vpor%ymm4, %ymm2, %ymm2
vpmovzxbw   %xmm3, %ymm4
vextracti128$0x1, %ymm0, %xmm0
vpmullw %ymm7, %ymm4, %ymm4
vpmullw %ymm8, %ymm1, %ymm1
vextracti128$0x1, %ymm3, %xmm3
vpmovzxbw   %xmm0, %ymm0
vpmovzxbw   %xmm3, %ymm3
vpmullw %ymm8, %ymm0, %ymm0
vpmullw %ymm7, %ymm3, %ymm3
vpaddw  %ymm4, %ymm1, %ymm1
vpmovzxbw   %xmm2, %ymm4
vextracti128$0x1, %ymm2, %xmm2
vpmovzxbw   %xmm2, %ymm2
vpmullw %ymm6, %ymm4, %ymm4
vpmullw %ymm6, %ymm2, %ymm2
vpaddw  %ymm3, %ymm0, %ymm0
vpaddw  %ymm4, %ymm1, %ymm1
vpaddw  %ymm2, %ymm0, %ymm0
vpsrlw  $8, %ymm1, %ymm1
vpsrlw  $8, %ymm0, %ymm0
vpand   %ymm1, %ymm9, %ymm1
vpand   %ymm0, %ymm9, %ymm0
vpackuswb   %ymm0, %ymm1, %ymm0
vpermq  $216, %ymm0, %ymm0
vmovdqu %ymm0, -32(%rcx)
cmpq%r8, %rcx
jne .L4


Maybe you can post what you think arm can do better here?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
C testcase anyone? ;)  I never succeeded extracting anything meaningful from
the Go testsuite logs to be able to reproduce sth (no cut&paste possible).

[Bug middle-end/88010] noinline function alias unexpectedly inlined

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Aliases are generally "transparent" for most (late) attribute lookups in IPA
since IPA looks through aliases.

[Bug fortran/88008] [9 Regression] ICE in check_typebound_baseobject, at fortran/resolve.c:6058

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88008

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.0

[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88018

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/88016] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474 since r262375

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88016

--- Comment #2 from Richard Biener  ---
Dup of PR88007?

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[hoganmeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

--- Comment #3 from krux  ---
A few NEON instructions are sufficient:
https://web.archive.org/web/20170227190422/http://hilbert-space.de/?p=22

clang seems to generate similar code, see the godbolt links.

[Bug tree-optimization/87977] [9 Regression] ICE: verify_ssa failed (error: definition in block 4 follows the use)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87977

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 14 09:01:47 2018
New Revision: 266098

URL: https://gcc.gnu.org/viewcvs?rev=266098&root=gcc&view=rev
Log:
PR tree-optimization/87977
* tree-ssa-math-opts.c (optimize_recip_sqrt): Don't reuse division
stmt, build a new one and replace the old one with it.  Formatting fix.
Call release_ssa_name (x) if !has_other_use and !delete_div.
(pass_cse_reciprocals::execute): Before calling optimize_recip_sqrt
verify lhs of stmt is still def.

* gcc.dg/recip_sqrt_mult_1.c: Add -fcompare-debug to dg-options.
* gcc.dg/recip_sqrt_mult_2.c: Likewise.
* gcc.dg/recip_sqrt_mult_3.c: Likewise.
* gcc.dg/recip_sqrt_mult_4.c: Likewise.
* gcc.dg/recip_sqrt_mult_5.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/recip_sqrt_mult_1.c
trunk/gcc/testsuite/gcc.dg/recip_sqrt_mult_2.c
trunk/gcc/testsuite/gcc.dg/recip_sqrt_mult_3.c
trunk/gcc/testsuite/gcc.dg/recip_sqrt_mult_4.c
trunk/gcc/testsuite/gcc.dg/recip_sqrt_mult_5.c
trunk/gcc/tree-ssa-math-opts.c

[Bug ipa/88016] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474 since r262375

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88016

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Liška  ---
Dup.

*** This bug has been marked as a duplicate of bug 88007 ***

[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
*** Bug 88016 has been marked as a duplicate of this bug. ***

[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-14
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
> 
> Using the opts_obstack sounds reasonable to me.
>

Let me do that.

[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |DUPLICATE

--- Comment #6 from Ville Voutilainen  ---
This seems to have been fixed by the fix to 86678.

*** This bug has been marked as a duplicate of bug 86678 ***

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86678

Ville Voutilainen  changed:

   What|Removed |Added

 CC||anders.granlund.0 at gmail dot 
com

--- Comment #7 from Ville Voutilainen  ---
*** Bug 67026 has been marked as a duplicate of this bug. ***

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[hoganmeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

--- Comment #4 from krux  ---
On x64 indeed both compilers generate a huge amount of code.
https://godbolt.org/z/TH7mqn

[Bug c++/55004] [meta-bug] constexpr issues

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 67026, which changed state.

Bug 67026 Summary: GCC incorrectly rejects well-formed constexpr function 
definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/88019] [9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5779

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88019

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Ah well, the usual -ftrapv issue with COND_EXPRs.

#13 0x00b2ff19 in create_empty_if_region_on_edge (
entry_edge= 33)>, 
condition=)
at /space/rguenther/src/gcc-slpcost/gcc/cfgloopmanip.c:704
(gdb) p debug_generic_expr (condition)
(if (graphite_IV.511_52 != 0)
  {
iftmp.512 = _42 + -2;
  }
else
  {
iftmp.512 = 0;
  }) < (graphite_IV.511_52 != 0 ? graphite_IV.511_52 /[ex] 4 + -2 : 0) + 1

the issue is the COND_EXPRs here.  That's fixable with
rewrite_to_non_trapping_overflow "easily".

[Bug tree-optimization/87974] [9 Regression] ICE in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 14 09:19:28 2018
New Revision: 266099

URL: https://gcc.gnu.org/viewcvs?rev=266099&root=gcc&view=rev
Log:
2018-11-14  Richard Biener  

PR tree-optimization/87974
* tree-vect-loop.c (vectorizable_reduction): When computing
the vectorized reduction PHI vector type ignore constant
and external defs.

* g++.dg/opt/pr87974.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr87974.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/87974] [9 Regression] ICE in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #5 from ktkachov at gcc dot gnu.org ---
I see vectorisation for arm (and aarch64 FWIW):
-O3 -march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard

gives the loop:
.L4:
mov r3, lr
add lr, lr, #48
vld3.8  {d16, d18, d20}, [r3]!
vld3.8  {d17, d19, d21}, [r3]
vmull.u8 q12, d16, d30
vmull.u8 q1, d18, d28
vmull.u8 q2, d19, d29
vmull.u8 q11, d17, d31
vmull.u8 q3, d20, d26
vadd.i16q12, q12, q1
vmull.u8 q10, d21, d27
vadd.i16q8, q11, q2
vadd.i16q9, q12, q3
vadd.i16q8, q8, q10
vshr.u16q9, q9, #8
vshr.u16q8, q8, #8
vmovn.i16   d20, q9
vmovn.i16   d21, q8
vst1.8  {q10}, [ip]!
cmp ip, r4
bne .L4

Though of course it's not as tight as the assembly given in the link

[Bug middle-end/88010] noinline function alias unexpectedly inlined

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
Yep, GCC considers attributes to be part of the definition of a function for
IPA passes.  We are not consitent here (i.e. warning attributes on aliases
counts), so it makes sense to support this (and is not too difficult to do in
this case).

Is there some critical use of this that we would want to have for GCC 9?
Honza

[Bug middle-end/88010] noinline function alias unexpectedly inlined

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010

--- Comment #4 from Jan Hubicka  ---
> Yep, GCC considers attributes to be part of the definition of a function for
> IPA passes.  We are not consitent here (i.e. warning attributes on aliases
> counts), so it makes sense to support this (and is not too difficult to do in
> this case).

Actually siplicity was bit overrated - currently all function
redirection code eliminates aliases, so we will need to carefully update
those so attributes are not lost.  Still implementable.

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[hoganmeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

--- Comment #6 from krux  ---
-mfloat-abi=hard was missing indeed. It's a pity there's no warning like when
trying to use the intrinsics.

Still I see a lot more instructions, maybe that got fixed after v7.2?
https://godbolt.org/z/OWzgXi

  vld3.8 {d16, d18, d20}, [r3]
  add ip, r3, #24
  add lr, lr, #1
  add r3, r3, #48
  cmp lr, r5
  vld3.8 {d17, d19, d21}, [ip]
  vmovl.u8 q5, d16
  vmovl.u8 q15, d18
  vmovl.u8 q11, d17
  vmovl.u8 q4, d19
  vmovl.u8 q0, d20
  vmovl.u8 q1, d21
  vmull.s16 q6, d10, d28
  vmull.s16 q3, d22, d28
  vmull.s16 q2, d30, d26
  vmull.s16 q11, d23, d29
  vmull.s16 q15, d31, d27
  vmull.s16 q5, d11, d29
  vmull.s16 q9, d8, d26
  vmull.s16 q8, d9, d27
  vadd.i32 q2, q6, q2
  vadd.i32 q10, q5, q15
  vadd.i32 q9, q3, q9
  vmull.s16 q15, d0, d24
  vadd.i32 q8, q11, q8
  vmull.s16 q3, d2, d24
  vmull.s16 q0, d1, d25
  vmull.s16 q1, d3, d25
  vadd.i32 q11, q2, q15
  vadd.i32 q9, q9, q3
  vadd.i32 q10, q10, q0
  vadd.i32 q8, q8, q1
  vshr.s32 q11, q11, #8
  vshr.s32 q9, q9, #8
  vshr.s32 q10, q10, #8
  vshr.s32 q8, q8, #8
  vmovn.i32 d30, q11
  vmovn.i32 d31, q10
  vmovn.i32 d20, q9
  vmovn.i32 d21, q8
  vmovn.i16 d16, q15
  vmovn.i16 d17, q10
  vst1.8 {q8}, [r4]

[Bug target/88013] can't vectorize rgb to grayscale conversion code

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013

--- Comment #7 from ktkachov at gcc dot gnu.org ---
I tried current trunk (future GCC 9)
GCC 9 learned to avoid excessive widening during vectorisation, which is what
accounts for the large number of instructions you see.

[Bug c++/88020] New: Template argument deduction fails inside sizeof

[toe-ger at web dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020

Bug ID: 88020
   Summary: Template argument deduction fails inside sizeof
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toe-ger at web dot de
  Target Milestone: ---

*Minimal example*:
template 
struct S{
S(T){}
};
static_assert(sizeof(S{0}));

*Expected output*:
*Actual output*:
:5:22: error: missing template arguments after 'S'
 static_assert(sizeof(S{0}));
  ^
:2:8: note: 'template struct S' declared here
 struct S{
^
*Reproduction*:
https://godbolt.org/z/9XLvfT
(currently also fails on trunk)
Note: Deduction guides are a C++17 feature and requires -std=c++17.
S s{0}; compiles.

[Bug target/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927

--- Comment #4 from Jozef Lawrynowicz  ---
Submitted patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01192.html

[Bug tree-optimization/88019] [9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5779

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88019

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88019] [9 Regression] ICE in gimplify_modify_expr, at gimplify.c:5779

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88019

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 14 11:11:05 2018
New Revision: 266105

URL: https://gcc.gnu.org/viewcvs?rev=266105&root=gcc&view=rev
Log:
2018-11-14  Richard Biener  

PR tree-optimization/88019
* graphite-isl-ast-to-gimple.c (ternary_op_to_tree): Rewrite
COND_EXPR arguments to non-trapping overflow.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c

[Bug testsuite/88021] New: aarch64 Busy hang running testcase pr60183.c since revision 265914

[matmal01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021

Bug ID: 88021
   Summary: aarch64 Busy hang running testcase pr60183.c since
revision 265914
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---

Since revision 265914, the testcase pr60183.c has been FAILing on
aarch64-none-linux-gnu regression tests with a timeout.

Some initial debugging has shown this is a busy hang in
lambda_matrix_right_hermite.

The inner "while (S[i][j] != 0)" loop never gets out of i == 1, j == 0.




(v) hw-a20-6:~ [11:10:29] % gcc-install/bin/native-gcc
/home/matmal01/gcc-source/gcc/testsuite/gcc.dg/torture/pr60183.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions-lm  -o ./pr60183.exe -wrapper
gdb,-q,--args
Reading symbols from
/home/matmal01/gcc-install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cc1...done.
(gdb) run
Starting program:
/home/matmal01/gcc-install/libexec/gcc/aarch64-unknown-linux-gnu/9.0.0/cc1
-quiet -imultiarch aarch64-linux-gnu
/home/matmal01/gcc-source/gcc/testsuite/gcc.dg/torture/pr60183.c -quiet
-dumpbase pr60183.c -mlittle-endian -mabi=lp64 -auxbase pr60183 -O3
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions -o /tmp/ccy2hzG0.s
^C
Program received signal SIGINT, Interrupt.
0x013e54f8 in lambda_matrix_right_hermite (n=,
U=, S=, m=, A=) at
../../gcc-source/gcc/tree-data-ref.c:3500
3500  a = S[i-1][j];
(gdb) print i
$1 = 1
(gdb) print j
$2 = 0
(gdb) cont
Continuing.
  Wait for a while^M^C
Program received signal SIGINT, Interrupt.
0x013e54f8 in lambda_matrix_right_hermite (n=,
U=, S=, m=, A=) at
../../gcc-source/gcc/tree-data-ref.c:3500
3500  a = S[i-1][j];
(gdb) print i
$3 = 1
(gdb) print j
$4 = 0
(gdb) next
3502  sigma = (a * b < 0) ? -1: 1;

[Bug testsuite/88021] aarch64 Busy hang running testcase pr60183.c since revision 265914

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-14
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I cannot reproduce this with a cross but does the following fix it?

diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 0096afb9ba7..5b554b02b4a 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -3458,7 +3500,8 @@ lambda_vector_first_nz (lambda_vector vec1, int n, int
start)
R2 = R2 + CONST1 * R1.  */

 static void
-lambda_matrix_row_add (lambda_matrix mat, int n, int r1, int r2, int const1)
+lambda_matrix_row_add (lambda_matrix mat, int n, int r1, int r2,
+  lambda_int const1)
 {
   int i;

@@ -3539,7 +3582,7 @@ lambda_matrix_right_hermite (lambda_matrix A, int m, int
n,
{
  while (S[i][j] != 0)
{
- int sigma, factor, a, b;
+ lambda_int sigma, factor, a, b;

  a = S[i-1][j];
  b = S[i][j];

[Bug target/85968] gcc/config/arc/arc.c:9805: bad test ?

[claziss at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85968

Claudiu Zissulescu  changed:

   What|Removed |Added

 CC||claziss at gmail dot com

--- Comment #1 from Claudiu Zissulescu  ---
Fixed by commit:

r261623 | claziss | 2018-06-15 14:22:10 +0300 (Fri, 15 Jun 2018) | 9 lines
Changed paths:
   M /trunk/gcc/ChangeLog
   M /trunk/gcc/config/arc/arc.c

[ARC] Fix warning in arc_return_address_register.

The if condition in arc_return_address_register which selects the arc
return address is not correct. The issue is signalized in bugzilla 85968.

gcc/
2018-06-15  Claudiu Zissulescu  

* config/arc/arc.c (arc_return_address_register): Fix if-condition.

[Bug target/85968] gcc/config/arc/arc.c:9805: bad test ?

[claziss at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85968

--- Comment #2 from claziss at gcc dot gnu.org ---
Author: claziss
Date: Wed Nov 14 11:31:12 2018
New Revision: 266107

URL: https://gcc.gnu.org/viewcvs?rev=266107&root=gcc&view=rev
Log:
[ARC] Backport form mainline
PR target/85968
* config/arc/arc.c (arc_return_address_register): Fix
if-condition.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arc/arc.c

[Bug testsuite/88021] aarch64 Busy hang running testcase pr60183.c since revision 265914

[matmal01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021

--- Comment #2 from Matthew Malcomson  ---
Hi Richard,

Applying that on top of r265914 does fix the problem.

Thanks for the quick reply!

[Bug c++/80016] error is positioned incorrectly

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Can the bug be marked as resolved?

[Bug c++/88020] Deduction guides fail inside sizeof

[toe-ger at web dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020

--- Comment #1 from toe-ger at web dot de ---
The godbolt link is a bit confusing because the output window is in the wrong
place. https://godbolt.org/z/OvlkUA is better.

[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260

--- Comment #7 from Martin Liška  ---
Can the bug be marked as resolved?

[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260

--- Comment #8 from Dominique d'Humieres  ---
> Can the bug be marked as resolved?

I still get an ICE with gcc 7 and 8. Any plan to do the back port (I can do it
if it helps)?

[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 14 12:36:59 2018
New Revision: 266140

URL: https://gcc.gnu.org/viewcvs?rev=266140&root=gcc&view=rev
Log:
PR rtl-optimization/87817
* config/i386/i386.c (ix86_fold_builtin): For _bzhi_u{32,64} if
last argument has low 8 bits clear, fold to 0.

* gcc.target/i386/bmi2-bzhi-3.c (main): Add a couple of new tests.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/bmi2-bzhi-3.c

[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 14 12:38:20 2018
New Revision: 266141

URL: https://gcc.gnu.org/viewcvs?rev=266141&root=gcc&view=rev
Log:
PR other/88007
* c-common.c (parse_optimize_options): Allocate option string from
opts_obstack rather than as GC memory.  Move the allocation after
warning for invalid option.

* gcc.dg/pr88007.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr88007.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71026] Missing division optimizations

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026

--- Comment #11 from Wilco  ---
Author: wilco
Date: Wed Nov 14 12:45:29 2018
New Revision: 266142

URL: https://gcc.gnu.org/viewcvs?rev=266142&root=gcc&view=rev
Log:
Simplify floating point comparisons

This patch implements some of the optimizations discussed in PR71026.

Simplify (C / x >= 0.0) into x >= 0.0 with -funsafe-math-optimizations
(since C / x can underflow to zero if x is huge, it's not safe otherwise).
If C is negative the comparison is reversed.

Simplify (x * C1) > C2 into x > (C2 / C1) with -funsafe-math-optimizations.
If C1 is negative the comparison is reversed.

gcc/
PR 71026/tree-optimization
* match.pd: Simplify floating point comparisons.

gcc/testsuite/
PR 71026/tree-optimization
* gcc.dg/div-cmp-1.c: New test.
* gcc.dg/div-cmp-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/div-cmp-1.c
trunk/gcc/testsuite/gcc.dg/div-cmp-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817

--- Comment #5 from Jakub Jelinek  ---
While the testcase doesn't FAIL with the above commit, it isn't really fixed
yet, a 0 could propagate to the insn already during RTL optimizations.

[Bug testsuite/88021] aarch64 Busy hang running testcase pr60183.c since revision 265914

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed then.

[Bug testsuite/88021] aarch64 Busy hang running testcase pr60183.c since revision 265914

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88021

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 14 13:07:03 2018
New Revision: 266143

URL: https://gcc.gnu.org/viewcvs?rev=266143&root=gcc&view=rev
Log:
2018-11-14  Richard Biener  

PR middle-end/88021
* tree-data-ref.c (lambda_matrix_row_add): Change const1 argument
to lambda_int.
(lambda_vector_mult_const): Likewise.
(lambda_matrix_right_hermite): Use lambda_int temporaries.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-03-17 00:00:00 |2018-11-14

--- Comment #2 from Jonathan Wakely  ---
Trunk now emits the warning three times!

s.cc: In constructor 'Foo::Foo(int)':
s.cc:5:20: warning: declaration of 'foo' shadows a member of 'Foo' [-Wshadow]
5 |   Foo(int foo) : foo(foo) {}
  |^
s.cc:3:11: note: shadowed declaration is here
3 |   int foo;
  |   ^~~
s.cc: In constructor 'Foo::Foo(int)':
s.cc:5:32: warning: declaration of 'foo' shadows a member of 'Foo' [-Wshadow]
5 |   Foo(int foo) : foo(foo) {}
  |^
s.cc:3:11: note: shadowed declaration is here
3 |   int foo;
  |   ^~~
s.cc: In constructor 'Foo::Foo(int)':
s.cc:5:32: warning: declaration of 'foo' shadows a member of 'Foo' [-Wshadow]
5 |   Foo(int foo) : foo(foo) {}
  |^
s.cc:3:11: note: shadowed declaration is here
3 |   int foo;
  |   ^~~

Was the patch ever posted to gcc-patches?

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147

--- Comment #3 from Paul Smith  ---
Unfortunately not because I never had time to do more than the patch attached
here: in particular I didn't hook it up to any command-line arguments, nor did
I add regression tests for it.  I didn't think it would be helpful to post the
patch in its current form to gcc-patches.  However I'm happy to do so if it
seems useful.

Looking at my schedule realistically the earliest I would have time to do
significant work on this would be February... I'm on the hook for
already-late-ish changes for a January release date at DayJob.  Sorry for that
:(.

[Bug c++/88020] Deduction guides fail inside sizeof

[ensadc at mailnesia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #2 from ensadc at mailnesia dot com ---
This has the same cause as bug 87709

[Bug c++/80016] error is positioned incorrectly

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-03-13 00:00:00 |2018-11-14

--- Comment #5 from Jonathan Wakely  ---
No, the finish location is still wrong on trunk.

Reduced:

namespace ns {
template struct trait;
}

struct any
{
  static unsigned const size = 3 * sizeof(void*);
  static unsigned const alignment = alignof(void*);

  template 
  static constexpr bool fits = sizeof(T) <= size
&& alignof(T) <= alignment
&& ns::trait::value;

  template >
  any();
};

any x;


The output on trunk includes:

expr-loc-bug.cpp:13:29: error: incomplete type 'ns::trait' used in nested
name specifier
   11 |   static constexpr bool fits = sizeof(T) <= size
  |~
   12 | && alignof(T) <= alignment
  | ~~
   13 | && ns::trait::value;
  | ^

I'd even argue the stating location still isn't right in this version, as the
error comes from ns::trait::value not the logical expression containing it.

[Bug sanitizer/88022] New: Support dynamic shadow offset in ASan

[chefmax at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022

Bug ID: 88022
   Summary: Support dynamic shadow offset in ASan
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This is a possible feature for GCC 10.

The possibility of setting ASan shadow offset dynamically is discussed many
times and recent libsanitizer already supports it for Android and Windows.
Although Linux is not supported yet, it seems that code for Android can be
reused quite easily.
Mainly, we'll need to tweak ifdefs in libsanitizer and add support on compiler
side (which won't be hard).
Preliminary performance numbers can be obtained from here:
https://github.com/google/sanitizers/issues/837

[Bug libstdc++/33491] parallel v3: add some documentation

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33491

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #2 from Jonathan Wakely  ---
(In reply to Wolfgang Bangerth from comment #0)
> Of even more interest I would find if the following: parallel mode probably
> implements a lot of stuff like work stealing, load balancing, etc beyond
> what the library part of C++98 specifies that it needs to provide. If 
> the respective classes are meant to have stable interfaces

They're not.

> then it would
> be interesting to document them so that user programs could also use these
> interfaces.

I don't think we want that to happen.

I expect the Parallel Mode to be deprecated once
https://gcc.gnu.org/ml/libstdc++/2018-11/msg00017.html is integrated and
stabilized. The executors work being done for a future C++ standard will
provide standardized APIs for user programs. We don't want users to depend on
our internal APIs from an old experiment.

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022

--- Comment #1 from Jakub Jelinek  ---
Isn't it possible to just add yet another range (like we already have Low and
High and sometimes Medium memory and their corresponding shadows and gaps) if
asan runtime determines some region clash?

[Bug fortran/88008] [9 Regression] ICE in check_typebound_baseobject, at fortran/resolve.c:6058

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88008

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see the ICE with revision r265728 with any patch for parameter inquiry,
likely r265729.

[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #6 from Segher Boessenkool  ---
A 0 as a register value there is undefined, too, it doesn't have to be literal
0.
It probably doesn't really fail in the current compiler, of course.

[Bug c++/80438] Variadic template class argument deduction failure from variadic constructor deduction guide

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87907

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/88020] Deduction guides fail inside sizeof

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87709
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to ensadc from comment #2)
> This has the same cause as bug 87709

Yes, looks like it.

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709

Jonathan Wakely  changed:

   What|Removed |Added

 CC||toe-ger at web dot de

--- Comment #5 from Jonathan Wakely  ---
*** Bug 88020 has been marked as a duplicate of this bug. ***

[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from gcc7 up to trunk (9.0). With gcc6 I get the error

Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug c++/88020] Deduction guides fail inside sizeof

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88020

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 87709 ***

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-10-23 00:00:00 |2018-11-14
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=88020 |

--- Comment #6 from Jonathan Wakely  ---
From Bug 88020:

template 
struct S{
S(T){}
};
static_assert(sizeof(S{0}));



:5:22: error: missing template arguments after 'S'
 static_assert(sizeof(S{0}));
  ^
:2:8: note: 'template struct S' declared here
 struct S{
^

[Bug tree-optimization/87917] ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87917

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to Sebastian Pop from comment #3)
> > Sebastian - can you say if
> > evolution_function_is_affine_multivariate_p ({0, +, {0, +, 4}_1}_2, 1)
> > should really return true?
> 
> You are right, {0, +, {0, +, 4}_1}_2 is not a valid affine multivariate
> function: only the base (not the step) should vary in an outer loop.
> 
> For example, this would be an affine multivariate: {{0, +, 4}_1, +, 42}_2.

Hmm, but evolution_function_is_affine_multivariate_p currently says:

  switch (TREE_CODE (chrec))
{
case POLYNOMIAL_CHREC:
  if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum))
{
  if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum))
return true;

so for {0, +, {0, +, 1}_1 }_2 and asking for loopnum == 2 where loop 2 is
nested inside loop 1 this would already return true because {0, +, 1}_1
is invariant in 2.  Now for the testcase we are asking for loopnum == 1
where the above doesn't hold but we then fall through to

  else
{
  if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC
  && CHREC_VARIABLE (CHREC_RIGHT (chrec))
 != CHREC_VARIABLE (chrec)
  && evolution_function_is_affine_multivariate_p
  (CHREC_RIGHT (chrec), loopnum))
return true;

which surely looks bogus (the != should probably be a flow_loop_nested_p
in some way).  A SCEV like {0, +, {0, +, 1}_1 }_1 isn't valid anyways.

If trying to make sense of evolution_function_is_affine_multivariate_p
by looking at evolution_function_is_affine_p and
evolution_function_is_univariate_p I would come up with sth like

if (evolution_function_is_invariant_p (CHREC_RIGHT (chrec),
   CHREC_VARIABLE (chrec))
&& (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC
|| evolution_function_is_affine_multivariate_p (CHREC_RIGHT
(chrec)))
  return true;
else
  return false;

That is, why's the evolution of CHREC_LEFT restricted at all here?

That said - this would also make the loopnum argument to
evolution_function_is_affine_multivariate_p moot.  So like the following
together with removing the arg everywhere.  It doesn't fix the ICE
though since we then implicitely ask for loopnum == 2.

Index: tree-chrec.c
===
--- tree-chrec.c(revision 266145)
+++ tree-chrec.c(working copy)
@@ -1063,7 +1063,7 @@ evolution_function_is_invariant_p (tree
evolution.  */

 bool
-evolution_function_is_affine_multivariate_p (const_tree chrec, int loopnum)
+evolution_function_is_affine_multivariate_p (const_tree chrec)
 {
   if (chrec == NULL_TREE)
 return false;
@@ -1071,33 +1071,11 @@ evolution_function_is_affine_multivariat
   switch (TREE_CODE (chrec))
 {
 case POLYNOMIAL_CHREC:
-  if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum))
-   {
- if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum))
-   return true;
- else
-   {
- if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC
- && CHREC_VARIABLE (CHREC_RIGHT (chrec))
-!= CHREC_VARIABLE (chrec)
- && evolution_function_is_affine_multivariate_p
- (CHREC_RIGHT (chrec), loopnum))
-   return true;
- else
-   return false;
-   }
-   }
-  else
-   {
- if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum)
- && TREE_CODE (CHREC_LEFT (chrec)) == POLYNOMIAL_CHREC
- && CHREC_VARIABLE (CHREC_LEFT (chrec)) != CHREC_VARIABLE (chrec)
- && evolution_function_is_affine_multivariate_p
- (CHREC_LEFT (chrec), loopnum))
-   return true;
- else
-   return false;
-   }
+  return (evolution_function_is_invariant_p (CHREC_RIGHT (chrec),
+CHREC_VARIABLE (chrec))
+ && (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC
+ || evolution_function_is_affine_multivariate_p
+   (CHREC_RIGHT (chrec;

 default:
   return false;


Hmm, maybe what is missing is a check at the top whether the CHREC itself
varies in loopnum?  Anyway, the current code doesn't make much sense to me.

And what dependence analysis does - asking for dependence of two DRs
in loop 2 (the inner one) with respect to evo

[Bug fortran/87946] [7/8/9 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87946

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||pault at gcc dot gnu.org
  Known to work||6.4.0
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Could be caused by r241450 (pr69834).

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88018

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
A latent issue before that I guess.

The problem is we have a call which can throw, isn't marked noreturn, but is
followed by __builtin_unreachable () call.  In RTL that is represented by the
bb having just EH edge and no fallthru edge.

The stack pass emits some insn(s) after such a call and calls
fixup_abnormal_edges to fix that up.  fixup_abnormal_edges relies on the
presence of the fallthru edge though.  I guess easiest would be just delete
those insns and not insert them on the fallthru edge (which doesn't exist).

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 14 14:33:44 2018
New Revision: 266147

URL: https://gcc.gnu.org/viewcvs?rev=266147&root=gcc&view=rev
Log:
2018-11-14  Richard Biener  

PR middle-end/87985
* tree-data-ref.c (split_constant_offset): Add wrapper
allocating a cache hash-map.
(split_constant_offset_1): Cache results of expanding
expressions from SSA def stmts.

* gcc.dg/pr87985.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87985.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||janus at gcc dot gnu.org
  Known to work||8.2.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Dominique d'Humieres  ---
Probably r264350 (pr88009).

[Bug go/87470] [9 Regression] libgo/go/runtime/malloc.go failed to build with -mx32

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87470

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ian Lance Taylor  ---
This was fixed by https://golang.org/cl/138817,
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00045.html .

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed, though for some reason I needed to add -floop-parallelize-all to the
flags in comment #0 to trigger it.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015

--- Comment #2 from David Malcolm  ---
Actually, I'm still not able to reproduce this, but the fix seems obvious; am
working on it.

[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925

--- Comment #15 from Eric Botcazou  ---
OK, it's probably time to concede final defeat, although this will bring back
quite a few redundant extensions on RISC architectures like ARM and SPARC.

For the records, here's a bit of history about this stuff: in the early days,
the code was straightforward and just looked inside paradoxical SUBREGs on
targets for which WORD_REGISTER_OPERATIONS is defined:

nonzero_bits:

#ifndef WORD_REGISTER_OPERATIONS
  /* On many CISC machines, accessing an object in a wider mode
 causes the high-order bits to become undefined.  So they are
 not known to be zero.  */
  if (GET_MODE_SIZE (GET_MODE (x))
  > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x
nonzero |= (GET_MODE_MASK (GET_MODE (x))
& ~ GET_MODE_MASK (GET_MODE (SUBREG_REG (x;
#endif

num_sign_bit_copies:

#ifdef WORD_REGISTER_OPERATIONS
  /* For paradoxical SUBREGs on machines where all register operations
 affect the entire register, just look inside.  Note that we are
  5473 kennerpassing MODE to the recursive call, so the number of
sign bit copies
  5473 kennerwill remain relative to that mode, not the inner mode.
 */
  2189 kenner 
  2189 kenner   if (GET_MODE_SIZE (GET_MODE (x))
  2189 kenner > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x
  2189 kenner   return num_sign_bit_copies (SUBREG_REG (x), mode);
  2189 kenner #endif

[Bug middle-end/86575] [7/8/9 Regression] -Wimplicit-fallthrough affects code generation

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575

--- Comment #4 from Michael Matz  ---
Author: matz
Date: Wed Nov 14 15:43:54 2018
New Revision: 266148

URL: https://gcc.gnu.org/viewcvs?rev=266148&root=gcc&view=rev
Log:
Fix PR middle-end/86575

PR middle-end/86575
* gimplify.c (collect_fallthrough_labels): Add new argument,
return location via that, don't modify statements.
(warn_implicit_fallthrough_r): Adjust call, don't use
statement location directly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c

[Bug tree-optimization/71026] Missing division optimizations

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026

--- Comment #12 from Wilco  ---
It looks the only case left to do is f5:

x * C <= 0.0 -> x <= 0.0 if C >= 1.0
x * C <= 0.0 -> x < FLT_MIN/C if C < 1.0

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
I am seeing this for a fortran compilation but not for the same .c compilation
as Martin did:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran5/../../gfortran
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran5/../../
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -O2 -floop-nest-optimize -S -o pr42334-1.s
during GIMPLE pass: graphite
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0:
internal compiler error: in dump_printf_loc, at dumpfile.c:1287
0x105747f7 dump_printf_loc(dump_flag, dump_location_t const&, char const*, ...)
/home/seurer/gcc/gcc-trunk/gcc/dumpfile.c:1287
0x1152c9d3 translate_isl_ast_to_gimple::scop_to_isl_ast(scop*)
/home/seurer/gcc/gcc-trunk/gcc/graphite-isl-ast-to-gimple.c:1417
0x1152ee7f graphite_regenerate_ast_isl(scop*)
/home/seurer/gcc/gcc-trunk/gcc/graphite-isl-ast-to-gimple.c:1476
0x11528793 graphite_transform_loops()
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:413
0x11529753 graphite_transforms
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:476
0x11529753 execute
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (test for excess errors)

[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925

--- Comment #16 from Eric Botcazou  ---
Then people realized that there was a problem if the SUBREGs were spilled onto
the stack at some point, hence an additional test on LOAD_EXTEND_OP:

r8787 | wilson | 1995-01-21 03:23:10 +0100 (Sat, 21 Jan 1995) | 3 lines

(num_sign_bit_copies): Can handle paradoxical subreg only
if LOAD_EXTEND_OP is defined to SIGN_EXTEND.

r19928 | amylaar | 1998-05-21 13:35:10 +0200 (Thu, 21 May 1998) | 3 lines

* combine.c (nonzero_bits): For paradoxical subregs, take
LOAD_EXTENDED_OP into account.

Then, in order to fix PR c/2454 on some platform, the mechanism was killed for
the first time without much ado:

r55386 | sayle | 2002-07-11 03:23:07 +0200 (Thu, 11 Jul 2002) | 5 lines

PR c/2454
* combine.c (nonzero_bits): LOAD_EXTEND_OP should only apply
to SUBREGs of MEMs.  (num_sign_bit_copies): Likewise.

Now the mechanism was quite powerful on RISC architectures whose loads are
implicitly extended via LOAD_EXTEND_OP and the infrastructure was still present
in the compiler so I decided to revive it after stumbling for the 47th time on
a trivially redundant extension in some SPARC assembly.  This initially
required  only a few adjustments and fixes left and right outside the combiner
but it now appears that they are major issues within the combiner itself which
cannot be solved in a satisfactory way.

[Bug middle-end/86575] [7/8 Regression] -Wimplicit-fallthrough affects code generation

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575

Michael Matz  changed:

   What|Removed |Added

Summary|[7/8/9 Regression]  |[7/8 Regression]
   |-Wimplicit-fallthrough  |-Wimplicit-fallthrough
   |affects code generation |affects code generation

--- Comment #5 from Michael Matz  ---
Fixed in trunk.  Not planning backporting, it's not a very important problem.

[Bug target/86891] [9 Regression] wrong code with -O -frerun-cse-after-loop -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891

Jakub Jelinek  changed:

   What|Removed |Added

 CC||collison at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
  Component|tree-optimization   |target

--- Comment #1 from Jakub Jelinek  ---
Started with r262890.
I believe the bug is in the RTL of the *sub3_carryinCV* patterns (though
I admit I don't know exactly what those insns do on aarch64).

Through -O and disabling of some GIMPLE opts we end up with arguments to
SUB_OVERFLOW that aren't constant during expansion, but will be turned into
constants during RTL optimizations.

We effectively are checking if unsigned subtraction 0xfff9U -
0xfff8U overflows.
The aarch64 expander has a pattern for usubvti4, and on input we have
that 0xfff9U constant in (reg:TI 111) and the -(unsigned __int128) 8 constant
in (reg:TI 117).  The expander emits:
(insn 23 22 24 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (subreg:DI (reg:TI 111) 0)
(subreg:DI (reg:TI 117) 0)))
(set (reg:DI 121)
(minus:DI (subreg:DI (reg:TI 111) 0)
(subreg:DI (reg:TI 117) 0)))
]) "pr86891.c":9 298 {subdi3_compare1}
 (nil))
(insn 24 23 25 2 (set (reg:DI 123)
(subreg:DI (reg:TI 111) 8)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(insn 25 24 26 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (sign_extend:TI (reg:DI 123))
(plus:TI (sign_extend:TI (subreg:DI (reg:TI 117) 8))
(ltu:TI (reg:CC 66 cc)
(const_int 0 [0])
(set (reg:DI 122)
(minus:DI (minus:DI (reg:DI 123)
(subreg:DI (reg:TI 117) 8))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0]
]) "pr86891.c":9 367 {*subdi3_carryinCV}
 (nil))
(insn 26 25 27 2 (set (subreg:DI (reg:TI 120) 0)
(reg:DI 121)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(insn 27 26 28 2 (set (subreg:DI (reg:TI 120) 8)
(reg:DI 122)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(jump_insn 28 27 71 2 (set (pc)
(if_then_else (ltu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 31)
(pc))) "pr86891.c":9 9 {condjump}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 31)

I assume these instructions DTRT at runtime.
Now consider what happens when you propagate those constants into that RTL.
insn 23 sets pseudo 121 to 0xfff9ULL - (-8ULL), i.e. 0x10001ULL with overflow
(first argument is smaller than second argument), so I expect carry is set.

Now, insn 25 I'd hope performs r122 = 0ULL - (-1ULL) - 1 (the last being
carry), which is I think modelled properly by the (set (reg:DI 122) (minus
...)) part of the insn.
What is incorrect is the compare part of insn 25.  Because it is compare 0
(-(unsigned __int128)1 + carry), i.e. comparison of 0 and 0, so no CC is set,
even when I hope
the instruction actually should set carry (if it doesn't it couldn't be used
even at runtime, because 0xfff9ULL - (-(unsigned __int128)8) does overflow.

Note, the i386.md pattern which I'd think would be similar in what it does at
runtime, is:
(define_insn "sub3_carry_ccc"
  [(set (reg:CCC FLAGS_REG)
(compare:CCC
  (zero_extend: (match_operand:DWIH 1 "register_operand" "0"))
  (plus:
(ltu: (reg:CC FLAGS_REG) (const_int 0))
(zero_extend:
  (match_operand:DWIH 2 "x86_64_sext_operand" "rmWe")
   (clobber (match_scratch:DWIH 0 "=r"))]
  ""
  "sbb{}\t{%2, %0|%0, %2}"
  [(set_attr "type" "alu")
   (set_attr "mode" "")])

i.e. instead of comparing (sign_extend:TI (operand 1)) with (plus:TI
(sign_extend:TI (operand 2)) (ltu:TI (cc) (const_int 0))) in aarch64 backend it
compares
(zero_extend:TI (operand 1)) with (plus:TI (ltu:TI (cc) (const_int 0))
(zero_extend:TI (operand 2)).  Not really sure if the order of carry and
extension of operand 2 matters that much
(needs to be checked in combine log if it should be matches by combiner in some
cases), but I think the zero_extend vs. sign_extend is significant.

Now, looking at what aarch64 does for add with carry, there are separate
patterns like add3_carryinC which set CC_C mode and use zero_extend and
add3_carryinV which sets CC_V mode and uses sign_extend.
So, shouldn't sub3_carryin{C,V} be split similarly and if we check carry
flag, we should use subdi3_carryinC?

[Bug tree-optimization/88023] New: [9 Regression] ICE: verify_ssa failed (error: definition in block 39 does not dominate use in block 34)

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88023

Bug ID: 88023
   Summary: [9 Regression] ICE: verify_ssa failed (error:
definition in block 39 does not dominate use in block
34)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha2018 snapshot (r266019) ICEs when compiling
gcc/testsuite/gcc.c-torture/compile/20150108.c w/ -O1 (-O2, -O3)
-ftree-loop-vectorize --param max-loop-header-insns=2:

% gcc-9.0.0-alpha2018 -O1 -ftree-loop-vectorize --param
max-loop-header-insns=2 -c gcc/testsuite/gcc.c-torture/compile/20150108.c
gcc/testsuite/gcc.c-torture/compile/20150108.c: In function 'fn1':
gcc/testsuite/gcc.c-torture/compile/20150108.c:5:5: error: definition in block
39 does not dominate use in block 34
5 | int fn1 () {
  | ^~~
for SSA_NAME: _107 in statement:
s_lsm.23_90 = PHI <_107(34), _107(39)>
PHI argument
_107
for PHI node
s_lsm.23_90 = PHI <_107(34), _107(39)>
during GIMPLE pass: vect
gcc/testsuite/gcc.c-torture/compile/20150108.c:5:5: internal compiler error:
verify_ssa failed
0xeea820 verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa.c:1188
0xc04add execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/passes.c:1932
0xc058de execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/passes.c:1979

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88018

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45002&action=edit
gcc9-pr88018.patch

Untested fix.

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[chefmax at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022

--- Comment #2 from chefmax at gcc dot gnu.org ---
I think nothing prevents us from trying several ranges, the question is whether
upstream guys will accept this...
I've just noticed that the code for dynamic shadow offset is already present in
libsanitizer sources and it seems that it's not hard to enable it for Linux.

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022

--- Comment #3 from Jakub Jelinek  ---
The dynamic offset code has the problem that a) it is usually larger b) usually
slower c) ABI incompatible.

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521

--- Comment #1 from Jonathan Wakely  ---
The meaning of "user-declared" in C++03 is closer to "has a function body" than
the meaning in C++11, where it includes defaulted definitions.
A defaulted definition in C++11 is equivalent to an implicit (i.e. not
user-declared) definition in C++03. So I would argue that your type is a POD
for the purposes of layout, and GCC is correct.

Consider:

struct Base {
unsigned x;
short y;
#if __cplusplus >= 201103L
~Base() = default;
#endif
};

struct Der : Base {
 short z;
};

int i[] = { sizeof(Base), sizeof(Der) };

I would argue that the #if block should not affect the ABI of this type, i.e.
it should be identical in C++03 and C++11, so it should be a "POD for the
purposes of layout". Otherwise adding explicitly-defaulted special members (to
conform to guidance like the Rule of Zero) causes ABI changes.

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 14 16:43:38 2018
New Revision: 266152

URL: https://gcc.gnu.org/viewcvs?rev=266152&root=gcc&view=rev
Log:
PR bootstrap/86739
* hash-map.h (hash_map::iterator::reference_pair): New class.
(hash_map::iterator::operator*): Return it rather than std::pair.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hash-map.h

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521

--- Comment #2 from Jonathan Wakely  ---
The C++03 definition of POD struct (which is what matters for the ABI) requires
that it has no user-defined destructor.

Your type has a user-declared destructor, which is implicitly-defined when
odr-used. That is not user-defined. So it's can be a POD struct.

[Bug rtl-optimization/85594] ICE during expand when compiling with -fwrapv -fopenmp

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85594

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
Moreover, adding -O1 -ftree-loop-vectorize makes current trunk snapshot ICE
like this:

% gcc-9.0.0-alpha2018 -O1 -fopenmp -ftree-loop-vectorize -fwrapv -c
gcc/testsuite/gcc.dg/gomp/pr81768-2.c
during GIMPLE pass: ifcvt
gcc/testsuite/gcc.dg/gomp/pr81768-2.c: In function 'foo._omp_fn.1':
gcc/testsuite/gcc.dg/gomp/pr81768-2.c:10:9: internal compiler error: tree
check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461
   10 | #pragma omp target parallel for schedule(static, 32) collapse(3)
  | ^~~
0x6ca2ea tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree.c:9623
0x6ac4fe tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree.h:3154
0x6ac4fe SSA_VAL(tree_node*, bool*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:461
0x6ac4fe vuse_ssa_val
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:479
0x6ac4fe vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:2615
0xe96960 visit_reference_op_load
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:3968
0xe96960 visit_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:4378
0xe981c4 process_bb
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6011
0xe99550 do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6618
0xe9a667 do_rpo_vn(function*, edge_def*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6707
0xd59209 tree_if_conversion(loop*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3066
0xd5a9b6 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3142
0xd5a9b6 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3130

Should I file a separate PR for this?