date:20230424

[Bug c/109619] New: ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc

2023-04-24 Thread anbu1024.me at gmail dot com via Gcc-bugs

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

Bug ID: 109619
   Summary: ICE: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in fold_const_call_1, at
fold-const-call.cc
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ gcc --version
gcc (GCC) 13.0.1 20230219 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ cat 4.c 

void foo(void *a1, const void *a2, long unsigned int a3)
{
  void *x = __builtin_memcpy(a1, a2, a3);
  int *a3 = __builtin_memmove(a1, a2, a3);
}



$ gcc 4.c 
4.c: In function ‘foo’:
4.c:5:8: error: ‘a3’ redeclared as different kind of symbol
5 |   int *a3 = __builtin_memmove(a1, a2, a3);
  |^~
4.c:2:54: note: previous definition of ‘a3’ with type ‘long unsigned int’
2 | void foo(void *a1, const void *a2, long unsigned int a3)
  |~~^~
4.c:4:13: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc:1800
4 |   void *x = __builtin_memcpy(a1, a2, a3);
  | ^~~~
0x840637 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-13-20230219/gcc/tree.cc:8959
0x776846 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-13-20230219/gcc/tree.h:3653
0x776846 fold_const_call_1
../../gcc-13-20230219/gcc/fold-const-call.cc:1800
0x776846 fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*,
tree_node*)
../../gcc-13-20230219/gcc/fold-const-call.cc:1903
0xa66a98 fold_builtin_3
../../gcc-13-20230219/gcc/builtins.cc:9851
0xa66a98 fold_builtin_n
../../gcc-13-20230219/gcc/builtins.cc:9932
0xc97037 gimplify_call_expr
../../gcc-13-20230219/gcc/gimplify.cc:3684
0xc88500 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16333
0xc9a465 gimplify_modify_expr
../../gcc-13-20230219/gcc/gimplify.cc:6153
0xc879e1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16361
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc97d34 gimplify_and_add(tree_node*, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:492
0xc97d34 gimplify_decl_expr
../../gcc-13-20230219/gcc/gimplify.cc:1936
0xc88132 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16558
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc88c38 gimplify_statement_list
../../gcc-13-20230219/gcc/gimplify.cc:2019
0xc88c38 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16806
0xc8a316 gimplify_stmt(tree_node**, gimple**)
../../gcc-13-20230219/gcc/gimplify.cc:7219
0xc8aa47 gimplify_bind_expr
../../gcc-13-20230219/gcc/gimplify.cc:1430
0xc87c95 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-13-20230219/gcc/gimplify.cc:16562
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/109618] New: ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc

2023-04-24 Thread anbu1024.me at gmail dot com via Gcc-bugs

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

Bug ID: 109618
   Summary: ICE: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in
generic_simplify_CONVERT_EXPR, at generic-match.cc
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

int foo()
{
  const unsigned int var_1 = 2;

  char var_5[var_1];

  int var_1[10];

  return sizeof(var_5);
}




$ gcc --version
gcc (GCC) 13.0.1 20230219 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc test.c  
test.c: In function ‘foo’:
test.c:8:7: error: conflicting type qualifiers for ‘var_1’
8 |   int var_1[10];
  |   ^
test.c:4:22: note: previous definition of ‘var_1’ with type ‘unsigned int’
4 |   const unsigned int var_1 = 2;
  |  ^
test.c :10:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at
generic-match.cc:28499
   10 |   return sizeof(var_5);
  |   ^~
0x840637 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-13-20230219/gcc/tree.cc:8959
0x8abac0 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-13-20230219/gcc/tree.h:3653
0x8abac0 generic_simplify_CONVERT_EXPR
gcc-13-20230219-build/gcc/generic-match.cc:28499
0xbf6848 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc-13-20230219/gcc/fold-const.cc:9341
0xbf8079 fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc-13-20230219/gcc/fold-const.cc:13778
0x9429bb c_expr_sizeof_expr(unsigned int, c_expr)
../../gcc-13-20230219/gcc/c/c-typeck.cc:3096
0x97ef46 c_parser_sizeof_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:8910
0x97ef46 c_parser_unary_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:8803
0x97fdef c_parser_cast_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:8672
0x9800df c_parser_binary_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:8440
0x98154b c_parser_conditional_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:8138
0x981d24 c_parser_expr_no_commas
../../gcc-13-20230219/gcc/c/c-parser.cc:8052
0x981fd1 c_parser_expression
../../gcc-13-20230219/gcc/c/c-parser.cc:11379
0x982717 c_parser_expression_conv
../../gcc-13-20230219/gcc/c/c-parser.cc:11419
0x97858b c_parser_statement_after_labels
../../gcc-13-20230219/gcc/c/c-parser.cc:6674
0x9798e4 c_parser_compound_statement_nostart
../../gcc-13-20230219/gcc/c/c-parser.cc:6296
0x99f164 c_parser_compound_statement
../../gcc-13-20230219/gcc/c/c-parser.cc:6105
0x9a10cb c_parser_declaration_or_fndef
../../gcc-13-20230219/gcc/c/c-parser.cc:2841
0x9a8a1b c_parser_external_declaration
../../gcc-13-20230219/gcc/c/c-parser.cc:1925
0x9a93f3 c_parser_translation_unit
../../gcc-13-20230219/gcc/c/c-parser.cc:1779
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread zzhu at greenliant dot com via Gcc-bugs

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

--- Comment #5 from Zhengfeng Zhu  ---
OK. Thanks. Let me confirm this issue.

