[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
Possibly relevant to Florian Weimer's work on stricter warnings

Re: [PATCH] Improved RTL expansion of 1LL << x.

[Jeff Law]

On 10/14/23 17:32, Roger Sayle wrote:


This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.

Consider the general case, x << y, which is expanded well as:

 t1 = y & 32;
 t2 = 0;
 t3 = x_lo >> 1;
 t4 = y ^ ~0;
 t5 = t3 >> t4;
 tmp_hi = x_hi << y;
 tmp_hi |= t5;
 tmp_lo = x_lo << y;
 out_hi = t1 ? tmp_lo : tmp_hi;
 out_lo = t1 ? t2 : tmp_lo;

which is nearly optimal, the only thing that can be improved is
that using a unary NOT operation "t4 = ~y" is better than XOR
with -1, on targets that support it.  [Note the one_cmpl_optab
expander didn't fall back to XOR when this code was originally
written, but has been improved since].

Now consider the relatively common idiom of 1LL << y, which
currently produces the RTL equivalent of:

 t1 = y & 32;
 t2 = 0;
 t3 = 1 >> 1;
 t4 = y ^ ~0;
 t5 = t3 >> t4;
 tmp_hi = 0 << y;
 tmp_hi |= t5;
 tmp_lo = 1 << y;
 out_hi = t1 ? tmp_lo : tmp_hi;
 out_lo = t1 ? t2 : tmp_lo;

Notice here that t3 is always zero, so the assignment of t5
is a variable shift of zero, which expands to a loop on many
smaller targets, a similar shift by zero in the first tmp_hi
assignment (another loop), that the value of t4 is no longer
required (as t3 is zero), and that the ultimate value of tmp_hi
is always zero.

Fortunately, for many (but perhaps not all) targets this mess
gets cleaned up by later optimization passes.  However, this
patch avoids generating unnecessary RTL at expand time, by
calling simplify_expand_binop instead of expand_binop, and
avoiding generating dead or unnecessary code when intermediate
values are known to be zero.  For the 1LL << y test case above,
we now generate:

 t1 = y & 32;
 t2 = 0;
 tmp_hi = 0;
 tmp_lo = 1 << y;
 out_hi = t1 ? tmp_lo : tmp_hi;
 out_lo = t1 ? t2 : tmp_lo;

On arc-elf, for example, there are 18 RTL INSN_P instructions
generated by expand before this patch, but only 12 with this patch
(improving both compile-time and memory usage).


This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2023-10-15  Roger Sayle  

gcc/ChangeLog
 * optabs.cc (expand_subword_shift): Call simplify_expand_binop
 instead of expand_binop.  Optimize cases (i.e. avoid generating
 RTL) when CARRIES or INTO_INPUT is zero.  Use one_cmpl_optab
 (i.e. NOT) instead of xor_optab with ~0 to calculate ~OP1.

OK.

FWIW H8 is another one of the targets where variable shifts have to be 
implemented as a loop.


Jeff

[Committed] RISC-V: Fix vsingle attribute

[Juzhe-Zhong]

RVVM2x2QI should be rvvm2qi instead of rvvmq1i.

gcc/ChangeLog:

* config/riscv/vector-iterators.md: Fix vsingle incorrect attribute for 
RVVM2x2QI.

---
 gcc/config/riscv/vector-iterators.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/vector-iterators.md 
b/gcc/config/riscv/vector-iterators.md
index 6800f8d3d76..0850475edc1 100644
--- a/gcc/config/riscv/vector-iterators.md
+++ b/gcc/config/riscv/vector-iterators.md
@@ -2230,7 +2230,7 @@
   (RVVM1x5QI "rvvm1qi") (RVVMF2x5QI "rvvmf2qi") (RVVMF4x5QI "rvvmf4qi") 
(RVVMF8x5QI "rvvmf8qi")
   (RVVM2x4QI "rvvm2qi") (RVVM1x4QI "rvvm1qi") (RVVMF2x4QI "rvvmf2qi") 
(RVVMF4x4QI "rvvmf4qi") (RVVMF8x4QI "rvvmf8qi")
   (RVVM2x3QI "rvvm2qi") (RVVM1x3QI "rvvm1qi") (RVVMF2x3QI "rvvmf2qi") 
(RVVMF4x3QI "rvvmf4qi") (RVVMF8x3QI "rvvmf8qi")
-  (RVVM4x2QI "rvvm4qi") (RVVM2x2QI "rvvm1qi") (RVVM1x2QI "rvvm1qi") 
(RVVMF2x2QI "rvvmf2qi") (RVVMF4x2QI "rvvmf4qi") (RVVMF8x2QI "rvvmf8qi")
+  (RVVM4x2QI "rvvm4qi") (RVVM2x2QI "rvvm2qi") (RVVM1x2QI "rvvm1qi") 
(RVVMF2x2QI "rvvmf2qi") (RVVMF4x2QI "rvvmf4qi") (RVVMF8x2QI "rvvmf8qi")
 
   (RVVM1x8HI "rvvm1hi") (RVVMF2x8HI "rvvmf2hi") (RVVMF4x8HI "rvvmf4hi")
   (RVVM1x7HI "rvvm1hi") (RVVMF2x7HI "rvvmf2hi") (RVVMF4x7HI "rvvmf4hi")
-- 
2.36.3

[Bug target/111492] RISC-V: Dynamic LMUL picking incorrect LMUL

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #1 from JuzheZhong  ---
Fixed

[Bug middle-end/111821] [11/12/13/14 Regression] OOM with packed struct and stack variable with copy

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

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

--- Comment #2 from Andrew Pinski  ---
Note smaller #s decrease the memory usage and compiles faster but still uses a
lot of memory.

Going from 0x100 to 0x200:
 expand :   0.60 (100%)   0.06 (100%)   0.70 ( 97%)
  271M ( 99%)

 expand :   1.99 ( 98%)   0.22 (100%)   2.20 ( 96%)
  543M (100%)

As you can see double the memory usage.

[Bug middle-end/111821] [11/12/13/14 Regression] OOM with packed struct and stack variable with copy

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
here is a testcase where it happens at -O1 and above (and not just -Og):
```
typedef union { char a[1003263430]; }
__attribute__((__packed__)) T;
unsigned short f(const void *p) {
unsigned short v;
*(T *)(void *)() = *(const T *)p;
return v;
}

```

Confirmed.

[Bug middle-end/111821] [11/12/13/14 Regression] OOM with packed struct and stack variable with copy

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |11.5
  Known to work||10.1.0, 10.5.0
Summary|GCC: 14: continue to|[11/12/13/14 Regression]
   |consume memory until OOM|OOM with packed struct and
   ||stack variable with copy
  Known to fail||11.1.0, 12.3.0

[Bug target/85152] VAX ICE with -O2

[macro at orcam dot me.uk via Gcc-bugs]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||macro at orcam dot me.uk
 Resolution|--- |FIXED

--- Comment #2 from Maciej W. Rozycki  ---
Fixed with commit b3f3bba3fa08 ("VAX: Ensure PIC mode address is
adjustable with aligned bit-field insns").

[Bug c/111821] New: GCC: 14: continue to consume memory until OOM

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111821
   Summary: GCC: 14: continue to consume memory until OOM
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The bug triggering program:
```
typedef union { char a[1003263430]; }
__attribute__((__packed__)) T;
void f(const void *p) {
unsigned short v;
*(T *)(void *)() = *(const T *)p;
}
```

When compile it with `gcc -Og`, gcc used up 8GB of memory on my computer, but
when compile with other options like `-Os`, it normally returns.

Compiler Explorer: https://godbolt.org/z/73n953Y3j

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

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

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

--- Comment #22 from Jerry DeLisle  ---
Sorry for delays.  I am back looking at this.

My take on the table 13.2 for the case: EN0.0E0

No matter what the E for the exponent must be shown.

If the exponent is 0 then a plus sign must be shown.

The value for 666. then must be 666.E+0

[Bug tree-optimization/111820] [13/14 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||11.1.0, 12.1.0, 12.3.0,
   ||9.1.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.3
   Last reconfirmed||2023-10-15
  Known to fail||13.1.0, 14.0
Summary|GCC: 14: hangs with a   |[13/14 Regression] Compiler
   |simple while loop   |time hog in the vectorizer
   ||with `-O3 -fno-tree-vrp`
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/111820] GCC: 14: hangs with a simple while loop

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

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

--- Comment #1 from Andrew Pinski  ---
Looks to be the vectorizer:
#0  0x012d1fe5 in wide_int_storage::operator= (x=..., this=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/wide-int.h:1221
#1  generic_wide_int::operator= (this=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/wide-int.h:775
#2  vect_peel_nonlinear_iv_init (stmts=0x7fffd1c0,
init_expr=0x779dbbd0, skip_niters=,
step_expr=0x779bad38, induction_type=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vect-loop.cc:9138
#3  0x012f5322 in vect_update_ivs_after_vectorizer
(loop_vinfo=0x3181a90, niters=0x779e60c0, update_e=0x779d5ba0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vect-loop-manip.cc:2028
#4  0x012fec74 in vect_do_peeling
(loop_vinfo=loop_vinfo@entry=0x3181a90, niters=,
niters@entry=0x779bad50, nitersm1=nitersm1@entry=0x779e0b40,
niters_vector=niters_vector@entry=0x7fffd700,
step_vector=step_vector@entry=0x7fffd708,
niters_vector_mult_vf_var=niters_vector_mult_vf_var@entry=0x7fffd710,
th=, check_profitability=,
niters_no_overflow=, advance=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vect-loop-manip.cc:3370
#5  0x012f01a9 in vect_transform_loop
(loop_vinfo=loop_vinfo@entry=0x3181a90,
loop_vectorized_call=loop_vectorized_call@entry=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vect-loop.cc:11386
#6  0x01331bec in vect_transform_loops (simduid_to_vf_htab=, loop=0x778054b0, loop_vectorized_call=0x0, fun=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vectorizer.cc:1004
#7  0x013321ed in try_vectorize_loop_1 (fun=0x779d6000,
loop_dist_alias_call=0x0, loop_vectorized_call=0x0, loop=0x778054b0,
num_vectorized_loops=0x7fffdacc, simduid_to_vf_htab=@0x7fffdad0: 0x0)
at /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vectorizer.cc:1150
#8  try_vectorize_loop (simduid_to_vf_htab=@0x7fffdad0: 0x0,
num_vectorized_loops=0x7fffdacc, loop=0x778054b0, fun=0x779d6000)
at /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vectorizer.cc:1180
#9  0x01332845 in (anonymous namespace)::pass_vectorize::execute
(this=, fun=0x779d6000) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vectorizer.cc:1296

[Bug c/111820] New: GCC: 14: hangs with a simple while loop

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111820
   Summary: GCC: 14: hangs with a simple while loop
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/ezdG5GGd8

When compile below program with option `-O3 -fno-tree-vrp`, GCC consumes upto
46 seconds to finish:
```
int r;
int r_0;

void f (void)
{
  int n = 0;
  while (-- n)
{
  r_0 += r ;
  r  += r;
  r  += r ;
  r  += r ;
  r  >= r ;
  r  += r ;
}
}
```

[Bug c/105555] ICE: in fold_offsetof, at c-family/c-common.cc:6815

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||141242068 at smail dot 
nju.edu.cn

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

[Bug c/111819] GCC: 14: internal compiler error: in fold_offsetof, at c-family/c-common.cc:6877

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/111818] [11/12/13/14 Regression] ICE with __builtin_memcpy with volatile and constants

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.9.1
  Known to fail||10.1.0, 5.1.0
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-15
Summary|GCC: 14: internal compiler  |[11/12/13/14 Regression]
   |error: tree check: expected |ICE with __builtin_memcpy
   |tree that contains 'decl|with volatile and constants
   |common' structure, have |
   |'integer_cst' in|
   |tree_could_trap_p, at   |
   |tree-eh.cc:2733 |
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Even though GCC 11.x and 12.x and 13.x don't ICE without checking enabled. The
IR is still invalid:
  _9 ={v} MEM  [(char * {ref-all})&305419896];

That is just wrong.

[Bug c/111819] New: GCC: 14: internal compiler error: in fold_offsetof, at c-family/c-common.cc:6877

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111819
   Summary: GCC: 14: internal compiler error: in fold_offsetof, at
c-family/c-common.cc:6877
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The bug triggering program:
```
long long a;
void f(_Complex double x) {
  (int *)&__imag(
  *(_Complex double *)((char *) + 16));
}
```

This bug can be verified at: https://godbolt.org/z/6d98f8YT7

The full stack dump:
```
: In function 'f':
:4:7: internal compiler error: in fold_offsetof, at
c-family/c-common.cc:6877
4 |   *(_Complex double *)((char *) + 16));
  |   ^
0x22ff3ee internal_error(char const*, ...)
???:0
0x9fc0a8 fancy_abort(char const*, int, char const*)
???:0
0xa4f1d8 build_unary_op(unsigned int, tree_code, tree_node*, bool)
???:0
0xa5c176 parser_build_unary_op(unsigned int, tree_code, c_expr)
???:0
0xaa468d c_parse_file()
???:0
0xb17919 c_common_parse_file()
???:0
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/111818] New: GCC: 14: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in tree_could_trap_p, at tree-eh.cc:2733

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111818
   Summary: GCC: 14: internal compiler error: tree check: expected
tree that contains 'decl common' structure, have
'integer_cst' in tree_could_trap_p, at tree-eh.cc:2733
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

When compile below program with GCC-14 and option `-O1`, GCC-14 crashes:
```
#define DUMMY_VALUE 0x12345678
static void foo(const volatile unsigned int x, void *p) {
  __builtin_memcpy(p, , sizeof x);
  __builtin_memcpy(p, , sizeof x);
}

void bar(int type, void *number) {
  switch (type) {
  case 1: foo(DUMMY_VALUE, number); break;
  case 7: foo(0, number); break;
  case 8: foo(0, number); break;
  case 9: foo(0, number); break;
  }
}
```

The crash reproducer: https://godbolt.org/z/7sP8zc3Kc

And the full stack dump:
```
: In function 'foo':
:3:23: warning: passing argument 2 of '__builtin_memcpy' discards
'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
3 |   __builtin_memcpy(p, , sizeof x);
  |   ^~
:3:23: note: expected 'const void *' but argument is of type 'const
volatile unsigned int *'
:4:23: warning: passing argument 2 of '__builtin_memcpy' discards
'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
4 |   __builtin_memcpy(p, , sizeof x);
  |   ^~
:4:23: note: expected 'const void *' but argument is of type 'const
volatile unsigned int *'
during RTL pass: expand
In function 'foo',
inlined from 'bar' at :9:11:
:3:3: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'integer_cst' in tree_could_trap_p, at
tree-eh.cc:2733
3 |   __builtin_memcpy(p, , sizeof x);
  |   ^
0x22ff3ee internal_error(char const*, ...)
???:0
0x8a8243 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0xc9ab0e set_mem_attributes_minus_bitpos(rtx_def*, tree_node*, int,
poly_int<1u, long>)
???:0
0xcc6c35 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xcd3083 store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
0xcd4d66 expand_assignment(tree_node*, tree_node*, bool)
???:0
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 target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

[macro at orcam dot me.uk via Gcc-bugs]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-10-15

[Bug modula2/111756] Re-building all-gcc after source changes fails to link

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 56114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56114=edit
Proposed patch implementing the dependency options for gm2/cc1gm2

This proposed patch implements -M, -MM, -MF, -MT, -MQ.

It probably also needs -MP, -MD, -MMD (to be done in the next patch).

[Bug c/111817] New: GCC: 14: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3389

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111817
   Summary: GCC: 14: internal compiler error: in expand_asm_stmt,
at cfgexpand.cc:3389
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The bug triggering program:
```
static int foo(int x, int y, int z) {
  int b;
  asm("" : "=a"(b), "\n="(x) : "0"(y), "1"(x), "mr"(z));
  return x;
}
```

The crash can be verfied at link: https://godbolt.org/z/6d7csd8xv

The full stack dump:
```
: In function 'foo':
:3:3: warning: output constraint '=' for operand 1 is not at the
beginning
3 |   asm("" : "=a"(b), "\n="(x) : "0"(y), "1"(x), "mr"(z));
  |   ^~~
:3:3: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
1 | static int foo(int x, int y, int z) {
  |^~~
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:1:12: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
5 | }
  | ^
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output constraint '=' for operand 1 is not at the
beginning
:5:1: warning: output 

[Bug c/111816] ICE with _GIMPLE and 2 returns

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
Summary|GCC: 14: internal compiler  |ICE with _GIMPLE and 2
   |error: Segmentation fault   |returns
   |at  |
   |c_parser_parse_gimple_body  |

--- Comment #1 from Andrew Pinski  ---
Note even though the gimple FE exists, it is mainly designed ONLY for testsuite
usage and that there will be many corner cases like this where code will cause
an ICE rather than be rejected for being invalid.

[Bug c/111816] New: GCC: 14: internal compiler error: Segmentation fault at c_parser_parse_gimple_body

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111816
   Summary: GCC: 14: internal compiler error: Segmentation fault
at c_parser_parse_gimple_body
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

When compile this program with GCC-14, GCC crashes:
```
__GIMPLE (ssa) int foo (int *a)
{
  return 0;
  return 0;
}
```

Compiler Explorer: https://godbolt.org/z/zecdo68WE

The full stack dump:
```
: In function 'foo':
:5:1: internal compiler error: Segmentation fault
5 | }
  | ^
0x22ff3ee internal_error(char const*, ...)
???:0
0xaad8ac c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
???:0
0xaa468d c_parse_file()
???:0
0xb17919 c_common_parse_file()
???:0
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/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-October
   ||/633012.html
   Keywords||patch

--- Comment #4 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633012.html

[Bug c/101285] [11/12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-October
   ||/633013.html

--- Comment #6 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633013.html

[PATCH 1/2] Fix ICE due to c_safe_arg_type_equiv_p not checking for error_mark node

[Andrew Pinski]

This is a simple error recovery issue when c_safe_arg_type_equiv_p
was added in r8-5312-gc65e18d3331aa999. The issue is that after
an error, an argument type (of a function type) might turn
into an error mark node and c_safe_arg_type_equiv_p was not ready
for that. So this just adds a check for error operand for its
arguments before getting the main variant.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR c/101285

gcc/c/ChangeLog:

* c-typeck.cc (c_safe_arg_type_equiv_p): Return true for error
operands early.

gcc/testsuite/ChangeLog:

* gcc.dg/pr101285-1.c: New test.
---
 gcc/c/c-typeck.cc |  3 +++
 gcc/testsuite/gcc.dg/pr101285-1.c | 10 ++
 2 files changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr101285-1.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index e55e887da14..6e044b4afbc 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -5960,6 +5960,9 @@ handle_warn_cast_qual (location_t loc, tree type, tree 
otype)
 static bool
 c_safe_arg_type_equiv_p (tree t1, tree t2)
 {
+  if (error_operand_p (t1) || error_operand_p (t2))
+return true;
+
   t1 = TYPE_MAIN_VARIANT (t1);
   t2 = TYPE_MAIN_VARIANT (t2);
 
diff --git a/gcc/testsuite/gcc.dg/pr101285-1.c 
b/gcc/testsuite/gcc.dg/pr101285-1.c
new file mode 100644
index 000..831e35f7662
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101285-1.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-W -Wall" } */
+const int b;
+typedef void (*ft1)(int[b++]); /* { dg-error "read-only variable" } */
+void bar(int * z);
+void baz()
+{
+(ft1) bar; /* { dg-warning "statement with no effect" } */
+}
+
-- 
2.39.3

[PATCH 2/2] [c] Fix PR 101364: ICE after error due to diagnose_arglist_conflict not checking for error

[Andrew Pinski]

When checking to see if we have a function declaration has a conflict due to
promotations, there is no test to see if the type was an error mark and then 
calls
c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes an
ICE.

This adds a check for error before the call of c_type_promotes_to.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR c/101364

gcc/c/ChangeLog:

* c-decl.cc (diagnose_arglist_conflict): Test for
error mark before calling of c_type_promotes_to.

gcc/testsuite/ChangeLog:

* gcc.dg/pr101364-1.c: New test.
---
 gcc/c/c-decl.cc   | 3 ++-
 gcc/testsuite/gcc.dg/pr101364-1.c | 8 
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr101364-1.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 5822faf01b4..eb2df08c0a7 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -1899,7 +1899,8 @@ diagnose_arglist_conflict (tree newdecl, tree olddecl,
  break;
}
 
-  if (c_type_promotes_to (type) != type)
+  if (!error_operand_p (type)
+ && c_type_promotes_to (type) != type)
{
  inform (input_location, "an argument type that has a default "
  "promotion cannot match an empty parameter name list "
diff --git a/gcc/testsuite/gcc.dg/pr101364-1.c 
b/gcc/testsuite/gcc.dg/pr101364-1.c
new file mode 100644
index 000..e7c94a05553
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101364-1.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c90 "} */
+
+void fruit(); /* { dg-message "previous declaration" } */
+void fruit( /* { dg-error "conflicting types for" } */
+int b[x], /* { dg-error "undeclared " } */
+short c)
+{} /* { dg-message "an argument type that has a" } */
-- 
2.39.3

[Bug regression/111709] [13/14 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||jeffreyalaw at gmail dot com

--- Comment #12 from John David Anglin  ---
The miscompilation of s_fma.c was introduced by the following change:

dave@atlas:~/gnu/gcc/gcc$ git bisect good
8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit
commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

Convert DOM to use Ranger rather than EVRP

[Jeff, this is the same patch I sent you last week with minor tweaks
to the commit message.]

[Despite the verbosity of the message, this is actually a pretty
straightforward patch.  It should've gone in last cycle, but there
was a nagging regression I couldn't get to until after stage1
had closed.]

There are 3 uses of EVRP in DOM that must be converted.
Unfortunately, they need to be converted in one go, so further
splitting of this patch would be problematic.

There's nothing here earth shattering.  It's all pretty obvious in
retrospect, but I've added a short description of each use to aid in
reviewing:

* Convert evrp use in cprop to ranger.

  This is easy, as cprop in DOM was converted to the ranger API last
  cycle, so this is just a matter of using a ranger instead of an
  evrp_range_analyzer.

* Convert evrp use in threader to ranger.

  The idea here is to use the hybrid approach we used for the initial
  VRP threader conversion last cycle.  The DOM threader will continue
  using the forward threader infrastructure while continuing to query
  DOM data structures, and only if the conditional does not relsolve,
  using the ranger.  This gives us the best of both worlds, and is a
  proven approach.

  Furthermore, as frange and prange come live in the next cycle, we
  can move away from the forward threader altogether, and just add
  another backward threader.  This will not only remove the last use
  of the forward threader, but will allow us to remove at least 1 or 2
  threader instances.

* Convert conditional folding to use the method used by the ranger and
  evrp.  Previously DOM was calling into the guts of
  simplify_using_ranges::vrp_visit_cond_stmt.  The blessed way now is
  using fold_cond() which rewrites the conditional and edges
  automatically.

  When legacy is removed, simplify_using_ranges will be further
  cleaned up, and there will only be one entry point into simplifying
  a statement.

* DOM was setting global ranges determined from unreachable edges as a
  side-effect of using the evrp engine.  We must handle these cases
  before nuking evrp, and DOM seems like a good fit.  I've just moved
  the snippet to DOM, but it could live anywhere else we do a DOM
  walk.

  For the record, this is the case *vrp handled:

:
...
if (c_5(D) != 5)
goto ;
else
goto ;
:
__builtin_unreachable ();
:

  If M dominates all uses of c_5, we can set the global range of c_5
  to [5,5].

I have tested on x86-64, pcc64le, and aarch64 Linux.

I also ran threading benchmarks as well as performance benchmarks.

DOM threads 1.56% more paths which ultimately yields a miniscule total
increase of 0.03%.

The conversion to ranger brings a 7.87% performance drop in DOM, which
is a wash in overall compilation.  This is in line with other
replacements of legacy evrp with ranger.  We handle a lot more cases.
It's not free .

There is a a regression on Wstringop-overflow-4.C which I'm planning
on XFAILing.  It's another variant of the usual middle-end false
positives: having no ranges produces no warnings, but slightly refined
ranges, or worse-- isolating specific problematic cases in the
threader causes flare-ups.

As an aside, as Richi has suggested, I think we should discuss
restricting the threader's ability to thread highly unlikely paths.
These cause no end of pain for middle-end warnings.  However,
I don't know if this would conflict with path isolation for
things like null dereferencing.  ISTR you were interested in this.

BTW, I think the Wstringop-overflow-4.C test is problematic and I've
attached my analysis.  Basically the regression is caused by a bad
interaction with the rounding/alignment that placement new has inlined
into the IL.  This happens for int16_r[] which the test is testing.
Ranger can glean some range info, which causes DOM threading to
isolate a path which causes a warning.

[Bug target/54089] [SH] Refactor shift patterns

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

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

--- Comment #105 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #104)
> I've been thinking about something. I suspect that this patch could take
> work away from other patches. I'm sorry, I don't know how to express myself
> properly. I mean there's several patches that corrects shift patterns and
> 'tst' instruction generation (most of them are written by you, by the way).
> I suspect that some of them might not run anymore because this patch looks
> more general and should cover more cases, including yet unknown cases, I
> hope. And, in the end, dead code may appear because of it. I hope I was able
> to make my point clearly.

Yes, I understand what you're saying.  As other parts of the compiler evolve,
the RTL input that the backend code has to work with changes.  It's a normal
thing that happens during the course of development.  Some patterns might stop
working (especially those combine patterns are prone to that).  And sometimes
things magically start working because something got fixed somewhere else.

I've tried to add SH specific test cases to try and keep it in check.  Ideally
we'd have to go through all of the specific SH quirks in the backend
periodically, try to remove them one by one and run tests to see if the
patterns are still working/needed or whether they can be removed.

Let me know if you have more test cases (that work or don't work).

[Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 111815
   Summary: VAX: ICE in 'print_operand_address' while building
'elf_zstd_decompress' from libbacktrace/elf.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
  Assignee: macro at orcam dot me.uk
  Reporter: macro at orcam dot me.uk
  Target Milestone: ---
Target: vax-*-*

Created attachment 56113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56113=edit
VAX: Only accept the index scaler as the RHS operand to ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression")
GCC for the `vax-netbsdelf' target fails to complete building, with an
ICE:

during RTL pass: final
.../libbacktrace/elf.c: In function 'elf_zstd_decompress':
.../libbacktrace/elf.c:5006:1: internal compiler error: in
print_operand_address, at config/vax/vax.cc:514
 5006 | }
  | ^
0x1113df97 print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.cc:514
0x10c2489b default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.cc:373
0x106ddd0b output_address(machine_mode, rtx_def*)
.../gcc/final.cc:3648
0x106ddd0b output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3505
0x106e2143 output_asm_insn(char const*, rtx_def**)
.../gcc/final.cc:3421
0x106e2143 final_scan_insn_1
.../gcc/final.cc:2841
0x106e28e3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.cc:2887
0x106e2bf7 final_1
.../gcc/final.cc:1979
0x106e3c67 rest_of_handle_final
.../gcc/final.cc:4240
0x106e3c67 execute
.../gcc/final.cc:4318
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.

This is due to combine producing an invalid address RTX:

(plus:SI (ashift:SI (const_int 1 [0x1])
(reg:QI 3 %r3 [1232]))
(reg/v:SI 10 %r10 [orig:736 weight_mask ] [736]))

where the expression is ((1 << R3) + R10), which does not match a valid
machine address mode.  Consequently `print_operand_address' chokes.

The ultimate cause has been commit c605a8bf9270 ("VAX: Accept ASHIFT in
address expressions"), where a shift of an immediate value by a register
has been mistakenly allowed as an index expression as if the shift
operation was commutative such as multiplication is.  So with ASHIFT
the scaler in an index expression has to be the right-hand operand, and
the backend has to enforce that, whereas with MULT the scaler can be
either operand.

[PATCH] Improved RTL expansion of 1LL << x.

[Roger Sayle]

This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.

Consider the general case, x << y, which is expanded well as:

t1 = y & 32;
t2 = 0;
t3 = x_lo >> 1;
t4 = y ^ ~0;
t5 = t3 >> t4;
tmp_hi = x_hi << y;
tmp_hi |= t5;
tmp_lo = x_lo << y;
out_hi = t1 ? tmp_lo : tmp_hi;
out_lo = t1 ? t2 : tmp_lo;

which is nearly optimal, the only thing that can be improved is
that using a unary NOT operation "t4 = ~y" is better than XOR
with -1, on targets that support it.  [Note the one_cmpl_optab
expander didn't fall back to XOR when this code was originally
written, but has been improved since].

Now consider the relatively common idiom of 1LL << y, which
currently produces the RTL equivalent of:

t1 = y & 32;
t2 = 0;
t3 = 1 >> 1;
t4 = y ^ ~0;
t5 = t3 >> t4;
tmp_hi = 0 << y;
tmp_hi |= t5;
tmp_lo = 1 << y;
out_hi = t1 ? tmp_lo : tmp_hi;
out_lo = t1 ? t2 : tmp_lo;

Notice here that t3 is always zero, so the assignment of t5
is a variable shift of zero, which expands to a loop on many
smaller targets, a similar shift by zero in the first tmp_hi
assignment (another loop), that the value of t4 is no longer
required (as t3 is zero), and that the ultimate value of tmp_hi
is always zero.

Fortunately, for many (but perhaps not all) targets this mess
gets cleaned up by later optimization passes.  However, this
patch avoids generating unnecessary RTL at expand time, by
calling simplify_expand_binop instead of expand_binop, and
avoiding generating dead or unnecessary code when intermediate
values are known to be zero.  For the 1LL << y test case above,
we now generate:

t1 = y & 32;
t2 = 0;
tmp_hi = 0;
tmp_lo = 1 << y;
out_hi = t1 ? tmp_lo : tmp_hi;
out_lo = t1 ? t2 : tmp_lo;

On arc-elf, for example, there are 18 RTL INSN_P instructions
generated by expand before this patch, but only 12 with this patch
(improving both compile-time and memory usage).


This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2023-10-15  Roger Sayle  

gcc/ChangeLog
* optabs.cc (expand_subword_shift): Call simplify_expand_binop
instead of expand_binop.  Optimize cases (i.e. avoid generating
RTL) when CARRIES or INTO_INPUT is zero.  Use one_cmpl_optab
(i.e. NOT) instead of xor_optab with ~0 to calculate ~OP1.


Thanks in advance,
Roger
--

diff --git a/gcc/optabs.cc b/gcc/optabs.cc
index e1898da..f0a048a 100644
--- a/gcc/optabs.cc
+++ b/gcc/optabs.cc
@@ -533,15 +533,13 @@ expand_subword_shift (scalar_int_mode op1_mode, optab 
binoptab,
 has unknown behavior.  Do a single shift first, then shift by the
 remainder.  It's OK to use ~OP1 as the remainder if shift counts
 are truncated to the mode size.  */
-  carries = expand_binop (word_mode, reverse_unsigned_shift,
- outof_input, const1_rtx, 0, unsignedp, methods);
-  if (shift_mask == BITS_PER_WORD - 1)
-   {
- tmp = immed_wide_int_const
-   (wi::minus_one (GET_MODE_PRECISION (op1_mode)), op1_mode);
- tmp = simplify_expand_binop (op1_mode, xor_optab, op1, tmp,
-  0, true, methods);
-   }
+  carries = simplify_expand_binop (word_mode, reverse_unsigned_shift,
+  outof_input, const1_rtx, 0,
+  unsignedp, methods);
+  if (carries == const0_rtx)
+   tmp = const0_rtx;
+  else if (shift_mask == BITS_PER_WORD - 1)
+   tmp = expand_unop (op1_mode, one_cmpl_optab, op1, 0, true);
   else
{
  tmp = immed_wide_int_const (wi::shwi (BITS_PER_WORD - 1,
@@ -552,22 +550,29 @@ expand_subword_shift (scalar_int_mode op1_mode, optab 
binoptab,
 }
   if (tmp == 0 || carries == 0)
 return false;
-  carries = expand_binop (word_mode, reverse_unsigned_shift,
- carries, tmp, 0, unsignedp, methods);
+  if (carries != const0_rtx && tmp != const0_rtx)
+carries = simplify_expand_binop (word_mode, reverse_unsigned_shift,
+carries, tmp, 0, unsignedp, methods);
   if (carries == 0)
 return false;
 
-  /* Shift INTO_INPUT logically by OP1.  This is the last use of INTO_INPUT
- so the result can go directly into INTO_TARGET if convenient.  */
-  tmp = expand_binop (word_mode, unsigned_shift, into_input, op1,
- into_target, unsignedp, methods);
-  if (tmp == 0)
-return false;
+  if (into_input != const0_rtx)
+{
+  /* Shift INTO_INPUT logically by OP1.  This is the last use of
+INTO_INPUT so 

Re: [PATCH] PR 91865: Avoid ZERO_EXTEND of ZERO_EXTEND in make_compound_operation.

[Jeff Law]

On 10/14/23 16:14, Roger Sayle wrote:


This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentionally generate a
non-canonical ZERO_EXTEND of a ZERO_EXTEND, which is unlikely to be
matched by the backend.

For the new test case:

const int table[2] = {1, 2};
int foo (char i) { return table[i]; }

compiling with -O2 -mlarge on msp430 we currently see:

Trying 2 -> 7:
 2: r25:HI=zero_extend(R12:QI)
   REG_DEAD R12:QI
 7: r28:PSI=sign_extend(r25:HI)#0
   REG_DEAD r25:HI
Failed to match this instruction:
(set (reg:PSI 28 [ iD.1772 ])
 (zero_extend:PSI (zero_extend:HI (reg:QI 12 R12 [ iD.1772 ]

which results in the following code:

foo:AND #0xff, R12
 RLAM.A #4, R12 { RRAM.A #4, R12
 RLAM.A  #1, R12
 MOVX.W  table(R12), R12
 RETA

With this patch, we now see:

Trying 2 -> 7:
 2: r25:HI=zero_extend(R12:QI)
   REG_DEAD R12:QI
 7: r28:PSI=sign_extend(r25:HI)#0
   REG_DEAD r25:HI
Successfully matched this instruction:
(set (reg:PSI 28 [ iD.1772 ])
 (zero_extend:PSI (reg:QI 12 R12 [ iD.1772 ])))
allowing combination of insns 2 and 7
original costs 4 + 8 = 12
replacement cost 8

foo:MOV.B   R12, R12
 RLAM.A  #1, R12
 MOVX.W  table(R12), R12
 RETA


This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?

2023-10-14  Roger Sayle  

gcc/ChangeLog
 PR rtl-optimization/91865
 * combine.cc (make_compound_operation): Avoid creating a
 ZERO_EXTEND of a ZERO_EXTEND.

gcc/testsuite/ChangeLog
 PR rtl-optimization/91865
 * gcc.target/msp430/pr91865.c: New test case.

Neither an ACK or NAK at this point.

The bug report includes a patch from Segher which purports to fix this 
in simplify-rtx.  Any thoughts on Segher's approach and whether or not 
it should be considered?


The BZ also indicates that removal of 2 patterns from msp430.md would 
solve this too (though it may cause regressions elsewhere?).  Any 
thoughts on that approach as well?


Thanks,
jeff

Re: [patch] libgomp.texi: Improve "OpenACC Environment Variables"

[Sandra Loosemore]

On 10/14/23 13:51, Tobias Burnus wrote:


@@ -5003,6 +5001,17 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic 
purposes.
 @node ACC_DEVICE_TYPE
 @section @code{ACC_DEVICE_TYPE}
 @table @asis
+@item @emph{Description}:
+Control the default device type to use when executing compute regions.
+If unset, the code can be run on any device type, favoring a non-host
+device type.
+
+Supported value in GCC (if compiled in) are


s/value/values/


+@itemize
+@item @code{host}
+@item @code{nvidia}
+@item @code{radeon}
+@end itemize
 @item @emph{Reference}:
 @uref{https://www.openacc.org, OpenACC specification v2.6}, section
 4.1.
@@ -5013,6 +5022,10 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic 
purposes.
 @node ACC_DEVICE_NUM
 @section @code{ACC_DEVICE_NUM}
 @table @asis
+@item @emph{Description}:
+Control which device, identified by device number, is the default device.
+The number must be a nonnegative integer number less that the number of


Ummm, too many "number"s!

How about rephrasing that as
The value must be a nonnegative integer less than the number of


+devices.  If unset, device number zero is used.
 @item @emph{Reference}:
 @uref{https://www.openacc.org, OpenACC specification v2.6}, section
 4.2.
@@ -5023,6 +5036,11 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic 
purposes.
 @node ACC_PROFLIB
 @section @code{ACC_PROFLIB}
 @table @asis
+@item @emph{Description}:
+Semicolon separated list of dynamic libraries to be loaded as profiling 
library.


s/Semicolon separated/Semicolon-separated/

There's also a semantic issue with "list of dynamic libraries" (plural) and 
"profiling library" (singular).  Are they all separately profiling libraries, 
or does the entire list constitute a single logical profiling library and its 
dependencies?



+The library file is found as described by the documentation of @code{dlopen} of


Probably s/The/Each/?


+your operating system.  Each library must implement at least the routine
+@code{acc_register_library} routine.


Again, I'm not sure if this applies to every library in the list, or just that 
some library in the list must provide this routine.


-Sandra

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #114 from Gaius Mulley  ---
This comment is to acknowledge the bug in cc1gm2 regarding the false positives:

 gm2/pim/fail/largeconst.mod
 gm2/pim/fail/largeconst2.mod

when encountering large ZTYPE constants.

Will fix - and thanks for the data type hint.

gcc-13-20231014 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20231014 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20231014/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision a9f39860efa645149ec88f0e9a7a31c3362b7e46

You'll find:

 gcc-13-20231014.tar.xz   Complete GCC

  SHA256=40bf42e54cefefa4a8f35c48e0f290c9ef8118eee9a72800296a0e620dfb0240
  SHA1=c7fa5bd8478bbc42556b25bc5e8b0c1c1dff1cdd

Diffs from 13-20231007 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[PATCH] PR 91865: Avoid ZERO_EXTEND of ZERO_EXTEND in make_compound_operation.

[Roger Sayle]

This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentionally generate a
non-canonical ZERO_EXTEND of a ZERO_EXTEND, which is unlikely to be
matched by the backend.

For the new test case:

const int table[2] = {1, 2};
int foo (char i) { return table[i]; }

compiling with -O2 -mlarge on msp430 we currently see:

Trying 2 -> 7:
2: r25:HI=zero_extend(R12:QI)
  REG_DEAD R12:QI
7: r28:PSI=sign_extend(r25:HI)#0
  REG_DEAD r25:HI
Failed to match this instruction:
(set (reg:PSI 28 [ iD.1772 ])
(zero_extend:PSI (zero_extend:HI (reg:QI 12 R12 [ iD.1772 ]

which results in the following code:

foo:AND #0xff, R12
RLAM.A #4, R12 { RRAM.A #4, R12
RLAM.A  #1, R12
MOVX.W  table(R12), R12
RETA

With this patch, we now see:

Trying 2 -> 7:
2: r25:HI=zero_extend(R12:QI)
  REG_DEAD R12:QI
7: r28:PSI=sign_extend(r25:HI)#0
  REG_DEAD r25:HI
Successfully matched this instruction:
(set (reg:PSI 28 [ iD.1772 ])
(zero_extend:PSI (reg:QI 12 R12 [ iD.1772 ])))
allowing combination of insns 2 and 7
original costs 4 + 8 = 12
replacement cost 8

foo:MOV.B   R12, R12
RLAM.A  #1, R12
MOVX.W  table(R12), R12
RETA


This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?

2023-10-14  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/91865
* combine.cc (make_compound_operation): Avoid creating a
ZERO_EXTEND of a ZERO_EXTEND.

gcc/testsuite/ChangeLog
PR rtl-optimization/91865
* gcc.target/msp430/pr91865.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 360aa2f25e6..f47ff596782 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -8453,6 +8453,9 @@ make_compound_operation (rtx x, enum rtx_code in_code)
new_rtx, GET_MODE (XEXP (x, 0)));
   if (tem)
return tem;
+  /* Avoid creating a ZERO_EXTEND of a ZERO_EXTEND.  */
+  if (GET_CODE (new_rtx) == ZERO_EXTEND)
+   new_rtx = XEXP (new_rtx, 0);
   SUBST (XEXP (x, 0), new_rtx);
   return x;
 }
diff --git a/gcc/testsuite/gcc.target/msp430/pr91865.c 
b/gcc/testsuite/gcc.target/msp430/pr91865.c
new file mode 100644
index 000..8cc21c8b9e8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/pr91865.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mlarge" } */
+
+const int table[2] = {1, 2};
+int foo (char i) { return table[i]; }
+
+/* { dg-final { scan-assembler-not "AND" } } */
+/* { dg-final { scan-assembler-not "RRAM" } } */

Re: [patch] libgomp.texi: Update "Enabling OpenMP"

[Jakub Jelinek]

On Sat, Oct 14, 2023 at 03:46:52PM -0600, Sandra Loosemore wrote:
> On 10/14/23 13:43, Tobias Burnus wrote:
> > When browsing libgomp doc, I came across
> > https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> First, I
> > found especially the Fortran part difficult to read. Secondly,
> > it missed the C++ attribute syntax. And I also missed a reference to
> > -fopenmp-simd.
> > 
> > The attached patch tries to improve this. Note that it talks about C and
> > C++ attributes, even though C23's [[omp::]] support has not yet landed.
> > (But is expected very soon.)
> 
> Is somebody actively working on implementing that, and expecting to get it
> in before Stage 1 closes?  I don't think we should document features that

I am (attached is a WIP, which can now compile most of g++.dg/gomp/attrs-1.C
in -std=c2x -fopenmp, except for the scan/section directives).
That said, I agree it might be premature to document it before it is in.

> don't exist yet.  This syntax for C also isn't even in the draft OpenMP 6.0
> document so at this point it's just a hypothetical extension.

It is in OpenMP spec git and it is very unlikely it would be removed.

Jakub
--- gcc/cp/parser.h.jj  2023-09-20 08:42:51.987008923 +0200
+++ gcc/cp/parser.h 2023-10-12 13:32:42.503496571 +0200
@@ -408,7 +408,8 @@ struct GTY(()) cp_parser {
  identifiers) rather than an explicit template parameter list.  */
   bool fully_implicit_function_template_p;
 
-  /* TRUE if omp::directive or omp::sequence attributes may not appear.  */
+  /* TRUE if omp::directive, omp::decl or omp::sequence attributes may not
+ appear.  */
   bool omp_attrs_forbidden_p;
 
   /* Tracks the function's template parameter list when declaring a function
--- gcc/c/c-decl.cc.jj  2023-10-11 10:59:12.378170030 +0200
+++ gcc/c/c-decl.cc 2023-10-11 17:23:42.902257966 +0200
@@ -61,6 +61,7 @@ along with GCC; see the file COPYING3.
 #include "context.h"  /* For 'g'.  */
 #include "omp-general.h"
 #include "omp-offload.h"  /* For offload_vars.  */
+#include "c-parser.h"
 
 #include "tree-pretty-print.h"
 
@@ -325,15 +326,34 @@ i_label_binding (tree node)
 
 /* The resulting tree type.  */
 
-union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
+union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE + 2 * (TREE_CODE 
(&%h.generic) == C_TOKEN_VEC)"),
chain_next ("(union lang_tree_node *) c_tree_chain_next 
(&%h.generic)"))) lang_tree_node
  {
   union tree_node GTY ((tag ("0"),
desc ("tree_node_structure (&%h)")))
 generic;
   struct lang_identifier GTY ((tag ("1"))) identifier;
+  struct c_tree_token_vec GTY ((tag ("2"))) c_token_vec;
 };
 
+/* Langhook for tree_size.  */
+size_t
+c_tree_size (enum tree_code code)
+{
+  gcc_checking_assert (code >= NUM_TREE_CODES);
+  switch (code)
+{
+case C_TOKEN_VEC: return sizeof (c_tree_token_vec);
+default:
+  switch (TREE_CODE_CLASS (code))
+   {
+   case tcc_declaration: return sizeof (tree_decl_non_common);
+   case tcc_type: return sizeof (tree_type_non_common);
+   default: gcc_unreachable ();
+   }
+}
+}
+
 /* Track bindings and other things that matter for goto warnings.  For
efficiency, we do not gather all the decls at the point of
definition.  Instead, we point into the bindings structure.  As
--- gcc/c/c-parser.cc.jj2023-10-11 10:59:12.426169364 +0200
+++ gcc/c/c-parser.cc   2023-10-13 17:47:27.32902 +0200
@@ -247,12 +247,21 @@ struct GTY(()) c_parser {
  macro.  */
   BOOL_BITFIELD seen_string_literal : 1;
 
+  /* TRUE if omp::directive, omp::decl or omp::sequence attributes may not
+ appear.  */
+  BOOL_BITFIELD omp_attrs_forbidden_p : 1;
+
   /* Location of the last consumed token.  */
   location_t last_token_location;
 
   /* Holds state for parsing collapsed OMP_FOR loops.  Managed by
  c_parser_omp_for_loop.  */
   struct omp_for_parse_data * GTY((skip)) omp_for_parse_state;
+
+  /* If we're in the context of OpenMP directives written as C23
+ attributes turned into pragma, vector of tokens created from that,
+ otherwise NULL.  */
+  vec *in_omp_attribute_pragma;
 };
 
 /* Return a pointer to the Nth token in PARSERs tokens_buf.  */
@@ -1383,6 +1392,17 @@ c_parser_skip_to_pragma_eol (c_parser *p
 }
   while (token_type != CPP_PRAGMA_EOL);
 
+  if (parser->in_omp_attribute_pragma)
+{
+  c_token *token = c_parser_peek_token (parser);
+  if (token->type == CPP_EOF)
+   {
+ parser->tokens = >tokens_buf[0];
+ parser->tokens_avail = token->flags;
+ parser->in_omp_attribute_pragma = NULL;
+   }
+}
+
   parser->error = false;
 }
 
@@ -5430,6 +5450,109 @@ c_parser_balanced_token_sequence (c_pars
 }
 }
 
+static bool c_parser_check_balanced_raw_token_sequence (c_parser *,
+   unsigned int *);
+
+/* Parse arguments of omp::directive or omp::decl attribute.
+
+   

Re: [patch] libgomp.texi: Update "Enabling OpenMP"

[Sandra Loosemore]

On 10/14/23 13:43, Tobias Burnus wrote:

When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> 
First, I found especially the Fortran part difficult to read. Secondly,

it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.

The attached patch tries to improve this. Note that it talks about C and
C++ attributes, even though C23's [[omp::]] support has not yet landed.
(But is expected very soon.)


Is somebody actively working on implementing that, and expecting to get it in 
before Stage 1 closes?  I don't think we should document features that don't 
exist yet.  This syntax for C also isn't even in the draft OpenMP 6.0 document 
so at this point it's just a hypothetical extension.  To me it seems a better 
use of resources to finish implementing things that are actually in earlier 
versions of the OpenMP standard, and to fill in documentation for features that 
are actually implemented.


Other than that...


diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 526d1be2955..d8126f96fe4 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -136,15 +136,22 @@ changed to GNU Offloading and Multi Processing Runtime 
Library.
 @node Enabling OpenMP
 @chapter Enabling OpenMP
 
-To activate the OpenMP extensions for C/C++ and Fortran, the compile-time 
-flag @command{-fopenmp} must be specified.  This enables the OpenMP directive
-@code{#pragma omp} in C/C++ and @code{!$omp} directives in free form, 
-@code{c$omp}, @code{*$omp} and @code{!$omp} directives in fixed form, 
-@code{!$} conditional compilation sentinels in free form and @code{c$},

-@code{*$} and @code{!$} sentinels in fixed form, for Fortran.  The flag also
-arranges for automatic linking of the OpenMP runtime library 
+To activate the OpenMP extensions for C/C++ and Fortran, the compile-time

+flag @command{-fopenmp} must be specified.  For C and C++, this enables


Use @option markup on options, not @command.


+the handling of the OpenMP directives using @code{#pragma omp} and the
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} attributes.  For Fortran, it enables for
+free source form the @code{!$omp} sentinel for directives and the
+@code{!$} conditional compilation sentinel and for fixed source form the
+@code{c$omp}, @code{*$omp} and @code{!$omp} sentinels for directives and
+the @code{c$}, @code{*$} and @code{!$} conditional compilation sentinels.
+The flag also arranges for automatic linking of the OpenMP runtime library
 (@ref{Runtime Library Routines}).


And I think all those @code markups should be @samp instead, or you could just 
replace this whole blurb with something like "This flag enables recognition of 
the directive syntax documented in the OpenMP specification, and also arranges 
for automatic linking..."



+The @command{-fopenmp-simd} flag can be used to enable a subset of


This should be @option too.


+OpenMP directives, which do not require the linking of neither the


s/, which/ that/
s/neither/either/


+OpenMP runtime library nor the POSIX threads library.
+
 A complete description of all OpenMP directives may be found in the
 @uref{https://www.openmp.org, OpenMP Application Program Interface} manuals.
 See also @ref{OpenMP Implementation Status}.


-Sandra

[Bug c/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 56112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56112=edit
Patch which I am testing

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=33135

--- Comment #4 from Andrew Pinski  ---
Note it might need to be under the check of -mieee too 

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

--- Comment #3 from Andrew Pinski  ---
Something like:
```
diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 294faf7c0c3..18fa2129388 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -980,6 +980,10 @@ sh_option_override (void)
   if (! OPTION_SET_P (TARGET_IEEE))
 TARGET_IEEE = ! flag_finite_math_only;

+  REAL_MODE_FORMAT (SFmode) = _single_format;
+  REAL_MODE_FORMAT (DFmode) = _double_format;
+
+
   if (sh_fixed_range_str)
 sh_fix_range (sh_fixed_range_str);

```

The mips (real) format here is the basically swapped meaning of the signalling
bit.

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #2 from Bruno Haible  ---
Created attachment 56111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56111=edit
test case for long double

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #1 from Bruno Haible  ---
Created attachment 56110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56110=edit
test case for double

[Bug target/111814] New: on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 111814
   Summary: on sh4, __builtin_nan* returns signalling NaNs instead
of quiet NaNs and vice versa
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 56109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56109=edit
test case for float

The bit that distinguishes a quiet NaN from a signalling NaN is,
according to , the most
significant bit of the mantissa field.  This bit is
*  == 0 to indicate a quiet NaN or Infinity,
   == 1 to indicate a signalling NaN,
   on these CPUs: hppa, mips, sh4.
*  == 1 to indicate a quiet NaN,
   == 0 to indicate a signalling NaN or Infinity,
   on all other CPUs.

The statement regarding sh4 follows from the "SH-4 Software Manual"

page 143.

The GCC primitives __builtin_nan* get this wrong:
- __builtin_nanf, __builtin_nan, __builtin_nanl return a signalling
  NaN instead of a quiet NaN.
- __builtin_nansf, __builtin_nans, __builtin_nansl return a quiet
  NaN instead of a signalling NaN.

How to reproduce:

Compile and run the attached programs in the Linux/sh4 QEMU user-mode
environment. I use QEMU version 8.0.2.

$ sh4-linux-gnu-gcc-11 foof.c
$ ./a.out 
Bits: 32
Mantissa bits: 24
Min exponent: -125
Max exponent:  128
1.0 representation: 00 00 80 3F
1/3 representation: AB AA AA 3E
+Infinity representation:   00 00 80 7F
-Infinity representation:   00 00 80 FF
qNaN representation:FF FF BF 7F
gcc qNaN representation:00 00 C0 7F
gcc sNaN representation:00 00 A0 7F

$ sh4-linux-gnu-gcc-11 food.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation: 00 00 00 00 00 00 F0 3F
1/3 representation: 55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:FF FF FF FF FF FF F7 7F
gcc qNaN representation:00 00 00 00 00 00 F8 7F
gcc sNaN representation:00 00 00 00 00 00 F4 7F

$ sh4-linux-gnu-gcc-11 fool.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation: 00 00 00 00 00 00 F0 3F
1/3 representation: 55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:FF FF FF FF FF FF F7 7F
gcc qNaN representation:00 00 00 00 00 00 F8 7F
gcc sNaN representation:00 00 00 00 00 00 F4 7F

The row "qNaN representation" shows the value of 0.0 / 0.0, as computed
by QEMU. As you can see, it is consistent with the "SH-4 Software Manual"

page 143.

The values in the rows "gcc qNaN representation" and
"gcc sNaN representation" are wrong: The most significant bit
of the mantissa field (bit 22 or 51, respectively) is the opposite
of what it should be.

[Bug c/101364] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
```
void fruit();
void fruit(
int b[x],
short c)
{}
```

[Bug c/101285] [11/12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_safe_arg_type_equiv_p, at c/c-typeck.c:5830

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 56108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56108=edit
Patch which I am testing

Re: [Patch] libgomp.texi: Clarify OMP_TARGET_OFFLOAD=mandatory

[Sandra Loosemore]

On 10/12/23 10:37, Tobias Burnus wrote:

@@ -3133,15 +3134,25 @@ variable can be set to one of three values - 
@code{MANDATORY}, @code{DISABLED}
 or @code{DEFAULT}.
 
 If set to @code{MANDATORY}, the program will terminate with an error if

-the offload device is not present or is not supported.  If set to
-@code{DISABLED}, then offloading is disabled and all code will run on the
-host. If set to @code{DEFAULT}, the program will try offloading to the
+any device construct or device memory routine uses a device that is unavailable
+or not supported by the implementation, or uses a non-conforming device number.
+If set to @code{DISABLED}, then offloading is disabled and all code will run on
+the host. If set to @code{DEFAULT}, the program will try offloading to the
 device first, then fall back to running code on the host if it cannot.
 
 If undefined, then the program will behave as if @code{DEFAULT} was set.
 
+Note: Even with @code{MANDATORY}, there will be no run-time termination when

+the device number in a @code{device} clause or argument to a device memory
+routine is for host, which includes using the device number in the
+@var{default-device-var} ICV.  However, the initial value of
+the @var{default-device-var} ICV is affected by @code{MANDATORY}.


Can we please rewrite this whole section in the present tense?  E.g.

s/will terminate/terminates/
s/will run/runs/
s/will try ... fall back/tries ... falls back/
s/will behave/behaves/
s/will be/is/

-Sandra

[Bug fortran/104351] ICE in gfc_generate_initializer, at fortran/expr.cc:5140

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed in gcc-14.

[patch] libgomp.texi: Improve "OpenACC Environment Variables"

[Tobias Burnus]

I was recently suggesting someone to use ACC_DEVICE_TYPE; I did not point to the
documentation it only contains the title:
  https://gcc.gnu.org/onlinedocs/libgomp/ACC_005fDEVICE_005fTYPE.html

Admittedly, there is also "Reference:" pointing to the OpenACC specification,
but the latter just states:

"The allowed values of this environment variable are implementation-defined. 
See the
release notes for currently-supported values of this environment variable."

Thus, I now added documentation for the three ACC_ env vars.
I removed GCC_ACC_NOTIFY as it does not seem to exist - and it looks as if it
never did ... (The Nvidia compiler seems to support ACC_NOTIFY with a similar
usage as GOMP_DEBUG and GCN_DEBUG). It was added in GCC 6, which implies that
it also won't be added again. (I also checked OG9 and OG13 and neither contained
it; I don't know whether some older OG did.)

Comments?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
libgomp.texi: Improve "OpenACC Environment Variables"

None of the ACC_* env vars was documented; in particular, the valid valids
for ACC_DEVICE_TYPE found to be lacking as those are not document in the
OpenACC spec.
GCC_ACC_NOTIFY was removed as I find any traces of it but the addition
to the documentation in commit r6-6185-gcdf6119dad04dd ("libgomp.texi:
Updates for OpenACC.").  It seems to be planned as GCC version of
the ACC_NOTIFY env var used by another compiler for offloading debugging.

libgomp/
	* libgomp.tex (ACC_DEVICE_TYPE, ACC_DEVICE_NUM, ACC_PROFLIB):
	Actually document what the function does.
	(GCC_ACC_NOTIFY): Remove unused env var.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 526d1be2955..941525d013d 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -4989,13 +4989,11 @@ The variables @env{ACC_DEVICE_TYPE} and @env{ACC_DEVICE_NUM}
 are defined by section 4 of the OpenACC specification in version 2.0.
 The variable @env{ACC_PROFLIB}
 is defined by section 4 of the OpenACC specification in version 2.6.
-The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
 
 @menu
 * ACC_DEVICE_TYPE::
 * ACC_DEVICE_NUM::
 * ACC_PROFLIB::
-* GCC_ACC_NOTIFY::
 @end menu
 
 
@@ -5003,6 +5001,17 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
 @node ACC_DEVICE_TYPE
 @section @code{ACC_DEVICE_TYPE}
 @table @asis
+@item @emph{Description}:
+Control the default device type to use when executing compute regions.
+If unset, the code can be run on any device type, favoring a non-host
+device type.
+
+Supported value in GCC (if compiled in) are
+@itemize
+@item @code{host}
+@item @code{nvidia}
+@item @code{radeon}
+@end itemize
 @item @emph{Reference}:
 @uref{https://www.openacc.org, OpenACC specification v2.6}, section
 4.1.
@@ -5013,6 +5022,10 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
 @node ACC_DEVICE_NUM
 @section @code{ACC_DEVICE_NUM}
 @table @asis
+@item @emph{Description}:
+Control which device, identified by device number, is the default device.
+The number must be a nonnegative integer number less that the number of
+devices.  If unset, device number zero is used.
 @item @emph{Reference}:
 @uref{https://www.openacc.org, OpenACC specification v2.6}, section
 4.2.
@@ -5023,6 +5036,11 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
 @node ACC_PROFLIB
 @section @code{ACC_PROFLIB}
 @table @asis
+@item @emph{Description}:
+Semicolon separated list of dynamic libraries to be loaded as profiling library.
+The library file is found as described by the documentation of @code{dlopen} of
+your operating system.  Each library must implement at least the routine
+@code{acc_register_library} routine.
 @item @emph{See also}:
 @ref{acc_register_library}, @ref{OpenACC Profiling Interface}
 
@@ -5033,15 +5051,6 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
 
 
 
-@node GCC_ACC_NOTIFY
-@section @code{GCC_ACC_NOTIFY}
-@table @asis
-@item @emph{Description}:
-Print debug information pertaining to the accelerator.
-@end table
-
-
-
 @c -
 @c CUDA Streams Usage
 @c -

[patch] libgomp.texi: Update "Enabling OpenMP"

[Tobias Burnus]

When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html

First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.

The attached patch tries to improve this. Note that it talks about C and
C++ attributes, even though C23's [[omp::]] support has not yet landed.
(But is expected very soon.)

I also do not try to list what -fopenmp-simd supports as that's at
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fopenmp
and I bet we won't keep both in sync and "man gcc" is more likely to be
up to date.

Comments?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
libgomp.texi: Update "Enabling OpenMP"

libgomp/
	* libgomp.texi (Enabling OpenMP): Update for C/C++ attributes;
	improve wording especially for Fortran; mention -fopenmp-simd.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 526d1be2955..d8126f96fe4 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -136,15 +136,22 @@ changed to GNU Offloading and Multi Processing Runtime Library.
 @node Enabling OpenMP
 @chapter Enabling OpenMP
 
-To activate the OpenMP extensions for C/C++ and Fortran, the compile-time 
-flag @command{-fopenmp} must be specified.  This enables the OpenMP directive
-@code{#pragma omp} in C/C++ and @code{!$omp} directives in free form, 
-@code{c$omp}, @code{*$omp} and @code{!$omp} directives in fixed form, 
-@code{!$} conditional compilation sentinels in free form and @code{c$},
-@code{*$} and @code{!$} sentinels in fixed form, for Fortran.  The flag also
-arranges for automatic linking of the OpenMP runtime library 
+To activate the OpenMP extensions for C/C++ and Fortran, the compile-time
+flag @command{-fopenmp} must be specified.  For C and C++, this enables
+the handling of the OpenMP directives using @code{#pragma omp} and the
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} attributes.  For Fortran, it enables for
+free source form the @code{!$omp} sentinel for directives and the
+@code{!$} conditional compilation sentinel and for fixed source form the
+@code{c$omp}, @code{*$omp} and @code{!$omp} sentinels for directives and
+the @code{c$}, @code{*$} and @code{!$} conditional compilation sentinels.
+The flag also arranges for automatic linking of the OpenMP runtime library
 (@ref{Runtime Library Routines}).
 
+The @command{-fopenmp-simd} flag can be used to enable a subset of
+OpenMP directives, which do not require the linking of neither the
+OpenMP runtime library nor the POSIX threads library.
+
 A complete description of all OpenMP directives may be found in the
 @uref{https://www.openmp.org, OpenMP Application Program Interface} manuals.
 See also @ref{OpenMP Implementation Status}.

[committed] libgomp.fortran/allocate-6.f90: Run with -fdump-tree-gimple (was: [Patch] OpenMP: Add ME support for 'omp allocate' stack variables)

[Tobias Burnus]

I wonder why I missed the following – but it now works :-/

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit fd6b17a4892684f286274d874f0029604feda7e5
Author: Tobias Burnus 
Date:   Sat Oct 14 20:09:34 2023 +0200

libgomp.fortran/allocate-6.f90: Run with -fdump-tree-gimple

libgomp/
* testsuite/libgomp.fortran/allocate-6.f90: Add missing
dg-additional-options "-fdump-tree-gimple"; fix scan.

diff --git a/libgomp/testsuite/libgomp.fortran/allocate-6.f90 b/libgomp/testsuite/libgomp.fortran/allocate-6.f90
index 5c32652f2a6..5034dd26b2e 100644
--- a/libgomp/testsuite/libgomp.fortran/allocate-6.f90
+++ b/libgomp/testsuite/libgomp.fortran/allocate-6.f90
@@ -1,3 +1,4 @@
+! { dg-additional-options "-fdump-tree-gimple" }
 module m
   use iso_c_binding
   use omp_lib
@@ -23,10 +24,10 @@ subroutine one ()
   !$omp allocate(var,var2) align(128) allocator(omp_low_lat_mem_alloc)
   var = 5
 ! { dg-final { scan-tree-dump-times "var\\.\[0-9\]+ = __builtin_GOMP_alloc \\(128, 4, 5\\);" 1 "gimple" } } */
-! { dg-final { scan-tree-dump-times "var2\\.\[0-9\]+ = __builtin_GOMP_alloc \\(128, D\\.\[0-9\]+, 5\\);" 1 "gimple" } } */
+! { dg-final { scan-tree-dump-times "var2 = __builtin_GOMP_alloc \\(128, D\\.\[0-9\]+, 5\\);" 1 "gimple" } } */
 
 ! { dg-final { scan-tree-dump-times "__builtin_GOMP_free \\(var\\.\[0-9\]+, 0B\\);" 1 "gimple" } } */
-! { dg-final { scan-tree-dump-times "__builtin_GOMP_free \\(var2\\.\[0-9\]+, 0B\\);" 1 "gimple" } } */
+! { dg-final { scan-tree-dump-times "__builtin_GOMP_free \\(var2, 0B\\);" 1 "gimple" } } */
 
   if (mod(transfer(loc(var), intptr), 128_c_intptr_t) /= 0) &
 stop 1

[Bug ada/111813] New: Inconsistent limit in Ada.Calendar.Formatting

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 111813
   Summary: Inconsistent limit in Ada.Calendar.Formatting
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

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

The Value function's description (ARM 9.6.1(87)[1] doesn't place any limitation 
on the Elapsed_Time parameter's value, beyond "Constraint_Error is raised if
the
string is not formatted as described for Image, or the function cannot
interpret 
the given string as a Duration value".

It would seem reasonable that Value and Image should be consistent, in that any 
string produced by Image should be accepted by Value. Since Image must produce
a 
two-digit representation of the Hours, there's an implication that its 
Elapsed_Time parameter should be less than 100 hours (the ARM merely says that 
in that case the result is implementation-defined).

The current implementation of Value raises Constraint_Error if the Elapsed_Time 
parameter is greater than or equal to 24 hours.

The attached demonstrator (calendar_format_value.adb) shows Image accepting an 
Elapsed_Time of 24h00m00s, converting it to "24:00:00"; given this string,
Value 
raises Constraint_Error.

This issue is present in GCC 10, 11, 12 and 13, but probably not worth 
backfitting.

[1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-9-6-1.html#p87

Re: [Patch] libgomp.texi: Note to 'Memory allocation' sect and missing mem-memory routines

[Sandra Loosemore]

On 10/12/23 04:53, Tobias Burnus wrote:


libgomp.texi: Note to 'Memory allocation' sect and missing mem-memory routines

This commit completes the documentation of the OpenMP memory-management
routines, except for the unimplemented TR11 additions.  It also makes clear
in the 'Memory allocation' section of the 'OpenMP-Implementation Specifics'
chapter under which condition OpenMP managed memory/allocators are used.

libgomp/ChangeLog:

* libgomp.texi: Fix some typos.
(Memory Management Routines): Document remaining 5.x routines.
(Memory allocation): Make clear when the section applies.

 libgomp/libgomp.texi | 382 +--
 1 file changed, 367 insertions(+), 15 deletions(-)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 0d965f96d48..3fc9c7dea23 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -1917,7 +1917,7 @@ is not supported.
 @item @emph{Description}:
 If the device number is refers to the initial device or to a device with


s/is refers/refers/


 memory accessible from the host (shared memory), the @code{omp_get_mapped_ptr}
-routines returnes the value of the passed @var{ptr}.  Otherwise, if associated
+routines returns the value of the passed @var{ptr}.  Otherwise, if associated
 storage to the passed host pointer @var{ptr} exists on device associated with


s/on device/on the device/ (or maybe /on a device/?)


+@node omp_alloc
+@subsection @code{omp_alloc} -- Memory allocation with an allocator
+@table @asis
+@item @emph{Description}:
+Allocate memory with the specified allocator, which can either be a predefined
+allocator, an allocator handle or @code{omp_null_allocator}.  If the allocators
+is @code{omp_null_allocator}, the allocator specified by the


Minimally, s/allocators is/allocator is/, or maybe something like /allocator 
argument is/, and/or add appropriate markup on allocator here to indicate that 
it is an argument.



+@var{def-allocator-var} ICV is used.  @var{size} must be a nonnegative number
+denoting the number of bytes to be allocated; if @var{size} is zero,
+@code{omp_alloc} will return a null pointer.  If successful, a pointer to the


s/will return/returns/


+allocated memory is returned, otherwise the @code{fallback} trait of the
+allocator determines the behavior.  The content of the allocated memory is
+unspecified.
+
+In @code{target} regions, either the @code{dynamic_allocators} clause must
+appear on a @code{requires} directive in the same compilation unit -- or the


s/ -- or/, or/


+@var{allocator} argument may only be a constant expression with the value of


s/may only be/must be/


+@node omp_aligned_alloc
+@subsection @code{omp_aligned_alloc} -- Memory allocation with an allocator 
and alignment
+@table @asis
+@item @emph{Description}:
+Allocate memory with the specified allocator, which can either be a predefined
+allocator, an allocator handle or @code{omp_null_allocator}.  If the allocators
+is @code{omp_null_allocator}, the allocator specified by the


Ditto above comments re "allocators is".


+@var{def-allocator-var} ICV is used.  @var{alignment} must be a positive power
+of two and @var{size} must be a nonnegative number that is a multiple of the
+alignment and denotes the number of bytes to be allocated; if @var{size} is
+zero, @code{omp_aligned_alloc} will return a null pointer.  The alignment will
+be at least the maximal value required by @code{alignment} trait of the


s/will return/return/

"The alignment will be" needs to be rewritten to avoid future tense too, but 
I'm not sure what you're trying to say here.  Is this a requirement on the 
alignment argument or a statement about the actual alignment of the allocated 
memory?



+allocator and the value of the  passed @var{alignment} argument.  If 
successful,
+a pointer to the allocated memory is returned, otherwise the @code{fallback}
+trait of the allocator determines the behavior.  The content of the allocated
+memory is unspecified.
+
+In @code{target} regions, either the @code{dynamic_allocators} clause must
+appear on a @code{requires} directive in the same compilation unit -- or the
+@var{allocator} argument may only be a constant expression with the value of
+one of the predefined allocators and may not be @code{omp_null_allocator}.


Ditto above comments re using comma and "must".


+@node omp_free
+@subsection @code{omp_free} -- Freeing memory allocated with OpenMP routines
+@table @asis
+@item @emph{Description}:
+The @code{omp_free} routine deallocates memory previously allocated by an
+OpenMP memory-management routine. The @var{ptr} argument must point to such
+memory or be a null pointer; if it is a null pointer, no operation is
+performed.  If specified, the @var{allocator} argument must be either the
+memory allocator that was used for the allocation or @code{omp_null_allocator};
+if it is @code{omp_null_allocator}, the implementation will determine the value


s/will 

[Bug bootstrap/111812] [14 regression] Can't build with gcc 4.8.5

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

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

--- Comment #3 from Jakub Jelinek  ---
r14-4332-ge40f3301019a521b11bfcc25aeb1388e6da1ca2f should have fixed this exact
issue, but I think for gcc 4.8.5 there is another poly_int related issue that
currently prevents builds with such system compiler.
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632008.html

[Bug bootstrap/111812] [14 regression] Can't build with gcc 4.8.5

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

   Host||powerpc64-linux-gnu
 Target||powerpc64-linux-gnu
 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Build||powerpc64-linux-gnu

--- Comment #2 from seurer at gcc dot gnu.org ---
That's fine by me

[Bug bootstrap/111812] [14 regression] Can't build with gcc 4.8.5

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

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

--- Comment #1 from Andrew Pinski  ---
See thread starting at
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632008.html

We might decide to push the host version requirement ...

[Bug bootstrap/111812] New: [14 regression] Can't build with gcc 4.8.5

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

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

Bug ID: 111812
   Summary: [14 regression] Can't build with gcc 4.8.5
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:73cd319b72ca45a537688cc8cc5751d86a00a0e9, r14-4306-g73cd319b72ca45

We have one older system that still has gcc 4.8.5 as the distro compiler.

seurer@granola:~/gcc/git/build/gcc-test$ g++ -v
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 


If gcc 4.8.5 is no longer the minimum requirement that's fine by me as I can
just build a later version to use.



g++ -std=gnu++11 -c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H  -DGENERATOR_FILE -I. -Ibuild
-I/home/seurer/gcc/git/gcc-test/gcc -I/home/seurer/gcc/git/gcc-test/gcc/build
-I/home/seurer/gcc/git/gcc-test/gcc/../include 
-I/home/seurer/gcc/git/gcc-test/gcc/../libcpp/include  \
-o build/genpreds.o /home/seurer/gcc/git/gcc-test/gcc/genpreds.cc
In file included from /home/seurer/gcc/git/gcc-test/gcc/rtl.h:30:0,
 from /home/seurer/gcc/git/gcc-test/gcc/genpreds.cc:27:
/home/seurer/gcc/git/gcc-test/gcc/vec.h: In member function 'void vec::quick_insert(unsigned int, const T&)':
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1089:18: error: 'is_trivially_copyable'
is not a member of 'std'
   static_assert (std::is_trivially_copyable ::value, "");
  ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1089:47: error: expected
primary-expression before '>' token
   static_assert (std::is_trivially_copyable ::value, "");
   ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1089:48: error: '::value' has not been
declared
   static_assert (std::is_trivially_copyable ::value, "");
^
/home/seurer/gcc/git/gcc-test/gcc/vec.h: In member function 'void vec::ordered_remove(unsigned int)':
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1105:18: error: 'is_trivially_copyable'
is not a member of 'std'
   static_assert (std::is_trivially_copyable ::value, "");
  ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1105:47: error: expected
primary-expression before '>' token
   static_assert (std::is_trivially_copyable ::value, "");
   ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1105:48: error: '::value' has not been
declared
   static_assert (std::is_trivially_copyable ::value, "");
^
/home/seurer/gcc/git/gcc-test/gcc/vec.h: In member function 'void vec::unordered_remove(unsigned int)':
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1153:18: error: 'is_trivially_copyable'
is not a member of 'std'
   static_assert (std::is_trivially_copyable ::value, "");
  ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1153:47: error: expected
primary-expression before '>' token
   static_assert (std::is_trivially_copyable ::value, "");
   ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1153:48: error: '::value' has not been
declared
   static_assert (std::is_trivially_copyable ::value, "");
^
/home/seurer/gcc/git/gcc-test/gcc/vec.h: In member function 'void vec::block_remove(unsigned int, unsigned int)':
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1167:18: error: 'is_trivially_copyable'
is not a member of 'std'
   static_assert (std::is_trivially_copyable ::value, "");
  ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1167:47: error: expected
primary-expression before '>' token
   static_assert (std::is_trivially_copyable ::value, "");
   ^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1167:48: error: '::value' has not been
declared
   static_assert (std::is_trivially_copyable ::value, "");
^
/home/seurer/gcc/git/gcc-test/gcc/vec.h: At global scope:
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1185:68: error: expected template-name
before '<' token
   struct is_trivially_copyable_or_pair : std::is_trivially_copyable { };
^
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1185:68: error: expected '{' before '<'
token
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1185:68: error: expected unqualified-id
before '<' token
/home/seurer/gcc/git/gcc-test/gcc/vec.h:1185:75: warning: extra ';'
[-Wpedantic]
   struct is_trivially_copyable_or_pair : std::is_trivially_copyable { };
   

[Bug c/111808] [C23] constexpr with excess precision

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

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

--- Comment #3 from Jakub Jelinek  ---
Excess precision changes behavior in lots of significant ways, and I don't
really see how we could warn for this, there are different kinds of excess
precision, the i386 one of promoting float/double to long double, s390{,x} way
of promoting float to double,
different arches depending on flags either promote _Float16 operations to float
(or double or long double) or don't, so I don't really see how we could try to
evaluate expressions 3-6 different ways and warn if there is some difference
between those.

[Bug c/111811] New: gcc: internal compiler error: tree check: expected none of vector_type, have vector_type in finish_struct

[congli at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111811
   Summary: gcc: internal compiler error: tree check: expected
none of vector_type, have vector_type in finish_struct
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congli at smail dot nju.edu.cn
  Target Milestone: ---

Compiler explorer: https://godbolt.org/z/WWzcPWcqs.

The following program `small.c` triggers a crash in gcc-14:

``` sh
% cat small.c
struct A {
__attribute__((__vector_size__(4))) float d : 1;
};


% gcc-tk -O0 small.c
:2:47: error: bit-field 'd' has invalid type
2 | __attribute__((__vector_size__(4))) float d : 1;
  |   ^
:3:1: internal compiler error: tree check: expected none of
vector_type, have vector_type in finish_struct, at c/c-decl.cc:9358
3 | };
  | ^
0x22ff3ee internal_error(char const*, ...)
  ???:0
0x8a7b87 tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
  ???:0
0xa7ab0d c_parser_declspecs(c_parser*, c_declspecs*, bool, bool, bool, bool,
bool, bool, bool, c_lookahead_kind)
  ???:0
0xaa468d c_parse_file()
  ???:0
0xb17919 c_common_parse_file()
  ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
```

GCC version:

```
gcc
(Compiler-Explorer-Build-gcc-300d7d3a8f4b53d045ce43f1ed4e10301781c786-binutils-2.40)
14.0.0 20231014 (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.
```

[Bug c/111808] [C23] constexpr with excess precision

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---

On i386 1. / 3. is computed with higher precision than double and then the
initializer changes the value which is a contraint violation in C23.  But
whether this happens or not depends on the architecture, so this code is not
portable.

Re: Question about gimple code during optimizing if-conversion

[Jeff Law via Gcc]

On 10/14/23 09:49, Andrew Pinski via Gcc wrote:

On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc  wrote:


Hi, I'm working on optimizing if-conversion for my own business
recently. I got a problem here.

I tried to optimize it in such a case, for example, when a conditional
statement block has only if statement and no else statement, the
source C code looks like this:

int* foo; // assume this has been initialized
int c = rand(), t = rand(), size = 1000;
for (int i = 0; i < size; i++) {
   if (foo[i] & (1 << c)) foo[i] ^= (1 << t);
}

Part of its corresponding gimple is optimized like this before if-conversion:

   :
   # i_71 = PHI 
   # ivtmp_9 = PHI 
   _5 = (long unsigned int) i_71;
   _6 = _5 * 4;
   _7 = foo_23 + _6;
   _8 = *_7;
   shifttmp_75 = _8 & shifttmp_76;
   if (shifttmp_75 != 0)
 goto ; [50.00%]
   else
 goto ; [50.00%]

[local count: 531502205]:
   goto ; [100.00%]

[local count: 531502204]:
   _12 = _8 ^ _11;
   *_7 = _12;

[local count: 1063004409]:
   i_39 = i_71 + 1;
   ivtmp_73 = ivtmp_9 - 1;
   if (ivtmp_73 != 0)
 goto ; [99.00%]
   else
 goto ; [1.00%]

I want to add some statements to gimple to make it like adding an else
block to the source code.

// What I expected:
int* foo; // assume this has been initialized
int c = rand(), t = rand(), size = 1000;
for (int i = 0; i < size; i++) {
   if (foo[i] & (1 << c)) foo[i] ^= (1 << t);
+  else foo[i] = foo[i];  // I want to add a statment here !
}

And of course I can't change the source code for real, so I can only
add a pass in front of if-conversion to modify the gimple.

For the example above, I know that I have to add them in the block
'', but what confuses me is that I don't know what kind of
statement to add to be legal due to my poor experience.

I try to add something like this below, but the compile error just
happened. So I'm here for help. What kind of statements should I add
here?

 [local count: 531502205]:
+ *_7 = *_7
  goto ; [100.00%]

Finally, The reason I did this was to avoid MASK_STORE generation,
because it might add an if branch in the final assembly which I don't
like it to be. And after such a modification, if-conversion should
have been changed it to the form of a ternary expression, which would
reduce the occurrence of branches after final vectorization and
produce more efficient code.

Or there if is a better way to get rid of MASK_STORE, please tell me
about that. :)


So there are 2 issues with this transformation which you need to take
into account.
1) C11/C++11 threading model (-fallow-store-data-races is needed)
2) foo could be read only and cause a trap if written to. if the
branch is never taken there would be no writes
Right.   See ifcvt_memrefs_wont_trap.  That probably could be extended 
to capture additional cases.  But I'm not sure that'll be sufficient for 
Hanke's problem.


Jeff

[Bug c/111808] [C23] constexpr with excess precision

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Excess precision?

[Bug c/111810] New: GCC-14 segfault: error: expected declaration or statement at end of input

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111810
   Summary: GCC-14 segfault: error: expected declaration or
statement at end of input
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

When compile this program with `gcc-14 -O0`, gcc crashes:
```
void = {0};
void uninliner_1() {
  {}
inline __RTL test(void) {
  uninliner_1();
```

This crash can be verified at https://godbolt.org/z/rc9oW43EE

The full stack backtrace is pasted below:

:1:6: error: expected identifier or '(' before '=' token
1 | void = {0};
  |  ^
: In function 'uninliner_1':
:4:14: warning: return type defaults to 'int' [-Wimplicit-int]
4 | inline __RTL test(void) {
  |  ^~~~
: In function 'test':
:5:3: error: no closing brace
5 |   uninliner_1();
  |   ^~~
: At top level:
:5:3: error: expected declaration or statement at end of input
:5:3: internal compiler error: Segmentation fault
0x22ff3ee internal_error(char const*, ...)
???:0
0xa2621e finish_function(unsigned int)
???:0
0xaa468d c_parse_file()
???:0
0xb17919 c_common_parse_file()
???:0
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.
Compiler returned: 1

[Bug c/111809] GCC-14: internal error, internal compiler error: in release_function_body, at cgraph.cc:1805

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> ---
Full stack backtrace:

: In function 'bar':
:8:1: error: SSA name '' with version 3 has no definition
8 | }
  | ^
At top level:
cc1: internal compiler error: in release_function_body, at cgraph.cc:1805
0x22ff3ee internal_error(char const*, ...)
???:0
0x9fc0a8 fancy_abort(char const*, int, char const*)
???:0
0xbd8857 cgraph_node::release_body(bool)
???:0
0xbde851 cgraph_node::remove()
???:0
0xbe92d1 symbol_table::finalize_compilation_unit()
???:0
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/111809] New: GCC-14: internal error, internal compiler error: in release_function_body, at cgraph.cc:1805

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111809
   Summary: GCC-14: internal error, internal compiler error: in
release_function_body, at cgraph.cc:1805
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Reproducer: https://godbolt.org/z/MP7qnTKz6

when compile this with `gcc-14 -O0 -fgimple`, gcc crashes:
```
inline __GIMPLE (ssa) void
bar (void)
{
  int _3;

__BB(2):
  return;
}
```

Re: Question about gimple code during optimizing if-conversion

[Andrew Pinski via Gcc]

On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc  wrote:
>
> Hi, I'm working on optimizing if-conversion for my own business
> recently. I got a problem here.
>
> I tried to optimize it in such a case, for example, when a conditional
> statement block has only if statement and no else statement, the
> source C code looks like this:
>
> int* foo; // assume this has been initialized
> int c = rand(), t = rand(), size = 1000;
> for (int i = 0; i < size; i++) {
>   if (foo[i] & (1 << c)) foo[i] ^= (1 << t);
> }
>
> Part of its corresponding gimple is optimized like this before if-conversion:
>
>   :
>   # i_71 = PHI 
>   # ivtmp_9 = PHI 
>   _5 = (long unsigned int) i_71;
>   _6 = _5 * 4;
>   _7 = foo_23 + _6;
>   _8 = *_7;
>   shifttmp_75 = _8 & shifttmp_76;
>   if (shifttmp_75 != 0)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
>
>[local count: 531502205]:
>   goto ; [100.00%]
>
>[local count: 531502204]:
>   _12 = _8 ^ _11;
>   *_7 = _12;
>
>[local count: 1063004409]:
>   i_39 = i_71 + 1;
>   ivtmp_73 = ivtmp_9 - 1;
>   if (ivtmp_73 != 0)
> goto ; [99.00%]
>   else
> goto ; [1.00%]
>
> I want to add some statements to gimple to make it like adding an else
> block to the source code.
>
> // What I expected:
> int* foo; // assume this has been initialized
> int c = rand(), t = rand(), size = 1000;
> for (int i = 0; i < size; i++) {
>   if (foo[i] & (1 << c)) foo[i] ^= (1 << t);
> +  else foo[i] = foo[i];  // I want to add a statment here !
> }
>
> And of course I can't change the source code for real, so I can only
> add a pass in front of if-conversion to modify the gimple.
>
> For the example above, I know that I have to add them in the block
> '', but what confuses me is that I don't know what kind of
> statement to add to be legal due to my poor experience.
>
> I try to add something like this below, but the compile error just
> happened. So I'm here for help. What kind of statements should I add
> here?
>
>  [local count: 531502205]:
> + *_7 = *_7
>  goto ; [100.00%]
>
> Finally, The reason I did this was to avoid MASK_STORE generation,
> because it might add an if branch in the final assembly which I don't
> like it to be. And after such a modification, if-conversion should
> have been changed it to the form of a ternary expression, which would
> reduce the occurrence of branches after final vectorization and
> produce more efficient code.
>
> Or there if is a better way to get rid of MASK_STORE, please tell me
> about that. :)

So there are 2 issues with this transformation which you need to take
into account.
1) C11/C++11 threading model (-fallow-store-data-races is needed)
2) foo could be read only and cause a trap if written to. if the
branch is never taken there would be no writes



Thanks,
Andrew Pinski

>
> Thanks
> Hanke Zhang

[Bug ipa/111789] [14 Regression] runtime Segmentation fault with '-O3 -fno-inline -fno-toplevel-reorder'

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

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

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

[Bug c/111804] wrong code with '-O3 -fno-inline-functions-called-once -fno-inline-small-functions -fno-toplevel-reorder -fno-tree-fre'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Same issue as PR 111789.

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

[Bug middle-end/111805] suboptimal codegen of variant

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-14
  Component|c++ |middle-end

--- Comment #2 from Andrew Pinski  ---
Anyways we have:
  __builtin_memcpy (_M_local_buf, "abc", 3);
  _5 = [(struct basic_string *)_3(D)].D.38438._M_local_buf;
  MEM[(struct _Alloc_hider *)_3(D)]._M_p = _5;
  __builtin_memcpy (_5, _M_local_buf, 3);
  MEM[(struct basic_string *)_3(D)]._M_string_length = 3;
  MEM[(char_type &)_3(D) + 19] = 0;

If we able to remove the first memcpy things would be just work I think ...

[Bug c++/111805] suboptimal codegen of variant

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

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

--- Comment #1 from Andrew Pinski  ---
The clang assembly you posted does not match the source you posted ...

[Bug middle-end/111806] g++ generates better code for variant at -Os compared to -O3

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

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

--- Comment #2 from Andrew Pinski  ---
The difference is -O2 duplicates the return which might speed up things.
This happens during bb reorder due to estimates of the bb counts.

[Bug tree-optimization/111807] [14 Regression] ice in verify_sra_access_forest with -O1 and bitfields in some cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/111807] [14 Regression] ice in verify_sra_access_forest with -O1 and bitfields in some cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |14.0
Summary|ice in  |[14 Regression] ice in
   |verify_sra_access_forest|verify_sra_access_forest
   |with -O1|with -O1 and bitfields in
   ||some cases
   Keywords||ice-on-valid-code

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #104 from Alexander Klepikov  
---
(In reply to Oleg Endo from comment #103)
> Sorry, I've been busy with other things.  I think your patch is OK, but I
> wanted to test it in more detail before committing it.

Oh, it's OK. By the way, your contribution is not less than mine.

I've been thinking about something. I suspect that this patch could take work
away from other patches. I'm sorry, I don't know how to express myself
properly. I mean there's several patches that corrects shift patterns and 'tst'
instruction generation (most of them are written by you, by the way). I suspect
that some of them might not run anymore because this patch looks more general
and should cover more cases, including yet unknown cases, I hope. And, in the
end, dead code may appear because of it. I hope I was able to make my point
clearly.

[Bug c/111808] New: [C23] constexpr

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 111808
   Summary: [C23] constexpr
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

GCC implements constraint 6.7.1p5 for constexpr initialized with a float
pointer value as an error.  For example, the following fails to compile on
i386:

int func(void) 
{
  constexpr double f2 = 1. / 3.;
  return 3. * f2 == 3. * (1. / 3.);
}

with

: In function 'func':
:7:25: error: 'constexpr' initializer not representable in type of
object
7 |   constexpr double f2 = 1. / 3.;

while it compiles on x64-86.  This seems problematic because this it will cause
a lot surprising failures when compiling code written for x64-86 on i386.  We
should either have a warning that such code is non-portable (but this seems
difficult) or downgrade this to a warning and accept the code as an extension
on architectures which compute with excess precision.

https://godbolt.org/z/7vsWhvKjd

[Bug c/111807] ice in verify_sra_access_forest with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Second test case:

int func_40_l_118;

struct S0 {
  signed f1 : 1;
};

void func_40() {
  struct S0 l_103[16];
  *l_103 = l_103[15];
  l_103[15].f1 &_40_l_118;
}

Re: [PATCH] c++: fix truncated diagnostic in C++23 [PR111272]

[Jason Merrill]

On 10/13/23 18:15, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


-- >8 --
In C++23, since P2448, a constexpr function F that calls a non-constexpr
function N is OK as long as we don't actually call F in a constexpr
context.  So instead of giving an error in maybe_save_constexpr_fundef,
we only give an error when evaluating the call.  Unfortunately, as shown
in this PR, the diagnostic can be truncated:

z.C:10:13: note: 'constexpr Jam::Jam()' is not usable as a 'constexpr' function 
because:
10 |   constexpr Jam() { ft(); }
   | ^~~

...because what?  With this patch, we say:

z.C:10:13: note: 'constexpr Jam::Jam()' is not usable as a 'constexpr' function 
because:
10 |   constexpr Jam() { ft(); }
   | ^~~
z.C:10:23: error: call to non-'constexpr' function 'int Jam::ft()'
10 |   constexpr Jam() { ft(); }
   | ~~^~
z.C:8:7: note: 'int Jam::ft()' declared here
 8 |   int ft() { return 42; }
   |   ^~

Like maybe_save_constexpr_fundef, explain_invalid_constexpr_fn should
also check the body of a constructor, not just the mem-initializer.

PR c++/111272

gcc/cp/ChangeLog:

* constexpr.cc (explain_invalid_constexpr_fn): Also check the body of
a constructor in C++14 and up.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-diag1.C: New test.
---
  gcc/cp/constexpr.cc  | 10 +-
  gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C | 21 
  2 files changed, 30 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 0f948db7c2d..dde4fec4a44 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -1098,7 +1098,15 @@ explain_invalid_constexpr_fn (tree fun)
  body = massage_constexpr_body (fun, body);
  require_potential_rvalue_constant_expression (body);
  if (DECL_CONSTRUCTOR_P (fun))
-   cx_check_missing_mem_inits (DECL_CONTEXT (fun), body, true);
+   {
+ cx_check_missing_mem_inits (DECL_CONTEXT (fun), body, true);
+ if (cxx_dialect > cxx11)
+   {
+ /* Also check the body, not just the ctor-initializer.  */
+ body = DECL_SAVED_TREE (fun);
+ require_potential_rvalue_constant_expression (body);
+   }
+   }
}
  }
  }
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C
new file mode 100644
index 000..0e2909e83ef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-diag1.C
@@ -0,0 +1,21 @@
+// PR c++/111272
+// { dg-do compile { target c++14 } }
+// { dg-options "-Werror=invalid-constexpr" }
+// { dg-prune-output "some warnings being treated as errors" }
+
+struct Jam
+{
+  // constexpr  // n.b.
+  int ft() { return 42; } // { dg-message "declared here" }
+
+  constexpr Jam() { ft(); } // { dg-error "call to non-.constexpr. function" }
+// { dg-message "declared here" "" { target c++20_down } .-1 }
+};
+
+constexpr bool test()
+{
+  Jam j; // { dg-error "called in a constant expression" }
+  return true;
+}
+
+static_assert(test(), ""); // { dg-error "non-constant condition" }

base-commit: d78fef5371759849944966dec65d9e987efba509

[Bug c/111708] Calling external global function instead of local static function.

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #8 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632999.html

[C PATCH] error for function with external and internal linkage [PR111708]

[Martin Uecker]

Bootstrapped and regression tested on x86_64.


c: error for function with external and internal linkage [PR111708]

Declaring a function with both external and internal linkage
in the same TU is translation-time UB.  Add an error for this
case as already done for objects.

PR c/111708

gcc/c/Changelog:

* c-decl.cc (grokdeclarator): Add error.

gcc/testsuite/Changelog:

* gcc.dg/pr111708-1.c: New test.
* gcc.dg/pr111708-2.c: New test.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 5822faf01b4..52490a784d0 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -8032,6 +8032,28 @@ grokdeclarator (const struct c_declarator *declarator,
TREE_THIS_VOLATILE (decl) = 1;
  }
  }
+
+   /* C99 6.2.2p7: It is invalid (compile-time undefined
+  behavior) to create an 'extern' declaration for a
+  function if there is a global declaration that is
+  'static' and the global declaration is not visible.
+  (If the static declaration _is_ currently visible,
+  the 'extern' declaration is taken to refer to that decl.) */
+   if (!initialized
+   && storage_class != csc_static
+   && storage_class != csc_auto
+   && current_scope != file_scope)
+ {
+   tree global_decl  = identifier_global_value (declarator->u.id.id);
+   tree visible_decl = lookup_name (declarator->u.id.id);
+
+   if (global_decl
+   && global_decl != visible_decl
+   && VAR_OR_FUNCTION_DECL_P (global_decl)
+   && !TREE_PUBLIC (global_decl))
+ error_at (loc, "function previously declared % "
+   "redeclared %");
+ }
   }
 else
   {
diff --git a/gcc/testsuite/gcc.dg/pr111708-1.c 
b/gcc/testsuite/gcc.dg/pr111708-1.c
new file mode 100644
index 000..4af7f53d75f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111708-1.c
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+extern int a(void);// external linkage (6.2.2p4)
+static int a(void);/* { dg-error "static declaration of 'a' follows 
non-static declaration" } */
+
+static int b(void);// internal linkage (6.2.2p3)
+extern int b(void);// internal linkage (6.2.2p4)
+
+static int h0(void);
+
+void s(void)
+{
+   extern int h0(void);// internal linkage (6.2.2p4),
+   extern int h0(void);// internal linkage (6.2.2p4), redeclaration, ok
+   extern int h2(void);// external linkage (6.2.2p4)
+   extern int h2(void);// external linkage (6.2.2p4), redeclaration, 
ok.
+}
+
+
+extern int i(void);// external linkage (6.2.2p4)
+static int j(void);// internal linkage (6.2.2p3)
+
+void bar(void)
+{
+   extern int i(void); // external linkage (6.2.2p4), ok
+}
+
+void foo(void)
+{
+   extern int j(void); // internal linkage (6.2.2p4), ok, internal
+}
+
+void x(void)
+{
+   int i(void);// no linkage (6.2.2p6)
+   int j;  // no linkage (6.2.2p6)
+   {
+   extern int j(void); /* { dg-error "function previously 
declared 'static' redeclared 'extern'" } */
+   }
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr111708-2.c 
b/gcc/testsuite/gcc.dg/pr111708-2.c
new file mode 100644
index 000..065c0525c2e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111708-2.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+/* { dg-require-effective-target trampolines } */
+
+static void pp(void)
+{
+   int pp;
+   {
+   auto void pp(void);
+   void pp(void) { }
+   }
+}
+
+static void q2(void);
+
+static void qq(void)
+{
+   auto void q2(void);
+   void q2(void) { }
+}
+

[Bug d/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Fixes committed. Thanks!

[committed] Fix ICE in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer

[Iain Buclaw]

Hi,

The internal error in analyzer turned out to be caused by a subtly
invalid tree representation of STRING_CSTs in the D front-end, fixed by
including the terminating NULL as part of the TREE_STRING_POINTER.

When adding a first analyzer test for D, it flagged up another subtle
mismatch in one assignment in the module support routines as well, fixed
by generating the correct field type for the compiler-generated struct.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and
committed to mainline.

Regards,
Iain.

---
PR d/111537

gcc/d/ChangeLog:

* expr.cc (ExprVisitor::visit (StringExp *)): Include null terminator
in STRING_CST string.
* modules.cc (get_compiler_dso_type): Generate ModuleInfo** type for
the minfo fields.

gcc/testsuite/ChangeLog:

* gdc.dg/analyzer/analyzer.exp: New test.
* gdc.dg/analyzer/pr111537.d: New test.
---
 gcc/d/expr.cc  |  6 +--
 gcc/d/modules.cc   |  9 ++--
 gcc/testsuite/gdc.dg/analyzer/analyzer.exp | 51 ++
 gcc/testsuite/gdc.dg/analyzer/pr111537.d   |  7 +++
 4 files changed, 66 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/analyzer/analyzer.exp
 create mode 100644 gcc/testsuite/gdc.dg/analyzer/pr111537.d

diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index 7038655bc94..551d004c241 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -2535,13 +2535,13 @@ public:
   {
/* Copy the string contents to a null terminated string.  */
dinteger_t length = (e->len * e->sz);
-   char *string = XALLOCAVEC (char, length + 1);
+   char *string = XALLOCAVEC (char, length + e->sz);
+   memset (string, 0, length + e->sz);
if (length > 0)
  memcpy (string, e->string, length);
-   string[length] = '\0';
 
/* String value and type includes the null terminator.  */
-   tree value = build_string (length, string);
+   tree value = build_string (length + e->sz, string);
TREE_TYPE (value) = make_array_type (tb->nextOf (), length + 1);
value = build_address (value);
 
diff --git a/gcc/d/modules.cc b/gcc/d/modules.cc
index f2180d30546..8d6c8f0f9ad 100644
--- a/gcc/d/modules.cc
+++ b/gcc/d/modules.cc
@@ -277,12 +277,13 @@ get_compiler_dso_type (void)
   DECL_CHAIN (field) = fields;
   fields = field;
 
-  field = create_field_decl (build_pointer_type (get_moduleinfo_type ()),
-NULL, 1, 1);
+  tree moduleinfo_ptr_ptr_type =
+build_pointer_type (build_pointer_type (get_moduleinfo_type ()));
+
+  field = create_field_decl (moduleinfo_ptr_ptr_type, NULL, 1, 1);
   DECL_CHAIN (field) = fields;
   fields = field;
-  field = create_field_decl (build_pointer_type (get_moduleinfo_type ()),
-NULL, 1, 1);
+  field = create_field_decl (moduleinfo_ptr_ptr_type, NULL, 1, 1);
   DECL_CHAIN (field) = fields;
   fields = field;
 
diff --git a/gcc/testsuite/gdc.dg/analyzer/analyzer.exp 
b/gcc/testsuite/gdc.dg/analyzer/analyzer.exp
new file mode 100644
index 000..7b82b8e0cd1
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/analyzer/analyzer.exp
@@ -0,0 +1,51 @@
+#  Copyright (C) 2023 Free Software Foundation, Inc.
+
+#  This file is part of GCC.
+#
+#  GCC is free software; you can redistribute it and/or modify it under
+#  the terms of the GNU General Public License as published by the Free
+#  Software Foundation; either version 3, or (at your option) any later
+#  version.
+#
+#  GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+#  WARRANTY; without even the implied warranty of MERCHANTABILITY or
+#  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+#  for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with GCC; see the file COPYING3.  If not see
+#  .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib gdc-dg.exp
+
+# If the analyzer has not been enabled, bail.
+if { ![check_effective_target_analyzer] } {
+return
+}
+
+global DEFAULT_DFLAGS
+if [info exists DEFAULT_DFLAGS] then {
+  set save_default_dflags $DEFAULT_DFLAGS
+}
+
+# If a testcase doesn't have special options, use these.
+set DEFAULT_DFLAGS "-fanalyzer -Wanalyzer-too-complex 
-fanalyzer-call-summaries"
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+gdc-dg-runtest [lsort \
+   [glob -nocomplain $srcdir/$subdir/*.d ] ] "" $DEFAULT_DFLAGS
+
+# All done.
+dg-finish
+
+if [info exists save_default_dflags] {
+  set DEFAULT_DFLAGS $save_default_dflags
+} else {
+  unset DEFAULT_DFLAGS
+}
diff --git a/gcc/testsuite/gdc.dg/analyzer/pr111537.d 
b/gcc/testsuite/gdc.dg/analyzer/pr111537.d
new file mode 100644
index 000..e50b05a3f79
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/analyzer/pr111537.d
@@ -0,0 +1,7 @@
+// { dg-do compile }
+import core.stdc.string;
+void main()
+{
+char[5] arr;
+

[committed] d: Reduce code duplication of writing generated files.

[Iain Buclaw]

Hi,

This is a small refactoring ahead of the next merge from upstream, where
a few more front-end routines will stop doing the file handling
themselves.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-lang.cc (d_write_file): New function.
(d_parse_file): Reduce code duplication.
---
 gcc/d/d-lang.cc | 91 -
 1 file changed, 29 insertions(+), 62 deletions(-)

diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 7dddcf5ac91..f290acf494b 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -978,6 +978,30 @@ d_add_builtin_module (Module *m)
   builtin_modules.push (m);
 }
 
+/* Writes to FILENAME.  DATA is the full content of the file to be written.  */
+
+static void
+d_write_file (const char *filename, const char *data)
+{
+  FILE *stream;
+
+  if (filename && (filename[0] != '-' || filename[1] != '\0'))
+stream = fopen (filename, "w");
+  else
+stream = stdout;
+
+  if (!stream)
+{
+  error ("unable to open %s for writing: %m", filename);
+  return;
+}
+
+  fprintf (stream, "%s", data);
+
+  if (stream != stdout && (ferror (stream) || fclose (stream)))
+error ("writing output file %s: %m", filename);
+}
+
 /* Implements the lang_hooks.parse_file routine for language D.  */
 
 static void
@@ -1264,8 +1288,6 @@ d_parse_file (void)
   if (d_option.deps)
 {
   obstack buffer;
-  FILE *deps_stream;
-
   gcc_obstack_init ();
 
   for (size_t i = 0; i < modules.length; i++)
@@ -1275,27 +1297,8 @@ d_parse_file (void)
   if (d_option.deps_filename_user)
d_option.deps_filename = d_option.deps_filename_user;
 
-  if (d_option.deps_filename)
-   {
- deps_stream = fopen (d_option.deps_filename, "w");
- if (!deps_stream)
-   {
- fatal_error (input_location, "opening dependency file %s: %m",
-  d_option.deps_filename);
- goto had_errors;
-   }
-   }
-  else
-   deps_stream = stdout;
-
-  fprintf (deps_stream, "%s", (char *) obstack_finish ());
-
-  if (deps_stream != stdout
- && (ferror (deps_stream) || fclose (deps_stream)))
-   {
- fatal_error (input_location, "closing dependency file %s: %m",
-  d_option.deps_filename);
-   }
+  d_write_file (d_option.deps_filename,
+   (char *) obstack_finish ());
 }
 
   if (global.params.vtemplates)
@@ -1306,29 +1309,7 @@ d_parse_file (void)
 {
   OutBuffer buf;
   json_generate (, );
-
-  const char *name = global.params.json.name.ptr;
-  FILE *json_stream;
-
-  if (name && (name[0] != '-' || name[1] != '\0'))
-   {
- const char *nameext
-   = FileName::defaultExt (name, json_ext.ptr);
- json_stream = fopen (nameext, "w");
- if (!json_stream)
-   {
- fatal_error (input_location, "opening json file %s: %m", nameext);
- goto had_errors;
-   }
-   }
-  else
-   json_stream = stdout;
-
-  fprintf (json_stream, "%s", buf.peekChars ());
-
-  if (json_stream != stdout
- && (ferror (json_stream) || fclose (json_stream)))
-   fatal_error (input_location, "closing json file %s: %m", name);
+  d_write_file (global.params.json.name.ptr, buf.peekChars ());
 }
 
   /* Generate Ddoc files.  */
@@ -1391,22 +1372,8 @@ d_parse_file (void)
   /* We want to write the mixin expansion file also on error.  */
   if (global.params.mixinOut.doOutput)
 {
-  FILE *mixin_stream = fopen (global.params.mixinOut.name.ptr, "w");
-
-  if (mixin_stream)
-   {
- OutBuffer *buf = global.params.mixinOut.buffer;
- fprintf (mixin_stream, "%s", buf->peekChars ());
-
- if (ferror (mixin_stream) || fclose (mixin_stream))
-   fatal_error (input_location, "closing mixin file %s: %m",
-global.params.mixinOut.name.ptr);
-   }
-  else
-   {
- fatal_error (input_location, "opening mixin file %s: %m",
-  global.params.mixinOut.name.ptr);
-   }
+  d_write_file (global.params.mixinOut.name.ptr,
+   global.params.mixinOut.buffer->peekChars ());
 }
 
   /* Remove generated .di files on error.  */
-- 
2.39.2

[Bug d/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:578afbc751d122b55196a23fe75a17e1b4e9bd0c

commit r14-4639-g578afbc751d122b55196a23fe75a17e1b4e9bd0c
Author: Iain Buclaw 
Date:   Sat Oct 14 02:19:41 2023 +0200

Fix ICE in set_cell_span, at text-art/table.cc:148 with D front-end and
-fanalyzer

The internal error in analyzer turned out to be caused by a subtly
invalid tree representation of STRING_CSTs in the D front-end, fixed by
including the terminating NULL as part of the TREE_STRING_POINTER.

When adding a first analyzer test for D, it flagged up another subtle
mismatch in one assignment in the module support routines as well, fixed
by generating the correct field type for the compiler-generated struct.

PR d/111537

gcc/d/ChangeLog:

* expr.cc (ExprVisitor::visit (StringExp *)): Include null
terminator
in STRING_CST string.
* modules.cc (get_compiler_dso_type): Generate ModuleInfo** type
for
the minfo fields.

gcc/testsuite/ChangeLog:

* gdc.dg/analyzer/analyzer.exp: New test.
* gdc.dg/analyzer/pr111537.d: New test.

[Bug c/111807] ice in verify_sra_access_forest with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
I've had a go at a git bisect and the current range is 
g:d53d20a940efe426 .. g:24eaada73def58a6, which is 14 commits.

Richard's two commits (g:6decda1a35be5764101987c210b5693a0d914e58,
g:35b5bb475375dba4ea9101d6db13a6012c4e84ca) look highly likely.

[Bug c/111807] ice in verify_sra_access_forest with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

struct S0 {
  unsigned f2 : 7
} func_40() {
  struct S0 l_4827[10];
  l_4827[5] = l_4827[9];
  0 || l_4827[9].f2;
}

[Bug c/111807] New: ice in verify_sra_access_forest with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111807
   Summary: ice in verify_sra_access_forest with -O1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code, when compiled by recent gcc, does this:

$ ~/gcc/results/bin/gcc -c -w -O1 bug965.c 
./buildData/in/in.20163.c: In function ‘func_57’:
./buildData/in/in.20163.c:1769:18: note: the ABI for passing parameters with
128-byte alignment has changed in GCC 4.6
during GIMPLE pass: esra
./buildData/in/in.20163.c: In function ‘func_40’:
./buildData/in/in.20163.c:2878:1: internal compiler error: in
verify_sra_access_forest, at tree-sra.cc:2414
0xfb289d verify_sra_access_forest(access*)
/home/dcb38/gcc/working/gcc/../../trunk.year/gcc/tree-sra.cc:2414
0xfb2a2a verify_all_sra_access_forests()
/home/dcb38/gcc/working/gcc/../../trunk.year/gcc/tree-sra.cc:2465
0xfb4672 analyze_all_variable_accesses()
/home/dcb38/gcc/working/gcc/../../trunk.year/gcc/tree-sra.cc:3534

The bug first seems to appear sometime between git hash g:530babc2058be5f2
and g:78dd49f387c515a6, a range of 52 commits.

I will have a go at a reduction.

Re: [PATCH] wide-int, v2: Fix estimation of buffer sizes for wide_int printing [PR111800]

[Richard Biener]

> Am 14.10.2023 um 11:50 schrieb Jakub Jelinek :
> 
> Hi!
> 
>> On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
>> Can we somehow abstract this common pattern?
> 
> So like this?  With room for the future tweaks like printing decimal
> instead of hex numbers by print_dec*, where we'd only need to adjust
> the inlines.  The XALLOCAVEC call is left for the callers, those would
> make the inlines uninlinable and not doing what they should.

LGTM.

Richard 

> 2023-10-14  Jakub Jelinek  
> 
>PR tree-optimization/111800
> gcc/
>* wide-int-print.h (print_dec_buf_size, print_decs_buf_size,
>print_decu_buf_size, print_hex_buf_size): New inline functions.
>* wide-int.cc (assert_deceq): Use print_dec_buf_size.
>(assert_hexeq): Use print_hex_buf_size.
>* wide-int-print.cc (print_decs): Use print_decs_buf_size.
>(print_decu): Use print_decu_buf_size.
>(print_hex): Use print_hex_buf_size.
>(pp_wide_int_large): Use print_dec_buf_size.
>* value-range.cc (irange_bitmask::dump): Use print_hex_buf_size.
>* value-range-pretty-print.cc (vrange_printer::print_irange_bitmasks):
>Likewise.
>* tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations): Use
>print_dec_buf_size.  Use TYPE_SIGN macro in print_dec call argument.
> gcc/c-family/
>* c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
>is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
>w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.
> 
> --- gcc/wide-int-print.h.jj2023-10-13 19:34:44.283830089 +0200
> +++ gcc/wide-int-print.h2023-10-14 11:21:44.190603091 +0200
> @@ -36,4 +36,40 @@ extern void print_hex (const wide_int_re
> extern void print_hex (const wide_int_ref , FILE *file);
> extern void pp_wide_int_large (pretty_printer *, const wide_int_ref &, 
> signop);
> 
> +inline bool
> +print_dec_buf_size (const wide_int_ref , signop sgn, unsigned int *len)
> +{
> +  unsigned int l = wi.get_len ();
> +  if ((l != 1 || sgn == UNSIGNED) && wi::neg_p (wi))
> +l = WIDE_INT_MAX_HWIS (wi.get_precision ());
> +  l = l * HOST_BITS_PER_WIDE_INT / 4 + 4;
> +  *len = l;
> +  return UNLIKELY (l > WIDE_INT_PRINT_BUFFER_SIZE);
> +}
> +
> +inline bool
> +print_decs_buf_size (const wide_int_ref , unsigned int *len)
> +{
> +  return print_dec_buf_size (wi, SIGNED, len);
> +}
> +
> +inline bool
> +print_decu_buf_size (const wide_int_ref , unsigned int *len)
> +{
> +  return print_dec_buf_size (wi, UNSIGNED, len);
> +}
> +
> +inline bool
> +print_hex_buf_size (const wide_int_ref , unsigned int *len)
> +{
> +  unsigned int l;
> +  if (wi::neg_p (wi))
> +l = WIDE_INT_MAX_HWIS (wi.get_precision ());
> +  else
> +l = wi.get_len ();
> +  l = l * HOST_BITS_PER_WIDE_INT / 4 + 4;
> +  *len = l;
> +  return UNLIKELY (l > WIDE_INT_PRINT_BUFFER_SIZE);
> +}
> +
> #endif /* WIDE_INT_PRINT_H */
> --- gcc/wide-int.cc.jj2023-10-14 11:07:52.738850767 +0200
> +++ gcc/wide-int.cc2023-10-14 11:22:03.100347386 +0200
> @@ -2450,9 +2450,9 @@ static void
> assert_deceq (const char *expected, const wide_int_ref , signop sgn)
> {
>   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
> -  unsigned len = wi.get_len ();
> -  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
> -p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
> +  unsigned len;
> +  if (print_dec_buf_size (wi, sgn, ))
> +p = XALLOCAVEC (char, len);
>   print_dec (wi, p, sgn);
>   ASSERT_STREQ (expected, p);
> }
> @@ -2463,9 +2463,9 @@ static void
> assert_hexeq (const char *expected, const wide_int_ref )
> {
>   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
> -  unsigned len = wi.get_len ();
> -  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
> -p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
> +  unsigned len;
> +  if (print_hex_buf_size (wi, ))
> +p = XALLOCAVEC (char, len);
>   print_hex (wi, p);
>   ASSERT_STREQ (expected, p);
> }
> --- gcc/wide-int-print.cc.jj2023-10-14 11:07:52.737850781 +0200
> +++ gcc/wide-int-print.cc2023-10-14 11:37:43.994623668 +0200
> @@ -75,9 +75,9 @@ void
> print_decs (const wide_int_ref , FILE *file)
> {
>   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
> -  unsigned len = wi.get_len ();
> -  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
> -p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
> +  unsigned len;
> +  if (print_decs_buf_size (wi, ))
> +p = XALLOCAVEC (char, len);
>   print_decs (wi, p);
>   fputs (p, file);
> }
> @@ -102,9 +102,9 @@ void
> print_decu (const wide_int_ref , FILE *file)
> {
>   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
> -  unsigned len = wi.get_len ();
> -  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
> -p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
> +  unsigned len;
> +  if (print_decu_buf_size (wi, ))
> +p = XALLOCAVEC (char, len);
>   print_decu (wi, p);
>   fputs (p, file);
> }
> @@ -141,9 +141,9 @@ void
> print_hex (const wide_int_ref , FILE *file)
> {
>   

[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067

[lr.soft.now at gmail dot com via Gcc-bugs]

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

Lev  changed:

   What|Removed |Added

 CC||lr.soft.now at gmail dot com

--- Comment #6 from Lev  ---
Probably the same bug, but using std::map's constructor that takes an
initializer list.
https://godbolt.org/z/Yavroaddo

[PATCH] wide-int, v2: Fix estimation of buffer sizes for wide_int printing [PR111800]

[Jakub Jelinek]

Hi!

On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
> Can we somehow abstract this common pattern?

So like this?  With room for the future tweaks like printing decimal
instead of hex numbers by print_dec*, where we'd only need to adjust
the inlines.  The XALLOCAVEC call is left for the callers, those would
make the inlines uninlinable and not doing what they should.

2023-10-14  Jakub Jelinek  

PR tree-optimization/111800
gcc/
* wide-int-print.h (print_dec_buf_size, print_decs_buf_size,
print_decu_buf_size, print_hex_buf_size): New inline functions.
* wide-int.cc (assert_deceq): Use print_dec_buf_size.
(assert_hexeq): Use print_hex_buf_size.
* wide-int-print.cc (print_decs): Use print_decs_buf_size.
(print_decu): Use print_decu_buf_size.
(print_hex): Use print_hex_buf_size.
(pp_wide_int_large): Use print_dec_buf_size.
* value-range.cc (irange_bitmask::dump): Use print_hex_buf_size.
* value-range-pretty-print.cc (vrange_printer::print_irange_bitmasks):
Likewise.
* tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations): Use
print_dec_buf_size.  Use TYPE_SIGN macro in print_dec call argument.
gcc/c-family/
* c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.

--- gcc/wide-int-print.h.jj 2023-10-13 19:34:44.283830089 +0200
+++ gcc/wide-int-print.h2023-10-14 11:21:44.190603091 +0200
@@ -36,4 +36,40 @@ extern void print_hex (const wide_int_re
 extern void print_hex (const wide_int_ref , FILE *file);
 extern void pp_wide_int_large (pretty_printer *, const wide_int_ref &, signop);
 
+inline bool
+print_dec_buf_size (const wide_int_ref , signop sgn, unsigned int *len)
+{
+  unsigned int l = wi.get_len ();
+  if ((l != 1 || sgn == UNSIGNED) && wi::neg_p (wi))
+l = WIDE_INT_MAX_HWIS (wi.get_precision ());
+  l = l * HOST_BITS_PER_WIDE_INT / 4 + 4;
+  *len = l;
+  return UNLIKELY (l > WIDE_INT_PRINT_BUFFER_SIZE);
+}
+
+inline bool
+print_decs_buf_size (const wide_int_ref , unsigned int *len)
+{
+  return print_dec_buf_size (wi, SIGNED, len);
+}
+
+inline bool
+print_decu_buf_size (const wide_int_ref , unsigned int *len)
+{
+  return print_dec_buf_size (wi, UNSIGNED, len);
+}
+
+inline bool
+print_hex_buf_size (const wide_int_ref , unsigned int *len)
+{
+  unsigned int l;
+  if (wi::neg_p (wi))
+l = WIDE_INT_MAX_HWIS (wi.get_precision ());
+  else
+l = wi.get_len ();
+  l = l * HOST_BITS_PER_WIDE_INT / 4 + 4;
+  *len = l;
+  return UNLIKELY (l > WIDE_INT_PRINT_BUFFER_SIZE);
+}
+
 #endif /* WIDE_INT_PRINT_H */
--- gcc/wide-int.cc.jj  2023-10-14 11:07:52.738850767 +0200
+++ gcc/wide-int.cc 2023-10-14 11:22:03.100347386 +0200
@@ -2450,9 +2450,9 @@ static void
 assert_deceq (const char *expected, const wide_int_ref , signop sgn)
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
-  unsigned len = wi.get_len ();
-  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
-p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
+  unsigned len;
+  if (print_dec_buf_size (wi, sgn, ))
+p = XALLOCAVEC (char, len);
   print_dec (wi, p, sgn);
   ASSERT_STREQ (expected, p);
 }
@@ -2463,9 +2463,9 @@ static void
 assert_hexeq (const char *expected, const wide_int_ref )
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
-  unsigned len = wi.get_len ();
-  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
-p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
+  unsigned len;
+  if (print_hex_buf_size (wi, ))
+p = XALLOCAVEC (char, len);
   print_hex (wi, p);
   ASSERT_STREQ (expected, p);
 }
--- gcc/wide-int-print.cc.jj2023-10-14 11:07:52.737850781 +0200
+++ gcc/wide-int-print.cc   2023-10-14 11:37:43.994623668 +0200
@@ -75,9 +75,9 @@ void
 print_decs (const wide_int_ref , FILE *file)
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
-  unsigned len = wi.get_len ();
-  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
-p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
+  unsigned len;
+  if (print_decs_buf_size (wi, ))
+p = XALLOCAVEC (char, len);
   print_decs (wi, p);
   fputs (p, file);
 }
@@ -102,9 +102,9 @@ void
 print_decu (const wide_int_ref , FILE *file)
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
-  unsigned len = wi.get_len ();
-  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
-p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
+  unsigned len;
+  if (print_decu_buf_size (wi, ))
+p = XALLOCAVEC (char, len);
   print_decu (wi, p);
   fputs (p, file);
 }
@@ -141,9 +141,9 @@ void
 print_hex (const wide_int_ref , FILE *file)
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
-  unsigned len = wi.get_len ();
-  if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
-p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
+  unsigned len;
+  if 

[Bug driver/36312] should refuse to overwrite input file with output file

[sarvelgcc at outlook dot com via Gcc-bugs]

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

sarvel  changed:

   What|Removed |Added

 CC||sarvelgcc at outlook dot com

--- Comment #23 from sarvel  ---
Created attachment 56105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56105=edit
possible fix to overwriting source code

added a possible fix, not sure whether thats the best approach as some source
extensions may be missed

alternatively list of extensions for executable files may be used but *I think*
it is easier to get list of all extensions for source files rather than
executables

Re: [PATCH] wide-int: Fix estimation of buffer sizes for wide_int printing [PR111800]

[Richard Biener]

> Am 14.10.2023 um 10:21 schrieb Jakub Jelinek :
> 
> Hi!
> 
> As mentioned in the PR, my estimations on needed buffer size for wide_int
> and especially widest_int printing were incorrect, I've used get_len ()
> in the estimations, but that is true only for !wi::neg_p (x) values.
> Under the hood, we have 3 ways to print numbers.
> print_decs which if
>  if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
>  || (wi.get_len () == 1))
> uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive or
> negative) and otherwise uses print_hex,
> print_decu which if
>  if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
>  || (wi.get_len () == 1 && !wi::neg_p (wi)))
> uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive
> only) and print_hex, which doesn't print most significant limbs which are
> zero and the first limb which is non-zero prints such that redundant 0
> hex digits aren't printed, while all limbs below that are printed with
> "%016" PRIx64.  For wi::neg_p (x) values, the first limb of the precision
> is always non-zero, so we print all the limbs for the precision.
> So, the current estimations are accurate if !wi::neg_p (x), or when
> print_decs will be used and x.get_len () == 1, otherwise we need to use
> estimation based on get_precision () rather than get_len ().
> 
> The following patch does that, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?

Can we somehow abstract this common pattern?

> The patch doesn't address what I've talked about earlier, that we might
> actually stop using print_hex when asked for print_dec{s,u} - we could for
> negative print_decs just negate and call print_decu, and in print_decu
> e.g. in a loop UNSIGNED wi::divmod_trunc by
> HOST_WIDE_INT_UC (1000) and print the 19 decimal digits of
> remainder if quotient is non-zero, otherwise non-padded rest, and then
> reshuffle the buffer.  And/or perhaps print_hex should also take signop
> and print negative hex constants as -0x. if asked for SIGNED.
> And finally, I think we should try to rewrite tree-ssa-ccp.cc bit-cp from
> widest_int to wide_int, even the earlier:
> PHI node value: CONSTANT 
> 0xffe2
>  (0x19)
> in the -fdump-tree-ccp-details dumps is horribly confusing when the
> type is say just 32-bit or 64-bit, and with the recent widest_int changes
> those are now around with > 32000 f hex digits in there.  Not to mention we 
> shouldn't
> really care about state of bits beyond the precision and I think we always
> have the type in question around (x.val is INTEGER_CST of the right type
> and we just to::widest it, just x.mask is widest_int).
> 
> 2023-10-14  Jakub Jelinek  
> 
>PR tree-optimization/111800
> gcc/
>* wide-int.cc (assert_deceq): Use wi.get_len () for buffer size
>estimation only if !wi::neg_p (wi) or if len is 1 and sgn is SIGNED,
>otherwise use WIDE_INT_MAX_HWIS for wi.get_precision ().
>(assert_hexeq): Use wi.get_len () for buffer size estimation only
>if !wi::neg_p (wi), otherwise use WIDE_INT_MAX_HWIS for
>wi.get_precision ().
>* wide-int-print.cc (print_decs): Use wi.get_len () for buffer size
>estimation only if !wi::neg_p (wi) or if len is 1, otherwise use
>WIDE_INT_MAX_HWIS for wi.get_precision ().
>(print_decu): Use wi.get_len () for buffer size estimation only if
>!wi::neg_p (wi), otherwise use WIDE_INT_MAX_HWIS for
>wi.get_precision ().
>(print_hex): Likewise.
>* value-range.cc (irange_bitmask::dump): Use get_len () for
>buffer size estimation only if !wi::neg_p (wi), otherwise use
>WIDE_INT_MAX_HWIS for get_precision ().
>* value-range-pretty-print.cc (vrange_printer::print_irange_bitmasks):
>Likewise.
>* tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations): Use
>i_bound.get_len () for buffer size estimation only if
>!wi::neg_p (i_bound) or if len is 1 and !TYPE_UNSIGNED, otherwise use
>WIDE_INT_MAX_HWIS for i_bound.get_precision ().  Use TYPE_SIGN macro
>in print_dec call argument.
> gcc/c-family/
>* c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
>is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
>w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.
> 
> --- gcc/wide-int.cc.jj2023-10-13 19:34:44.288830022 +0200
> +++ gcc/wide-int.cc2023-10-13 20:23:12.889386810 +0200
> @@ -2450,7 +2450,9 @@ static void
> assert_deceq (const char *expected, const wide_int_ref , signop sgn)
> {
>   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
>   unsigned len = wi.get_len ();
> +  if ((len != 1 || sgn == UNSIGNED) && wi::neg_p (wi))
> +len = WIDE_INT_MAX_HWIS (wi.get_precision ());
>   if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
> p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
>   print_dec (wi, p, 

Re: [PATCH] libstdc++: Workaround for LLVM-61763 in ranges

[Jonathan Wakely]

On Sat, 14 Oct 2023, 00:33 Benjamin Brock,  wrote:

> This is my first time submitting a patch, so my apologies if I'm
> submitting incorrectly or missing something.
>

Thanks for contributing!

I don't think this patch counts as legally significant, but if you
contribute again in future you should be aware of
https://gcc.gnu.org/contribute.html#legal and either complete the copyright
assignment paperwork, or add a DCO sign-off to the commit message.


> Clang is unable to compile parts of libstdc++'s ranges implementation
> due to LLVM-61763, a Clang frontend compiler bug in handling the
> declarations of constrained friends.  The problem areas are zip_view,
> zip_transform_view, and adjacent_transform_view.
>
> A simple ranges program like the following fails to compile using
> Clang trunk and libstdc++.
>
>   std::vector v = {1, 2, 3, 4};
>   int sum = 0;
>   for (auto&& [i, j] : std::ranges::views::zip(v, v))
> sum += i * j;
>
> In file included from :1:
>
> /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/ranges:4655:14:
> error: type constraint differs in template redeclaration
>  4655 | template
>   |  ^
> . . . . . .
>
> Godbolt: https://godbolt.org/z/Ynbs15aGh
>
> This patch adds a small workaround that avoids declaring constrained
> friends when compiling with Clang, instead making some members public.
> MSVC's standard library has implemented a similar workaround.
>
> Scanning through libstdc++, there do appear to be other workarounds
> for Clang, e.g. in complex and experimental/simd.  Hopefully this kind
> of workaround is acceptable---while the core issue is a Clang compiler
> bug, it may take a while to fix, and it would be very useful for
> libstdc++ ranges to work with Clang in the meantime.
>

Yes, this is ok because the hack is limited to __clang__.


> 2023-10-13  Benjamin Brock 
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges: implement workaround for LLVM-61763 in
>   zip_view and adjacency_view
>

This should be a complete sentence, so capital letter and full stop.

I can get this pushed to trunk and gcc-13 next week, thanks again for the
patch.



> ---
>
> diff --git a/libstdc++-v3/include/std/ranges
> b/libstdc++-v3/include/std/ranges
> index 1d529a886be..7893e3a84c9 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -4632,6 +4632,9 @@ namespace views::__adaptor
>class zip_view<_Vs...>::_Iterator
>  : public __detail::__zip_view_iter_cat<_Const, _Vs...>
>{
> +#ifdef __clang__ // LLVM-61763 workaround
> +  public:
> +#endif
>
>  __detail::__tuple_or_pair_t _Vs>>...> _M_current;
>
>  constexpr explicit
> @@ -4652,11 +4655,13 @@ namespace views::__adaptor
> return input_iterator_tag{};
>  }
>
> +#ifndef __clang__ // LLVM-61763 workaround
>  template
>requires (view<_Ws> && ...) && (sizeof...(_Ws) > 0) &&
> is_object_v<_Fp>
> && regular_invocable<_Fp&, range_reference_t<_Ws>...>
> && std::__detail::__can_reference range_reference_t<_Ws>...>>
>friend class zip_transform_view;
> +#endif
>
>public:
>  // iterator_category defined in __zip_view_iter_cat
> @@ -5327,6 +5332,9 @@ namespace views::__adaptor
>template
>class adjacent_view<_Vp, _Nm>::_Iterator
>{
> +#ifdef __clang__ // LLVM-61763 workaround
> +  public:
> +#endif
>  using _Base = __detail::__maybe_const_t<_Const, _Vp>;
>  array, _Nm> _M_current = array,
> _Nm>();
>
> @@ -5367,12 +5375,14 @@ namespace views::__adaptor
>
>  friend class adjacent_view;
>
> +#ifndef __clang__ // LLVM-61763 workaround
>  template
>requires view<_Wp> && (_Mm > 0) && is_object_v<_Fp>
>  && regular_invocable<__detail::__unarize<_Fp&, _Mm>,
> range_reference_t<_Wp>>
>  &&
> std::__detail::__can_reference _Mm>,
>
> range_reference_t<_Wp>>>
>friend class adjacent_transform_view;
> +#endif
>
>public:
>  using iterator_category = input_iterator_tag;
>

[PATCH] wide-int: Fix estimation of buffer sizes for wide_int printing [PR111800]

[Jakub Jelinek]

Hi!

As mentioned in the PR, my estimations on needed buffer size for wide_int
and especially widest_int printing were incorrect, I've used get_len ()
in the estimations, but that is true only for !wi::neg_p (x) values.
Under the hood, we have 3 ways to print numbers.
print_decs which if
  if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
  || (wi.get_len () == 1))
uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive or
negative) and otherwise uses print_hex,
print_decu which if
  if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
  || (wi.get_len () == 1 && !wi::neg_p (wi)))
uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive
only) and print_hex, which doesn't print most significant limbs which are
zero and the first limb which is non-zero prints such that redundant 0
hex digits aren't printed, while all limbs below that are printed with
"%016" PRIx64.  For wi::neg_p (x) values, the first limb of the precision
is always non-zero, so we print all the limbs for the precision.
So, the current estimations are accurate if !wi::neg_p (x), or when
print_decs will be used and x.get_len () == 1, otherwise we need to use
estimation based on get_precision () rather than get_len ().

The following patch does that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

The patch doesn't address what I've talked about earlier, that we might
actually stop using print_hex when asked for print_dec{s,u} - we could for
negative print_decs just negate and call print_decu, and in print_decu
e.g. in a loop UNSIGNED wi::divmod_trunc by
HOST_WIDE_INT_UC (1000) and print the 19 decimal digits of
remainder if quotient is non-zero, otherwise non-padded rest, and then
reshuffle the buffer.  And/or perhaps print_hex should also take signop
and print negative hex constants as -0x. if asked for SIGNED.
And finally, I think we should try to rewrite tree-ssa-ccp.cc bit-cp from
widest_int to wide_int, even the earlier:
PHI node value: CONSTANT 
0xffe2
 (0x19)
in the -fdump-tree-ccp-details dumps is horribly confusing when the
type is say just 32-bit or 64-bit, and with the recent widest_int changes
those are now around with > 32000 f hex digits in there.  Not to mention we 
shouldn't
really care about state of bits beyond the precision and I think we always
have the type in question around (x.val is INTEGER_CST of the right type
and we just to::widest it, just x.mask is widest_int).

