[Bug c/102763] New: ICE on gimple code: segmentation fault, build_component_ref

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 102763
   Summary: ICE on gimple code: segmentation fault,
build_component_ref
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
__GIMPLE
foo() { get_current()->flags; }

$ gcc-trunk -w -fgimple mutant.c
mutant.c: In function ‘foo’:
mutant.c:2:1: internal compiler error: Segmentation fault
2 | foo() { get_current()->flags; }
  | ^~~
0xf8c8d3 crash_signal
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/toplev.c:326
0x967665 build_component_ref(unsigned int, tree_node*, tree_node*, unsigned
int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-typeck.c:2466
0x9c27bf c_parser_gimple_postfix_expression_after_primary
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:1838
0x9c27bf c_parser_gimple_postfix_expression
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:1716
0x9c3b13 c_parser_gimple_unary_expression
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:1203
0x9c44f1 c_parser_gimple_statement
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:710
0x9c5273 c_parser_gimple_compound_statement
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:650
0x9c5273 c_parser_gimple_compound_statement
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:381
0x9c6f47 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/gimple-parser.c:253
0x9b48c8 c_parser_declaration_or_fndef
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:2539
0x9bd933 c_parser_external_declaration
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:1780
0x9be39b c_parser_translation_unit
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:1653
0x9be39b c_parse_file()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:23222
0xa20db5 c_common_parse_file()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c-family/c-opts.c:1237
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.

[Bug ipa/102762] [10/11/12 Regression] ICE with -O2: Segmentation fault, memcpy, copy_bb

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||9.4.0
   Target Milestone|--- |10.4
Summary|ICE with -O2: Segmentation  |[10/11/12 Regression] ICE
   |fault, memcpy, copy_bb  |with -O2: Segmentation
   ||fault, memcpy, copy_bb
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-15
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed, this is invalid code since there is no varargs and foo is never
inlined.

[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Last reconfirmed||2021-10-15
 Status|UNCONFIRMED |NEW
Summary|ICE with -O1 and above: in  |[10/11/12 Regression] ICE
   |ix86_print_operand_address_ |with -O1 and above: in
   |as, at  |ix86_print_operand_address_
   |config/i386/i386.c:13720|as due to %a0 and
   ||if_then_else and X
   ||constraint
  Known to work||9.1.0, 9.4.0
   Target Milestone|--- |10.4
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(insn 16 30 20 2 (parallel [
(asm_operands/v ("%a0") ("") 0 [
(if_then_else:SI (ne:SI (reg:SI 0 ax [86])
(const_int 0 [0]))
(const_int 2 [0x2])
(const_int 1 [0x1]))
]
 [
(asm_input:SI ("X") /app/example.cpp:1)
]
 [] /app/example.cpp:1)
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":1:7 -1
 (expr_list:REG_DEAD (reg:SI 0 ax [86])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor
   Keywords||ice-checking
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
There is a types which are not the same issue.

(gdb) p debug_tree(*expr_p)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7725f5e8 precision:32 min  max

pointer_to_this >
side-effects
arg:0 

def_stmt _2 = _1 & -128;
version:2>
arg:1 

arg:0 

def_stmt _1 = *type;
version:1>
arg:1 >
t.c:3:18 start: t.c:3:18 finish: t.c:3:31>

This shows up in GCC 11 (with checking enabled).

[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #9 from Sam James  ---
Confirmed that the GCC 11 branch backport works here. Thanks all!

[Bug c/102762] New: ICE with -O2: Segmentation fault, memcpy, copy_bb

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 102762
   Summary: ICE with -O2: Segmentation fault, memcpy, copy_bb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
foo(a, b) {
  log_bad_request(0, __builtin_va_arg_pack());
  foo(0);
}

$ gcc-trunk -w -O2 mutant.c
during IPA pass: inline
mutant.c: In function ‘foo’:
mutant.c:3:3: internal compiler error: Segmentation fault
3 |   foo(0);
  |   ^~
0xf8c8d3 crash_signal
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/toplev.c:326
0x101972c memcpy
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
0x101972c copy_bb
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:2130
0x101aac2 copy_cfg_body
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:3070
0x101aac2 copy_body
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:3323
0x101dc06 expand_call_inline
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:5108
0x101f591 gimple_expand_calls_inline
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:5303
0x101f591 optimize_inline_calls(tree_node*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree-inline.c:5476
0xd2eddb inline_transform(cgraph_node*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/ipa-inline-transform.c:790
0xe93b34 execute_one_ipa_transform_pass
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/passes.c:2290
0xe93b34 execute_all_ipa_transforms(bool)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/passes.c:2337
0xae3d29 cgraph_node::expand()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:1821
0xae514f expand_all_functions
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:1992
0xae514f symbol_table::compile()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:2356
0xae802b symbol_table::compile()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xae802b symbol_table::finalize_compilation_unit()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:2537
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.

[Bug rtl-optimization/15792] missed subreg optimization

[gabravier at gmail dot com via Gcc-bugs]

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

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #11 from Gabriel Ravier  ---
Seems like the issue is present again, except it's test1 that gets the better
asm now. Perhaps this should be re-opened ?

[Bug c/102761] New: ICE with -O1 and above: in ix86_print_operand_address_as, at config/i386/i386.c:13720

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 102761
   Summary: ICE with -O1 and above: in
ix86_print_operand_address_as, at
config/i386/i386.c:13720
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
f() { asm("%a0" : : "X"(tag() ? 2 : 1)); }

$ gcc-trunk -w -O1 mutant.c
during RTL pass: final
mutant.c: In function ‘f’:
mutant.c:1:42: internal compiler error: in ix86_print_operand_address_as, at
config/i386/i386.c:13720
1 | f() { asm("%a0" : : "X"(tag() ? 2 : 1)); }
  |  ^
0x83f47a ix86_print_operand_address_as
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/config/i386/i386.c:13720
0xbe46e7 output_address(machine_mode, rtx_def*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:3693
0xbe532e output_asm_insn(char const*, rtx_def**)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:3550
0xbe7612 final_scan_insn_1
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:2690
0xbe789f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:2940
0xbe7b67 final_1
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:1997
0xbe8598 rest_of_handle_final
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:4285
0xbe8598 execute
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/final.c:4363
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.

[Bug ipa/102759] [12 Regression] ICE: Segmentation fault in maybe_check_access_sizes

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
  Component|c   |ipa
Summary|ICE: Segmentation fault,|[12 Regression] ICE:
   |contains_struct_check(tree_ |Segmentation fault in
   |node*,  |maybe_check_access_sizes
   |tree_node_structure_enum,   |
   |char const*, int, char  |
   |const*),|
   |maybe_check_access_sizes|
   Last reconfirmed||2021-10-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
This code is wildly undefined 

Confirmed, doubt it is a dup because GCC 11.2.0 does not ICE.

[Bug c++/102642] [11/12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||cnsun at uwaterloo dot ca

--- Comment #4 from Chengnian Sun  ---
The following might be a duplicate.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
static a __attribute__((weakref("")));
static b __attribute__((weakref("")));
static b __attribute__((weakref("test4_f")));
test4_f;
c() { return b }

$ gcc-trunk -w mutant.c
mutant.c: In function ‘c’:
mutant.c:5:15: error: expected ‘;’ before ‘}’ token
5 | c() { return b }
  |   ^~
  |   ;
At top level:
cc1: internal compiler error: in get, at cgraph.h:2776
0x836e01 varpool_node::get(tree_node const*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraph.h:2776
0x836e01 varpool_node::analyze()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/varpool.c:534
0xae7026 analyze_functions
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:1288
0xae7fc1 symbol_table::finalize_compilation_unit()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/cgraphunit.c:2508
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.

[Bug c/102760] New: ICE: in decompose, at wide-int.h:984

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 102760
   Summary: ICE: in decompose, at wide-int.h:984
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
int isascii(enum mm2);
f1(char *type) { isascii(*type); }

$ gcc-trunk -w mutant.c
mutant.c: In function ‘f1’:
mutant.c:2:26: error: type of formal parameter 1 is incomplete
2 | f1(char *type) { isascii(*type); }
  |  ^
mutant.c:2:18: internal compiler error: in decompose, at wide-int.h:984
2 | f1(char *type) { isascii(*type); }
  |  ^~
0x84c5a6 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/wide-int.h:984
0x87be6e wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree.h:3612
0x87be6e wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/wide-int.h:1034
0x87be6e generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/wide-int.h:790
0x87be6e wi::binary_traits,
generic_wide_int >,
wi::int_traits >::precision_type,
wi::int_traits >
>::precision_type>::result_type
wi::bit_and_not,
generic_wide_int >
>(generic_wide_int const&,
generic_wide_int > const&)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/wide-int.h:2343
0x87be6e gimple_simplify_BIT_AND_EXPR
   
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc-build-trunk/gcc/gimple-match.c:124016
0x15a7906 gimple_simplify
   
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc-build-trunk/gcc/gimple-match.c:142649
0x15a930c gimple_resimplify2
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-match-head.c:320
0x15d451a gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-match-head.c:959
0xc68926 fold_stmt_1
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-fold.c:6212
0xca9b40 gimplify_modify_expr
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:6129
0xc9c7d3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:14584
0xca04da gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:7018
0xca26c6 gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:494
0xca26c6 internal_get_tmp_var
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:647
0xc9bdf7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:15587
0xc9c67a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:15350
0xca04da gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:7018
0xca0d0e gimplify_bind_expr
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:1426
0xc9d00c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimplify.c:14785
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.

[Bug c/102759] New: ICE: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*), maybe_check_access_sizes

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 102759
   Summary: ICE: Segmentation fault,
contains_struct_check(tree_node*,
tree_node_structure_enum, char const*, int, char
const*), maybe_check_access_sizes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

This might be a duplicate to PR 100784

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
a4() { void fa4(int[]); }
void fa4();
call_fa4() { fa4(a4); }

$ gcc-trunk -w mutant.c
during GIMPLE pass: waccess
mutant.c: In function ‘call_fa4’:
mutant.c:3:1: internal compiler error: Segmentation fault
3 | call_fa4() { fa4(a4); }
  | ^~~~
0xf8c8d3 crash_signal
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/toplev.c:326
0x72b653 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/tree.h:3546
0x72b653 maybe_check_access_sizes
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-ssa-warn-access.cc:2880
0xc822f4 check_call
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-ssa-warn-access.cc:3151
0xc822f4 check
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-ssa-warn-access.cc:3310
0xc822f4 check
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-ssa-warn-access.cc:3326
0xc822f4 execute
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/gimple-ssa-warn-access.cc:3340
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.

[Bug target/102758] [12 Regression] Failure to use registers optimally with return values (2 operands related and subreg)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor
   Keywords|needs-bisection |
Summary|[12 Regression] Failure to  |[12 Regression] Failure to
   |use registers optimally |use registers optimally
   |with return values (2   |with return values (2
   |operands related)   |operands related and
   ||subreg)

--- Comment #2 from Andrew Pinski  ---
So the difference in the IR happens from forwprop.
before RA we have this for the old compiler:
(insn 9 8 14 2 (set (reg:V8HI 89)
(plus:V8HI (reg:V8HI 90)
(subreg:V8HI (reg:V2DI 91) 0))) "/app/example.cpp":8:29 3418
{*addv8hi3}
 (expr_list:REG_DEAD (reg:V2DI 91)
(expr_list:REG_DEAD (reg:V8HI 90)
(nil
(insn 14 9 15 2 (set (reg/i:V2DI 20 xmm0)
(subreg:V2DI (reg:V8HI 89) 0)) "/app/example.cpp":9:1 1439
{movv2di_internal}
 (expr_list:REG_DEAD (reg:V8HI 89)
(nil)))

With the new compile we have:
(insn 10 9 14 2 (set (subreg:V8HI (reg:V2DI 84 [  ]) 0)
(plus:V8HI (reg:V8HI 90)
(subreg:V8HI (reg:V2DI 91) 0))) "/app/example.cpp":8:41 5787
{*addv8hi3}
 (expr_list:REG_DEAD (reg:V8HI 90)
(expr_list:REG_DEAD (reg:V2DI 91)
(nil
(insn 14 10 15 2 (set (reg/i:V2DI 20 xmm0)
(reg:V2DI 84 [  ])) "/app/example.cpp":9:1 1634
{movv2di_internal}
 (expr_list:REG_DEAD (reg:V2DI 84 [  ])
(nil)))

This now confuses the register allocator.

So this is only an issue with return because of the hard register being
involved. So this is a minor issue and not much of a problem unless you are
doing microbenchmarking.

[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||cnsun at uwaterloo dot ca

--- Comment #3 from Chengnian Sun  ---
A possible duplicate.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gzh6IUhxke-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211014 (experimental) [master -gee9fa8a57] (GCC)

$ cat mutant.c
baz4(int[(int)+1.0]) {}

$ gcc-trunk  mutant.c
mutant.c:1:1: internal compiler error: in handle_argspec_attribute, at
c-family/c-attribs.c:3654
1 | baz4(int[(int)+1.0]) {}
  | ^~~~
0x6cba3d handle_argspec_attribute
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c-family/c-attribs.c:3654
0x936c35 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/attribs.c:715
0x954efc push_parm_decl(c_parm const*, tree_node**)
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-decl.c:5927
0x99de49 c_parser_parms_list_declarator
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:4297
0x99e1bc c_parser_parms_declarator
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:4223
0x996820 c_parser_direct_declarator_inner
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:4136
0x9b37b5 c_parser_declaration_or_fndef
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:2154
0x9bd933 c_parser_external_declaration
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:1780
0x9be39b c_parser_translation_unit
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:1653
0x9be39b c_parse_file()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c/c-parser.c:23222
0xa20db5 c_common_parse_file()
/tmp/tmp.gzh6IUhxke-gcc-builder/gcc/gcc/c-family/c-opts.c:1237
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.

[Bug target/102758] [12 Regression] Failure to use registers optimally with return values (2 operands related)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-10-15
 Status|UNCONFIRMED |NEW
  Known to work||11.2.0
   Target Milestone|--- |12.0
Summary|[x86] Failure to use|[12 Regression] Failure to
   |registers optimally when|use registers optimally
   |swapping between|with return values (2
   |(identically represented)   |operands related)
   |vector types|
  Known to fail||12.0

--- Comment #1 from Andrew Pinski  ---
GCC 11.2.0 (and before) produces:
movdqa  .LC0(%rip), %xmm0
paddw   %xmm1, %xmm0
ret

Which is what you want.
I don't know why trunk changed ...

[Bug target/102758] New: [x86] Failure to use registers optimally when swapping between (identically represented) vector types

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102758
   Summary: [x86] Failure to use registers optimally when swapping
between (identically represented) vector types
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

typedef int64_t v2i64 __attribute__((vector_size(16)));
typedef uint16_t v8u16 __attribute__((vector_size(16)));

v2i64 f(v8u16 make_b_xxm1, v2i64 b)
{
return (v2i64)((v8u16)b + (v8u16){1});
}

With -O3, GCC outputs this:

f(unsigned short __vector(8), long __vector(2)):
movdqa  xmm2, XMMWORD PTR .LC0[rip]
paddw   xmm2, xmm1
movdqa  xmm0, xmm2
ret

LLVM outputs this:

f(unsigned short __vector(8), long __vector(2)):
movdqa  xmm0, xmm1
paddw   xmm0, xmmword ptr [rip + .LCPI0_0]
ret

It should be possible to optimize out the last `movdqa`. This seems to be
directly related to the usage of differing types here (even though the
conversion is cost-free) as replacing all usage of `v2i64` with `v8u16` makes
this be better optimized.

[Bug c++/86216] g++ ICE on valid code: verify_ssa failed

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #12 from Andrew Pinski  ---
*** Bug 102757 has been marked as a duplicate of this bug. ***

[Bug c++/102757] ICE on amd64 (internal compiler error: in expand_expr_real_1, at expr.c:10014)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 86216.

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

[Bug c++/102757] New: ICE on amd64 (internal compiler error: in expand_expr_real_1, at expr.c:10014)

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 102757
   Summary: ICE on amd64 (internal compiler error: in
expand_expr_real_1, at expr.c:10014)
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---

Created attachment 51605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51605=edit
logging.ii (minimised reproducer)

Originally reported downstream at https://bugs.gentoo.org/806094.

I hit the issue when building android-tools-31.0.0_p1. Note that this issue
does not seem to occur with gcc 10.3.0 or gcc 11.2.0.

I've managed to minimise the crasher to:
```
$ cat logging.ii
struct Trans_NS___cxx11_basic_string {
  int *c_str();
};
int snprintf(...);
enum LogSeverity {};
enum LogId {};
template 
void SplitByLogdChunks(LogId, LogSeverity, char *, char *, int, char *msg, F) {
  long max_size;
  Trans_NS___cxx11_basic_string file_header;
  char logd_chunk[max_size];
  auto write_to_logd_chunk = [&](char *, int) {
*file_header.c_str() = snprintf(sizeof(logd_chunk));
  };
  char newline;
  write_to_logd_chunk(msg, newline);
}
void LogdLogChunk();
LogId LogdLogger_id;
LogSeverity LogdLogger_severity;
char LogdLogger_tag, LogdLogger_file, LogdLogger_message;
int LogdLogger_line;
void LogdLogger() {
  SplitByLogdChunks(LogdLogger_id, LogdLogger_severity, _tag,
_file, LogdLogger_line, _message,
LogdLogChunk);
}
```

It can be induced via:
```
$ x86_64-pc-linux-gnu-g++ logging.ii
during RTL pass: expand
logging.ii: In lambda function:
logging.ii:13:36: internal compiler error: in expand_expr_real_1, at
expr.c:10014
   13 | *file_header.c_str() = snprintf(sizeof(logd_chunk));
  |^~~~
unrecognized DWARF version in .debug_info at 6
unrecognized DWARF version in .debug_info at 6
unrecognized DWARF version in .debug_info at 6
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

```
$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.4.0/work/gcc-9.4.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.4.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.4.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.4.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.4.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.4.0/python
--enable-languages=c,c++,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 9.4.0
p1' --enable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --disable-vtable-verify --disable-libvtv --enable-lto
--with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.4.0 (Gentoo Hardened 9.4.0 p1)
```

[Bug tree-optimization/102744] [12 regression] -O2 vectorization causes Wzero-length-array-bounds-2.c to fail on arc-elf

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Martin Sebor from comment #1)
> Here's the relevant part of the test with line numbers:
> 
> 68char cbuf1[1 * sizeof (struct C)];
> 69char cbuf2[2 * sizeof (struct C)] = { };
> 70
> 71void test_C_global_buf (void)
> 72{
> 73  struct C *p = (struct C*)
>...
> 84  p = (struct C*)
>...
> 90  p->b2.a[ 0].i = 0;
> 91  p->b2.a[ 1].i = 0;
> 92  p->b2.a[ 2].i = 0; // { dg-warning "\\\[-Warray-bounds" }
> 93  p->b2.a[ 3].i = 0; // { dg-warning "\\\[-Warray-bounds" }
> 94  sink (p);
> 
> ad the output is below.  We get the two -Warray-bounds instances as
> expected; they are issued before vectorization.  Then we get an additional
> -Wstringop-overflow for the valid store on line 90 from the strlen pass
> thanks to the four stores having been vectorized.  So the problem is
What i got is 2 store vectorized which cause extra -Wstringop-overflow=
For x86 which have 4 stores vectorized, there's no extra warning.
Should be behavior of extra warning for 2 store vectorized but not 4 store
vectorized be expected

Here is dump for arc-elf
void test_C_global_buf ()
{
  int * vectp.23;
  vector(2) int * vectp_cbuf2.22;
  int * vectp.21;
  vector(2) int * vectp_cbuf2.20;
  int * vectp.19;
  vector(2) int * vectp_cbuf1.18;
  int * vectp.17;
  vector(2) int * vectp_cbuf1.16;
  int * _22;

   [local count: 1073741824]:
  MEM  [(int *)] = { 0, 0 };
  MEM[(struct C *)].b1.a[1].i = 0;
  sink ();
  MEM  [(int *) + 8B] = { 0, 0 };
  sink ();
  MEM  [(int *)] = { 0, 0 };
  MEM[(struct C *)].b1.a[1].i = 0;
  sink ();
  MEM  [(int *) + 8B] = { 0, 0 };
  _22 = [(struct C *)].b2.a[0].i + 8;
  MEM  [(int *)_22] = { 0, 0 };
  sink ();
  return;


And dump for x86

void test_C_global_buf ()
{
  int * vectp.33;
  vector(4) int * vectp_cbuf2.32;
  int * vectp.31;
  vector(2) int * vectp_cbuf2.30;
  int * vectp.29;
  vector(2) int * vectp_cbuf1.28;
  int * vectp.27;
  vector(2) int * vectp_cbuf1.26;

   [local count: 1073741824]:
  MEM  [(int *)] = { 0, 0 };
  MEM[(struct C *)].b1.a[1].i = 0;
  sink ();
  MEM  [(int *) + 8B] = { 0, 0 };
  sink ();
  MEM  [(int *)] = { 0, 0 };
  MEM[(struct C *)].b1.a[1].i = 0;
  sink ();
  MEM  [(int *) + 8B] = { 0, 0, 0, 0 };
  sink ();
  return;

}

[Bug tree-optimization/102756] [12 Regression] Complete unrolling is too senative to PRE; c-c++-common/torture/vector-compare-2.c

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/102756] [12 Regression] Complete unrolling is too senative to PRE; c-c++-common/torture/vector-compare-2.c

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-10-15
   Keywords||missed-optimization
Summary|[12 Regression] Vectorizer  |[12 Regression] Complete
   |change creates poor code|unrolling is too senative
   |for |to PRE;
   |c-c++-common/torture/vector |c-c++-common/torture/vector
   |-compare-2.c|-compare-2.c
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
With -ftree-vectorize
size: 7-4, last_iteration: 7-4
  Loop size: 7
  Estimated size after unrolling: 8


  _1 = VIEW_CONVERT_EXPR(r)[i_10];


With -fno-tree-vectorize
size: 7-4, last_iteration: 6-4
  Loop size: 7
  Estimated size after unrolling: 7

  pretmp_2 = MEM[(vector(4) int *)][i_7];


Also -O2 -fno-tree-vectorize -fno-tree-pre produces the same as the -O2
-ftree-vectorize case.



--- CUT 
Loop 1 iterates 3 times.
Loop 1 iterates at most 3 times.
Loop 1 likely iterates at most 3 times.
Estimating sizes for loop 1
 BB: 3, after_exit: 0
  size:   1 _1 = VIEW_CONVERT_EXPR(r)[i_10];
  size:   2 if (_1 != -3)
 BB: 7, after_exit: 1
 BB: 5, after_exit: 0
  size:   1 i_7 = i_10 + 1;
   Induction variable computation will be folded away.
  size:   1 ivtmp_9 = ivtmp_2 - 1;
   Induction variable computation will be folded away.
  size:   2 if (ivtmp_9 != 0)
   Exit condition will be eliminated in peeled copies.
   Exit condition will be eliminated in last copy.
   Constant conditional.
size: 7-4, last_iteration: 7-4
  Loop size: 7
  Estimated size after unrolling: 8
Not unrolling loop 1: size would grow.


vs:
Estimating sizes for loop 1
 BB: 3, after_exit: 0
  size:   2 if (prephitmp_9 != -3)
 BB: 6, after_exit: 1
  size:   1 pretmp_2 = MEM[(vector(4) int *)][i_7];
 BB: 5, after_exit: 0
  size:   1 i_7 = i_10 + 1;
   Induction variable computation will be folded away.
  size:   1 ivtmp_11 = ivtmp_1 - 1;
   Induction variable computation will be folded away.
  size:   2 if (ivtmp_11 != 0)
   Exit condition will be eliminated in peeled copies.
   Exit condition will be eliminated in last copy.
   Constant conditional.
size: 7-4, last_iteration: 6-4
  Loop size: 7
  Estimated size after unrolling: 7


PRE decides to do the load for MEM[(vector(4) int *)][0] which is why the
last iteration is 6-4 rather than 7-4.

[Bug tree-optimization/102756] New: [12 Regression] Vectorizer change creates poor code for c-c++-common/torture/vector-compare-2.c

[law at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102756
   Summary: [12 Regression] Vectorizer change creates poor code
for c-c++-common/torture/vector-compare-2.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

The visium-elf port is a bit broken in that any code which calls abort will
fail to link.   This has turned out to be useful in that it has pointed out
cases where the quality of our code generation has suffered.

The change to turn on the vectorizer by default at -O2 is yet another example.

c-c++-common/torture/vector-compare-2.c before the vectorizer change compiled
down to this code at -O2:



.file   "j.c"
.text
.align  4
.p2align 8
.global foo
.type   foo, @function
foo:
moviu   r9,65535
movil   r9,65533
write.l (r1),r9
write.l 1(r1),r9
write.l 2(r1),r9
bra tr,r21,r0   ;return
 write.l 3(r1),r9
.size   foo, .-foo
.section.text.startup,"ax",@progbits
.align  4
.p2align 8
.global main
.type   main, @function
main:
bra tr,r21,r0   ;return
 moviq   r1,0   ;movsi  r  J
.size   main, .-main
.ident  "GCC: (GNU) 12.0.0 20211008 (experimental)"


Of particular note "main" does _not_ call abort.  The optimizers have figured
everything out and realized that it should never abort.

After enabling the vectorizer at -O2 we get:
.file   "j.c"
.text
.align  4
.p2align 8
.global foo
.type   foo, @function
foo:
moviu   r9,65535
movil   r9,65533
write.l (r1),r9
write.l 1(r1),r9
write.l 2(r1),r9
bra tr,r21,r0   ;return
 write.l 3(r1),r9
.size   foo, .-foo
.section.text.startup,"ax",@progbits
.align  4
.p2align 8
.global main
.type   main, @function
main:
subisp,36
moviq   r10,23  ;movsi  r  J
write.l (sp),fp
move.l  fp,sp   ;stack_save
add.l   r8,fp,r10
lsr.l   r8,r8,4
asl.l   r8,r8,4
moviu   r9,65535
write.l 1(sp),r21
movil   r9,65533
write.l (r8),r9
write.l 1(r8),r9
write.l 2(r8),r9
write.l 3(r8),r9
move.l  r10,r8
moviq   r8,16   ;movsi  r  J
add.l   r7,r10,r8
.L5:
read.l  r8,(r10)
cmp.l   r8,r9
brr ne,.L8
 addir10,4
cmp.l   r10,r7
brr ne,.L5
 moviq   r1,0   ;movsi  r  J
read.l  fp,(sp)
read.l  r21,1(sp)
bra tr,r21,r0   ;return
 addisp,36  ;stack pop
.L8:
moviu   r10,%u abort
movil   r10,%l abort
bra tr,r10,r21
 nop;call
.size   main, .-main
.ident  "GCC: (GNU) 12.0.0 20211008 (experimental)"


Note how there's a call to abort starting at the label .L8.  And more generally
the code in "main" is considerably larger and more complex.

This is a code quality regression.

[Bug c++/102748] static_assert on concept leads to undefined reference

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-15

--- Comment #1 from Andrew Pinski  ---
Confirmed related to PR 99130.

[Bug tree-optimization/102752] [12 Regression] Recent change to ldist causing ICE on msp430-elf, rl78-elf, and xstormy16-elf

[law at gcc dot gnu.org via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Jeffrey A. Law  ---
And just an FYI.  That patch fixes the problem on all three affected platforms.
 Assuming it bootstraps and regression tests, consider it pre-approved for the
trunk.

Thanks

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #2 from Andrew Pinski  ---
What exact configure line did you do?
Also what exact error message is happening and when? While building gcc's
library or otherwise?

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-14
  Component|c   |driver
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
This should have been taken care of by this part:
static char*
find_a_program (const char *name)
{
  /* Do not search if default matches query. */

#ifdef DEFAULT_ASSEMBLER
  if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, X_OK) == 0)
return xstrdup (DEFAULT_ASSEMBLER);
#endif


So why is it not?

[Bug c/102755] New: Built gcc cross compiler always tries to use "as" instead of cross assembler

[dr.duncan.p.simpson at gmx dot com via Gcc-bugs]

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

Bug ID: 102755
   Summary: Built gcc cross compiler always tries to use "as"
instead of  cross assembler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dr.duncan.p.simpson at gmx dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Created attachment 51604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51604=edit
Proposed minimal fix

In gcc.c the assembler name is hard coded as "as" and the --with-as option does
not change this. When building an aarch64-linxu-gnu cross compiler the build
process used aarc64-linux-gnu-as but the built cross compiler attempted to use
"as", which does not work. While I could override the spec file that is a
suboptimal solution.

This affects at least the gcc-12 tip version and probably most other versions
too. The proposed fix has been tested without --with-as and with
--with-as=/usr/local/bin/aarch64-linux-gnu-as.

[Bug c++/98216] [C++20] template mangling for double template argument is wrong

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r12-4278-g74ccca380cde5e79

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-October/056724.html

[Bug c++/99008] [10 Regression] ICE in set_constraints, at cp/constraint.cc:1256

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|10.4|11.0

--- Comment #7 from Patrick Palka  ---
I suppose this isn't worth backporting to the 10 branch.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/98216] [C++20] template mangling for double template argument is wrong

[hq.ks at web dot de via Gcc-bugs]

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

hq.ks at web dot de changed:

   What|Removed |Added

 CC||hq.ks at web dot de

--- Comment #11 from hq.ks at web dot de ---
*** Bug 102754 has been marked as a duplicate of this bug. ***

[Bug c++/102754] collisions in double constant template mangling for negative values

[hq.ks at web dot de via Gcc-bugs]

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

hq.ks at web dot de changed:

   What|Removed |Added

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

--- Comment #3 from hq.ks at web dot de ---
Marked as duplicate.

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

[Bug c++/102754] collisions in double constant template mangling for negative values

[hq.ks at web dot de via Gcc-bugs]

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

--- Comment #2 from hq.ks at web dot de ---
Created attachment 51603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51603=edit
output

[Bug c++/102754] collisions in double constant template mangling for negative values

[hq.ks at web dot de via Gcc-bugs]

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

--- Comment #1 from hq.ks at web dot de ---
Created attachment 51602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51602=edit
compile, grep object symbols

[Bug c++/102754] New: collisions in double constant template mangling for negative values

[hq.ks at web dot de via Gcc-bugs]

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

Bug ID: 102754
   Summary: collisions in double constant template mangling for
negative values
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hq.ks at web dot de
  Target Milestone: ---

Created attachment 51601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51601=edit
reproducer

This was a weird one. 

C++ famously does not allow floating point numbers directly as template
parameters for unfathomable reasons (but lambda expressions returning double or
string constants are fine, go figure). The common workaround seems to be to
have a literal wrapper class which stores a FP number, can be initialized by
one and is convertable to one. 

When using this with negative double numbers, some came out all wrong from the
template, causing quite some confusion. 

Apparently, if two or more template instances depend on a double parameter
which is
a) negative
b) whose mantissa would fit into some 21 bits (possibly causing the 32 less
significant bits of the fraction part to be zero?)
any instance after the first one would erroneously refer to the first one. 

On further digging, I think this is somehow related to name mangling. 

For example, 3.0266874179647485e+267D (Binary 0x) will result
in an object named _ZTAXtl4wrapIdELdEEE for me. 
-1.486039738058660044846e-267 (aka 88 88 88 88 88 88 88 88), however, will
result in an object named _ZTAXtl4wrapIdELdEEE. 

Note how the upper 32 bits have all been replaced by ones! This means that any
doublewrap objects which have their sign bit set will collide if their lower 32
bits are the same. The case I encountered was just the special case of the
lower 32 bits being zero. 

Having concluded that, I can also conclude that this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 .
(Having spend a day to write up this bug report, I will still submit it and
then try to mark it as a duplicate. Hope that is okay.)

[Bug fortran/102717] ICE in gfc_simplify_reshape, at fortran/simplify.c:6843

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-4415-gb47490c572c5938f887b54240af6096a7c90f640
Author: Harald Anlauf 
Date:   Thu Oct 14 20:19:50 2021 +0200

Fortran: generate error message for negative elements in SHAPE array

gcc/fortran/ChangeLog:

PR fortran/102717
* simplify.c (gfc_simplify_reshape): Replace assert by error
message for negative elements in SHAPE array.

gcc/testsuite/ChangeLog:

PR fortran/102717
* gfortran.dg/reshape_shape_2.f90: New test.

[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:1b115daf62d94337b3d0b2962b0bbbf005a450e0

commit r12-4414-g1b115daf62d94337b3d0b2962b0bbbf005a450e0
Author: Harald Anlauf 
Date:   Thu Oct 14 20:18:14 2021 +0200

Fortran: fix order of checks for the SHAPE intrinsic

gcc/fortran/ChangeLog:

PR fortran/102716
* check.c (gfc_check_shape): Reorder checks so that invalid KIND
arguments can be detected.

gcc/testsuite/ChangeLog:

PR fortran/102716
* gfortran.dg/shape_10.f90: New test.

[Bug c++/102753] ICE in cp_genericize_r on invalid use of pointer to a consteval member function

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-14

--- Comment #1 from Andrew Pinski  ---
Clang gives:
:7:8: error: cannot take address of consteval function 'f' outside of
an immediate invocation
  (t.*::f)();
   ^
:2:17: note: declared here
  consteval int f() const { return 12; }
^

ICC accepts the code.
MSVC gives:
(7): error C7596: 'test::f': cannot take address of immediate function
outside of an immediate invocation


Confirmed.

[Bug tree-optimization/102752] [12 Regression] Recent change to ldist causing ICE on msp430-elf, rl78-elf, and xstormy16-elf

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jeffrey A. Law  ---
No worries.  This is why we have testing systems.

[Bug tree-optimization/102752] [12 Regression] Recent change to ldist causing ICE on msp430-elf, rl78-elf, and xstormy16-elf

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
It looks like I missed to take the TREE_TYPE of reduction_var. I just did a
quick test with

diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
index fb9250031b5..0559b9c47d7 100644
--- a/gcc/tree-loop-distribution.c
+++ b/gcc/tree-loop-distribution.c
@@ -3430,7 +3430,7 @@ generate_strlen_builtin_using_rawmemchr (loop_p loop,
tree reduction_var,
 static bool
 reduction_var_overflows_first (tree reduction_var, tree load_type)
 {
-  widest_int n2 = wi::lshift (1, TYPE_PRECISION (reduction_var));;
+  widest_int n2 = wi::lshift (1, TYPE_PRECISION (TREE_TYPE (reduction_var)));;
   widest_int m2 = wi::lshift (1, TYPE_PRECISION (ptrdiff_type_node) - 1);
   widest_int s = wi::to_widest (TYPE_SIZE_UNIT (load_type));
   return wi::ltu_p (n2, wi::udiv_trunc (m2, s));
@@ -3681,7 +3681,7 @@ loop_distribution::transform_reduction_loop (loop_p loop)
  && ((TYPE_PRECISION (sizetype) >= TYPE_PRECISION (ptr_type_node) - 1
   && TYPE_PRECISION (ptr_type_node) >= 32)
  || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (reduction_var))
- && TYPE_PRECISION (reduction_var) <= TYPE_PRECISION
(sizetype)))
+ && TYPE_PRECISION (TREE_TYPE (reduction_var)) <=
TYPE_PRECISION (sizetype)))
  && builtin_decl_implicit (BUILT_IN_STRLEN))
generate_strlen_builtin (loop, reduction_var, load_iv.base,
 reduction_iv.base, loc);

successfully. It's getting late here. I will come back to this tomorrow
morning. Sorry for the inconvenience.

[Bug c++/102753] New: ICE on invalid use of pointer to a consteval member function

[aaron at aaronballman dot com via Gcc-bugs]

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

Bug ID: 102753
   Summary: ICE on invalid use of pointer to a consteval member
function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron at aaronballman dot com
  Target Milestone: ---

The following code crashes GCC instead of giving an error:

struct test {
  consteval int f() const { return 12; }
};

constexpr test t;
int main() {
  (t.*::f)();
}

Note that the call to the PMF is not in a constant evaluated context.

https://godbolt.org/z/beWhE9qMv

[Bug tree-optimization/102738] Failure to optimize (signed) right shift if the range is already known to be [-1, 0]

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Macleod  ---
I added this to the simplifier, so we now get all these cases right in EVRP.  
I incorporated all 6 into one test.

[Bug tree-optimization/102738] Failure to optimize (signed) right shift if the range is already known to be [-1, 0]

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r12-4413-gf0b7d4cc49ddb1c2c7474cc3f61e260aa93a96c0
Author: Andrew MacLeod 
Date:   Thu Oct 14 10:43:58 2021 -0400

Simplification for right shift.

When the first operand of a signed right shift is zero or negative one, the
RHS doesn't matter and the shift can be converted to a copy.

PR tree-optimization/102738
gcc/
* vr-values.c (simplify_using_ranges::simplify): Handle
RSHIFT_EXPR.

gcc/testsuite
* gcc.dg/pr102738.c: New.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Uroš Bizjak  ---
(In reply to jos...@codesourcery.com from comment #24)
> This is a fundamentally different test, because it involves (in the 
> abstract machine) lvalue-to-rvalue conversion of a sNaN representation.  
> That means that, unlike the present bug, and the two others I referenced, 
> (a) it's only valid with -fsignaling-nans, (b) it's at most a 
> quality-of-implementation issue because of the rule that assignment to the 
> same format may be a convertFormat operation rather a copy operation, and 
> (c) the ABI means the exception can't be avoided when an sNaN is returned.  
> Effectively, this test is bug 56831, whereas the present bug is more like 
> bug 58416 and bug 71460.

I would like to point out (in the context of trapping behavior of x87) that I
don't think we should disable FP conditional moves with the patch in Comment
#18 to fix the presented corner case, as this will effect the runtime
performance of the vast majority of applications that don't care about traps.
Looking at the above referred bugs, it is IMO time to throw in the towel and
declare x87 math as kind-of-broken w.r.t trapping. The compiler will generate
code that speculatively loads values at various places (as shown by the
testcase in Comment #20), not only at the FCMOV site.

I'm not a language lawyer, but IMO access to a non-volatile object is not
forbidden *if the value is not used*. Unfortunately, some accesses have
secondary effects that are not considered by the compiler, and the trapping
behavior of FLDS/FLDL is certainly one of them.

[Bug tree-optimization/102752] [12 Regression] Recent change to ldist causing ICE on msp430-elf, rl78-elf, and xstormy16-elf

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jeffrey A. Law  ---
gcc.dg/tree-ssa/pr45427.c shows the same issue.

[Bug tree-optimization/102752] New: [12 Regression] Recent change to ldist causing ICE on msp430-elf, rl78-elf, and xstormy16-elf

[law at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102752
   Summary: [12 Regression] Recent change to ldist causing ICE on
msp430-elf, rl78-elf, and xstormy16-elf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

After this change:


msp430-elf, rl78-elf and xstormy16-elf are all getting an ICE on
gcc.c-torture/execute/

>From the msp430-elf gcc.log file:

/home/jlaw/jenkins/workspace/msp430-elf/gcc/gcc/testsuite/gcc.c-torture/execute/20100827-1.c:
In function 'foo':^M
/home/jlaw/jenkins/workspace/msp430-elf/gcc/gcc/testsuite/gcc.c-torture/execute/20100827-1.c:3:1:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(ssa_name) in transform_reduction_loop, at tree-loop-distribution.c:3684^M
0x1532ceb tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)^M
../../..//gcc/gcc/tree.c:8739^M
0x861c29 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)^M
../../..//gcc/gcc/tree.h:3556^M
0x12006d9 loop_distribution::transform_reduction_loop(loop*)^M
../../..//gcc/gcc/tree-loop-distribution.c:3684^M
0x1200d92 loop_distribution::execute(function*)^M
../../..//gcc/gcc/tree-loop-distribution.c:3776^M
0x12012bd execute^M
../../..//gcc/gcc/tree-loop-distribution.c:3901^M
Please submit a full bug report,^M

You should be able to reproduce this with just a cross compiler.  No assembler
or target libraries should be needed.

[Bug testsuite/102751] New: [12 regression] new test case cc.dg/tree-ssa/pr102736.c fails

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102751
   Summary: [12 regression] new test case
cc.dg/tree-ssa/pr102736.c fails
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:a311163fd81babd6116e2856f4551c3ca13d8914, r12-4395
make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr102736.c"
FAIL: gcc.dg/tree-ssa/pr102736.c execution test
# of expected passes1
# of unexpected failures1

There's no message from it

spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/pr102736.c
-fdiagnostics-plain-output -O1 -ftree-vrp -lm -o ./pr102736.exe
PASS: gcc.dg/tree-ssa/pr102736.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home3/seurer/gcc/git/build/gcc-test/gcc::/home3/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/tree-ssa/pr102736.c execution test

(gdb) run
Starting program: /home3/seurer/gcc/git/build/gcc-test/pr102736.exe 

Program received signal SIGABRT, Aborted.
0x77c30468 in __libc_signal_restore_set (set=0x7fffe768) at
../sysdeps/unix/sysv/linux/internal-signals.h:86
86  ../sysdeps/unix/sysv/linux/internal-signals.h: No such file or
directory.
(gdb) where
#0  0x77c30468 in __libc_signal_restore_set (set=0x7fffe768) at
../sysdeps/unix/sysv/linux/internal-signals.h:86
#1  __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:48
#2  0x77c07cd0 in __GI_abort () at abort.c:79
#3  0x1738 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/pr102736.c:19


commit a311163fd81babd6116e2856f4551c3ca13d8914 (HEAD, refs/bisect/bad)
Author: Aldy Hernandez 
Date:   Thu Oct 14 10:28:39 2021 +0200

Do not call range_on_path_entry for SSAs defined within the path

[Bug tree-optimization/102744] [12 regression] -O2 vectorization causes Wzero-length-array-bounds-2.c to fail on arc-elf

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org
   Last reconfirmed||2021-10-14
 Status|UNCONFIRMED |NEW
 Blocks||102706
   Target Milestone|--- |12.0
   Keywords||diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Here's the relevant part of the test with line numbers:

68  char cbuf1[1 * sizeof (struct C)];
69  char cbuf2[2 * sizeof (struct C)] = { };
70  
71  void test_C_global_buf (void)
72  {
73struct C *p = (struct C*)
   ...
84p = (struct C*)
   ...
90p->b2.a[ 0].i = 0;
91p->b2.a[ 1].i = 0;
92p->b2.a[ 2].i = 0; // { dg-warning "\\\[-Warray-bounds" }
93p->b2.a[ 3].i = 0; // { dg-warning "\\\[-Warray-bounds" }
94sink (p);

ad the output is below.  We get the two -Warray-bounds instances as expected;
they are issued before vectorization.  Then we get an additional
-Wstringop-overflow for the valid store on line 90 from the strlen pass thanks
to the four stores having been vectorized.  So the problem is basically the
same as in one of the other reports.  I hesistate to mark this a dupe only
because it will need its own suppression (CC'ing Hongtao as a heads up).

As an aside, these regressions will no doubt make the warnings pretty confusing
to users.  We (i.e., I) should try to come up with a fix before GCC 12 goes out
the door.  I don't expect to have the time to to get to it before stage 1 ends.

/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:92:10:
warning: array subscript 2 is above array bounds of 'struct A[0]'
[-Warray-bounds]
   92 |   p->b2.a[ 2].i = 0; // { dg-warning "\\\[-Warray-bounds" }
  |   ~~~^~~~
/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:10:28: note:
while referencing 'a'
   10 | struct B { int j; struct A a[0]; };
  |^
/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:93:10:
warning: array subscript 3 is above array bounds of 'struct A[0]'
[-Warray-bounds]
   93 |   p->b2.a[ 3].i = 0; // { dg-warning "\\\[-Warray-bounds" }
  |   ~~~^~~~
/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:10:28: note:
while referencing 'a'
   10 | struct B { int j; struct A a[0]; };
  |^
/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:90:17:
warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
   90 |   p->b2.a[ 0].i = 0;
  |   ~~^~~
/src/gcc/master/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:69:6: note:
at offset 16 into destination object 'cbuf2' of size 16
   69 | char cbuf2[2 * sizeof (struct C)] = { };
  |  ^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
[Bug 102706] [12 regression] -O2 vectorization causes regression in
Warray-bounds-48.c on many targets

[Bug tree-optimization/102750] New: 433.milc regressed by 10% on AMD zen2 at -Ofast -march=native -flto after r12-3893-g6390c5047adb75

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102750
   Summary: 433.milc regressed by 10% on AMD zen2 at -Ofast
-march=native -flto after r12-3893-g6390c5047adb75
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

I have bisected an AMD zen2 10% performance regression of SPEC 2006 FP
433.milc benchmark when compiled with -Ofast -march=native -flto to
commit r12-3893-g6390c5047adb75.  See also:

 
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=412.70.0=289.70.0;

As Richi asked, I am filing this bug even though I cannot reproduce the
regression neither on an AMD zen3 machine nor on Intel CascadeLake, because
the history of the benchmark performance and because I know milc can be
sensitive to conditions outside our control.  OTOH, the regression
reproduces reliably for me.

Some relevant perf data:

BEFORE:
# Samples: 585K of event 'cycles:u'
# Event count (approx.): 472738682838
#
# Overhead   Samples  Command  Shared Object   Symbol
#     ...  .. 
.
# 
24.59%140397  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
u_shift_fermion
18.47%105497  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
add_force_to_mom
15.97% 96343  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_na
15.29% 90027  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_nn
 5.55% 35114  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
path_product
 4.75% 27693  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
compute_gen_staple
 2.76% 16109  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_an
 2.42% 14255  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
imp_gauge_force.constprop.0
 2.02% 11561  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_adj_su3_mat_4vec

AFTER:
# Samples: 634K of event 'cycles:u'
# Event count (approx.): 513635733685
#
# Overhead   Samples  Command  Shared Object   Symbol   
#     ...  .. 
.
#
24.04%149010  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
add_force_to_mom
23.76%147370  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
u_shift_fermion
14.19% 90929  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_nn
14.14% 92912  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_na
 4.90% 33846  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
path_product
 3.89% 24621  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
mult_su3_an
 3.62% 22831  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
compute_gen_staple
 2.05% 13215  milc_peak.mine-  milc_peak.mine-lto-nat  [.]
imp_gauge_force.constprop.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

[thiago at kde dot org via Gcc-bugs]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #10 from Thiago Macieira  ---
(In reply to Jonathan Wakely from comment #9)
> Thanks for noticing I missed it.

Well, I had to clear C++'s good name when Arjan complained that he couldn't
understand what the compiler was telling him about  :)

[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Martin Jambor  ---
Looking at the LNT graph, I guess this bug should be either closed or suspended
(not sure what the suspended state means for the blocked metabug, so probably
closed).

Yeah, it's weird.

[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories

[law at gcc dot gnu.org via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
So that begs the question, do we want to install the patch or wait for the move
to sphinx?

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #24 from joseph at codesourcery dot com  ---
On Thu, 14 Oct 2021, ubizjak at gmail dot com via Gcc-bugs wrote:

> The situation is hopeless from the beginning. Please consider this testcase:
> 
> --cut here--
> #include 
> #include 
> 
> double
> __attribute__((noinline,noipa))
> foo (double a, double b, char c)
> {
>   return c ? a : b;
> }
> 
> int main ()
> {
>   double a = __builtin_nans ("");
>   double b = 42.0;
> 
>   feclearexcept (FE_INVALID);
>   foo (a, b, 0);

This is a fundamentally different test, because it involves (in the 
abstract machine) lvalue-to-rvalue conversion of a sNaN representation.  
That means that, unlike the present bug, and the two others I referenced, 
(a) it's only valid with -fsignaling-nans, (b) it's at most a 
quality-of-implementation issue because of the rule that assignment to the 
same format may be a convertFormat operation rather a copy operation, and 
(c) the ABI means the exception can't be avoided when an sNaN is returned.  
Effectively, this test is bug 56831, whereas the present bug is more like 
bug 58416 and bug 71460.

[Bug c++/102749] New: ambigous call on different std::variant types with iterators

[benni.probst at gmx dot de via Gcc-bugs]

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

Bug ID: 102749
   Summary: ambigous call on different std::variant types with
iterators
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.probst at gmx dot de
  Target Milestone: ---

Created attachment 51600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51600=edit
dataContainer switching between container Types, reading with std::variant
iterator types

the compiler cannot see the difference:

In file included from
/home/benjamin/CLionProjects/UltiHash/aiHeuristics_runtime_tests.h:4,
 from /home/benjamin/CLionProjects/UltiHash/main.cpp:8:
/home/benjamin/CLionProjects/UltiHash/dataContainer.h: In instantiation of
‘dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum,
internEnum):: [with
auto:179 = std::integral_constant]’:
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84:   required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::benchmark(long unsigned int, long unsigned int, internEnum,
internEnum)::]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1103:78:   required from
‘dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum) [with auto:177
= std::integral_constant]’
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84:   required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::benchmark(long unsigned int, long unsigned int, internEnum,
internEnum)]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1055:83:   required from
‘dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum):: [with auto:176 =
std::integral_constant]’
/usr/local/include/boost/mp11/detail/mp_with_index.hpp:374:84:   required by
substitution of ‘template constexpr decltype
(declval()(declval >()))
boost::mp11::mp_with_index(std::size_t, F&&) [with N =
std::integral_constant; F = dataContainer::benchmark(long unsigned int, long unsigned int, internEnum,
internEnum)::]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1051:79:   required from
‘void dataContainer::benchmark(long unsigned int, long unsigned int,
internEnum, internEnum) [with T = unsigned int; alloc = {}; internEnum = long
unsigned int]’
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1050:10:   required from
here
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:1106:21: error: call of
overloaded ‘insert(__gnu_cxx::__normal_iterator >&, unsigned int)’ is ambiguous
 1106 | insert(itB, T{});
  | ^~
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:604:18: note: candidate:
‘dataContainer::iteratorType dataContainer::insert(dataContainer::iteratorType&&, Args&& ...) [with Args
= {unsigned int}; T = unsigned int; alloc = {}; dataContainer::iteratorType = std::variant<__gnu_cxx::__normal_iterator > >,
std::_Deque_iterator,
std::_List_iterator, boost::container::vec_iterator, boost::container::stable_vector_iterator,
unsigned int*, boost::container::dtl::deque_iterator,
boost::container::dtl::iterator_from_iiterator, boost::intrusive::list_node_traits,
boost::intrusive::normal_link, boost::intrusive::dft_tag, 1>, false>, false>,
std::_Fwd_list_iterator,
boost::container::dtl::iterator_from_iiterator, boost::intrusive::slist_node_traits,
boost::intrusive::normal_link, boost::intrusive::dft_tag, 2>, false>, false>
>]’
  604 | iteratorType insert(iteratorType &, Args &&...args){
  |  ^~
/home/benjamin/CLionProjects/UltiHash/dataContainer.h:649:23: note: candidate:
‘dataContainer::constIteratorType dataContainer::insert(dataContainer::constIteratorType&&, Args&& ...) [with
Args = {unsigned int}; T = unsigned int; alloc = {}; dataContainer::constIteratorType = std::variant<__gnu_cxx::__normal_iterator > >,
std::_Deque_iterator,
std::_List_const_iterator,
boost::container::vec_iterator,
boost::container::stable_vector_iterator, const unsigned
int*, boost::container::dtl::deque_iterator,
boost::container::dtl::iterator_from_iiterator, boost::intrusive::list_node_traits,
boost::intrusive::normal_link, boost::intrusive::dft_tag, 1>, false>, true>,
std::_Fwd_list_const_iterator,
boost::container::dtl::iterator_from_iiterator, boost::intrusive::slist_node_traits,
boost::intrusive::normal_link, boost::intrusive::dft_tag, 2>, false>, true> >]’
  649 | constIteratorType insert(constIteratorType &, Args &&...args){
  |   ^~

[Bug rtl-optimization/102627] [11 Regression] wrong code with "-O1"

[vmakarov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Vladimir Makarov  ---
I've committed the patch to gcc-11 branch too after nobody made complaints
about the patch in the trunk.  I've also successfully tested and bootstrapped
the patch on the branch too.

[Bug rtl-optimization/102627] [11 Regression] wrong code with "-O1"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Vladimir Makarov
:

https://gcc.gnu.org/g:99d21577f8a00196f3133fe1066de6e3e7d180c1

commit r11-9154-g99d21577f8a00196f3133fe1066de6e3e7d180c1
Author: Vladimir N. Makarov 
Date:   Fri Oct 8 10:16:09 2021 -0400

[PR102627] Use at least natural mode during splitting hard reg live range

In the PR test case SImode was used to split live range of cx on x86-64
because it was the biggest mode for this hard reg in the function.  But
all 64-bits of cx contain structure members.  We need always to use at
least
natural mode of hard reg in splitting to fix this problem.

gcc/ChangeLog:

PR rtl-optimization/102627
* lra-constraints.c (split_reg): Use at least natural mode of hard
reg.

gcc/testsuite/ChangeLog:

PR rtl-optimization/102627
* gcc.target/i386/pr102627.c: New test.

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #7 from TC  ---
(In reply to Barry Revzin from comment #6)
> The "real" answer is allowing constexpr placement new, but that obviously
> doesn't help you right now.
> 
> But I think the helpful answer is that you can add a constructor to your
> storage like storage(init_from_invoke_t, Args&&... args) that initializes
> the underlying value from invoke((Args&&)args...), and then
> construct_at(, init_from_invoke, [&]() -> decltype(auto) { return
> *i; }).
> 
> Something like that?

Yes. Something at that level of generality will be needed for the new
optional::transform, so it seems the better approach.

In my proof-of-concept implementation (which didn't have that concern), I used
something tailored to this specific case, along the lines of 

struct __deref_tag {};

template
struct __cache_wrapper {
template
constexpr __cache_wrapper(__deref_tag, const _Iter& __i)
: __t(*__i) {}
_Tp __t;
};

and then stored a __non_propagating_cache<__cache_wrapper>>
__cache, so that emplace-deref(i) is __cache.emplace(__deref_tag{}, i);

[Bug c++/102748] New: static_assert on concept leads to undefined reference

[raffael at casagrande dot ch via Gcc-bugs]

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

Bug ID: 102748
   Summary: static_assert on concept leads to undefined reference
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raffael at casagrande dot ch
  Target Milestone: ---

Try to compile and link the following simple program with `-std=c++20`:
---
template 
auto ForEachGuided(RANGE&& range, CALLABLE&& c) {
  range.begin();
}

struct RandomAccessRangeAT {
  void begin() const noexcept;
};

template 
concept FESpaceFactory = requires(const FE_SPACE_FACTORY& fe_space_factory,
  const RandomAccessRangeAT& range) {
  {fe_space_factory(range)};
};

int main() {
  auto fes_provider = [](auto&& range) {
ForEachGuided(range, []() {});
  };
  static_assert(FESpaceFactory);
}
--

Compilation will work, but during linking we get the error message:
"undefined reference to `RandomAccessRangeAT::begin() const'"

As soon as we apply some optimization flags, the linking error vanishes.
Also clang doesn't have this problem...

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Barry Revzin  ---
The "real" answer is allowing constexpr placement new, but that obviously
doesn't help you right now.

But I think the helpful answer is that you can add a constructor to your
storage like storage(init_from_invoke_t, Args&&... args) that initializes the
underlying value from invoke((Args&&)args...), and then construct_at(,
init_from_invoke, [&]() -> decltype(auto) { return *i; }).

Something like that?

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Patrick Palka from comment #1)
> > We might first need to implement P2231 (for constexpr optional) before this
> > function can be properly constexpr.
> 
> Implemented in r12-4389

Yay, thanks!  I thought this would be enough to straightforwardly make
emplace-deref constexpr, but I ran into an unrelated wrinkle.  During constexpr
evaluation we can't use placement new to initialize the contained value
directly from *__i and instead have to use the equivalent of
construct_at(, *__i), but the latter incurs an extra move due to the
temporary materialization of *__i, which is contrary to the effects of
emplace-deref ([range.nonprop.cache]/1.6):

  Calls reset().  Then initializes the contained value as if
direct-non-list-initializing an object of type T with the argument *i.

Am I missing something or is it not possible to perform this direct-init in the
constexpr case?

[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Илья Шипицин  ---
I came to this situation using wrong powershell approach. I found all "gcda"
and merged them into single string. Powershell executed "gcov" and passed 1
(!!) argument as concatenated string.

Actually, if gcov cannot find some required file, it should return "1" (or
other non zero).

[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-14
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I've got your point.
The question is if we should return 1 if we can't open .gcda (or .gcno) file
for one input file, or for all of them?

Note one can execute gcov file multiple filenames as arguments.

[Bug gcov-profile/102747] New: gcov returns 0 when invoked on gcda generated by previous gcc version

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 102747
   Summary: gcov returns 0 when invoked on gcda generated by
previous gcc version
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

we use several gcc versions, so we do not know whether particular "gcda" was
produced by gcc-N or gcc-M.

for example, mixing gcc11 and gcc12 together:

running gcov-12 on gcda produced by gcc-11

gcov a-hello.gcda
a-hello.gcno:version 'B12R', prefer 'B20 '
a-hello.gcno:no functions found
a-hello.gcda:version 'B12R', prefer version 'B20 '
No executable lines
$ echo $?
0
$ 



I'm fine with error itself, it is expected. However I beleive exit status
should be "1"

[Bug ipa/102557] [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access) since r12-3202-gf5ff3a8ed4ca9173

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
Can we close it as fixed now?

[Bug gcov-profile/102746] New: gcov returns 0 un erroneuos incovation

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 102746
   Summary: gcov returns 0 un erroneuos incovation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

repro steps:

several source files (for example, two)

main.c:

void hello(void);

void main(void){
 hello();
}

hello.c:

#include 

void hello(void) {
   printf("hello"); 
}


..

build with coverage (using master branch gcc)

gcc --coverage -o hello main.c hello.c



execute

./hello



executing "gcov" in erroneous way 

gcov "hello-hello.gcda  hello-main.gcda"
hello-hello.gcda  hello-main.gcno:cannot open notes file
hello-hello.gcda  hello-main.gcda:cannot open data file, assuming not executed
No executable lines

however, exit status is "0"

$ echo $?
0
$



it is hard to identify error situation when exit status is "0". I beleive it
should be "1" under such circumstances

[Bug libstdc++/102743] [12 Regression] build failure for i686-w64-mingw32 target because of patch yesterday

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC|jwakely at redhat dot com  |
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Jonathan Wakely  ---
Fixed - sorry about that.

[Bug fortran/102745] New: CLASS → TYPE check fails after RESHAPE

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102745
   Summary: CLASS → TYPE check fails after RESHAPE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Found when working on PR102689

Expected:
* 'CLASS(t)' in the first error message
* an error for passing CLASS(t) to TYPE(t2) in the call with RESHAPE.


implicit none (type, external)
type t
end type t
type, extends(t) :: t2
  integer :: i
end type t2

class(t), allocatable :: A(:), B(:,:,:)

allocate (t2 :: A(100), B(10,10,1))

call bar(A)  ! Rejected (with slightly odd message: Error: Type mismatch in
argument ‘x’ at (1); passed CLASS(__class_MAIN___T_1_0a) to TYPE(t2)
call bar(reshape(B, [size(B)]))  ! Wrongly accepted

contains

subroutine bar(x)
  type(t2), intent(in) :: x(:)
end
end

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[vajdaz at protonmail dot com via Gcc-bugs]

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

--- Comment #23 from Zoltan Vajda  ---
(In reply to Uroš Bizjak from comment #20)
> (In reply to jos...@codesourcery.com from comment #16)
> > I don't think this bug is anything to do with -fsignaling-nans, for the 
> > same reason as applies to bug 58416 and bug 71460.
> 
> The situation is hopeless from the beginning. Please consider this testcase:
> 
> --cut here--
> #include 
> #include 
> 
> double
> __attribute__((noinline,noipa))
> foo (double a, double b, char c)
> {
>   return c ? a : b;
> }
> 
> int main ()
> {
>   double a = __builtin_nans ("");
>   double b = 42.0;
> 
>   feclearexcept (FE_INVALID);
>   foo (a, b, 0);
>   if (fetestexcept (FE_INVALID))
> __builtin_abort ();
> 
>   return 0;
> }
> --cut here--
> 
> $ gcc -O2 -m32 -march=i686 -lm fcmov.c
> $ ./a.out 
> Aborted (core dumped)
> $ gcc -O2 -m32 -march=i386 -lm fcmov.c
> $ ./a.out 
> Aborted (core dumped)
> 
> Because the compiler generates:
> 
> foo:
> cmpb$0, 20(%esp)
> fldl12(%esp)
> fldl4(%esp)
> fcmove  %st(1), %st
> fstp%st(1)
> ret
> 
> in the former case and:
> 
> foo:
> fldl4(%esp)
> fldl12(%esp)
> cmpb$0, 20(%esp)
> jne .L4
> fstp%st(1)
> jmp .L2
> .L4:
> fstp%st(0)
> .L2:
> ret
> 
> in the later.
> 
> Since the ABI specifies the operand size on the stack, the above code will
> always trap.

There is a small but very important difference between this example and my
example.

In this example the compiler may assume that objects 'a' and 'b' both are
initialized at the beginning of the function execution (calling a function with
uninitialized input by value would be UB). Therefore you may argue that
accessing both of them is fine. If you feed foo() with SNaN through 'a', it
will always abort, independent of 'c'.

In my example there is an uninitialized object when the function execution
starts (local variable 'result') , and at C++ level there is no execution path
that would result in accessing this object before initialization. In spite of
this, at ASM level, the object is accessed before initialization. I don't see
any argument that makes this access valid. My example function aborts randomly,
independent of the input. The behavior depends on some random data on the
stack.

[Bug libstdc++/102743] [12 Regression] build failure for i686-w64-mingw32 target because of patch yesterday

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:5e3f88838994b67580594c4679c839fff7cdeba0

commit r12-4404-g5e3f88838994b67580594c4679c839fff7cdeba0
Author: Jonathan Wakely 
Date:   Thu Oct 14 13:20:57 2021 +0100

libstdc++: Fix brainwrong in path::_S_convert(T) [PR102743]

This function was supposed to check whether the parameter's value type
is the same as path::value_type, and therefore needs no conversion.
Instead it checks whether the parameter is the same as its own value
type, which is never true. This means we incorrectly return a string
view for the case where T is path::string_type, instead of just
returning the string itself. The only place that happens is
path::_S_convert_loc for Windows, where we call _S_convert with a
std::wstring rvalue.

This fixes the condition in _S_convert(T).

libstdc++-v3/ChangeLog:

PR libstdc++/102743
* include/bits/fs_path.h (path::_S_convert(T)): Fix condition
for returning the same string unchanged.

[Bug ipa/102557] [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access) since r12-3202-gf5ff3a8ed4ca9173

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r12-4401-gfecd145359fc981beb2802f746190227c5cc010a
Author: Jan Hubicka 
Date:   Thu Oct 14 15:48:01 2021 +0200

Fix ICE in insert_access.

gcc/ChangeLog:

PR ipa/102557
* ipa-modref-tree.h (modref_access_node::update2):
Also check that parm_offset is unchanged.
(modref_ref_node::insert_access): Fix updating of
parameter.

[Bug tree-optimization/102744] New: [12 regression] -O2 vectorization causes Wzero-length-array-bounds-2.c to fail on arc-elf

[law at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102744
   Summary: [12 regression] -O2 vectorization causes
Wzero-length-array-bounds-2.c to fail on arc-elf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Starting with the patch to vectorize at -O2,
gcc.dg/Wzero-length-array-bounds-2.c has started failing on arc-elf.  We're
getting an additional diagnostic:

/home/jlaw/test/gcc/gcc/testsuite/gcc.dg/Wzero-length-array-bounds-2.c:90:17:
warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]

This may well be the same underlying issue as the other problems we're chasing
in this space, if that turns out to be the case, just mark this is a duplicate.
 I haven't debugged it in any notable way.  It should reproduce with just a
cross compiler.

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

commit r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
Author: Richard Biener 
Date:   Thu Oct 14 09:00:25 2021 +0200

tree-optimization/102659 - really avoid undef overflow in if-conversion

This plugs the remaining hole of POINTER_PLUS_EXPR with undefined
overflow.  Unfortunately we have to go through some lengths to
not put invariant conversions into the loop body since that confuses
the vectorizers gather/scatter discovery which relies on identifying
an invariant component of plus and minus expressions.  We can
emit those in the loop preheader but then we have to accept that
being non-empty when looking for the LOOP_VECTORIZED internal
function call in the vectorizer.

2021-10-14  Richard Biener  

PR tree-optimization/102659
* tree-if-conv.c (if_convertible_gimple_assign_stmt_p): Also
rewrite pointer typed undefined overflow operations.
(predicate_statements): Likewise.  Make sure to emit invariant
conversions in the preheader.
* tree-vectorizer.c (vect_loop_vectorized_call): Look through
non-empty preheaders.
* tree-data-ref.c (dr_analyze_indices): Strip useless
conversions to the MEM_REF base type.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Martin Sebor from comment #3)
> Simply initializing the variable as in the patch below avoids the warning. 
> The control flow in the code is sufficiently opaque to make it worthwhile
> from a readability point irrespective of whether or not the variable can, in
> fact, be used uninitialized.
> 
> index e50d3fc3b62..c7f0a405ff6 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -199,7 +199,7 @@ stack_region_maybe_used_p (poly_uint64 lower_bound,
> poly_uint64 upper_bound,
>  static void
>  mark_stack_region_used (poly_uint64 lower_bound, poly_uint64 upper_bound)
>  {
> -  unsigned HOST_WIDE_INT const_lower, const_upper;
> +  unsigned HOST_WIDE_INT const_lower, const_upper = 0;
>const_lower = constant_lower_bound (lower_bound);
>if (upper_bound.is_constant (_upper))
>  for (unsigned HOST_WIDE_INT i = const_lower; i < const_upper; ++i)
I disagree that this is better for readability.  Initialising to zero
implies that the zero can reach code dominated by is_constant returning
true.  In other words, it implies that the zero might be used and that
initialising to a different value would give different behaviour,
which in turn raises the question why 0 is the right choice.

The control flow for is_constant is just:

  if (is_constant ())
{
  *const_value = this->coeffs[0];
  return true;
}
  return false;

where it is clear that const_value is assigned to iff the
function returns true.  If we can't handle this kind of
construct then I think we should try to punt on it.

It doesn't seem all that different from what would happen
for std::optional> after SRA, where AIUI
the second array element would be uninitialised if
_M_engaged is false.

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-4395-ga311163fd81babd6116e2856f4551c3ca13d8914
Author: Aldy Hernandez 
Date:   Thu Oct 14 10:28:39 2021 +0200

Do not call range_on_path_entry for SSAs defined within the path

In the path solver, when requesting the range of an SSA for which we
know nothing, we ask the ranger for the range incoming to the path.
We do this by asking for all the incoming ranges to the path entry
block and unioning them.

The problem here is that we're asking for a range on path entry for an
SSA which *is* defined in the path, but for which we know nothing
about:

some_global.1_2 = some_global;
_3 = (char) some_global.1_2;

This request is causing us to ask for range_on_edge of _3 on the
incoming edges to the path.  This is a bit of nonsensical request
because _3 isn't live on entry to the path, so ranger correctly
returns UNDEFINED.  The proper thing is to avoid asking this in the
first place.

I have added a relevant assert, since it doesn't make sense to call
range_on_path_entry for SSAs defined within the path.

Tested on x86-64 Linux.

PR tree-optimization/102736

gcc/ChangeLog:

PR tree-optimization/102736
* gimple-range-path.cc (path_range_query::range_on_path_entry):
Assert that the requested range is defined outside the path.
(path_range_query::ssa_range_in_phi): Do not call
range_on_path_entry for SSA names that are defined within the
path.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr102736.c: New test.

[Bug libstdc++/102743] [12 Regression] build failure for i686-w64-mingw32 target because of patch yesterday

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-10-14

[Bug libstdc++/102743] [12 Regression] build failure for i686-w64-mingw32 target because of patch yesterday

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|build failure for   |[12 Regression] build
   |i686-w64-mingw32 target |failure for
   |because of patch yesterday  |i686-w64-mingw32 target
   ||because of patch yesterday
   Keywords||build
   Target Milestone|--- |12.0

[Bug libstdc++/102743] New: build failure for i686-w64-mingw32 target because of patch yesterday

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 102743
   Summary: build failure for i686-w64-mingw32 target because of
patch yesterday
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51599=edit
error message

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #22 from rguenther at suse dot de  ---
On Thu, 14 Oct 2021, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
> 
> --- Comment #20 from Uroš Bizjak  ---
> (In reply to jos...@codesourcery.com from comment #16)
> > I don't think this bug is anything to do with -fsignaling-nans, for the 
> > same reason as applies to bug 58416 and bug 71460.
> 
> The situation is hopeless from the beginning. Please consider this testcase:
> 
> --cut here--
> #include 
> #include 
> 
> double
> __attribute__((noinline,noipa))
> foo (double a, double b, char c)
> {
>   return c ? a : b;
> }
> 
> int main ()
> {
>   double a = __builtin_nans ("");
>   double b = 42.0;
> 
>   feclearexcept (FE_INVALID);
>   foo (a, b, 0);
>   if (fetestexcept (FE_INVALID))
> __builtin_abort ();
> 
>   return 0;
> }
> --cut here--
> 
> $ gcc -O2 -m32 -march=i686 -lm fcmov.c
> $ ./a.out 
> Aborted (core dumped)
> $ gcc -O2 -m32 -march=i386 -lm fcmov.c
> $ ./a.out 
> Aborted (core dumped)
> 
> Because the compiler generates:
> 
> foo:
> cmpb$0, 20(%esp)
> fldl12(%esp)
> fldl4(%esp)
> fcmove  %st(1), %st
> fstp%st(1)
> ret
> 
> in the former case and:
> 
> foo:
> fldl4(%esp)
> fldl12(%esp)
> cmpb$0, 20(%esp)
> jne .L4
> fstp%st(1)
> jmp .L2
> .L4:
> fstp%st(0)
> .L2:
> ret
> 
> in the later.
> 
> Since the ABI specifies the operand size on the stack, the above code will
> always trap.

Indeed and since those loads from the argument space appear as registers
in GIMPLE there's nothing avoiding "speculative" accesses to those so
the issue for argument slots are much harder to mitigate.  I also think
that RTL expansion happily puts those loads in the prologue rather
than next to the first use.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #21 from Uroš Bizjak  ---
(In reply to Zoltan Vajda from comment #19)
> The problem does not only apply for conditional moves! I can turn on sse,
> for example.
> 
> https://gcc.godbolt.org/z/jP3Kne8T5
> 
> Then the problematic code with the conditional move disappears, but I have a
> similar speculative fld problem in another situation.
> 
> .L10:
> inc esi
> cmp edi, esi
> jne .L11
> testbl, bl<= test input variable 'b'
> fld QWORD PTR [ebp-24]<= load of (maybe) uninitialized
> 'result'
> je  .L24  <= jump based on value of 'b'

This one is fixed at least in gcc-10.

.L18:
testb   %bl, %bl
je  .L8
fldl-24(%ebp)
addl$20, %esp
popl%ebx

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Uroš Bizjak  ---
(In reply to jos...@codesourcery.com from comment #16)
> I don't think this bug is anything to do with -fsignaling-nans, for the 
> same reason as applies to bug 58416 and bug 71460.

The situation is hopeless from the beginning. Please consider this testcase:

--cut here--
#include 
#include 

double
__attribute__((noinline,noipa))
foo (double a, double b, char c)
{
  return c ? a : b;
}

int main ()
{
  double a = __builtin_nans ("");
  double b = 42.0;

  feclearexcept (FE_INVALID);
  foo (a, b, 0);
  if (fetestexcept (FE_INVALID))
__builtin_abort ();

  return 0;
}
--cut here--

$ gcc -O2 -m32 -march=i686 -lm fcmov.c
$ ./a.out 
Aborted (core dumped)
$ gcc -O2 -m32 -march=i386 -lm fcmov.c
$ ./a.out 
Aborted (core dumped)

Because the compiler generates:

foo:
cmpb$0, 20(%esp)
fldl12(%esp)
fldl4(%esp)
fcmove  %st(1), %st
fstp%st(1)
ret

in the former case and:

foo:
fldl4(%esp)
fldl12(%esp)
cmpb$0, 20(%esp)
jne .L4
fstp%st(1)
jmp .L2
.L4:
fstp%st(0)
.L2:
ret

in the later.

Since the ABI specifies the operand size on the stack, the above code will
always trap.

[Bug testsuite/102735] privatization-1-compute.c results in both XFAIL and PASS

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|xfail   |
 Status|UNCONFIRMED |ASSIGNED
 CC||tschwinge at gcc dot gnu.org
   Last reconfirmed||2021-10-14
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
ACK, mine.

Ought to be resolved by my proposed
 "Make
sure that we get unique test names if several DejaGnu directives refer to the
same line", which I shall ping once again.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[vajdaz at protonmail dot com via Gcc-bugs]

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

--- Comment #19 from Zoltan Vajda  ---
(In reply to Uroš Bizjak from comment #18)
> The following patch fixes the PR, see the comment inline:
> 
> --cut here--
> diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> index 6e2b7920d2b..b87490fe544 100644
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> @@ -4094,6 +4094,15 @@ ix86_expand_fp_movcc (rtx operands[])
>   && !TARGET_64BIT))
>  return false;
>  
> +  /* Disable SFmode and DFmode x87 FCMOV with trapping math
> + to prevent speculative load using FLDL/FLDS from uninitialized
> + memory location, which can contain sNaN value.  FLDL/FLDS traps
> + on sNaN, see PR93934.  */
> +
> +  if ((mode == SFmode || mode == DFmode)
> +  && flag_trapping_math)
> +return false;
> +
>/* The floating point conditional move instructions don't directly
>   support conditions resulting from a signed integer comparison.  */
>  
> --cut here--

The problem does not only apply for conditional moves! I can turn on sse, for
example.

https://gcc.godbolt.org/z/jP3Kne8T5

Then the problematic code with the conditional move disappears, but I have a
similar speculative fld problem in another situation.

.L10:
inc esi
cmp edi, esi
jne .L11
testbl, bl<= test input variable 'b'
fld QWORD PTR [ebp-24]<= load of (maybe) uninitialized 'result'
je  .L24  <= jump based on value of 'b'
add esp, 20
pop ebx
pop esi
pop edi
pop ebp
ret
.L24:
fstpst(0)
.L8:
fld QWORD PTR .LC1
add esp, 20
pop ebx
pop esi
pop edi
pop ebp
ret

[Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Tobias Burnus  ---
Actually, it prints the line number at the call site. Thus, there is probably
no need for adding the name of callee.

However, related to the fsym/proc_name passing:

Currently, the callers in gfc_conv_procedure_call do not make use of the
avoid-copy-in feature by not passing the (add) contiguous (check) = true flag
to gfc_conv_subref_array_arg.

There are some testcase which check that the copyin does not happen when being
contiguous, but I think those are not used for dummy arguments that are
(CONTIGUOUS) assumed-shape/assumed-rank arrays.

Side note: To get that working, it requires the gfc_conv_subref_array_arg
changes of the patch at
  https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.html
which might be the reason for not doing it currently.

 * * *

Another observation, which might be unrelated or related: TRANSFORM can be
implemented by just swapping the first and second dimension (see
trans-intrinsic.s + trans-array.c, search for ISYM_TRANSFORM).

Currently, GCC for a call makes it contiguous – which it could be also
transferred as is (noncontiguous). I am not sure what's better, though.

Testcase: gfortran.dg/c-interop/fc-descriptor-7.f90 also part of the patch 
  https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.html
Search for the comments regarding the implementation choice.

As testing shows, calling a Fortran procedure does the copy in (as mentioned)
but with my patch, calling a BIND(C) procedure passes the array as
noncontiguous array.
Thus, I wonder whether it is also related to the gfc_conv_subref_array_arg.

 * * *

gfc_conv_subref_array_arg: While the above mentioned patch adds support for a
contiguous check with descriptors, I lack an optional + contiguous check
testcase.

However, that can only be added once gfc_conv_subref_array_arg is called with
contiguous=true - or in any other way with type = descriptor type.

[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Aldy Hernandez  ---
(In reply to Aldy Hernandez from comment #8)
> On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
> >
> > --- Comment #7 from Andrew Pinski  ---
> > Because:
> >   if (d_11 > 1)
> > goto ; [59.00%]
> >   else
> > goto ; [41.00%]
> >
> >[local count: 391808389]:
> >
> >[local count: 955630225]:
> >   # iftmp.1_6 = PHI <0(3), 2(4)>
> >
> > If the phi node was removed, the original al condition for d_11 > 1 would
> > be
> > remove.
> >
> 
> As the IL stands, the 3->5 edge has relevant range information.  If the IL
> should be different at this point, there is no way the threader can know
> this.

Note that I'm not against a cleanup pass running before as you suggested, or
perhaps whomever made the PHI redundant could also clean up the PHI itself. 
I'm just merely saying that the threader is working as expected with the IL at
hand.

Also, if we did have cleaner IL, we could probably tweak the threader to elide
the call to foo() earlier.  That is, without having to resort to help from the
RTL optimizers.

In this testcase we could probably divine that the combination of the
truncating cast and the bitwise AND is showing that a.4_2 can't have both the
lower bits set and cleared at the same time.  I'm not sure it's worth tweaking
the path solver for this, but it's definitely worth exploring.

As usual, thanks for narrowing all these bug reports.  It makes a big
difference, and your presence during bug hunting season is always a big plus.

[Bug target/102352] Add -mstack-protector-guard=... for arm32

[ardb at kernel dot org via Gcc-bugs]

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

Ard Biesheuvel  changed:

   What|Removed |Added

 CC||ardb at kernel dot org

--- Comment #1 from Ard Biesheuvel  ---
For 32-bit ARM, it would be useful to have

   -mstack-protector-guard=tls
   -mstack-protector-guard-offset=

and use gen_load_tp_hard() internally. As we also use the TLS register to index
other per-task data (using __builtin_thread_pointer()), we get better code this
way, since the compiler understands that there is no need to load the TLS
register multiple times in the same function.

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 51598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51598=edit
proposed patch in testing

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Aldy Hernandez  ---
Here are some debugging tips for when I'm not around ;-).

When the jump threader is suspected, I find it useful to do some bisecting to
find the actual jump thread that is causing the problem.  Note that sometimes
it's a combination of threaded paths, but most of the time it's just one.

First I make sure the problem goes away without jump threading:

abulafia:~/bld/t/gcc$ ./xgcc -B./ a.c -O2 -fno-thread-jumps
abulafia:~/bld/t/gcc$ ./a.out
abulafia:~/bld/t/gcc$ 

And then I start playing -fdbg-cnt games, which ultimately led me to:

abulafia:~/bld/t/gcc$ ./xgcc -B./ a.c -O2 -fdbg-cnt=registered_jump_thread:4-4
-fdump-tree-all-details-threading
***dbgcnt: lower limit 4 reached for registered_jump_thread.***
***dbgcnt: upper limit 4 reached for registered_jump_thread.***
abulafia:~/bld/t/gcc$ ./a.out
Aborted (core dumped)

The 4th jump threaded path reproduces the problem.

I then look at the dump file with the dbgcnt message (*.vrp-thread1):

***dbgcnt: lower limit 4 reached for registered_jump_thread.***
***dbgcnt: upper limit 4 reached for registered_jump_thread.***
  [4] Registering jump thread: (3, 5) incoming edge;  (5, 7) joiner (7, 8)
normal (8, 9) nocopy; 

The block immediately preceding this message is the path solver in action:

*** path_range_query **
 Registering value_relation (path_oracle) (_4 < a.4_14) (bb3)
 Registering value_relation (path_oracle) (_3 == iftmp.3_15) (bb3)
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb3)

path_range_query: compute_ranges for path: BB 3, BB 5, BB 7
range_defined_in_block (BB5) for iftmp.3_15 is char [0, 0]
range_defined_in_block (BB5) for _5 is unsigned char [0, 0]
range_defined_in_block (BB5) for iftmp.3_15 is char [0, 0]
range_defined_in_block (BB7) for iftmp.6_13 is unsigned char [0, 0]

Path is (length=3):

=== BB 3 
Imports: b.1_2  a.4_14  
Exports: b.1_2  _3  _4  a.4_14  
 _3 : b.1_2(I)  
 _4 : b.1_2(I)  _3  
 [local count: 1073741824]:
  L:
d.0_1 = d;
b.1_2 = b;
_3 = (char) b.1_2;
_4 = (int) _3;
a.4_14 = a;
if (_4 >= a.4_14)
  goto ; [50.00%]
else
  goto ; [50.00%]

_4 : int [-128, 127]
3->4  (T) _4 :  int [-128, 127]
3->4  (T) a.4_14 :  int [-INF, 127]
3->5  (F) _4 :  int [-128, 127]
3->5  (F) a.4_14 :  int [-127, +INF]

=== BB 5 
Imports: d.0_1  
Exports: d.0_1  
d.0_1   int VARYING
b.1_2   int VARYING
 [local count: 1073741824]:
# iftmp.3_15 = PHI <_3(3), 0(4)>
_5 = (unsigned char) iftmp.3_15;
if (d.0_1 == 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

5->6  (T) d.0_1 :   int [0, 0]
5->7  (F) d.0_1 :   int [-INF, -1][1, +INF]
etc
etc
etc

The solver decided that iftmp.3_15 is [0, 0] along the path:

  range_defined_in_block (BB5) for iftmp.3_15 is char [0, 0]

This makes absolutely no sense.  The iftmp.3_15 SSA is _3 on the 3->5 edge, and
we have no knowledge of _3 in BB3.  Well, unless we had some global range for
_3 from a previous *vrp pass, but that's not the case here.

The problem here is that since we didn't have a range so far for _3, we decided
to ask for the ranger's range on entry to the path.  This is incorrect, because
_3 is not live on entry.  Assuming it is had us calling range_on_edge on each
incoming edge to BB3, which ranger was happy to return UNDEFINED for.  This was
an oversight.  We should never call range_on_path_entry for things defined in
the path.  The other call to range_on_path_entry had an appropriate gate.  The
one when calculating PHIs did not.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Uroš Bizjak  ---
The following patch fixes the PR, see the comment inline:

--cut here--
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 6e2b7920d2b..b87490fe544 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -4094,6 +4094,15 @@ ix86_expand_fp_movcc (rtx operands[])
  && !TARGET_64BIT))
 return false;

+  /* Disable SFmode and DFmode x87 FCMOV with trapping math
+ to prevent speculative load using FLDL/FLDS from uninitialized
+ memory location, which can contain sNaN value.  FLDL/FLDS traps
+ on sNaN, see PR93934.  */
+
+  if ((mode == SFmode || mode == DFmode)
+  && flag_trapping_math)
+return false;
+
   /* The floating point conditional move instructions don't directly
  support conditions resulting from a signed integer comparison.  */

--cut here--

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp by r12-3903

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #2)
> works with  --disable-tree-vrp-thread1
> 
> 
> Looking at the  .vrp-thread1 listing, I see a lot of
> 
>  Registering value_relation (_4 >= a.4_14) on (3->4)
>  Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb4)
>   [1] Registering jump thread: (4, 5) incoming edge;  (5, 7) joiner (7, 8)
> normal (8, 9) nocopy;
>  Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
>  Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
>   [2] Registering jump thread: (6, 7) incoming edge;  (7, 9) joiner;
>  Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
>   [3] Registering jump thread: (6, 7) incoming edge;  (7, 8) joiner (8, 9)
> nocopy;
>  Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
>  Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
>  Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
>  Registering value_relation (path_oracle) (_4 < a.4_14) (bb3)
>  Registering value_relation (path_oracle) (_3 == iftmp.3_15) (bb3)
>  Registering value_relation (path_oracle) (_4 < a.4_14) (bb3)
>  Registering value_relation (path_oracle) (_3 == iftmp.3_15) (bb3)
>  Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb3)

What you're seeing here is the verbosity out of path_oracle::register_relation
for each candidate path as it's being tried.

What I've been doing is avoiding dumping the details of the path solver in
action, unless TDF_THREADING, but the above message is coming from the path
oracle itself, which is keyed off of TDF_DETAILS.

This is a bit confusing.  Perhaps we should silence these messages unless
TDF_THREADING?  What do you think?

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jonathan Wakely  ---
Thanks for noticing I missed it.

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:3bf56cdf5ec5e07ea34e6be0110ab8fc76641d87

commit r11-9153-g3bf56cdf5ec5e07ea34e6be0110ab8fc76641d87
Author: Jonathan Wakely 
Date:   Thu Jul 22 18:49:57 2021 +0100

libstdc++: Fix non-default constructors for hash containers [PR101583]

When I added the new mixin to _Hashtable, I forgot to explicitly
construct it in each non-default constructor. That means you can't
use any constructors unless all three of the hash function, equality
function, and allocator are all default constructible.

libstdc++-v3/ChangeLog:

PR libstdc++/101583
* include/bits/hashtable.h (_Hashtable): Replace mixin with
_Enable_default_ctor. Construct it explicitly in all
non-forwarding, non-defaulted constructors.
* testsuite/23_containers/unordered_map/cons/default.cc: Check
non-default constructors can be used.
* testsuite/23_containers/unordered_set/cons/default.cc:
Likewise.

(cherry picked from commit 8ed6cfbbee74ec9e03f2558b9c36f61dd7d4dcfd)

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Patrick Palka from comment #1)
> We might first need to implement P2231 (for constexpr optional) before this
> function can be properly constexpr.

Implemented in r12-4389

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
Oops, yes, I thought I'd included this in my backports. Doing it now ...

[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union

[curdeius at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Curdeius Curdeius  ---
For other users with this problem, a workaround is to use a named struct. So
here, it would look like:
```
typedef struct {
const void* content;
} put_t;

typedef struct {
union {
put_t put; // named struct
};
} op_t;

op_t f(const char* alias) {
return op_t{
.put =
put_t{ // named explicitly
.content = alias,
},
};
}
```

[Bug libbacktrace/102742] New: ERROR: descriptor 3 still open after tests complete

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102742
   Summary: ERROR: descriptor 3 still open after tests complete
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

>From time to time, I see this failure when I run tests when I run e.g.

make -j16 check -k RUNTESTFLAGS="dg.exp=pr64637.c"

ERROR: descriptor 3 still open after tests complete
ERROR: descriptor 4 still open after tests complete

However, running with -j1 it's gone. I'm pretty sure these FDs belong to
jobserver and I can prove it with:

diff --git a/libbacktrace/btest.c b/libbacktrace/btest.c
index 9f9c03babf3..f9be9a26db4 100644
--- a/libbacktrace/btest.c
+++ b/libbacktrace/btest.c
@@ -482,6 +482,9 @@ check_open_files (void)
 int
 main (int argc ATTRIBUTE_UNUSED, char **argv)
 {
+  const char *makeflags = getenv ("MAKEFLAGS");
+  fprintf (stderr, "XXX: %s\n", makeflags);
+
   state = backtrace_create_state (argv[0], BACKTRACE_SUPPORTS_THREADS,
  error_callback_create, NULL);

Then I see:

XXX: kw -j16 --jobserver-auth=3,4

in test-suite.log.

[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
*** Bug 102741 has been marked as a duplicate of this bug. ***