[Bug debug/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
GCC does not have an option called -Os2 .

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

2023-04-24 Thread crazylht at gmail dot com via Gcc-bugs

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

--- Comment #1 from Hongtao.liu  ---
Mine, I'll take a look.

[Bug debug/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread zzhu at greenliant dot com via Gcc-bugs

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

--- Comment #3 from Zhengfeng Zhu  ---
-D__RISC_V__=1 -D__arm__ -D__FW_BCU__ -I"/cygdrive/F/Include" -Os2
-mcmodel=medium -g3 -Wall -mcpu=n25 -ffunction-sections -fdata-sections -c
-fmessage-length=0 -msmall-data-limit=0

The .i file we can't show it here.

[Bug debug/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
  Component|c   |debug

[Bug c/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed|2023-04-25 00:00:00 |
 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #2 from Sam James  ---
Please include the full preprocessed source and other information listed at
https://gcc.gnu.org/bugs/#need.

[Bug c/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||sjames at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-25

--- Comment #1 from Sam James  ---
Please include the full preprocessed source and other information listed at
https://gcc.gnu.org/bugs/#need.

[Bug c/109617] New: RISC-V: ICE for vlmul_ext_v intrinsic API

2023-04-24 Thread pan2.li at intel dot com via Gcc-bugs

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

Bug ID: 109617
   Summary: RISC-V: ICE for vlmul_ext_v intrinsic API
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

Given we have the bellow sample code.

#include 

vint16m8_t test_vlmul_ext_v_i16mf4_i16m8(vint16mf4_t op1) {
  return __riscv_vlmul_ext_v_i16mf4_i16m8(op1);
}

It will have ICE when building with this option "riscv64-unknown-elf-gcc
-march=rv64gcv -O3 test.c -c -S -o -".

during RTL pass: expand
test.c: In function 'test_vlmul_ext_v_i16mf4_i16m8':
test.c:7:10: internal compiler error: in code_for_vlmul_extx32, at
./insn-opinit.h:572
7 |   return __riscv_vlmul_ext_v_i16mf4_i16m8(op1);
  |  ^
0x1c07559 code_for_vlmul_extx32(machine_mode)
./insn-opinit.h:572
0x1c0b14e riscv_vector::vlmul_ext::expand(riscv_vector::function_expander&)
const
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vector-builtins-bases.cc:1522
0x1c03b2d riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-vector-builtins.cc:3501
0x1bd8463 riscv_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/config/riscv/riscv-builtins.cc:379
0xe2951d expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/builtins.cc:7341
0x103cb67 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/expr.cc:11864
0x102e744 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/expr.cc:8999
0x1022e43 store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/expr.cc:6330
0x10213c1 expand_assignment(tree_node*, tree_node*, bool)
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/expr.cc:6048
0xe6cab9 expand_call_stmt
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/cfgexpand.cc:2829
0xe70886 expand_gimple_stmt_1
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/cfgexpand.cc:3880
0xe70f7a expand_gimple_stmt
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/cfgexpand.cc:4044
0xe79c1a expand_gimple_basic_block
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/cfgexpand.cc:6106
0xe7c17c execute
   
/home/pli/repos/toolchains/gcc/reference/riscv-gnu-toolchain/gcc/__BUILD_RISC-V/../gcc/cfgexpand.cc:6841

[Bug c/109616] New: internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

2023-04-24 Thread zzhu at greenliant dot com via Gcc-bugs

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

Bug ID: 109616
   Summary: internal compiler error: in dwarf2out_var_location, at
dwarf2out.c:26371 （GreenLiant）
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzhu at greenliant dot com
  Target Milestone: ---

When compile one c program, we using the '-Os2:Optimize more for size', then we
compile occur this issue.

[Bug target/109615] Redundant VSETVL after optimized code of RVV

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Severity|normal  |enhancement
 Target||Riscv
   Keywords||missed-optimization

[Bug c/109615] New: Redundant VSETVL after optimized code of RVV

2023-04-24 Thread pan2.li at intel dot com via Gcc-bugs

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

Bug ID: 109615
   Summary: Redundant VSETVL after optimized code of RVV
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

Assume we have a sample code as below.


#include "riscv_vector.h"

void f (int8_t * restrict in, int8_t * restrict out, int n, int m, int cond)
{
  size_t vl = 101;
  if (cond)
vl = m * 2;
  else
vl = m * 2 * vl;

  for (size_t i = 0; i < n; i++)
{
  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
  __riscv_vse8_v_i8mf8 (out + i, v, vl);

  vbool64_t mask = __riscv_vlm_v_b64 (in + i + 100, vl);

  vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tumu (mask, v, in + i + 100, vl);
  __riscv_vse8_v_i8mf8 (out + i + 100, v2, vl);
}

  for (size_t i = 0; i < n; i++)
{
  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + 300, vl);
  __riscv_vse8_v_i8mf8 (out + i + 300, v, vl);
}
}

Currently the upstream will generate the code as below with *-march=rv64gcv -O3
-frename-registers* options. It looks like the last vsetvl of .L4 bb is
redundant.

f:
slliw   a3,a3,1
bne a4,zero,.L2
li  a5,101
mul a3,a3,a5
.L2:
addia4,a1,100
add t1,a0,a2
mv  t0,a0
beq a2,zero,.L1
vsetvli zero,a3,e8,mf8,tu,mu
.L4:
addia6,t0,100
addia7,a4,-100
vle8.v  v1,0(t0)
addit0,t0,1
vse8.v  v1,0(a7)
vlm.v   v0,0(a6)
vle8.v  v1,0(a6),v0.t
vse8.v  v1,0(a4)
addia4,a4,1
bne t0,t1,.L4
addia0,a0,300
addia1,a1,300
add a2,a0,a2
vsetvli zero,a3,e8,mf8,ta,ma   // <= redundant ?
.L5:
vle8.v  v2,0(a0)
addia0,a0,1
vse8.v  v2,0(a1)
addia1,a1,1
bne a2,a0,.L5
.L1:
ret

[Bug analyzer/109614] New: -Wanalyzer-use-after-free gets confused about a free function in Coreutils

2023-04-24 Thread eggert at cs dot ucla.edu via Gcc-bugs

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

Bug ID: 109614
   Summary: -Wanalyzer-use-after-free gets confused about a free
function in Coreutils
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

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

This is (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64. Compile the
attached file (derived from GNU coreutils csplit) with:

  gzip -d a.i.gz
  gcc -fanalyzer -S a.i

The first warning is a false positive. As near as I can make out, -fanalyzer
got confused and is treating free_buffer as if it calls itself or was called
twice, which is obviously wrong (the diagnostic is confusing at any rate). The
full set of diagnostics is shown below.

a.i: In function ‘free_buffer’:
a.i:4491:21: warning: use after ‘free_buffer’ of ‘buf’ [CWE-416]
[-Wanalyzer-use-after-free]
 4491 |   for (struct line *l = buf->line_start; l;)
  | ^
  ‘main’: events 1-6
|
| 5509 | main (int argc, char **argv)
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|..
| 5588 |   if (argc - optind < 2)
|  |  ~
|  |  |
|  |  (2) following ‘false’ branch...
|..
| 5598 |   idx_t prefix_len = strlen (prefix);
|  |  ~~~
|  |  |
|  |  (3) ...to here
|..
| 5616 |   if (__builtin_add_overflow (prefix_len,
max_digit_string_len + 1, _size))
|  |  ~
|  |  |
|  |  (4) following ‘false’ branch...
| 5617 | xalloc_die ();
| 5618 |   filename_space = ximalloc (filename_size);
|  |
|  ||
|  |(5) ...to here
| 5619 |   set_input_file (argv[optind++]);
|  |   ~~~
|  |   |
|  |   (6) calling ‘set_input_file’ from ‘main’
|
+--> ‘set_input_file’: events 7-11
   |
   | 4708 | set_input_file (char const *name)
   |  | ^~
   |  | |
   |  | (7) entry to ‘set_input_file’
   | 4709 | {
   | 4710 |   if (! (strcmp (name, "-") == 0) && fd_reopen (
   |  |  ~~~
   |  |  ||  |
   |  |  ||  (9) ...to here
   |  |  |(10) following
‘false’ branch...
   |  |  (8) following ‘true’ branch (when the strings
are non-equal)...
   | 4711 |0
   |  |~
   | 4712 |   
, name,
   |  |   
~~~
   | 4713 |
   00
   |  |
   ~~
   | 4714 |
   , 0) < 0)
   |  |
   
   |..
   | 4731 | }
   |  | ~
   |  | |
   |  | (11) ...to here
   |
<--+
|
  ‘main’: events 12-21
|
| 5619 |   set_input_file (argv[optind++]);
|  |   ^~~
|  |   |
|  |   (12) returning to ‘main’ from ‘set_input_file’
|..
| 5651 | for (i = 0; i < nsigs; i++)
|  | ~
|  |   |
|  |   (13) following ‘true’ branch (when ‘i <=
10’)...
|  |   (15) following ‘true’ branch (when ‘i <=
10’)...
| 5652 |   {
| 5653 | sigaction (sig[i],
|  |~~

[Bug c/85678] -fno-common should be default

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Sam James  ---
(In reply to David Brown from comment #15)
> This has been implemented in gcc 10, and -fno-common is now the default. 
> This "bug" can presumably now be closed.
> 
> Many thanks to the gcc developers here.

Done in r10-4867-g6271dd984d7f92.

[Bug c/85678] -fno-common should be default

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91093,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91092
 CC||sjames at gcc dot gnu.org

--- Comment #16 from Sam James  ---
For the record, this was done on the Clang side as
https://reviews.llvm.org/D75056.

Also adding -Wimplicit-function-declaration to See Also, along with
-Wimplicit-int and stricter prototypes given they're all related to the same
era + need care in distributions first (which Florian and I are working on).

(Maybe we want a tracker for these, not sure.)

[Bug analyzer/109613] New: -Wanalyzer-null-dereference false positive involving __builtin_unreachable

2023-04-24 Thread eggert at cs dot ucla.edu via Gcc-bugs

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

Bug ID: 109613
   Summary: -Wanalyzer-null-dereference false positive involving
__builtin_unreachable
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 54914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54914=edit
compile with "gcc -fanalyzer -S -O2 u.i" to reproduce the bug

I ran into this problem compiling GNU coreutils with gcc (GCC) 13.0.1 20230401
(Red Hat 13.0.1-0) on x86-64. Compile the attached program with:

  gzip -d u.i.gz
  gcc -fanalyzer -S -O2 u.i

The output is shown below. The first warning is wrong, since 'mode' is not null
there. Although this should be deducible even without the __builtin_unreachable
calls in lines 9025, 9027, 9029 (because xpalloc returns nonnull), it's clearly
deducible with those three lines, since if new_mode_len is nonnegative (checked
by line 9029) then xpalloc must be called and therefore 'mode' cannot be null.

If I remove line 9027, which is merely "((0 <= mode_comma_len) ? (void) 0 :
__builtin_unreachable ());", the false positive goes away. There must be
something wrong there too, as that line merely adds a constraint.


u.i: In function ‘main’:
u.i:9033:28: warning: dereference of NULL ‘mode’ [CWE-476]
[-Wanalyzer-null-dereference]
 9033 | mode[mode_len] = ',';
  | ~~~^
  ‘main’: events 1-11
|
| 8988 |   while ((c = getopt_long (argc, argv,
|  |  ~
| 8989 |   
("Rcfvr::w::x::X::s::t::u::g::o::a::,::+::=::"
|  |   
~~
| 8990 | "0::1::2::3::4::5::6::7::"),
|  | 
| 8991 |long_options,
|  |~
| 8992 | ((void *)0)
|  | ~~~
| 8993 | ))
|  | ~~
| 8994 |  != -1)
|  |  ^
|  |  |
|  |  (1) following ‘true’ branch (when ‘c != -1’)...
| 8995 | {
| 8996 |   switch (c)
|  |   ~~
|  |   |
|  |   (2) ...to here
|  |   (3) following ‘case 43 ... 44:, case 48 ... 55:,
case 61:, case 88:, case 97:, case 103:, case 111:, case 114 ... 117:, case 119
... 120:’ branch...
| 8997 | {
| 8998 | case 'r':
|  | 
|  | |
|  | (4) ...to here
|..
| 9027 | ((0 <= mode_comma_len) ? (void) 0 :
__builtin_unreachable ());
|  |
~
|  |   |
|  |   (5)
following ‘false’ branch (when ‘mode_comma_len >= 0’)...
| 9028 | idx_t new_mode_len = mode_comma_len + arg_len;
|  |   
|  |   |
|  |   (6) ...to here
| 9029 | ((0 <= new_mode_len) ? (void) 0 :
__builtin_unreachable ());
| 9030 | if (mode_alloc <= new_mode_len)
|  |~
|  ||
|  |(7) following ‘false’ branch...
|..
| 9033 | mode[mode_len] = ',';
|  | 
|  | |  |
|  | |  (11) dereference of NULL ‘mode
+ (sizetype)mode_len’
|  | (8) ...to here
|  | (9) ‘mode’ is NULL
| 9034 | memcpy (mode + mode_comma_len, arg, arg_len +
1);
|  | ~
|  |  |
|  |  (10) ‘mode’ is NULL
|

[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference

2023-04-24 Thread egallager at gcc dot gnu.org via Gcc-bugs

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Xi Ruoyao from comment #3)
> -Wnull-dereference is known to give false warnings in many cases (the doc
> says "the precision of the warnings depends on the optimization options
> used" and I remember there are several recent PRs complaining it).  So it's
> not suitable for -Wall or -Wextra.

Well, it's not suitable for -Wall or -Wextra *yet*, but I think it's a
worthwhile goal getting it there eventually. See further discussion in bug
86172

[Bug debug/109612] New: Adding -g makes compilation 220 times slower

2023-04-24 Thread dcb314 at hotmail dot com via Gcc-bugs

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

Bug ID: 109612
   Summary: Adding -g makes compilation 220 times slower
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54913=edit
C source code

The attached C code, when compiled by -g, takes a long time:

$ (ulimit -t 120; time /home/dcb36/gcc/results/bin/gcc-O3 -w -c bug909.c)

real0m0.496s
user0m0.472s
sys 0m0.013s
$ (ulimit -t 120; time /home/dcb36/gcc/results/bin/gcc  -g  -O3 -w -c bug909.c)

real1m48.669s
user1m44.093s
sys 0m3.329s

$  /home/dcb36/gcc/results/bin/gcc   -v
Using built-in specs.
COLLECT_GCC=/home/dcb36/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb36/gcc/results.20230424.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb36/gcc/results.20230424.asan.ubsan --disable-multilib
--disable-bootstrap --with-build-config=bootstrap-asan
--with-build-config=bootstrap-ubsan --with-pkgversion=ff8f95449350372b
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230424 (experimental) (ff8f95449350372b) 
$

[Bug tree-optimization/109611] Missing -Wrestrict across TUs (even with LTO)

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-24
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. It might be the case the restrict warning only happens early.

[Bug tree-optimization/109611] New: Missing -Wrestrict across TUs (even with LTO)

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109611
   Summary: Missing -Wrestrict across TUs (even with LTO)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org
Blocks: 84774
  Target Milestone: ---

```
$ cat test.c
#include 

char foo[200];
char* bar(char*);

int main (int argc, char **argv) {
strncpy (foo, bar (foo) + 50, 70);
}

$ cat test2.c
char* bar (char* x) {
return x;
}
```

```
$ gcc -flto-partition=none -flto test2.c test.c -Wrestrict -O3
[no -Wrestrict warning]
```

But by forcing them all into the same TU:
```
$ cat test{2,}.c | gcc -x c - -O3 -Wrestrict -S -o /dev/null
In file included from /usr/include/string.h:535,
  from :6:
In function ‘strncpy’,
 inlined from ‘main’ at :14:3:
 /usr/include/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’
accessing 70 bytes at offsets 0 and 50 overlaps between 1 and 20 bytes at
offset 50 [-Wrestrict]
[...]
```

None of -fwhole-program, -flto-partition=none nor -flto-partition=one make any
difference.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Jakub Jelinek  ---
In that case it started with r12-382-ged3c43224cc4e378d
But maybe it would be better to track it separately.

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

2023-04-24 Thread gburca-gnu at ebixio dot com via Gcc-bugs

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

--- Comment #7 from Gabriel Burca  ---
Here's the code that still fails with -O3 -fno-optimize-sibling-calls:

```
#include 
#include 
#define N 23
#define MAX_LEN 13
char dst[N + 1];

void stringify(uint64_t id) {
  char buf[MAX_LEN];
  char *ptr = buf + sizeof(buf);  // start from the end of buf
  *(--ptr) = '\0';// terminate string
  while (id && ptr > buf) {
*(--ptr) = static_cast(id % 10) + '0';
id /= 10;
  }
  __builtin_strncpy(dst, ptr, N);   // copy ptr/buf to dst
}

int main() {
  stringify(12345);
  if (strcmp(dst, "12345"))
__builtin_abort();
}
```

Notably this only fails with -O3, not with -O2

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

2023-04-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #18)
> (In reply to Bernhard Reutner-Fischer from comment #17)
> > (In reply to Bernhard Reutner-Fischer from comment #16)

> We can just mark the dt symbol (which is used to describe the generic
> interface) as attr.generic = 1
> 
> This regtests cleanly and fixes the reported bug.
> 
> 
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 221165d6dac..28ed1a32b9e 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -4977,6 +4986,10 @@ generate_isocbinding_symbol (const char *mod_name,
> iso_c_binding_symbol s,
> if (!tmp_sym->attr.function
> && !gfc_add_function (_sym->attr, tmp_sym->name, NULL))
>   return NULL;
> +
> +   /* Mark the derived-type symbol in the generic interface
> +  as generic.  */
> +   dt_sym->attr.generic = 1;
>   }
>  
> /* Say what module this symbol belongs to.  */
> 
> 
> i.e. it marks the dt as GENERIC, so the gmodule contents from comment #16
> become

I have reduced the failing version further for easier debugging
(it still fails on 14-trunk and on 13-branch) to the following:

module AModule
  use, intrinsic :: ISO_C_BINDING, only: C_PTR
end module

module DModule
  type, abstract :: DType
  end type
end module

module FModule
  use AModule
  use DModule
  implicit none
  public :: FProc
  private
contains
  subroutine FProc(x)
class(DType), allocatable, intent(out) :: x
  end subroutine
end module

module GModule
  use AModule
end module

module HModule
  use FModule
  use, intrinsic :: ISO_C_BINDING, only: C_PTR
  use GModule
  implicit none
  type(C_PTR) :: context
end module

I think I agree more with your thoughts in comment#16 than comment#18:
the symbol C_PTR is erroneously marked as ambiguous in module reading,
but for the wrong reason.  C_PTR is an intrinsic DT and not a procedure;
so we should not mark it as "generic".

As long as a symbol from an *intrinsic module* is use-associated - either
directly or indirectly - the conflict check could trace it down to its
origin (in case it is renamed), and we would resolve this explicitly.

I haven't checked the standard about possible issues coming with renaming;
I should do that now..

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
Note, changing `ptr < buf` to `ptr != buf` still invokes the wrong code being
generated.

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

2023-04-24 Thread arsen at gcc dot gnu.org via Gcc-bugs

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #45 from Arsen Arsenović  ---
to recap what I've found in the bug that just got marked as a dupe:

this is set through a chain of all-target-libstdc++-v3 ->
RAW_CXX_TARGET_EXPORTS -> BASE_TARGET_EXPORTS

the idea here is that newly-built target code should use existing target
libraries rather than $build libraries (which makes sense).

however, the existing approach makes *all* code involved in building target
libs use newly-built libraries, which results in libstdc++ et al being
*downgraded* for make, sh, msgfmt, ld, ... (but not gcc, since the new gcc is
used).

a fix for this might be to build target libraries with adjusted rpaths, or
something similar, but I'm not sure of the full scope of the issue yet (my
debugging this morning was cursory), so I'm not sure if that's sufficient.  I'm
also not sure how to deal with static linking - maybe libtool helps?

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, exactly, the difference between the two revisions is first in tailc pass:
--- pr109609.C.202t.tailc_  2023-04-24 15:48:33.0 -0400
+++ pr109609.C.202t.tailc   2023-04-24 15:49:08.0 -0400
@@ -44,7 +44,7 @@ void invert (const char * id)
[local count: 137085153]:
   # ptr_27 = PHI  [(void *) + 12B](2)>
   __builtin_printf ("Src: %s\n", ptr_27);
-  __builtin_strncpy (, ptr_27, 23);
+  __builtin_strncpy (, ptr_27, 23); [tail call]
   buf ={v} {CLOBBER};
   return;

Obviously, we shouldn't tail call strncpy when the second argument points into
an automatic variable in the current function.

[Bug middle-end/109609] [12/13/14 Regression] Invalid strncpy/strncat optimization in GCC 12

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
Oh the problem is related to tail calls:

  strncpy (, ptr_30, 23); [tail call]

That should not be marked as a tail call as buf is still alive during the call
of strncpy.

Simple workaround, add
asm("":::"memory");

Right before the end of invert.
Or use -fno-optimize-sibling-calls

Self contained testcase:
```
#define N 23
#define MAX_LEN 13
char dst[N + 1];

void invert(const char *id) {
  char buf[MAX_LEN];
  char *ptr = buf + sizeof(buf);  // start from the end of buf
  *(--ptr) = '\0';// terminate string
  while (*id && ptr > buf) {
*(--ptr) = *(id++);   // copy id backwards
  }
  __builtin_strncpy(dst, ptr, N);   // copy ptr/buf to dst
 // asm("":::"memory"); // This "fixes" the issue.
}


int main() {
  invert("abcde");
  if (strcmp(dst, "edcba"))
__builtin_abort();
}
```

[Bug middle-end/109609] [12/13/14 Regression] Invalid strncpy/strncat optimization in GCC 12

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
Summary|Invalid strncpy/strncat |[12/13/14 Regression]
   |optimization in GCC 12  |Invalid strncpy/strncat
   ||optimization in GCC 12
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-24
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jakub Jelinek  ---
Started with r12-145-gd1d01a66012a93cc8cb7d

[Bug libstdc++/109602] Import Gentoo msgfmt patch ?

2023-04-24 Thread arsen at gcc dot gnu.org via Gcc-bugs

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #6 from Arsen Arsenović  ---
(In reply to Romain Geissler from comment #5)
> Hi,
> 
> My intention was to try to raise upstream an issue that people packaging gcc
> may hit in some cases. Gentoo has such a patch, but I also have a similar
> one on my side since couple of years, it's only yesterday that I discovered
> Gentoo had one too (and Alpine Linux). I am not a user of Gentoo nor Alpine
> Linux myself, I just also package my own gcc.
> 
> So I apologize to the Gentoo and Gcc communities if I offended anyone by
> opening this bug report, that was not the intention.

no worries, I doubt anyone took offense.  we (Gentoo) try to work as closely as
possible with upstream GCC, so usually a patch being on our end only means that
nobody reworked it to be upstreamable.  if in doubt, you can email
toolch...@gentoo.org - we'd be happy to answer.

in this instance, the 'fix' we use is not applicable in the general case, since
it doesn't solve the general problem of building a downgraded gcc, so we never
upstreamed it.

PS: the general issue is reported, marking as dupe

have a lovely day!

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

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

2023-04-24 Thread arsen at gcc dot gnu.org via Gcc-bugs

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #44 from Arsen Arsenović  ---
*** Bug 109602 has been marked as a duplicate of this bug. ***

[Bug target/109610] New: [14 regression] gcc.target/powerpc/dform-3.c fails after

2023-04-24 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109610
   Summary: [14 regression] gcc.target/powerpc/dform-3.c fails
after
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:0368d169492017cfab5622d38b15be94154d458c, r14-172-g0368d169492017

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/dform-3.c"

FAIL: gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrd 
FAIL: gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrld 
# of expected passes7
# of unexpected failures2


commit 0368d169492017cfab5622d38b15be94154d458c (HEAD, refs/bisect/bad)
Author: liuhongt 
Date:   Wed Feb 8 12:42:27 2023 +0800

Use NO_REGS in cost calculation when the preferred register class are not
known yet.

[Bug middle-end/109609] Invalid strncpy/strncat optimization in GCC 12

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Note strcpy arguments cannot be overlapping if the dst overlaps with the
> src, then the behavior is undefined. I think you are hitting that undefined
> behavior here.

I take that back, I read the source incorrectly at the time.

[Bug middle-end/109609] Invalid strncpy/strncat optimization in GCC 12

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
Note strcpy arguments cannot be overlapping if the dst overlaps with the src,
then the behavior is undefined. I think you are hitting that undefined behavior
here.

[Bug c++/109609] New: Invalid strncpy/strncat optimization in GCC 12

2023-04-24 Thread gburca-gnu at ebixio dot com via Gcc-bugs

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

Bug ID: 109609
   Summary: Invalid strncpy/strncat optimization in GCC 12
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gburca-gnu at ebixio dot com
  Target Milestone: ---

The following code prints uninitialized garbage when compiled with -O2 or -O3
in all versions of GCC 12 (including trunk). It works correctly in GCC 11.
Replacing strncpy() with strncat() gives the same results, however when using
the commented out strncpy() call, the output is as expected. See also how the
generated assembly changes when the printf() inside the function is commented
out.

Expected output:
Src: edcba
Dst: edcba

Actual output:
Src: edcba
Dst: 

https://godbolt.org/z/5E51Gdh9s

Compile args:
g++ -O2 file.cpp

8<--- file.cpp --
#include 
#include 
#include 

static constexpr unsigned N = 23;
char dst[N + 1];

void invert(const char *id) {
  constexpr int MAX_LEN = 13;
  char buf[MAX_LEN];
  char *ptr = buf + sizeof(buf);  // start from the end of buf
  *(--ptr) = '\0';// terminate string
  while (*id && ptr > buf) {
*(--ptr) = *(id++);   // copy id backwards
  }
  printf("Src: %s\n", ptr);
  strncpy(dst, ptr, N);   // copy ptr/buf to dst
  //strncpy(dst, ptr, std::min(N, strlen(ptr)));
}


int main() {
  invert("abcde");
  printf("Dst: %s\n", dst);
}
8<--- file.cpp --

g++ -v -save-temps -O2 file.cpp
Using built-in specs.
COLLECT_GCC=/home/gb/.fighome/runtime/gcc/12.2.0-1/bin/g++
COLLECT_LTO_WRAPPER=/home/gb/.fighome/runtime/gcc/12.2.0-1/bin/../libexec/gcc/x86_64-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-12.2.0/configure --prefix
/data/work/chhq-sudbld10-001-CENTOS7/15df1254b8bb2e5c/scratch/gcc/12.2.0/staging
--build=x86_64-linux-gnu --disable-multilib --disable-multiarch
--enable-clocale=gnu --enable-languages=c,c++,fortran --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-pkgversion=''\''internal_build'\''' --with-system-zlib --disable-werror
--with-libelf=/data/work/chhq-sudbld10-001-CENTOS7/15df1254b8bb2e5c/scratch/gcc/12.2.0/build/libelf-0.8.13
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 ('internal_build')
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/home/gb/.fighome/runtime/gcc/12.2.0-1/bin/../libexec/gcc/x86_64-linux-gnu/12.2.0/cc1plus
-E -quiet -v -iprefix
/home/gb/.fighome/runtime/gcc/12.2.0-1/bin/../lib/gcc/x86_64-linux-gnu/12.2.0/
-D_GNU_SOURCE file.cpp -mtune=generic -march=x86-64 -O2 -fpch-preprocess

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Andrew Pinski  ---
Just a quick note on this part of the bug report:

(In reply to Richard Biener from comment #3)
> Doing this in a classical way in phi-opt might end up being slightly
> convoluted.
> So I'd propose to try to utilize match-and-simplify by adding
> 
> 
> (cond (ge @0 @1) (max:s @0 @2) (max:s @1 @2))
> -> (max (max @0 @1) @2)

I am going to submit patches for the above later today or tomorrow.

> 
> kind patterns and from phiopt doing exploded queries of this simplification
> by seeding the cond expr from the dominating condition plus the PHI operands.
> 
>  res = gimple_simplify (COND_EXPR, build2 /* Ick */ (cond-code,
> boolean_type, cond-op0, cond-op1), true-phi-arg, false-phi-arg, ,
> follow_single_use_edges);
> 
> of course you need more than a single pattern or consider swapped ops 2 and 3
> (not yet supported).  In the end explicit pattern explosion might make a
> manual
> implementation in phiopt easier (who knows).

This part is fully implemented in r14-204-gf1f5cbaa3f716fcb472dee5 (there was a
few pieces of the match-and-simplify phiopt implemented in GCC 12). 

Note phiopt already does "a ? b : c" -> "!a ? c : b" (where !a folds)
(implemented in r12-2040-ga50cecb20a10) specifically because of the explosion
issue.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

2023-04-24 Thread gjl at gcc dot gnu.org via Gcc-bugs

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #19 from Georg-Johann Lay  ---
Created attachment 54912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54912=edit
pr105532.diff: Proposed patch for the AVR backend

Here is a proposed, untested patch.

gcc/
PR target/105532
* config/avr/avr.cc (opts.h): Include it.
(avr_option_override): Set --param_min_pagesize=0.

gcc/testsuite/
PR target/105532
* gcc.target/avr/torture/pr105532.c: New test.

[Bug c/109598] [12/13/14 Regression] ICE: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|ICE: tree check: expected   |[12/13/14 Regression] ICE:
   |array_type, have error_mark |tree check: expected
   |in array_ref_low_bound, at  |array_type, have error_mark
   |tree.cc |in array_ref_low_bound, at
   ||tree.cc

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Liška from comment #2)
> Started with r12-3278-g823685221de986.

I figured that caused this issue. 

> it would be nice if the frontend wouldn't emit

If the C front-end had its own AST, then it would be easier but it does not.
Maybe we should not gimplify things if there was an error (from the front-end);
that might help.

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

2023-04-24 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

David Malcolm  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from David Malcolm  ---
Richi: what is the mechanism (if any) for freshly-created gimple stmts to get a
location_t within gimple-match.cc?  It seems to me that the stmts ought to
somehow be assigned the location_t of whatever they are simplified from, or
we'll keep running into stmts with UNKNOWN_LOCATION.  Should we be passing a
location_t around in the generated match code, or have a postprocessing phase
where we copy a location_t to all freshly-created stmts?

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

2023-04-24 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from David Malcolm  ---
The optimized stmt with UNKNOWN_LOCATION is created from:

(gdb) call inform(stmt->location, "stmt in gimple_simplify")
../../src/pr109580.c:10:9: note: stmt in gimple_simplify
   10 | err |= dup2(nfd, 0) < 0;
  | ^~

here:

(gdb) bt
#0  gimple_set_code (g=, code=GIMPLE_ASSIGN) at
../../src/gcc/gimple.cc:112
#1  0x010b2d0f in gimple_init (g=,
code=GIMPLE_ASSIGN, num_ops=3) at ../../src/gcc/gimple.cc:131
#2  0x010b2d82 in gimple_alloc (code=GIMPLE_ASSIGN, num_ops=3) at
../../src/gcc/gimple.cc:158
#3  0x010b2de8 in gimple_build_with_ops_stat (code=GIMPLE_ASSIGN,
subcode=98, num_ops=3) at ../../src/gcc/gimple.cc:186
#4  0x010b3c83 in gimple_build_assign_1 (lhs=, subcode=BIT_IOR_EXPR, op1=, 
op2=, op3=) at
../../src/gcc/gimple.cc:469
#5  0x010b3d64 in gimple_build_assign (lhs=, subcode=BIT_IOR_EXPR, op1=, 
op2=, op3=) at
../../src/gcc/gimple.cc:496
#6  0x01c63850 in maybe_push_res_to_seq (res_op=0x7fff5980,
seq=0x7fffd3d8, res=)
at ../../src/gcc/gimple-match-head.cc:634
#7  0x01d508c9 in gimple_simplify_189 (res_op=0x7fffd200,
seq=0x7fffd3d8, valueize=0x175579f , 
type=, captures=0x7fff5b30,
bitop=BIT_IOR_EXPR) at gimple-match.cc:52798
#8  0x01e587f2 in gimple_simplify_BIT_IOR_EXPR (res_op=0x7fffd200,
seq=0x7fffd3d8, valueize=0x175579f , 
code=..., type=, _p0=, _p1=) at gimple-match.cc:115984
#9  0x01fcfaed in gimple_simplify (res_op=0x7fffd200,
seq=0x7fffd3d8, valueize=0x175579f , code=..., 
type=, _p0=,
_p1=) at gimple-match.cc:211249
#10 0x01c62774 in gimple_resimplify2 (seq=0x7fffd3d8,
res_op=0x7fffd380, valueize=0x175579f )
at ../../src/gcc/gimple-match-head.cc:323
#11 0x01c632a2 in gimple_match_op::resimplify (this=0x7fffd380,
seq=0x7fffd3d8, valueize=0x175579f )
at ../../src/gcc/gimple-match-head.cc:516
#12 0x01c648ec in gimple_simplify (stmt=,
res_op=0x7fffd380, seq=0x7fffd3d8, 
valueize=0x175579f , top_valueize=0x175579f
) at ../../src/gcc/gimple-match-head.cc:1115
#13 0x010dd6dc in fold_stmt_1 (gsi=0x7fffd710, inplace=false,
valueize=0x175579f )
at ../../src/gcc/gimple-fold.cc:6251
#14 0x010dde07 in fold_stmt (gsi=0x7fffd710, valueize=0x175579f
) at ../../src/gcc/gimple-fold.cc:6417
#15 0x01757984 in (anonymous namespace)::pass_forwprop::execute
(this=0x3f79bb0, fun=0x7fffea816000)
at ../../src/gcc/tree-ssa-forwprop.cc:3851
#16 0x01431388 in execute_one_pass (pass=) at ../../src/gcc/passes.cc:2651
#17 0x014317a9 in execute_pass_list_1 (pass=) at ../../src/gcc/passes.cc:2760
#18 0x014317da in execute_pass_list_1 (pass=) at ../../src/gcc/passes.cc:2761
#19 0x01431839 in execute_pass_list (fn=0x7fffea816000, pass=) at ../../src/gcc/passes.cc:2771
#20 0x0142ef7f in do_per_function_toporder (callback=0x14317f5
, data=0x3f79820)
at ../../src/gcc/passes.cc:1780
#21 0x01432567 in execute_ipa_pass_list (pass=) at ../../src/gcc/passes.cc:3105
#22 0x00ea7ede in ipa_passes () at ../../src/gcc/cgraphunit.cc:2202
#23 0x00ea8328 in symbol_table::compile (this=0x7fffea648000) at
../../src/gcc/cgraphunit.cc:2323
#24 0x00ea89bb in symbol_table::finalize_compilation_unit
(this=0x7fffea648000) at ../../src/gcc/cgraphunit.cc:2575
#25 0x0159fa0f in compile_file () at ../../src/gcc/toplev.cc:471
#26 0x015a33d1 in do_compile (no_backend=false) at
../../src/gcc/toplev.cc:2125
#27 0x015a389b in toplev::main (this=0x7fffdd8a, argc=21,
argv=0x7fffde98) at ../../src/gcc/toplev.cc:2283
#28 0x02f77c1a in main (argc=21, argv=0x7fffde98) at
../../src/gcc/main.cc:39