2023-10-14  Jakub Jelinek  

PR tree-optimization/111800
gcc/
* wide-int.cc (assert_deceq): Use wi.get_len () for buffer size
estimation only if !wi::neg_p (wi) or if len is 1 and sgn is SIGNED,
otherwise use WIDE_INT_MAX_HWIS for wi.get_precision ().
(assert_hexeq): Use wi.get_len () for buffer size estimation only
if !wi::neg_p (wi), otherwise use WIDE_INT_MAX_HWIS for
wi.get_precision ().
* wide-int-print.cc (print_decs): Use wi.get_len () for buffer size
estimation only if !wi::neg_p (wi) or if len is 1, otherwise use
WIDE_INT_MAX_HWIS for wi.get_precision ().
(print_decu): Use wi.get_len () for buffer size estimation only if
!wi::neg_p (wi), otherwise use WIDE_INT_MAX_HWIS for
wi.get_precision ().
(print_hex): Likewise.
* value-range.cc (irange_bitmask::dump): Use get_len () for
buffer size estimation only if !wi::neg_p (wi), otherwise use
WIDE_INT_MAX_HWIS for get_precision ().
* value-range-pretty-print.cc (vrange_printer::print_irange_bitmasks):
Likewise.
* tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations): Use
i_bound.get_len () for buffer size estimation only if
!wi::neg_p (i_bound) or if len is 1 and !TYPE_UNSIGNED, otherwise use
WIDE_INT_MAX_HWIS for i_bound.get_precision ().  Use TYPE_SIGN macro
in print_dec call argument.
gcc/c-family/
* c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.

