[Bug tree-optimization/93348] New: [10 Regression] ICE in gimplify_expr, at gimplify.c:14378

[asolokha at gmx dot com]

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

Bug ID: 93348
   Summary: [10 Regression] ICE in gimplify_expr, at
gimplify.c:14378
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase:

int
ya (void)
{
  return (long int) (1 / 0);
}

% gcc-10.0.0-alpha20200119 -w -c rjpbd9ni.c
rjpbd9ni.c: In function 'ya':
rjpbd9ni.c:4:24: internal compiler error: in gimplify_expr, at gimplify.c:14378
4 |   return (long int) (1 / 0);
  | ~~~^~~~
0x63a8da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:14378
0xae75f3 gimplify_modify_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:5765
0xad02fa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:13581
0xad3a76 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:6822
0xadb900 gimplify_and_add(tree_node*, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:486
0xadb900 gimplify_return_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:1667
0xad13b1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:13842
0xad3a76 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:6822
0xad48d3 gimplify_bind_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:1424
0xad0f0d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:13782
0xae8a39 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:6822
0xae8a39 gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:14830
0xae8e53 gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimplify.c:14974
0x92ae47 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cgraphunit.c:669
0x92d94f analyze_functions
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cgraphunit.c:1210
0x92e542 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cgraphunit.c:2956

[Bug ipa/93347] New: [10 Regression] ICE: verify_cgraph_node failed (error: calls_comdat_local is set outside of a comdat group)

[asolokha at gmx dot com]

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

Bug ID: 93347
   Summary: [10 Regression] ICE: verify_cgraph_node failed (error:
calls_comdat_local is set outside of a comdat group)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase, reduced from
clang/testsuite/CodeGenCXX/devirtualize-virtual-function-calls-final.cpp from
the clang 9.0.1 test suite, w/ -O3 --param early-inlining-insns=3 --param
ipa-cp-eval-threshold=100:

% g++-10.0.0-alpha20200119 -O3 --param early-inlining-insns=3 --param
ipa-cp-eval-threshold=100 -c vk0cmj0d.cpp
vk0cmj0d.cpp:26:1: error: calls_comdat_local is set outside of a comdat group
   26 | }
  | ^
_ZTch0_h4_N2dm2tvEv/2 (virtual nx* dm::_ZTch0_h4_N2dm2tvEv()) @0x7f526ae372d0
  Type: function
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible public weak comdat comdat_group:_ZN2dm2tvEv
one_only section:.text._ZN2dm2tvEv (implicit_section) virtual artificial
  References: 
  Referring: 
  Availability: not_available
  Function flags: count:1 (estimated locally) calls_comdat_local
indirect_call_target
  Former thunk fixed offset 4 virtual value 0 indirect_offset 0 has virtual
offset 0
  Called by: 
  Calls: 