[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective

2023-04-24 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from David Malcolm  ---
The warning is emitted on this statement:

  _23 = _3 | _5;

within this basic block in the optimized code:

   [local count: 217325344]:
  nfd_26 = emacs_open_noquit ("/dev/null", 2, 0);
  _3 = nfd_26 < 0;
  _4 = dup2 (nfd_26, 0);
  _5 = _4 < 0;
  _23 = _3 | _5;
  _6 = dup2 (nfd_26, 1);
  [...snip...]

where the statement has UNKNOWN_LOCATION for its source location.

So there are several things going on here:

(a) the statement has UNKNOWN_LOCATION, rather than a meaningful source
location

(b) pragmas don't affect statements at UNKNOWN_LOCATION; perhaps they should?

(c) the analyzer has some logic to workaround stmt bad locations (stmt_finder);
perhaps it could use it in this case

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

2023-04-24 Thread aldot at gcc dot gnu.org via Gcc-bugs

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

--- Comment #18 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #17)
> (In reply to Bernhard Reutner-Fischer from comment #16)
> 
> > I'm testing a more elaborate test which keeps check_for_ambiguous in the
> > same spot as before, but in that check, looks if the symtree (C_ptr in this
> > case, number 3) is listed in the generic interfaces after the existing check
> > that looks if the symbol itself is GENERIC.
> 
> This highlights cases like in use_24.f90 and use_27.f90 and requires
> follow-up changes that i'm not entirely comfortable with.

We can just mark the dt symbol (which is used to describe the generic
interface) as attr.generic = 1

This regtests cleanly and fixes the reported bug.


diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 221165d6dac..28ed1a32b9e 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -4977,6 +4986,10 @@ generate_isocbinding_symbol (const char *mod_name,
iso_c_binding_symbol s,
  if (!tmp_sym->attr.function
  && !gfc_add_function (_sym->attr, tmp_sym->name, NULL))
return NULL;
+
+ /* Mark the derived-type symbol in the generic interface
+as generic.  */
+ dt_sym->attr.generic = 1;
}

  /* Say what module this symbol belongs to.  */


i.e. it marks the dt as GENERIC, so the gmodule contents from comment #16
become
...
(('c_funptr' '__iso_c_binding' 2) ('c_ptr' '__iso_c_binding' 3)) // generic
interfaces
...
(2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 GENERIC IS_BIND_C IS_C_INTEROP
PRIVATE_COMP) ((4 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (
UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ()))
PRIVATE (DERIVED 2 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0)
3 'C_ptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN 0 0 GENERIC IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((5
'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL
UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (
DERIVED 3 0 1 1 VOID ()) 0 0 () () 0 () () () 2 42 0)

[Bug testsuite/109608] New: [14 regression] net test case g++.dg/cpp0x/constexpr-pmf3.C in r10-11306-gda17a9049ee0a8 has excess errors

2023-04-24 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109608
   Summary: [14 regression] net test case
g++.dg/cpp0x/constexpr-pmf3.C in
r10-11306-gda17a9049ee0a8 has excess errors
   Product: gcc
   Version: 10.4.1
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:da17a9049ee0a8ca9f93edf137df92e824a7593e, r10-11306-gda17a9049ee0a8
make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp0x/constexpr-pmf3.C"
FAIL: g++.dg/cpp0x/constexpr-pmf3.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-pmf3.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-pmf3.C  -std=c++2a (test for excess errors)
# of unexpected failures3
# of unsupported tests  1


commit da17a9049ee0a8ca9f93edf137df92e824a7593e (HEAD, refs/bisect/bad)
Author: Jason Merrill 
Date:   Thu Mar 23 16:50:09 2023 -0400

c++: constexpr PMF conversion [PR105996]


FAIL: g++.dg/cpp0x/constexpr-pmf3.C  -std=c++14 (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf3.C:12:41:
error: extra ';' [-Wpedantic]

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

2023-04-24 Thread aldot at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #16)

> I'm testing a more elaborate test which keeps check_for_ambiguous in the
> same spot as before, but in that check, looks if the symtree (C_ptr in this
> case, number 3) is listed in the generic interfaces after the existing check
> that looks if the symbol itself is GENERIC.

This highlights cases like in use_24.f90 and use_27.f90 and requires follow-up
changes that i'm not entirely comfortable with.

> 
> I did not really look at the standard, so i wonder if that makes sense to
> somebody more familiar with that area?

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Andrew Pinski  ---
The phiopt issue is fixed for GCC 14 now.
Ifcvt will be fixed soon.

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

2023-04-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:7049241f6ee558cfc0b227b5a0a355ec29afd6f1

commit r14-201-g7049241f6ee558cfc0b227b5a0a355ec29afd6f1
Author: Andrew Pinski 
Date:   Thu Apr 20 10:56:17 2023 -0700

PHIOPT: Allow other diamond uses when do_hoist_loads is true

While working on adding diamond shaped form to match-and-simplify
phiopt, I Noticed that we would not reach there if do_hoist_loads
was true. In the original code before the cleanups it was not
obvious why but after I finished the cleanups, it was just a matter
of removing a continue and that is what this patch does.

This just happens also to fix a bug report that I noticed too.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/68894
* tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Remove the
continue for the do_hoist_loads diamond case.

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:2f58dd71d1b8e23f28a43360742519e92ee0c8d5

commit r14-199-g2f58dd71d1b8e23f28a43360742519e92ee0c8d5
Author: Andrew Pinski 
Date:   Thu Apr 20 09:23:25 2023 -0700

PHIOPT: Move check on diamond bb to tree_ssa_phiopt_worker from
minmax_replacement

This moves the check to make sure on the diamond shaped form bbs that
the the two middle bbs are only for that diamond shaped form earlier
in the shared code.
Also remove the redundant check for single_succ_p since that was already
done before hand.
The next patch will simplify the code even further and remove redundant
checks.

PR tree-optimization/109604

gcc/ChangeLog:

* tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Move the
diamond form check from ...
(minmax_replacement): Here.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr109604-1.c: New test.
* gcc.c-torture/compile/pr109604-2.c: New test.

[Bug libstdc++/109606] Unguarded `__is_same` builtin usage

2023-04-24 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Jonathan Wakely  ---
N.B. I added other unguarded uses of the built-in to bits/locale_classes.tcc
and in that case it's used in C++98 too, so even std::is_same<>::value isn't
available (and I didn't want to use the old __are_same<>::__value trait).

I suppose we could add something like this to bits/c++config.h:

#if ! __has_builtin(__is_same)
// Assume the much older __is_same_as built-in is supported instead:
# define __is_same(T, U) __is_same_as(T, U)
#endif

but it sounds like it won't be needed now anyway. So I'll close this as WONTFIX
if that's OK.

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread dcb314 at hotmail dot com via Gcc-bugs

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

--- Comment #3 from David Binderman  ---
Another test case, this time in C++:

struct {
  int second;
} selectPlayer_playerRes;
int selectPlayer_playerRes_0;
int selectPlayer() {
  if (selectPlayer_playerRes_0 && selectPlayer_playerRes.second >= 0)
return selectPlayer_playerRes.second;
  else
return -1;
}

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
I had already posted a fix for this (and approved already):
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616499.html

I will add the testcase.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

2023-04-24 Thread david at westcontrol dot com via Gcc-bugs

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

David Brown  changed:

   What|Removed |Added

 CC||david at westcontrol dot com

--- Comment #18 from David Brown  ---
This issue does not appear to be related to any particular backend.

Changing the initial code to remove the volatile :

void m(void) {
 uint8_t * ptr2 = ( uint8_t*)(0x0030);
*ptr2 = 0xd8;
}

gives a warning in gcc 11 as well - "warning: writing 1 byte into a region of
size 0".  (gcc 12 and 13 give the "array subscript [0] is outside array bounds"
warning.)


It is standard practice in embedded development to cast an integer value (often
a compile-time constant, but not always) to a pointer and use that to access
memory-mapped registers or other data at fixed addresses.  Typically the
pointers are pointer-to-volatile.  Sometimes the data type in question is a
"uintN_t" type, sometimes it is a struct covering a range of registers.  There
are other ways to specify fixed addresses, such as using "extern" data that is
defined in a linker file or an assembly file - but I have not seen other
methods used much in recent decades.

The compiler knows nothing about the size of the region pointed to here.  It is
no more appropriate for it to guess the size is 0 than to guess it is 42.  It
should either assume the size is one single object of the named type, or an
array of unknown size of the named type.  (I'd prefer the first, but the second
is also a reasonable choice.)

As an embedded developer, I don't want to have to turn off useful warnings to
avoid false positives on common and essential constructs.

[Bug libstdc++/109606] Unguarded `__is_same` builtin usage

2023-04-24 Thread akaraevz at mail dot ru via Gcc-bugs

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

--- Comment #4 from Alexander  ---
^ I meant `__is_same`, not `__same_as` (typo)

[Bug bootstrap/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers

2023-04-24 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from seurer at gcc dot gnu.org ---
I've seen some successful builds go by on the old systems.  Thanks!

[Bug libstdc++/109606] Unguarded `__is_same` builtin usage

2023-04-24 Thread akaraevz at mail dot ru via Gcc-bugs

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

--- Comment #3 from Alexander  ---
(In reply to Jonathan Wakely from comment #1)
> Yes. Using libstdc++ headers with older **or newer** versions of GCC is
> completely unsupported. For other compilers, they need to be sufficiently
> close to GCC, which means they should support built-ins added to GCC 10 by
> now.
Thanks you for explanation. Usage of `_GLIBCXX_HAVE_BUILTIN_IS_SAME` confused
me, I expected that all `__same_as` usages should be guarded by this flag.

> That was added some years ago, and I've been thinking of simplifying it.
> 
> Do you actually see a problem with any real compiler?
There's no problem with any real compiler (at least for me), however the
problem exists for ReSharper C++ (tracking issue:
https://youtrack.jetbrains.com/issue/RSCPP-34115). Amongst other, ReSharper has
its own preprocessor and also constexpr evaluation engine where `__same_as`
built-in was marked as supported only in clang. We missed that gcc-10 started
supporting it too. It wasn't an issue before, because we simply returned
`false` from `__has_builtin(__same_as)` for gcc and everything worked fine with
fallback to naive implementation (i.e. for `std::is_same`). Of course, we'll
fix this issue on our side, providing `__same_as` for gcc-10 (and later) too.

[Bug libstdc++/109606] Unguarded `__is_same` builtin usage

2023-04-24 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jonathan Wakely  ---
P.S. the reason it uses __is_same instead of std::is_same_v is because it is
C++14 code, and the reason it doesn't use std::is_same<>::value is to avoid the
class template instantiation.

[Bug libstdc++/109606] Unguarded `__is_same` builtin usage

2023-04-24 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Alexander from comment #0)
> This commit
> (https://github.com/gcc-mirror/gcc/commit/
> 17855eed7fc76b2cee7fbbc26f84d3c8b99be13c) introduces new helper function
> `__find_uniq_type_in_pack` that uses `__is_same` builtin. However, this
> builtin is only supported since gcc-10. There's no `#ifdef`-guard so this
> code won't compile using gcc-9 or any other compiler that doesn't provide
> `__is_same` builtin. Is it expected behaviour?

Yes. Using libstdc++ headers with older **or newer** versions of GCC is
completely unsupported. For other compilers, they need to be sufficiently close
to GCC, which means they should support built-ins added to GCC 10 by now.


> In contrast, current implementation of `std::is_same`
> (https://github.com/gcc-mirror/gcc/blob/
> b98c63e9e8ceaf9e04c28d83500f98313284c7f8/libstdc%2B%2B-v3/include/std/
> type_traits#L1392-L1406) correctly checks for
> `_GLIBCXX_HAVE_BUILTIN_IS_SAME` flag:

That was added some years ago, and I've been thinking of simplifying it.

Do you actually see a problem with any real compiler?

[Bug ipa/109607] IPA replaces stmt with invalid gimple

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-24
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
#0  ipa_param_body_adjustments::modify_expression (this=0x4b1f040, 
expr_p=0x737222b8, convert=true)
at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:1867
#1  0x016f7dc5 in ipa_param_body_adjustments::modify_assignment (
this=0x4b1f040, stmt=, 
extra_stmts=0x7fffd0a8)
at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:1890
#2  0x016f927a in ipa_param_body_adjustments::modify_gimple_stmt (
this=0x4b1f040, stmt=0x7fffd168, extra_stmts=0x7fffd0a8, 
orig_stmt=)
at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:2273
#3  0x01abb925 in remap_gimple_stmt (
stmt=, id=0x7fffd730)
at /space/rguenther/src/gcc/gcc/tree-inline.cc:1961

Supposedly the easiest would be to make any is_gimple_reg_type IPA SRA
replacement (I suppose all are ...) either address-taken or
DECL_NOT_GIMPLE_REG_P.

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 42488ee09c3..473d759f983 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1384,6 +1384,8 @@ ipa_param_body_adjustments::common_initialization (tree
old_fndecl,
  DECL_CONTEXT (new_parm) = m_fndecl;
  TREE_USED (new_parm) = 1;
  DECL_IGNORED_P (new_parm) = 1;
+ if (is_gimple_reg_type (new_type))
+   DECL_NOT_GIMPLE_REG_P (new_parm) = 1;
  layout_decl (new_parm, 0);
  m_new_decls.quick_push (new_parm);


seems to work on the testcase I have.

[Bug ipa/109607] New: IPA replaces stmt with invalid gimple

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109607
   Summary: IPA replaces stmt with invalid gimple
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On cfghooks.cc we replace

BIT_FIELD_REF <*this_8(D), 8, 56>

with

BIT_FIELD_REF (ISRA.814), 8, 56>

in ipa_param_body_adjustments::modify_expression.  The replacement seems
to be of type 'unsigned long'.  This is (should be) invalid GIMPLE unless
ISRA.814 is made a non-register.

Note when replacing memory with register BIT_FIELD_REFs have to be careful
with endianess (IIRC), thus the replacement looks dangerous anyway.

A fix for PR109594 will make us trip over this new IL checking during
bootstrap.

[Bug libstdc++/109602] Import Gentoo msgfmt patch ?

2023-04-24 Thread romain.geissler at amadeus dot com via Gcc-bugs

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

--- Comment #5 from Romain Geissler  ---
Hi,

My intention was to try to raise upstream an issue that people packaging gcc
may hit in some cases. Gentoo has such a patch, but I also have a similar one
on my side since couple of years, it's only yesterday that I discovered Gentoo
had one too (and Alpine Linux). I am not a user of Gentoo nor Alpine Linux
myself, I just also package my own gcc.

So I apologize to the Gentoo and Gcc communities if I offended anyone by
opening this bug report, that was not the intention.

Cheers,
Romain

[Bug libstdc++/109602] Import Gentoo msgfmt patch ?

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
Arsen is, of course, spot on, but to add some more notes:
- Please in future, don't unilaterally send downstream patches upstream without
attempting to speak to us first. This is on our list to send upstream and
hasn't been yet for the reasons Arsen describes (it needs tidying + proper
rationale included). We're very easily reached and this caught me *very* off
guard.

- The issues for gettext come from msgfmt->libxml2->icu, but it also happens
(we have a similar patch) for when using libarchive tar instead of GNU tar too.

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator with -O3

2023-04-24 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Tamar Christina  ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > (In reply to Richard Biener from comment #3)
> > > The issue isn't unrolling but invariant motion.  We unroll the innermost
> > > loop, vectorizer the middle loop and then unroll that as well.  That 
> > > leaves
> > > us with
> > > 64 invariant loads from b[] in the outer loop which I think RTL opts never
> > > "schedule back", even with -fsched-pressure.
> > > 
> > 
> > Aside from the loads, by fully unrolling the inner loop, that means we need
> > 16 unique registers live for the destination every iteration.  That's
> > already half the SIMD register file on AArch64 gone, not counting the
> > invariant loads.
> 
> Why?  You can try -fno-tree-pre -fno-tree-loop-im -fno-predictive-commoning

Oh, I was basing that on the output of the existing using a lower loop count
with e.g.
template void f<16, 16, 4>

But yes, those options avoid the spills, but of course without them you leave
all the loads inside the loop iteration.

I was hoping more we could get closer to https://godbolt.org/z/7c5YfxE5j which
is a lot better code. i.e. the invariants moved inside the outer loop.  But
yes, I do understand this may be hard to do automatically.

> 
> > The #pragma GCC unroll 8 doesn't work as that seems to stop GIMPLE unrolling
> > and does it at RTL instead.
> 
> ... because on GIMPLE we only can fully unroll or not.

But is this an intrinsic limitation or just because atm we only unroll for SLP?

> 
> > At the moment a way for the user to locally control the unroll amount would
> > already be a good step. I know there's the param, but that's global and
> > typically the unroll factor would depend on the GEMM kernel.
> 
> As said it should already work to the extent that on GIMPLE we do not
> perform classical loop unrolling.

Right, but the RTL unroller produces horrible code.. e.g. the addressing modes
are pretty bad.

[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #22 from Richard Biener  ---
Created attachment 54911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54911=edit
patch I am testing

I am testing the attached.

[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator with -O3

2023-04-24 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
(In reply to Richard Biener from comment #5)
> 
> Why?  You can try -fno-tree-pre -fno-tree-loop-im -fno-predictive-commoning

Note that while at -O2 just -fno-tree-loop-im is enough, at -O3 one also needs
-fno-gcse, which otherwise seems to perform unrestricted hoisting of loop
invariants at RTL level.

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread sebastian.huber--- via Gcc-bugs

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

--- Comment #15 from Sebastian Huber  ---
Thanks for digging into this. With the change I am able to build the
powerpc-rtems target.

[Bug libstdc++/109606] New: Unguarded `__is_same` builtin usage

2023-04-24 Thread akaraevz at mail dot ru via Gcc-bugs

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

Bug ID: 109606
   Summary: Unguarded `__is_same` builtin usage
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akaraevz at mail dot ru
  Target Milestone: ---

Hello.

This commit
(https://github.com/gcc-mirror/gcc/commit/17855eed7fc76b2cee7fbbc26f84d3c8b99be13c)
introduces new helper function `__find_uniq_type_in_pack` that uses `__is_same`
builtin. However, this builtin is only supported since gcc-10. There's no
`#ifdef`-guard so this code won't compile using gcc-9 or any other compiler
that doesn't provide `__is_same` builtin. Is it expected behaviour?

In contrast, current implementation of `std::is_same`
(https://github.com/gcc-mirror/gcc/blob/b98c63e9e8ceaf9e04c28d83500f98313284c7f8/libstdc%2B%2B-v3/include/std/type_traits#L1392-L1406)
correctly checks for `_GLIBCXX_HAVE_BUILTIN_IS_SAME` flag:

```cpp
  template
struct is_same
#ifdef _GLIBCXX_HAVE_BUILTIN_IS_SAME
: public integral_constant
#else
: public false_type
#endif
{ };

#ifndef _GLIBCXX_HAVE_BUILTIN_IS_SAME
  template
struct is_same<_Tp, _Tp>
: public true_type
{ };
#endif
```

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 54910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54910=edit
gcc13-pr109566.patch

Full test I'm going to bootstrap/regtest momentarily.

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13/14 Regression] powerpc: |[12/13/14 Regression]
   |unrecognizable insn for |powerpc: unrecognizable
   |-mcpu=e6500, -mcpu=power3,  |insn for -mcpu=e6500,
   |..., -mcpu=power10  |-mcpu=power3, ...,
   ||-mcpu=power10

--- Comment #13 from Jakub Jelinek  ---
Confirmed at least on the reduced testcase this really started with r12-6433.
Though, it still could be considered P1 on 13/14 branches given that the ranger
changes make it trigger on code on which it didn't trigger before.
powerpc*-rtems* isn't primary nor secondary, but it can trigger even on
powerpc64-linux with -m32 -mpowerpc64.

[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator with -O3

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Richard Biener  ---
(In reply to Tamar Christina from comment #4)
> (In reply to Richard Biener from comment #3)
> > The issue isn't unrolling but invariant motion.  We unroll the innermost
> > loop, vectorizer the middle loop and then unroll that as well.  That leaves
> > us with
> > 64 invariant loads from b[] in the outer loop which I think RTL opts never
> > "schedule back", even with -fsched-pressure.
> > 
> 
> Aside from the loads, by fully unrolling the inner loop, that means we need
> 16 unique registers live for the destination every iteration.  That's
> already half the SIMD register file on AArch64 gone, not counting the
> invariant loads.

Why?  You can try -fno-tree-pre -fno-tree-loop-im -fno-predictive-commoning

> > Estimating register pressure on GIMPLE is hard and we heavily rely on
> > "optimistic" transforms with regard to things being optimized in followup
> > passes during the GIMPLE phase.
> 
> Understood, but if we can't do it automatically, is there a way to tell the
> unroller not to fully unroll this?

Like you did ...

> The #pragma GCC unroll 8 doesn't work as that seems to stop GIMPLE unrolling
> and does it at RTL instead.

... because on GIMPLE we only can fully unroll or not.

> At the moment a way for the user to locally control the unroll amount would
> already be a good step. I know there's the param, but that's global and
> typically the unroll factor would depend on the GEMM kernel.

As said it should already work to the extent that on GIMPLE we do not
perform classical loop unrolling.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000.cc.jj  2023-04-04 10:33:47.433201866 +0200
+++ gcc/config/rs6000/rs6000.cc 2023-04-24 12:31:07.237031550 +0200
@@ -11409,7 +11409,16 @@ bool
 rs6000_is_valid_rotate_dot_mask (rtx mask, machine_mode mode)
 {
   int nb, ne;
-  return rs6000_is_valid_mask (mask, , , mode) && nb >= ne && ne > 0;
+  if (rs6000_is_valid_mask (mask, , , mode) && nb >= ne && ne > 0)
+{
+  if (TARGET_64BIT)
+   return true;
+  /* *rotldi3_mask_dot requires for -m32 -mpowerpc64 that the mask is
+<= 0x7ff.  */
+  return (UINTVAL (mask) << (63 - nb)) <= 0x7fff;
+}
+  else
+return false;
 }

 /* Return whether MASK (a CONST_INT) is a valid mask for any rlwinm, rldicl,
seems to fix this.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Jakub Jelinek  ---
I bet the culprit is that *rotl3_mask_dot has
(mode == Pmode || UINTVAL (operands[3]) <= 0x7fff)
in condition.  So, because *branch_anddi3_dot always wants DImode, if Pmode is
SImode,
it should make sure (UINTVAL (operands[2]) << (63 - nb)) <= 0x7fff.

[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator with -O3

2023-04-24 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Tamar Christina  ---
(In reply to Richard Biener from comment #3)
> The issue isn't unrolling but invariant motion.  We unroll the innermost
> loop, vectorizer the middle loop and then unroll that as well.  That leaves
> us with
> 64 invariant loads from b[] in the outer loop which I think RTL opts never
> "schedule back", even with -fsched-pressure.
> 

Aside from the loads, by fully unrolling the inner loop, that means we need 16
unique registers live for the destination every iteration.  That's already half
the SIMD register file on AArch64 gone, not counting the invariant loads.

> Estimating register pressure on GIMPLE is hard and we heavily rely on
> "optimistic" transforms with regard to things being optimized in followup
> passes during the GIMPLE phase.

Understood, but if we can't do it automatically, is there a way to tell the
unroller not to fully unroll this?

The #pragma GCC unroll 8 doesn't work as that seems to stop GIMPLE unrolling
and does it at RTL instead.

At the moment a way for the user to locally control the unroll amount would
already be a good step. I know there's the param, but that's global and
typically the unroll factor would depend on the GEMM kernel.

[Bug driver/109605] -fno-tree-vectorize does not disable vectorizer

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |driver

--- Comment #1 from Richard Biener  ---
You mean -ftree-slp-vectorize -fno-tree-vectorize doesn't disable SLP
vectorization?  I suspect this is since we use EnabledBy() which
doesn't seem to imply a DisabledBy() of the negative form(?).

[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible

2023-04-24 Thread avieira at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from avieira at gcc dot gnu.org ---
Err that should be 'double d[4];' so:
typedef struct 
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;

#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
{
STRUCT s;
double d[4];
} TYPE;
#endif

[Bug target/66207] Switch alpha to LRA

2023-04-24 Thread ubizjak at gmail dot com via Gcc-bugs

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #11)
> I wonder if we can for simplicity deprecate non EV6 ... does any other
> existing architecture use this functionality?

To be more precise: is there a target that synthesizes sub-word (8/16-bit)
memory access from instructions that use word-sized (32-bit) access? Including
basic moves to/from memory.

[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible

2023-04-24 Thread avieira at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from avieira at gcc dot gnu.org ---
Sorry for the delay. Here's the typedefs with GNU vectors.  

typedef struct 
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;

#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
{
STRUCT s;
double d[2];
} TYPE;
#endif

To be fair I suspect you could see similar behaviour with just 16-byte vectors,
but with aarch64 the backend will know to use 64-bit scalar moves for 128-bit
BLKmodes, though even then, picking the vector mode would result in more
optimal (single vector move) code.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Jakub Jelinek  ---
Ah, but that actually isn't the problem, rather just useless clutter.
The problem is that
(jump_insn 10 7 32 2 (parallel [
(set (pc)
(if_then_else (eq (and:DI (reg:DI 9 9 [121])
(const_int 2146435072 [0x7ff0]))
(const_int 0 [0]))
(label_ref:SI 40)
(pc)))
(clobber (reg:DI 9 9 [125]))
(clobber (reg:CC 100 0))
]) "pr109566-3.c":6:6 229 {*branch_anddi3_dot}
 (int_list:REG_BR_PROB 708669604 (nil))
 -> 40)
is split into:
(insn 43 7 44 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [121])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [125]))
]) "pr109566-3.c":6:6 -1
 (nil))
(jump_insn 44 43 32 2 (set (pc)
(if_then_else (eq:CCEQ (reg:CC 100 0)
(const_int 0 [0]))
(label_ref 40)
(pc))) "pr109566-3.c":6:6 -1
 (int_list:REG_BR_PROB 708669604 (nil))
 -> 40)
and the first instruction isn't recognized.

[Bug target/66207] Switch alpha to LRA

2023-04-24 Thread ubizjak at gmail dot com via Gcc-bugs

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Uroš Bizjak from comment #6)
> > So, LRA testresults are clean on alphaev68-linux-gnu.
> 
> Please note that the above applies to alpha*EV6*, not plain alpha.
> 
> Plain alpha is !BWX architecture and uses {un,}aligned_memory_operand
> predicates that call resolve_reload_operand function. Unfortunately, this
> function peeks deep into reload internals (reg_equiv_memory_loc) that has no
> equivalent in LRA. As said in the function comment, this internal function
> resolves what reload is going to do with OP if it is a register.

In addition, non-BWX targets use find_replacement, another reload-specific
function, and several other hacks when reload_in_progress is active.

[Bug target/66207] Switch alpha to LRA

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Richard Biener  ---
I wonder if we can for simplicity deprecate non EV6 ... does any other existing
architecture use this functionality?

[Bug tree-optimization/109604] [14 Regression] ICE during GIMPLE pass: phiopt since r14-169-g84325f1c6aa3c5

2023-04-24 Thread marxin at gcc dot gnu.org via Gcc-bugs

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

Martin Liška  changed:

   What|Removed |Added

Summary|[14 Regression] ice during  |[14 Regression] ICE during
   |GIMPLE pass: phiopt |GIMPLE pass: phiopt since
   ||r14-169-g84325f1c6aa3c5
   Last reconfirmed||2023-04-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r14-169-g84325f1c6aa3c5.

[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #21 from Richard Biener  ---
aliasing_component_refs_p seems to try handle trailing arrays via
component_ref_to_zero_sized_trailing_array_p.  It properly detects

f_5->fam[0].n

but fails on

MEM[(struct P *)f_3(D) + 8B].n

but it would also in all cases happily continue with the base ref type
when comparing sizes:

  /* Now search for the type1 in the access path of ref2.  This
 would be a common base for doing offset based disambiguation on.
 This however only makes sense if type2 is big enough to hold type1.  */
  int cmp_outer = compare_type_sizes (type2, type1);

I also wonder if

  /* If we didn't find a common base, try the other way around.  */
  if (cmp_outer <= 0
  || (end_struct_ref1
  && compare_type_sizes (TREE_TYPE (end_struct_ref1), type1) <= 0))

here type1 shouldn't be type2?

In any case we end up failing the access_path_may_continue_p checks and
disambiguate.

diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index 81bc51ed4ad..8a1ec9091fa 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -1330,7 +1330,7 @@ aliasing_component_refs_p (tree ref1,
   /* If we didn't find a common base, try the other way around.  */
   if (cmp_outer <= 0 
   || (end_struct_ref1
- && compare_type_sizes (TREE_TYPE (end_struct_ref1), type1) <= 0))
+ && compare_type_sizes (TREE_TYPE (end_struct_ref1), type2) <= 0))
 {
   int res = aliasing_component_refs_walk (ref2, type2, base2,
  offset2, max_size2,

seems to fix the testcase - can anybody confirm?

Honza, is that indeed a typo or do I just hide the issue?

[Bug tree-optimization/109605] New: -fno-tree-vectorize does not disable vectorizer

2023-04-24 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109605
   Summary: -fno-tree-vectorize does not disable vectorizer
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

-ftree-vectorize enables -ftree-slp-vectorize and -ftree-loop-vectorize however
-fno-tree-vectorize does not disable them.  This is quite counter-intuitive and
at least I got caught in this trap while doing some benchmarking.

[Bug c/109598] ICE: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc

2023-04-24 Thread marxin at gcc dot gnu.org via Gcc-bugs

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

Martin Liška  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-3278-g823685221de986.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||yinyuefengyi at gmail dot com

--- Comment #9 from Jakub Jelinek  ---
Ah, it ICEs on powerpc64-linux too, with -m32 -O2 -mpowerpc64 -mcpu=power3 (or
10 etc.),
-mpowerpc64 is what matters.
In *.postreload we have
(jump_insn 10 7 32 2 (parallel [
(set (pc)
(if_then_else (eq (and:DI (reg:DI 9 9 [121])
(const_int 2146435072 [0x7ff0]))
(const_int 0 [0]))
(label_ref:SI 40)
(pc)))
(clobber (reg:DI 9 9 [125]))
(clobber (reg:CC 100 0))
]) "pr109566-3.c":6:6 229 {*branch_anddi3_dot}
 (int_list:REG_BR_PROB 708669604 (nil))
The define_insn_and_split has been introduced already in GCC 12 in PR102239
r12-6433
and I'd say it is just wrong, the FAIL part doesn't belong there, that is an
ICE if for a define_insn_and_split with "#" the splitter part FAILs.
The condition on the instruction or predicates/constraints should make sure it
is splittable.

[Bug target/66207] Switch alpha to LRA

2023-04-24 Thread ubizjak at gmail dot com via Gcc-bugs

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> So, LRA testresults are clean on alphaev68-linux-gnu.

Please note that the above applies to alpha*EV6*, not plain alpha.

Plain alpha is !BWX architecture and uses {un,}aligned_memory_operand
predicates that call resolve_reload_operand function. Unfortunately, this
function peeks deep into reload internals (reg_equiv_memory_loc) that has no
equivalent in LRA. As said in the function comment, this internal function
resolves what reload is going to do with OP if it is a register.

[Bug c/66425] (void) cast doesn't suppress attribute((warn_unused_result))

2023-04-24 Thread achurch+gcc at achurch dot org via Gcc-bugs

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

--- Comment #53 from Andrew Church  ---
(In reply to Segher Boessenkool from comment #51)
> And that is the core of why this issue reinflames once in a while: some
> people
> abuse the attribute, and the compiler cannot read minds.

Ah, for a mindread() API...

But ultimately, this is why I suggest that the compiler should leave as many
decisions as possible to the end user (in this case, the API user as opposed to
the API developer) - if the user has decided a particular result is safe to
ignore, then anything the compiler tries to do to stop that is just an
annoyance to be worked around or outright disabled.

> Completely useless casts to void cluttered programs decades ago already,
> we do not fear cargo cult, instead we observed it already existed.

At the risk of starting a linguistic discussion, the phrase you're looking for
is not "cargo cult", but "idiomatic".  Using "(void)" to mean "I am explicitly
discarding this value" is idiomatic, much the same way as "goodbye" is an
idiomatic greeting and not a literal wish for God to be with the listener.  I'm
probably not as old as some developers here, but I'm certainly old enough to
remember some compilers which gleefully spit out warnings on practically every
non-void expression, and liberal use of (void) was needed if you wanted any
chance at seeing the useful warnings.

"Cargo cult" programming is when people start using (void) without even knowing
what it does:  "Hey, so what does this 'void' thing do?"  "Uh, I dunno, it's
all over the code so I just copied it."  I wouldn't be surprised to find cases
of that as well, but I don't think that's the specific thing we're worried
about here.

> Changing the behaviour of this attribute after all that time will not make
> things better.  But perhaps we can say a bit more in the documentation,
> maybe at one of the three very concise quotes above?  Say half a line worth?

If glibc changes from _wur to [[nodiscard]], as Florian suggested may happen,
that would resolve the immediate case that brought me here (a "best-effort"
system() call, where the success or failure of the call or the program executed
is irrelevant to the caller).  I do fear leaving the current behavior as is
could just be kicking the can down the road, so to speak, but perhaps a slight
edit here might help:

> 'warn_unused_result'
>  The 'warn_unused_result' attribute causes a warning to be emitted
>  if a caller of the function with this attribute does not use its
>  return value.  This is useful for functions where not checking the
>  result is either a security problem or always a bug, such as
>  'realloc'.

I would suggest removing "either a security problem or", and adding something
along the lines of:

"For cases in which not checking the result carries risks but is not
necessarily an error, use the [[nodiscard]] attribute, which allows the caller
to suppress the warning by explicitly casting the result to void."

Writing user documentation isn't (remotely!) my specialty, but I think
something like this could both help clarify that the two behave differently and
let people know that yes, the fact that you can't silence _wur calls is
intentional.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Jakub Jelinek  ---
Ah, --target powerpc-rtems6 reproduces it, wonder what is different here.
Reduced testcase:
void
foo (double x)
{
  union { double d; unsigned i; } u;
  u.d = x;
  if (u.i & 2146435072)
return;
  else
for (;;)
  ;
}

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2023-04-24 Thread ktkachov at gcc dot gnu.org via Gcc-bugs

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

Bug 109406 Summary: Missing use of aarch64 SVE2 unpredicated integer multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109406

   What|Removed |Added

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

[Bug target/109406] Missing use of aarch64 SVE2 unpredicated integer multiply

2023-04-24 Thread ktkachov at gcc dot gnu.org via Gcc-bugs

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 14

[Bug target/109406] Missing use of aarch64 SVE2 unpredicated integer multiply

2023-04-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

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

commit r14-193-g9fd4a38c2f30b72ad5e3df7acb1ade201d8ac2cd
Author: Kyrylo Tkachov 
Date:   Mon Apr 24 10:27:31 2023 +0100

aarch64: PR target/109406 Add support for SVE2 unpredicated MUL

SVE2 supports an unpredicated vector integer MUL form that we can emit from
our SVE expanders
without using up a predicate registers. This patch does so.
As the SVE MUL expansion currently is templated away through a code
iterator I did not split it
off just for this case but instead special-cased it in the define_expand.
It seemed somewhat less
invasive than the alternatives but I could split it off more explicitly if
others want to.
The div-by-bitmask_1.c testcase is adjusted to expect this new MUL form.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

PR target/109406
* config/aarch64/aarch64-sve.md (3): Handle
TARGET_SVE2 MUL
case.
* config/aarch64/aarch64-sve2.md
(*aarch64_mul_unpredicated_): New
pattern.

gcc/testsuite/ChangeLog:

PR target/109406
* gcc.target/aarch64/sve2/div-by-bitmask_1.c: Adjust for
unpredicated SVE2
MUL.
* gcc.target/aarch64/sve2/unpred_mul_1.c: New test.

[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Richard Biener  ---
This goes wrong in update_address_taken before into-SSA which removes
TREE_ADDRESSABLE from 'v' without transforming it in any way.

 :
D.3193 = VIEW_CONVERT_EXPR(v)[18446744073709551615];
return D.3193;

update_address_taken uses maybe_rewrite_mem_ref_base to rewrite rvalues
but that leaves all outer handled components in place - in fact it
even puts a VIEW_CONVERT_EXPR around it.

For a "valid" testcase

typedef int v4si __attribute__((vector_size(16)));

int foo (v4si v)
{
  return v[1];
}

the frontend produces

  return VIEW_CONVERT_EXPR(v)[1];

and we then gimplify it to

  D.2755 = BIT_FIELD_REF ;

via folding the stmt and maybe_canonicalize_mem_ref_addr, but we refrain from
doing that for out-of-bound accesses.

We do not have good IL verification for the differences between valid GIMPLE
and valid GIMPLE SSA - verify_gimple_* verifies GIMPLE and verify_ssa
doesn't apply any additional IL constraints.

I think we do not want ARRAY_REF of SSA_NAMEs nor do we want multi-level
handled_components on SSA_NAMEs.

Either we have to be way more aggressive in rewriting the refs
(use get_ref_base_and_extent?) to BIT_FIELD_REFs or in this case to
in-bound refs or zero or we have to restrict the rewrite to the cases
we already handle (which is very few special cases around MEM_REF[]).

I'm trying to see what doing the latter regresses.

[Bug c/66425] (void) cast doesn't suppress attribute((warn_unused_result))

2023-04-24 Thread jengelh at inai dot de via Gcc-bugs

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

--- Comment #52 from Jan Engelhardt  ---
>This is useful for functions where not checking the
>result is either a security problem or always a bug, such as
>'realloc'.

always? reall..y..oc?

  void *x = malloc(1);
  realloc(x, 0);

[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Yes.

[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d

2023-04-24 Thread marxin at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Martin Liška  ---
Fixed now?

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread sebastian.huber--- via Gcc-bugs

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

--- Comment #7 from Sebastian Huber  ---
(In reply to Jakub Jelinek from comment #6)
> How have you configured gcc?  I certainly can't reproduce this with
> --enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
> --with-cpu-64=power7 --with-long-double-128 --enable-checking=release
> --target=powerpc64-linux-gnu --enable-languages=c,c++,fortran,lto
> nor
> --target powerpc-linux --enable-languages=c,c++
> configured gccs.

I notices this issue with the powerpc-rtems6 target while building Newlib. Can
you compile the test case with your compiler?

I was able to reproduce the error with the powerpc-elf target:

powerpc-elf-gcc -O2  -mcpu=power10 -c test.c
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c: In function '__ieee754_fmod':
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: error: unrecognizable
insn:
   32 | }
  | ^
(insn 49 8 50 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [123])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [127]))
]) "/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c":21:4 -1
 (nil))
during RTL pass: split2
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: internal compiler error:
in extract_insn, at recog.cc:2791
0x40730a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:108
0x407329 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:116
0x957257 extract_insn(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2791
0x9572b1 extract_insn_cached(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2680
0x6a99ab cleanup_subreg_operands(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/final.cc:3054
0x95561c split_insn
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3420
0x95a392 split_all_insns()
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3488
0x95a4a8 execute
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:4412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/66425] (void) cast doesn't suppress attribute((warn_unused_result))

2023-04-24 Thread segher at gcc dot gnu.org via Gcc-bugs

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

--- Comment #51 from Segher Boessenkool  ---
(In reply to rusty from comment #47)
> Civility please.

Thank you.

> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point.  The use of _wur has changed from "ignoring
> the result is criminally wrong" to "possibly wrong".

And that is the core of why this issue reinflames once in a while: some people
abuse the attribute, and the compiler cannot read minds.


The documentation of this attribute states
'warn_unused_result'
 The 'warn_unused_result' attribute causes a warning to be emitted
 if a caller of the function with this attribute does not use its
 return value.  This is useful for functions where not checking the
 result is either a security problem or always a bug, such as
 'realloc'.

The "non-bugs" section of the manual ("Certain Changes We Don't Want to Make"
says
   * Warning when a non-void function value is ignored.

 C contains many standard functions that return a value that most
 programs choose to ignore.  One obvious example is 'printf'.
 Warning about this practice only leads the defensive programmer to
 clutter programs with dozens of casts to 'void'.  Such casts are
 required so frequently that they become visual noise.  Writing
 those casts becomes so automatic that they no longer convey useful
 information about the intentions of the programmer.  For functions
 where the return value should never be ignored, use the
 'warn_unused_result' function attribute (*note Function
 Attributes::).

Completely useless casts to void cluttered programs decades ago already,
we do not fear cargo cult, instead we observed it already existed.

And finally there is
'-Wno-unused-result'
 Do not warn if a caller of a function marked with attribute
 'warn_unused_result' (*note Function Attributes::) does not use its
 return value.  The default is '-Wunused-result'.

A caller that casts a return value to void *explicitly* does not use that
return value.


> I still put a comment complaining about this every time I hit it, which is
> about once or twice a year.  But I have little more to say; it's been almost
> 20 year after all :)

Changing the behaviour of this attribute after all that time will not make
things better.  But perhaps we can say a bit more in the documentation,
maybe at one of the three very concise quotes above?  Say half a line worth?

[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
On the #c5 testcase on x86_64 at -O2 this bisects to
r10-514-gc6b84edb6110dd2b4fb

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
How have you configured gcc?  I certainly can't reproduce this with
--enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
--with-cpu-64=power7 --with-long-double-128 --enable-checking=release
--target=powerpc64-linux-gnu --enable-languages=c,c++,fortran,lto
nor
--target powerpc-linux --enable-languages=c,c++
configured gccs.

[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

2023-04-24 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

--- Comment #19 from Alexander Monakov  ---
Manually minimized testcase for investigation, miscompiled at -O2:

struct P {
long v;
struct P *n;
};

struct F {
long x;
struct P fam[];
};

int f(struct F *f, int i)
{
struct P *p = f->fam;
asm("" : "+r"(f): "r"(p));
p->v = 0;
p->n = 0;
return f->fam->n != 0;
}

Trunk emits:
f:
lea rdx, [rdi+8]
mov rax, rdi
mov QWORD PTR [rdi+8], 0
cmp QWORD PTR [rax+16], 0
mov QWORD PTR [rdi+16], 0
setne   al
movzx   eax, al
ret

1 2 >

1 - 100 of 122 matches

Mail list logo