--- gcc/wide-int.cc.jj  2023-10-13 19:34:44.288830022 +0200
+++ gcc/wide-int.cc 2023-10-13 20:23:12.889386810 +0200
@@ -2450,7 +2450,9 @@ static void
 assert_deceq (const char *expected, const wide_int_ref , signop sgn)
 {
   char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf;
   unsigned len = wi.get_len ();
+  if ((len != 1 || sgn == UNSIGNED) && wi::neg_p (wi))
+len = WIDE_INT_MAX_HWIS (wi.get_precision ());
   if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS))
 p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4);
   print_dec (wi, p, sgn);
@@ -2463,7 +2465,11 @@ static void
 assert_hexeq (const char *expected, const wide_int_ref )
 {
   char 

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #113 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-4635-gcb0119242317c2a6f3127b4acff6aadbfd1dfbc4
Author: Jakub Jelinek 
Date:   Sat Oct 14 09:35:44 2023 +0200

middle-end: Allow _BitInt(65535) [PR102989]

The following patch lifts further restrictions which limited _BitInt to at
most 16319 bits up to 65535.
The problem was mainly in INTEGER_CST representation, which had 3
unsigned char members to describe lengths in number of 64-bit limbs, which
it wanted to fit into 32 bits.  This patch removes the third one which was
just a cache to save a few compile time cycles for wi::to_offset and
enlarges the other two members to unsigned short.
Furthermore, the same problem has been in some uses of trailing_wide_int*
(in value-range-storage*) and value-range-storage* itself, while other
uses of trailing_wide_int* have been fine (e.g. CONST_POLY_INT, where no
constants will be larger than 3/5/9/11 limbs depending on target, so 255
limit is plenty).  The patch turns all those length representations to be
unsigned short for consistency, so value-range-storage* can handle even
16320-65535 bits BITINT_TYPE ranges.  The cc1plus growth is about 16K,
so not really significant for 38M .text section.

Note, the reason for the new limit is
  unsigned int precision : 16;
TYPE_PRECISION limit, if we wanted to overcome that, TYPE_PRECISION would
need to use some other member for BITINT_TYPE from all the others and
we could reach that way 4194239 limit (65535 * 64 - 1, again implied by
INTEGER_CST and value-range-storage*).  Dunno if that is
worth it or if it is something we want to do for GCC 14 though.

2023-10-14  Jakub Jelinek  

PR c/102989
gcc/
* tree-core.h (struct tree_base): Remove int_length.offset
member, change type of int_length.unextended and
int_length.extended
from unsigned char to unsigned short.
* tree.h (TREE_INT_CST_OFFSET_NUNITS): Remove.
(wi::extended_tree ::get_len): Don't use
TREE_INT_CST_OFFSET_NUNITS,
instead compute it at runtime from TREE_INT_CST_EXT_NUNITS and
TREE_INT_CST_NUNITS.
* tree.cc (wide_int_to_tree_1): Don't assert
TREE_INT_CST_OFFSET_NUNITS value.
(make_int_cst): Don't initialize TREE_INT_CST_OFFSET_NUNITS.
* wide-int.h (WIDE_INT_MAX_ELTS): Change from 255 to 1024.
(WIDEST_INT_MAX_ELTS): Change from 510 to 2048, adjust comment.
(trailing_wide_int_storage): Change m_len type from unsigned char *
to unsigned short *.
(trailing_wide_int_storage::trailing_wide_int_storage): Change
second
argument from unsigned char * to unsigned short *.
(trailing_wide_ints): Change m_max_len type from unsigned char to
unsigned short.  Change m_len element type from
struct{unsigned char len;} to unsigned short.
(trailing_wide_ints ::operator []): Remove .len from m_len
accesses.
* value-range-storage.h (irange_storage::lengths_address): Change
return type from const unsigned char * to const unsigned short *.
(irange_storage::write_lengths_address): Change return type from
unsigned char * to unsigned short *.
* value-range-storage.cc (irange_storage::write_lengths_address):
Likewise.
(irange_storage::lengths_address): Change return type from
const unsigned char * to const unsigned short *.
(write_wide_int): Change len argument type from unsigned char *&
to unsigned short *&.
(irange_storage::set_irange): Change len variable type from
unsigned char * to unsigned short *.
(read_wide_int): Change len argument type from unsigned char to
unsigned short.  Use trailing_wide_int_storage 
instead of trailing_wide_int_storage and
trailing_wide_int  instead of trailing_wide_int.
(irange_storage::get_irange): Change len variable type from
unsigned char * to unsigned short *.
(irange_storage::size): Multiply n by sizeof (unsigned short)
in len_size variable initialization.
(irange_storage::dump): Change len variable type from
unsigned char * to unsigned short *.
gcc/cp/
* module.cc (trees_out::start, trees_in::start): Remove
TREE_INT_CST_OFFSET_NUNITS handling.
gcc/testsuite/
* gcc.dg/bitint-38.c: Change into dg-do run test, in addition
to checking the addition, division and right shift results at
compile
time check it also at runtime.
* gcc.dg/bitint-39.c: New 

[Bug c++/98533] [11/12/13/14 Regression] ICE: 'verify_type' failed

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

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at gcc dot gnu.org

--- Comment #9 from Roman Zhuykov  ---
Just adding another example where I caught the same error:

$ cat test.cc 
class IR;
class Pass {
public:
explicit Pass(IR *ir) : ir_(ir) {}
virtual ~Pass() = default;
IR *ir_ {nullptr};
};
class PassManager {
public:
template  void RunPass() { T pass(ir_); }
IR *ir_ {nullptr};
};
class IR final {
public:
template  void RunPass() { pass_manager_.RunPass(); }
PassManager pass_manager_;
};
class ThePass : Pass {
public:
explicit ThePass(IR *ir) : Pass(ir) {}
ThePass(const ThePass &) = delete;
template  void Bar(void *inst, Func func
= [](void *) {});
};

void foo(IR *ir) { ir->RunPass(); }

$ g++ -fchecking -g -c test.cc  # any g++ from 8 to 13
test.cc:18:7: error: type variant has different ‘TYPE_FIELDS’
   18 | class ThePass : Pass {
  |   ^~~
 

[Bug c++/111806] g++ generates better code for variant at -Os compared to -O3

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #1 from AK  ---
It seems like we could 'sink' the 4 common instructions (of .L2) at -O3

L2:
add rsp, 48
xor eax, eax
pop rbx
ret


Or is it due to some kind of tail duplication?

[Bug c++/111806] New: g++ generates better code for variant at -Os compared to -O3

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 111806
   Summary: g++ generates better code for variant at
-Os compared to -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

#include
#include
#include

int foo() {
std::variant v {"abc"};
std::cout << std::get<0>(v);
return 0;
}

g++ -O3 -std=c++20 -g0  -fno-exceptions

foo():
.LFB2484:
pushrbx
mov eax, 25185
mov edx, 3
mov edi, OFFSET FLAT:_ZSt4cout
sub rsp, 48
lea rbx, [rsp+16]
mov WORD PTR [rsp+16], ax
mov rsi, rbx
mov QWORD PTR [rsp], rbx
mov BYTE PTR [rsp+18], 99
mov QWORD PTR [rsp+8], 3
mov BYTE PTR [rsp+19], 0
mov BYTE PTR [rsp+32], 0
callstd::basic_ostream >&
std::__ostream_insert >(std::basic_ostream >&, char const*, long)
cmp BYTE PTR [rsp+32], 0
je  .L5
.L2:
add rsp, 48
xor eax, eax
pop rbx
ret
.L5:
mov rdi, QWORD PTR [rsp]
cmp rdi, rbx
je  .L2
mov rax, QWORD PTR [rsp+16]
lea rsi, [rax+1]
calloperator delete(void*, unsigned long)
add rsp, 48
xor eax, eax
pop rbx
ret
.LFE2484:


g++ -Os -std=c++20 -g0  -fno-exceptions


foo():
.LFB2463:
pushrbx
mov edx, 3
mov edi, OFFSET FLAT:_ZSt4cout
sub rsp, 48
lea rbx, [rsp+24]
mov WORD PTR [rsp+24], 25185
mov rsi, rbx
mov QWORD PTR [rsp+8], rbx
mov BYTE PTR [rsp+26], 99
mov QWORD PTR [rsp+16], 3
mov BYTE PTR [rsp+27], 0
mov BYTE PTR [rsp+40], 0
callstd::basic_ostream >&
std::__ostream_insert >(std::basic_ostream >&, char const*, long)
cmp BYTE PTR [rsp+40], 0
jne .L2
mov rdi, QWORD PTR [rsp+8]
cmp rdi, rbx
je  .L2
mov rax, QWORD PTR [rsp+24]
lea rsi, [rax+1]
calloperator delete(void*, unsigned long)
.L2:
add rsp, 48
xor eax, eax
pop rbx
ret
.LFE2463:


https://godbolt.org/z/3xKh35Mrv