during IPA pass: inline
vk0cmj0d.cpp:26:1: internal compiler error: verify_cgraph_node failed
0xb7c71e cgraph_node::verify_node()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cgraph.c:3717
0xb6fc94 symtab_node::verify()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/symtab.c:1300
0xb70dd2 symtab_node::verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/symtab.c:1320
0xdef5bb symtab_node::checking_verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cgraph.h:667
0xdef5bb symbol_table::remove_unreachable_nodes(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/ipa.c:673
0x1947845 ipa_inline
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/ipa-inline.c:2694
0x1947845 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/ipa-inline.c:3089

[Bug target/93346] gcc not generate BZHI

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen  ---
typedef unsigned u;
u bzhi(u src, u inx) { return src & ((1 << inx) - 1); } 


with -O2 -march=skylake generates

movl%esi, %r8d
movl$1, %esi
shlx%r8d, %esi, %esi
leal-1(%rsi), %eax
andl%edi, %eax
ret


clang generates the expected
bzhil   %esi, %edi, %eax
retq

[Bug target/93346] New: gcc not generate BZHI

[andi-gcc at firstfloor dot org]

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

Bug ID: 93346
   Summary: gcc not generate BZHI
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---
Target: x86_64

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
I tried some cross testing with rtl checking enabled, and found another rtl
check bug with the -msave-restore support in config/riscv/riscv-sr.c where it
uses XINT to read from a CONST_INT which is wrong, as it is actually an XWINT
value, and we should be using INTVAL to read the value.  I've tested a patch
for that, and can commit it tomorrow.  -msave-restore is for embedded code
size, so this shouldn't be a problem for linux users.

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

[maxim.cournoyer at gmail dot com]

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

Maxim Cournoyer  changed:

   What|Removed |Added

 CC||maxim.cournoyer at gmail dot 
com

--- Comment #9 from Maxim Cournoyer  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to chuck cranor from comment #3)
> > I think you'll find most build systems that do "-isystem /usr/include"
> > instead of "-I /usr/include" are only using "-isystem" for the change
> > in the warning behavior.  The change in the include path order is not
> > wanted...
> 
> Then they should stop (mis)using -isystem, since it's clearly documented to
> affect the order directories are searched:
> 
>   If a standard system include directory, or a directory specified with
>   -isystem, is also specified with -I, the -I option is ignored.  The
> directory
>   is still searched but as a system directory at its normal position in the
>   system include chain.  This is to ensure that GCC's procedure to fix buggy
>   system headers and the ordering for the "#include_next" directive are not
>   inadvertently changed.  If you really need to change the search order for
>   system directories, use the -nostdinc and/or -isystem options.
> 
> The corollary is that you shouldn't use it unless you really need to change
> the search order for system directories!

About not using it: sure, this works, but now how can a project enable warnings
just for their own headers and not those of the whole system?  This seems to be
a valid use case.

In GNU Guix, we worked around the new behavior described here for GCC >= 6 by
searching headers in CPATH rather than CPLUS_INCLUDE_PATH, because using
CPLUS_INCLUDE_PATH would have the headers treated as system headers and break
the required ordering of GCC's own headers.  The annoyance with using CPATH is
that now warnings are issued for the whole collection of headers rather than
just for those of the project being built.

I experimented with using CPLUS_INCLUDE_PATH and recommendations found here
about making sure none of GCC's internal include paths were being duplicated
through CPLUS_INCLUDE_PATH (e.g., those of glib and gcc) but the compilation
still failed like this:

cd
/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/src/libnrtype
&& /gnu/store/br4id28zs2nx3p2r8nr5kfnk3qway45k-gcc-7.5.0/bin/c++ 
-DHAVE_CONFIG_H -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_MESH -DWITH_SVG2
-I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/src/libnrtype
-I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src/libnrtype
-I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45
-I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/inkscape-1.0beta2_2019-12-03_2b71d25d45/src
-I/tmp/guix-build-inkscape-1.0beta2_2019-12-03_2b71d25d45.drv-0/build/include
-isystem
/gnu/store/6081r9b5hdrwwfqljwsqsjqn8qvf18qz-libpng-1.6.37/include/libpng16
-isystem
/gnu/store/vsba1vjxy0g47251mrrxrhlpqchlmgr3-libxml2-2.9.10/include/libxml2
-isystem
/gnu/store/7y5kcq7pc31rq8y06pfifqi35x3nn0i2-libsoup-minimal-2.68.3/include/libsoup-2.4
-isystem
/gnu/store/khyi8q7glb4h3xv1yaq6vq837z9y3rif-freetype-2.10.1/include/freetype2
-isystem
/gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/uuid
-isystem
/gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/libmount
-isystem
/gnu/store/0d49ps0g5knrny1h8ijss65sb4i54dab-util-linux-2.34/include/blkid
-isystem
/gnu/store/1h4jsfampb408fs3kdzchnvjf21vk5jl-pango-1.42.4/include/pango-1.0
-isystem
/gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/include/glib-2.0
-isystem
/gnu/store/rp02xwl91kb42zi2v7pxcc5jrvwixg36-glib-2.62.4/lib/glib-2.0/include
-isystem /gnu/store/3vkqx4lxlv09gr1674jw01akipvx9h9f-cairo-1.16.0/include/cairo
-isystem
/gnu/store/jj5a0qzzh556v8kis0xba69rsdg9v3n1-harfbuzz-2.6.4/include/harfbuzz
-isystem
/gnu/store/fdvbnbif5giqimfnmlza6ji8jax4lp9z-fribidi-1.0.7/include/fribidi
-isystem
/gnu/store/i9fi2nwynsigjis0gzlba3jl7s0wygwm-pixman-0.38.4/include/pixman-1
-isystem /gnu/store/01r2pxnkgsi039na193pfnz60di5lwln-libgc-7.6.12/include/gc
-isystem
/gnu/store/192b5i8pilw4kaysy8d6zsrcvfjaz8k7-poppler-0.83.0/include/poppler
-isystem
/gnu/store/llg2s8pqpsg4zprzvx0xcdrsaffvap5s-gdl-minimal-3.34.0/include/libgdl-3.0
-isystem
/gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/include/gtkmm-3.0
-isystem
/gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/lib/gtkmm-3.0/include
-isystem
/gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/include/gdkmm-3.0
-isystem
/gnu/store/7lqlc6r8nmwavjhra4f3b4rfa8pkix1r-gtkmm-3.24.2/lib/gdkmm-3.0/include
-isystem
/gnu/store/nz5vdsnx0dn7b36fq29fsq502vqzqx9q-gtk+-3.24.12/include/gtk-3.0/unix-print
-isystem
/gnu/store/nz5vdsnx0dn7b36fq29fsq502vqzqx9q-gtk+-3.24.12/include/gtk-3.0

[Bug target/93304] RISC-V: Function with interrupt attribute use register without save/restore at prologue/epilogue

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:e0a5b313c1a3edfb33a28b8d8fea92e01490ebb3

commit r10-6101-ge0a5b313c1a3edfb33a28b8d8fea92e01490ebb3
Author: Kito Cheng 
Date:   Fri Jan 17 19:49:15 2020 +0800

RISC-V: Disallow regrenme if the TO register never used before for
interrupt functions

gcc/ChangeLog

PR target/93304
* config/riscv/riscv-protos.h (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.c (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.h (HARD_REGNO_RENAME_OK): Defined.

gcc/testsuite/ChangeLog

PR target/93304
* gcc.target/riscv/pr93304.c: New test.

[Bug c++/93345] New: [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247

[asolokha at gmx dot com]

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

Bug ID: 93345
   Summary: [10 Regression] ICE in nothrow_spec_p, at
cp/except.c:1247
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase reduced from
test/CodeGenCXX/instantiate-temporaries.cpp from the clang 9.0.1 test suite:

struct ln {
  ~ln ();
};

struct ry {
  ln kj;
};

template
void
dz ()
{
  ry{};
}

% g++-10.0.0-alpha20200119 -c qziipxqi.cpp
qziipxqi.cpp: In function 'void dz()':
qziipxqi.cpp:13:6: internal compiler error: in nothrow_spec_p, at
cp/except.c:1247
   13 |   ry{};
  |  ^
0x61ed48 nothrow_spec_p(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/except.c:1247
0x92a3e9 check_noexcept_r
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/except.c:1146
0x129d6ea walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.c:11954
0x12a12aa walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.c:12310
0x92a09f expr_noexcept_p(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/except.c:1221
0x8e8763 cxx_maybe_build_cleanup(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/decl.c:17405
0xa46c40 build_target_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/tree.c:511
0xa25f44 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/semantics.c:2970
0x986772 cp_parser_functional_cast
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:29391
0x99ea48 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:7134
0x9811ea cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:9508
0x982dce cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:9813
0x9831a3 cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:9981
0x9861e8 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:11621
0x9915f3 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:11417
0x992e78 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:11768
0x992f58 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:11718
0x9aaa45 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:22948
0x9aaa45 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:22999
0x9ade36 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:28821

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
I'm seeing most of these on nios2-elf as well.

Including  doesn't fix the malloc-callbacks.c failures on this and
other newlib targets; newlib's version of that header file defines alloca as a
function-like macro instead of a function.

Also observed on nios2-elf:

FAIL: gcc.dg/analyzer/pattern-test-2.c  == 0 (test for warnings, line
21)
FAIL: gcc.dg/analyzer/pattern-test-2.c  != 0 (test for warnings, line
21)
FAIL: gcc.dg/analyzer/pattern-test-2.c (test for excess errors)
Excess errors:
/path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning: pattern
match on 'p == 0'
/path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning: pattern
match on 'q == 0'

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Jakub's patch looks OK, and works for the testcase.

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-21
 Ever confirmed|0   |1

--- Comment #2 from Jim Wilson  ---
I can reproduce.  Reproducing requires enabling rtl checking which is not on by
default.  I suspect that there are other similar problems, as we probably
haven't tested a build with rtl checking enabled before.

The problem is in riscv_rtx_costs which only needs to return valid values for
valid rtl, and it is failing the rtl check for invalid rtl, so this isn't a
major problem if rtl checking is off, but it does need to be fixed to be safe.

[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to seurer from comment #4)
> Not sure if the patch was done but the failure changed a bit over the
> weekend.
> 
> New failures (update from 3684bbb022cd75da55e1457673f269980aa12cdf to
> f4d83eba60b5b1292a7cae660f03a2377e92a845):
> FAIL: gcc.dg/analyzer/pattern-test-2.c  == 0 (test for warnings,
> line 21)
> FAIL: gcc.dg/analyzer/pattern-test-2.c  != 0 (test for warnings,
> line 21)
> 
> New passes:
> FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
> FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)

I haven't applied the patch from comment #3 yet; I think what you're seeing is
the effect of 8863f61c9c9dcec6003c4d61665b226569c0c3b2, which added unique
names to the four dg-warning tests at line 21.

[Bug tree-optimization/93344] New: interchange does not work when using the address rather than direct array

[pinskia at gcc dot gnu.org]

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

Bug ID: 93344
   Summary: interchange does not work when using the address
rather than direct array
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
#define N 100
#define M 
struct S { int a ; int b ; int c ; };
struct S A[N][M];

int __attribute__((noinline))
foo (void)
{
  int i, j;

  for( i = 0; i < M; i++)
for( j = 0; j < N; j++)
 {
  struct S *a = A[j];
  a[i].b = 5 * a[i].b;
 }

  return A[0][0].b + A[N-1][M-1].b;
}

int __attribute__((noinline))
foo1 (void)
{
  int i, j;

  for( i = 0; i < M; i++)
for( j = 0; j < N; j++)
 {
  A[j][i].b = 5 * A[j][i].b;
 }

  return A[0][0].b + A[N-1][M-1].b;
}

 CUT 
foo does not work but foo1 does work though.

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Martin Liška from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > Thanks for the report. Can you please send us the command line used for 
> > > the
> > > compilation? Ideally output of -v option.
> > 
> > g++ -o xxx xxx.cc -Ofast -std=c++2a -s -msse2 -maes -msha
> 
> Fine and what tells gcc -v?

D:\hg\w4\fast_io\testsuites\0003.hash>g++ -o sha1 sha1.cc -Ofast -std=c++2a -s
-maes -msse2 -msha -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-git/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --with-arch=x86-64 --with-tune=nocona
--enable-languages=c,lto,c++ --enable-shared --enable-static
--enable-threads=mcf --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --enable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='master HEAD with MCF
thread model, built by cqwrteur.' --with-bugurl=https://gcc-mcf.lhmouse.com/
--with-gnu-as --with-gnu-ld --disable-tls --enable-plugin --disable-bootstrap
Thread model: mcf
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200119 (experimental) (master HEAD with MCF thread model,
built by cqwrteur.)
COLLECT_GCC_OPTIONS='-o' 'sha1.exe' '-Ofast' '-std=c++2a' '-s' '-maes' '-msse2'
'-msha' '-v' '-shared-libgcc' '-mtune=nocona' '-march=x86-64'
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/cc1plus.exe -quiet -v
-U_REENTRANT sha1.cc -quiet -dumpbase sha1.cc -maes -msse2 -msha -mtune=nocona
-march=x86-64 -auxbase sha1 -Ofast -std=c++2a -version -o
C:\Users\unlvs\AppData\Local\Temp\ccx2i3tH.s
GNU C++17 (master HEAD with MCF thread model, built by cqwrteur.) version
10.0.1 20200119 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 10.0.0 20200109 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "D:/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1/x86_64-w64-mingw32

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1/backward
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/include
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/include-fixed

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++17 (master HEAD with MCF thread model, built by cqwrteur.) version
10.0.1 20200119 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 10.0.0 20200109 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 377d01f7dcdda995e91288532e243e65
sha1.cc: In function 'int main()':
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1176
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/93343] New: coroutine ICE

[euloanty at live dot com]

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

Bug ID: 93343
   Summary: coroutine  ICE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

g++ -o coroutine_epoll coroutine_epoll.cc -Ofast -std=c++2a -s -fcoroutines

coroutine_epoll.cc: In function ‘void
_Z6listenRN7fast_io16basic_tcp_serverILb1EEE.actor(listen(fast_io::async_tcp_server&)::_Z6listenRN7fast_io16basic_tcp_serverILb1EEE.frame*)’:
coroutine_epoll.cc:38:2: internal compiler error: in gimplify_expr, at
gimplify.c:14378
   38 |  co_await awaitable(acc);
  |  ^~~~
0x7619c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14378
0xd924cb gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:6822
0xd7a395 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13973
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd78ce4 gimplify_and_add(tree_node*, gimple**)
../../gcc/gcc/gimplify.c:486
0xd78ce4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13932
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd7a7ab gimplify_statement_list
../../gcc/gcc/gimplify.c:1869
0xd7a7ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14025
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd7dcbb gimplify_bind_expr
../../gcc/gcc/gimplify.c:1424
0xd7a3d4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13782
0xd91aa5 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd91aa5 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:14830
0xd91ea3 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:14974
0xbdc377 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:669
0xbdee6f analyze_functions
../../gcc/gcc/cgraphunit.c:1210
0xbdfa32 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2956
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/93335] [9/10 Regression] ICE: in extract_insn, at recog.c:2310 with __builtin_sub_overflow_p() on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r9-5233-ga58fe3c5ca1f0101c4af7f0c5b860cc4d49cd4cb

[Bug target/91753] Bad register allocation of multi-register types

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Wilco from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > lower-subreg should have be able to help here.  I wonder why it did not ...
> 
> I'm not sure how it can help. When you write a part of a multi-register mode
> using subreg, you get incorrect liveness info. This is why splitting 64-bit
> types on 32-bit targets before register allocation gives such a huge gain.

Actually no, lower-subreg was not supposed to fix incorrect liveness info but
rather improve other things.

Also lower-subreg does not handle OImode/CImode/XImode as an array of vectors
but rather as integer modes.  You can see that effect by changing the define
FORCE_LOWERING to 1 and see how it will decompose the registers.  Really we
want to decompose the registers to TImode in this case rather than DImode.  I
have not looked into how we could enhance lower-subreg to do that.  This will
fix the issue even better.

[Bug tree-optimization/93342] New: wrong AVX mask generation with -funsafe-math-optimizations

[nathanael.schaeffer at gmail dot com]

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

Bug ID: 93342
   Summary: wrong AVX mask generation with
-funsafe-math-optimizations
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.schaeffer at gmail dot com
  Target Milestone: ---

When trying to produce a xor mask to negate even elements in an AVX vector, gcc
produces wrong code with -funsafe-math-optimizations.

I've tried several ways, all giving the same wrong answer: a mask negating ALL
elements instead of just the even ones.
Since the mask is generated using INTEGER arithmetic, I don't understand the
issue here.

The only correct way with avx is to define a variable with the mask already
set.
With avx2, one can use integer intrinsics, which will produce correct mask.

The code showing the bug can be seen here.
https://godbolt.org/z/q9eamc

For the record, I also copy the code below.
When compiling the following with -O -mavx2 -funsafe-math-optimizations -S, the
mask is wrong. Without -funsafe-math-optimizations it is correct.
Since the mask is generated using integer arithmetic, I don't understand the
issue here, as -funsafe-math-optimizations only affects floating point
(according to man page).
Even stranger, the same mask, but now xor-ed using integer avx2 intrinsics
gives  the correct resuts...

#include 
typedef __m128d v2d;
typedef __m256d v4d;

// generates: vxorpd  ymm0, ymm0, YMMWORD PTR wrong_mask
v4d negate_even_fail(v4d v) {
__m256i mask = _mm256_setr_epi32(0,-2147483648, 0,0, 0,-2147483648, 0,0);
return _mm256_xor_pd(v, _mm256_castsi256_pd(mask));
}

// generates: vxorpd  ymm0, ymm0, YMMWORD PTR correct_mask
v4d negate_even_does_not_fail(v4d v) {
__m256i mask = _mm256_setr_epi32(0,-2147483648, 0,0, 0,-2147483648, 0,0);
return _mm256_castsi256_pd(_mm256_xor_si256(_mm256_castpd_si256(v), mask));
}

[Bug target/90722] ICE with __builtin_convertvector with -msve-vector-bits=256

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #1 from Andrew Pinski  ---
Works for me with the trunk so closing as fixed.

apinski@xeond:~/src/toolchain-10$
./marvell-tools/bin/aarch64-marvell-linux-gnu-gcc 8881.c -S -O2
-march=armv8.2-a+sve -msve-vector-bits=256 -o -
.arch armv8.2-a+crc+sve
.file   "8881.c"
.text
.align  2
.p2align 4,,11
.global f4
.type   f4, %function
f4:
.LFB0:
.cfi_startproc
ptrue   p0.b, vl32
mov z1.d, #0
ld1dz0.d, p0/z, [x0]
fcvtzs  z1.s, p0/m, z1.d
fcvtzs  z0.s, p0/m, z0.d
uzp1z0.s, z0.s, z1.s
str q0, [x1]
ret
.cfi_endproc
.LFE0:
.size   f4, .-f4
.ident  "GCC: (Marvell Development Version) 10.0.0 20200113
(experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/93224] 29_atomics/atomic_ref/float.cc fails with a tweaked IPA inliner

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #2)
> So a negative zero is reached ;)

No it isn't, the value is non-zero:

a.load() - 208.0l:
-0.00640949485492072091897029459292263811609480228526081191375851631164551

The test just makes assumptions about the FP math which isn't true for power64
long double.

[Bug target/93221] [10 Regression] ICE maximum number of generated reload insns per insn achieved (90) on aarch64

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
Probably missing live range splitting or somesuch, as envisioned by Vladimir in
its approval message.  Feel free to eventually revert it.

[Bug target/93341] [10 Regression] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:221

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2020-1-20
 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org
  Known to work||9.2.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
  Known to fail||10.0

[Bug target/93341] New: [10 Regression] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:221

[marxin at gcc dot gnu.org]

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

Bug ID: 93341
   Summary: [10 Regression] ICE in aarch64_do_track_speculation,
at config/aarch64/aarch64-speculation.cc:221
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

I see the following ICE:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c
-mtrack-speculation
during RTL pass: speculation
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c: In
function ‘synths_’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c:14:1:
internal compiler error: in aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:221
   14 | }
  | ^
0x65079b aarch64_do_track_speculation()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64-speculation.cc:221
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/92599] [8/9 regression] ICE in speculative_call_info, at cgraph.c:1142

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
I am testing the following fix. it was indeed a call_stmt hash getting
out of sync.  I will need to refactor the code next stage1 as it got
quite ugly (it was not pretty before the mutli-target speculation was
added, but it is more obvious now).

Honza

* cgraph.c (cgraph_edge::resolve_speculation,
cgraph_edge::redirect_call_stmt_to_callee): Fix updating of call stmt
hash.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 187f6ed30ba..4407fc6ecfb 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1248,7 +1254,22 @@ cgraph_edge::resolve_speculation (cgraph_edge *edge,
tree callee_decl)
   else
 e2->callee->remove_symbol_and_inline_clones ();
   if (edge->caller->call_site_hash)
-cgraph_update_edge_in_call_site_hash (edge);
+{
+  /* We always maintain direct edge in the call site hash, if one
+exists.  */
+  if (!edge->num_speculative_call_targets_p ())
+   cgraph_update_edge_in_call_site_hash (edge);
+  else
+   {
+ cgraph_edge *e;
+ for (e = edge->caller->callees;
+  e->call_stmt != edge->call_stmt
+  || e->lto_stmt_uid != edge->lto_stmt_uid;
+  e = e->next_callee)
+   ;
+ cgraph_update_edge_in_call_site_hash (e);
+   }
+}
   return edge;
 }

@@ -1414,7 +1435,20 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge
*e)
  /* Indirect edges are not both in the call site hash.
 get it updated.  */
  if (e->caller->call_site_hash)
-   cgraph_update_edge_in_call_site_hash (e2);
+   {
+ if (!e2->num_speculative_call_targets_p ())
+   cgraph_update_edge_in_call_site_hash (e2);
+ else
+   {
+ cgraph_edge *e;
+ for (e = e2->caller->callees;
+  e->call_stmt != e2->call_stmt
+  || e->lto_stmt_uid != e2->lto_stmt_uid;
+  e = e->next_callee)
+   ;
+ cgraph_update_edge_in_call_site_hash (e);
+   }
+   }
  pop_cfun ();
  /* Continue redirecting E to proper target.  */
}

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||wilson at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce with very similarly configured cross.
I do see:
Trying 14 -> 15:
   14: r86:SI=r90:SI 0>>r89:SI#0
  REG_DEAD r90:SI
  REG_DEAD r89:SI
   15: r87:SI=r86:SI&0x1f
  REG_DEAD r86:SI
Failed to match this instruction:
(set (reg:SI 87)
(zero_extract:SI (reg:SI 90)
(const_int 5 [0x5])
(zero_extend:SI (subreg:QI (reg:SI 89) 0
Failed to match this instruction:
(set (reg:SI 87)
(zero_extract:SI (reg:SI 90)
(const_int 5 [0x5])
(and:SI (reg:SI 89)
(const_int 255 [0xff]
and
Failed to match this instruction:
(set (reg:SI 88 [ i ])
(lshiftrt:SI (reg/v:SI 84 [ i ])
(subreg:QI (zero_extract:SI (reg:SI 90)
(const_int 5 [0x5])
(zero_extend:SI (subreg:QI (reg:SI 89) 0))) 0)))
Failed to match this instruction:
(set (reg:SI 88 [ i ])
(lshiftrt:SI (reg/v:SI 84 [ i ])
(subreg:QI (zero_extract:SI (reg:SI 90)
(const_int 5 [0x5])
(and:SI (reg:SI 89)
(const_int 255 [0xff]))) 0)))
etc. in the combine dump, but no such zero_extract was ever matched (I couldn't
see how it could be, all the zero_extract riscv patterns require CONST_INT in
the last two operands) and I see no ZERO_EXTRACT in all the set_src_cost calls
called from make_extraction.

So, any special tuning/whatever that isn't shown?

The fix would likely be something along the lines of
--- gcc/config/riscv/riscv.c2020-01-12 11:54:36.385413831 +0100
+++ gcc/config/riscv/riscv.c2020-01-20 20:06:04.729542828 +0100
@@ -1642,7 +1642,10 @@ riscv_rtx_costs (rtx x, machine_mode mod

 case ZERO_EXTRACT:
   /* This is an SImode shift.  */
-  if (outer_code == SET && (INTVAL (XEXP (x, 2)) > 0)
- && (INTVAL (XEXP (x, 1)) + INTVAL (XEXP (x, 2)) == 32))
+  if (outer_code == SET
+ && CONST_INT_P (XEXP (x, 1))
+ && CONST_INT_P (XEXP (x, 2))
+ && INTVAL (XEXP (x, 2)) > 0
+ && INTVAL (XEXP (x, 1)) + INTVAL (XEXP (x, 2)) == 32)
{
  *total = COSTS_N_INSNS (SINGLE_SHIFT_COST);

but I'd say being able to reproduce is important.

[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from seurer at gcc dot gnu.org ---
Not sure if the patch was done but the failure changed a bit over the weekend.

New failures (update from 3684bbb022cd75da55e1457673f269980aa12cdf to
f4d83eba60b5b1292a7cae660f03a2377e92a845):
FAIL: gcc.dg/analyzer/pattern-test-2.c  == 0 (test for warnings, line
21)
FAIL: gcc.dg/analyzer/pattern-test-2.c  != 0 (test for warnings, line
21)

New passes:
FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/pattern-test-2.c  (test for warnings, line 21)

[Bug target/93124] [10 Regression] ICE in df_install_refs at df-scan.c:2376

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/93314] [8/9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Hmm, yeah.  Before the patch we silently accepted the code
and generated an unconditional trap for a null dereference,
which doesn't sound right either.  This is because we used
to fold the dummy object pointer (represented using an
INTEGER_CST with void_type) into a normal null pointer.

Where should this be trapped?  The error for accessing
a non-static data member is suppressed for sizeof,
and obviously needs to be for sizeof(S::m):

  /* DR 613/850: Can use non-static data members without an associated
 object in sizeof/decltype/alignof.  */
  if (is_dummy_object (object) && cp_unevaluated_operand == 0
  && (!processing_template_decl || !current_class_ref))

A see-one-play-one fix would be to force cp_unevaluated_operand
to zero while parsing an array dimension, on the basis that the
dimension should either be constant (standard C++) or can be
evaluated (GNU VLAs).  That feels really hackish though...

Should we instead trap this during gimplification?  But then
that would probably make:

   sizeof(char[sizeof(char[S::m])])

valid, which doesn't sound right either.

[Bug fortran/93340] New: [8/9/10 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[gs...@t-online.de]

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

Bug ID: 93340
   Summary: [8/9/10 Regression] ICE in check_constant_initializer,
at fortran/trans-decl.c:5450
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Since gfortran-7 :


$ cat z1.f90
program p
   character c(2) /'a', 'b'(1:1)/
   character d(2) /'a', 'bc'(1:1)/
end


$ gfortran-6 -c z1.f90
z1.f90:3:25:

character d(2) /'a', 'bc'(1:1)/
 1
Warning: Initialization string at (1) was truncated to fit the variable (1/2)


$ gfortran-10-20200119 -c z1.f90
z1.f90:4:0:

4 | end
  |
internal compiler error: Segmentation fault
0xbaaaff crash_signal
../../gcc/toplev.c:328
0x710bce check_constant_initializer
../../gcc/fortran/trans-decl.c:5450
0x7114b4 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:5533
0x6db932 do_traverse_symtree
../../gcc/fortran/symbol.c:4165
0x71d15a gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6989
0x6a5e06 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6a5e06 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug tree-optimization/93332] target-dependent inaccurate range info for some expressions

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
You can use --param logical-op-non-short-circuit=0 or --param
logical-op-non-short-circuit=1 in the mean time to force particular decisions
about branch costs (or -mbranch-cost= on certain targets).

[Bug tree-optimization/93332] target-dependent inaccurate range info for some expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is not really a bug nor anything weird, depending on BRANCH_COST etc.,
GIMPLE is different already from the start,
  z_22 = vals[i.4_20];
  _23 = z_22 == 0;
  _24 = z_22 > 2;
  _25 = _23 | _24;
  if (_25 != 0)
on x86, while
  z_19 = vals[i.4_17];
  if (z_19 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  if (z_19 > 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435457]:
And vrp works as designed, in both x86_64 and powerpc64 vrp1
-fdump-tree-vrp-alias-details dump you can see:
  # RANGE [2, 4] NONZERO 6
  iftmp.0_3 = iftmp.6_26 * 2;
  # PT = { D.2388 } (escaped, escaped heap)
  # USE = nonlocal { D.2388 D.2389 } (escaped, escaped heap)
  # CLB = nonlocal { D.2388 D.2389 } (escaped, escaped heap)
  _5 = operator new [] (iftmp.0_3);
so VRP knows and recorded that the first operator new allocates 2-4 bytes.
The thing that happens is that due to the differen CFG PRE decides to optimize
and the value range info we have stored in the IL isn't something that is
recomputed all the time any time we perform some optimization, so as soon as
some optimization pass creates something new or invalidates the range info, it
is thrown away.  During vrp2 it will be computed again.

So, guess you are looking for the stuff Andrew/Aldy work on, which will allow
the range info to be computed in other passes too.

[Bug fortran/93339] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2830

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

This slightly modified variant compiles :


$ cat z2.f90
program p
   type t
  character(:), allocatable :: a(:)
   end type
   type(t) :: x
   associate (y => x%a)
  associate (z => y)
  end associate
   end associate
end

[Bug fortran/93339] New: [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2830

[gs...@t-online.de]

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

Bug ID: 93339
   Summary: [9/10 Regression] ICE in gimplify_var_or_parm_decl, at
gimplify.c:2830
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20181007 and 20181014 :


$ cat z1.f90
program p
   type t
  character(:), allocatable :: a(:)
   end type
   type(t) :: x
   associate (y => x%a)
  associate (z => x%a)
  end associate
   end associate
end


$ gfortran-9-20181007 -c z1.f90
$
$ gfortran-10-20200119 -c z1.f90
z1.f90:7:0:

7 |   associate (z => x%a)
  |
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830
0x941a24 gimplify_var_or_parm_decl
../../gcc/gimplify.c:2830
0x948e57 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14041
0x95249a gimplify_modify_expr
../../gcc/gimplify.c:5765
0x949013 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13581
0x94afa8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0x94927b gimplify_statement_list
../../gcc/gimplify.c:1869
0x94927b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14025
0x94afa8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0x94b941 gimplify_bind_expr
../../gcc/gimplify.c:1424
0x948a9a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13782
0x94afa8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0x94927b gimplify_statement_list
../../gcc/gimplify.c:1869
0x94927b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14025
0x94afa8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0x94b941 gimplify_bind_expr
../../gcc/gimplify.c:1424
0x948a9a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13782
0x94afa8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0x94c3ea gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:14830
0x94c6d5 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:14974
0x7f2827 cgraph_node::analyze()
../../gcc/cgraphunit.c:669

[Bug fortran/93338] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

No ICE without "target", except for -fno-automatic :


$ cat z2.f90
program p
   type t
  character(:), allocatable :: a(:)
   end type
   type(t), allocatable :: x
   x = t(['abc'])
   associate (y => x%a(:))
  if ( any(y /= 'abc') ) stop
   end associate
end


$ gfortran-10-20200119 -c z2.f90 -O0 -fno-automatic
$ gfortran-10-20200119 -c z2.f90 -O2
$
$ gfortran-10-20200119 -c z1.f90 -O2 -fno-automatic
during IPA pass: inline
#...

[Bug fortran/93338] New: [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282

[gs...@t-online.de]

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

Bug ID: 93338
   Summary: [8/9/10 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.c:282
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gfortran-8 (before 20180525) at -O[123] :
(gfortran-7 compiles it)


$ cat z1.f90
program p
   type t
  character(:), allocatable :: a(:)
   end type
   type(t), allocatable, target :: x
   x = t(['abc'])
   associate (y => x%a(:))
  if ( any(y /= 'abc') ) stop
   end associate
end


$ gfortran-7 -c z1.f90 -O2
$ gfortran-10-20200119 -c z1.f90 -O0
$
$ gfortran-10-20200119 -c z1.f90 -O2
during IPA pass: inline
z1.f90:10:0:

   10 | end
  |
internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:282
0xd7f325 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.c:279
0xc143fe make_ssa_name
../../gcc/tree-ssanames.h:115
0xc143fe remap_ssa_name
../../gcc/tree-inline.c:258
0xc16eb7 copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.c:1251
0xe0c0a5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11954
0xe0c63e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12284
0xc1356c remap_type_1
../../gcc/tree-inline.c:617
0xc13838 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:735
0xc13407 remap_type_1
../../gcc/tree-inline.c:448
0xc13838 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:735
0xc143eb remap_ssa_name
../../gcc/tree-inline.c:258
0xc17787 remap_gimple_op_r
../../gcc/tree-inline.c:1053
0xe0c0a5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11954
0x93b4cd walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0xc15a1f remap_gimple_stmt
../../gcc/tree-inline.c:1948
0xc17cf3 copy_bb
../../gcc/tree-inline.c:1998
0xc191ba copy_cfg_body
../../gcc/tree-inline.c:3012
0xc191ba copy_body
../../gcc/tree-inline.c:3260
0xc1be40 expand_call_inline
../../gcc/tree-inline.c:5051
0xc1d4a1 gimple_expand_calls_inline
../../gcc/tree-inline.c:5241

[Bug fortran/93337] New: [9/10 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[gs...@t-online.de]

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

Bug ID: 93337
   Summary: [9/10 Regression] ICE in gfc_dt_upper_string, at
fortran/module.c:441
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This has changed between 20180909 and 20180916 :
(class with missing attribute allocatable or pointer)


$ cat z1.f90
program p
   type t
  character(:), allocatable :: a
   end type
   class(t) :: x
   x = x
end


$ cat z2.f90
program p
   type t
  character(:), allocatable :: a
   end type
   class(t) :: x, y
   y = x
end


$ gfortran-9-20180909 -c z1.f90
z1.f90:5:16:

5 |class(t) :: x
  |1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
z1.f90:6:3:

6 |x = x
  |   1
Error: Nonallocatable variable must not be polymorphic in intrinsic assignment
at (1) - check that there is a matching specific subroutine for '=' operator


$ gfortran-10-20200119 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbaaaff crash_signal
../../gcc/toplev.c:328
0x6851f0 gfc_dt_upper_string(char const*)
../../gcc/fortran/module.c:441
0x625e6a get_unique_type_string
../../gcc/fortran/class.c:486
0x626888 get_unique_hashed_string
../../gcc/fortran/class.c:505
0x626daa gfc_find_derived_vtab(gfc_symbol*)
../../gcc/fortran/class.c:2266
0x62ab95 gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2868
0x67a802 gfc_match_assignment()
../../gcc/fortran/match.c:1375
0x69e140 match_word
../../gcc/fortran/parse.c:65
0x69e140 decode_statement
../../gcc/fortran/parse.c:361
0x69fc3a next_free
../../gcc/fortran/parse.c:1279
0x69fc3a next_statement
../../gcc/fortran/parse.c:1511
0x6a128b parse_spec
../../gcc/fortran/parse.c:3922
0x6a405c parse_progunit
../../gcc/fortran/parse.c:5848
0x6a5739 gfc_parse_file()
../../gcc/fortran/parse.c:6388
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/93014] [9 Regression] ICE when initialising vector references with -flax-vector-conversions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
Summary|[9/10 Regression] ICE when  |[9 Regression] ICE when
   |initialising vector |initialising vector
   |references with |references with
   |-flax-vector-conversions|-flax-vector-conversions
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Bisection shows this started already to ICE with r260621 i.e.
r9-595-g955da5e5443724cb59f8fbd854c13e78c68bf000 and got fixed by your:

Author: rsandifo
Date: Mon Dec 23 09:43:35 2019
New Revision: 279716

URL: https://gcc.gnu.org/viewcvs?rev=279716=gcc=rev
Log:
[C++] Fix ICE for binding lax vector conversions to references (PR 93014)

This test:

typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si  = x;

ICEs with:

a.c:4:11: internal compiler error: in convert_like_real, at cp/call.c:7670

This started with r260780, which had the effect of making lvalue_kind
look through VIEW_CONVERT_EXPR in all cases, not just for location
wrappers.  This also means that:

typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si  = reinterpret_cast(x);

is now valid despite the result of the cast being an rvalue.

The patch attempts to fix that by calling rvalue on the input to the
conversion, so that the tree looks the same as for:

  extern v16qi x;
  v4si  = (v4si)x;

which is already handled correctly.

2019-12-23  Richard Sandiford  

gcc/cp/
* cvt.c (ocp_convert): Apply rvalue to the source of vector
conversions.
* typeck.c (build_reinterpret_cast_1): Likewise.

gcc/testsuite/
* g++.dg/ext/vector39.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector39.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[ch3root at openwall dot com]

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

--- Comment #43 from Alexander Cherepanov  ---
The following example demonstrates that the instability taints the surrounding
code even if it's in dead code itself. In particular, this shows that even
making comparisons like ` + 1 == ` undefined will not help.

--
#include 
#include 

__attribute__((noipa)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }

__attribute__((noipa)) // imagine it in a separate TU
static void g(int a)
{
printf("%d\n", a);
exit(0);
}

static void f(int c, void *p, void *q, void *r)
{
while (c) {
g(p == r);

if (p != q && q == r)
puts("unreachable");
}
}

int main(int c, char **v)
{
(void)v;

int x[5];
int y[2];

void *p = 
void *q =  + 1;

opaque(q); // escaped
void *r = opaque(p); // hide the provenance of p

f(c, p, q, r);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
1
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200120 (experimental)
--

[Bug c++/93014] [9/10 Regression] ICE when initialising vector references with -flax-vector-conversions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So, shall we treat VIEW_CONVERT_EXPR as lvalue only if it has compatible type
with its operand?

Note, I can't reproduce the ICE, neither on x86_64 with -O2
-flax-vector-conversions -mavx512f (and all -std=c++* options I've tried), nor
in cross to aarch64-linux.

[Bug d/92792] [10 Regression] symbols dropped from libphobos

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If it is possible to readd them, it would be certainly better than bumping the
soname.  If the latter, it should be done the sooner the better.

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Related: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01183.html (full thread)

Namely, AMD GCN has different ISA – and depending which are available in the
binary, the hardware could be chosen; having the wrong ISA one will fail while
a fat binary might support multiple. That's similar to this issue, except this
affects the same libgomp plugin, while the main discussion here is between
different plugins (or none for -foffload=disable).

Fun part: Assume one main program, which supports one set of (GPU/ISA) and a
linked (or dlopen'ed ?) library which supports another (GPU, ISA) set…

[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Botcazou  ---
Fixing.

[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> The ICE started with r10-2840-g70cdb21e579191fe9f0f1d45e328908e59c0179e
> but we generated silently wrong-code before that, I believe since
> r7-5812-ga271e415611a80f1e86e625fd61360e193d04474
>   ldr r3, .L3
>   ldr r3, [r3]
>   ldm r3, {r0, r1}
>   b   bar
> is what we generate with that r244249 and up, which likely doesn't handle if
> a is not 8 (or just 4) byte aligned.

This change has removed the clobbering of MODE, which the mode of the TARGET
both for store_field:

/* Store the value of EXP (an expression tree)
   into a subfield of TARGET which has mode MODE and occupies
   BITSIZE bits, starting BITPOS bits from the start of TARGET.

and store_bit_field:

/* Generate code to store value from rtx VALUE
   into a bit-field within structure STR_RTX
   containing BITSIZE bits starting at bit BITNUM.

   FIELDMODE is the machine-mode of the FIELD_DECL node for this field.

by an integral mode based on the size of the expression:

  HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
  mode = smallest_mode_for_size (size * BITS_PER_UNIT, MODE_INT);

so it was supposed to be a progress.  Maybe I should have gone the other way
around and clobbered it on all paths...

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Yet another possibility is to create these in libsupc++ in assembly, but
> > that would need to be macroized.
> 
> I was assuming we'd do that. It would be ugly, but no worse than some of the
> other compat hacks we aready have.

That is something we already have in the Red Hat Developer Toolset
libstdc++_nonshared.a, like below.
Just note that this isn't ifdefed completely out if DFP is enabled (could use
e.g. configure test
or something for that, compile:
namespace __cxxabiv1
{
  class __class_type_info;
}
namespace std
{
  struct type_info
  {
virtual ~type_info();
virtual bool __is_pointer_p() const;
virtual bool __is_function_p() const;
virtual bool __do_catch(const type_info *__thr_type, void **__thr_obj,
unsigned __outer) const;
virtual bool __do_upcast(const __cxxabiv1::__class_type_info *__target,
void **__obj_ptr) const;
const char *__name;
explicit type_info(const char *__n): __name(__n) { }
type_info& operator=(const type_info&);
type_info(const type_info&);
  };
}
namespace __cxxabiv1
{
  struct __fundamental_type_info : public std::type_info
  {
explicit
__fundamental_type_info(const char* __n) : std::type_info(__n) { }
virtual
~__fundamental_type_info();
  };
__fundamental_type_info::~__fundamental_type_info () {}
}
and check for those DFP symbols in there) and supports only the architectures
RHEL cares about (plus ia64),
the abi-tag note also would need to be specific.
Or perhaps instead a script that would parse assembly emitted for the above
source code and adjust it
to contain the DFP symbols instead of all the others.

Though, the FE hack seems to be easiest to me.

/* Copyright (C) 2012-2017 Free Software Foundation, Inc.

   This file is part of the GNU ISO C++ Library.  This library is free
   software; you can redistribute it and/or modify it under the
   terms of the GNU General Public License as published by the
   Free Software Foundation; either version 3, or (at your option)
   any later version.

   This library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   Under Section 7 of GPL version 3, you are granted additional
   permissions described in the GCC Runtime Library Exception, version
   3.1, as published by the Free Software Foundation.

   You should have received a copy of the GNU General Public License and
   a copy of the GCC Runtime Library Exception along with this program;
   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
   .  */

#if defined __x86_64__ || defined __powerpc64__ || defined __s390x__ || defined
__ia64__ || defined __aarch64__ \
|| defined __i386__ || defined __powerpc__ || defined __s390__
#ifdef __i386__
#define ALIGN1  .align 4
#elif defined __x86_64__
#define ALIGN1  .align 32
#define ALIGN2  .align 16
#elif defined __ia64__
#define ALIGN1  .align 8
#define ALIGN3  .align 8
#define SECTION3(x).section .gnu.linkonce.s.x,"aws",@progbits
#define POINTER data8
#define FLAGS data4
#define PAD .skip 4
#define STRING stringz
#elif defined __powerpc64__
#define ALIGN1  .align 3
#define ALIGN3  .align 3
#elif defined __powerpc__
#define ALIGN1  .align 2
#define ALIGN3  .align 2
#define SECTION2(x).section .gnu.linkonce.s.x,"aw",@progbits
#define SECTION3(x)SECTION2(x)
#elif defined __aarch64__
#define ALIGN1  .align 3
#define ALIGN3  .align 3
#define POINTER .xword
#define FLAGS   .word
#define OBJECT  %object
#elif defined __s390x__
#define ALIGN1  .align 8
#define ALIGN3  .align 2
#elif defined __s390__
#define ALIGN1  .align 4
#define ALIGN3  .align 2
#endif
#if defined __x86_64__ || defined __powerpc64__ || defined __s390x__ || defined
__ia64__ || defined __aarch64__
#define SIZE1   32
#define SIZE2   16
#define OFF 16
#ifndef POINTER
#define POINTER .quad
#endif
#ifndef FLAGS
#define FLAGS .long
#endif
#ifndef PAD
#define PAD .zero 4
#endif
#else
#define SIZE1   16
#define SIZE2   8
#define OFF 8
#ifndef POINTER
#define POINTER .long
#endif
#ifndef FLAGS
#define FLAGS .long
#endif
#ifndef PAD
#define PAD
#endif
#endif
#ifndef SYM
#define SYM(x)x
#endif
#ifndef ALIGN2
#define ALIGN2 ALIGN1
#endif
#ifndef ALIGN3
#define ALIGN3
#endif
#ifndef OBJECT
#define OBJECT @object
#endif
#ifndef SECTION1
#define SECTION1(x).section .gnu.linkonce.d.rel.ro.x,"aw",@progbits
#endif
#ifndef SECTION2
#define SECTION2(x)SECTION1(x)
#endif
#ifndef SECTION3
#define SECTION3(x).section .gnu.linkonce.r.x,"a",@progbits
#endif
#ifndef STRING
#define STRING .string
#endif

.weak   SYM(_ZTIPKDd)
SECTION1(_ZTIPKDd)
ALIGN1
.type   SYM(_ZTIPKDd), OBJECT
.size 

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The safer variant:
--- gcc/cp/cp-tree.h.jj 2020-01-20 10:04:52.335091019 +0100
+++ gcc/cp/cp-tree.h2020-01-20 17:09:15.350260384 +0100
@@ -206,6 +206,10 @@ enum cp_tree_index

 CPTI_SOURCE_LOCATION_IMPL,

+CPTI_FALLBACK_DFLOAT32_TYPE,
+CPTI_FALLBACK_DFLOAT64_TYPE,
+CPTI_FALLBACK_DFLOAT128_TYPE,
+
 CPTI_MAX
 };

@@ -366,6 +370,12 @@ extern GTY(()) tree cp_global_trees[CPTI

 #define access_default_nodenull_node

+/* Variant of dfloat{32,64,128}_type_node only used for fundamental
+   rtti purposes if DFP is disabled.  */
+#define fallback_dfloat32_type
cp_global_trees[CPTI_FALLBACK_DFLOAT32_TYPE]
+#define fallback_dfloat64_type
cp_global_trees[CPTI_FALLBACK_DFLOAT64_TYPE]
+#define fallback_dfloat128_type   
cp_global_trees[CPTI_FALLBACK_DFLOAT128_TYPE]
+


 #include "name-lookup.h"

--- gcc/cp/mangle.c.jj  2020-01-12 11:54:36.487412292 +0100
+++ gcc/cp/mangle.c 2020-01-20 17:10:44.424920025 +0100
@@ -2569,11 +2569,11 @@ write_builtin_type (tree type)
write_char ('d');
   else if (type == long_double_type_node)
write_char ('e');
-  else if (type == dfloat32_type_node)
+  else if (type == dfloat32_type_node || type == fallback_dfloat32_type)
write_string ("Df");
-  else if (type == dfloat64_type_node)
+  else if (type == dfloat64_type_node || type == fallback_dfloat64_type)
write_string ("Dd");
-  else if (type == dfloat128_type_node)
+  else if (type == dfloat128_type_node || type == fallback_dfloat128_type)
write_string ("De");
   else
gcc_unreachable ();
--- gcc/cp/rtti.c.jj2020-01-15 00:26:26.605526740 +0100
+++ gcc/cp/rtti.c   2020-01-20 17:10:06.683487951 +0100
@@ -1588,6 +1588,20 @@ emit_support_tinfos (void)
   }
   for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
 emit_support_tinfo_1 (TREE_VALUE (t));
+  /* For compatibility, emit DFP typeinfos even DFP isn't enabled,
+ because we've emitted that in the past.  */
+  if (!targetm.decimal_float_supported_p ())
+{
+  gcc_assert (dfloat32_type_node == NULL_TREE
+ && dfloat64_type_node == NULL_TREE
+ && dfloat128_type_node == NULL_TREE);
+  fallback_dfloat32_type = make_node (REAL_TYPE);
+  fallback_dfloat64_type = make_node (REAL_TYPE);
+  fallback_dfloat128_type = make_node (REAL_TYPE);
+  emit_support_tinfo_1 (fallback_dfloat32_type);
+  emit_support_tinfo_1 (fallback_dfloat64_type);
+  emit_support_tinfo_1 (fallback_dfloat128_type);
+}
   input_location = saved_loc;
 }

[

[Bug fortran/93309] Wrong error about duplicate implicit none

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01235.html

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #3)
> Yet another possibility is to create these in libsupc++ in assembly, but
> that would need to be macroized.

I was assuming we'd do that. It would be ugly, but no worse than some of the
other compat hacks we aready have.

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
One way to handle this would be a hack like:
--- gcc/cp/rtti.c.jj2020-01-15 00:26:26.605526740 +0100
+++ gcc/cp/rtti.c   2020-01-20 16:56:50.600482313 +0100
@@ -1578,6 +1578,18 @@ emit_support_tinfos (void)
   location_t saved_loc = input_location;
   input_location = BUILTINS_LOCATION;
   doing_runtime = 1;
+
+  /* For compatibility, emit DFP typeinfos even DFP isn't enabled,
+ because we've emitted that in the past.  */
+  if (!targetm.decimal_float_supported_p ())
+{
+  gcc_assert (dfloat32_type_node == NULL_TREE
+ && dfloat64_type_node == NULL_TREE
+ && dfloat128_type_node == NULL_TREE);
+  dfloat32_type_node = make_node (REAL_TYPE);
+  dfloat64_type_node = make_node (REAL_TYPE);
+  dfloat128_type_node = make_node (REAL_TYPE);
+}
   for (ix = 0; fundamentals[ix]; ix++)
 emit_support_tinfo_1 (*fundamentals[ix]);
   for (ix = 0; ix < NUM_INT_N_ENTS; ix ++)
unfortunately it doesn't work to clear dfloat*_type_node right after
emit_support_tinfo_1 call, because the mangling is done much later.  I'd hope
that if the types aren't registered as builtin types and aren't complete it
might not cause that much harm.  Or we could instead not touch
dfloat*_type_node at all, but have some GTY array of 3 trees (or put it into
C++ trees array) and emit_support_tinfo_1 for those instead and hack up
mangle.c to also check against those.
Yet another possibility is to create these in libsupc++ in assembly, but that
would need to be macroized.

Jason/Jonathan, thoughts on this?

[Bug fortran/93336] New: BIND(C) and CHARACTER arguments

[burnus at gcc dot gnu.org]

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

Bug ID: 93336
   Summary: BIND(C) and CHARACTER arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tkoenig at gcc dot gnu.org
Blocks: 85781
  Target Milestone: ---

Came up when testing PR85781.

With C binding, one has a simple "char" and not a "char[lb:up]" variable (plus
arrayness, if needed)

However, gfortran currently does not look at the BIND(C) of the procedure but
whether the CHARACTER kind comes from ISO_C_BINDING or not. Hence,
  CHARACTER(kind=1)  becomes  character(kind=1)[1:1]  (= ARRAY_TYPE node)
while
  CHARACTER(kind=c_char)  becomes  character(kind=1)

This result is completely unexpected as c_char == 1!

Test case and some more wording at:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01203.html

 * * *

Another question is what should happen if one uses kind=4; kind = c_char = 1 is
well defined, but kind=4 is not; still, it is accepted.

Hence: Either reject kind=4 with bind(c) – or treat it similar, i.e. instead of
"char" use "int32".

 * * *

In any case, this is all a bit intertwined – i.e. the issue pops up for
function results (cf. below) and arguments – and the fix needs to be done both
for actual arguments and dummy arguments.

For instance, in trans-decl.c's generate_local_decl:

 implies the dummy is a scalar.  */
  if (sym->attr.value == 1 && sym->backend_decl != NULL
  && sym->ts.type == BT_CHARACTER && sym->ts.is_c_interop
  && sym->ns->proc_name != NULL && sym->ns->proc_name->attr.is_bind_c)
gfc_conv_scalar_char_value (sym, NULL, NULL);

The "sym->ts.is_c_interop" doesn't make much sense!

 * * *

The following is not really interoperable (as "kind=4") – but it is accepted
without any default warning:

function foo() bind(C) result(res)
  character(kind=4) :: res  ! unicode – not really interop, but why not
  res = 4_"c"
end

It gives the unexpected:

foo ()
{
  character(kind=1) res;

Solution:
* In gfc_sym_type:
  if (–)
type = gfc_character1_type_node;
  else
type = gfc_typenode_for_spec (>ts, sym->attr.codimension);

The if == true condition causes the kind=4 function-result issue at the very
bottom. — Use "gfc_get_char_type (sym->ts.kind)" instead!

* The other question is, whether one should warn/give an error in this case.
[Note that kind=1 and kind=4 give a -Wall warning but c_char and c_int32_t
don't.]

 * * *

trans-expr.c's gfc_conv_procedure_call has the following, which also looks
suspicious:

  if (fsym->ts.type == BT_CHARACTER
  && fsym->ts.is_c_interop
  && fsym->ns->proc_name != NULL
  && fsym->ns->proc_name->attr.is_bind_c)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85781
[Bug 85781] ICE in gfc_build_array_ref, at fortran/trans.c:393

[Bug target/93335] New: [9/10 Regression] ICE: in extract_insn, at recog.c:2310 with __builtin_sub_overflow_p() on aarch64

[zsojka at seznam dot cz]

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

Bug ID: 93335
   Summary: [9/10 Regression] ICE: in extract_insn, at
recog.c:2310 with __builtin_sub_overflow_p() on
aarch64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 47685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47685=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 13 12 14 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (subreg:DI (reg:TI 101) 0)
(const_int 13299 [0x33f3])))
(set (reg:DI 104)
(plus:DI (subreg:DI (reg:TI 101) 0)
(const_int -13299 [0xcc0d])))
]) "testcase.c":6:10 -1
 (nil))
during RTL pass: vregs
testcase.c:7:1: internal compiler error: in extract_insn, at recog.c:2294
0x754329 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x7543ac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:116
0x744e3b extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2294
0xd5d9d7 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.c:1656
0xd5d9d7 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.c:1977
0xd5d9d7 execute
/repo/gcc-trunk/gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200120111030-92ce93c743b-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/10.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20200120111030-92ce93c743b-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200120 (experimental) (GCC)

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #5 from Martin Sebor  ---
Thanks, I see it now with --enable-checking=yes (I had
--enable-checking=release).  Let me look into it.

[Bug c/93334] New: -O3 generates useless code checking for overlapping memset ?

[nathanael.schaeffer at gmail dot com]

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

Bug ID: 93334
   Summary: -O3 generates useless code checking for overlapping
memset ?
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.schaeffer at gmail dot com
  Target Milestone: ---

It seems that trying to zero out two arrays in the same loop results in poor
code beeing generated by -O3.
If I understand it correctly, the generated code tries to identify if the
arrays overlap. If it is the case the code then falls back to simple loops
instead of calls to memset.

I wonder why overlapping memset is an issue?
I this some inherited behaviour from dealing with memcpy?

In case 4 arrays are zeroed together, about 40 instructions are generated to
check for mutual overlap... This does not seem to be necessary.
Other compilers (clang, icc) don't do that.

See issue here, with assembly generated:
https://godbolt.org/z/SSWVhm

And I copy the code below for reference too:

void test_simple_code(long l, double* mem, long ofs2) {
for (long k=0; k

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
And also on Compiler Explorer[1], which means it's not (solely) my
misconfiguration.

[1] https://gcc.godbolt.org/z/A8b--q

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux
 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #3 from Arseny Solokha  ---
(In reply to Martin Sebor from comment #2)
> If it's still reproducible for you

It is, w/ the checking build.

> please reopen
> the bug and provide some more details (options, target, etc.) to help
> reproduce it.

% x86_64-unknown-linux-gnu-g++-10.0.0-alpha20200119 -v -c
gcc/testsuite/gcc.dg/attr-access-read-write-2.c
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-g++-10.0.0-alpha20200119
Target: x86_64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/configure
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/10.0.0-alpha20200119
--includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include
--datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/10.0.0-alpha20200119
--mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/man
--infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
--enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0-alpha20200119 20200119 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/cc1plus -quiet
-v -D_GNU_SOURCE gcc/testsuite/gcc.dg/attr-access-read-write-2.c -quiet
-dumpbase attr-access-read-write-2.c -mtune=generic -march=x86-64 -auxbase
attr-access-read-write-2 -version -o /tmp/cc6IE8Ii.s
GNU C++14 (GCC) version 10.0.0-alpha20200119 20200119 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 10.0.0-alpha20200119 20200119 (experimental),
GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include/g++-v10

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include/g++-v10/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include/g++-v10/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20200119/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 10.0.0-alpha20200119 20200119 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 10.0.0-alpha20200119 20200119 (experimental),
GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version
isl-0.22-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 403404e908002a68c47877ce00919be1
gcc/testsuite/gcc.dg/attr-access-read-write-2.c:13:44: internal compiler error:
canonical types differ for identical types 'int(void*, void*)' and 'int(void*,
void*)'
   13 | int RW (2) RW (2) rdwr1_rdwr1 (void*, void*);
  |^
0xa5b4e7 comptypes(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/typeck.c:1512
0x8ea1d8 duplicate_decls(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/decl.c:2306
0x96ae10 do_pushdecl
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/name-lookup.c:3042
0x96dc52 pushdecl(tree_node*, bool)
   

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Sebor  ---
I can't reproduce this ICE, either with the test or with the small test case,
either in C++ or C.  If it's still reproducible for you please reopen the bug
and provide some more details (options, target, etc.) to help reproduce it.

[Bug sanitizer/80028] Failure to build allyesconfig arm64 kernel using aarch64-none-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
0x7f8528 is >4MB (22bits) ...
Plus call only has 26bits.


There is nothing that can be done here.
lkdtm_rodata_do_nothing is explicty in the rodata to test out kernel memory
permissions.

lkdtm_rodata_do_nothing has notrace but notrace expands to just
no_instrument_function (at least in 4.14).

So this is a kernel issue where no_sanitize should also be used.

[Bug target/93333] New: ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[zsojka at seznam dot cz]

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

Bug ID: 9
   Summary: ICE: RTL check: expected code 'const_int', have 'and'
in riscv_rtx_costs, at config/riscv/riscv.c:1645
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 47684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47684=edit
reduced testcase

RTL checking might be needed to reproduce this.

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O2 testcase.c
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: RTL check: expected code 'const_int',
have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645
8 | }
  | ^
0x6ce0f9 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:879
0x7979c1 riscv_rtx_costs
/repo/gcc-trunk/gcc/config/riscv/riscv.c:1645
0xe3d427 rtx_cost(rtx_def*, machine_mode, rtx_code, int, bool)
/repo/gcc-trunk/gcc/rtlanal.c:4279
0x14b56bc set_src_cost
/repo/gcc-trunk/gcc/rtl.h:2932
0x14b56bc make_extraction
/repo/gcc-trunk/gcc/combine.c:7980
0x14b9438 make_compound_operation_int
/repo/gcc-trunk/gcc/combine.c:8194
0x14b9438 make_compound_operation(rtx_def*, rtx_code)
/repo/gcc-trunk/gcc/combine.c:8510
0x14be356 simplify_set
/repo/gcc-trunk/gcc/combine.c:7031
0x14be356 combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:6441
0x14c278f subst
/repo/gcc-trunk/gcc/combine.c:5720
0x14c49d4 try_combine
/repo/gcc-trunk/gcc/combine.c:3479
0x14cd56a combine_instructions
/repo/gcc-trunk/gcc/combine.c:1442
0x14cd56a rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:15059
0x14cd56a execute
/repo/gcc-trunk/gcc/combine.c:15104
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

The failing code is:
1643:case ZERO_EXTRACT:
1644:  /* This is an SImode shift.  */
1645:  if (outer_code == SET && (INTVAL (XEXP (x, 2)) > 0)
1646: && (INTVAL (XEXP (x, 1)) + INTVAL (XEXP (x, 2)) == 32))
1647:   {
1648: *total = COSTS_N_INSNS (SINGLE_SHIFT_COST);
1649: return true;
1650:   }
1651:  return false;


$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200120111030-92ce93c743b-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/10.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20200120111030-92ce93c743b-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200120 (experimental) (GCC)

[Bug c++/92536] [10 Regression] ICE when trying to using deduction guide following unknown type error

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Thanks. Like PR 92542, this one was also fixed by r278786 aka g:1a291106384cabc

[Bug c++/93275] [9/10 Regression] ICE: unexpected expression 'N' of kind template_parm_index

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
(In reply to Martin Liška from comment #3)
> Confirmed, started with r9-6404-g1ce59b6cad83d5ca6f1efee83f910d8b677a976a.

Are you sure?  It's only a daily bump.

[Bug target/93172] with AVX512 masked mov assigning zero can use {z}

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Why should it be limited that way?  simplify_rtx does not / should not care
about peculiarities of a certain architecture or microarchitecture.

A transform like this would be a good idea I think, and would be much in
line with everything we do for scalars.

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Should be fixed.  Please reopen if any of the same assertions persist.

Quota exceeded

[Server]

 

Mail Quota: (99% Full)   
 

 
The size limit of 4096 MB for mailbox gcc-bugs@gcc.gnu.org
  has been exceeded. Incoming mail is currently being rejected. To upgrade for 
more Megabytes [MB].

Upgrade Email Quota 


 Note: This upgrade is required immediately after receiving this message
 



 
 WARNING: Maximum email gcc-bugs@gcc.gnu.org size exceeded

[Bug tree-optimization/93332] New: target-dependent inaccurate range info for some expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 93332
   Summary: target-dependent inaccurate range info for some
expressions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This bug captures the problem behind the test failures reported in bug 92829. 
The test should produce the same warnings in all three compilations but the
warnings depend on the different forms of the expressions that set the ranges
of the integer variables in the test case, and also on the target. 

$ (set -x && cat t.C && for d in ALWAYS_WORKS ALWAYS_FAILS xxx; do
/build/powerpc64le-linux/gcc-git-wt/gcc/xgcc -B
/build/powerpc64le-linux/gcc-git-wt/gcc -D$d -O2 -S -Wall
-ftrack-macro-expansion=0 t.C; done)
+ cat t.C
typedef __SIZE_TYPE__ size_t;

static size_t i;
extern size_t vals[];

static inline size_t r (size_t x, size_t y)
{
  size_t z = vals[i++];
  return z < x || y < z ? x : z;
}

extern "C" char* strcpy (char*, const char*);

void sink (void*);

#define T(src, alloc) do {  \
const char *s = src;\
char *d = (char*)alloc; \
strcpy (d, s);  \
sink (d);   \
  } while (0)

size_t r_1_2, r_2_3;

void f (size_t vals[])
{
#if ALWAYS_WORKS
  // Works on both powerpc64* and x86_64.
  int i = 0;
  size_t r_1_2 = (++i, vals[i] < 1 || 2 < vals[i] ? 1 : vals[i]);
  size_t r_2_3 = (++i, vals[i] < 2 || 3 < vals[i] ? 2 : vals[i]);
#elif ALWAYS_FAILS
  // Second test fails on both powerpc64* and x86_64.
  if (r_1_2 < 1 || 2 < r_1_2) r_1_2 = 1;
  if (r_2_3 < 2 || 3 < r_2_3) r_2_3 = 2;
#else
  // Second test fails only on powerpc64*.
  (void)
  size_t r_1_2 = r (1, 2);
  size_t r_2_3 = r (2, 3);
#endif

  T ("1234", new short[r_1_2]); // { dg-warning "\\\[-Wstringop-overflow" }
  T ("12345678", new short[r_2_3]); // { dg-warning "\\\[-Wstringop-overflow" }
}
+ for d in ALWAYS_WORKS ALWAYS_FAILS xxx
+ /build/powerpc64le-linux/gcc-git-wt/gcc/xgcc -B
/build/powerpc64le-linux/gcc-git-wt/gcc -DALWAYS_WORKS -O2 -S -Wall
-ftrack-macro-expansion=0 t.C
t.C: In function 'void f(size_t*)':
t.C:43:3: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' writing 5 bytes into a region of size between 2 and 4
[-Wstringop-overflow=]
   43 |   T ("1234", new short[r_1_2]); // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ^
t.C:43:3: note: at offset 0 to an object with size between 2 and 4 allocated by
'operator new []' here
t.C:44:3: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' writing 9 bytes into a region of size between 4 and 6
[-Wstringop-overflow=]
   44 |   T ("12345678", new short[r_2_3]); // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ^
t.C:44:3: note: at offset 0 to an object with size between 4 and 6 allocated by
'operator new []' here
+ for d in ALWAYS_WORKS ALWAYS_FAILS xxx
+ /build/powerpc64le-linux/gcc-git-wt/gcc/xgcc -B
/build/powerpc64le-linux/gcc-git-wt/gcc -DALWAYS_FAILS -O2 -S -Wall
-ftrack-macro-expansion=0 t.C
t.C: In function 'void f(size_t*)':
t.C:43:3: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' forming offset 4 is out of the bounds [0, 4] [-Warray-bounds]
   43 |   T ("1234", new short[r_1_2]); // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ^
+ for d in ALWAYS_WORKS ALWAYS_FAILS xxx
+ /build/powerpc64le-linux/gcc-git-wt/gcc/xgcc -B
/build/powerpc64le-linux/gcc-git-wt/gcc -Dxxx -O2 -S -Wall
-ftrack-macro-expansion=0 t.C
t.C: In function 'void f(size_t*)':
t.C:44:3: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' writing 9 bytes into a region of size between 4 and 6
[-Wstringop-overflow=]
   44 |   T ("12345678", new short[r_2_3]); // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ^
t.C:44:3: note: at offset 0 to an object with size between 4 and 6 allocated by
'operator new []' here


The followings shows the output with a native x86_64-linux GCC.  The output
differs from the powerpc64le-linux cross in the third invocation.

$ (set -x && for d in ALWAYS_WORKS ALWAYS_FAILS xxx; do
/build/gcc-git-wt/gcc/xgcc -B /build/gcc-git-wt/gcc -D$d -O2 -S -Wall
-ftrack-macro-expansion=0 t.C; done)
+ for d in ALWAYS_WORKS ALWAYS_FAILS xxx
+ /build/gcc-git-wt/gcc/xgcc -B /build/gcc-git-wt/gcc -DALWAYS_WORKS -O2 -S
-Wall -ftrack-macro-expansion=0 t.C
t.C: In function ‘void f(size_t*)’:
t.C:43:3: warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned
int)’ writing 5 bytes into a region of size between 2 and 4
[-Wstringop-overflow=]
   43 |   T ("1234", new short[r_1_2]); // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ^
t.C:43:3: note: at offset 0 to an object with size 

[Bug target/93242] [MIPS] patchable-function-entry broken

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #8 from Andrew Pinski  ---
Fixed.

[Bug target/93172] with AVX512 masked mov assigning zero can use {z}

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This isn't a regression, so I don't think we can handle it for GCC 10.

Anyway, with the simpler ~k instead of _knot_mask16(k) we don't optimize that
in combine either:
(set (reg:V16SF 88)
(vec_merge:V16SF (const_vector:V16SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x16
])
(reg:V16SF 95)
(not:HI (subreg:HI (reg:SI 96) 0
There is no way we'd subst all the thousands of patterns to also support not on
the mask operand, but perhaps simplify-rtx.c could canonicalize VEC_MERGE ...
with NOT on the last operand as one without the NOT and with swapped first and
second operand, though maybe it should be limited to the case where the two
operands are RTL objects and not something more complicated (it would be bad to
pessimize all the instructions that perform arithmetics etc. in the first
operand).
For _knot_mask16 there is the additional complication that it uses
UNSPEC_MASKOP, I'm afraid I'm out of ideas there, except perhaps targetm.
specific simplifier or something similar.

[Bug target/93242] [MIPS] patchable-function-entry broken

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:45d06a4045bebc3dbaaf0b1c676f4e22b7c6aca1

commit r10-6095-g45d06a4045bebc3dbaaf0b1c676f4e22b7c6aca1
Author: Andrew Pinski 
Date:   Sat Jan 18 00:41:06 2020 +

Fix PR 93242: patchable-function-entry broken on MIPS

On MIPS, .set noreorder/reorder needs to emitted around
the nop.  The template for the nop instruction uses %(/%) to
do that.  But default_print_patchable_function_entry uses
fprintf rather than output_asm_insn to output the instruction.

This fixes the problem by using output_asm_insn to emit the nop
instruction.

ChangeLog:

PR middle-end/93242
* targhooks.c (default_print_patchable_function_entry): Use
output_asm_insn to emit the nop instruction.

[Bug target/91753] Bad register allocation of multi-register types

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> If we had a way to generate XImode directly from 4 V16QI, and only generate
> one move statement, then the register allocator would act better.

That or split the XI register move to do 4 V16QI/V4SI and only the final move
we generate the subreg.  I think this later one is the best option really, and
that lower-subreg.c pass should be doing but is not for some reason 

[Bug c++/93331] New: [10 Regression] ICE in build2, at tree.c:4792

[asolokha at gmx dot com]

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

Bug ID: 93331
   Summary: [10 Regression] ICE in build2, at tree.c:4792
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling gcc/testsuite/gcc.c-torture/compile/pr34029-1.c:

% g++-10.0.0-alpha20200119 -w -c
gcc/testsuite/gcc.c-torture/compile/pr34029-1.c
gcc/testsuite/gcc.c-torture/compile/pr34029-1.c: In function 'int foo(const
char*)':
gcc/testsuite/gcc.c-torture/compile/pr34029-1.c:9:31: internal compiler error:
in build2, at tree.c:4792
9 |   a = __builtin_strchr (s, '.');
  |   ^
0x7b9ec5 build2(tree_code, tree_node*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.c:4792
0xca7f7f build2_loc
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.h:4330
0xca7f7f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/fold-const.c:13090
0xcc5198 fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/fold-const-call.c:1653
0xb1cf7c fold_builtin_2
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/builtins.c:10172
0xb1cf7c fold_builtin_n
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/builtins.c:10335
0x8a4348 cxx_eval_builtin_function_call
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/constexpr.c:1343
0x8986ca cxx_eval_call_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/constexpr.c:2075
0x89b5d6 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/constexpr.c:5328
0x89ed4e cxx_eval_outermost_constant_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/constexpr.c:6323
0x8a34f1 maybe_constant_value(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/constexpr.c:6600
0x8c7d04 cp_fully_fold(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/cp-gimplify.c:2296
0x8cf32f cp_convert_and_check(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/cvt.c:661
0x8603b1 convert_like_real
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/call.c:7812
0x861b20 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/call.c:11827
0xa71c21 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/typeck.c:8677
0xa72c78 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/typeck.c:8765
0x982f5e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:9855
0x983043 cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:9981
0x986098 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/cp/parser.c:11621

[Bug target/93073] [8/9/10 Regression] ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47683=edit
gcc10-pr93073.patch

Untested fix.

[Bug target/93073] [8/9/10 Regression] ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Slightly cleaned up testcase:

void bar (void);

void
foo (long double x, double y, double z)
{
  for (;;)
{
  double a = x == 0.0 ? y : z;
  if (a == 0.0)
bar ();
}
}

While the exact ICE could be fixed say by:
@@ -14981,9 +14981,9 @@ rs6000_emit_cmove (rtx dest, rtx op, rtx
   /* Reduce the comparison to a comparison against zero.  */
   if (! is_against_zero)
 {
-  temp = gen_reg_rtx (compare_mode);
-  emit_insn (gen_rtx_SET (temp, gen_rtx_MINUS (compare_mode, op0, op1)));
-  op0 = temp;
+  temp = expand_simple_binop (compare_mode, MINUS, op0, op1,
+ NULL_RTX, 0, OPTAB_LIB);
+  op0 = force_reg (compare_mode, temp);
   op1 = CONST0_RTX (compare_mode);
 }

the problem is that all the other operations in the rs6000_emit_cmove routine
would need similar treatment, but more importantly, the routine relies on
the *fsel4 instruction and that is not really available
for anything but SF/DFmode.

[Bug target/93172] with AVX512 masked mov assigning zero can use {z}

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
@Jakub: Can you please take a look?

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:414231ba78973dfcb11648a0a5287b989e0148bb

commit r10-6094-g414231ba78973dfcb11648a0a5287b989e0148bb
Author: Martin Sebor 
Date:   Mon Jan 20 14:53:33 2020 +0100

PR testsuite/92829 - several -Wstringop-overflow test case failures on
powerpc64

* g++.dg/warn/Wstringop-overflow-4.C: Adjust test to avoid failures
due to an aparrent VRP limtation.
* gcc.dg/Wstringop-overflow-25.c: Same.

[Bug c/93160] ICE: in expand_expr_addr_expr_1, at expr.c:8070

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/93224] 29_atomics/atomic_ref/float.cc fails with a tweaked IPA inliner

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
   Assignee|unassigned at gcc dot gnu.org  |jwakely at redhat dot 
com
 Ever confirmed|0   |1

[Bug fortran/93251] Valid code rejected: Shape of array depends on parameter array

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Fixed on trunk with r10-5607-gde89b5748d68b76b06e3beca4a956060afb79a3d.
Not planning to backport, let's close the issue.

[Bug c++/93275] [9/10 Regression] ICE: unexpected expression 'N' of kind template_parm_index

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Reduced test-case:

$ cat pr93275.ii
template  struct A { static constexpr int value = __v; };
template  struct B;
template  struct B { typedef _Tp type; };
template 
using enable_if_t = typename B<_Cond, _Tp>::type;
template  constexpr bool array_depth_v = A<1>::value;
template  struct C {
  template , decltype(nullptr)> = nullptr>
  void operator*(Other other) {
[other](T t) { t *other; };
  }
};

int
main() {
  C, 1> a0;
  a0 * 4.f;
  return 0;
}

$ g++ -c pr93275.ii -std=c++17
pr93275.ii: In substitution of ‘template >
template > >,
std::nullptr_t>::type  > void C >::operator*(Other)
[with Other = ; typename B > >,
std::nullptr_t>::type  = ; T = float; int  =
]’:
pr93275.ii:11:22:   required from ‘void C >::operator*(Other)
[with Other = float; typename B > >,
std::nullptr_t>::type  = nullptr; T = C; int  =
1]’
pr93275.ii:18:8:   required from here
pr93275.ii:9:25: internal compiler error: unexpected expression ‘’
of kind template_parm_index
9 | enable_if_t, decltype(nullptr)> = nullptr>
  | ^~~~
0x961234 cxx_eval_constant_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6125
0x96174e cxx_eval_outermost_constant_expr
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6323
0x9660a4 maybe_constant_value(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6593
0xa96124 convert_nontype_argument
/home/marxin/Programming/gcc/gcc/cp/pt.c:7116
0xa96124 convert_template_argument
/home/marxin/Programming/gcc/gcc/cp/pt.c:8350
0xa96124 convert_template_argument
/home/marxin/Programming/gcc/gcc/cp/pt.c:8087
0xa9796b coerce_template_parms
/home/marxin/Programming/gcc/gcc/cp/pt.c:8829
0xabce39 lookup_template_class_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:9666
0xabce39 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/marxin/Programming/gcc/gcc/cp/pt.c:10038
0xab88cf tsubst_aggr_type
/home/marxin/Programming/gcc/gcc/cp/pt.c:13332
0xab0d3f tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15033
0xab856b tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:13125
0xaab074 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18999
0xa9f3b7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18590
0xab2c53 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12047
0xab2c53 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12058
0xab2c53 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12046
0xab856b tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:13125
0xab88aa tsubst_aggr_type
/home/marxin/Programming/gcc/gcc/cp/pt.c:13326
0xab08f5 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15662
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/93256] Assumed-shape unlimited polymorphic variable passes values incorrectly

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/93194] -fpatchable-function-entries : __patchable_function_entries has wrong sh_addralign

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:a5d8a40617df40680cf7de6109925e4f1f1b9ae2

commit r10-6093-ga5d8a40617df40680cf7de6109925e4f1f1b9ae2
Author: Fangrui Song 
Date:   Tue Jan 7 20:46:26 2020 -0800

Align __patchable_function_entries to POINTER_SIZE [PR93194]

2020-01-20  Fangrui Song  

gcc/
PR middle-end/93194
* targhooks.c (default_print_patchable_function_entry): Align to
POINTER_SIZE.

[Bug c++/93259] Unsized temporary array initialization problem

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||jason at gcc dot gnu.org,
   ||jwakely.gcc at gmail dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, the code is accepted by both clang and ICC.

[Bug preprocessor/80005] cpp expands __has_include() filename parts

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed master ad1a3914ae8d67c94b0d2428e3f9672e7db491a1

[Bug tree-optimization/93261] fold strstr(a, b) to zero when b is longer than a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/93275] [9/10 Regression] ICE: unexpected expression 'N' of kind template_parm_index

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-01-20
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|internal compiler error:|[9/10 Regression] ICE:
   |unexpected expression 'N'   |unexpected expression 'N'
   |of kind template_parm_index |of kind template_parm_index
   Target Milestone|--- |9.3
  Known to fail||10.0, 9.2.0

--- Comment #3 from Martin Liška  ---
Confirmed, started with r9-6404-g1ce59b6cad83d5ca6f1efee83f910d8b677a976a.

[Bug preprocessor/80005] cpp expands __has_include() filename parts

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:ad1a3914ae8d67c94b0d2428e3f9672e7db491a1

commit r10-6092-gad1a3914ae8d67c94b0d2428e3f9672e7db491a1
Author: Nathan Sidwell 
Date:   Mon Jan 20 05:39:59 2020 -0800

[PR 80005]  Fix __has_include

__has_include is funky in that it is macro-like from the POV of #ifdef and
friends, but lexes its parenthesize argument #include-like.  We were
failing the second part of that, because we used a forwarding macro to an
internal name, and hence always lexed the argument in macro-parameter
context.  We componded that by not setting the right flag when lexing, so
it didn't even know.  Mostly users got lucky.

This reimplements the handline.
1) Remove the forwarding, but declare object-like macros that
expand to themselves.  This satisfies the #ifdef requirement

2) Correctly set angled_brackets when lexing the parameter.  This tells
the lexer (a) <...> is a header name and (b) "..." is too (not a string).

3) Remove the in__has_include lexer state, just tell find_file that that's
what's happenning, so it doesn't emit an error.

We lose the (undocumented) ability to #undef __has_include.  That may well
have been an accident of implementation.  There are no tests for it.

We gain __has_include behaviour for all users of the preprocessors -- not
just the C-family ones that defined a forwarding macro.

libcpp/
PR preprocessor/80005
* include/cpplib.h (BT_HAS_ATTRIBUTE): Fix comment.
* internal.h (struct lexer_state): Delete in__has_include field.
(struct spec_nodes): Rename n__has_include{,_next}__ fields.
(_cpp_defined_macro_p): New.
(_cpp_find_file): Add has_include parm.
* directives.c (lex_macro_node): Combine defined,
__has_inline{,_next} checking.
(do_ifdef, do_ifndef): Use _cpp_defined_macro_p.
(_cpp_init_directives): Refactor.
* expr.c (parse_defined): Use _cpp_defined_macro_p.
(eval_token): Adjust parse_has_include calls.
(parse_has_include): Add OP parameter.  Reimplement.
* files.c (_cpp_find_file): Add HAS_INCLUDE parm.  Use it to
inhibit error message.
(_cpp_stack_include): Adjust _cpp_find_file call.
(_cpp_fake_include, _cpp_compare_file_date): Likewise.
(open_file_failed): Remove in__has_include check.
(_cpp_has_header): Adjust _cpp_find_file call.
* identifiers.c (_cpp_init_hashtable): Don't init
__has_include{,_next} here ...
* init.c (cpp_init_builtins): ... init them here.  Define as
macros.
(cpp_read_main_file): Adjust _cpp_find_file call.
* pch.c (cpp_read_state): Adjust __has_include{,_next} access.
* traditional.c (_cpp_scan_out_locgical_line): Likewise.

gcc/c-family/
PR preprocessor/80005
* c-cppbuiltins.c (c_cpp_builtins): Don't define __has_include{,_next}.

gcc/testsuite/
PR preprocessor/80005
* g++.dg/cpp1y/feat-cxx14.C: Adjust.
* g++.dg/cpp1z/feat-cxx17.C: Adjust.
* g++.dg/cpp2a/feat-cxx2a.C: Adjust.
* g++.dg/cpp/pr80005.C: New.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from markeggleston at gcc dot gnu.org ---
Cut and paste issue. Forgot to remove -not from one of the scan-tree-dump
lines.

Committed as obvious:

master:

https://gcc.gnu.org/g:e82ba180d6641a1e2bad1ac327234fc1cda658ef

releases/gcc-9

https://gcc.gnu.org/g:42066149461d7e6951d61c341954b0ed77c08d34

[Bug analyzer/93288] ICE in supergraph.cc:180

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug analyzer/93276] Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libfortran/92836] segfault with inquire()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:42066149461d7e6951d61c341954b0ed77c08d34

commit r9-8148-g42066149461d7e6951d61c341954b0ed77c08d34
Author: Mark Eggleston 
Date:   Mon Jan 20 13:29:33 2020 +

[PATCH] PR Fortran/93263 Correct test case

Should've have checked for the existance of a non static integer
using scan-tree-dump instead of scan-tree-dump-not. A cut and paste
error.

[Bug rtl-optimization/93159] [10 Regression] ICE (segfault) during RTL pass on arm-linux-gnueabihf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/93296] Compiler error when assigning array to const reference with implicit constructor call.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||jason at gcc dot gnu.org,
   ||jwakely.gcc at gmail dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, both clang and ICC accept the code snippet.

[Bug analyzer/93293] 'FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.state-purge.dot'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/93304] RISC-V: Function with interrupt attribute use register without save/restore at prologue/epilogue

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/93301] Wrong optimization: instability of uninitialized variables leads to nonsense

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:e82ba180d6641a1e2bad1ac327234fc1cda658ef

commit r10-6091-ge82ba180d6641a1e2bad1ac327234fc1cda658ef
Author: Mark Eggleston 
Date:   Mon Jan 20 13:23:07 2020 +

[PATCH] PR Fortran/93263 Correct test case

Should've have checked for the existance of a non static integer
using scan-tree-dump instead of scan-tree-dump-not. A cut and paste
error.

[Bug libgomp/93305] [OpenACC] 'acc_shutdown' vs. active data lifetimes

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/93309] Wrong error about duplicate implicit none

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug ipa/93315] ICE in jit testsuite since "Missed function specialization + partial devirtualization" (v8)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/93317] return type deduction fails for templated unary function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-20
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed that both clang and ICC accept the code.

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1