[Bug tree-optimization/113358] OpenMP inhibits vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
The issue with block.c is

Analyzing loop at block.c:22
block.c:22:39: note:  === analyze_loop_nest ===
block.c:22:39: note:   === vect_analyze_loop_form ===
block.c:22:39: note:=== get_loop_niters ===
block.c:22:39: missed:   not vectorized: number of iterations cannot be
computed.
block.c:22:39: missed:  bad loop form.
block.c:22:39: missed: couldn't vectorize loop

we fail to compute an expression for the number of scalar iterations in the
innermost loop.  That's because we have 'j < J + BLOCK && j < n' as
the terminating condition.  I suspect that the blocking should peel the
case where J + BLOCK > n, basically

  if (J + BLOCK > n || I + BLOCK > n)
{
  ... blocking nest with < n exit condition
}
  else
{
  ... blocking nest with < {J,I} + BLOCK exit condition
}

the vectorizer (or rather niter analysis) could try to recover in a similar
way with using 'assumptions' - basically we can compute the number of
iterations to BLOCK if we assume that J + BLOCK <= n.  The exit condition
looks like

  _145 = J_86 + 999;
...
   [local count: 958878294]:
  # j_88 = PHI 
...
  j_58 = j_88 + 1;
  _63 = n_49(D) > j_58;
  _64 = j_58 <= _145;
  _65 = _63 & _64;
  if (_65 != 0)

we could try to pattern-match this NE_EXPR (we need to choose which
condition we use as assumption and which to base the niters on).
Another possibility would be (I think this came up in another bugreport
as well) to use j < MIN (J + BLOCK, n).

The following source modification works:

for (int i = I; i < I + BLOCK && i < n; i++) {
int m = J + BLOCK > n ? n : J + BLOCK;
for (int j = J; j < m; j++) {

whether it's a general profitable transform or should be matched again
only during niter analysis I'm not sure (if the MIN is loop invariant
and this is an exit condition it surely is profitable).

[Bug target/113393] RISC-V: Full coverage test bugs for upstream 20240112

[pan2.li at intel dot com via Gcc-bugs]

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

Li Pan  changed:

   What|Removed |Added

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

--- Comment #2 from Li Pan  ---
Closed as fixed in upstream and validated.

[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Target||aarch64

--- Comment #8 from Richard Biener  ---
All these might also point to IPA mod-ref issues.

[Bug tree-optimization/113361] wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed I assume.

[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/113369] Many tests with -save-temps

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Try removing them all and see which ones fail (of course most are gcc.target)? 
I suspect most don't need -save-temps.

Removing -save-temps from tests that pass after that is pre-approved.

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #2 from Richard Biener  ---
Confirmed, it's a recent regression.

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #5 from Richard Biener  ---
(gdb) p debug_gimple_stmt (phi)
.MEM_31 = PHI <.MEM_109(5), (3)>

[Bug tree-optimization/113361] wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0

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

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

--- Comment #3 from Jakub Jelinek  ---
Yes, sorry for not closing it.

[Bug tree-optimization/113379] `MIN == MAX` should be optimzed to `a == b`

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-15
 Ever confirmed|0   |1

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-15

--- Comment #3 from Richard Biener  ---
We could buffer stdin to a temporary file ... (of course that would defeat it's
purpose somewhat).

[Bug tree-optimization/113380] `(a CMP CST) | (a*a CMP CST1)` is not optimized as decent as with `||`

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

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

--- Comment #1 from Richard Biener  ---
Interesting - smells like fold-const.cc stuff not in match.pd.

[Bug fortran/113384] [14 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||testsuite-fail

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Started to ICE with r14-7194-g6cb155a6cf314232248a12bdd395ed4151ae5a28 with
pr113374.c: In function ‘void decode(vector)’:
pr113374.c:7:6: error: PHI node with wrong VUSE on edge from BB 5
7 | void decode(struct vector vec) {
  |  ^~
.MEM_115 = PHI <.MEM_7(5), .MEM_7(3)>
expected .MEM_108
pr113374.c:7:6: error: multiple virtual PHI nodes in BB 11
.MEM_28 = PHI <.MEM_7(7)>
.MEM_116 = PHI <.MEM_9(D)(7)>
pr113374.c:7:6: error: PHI node with wrong VUSE on edge from BB 11
.MEM_30 = PHI <.MEM_116(11), .MEM_115(17)>
expected .MEM_28
during GIMPLE pass: vect
pr113374.c:7:6: internal compiler error: verify_ssa failed
r14-7195-g411de96dbf2bdafc7a90ebbfc63e68afd6388d29 changes the ICE to
during GIMPLE pass: vect
pr113374.c: In function ‘void decode(vector)’:
pr113374.c:7:6: internal compiler error: in as_a, at is-a.h:255
7 | void decode(struct vector vec) {
  |  ^~
0xa16d76 gphi* as_a(gimple*)
../../gcc/is-a.h:255
0x14b5428 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, edge_def*, loop*,
edge_def*, edge_def*, edge_def**, bool, vec*)
../../gcc/tree-vect-loop-manip.cc:1742
0x14ba302 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
../../gcc/tree-vect-loop-manip.cc:3346
0x14a47ee vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.cc:11924
and finally r14-7196-g99c0a540d6689ede068f9ba98af6f38c3cd71362 to
during GIMPLE pass: vect
pr113374.c: In function ‘void decode(vector)’:
pr113374.c:7:6: internal compiler error: Segmentation fault
7 | void decode(struct vector vec) {
  |  ^~
0x1151dc6 crash_signal
../../gcc/toplev.cc:317
0x13485a9 find_uses_to_rename_use
../../gcc/tree-ssa-loop-manip.cc:414
0x1348884 find_uses_to_rename_bb
../../gcc/tree-ssa-loop-manip.cc:489
0x1348a6d find_uses_to_rename
../../gcc/tree-ssa-loop-manip.cc:521
which appears until latest trunk.

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa since r14-6822

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[14 regression] ICE in  |[14 regression] ICE in
   |verify_ssa  |verify_ssa since r14-6822

--- Comment #6 from Jakub Jelinek  ---
Started with r14-6822-g01f4251b8775c832a92d55e2df57c9ac72eaceef

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Pilar Latiesa  ---
(In reply to Pilar Latiesa from comment #0)
> I don't understand why all these functions are even instantiated as they
> appear to be related to the vectorization of other algorithms.

Pragma messages are shown irrespectively of whether the function is
instantiated.

> i.e. is checking defined(_PSTL_USAGE_WARNINGS) instead of just
> _PSTL_USAGE_WARNINGS. This logic doesn't seem right.

This change was made as part of r14-2109-g3162ca09dbdc2e:

- #if _PSTL_USAGE_WARNINGS
+ #if defined(_PSTL_USAGE_WARNINGS)

I don’t think this change is correct.

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Like in PR113374, started to ICE with one message in
r14-7194-g6cb155a6cf314232248a12bdd395ed4151ae5a28, another one in
r14-7195-g411de96dbf2bdafc7a90ebbfc63e68afd6388d29 and yet another one
r14-7196-g99c0a540d6689ede068f9ba98af6f38c3cd71362 which is what we get until
latest trunk.

[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`

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

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

--- Comment #11 from Jakub Jelinek  ---
Like in PR113374, started to ICE with one message in
r14-7194-g6cb155a6cf314232248a12bdd395ed4151ae5a28, another one in  
r14-7195-g411de96dbf2bdafc7a90ebbfc63e68afd6388d29 and yet another one  
r14-7196-g99c0a540d6689ede068f9ba98af6f38c3cd71362 which is what we get until   
latest trunk.

[Bug tree-optimization/113370] wrong code with shift and _BitInt() at -O0

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:8a1927856a10c5ff1b86504c345c8be449b53c30

commit r14-7239-g8a1927856a10c5ff1b86504c345c8be449b53c30
Author: Jakub Jelinek 
Date:   Mon Jan 15 09:58:37 2024 +0100

lower-bitint: Fix up handling of INTEGER_CSTs in handle_operand in right
shifts or comparisons [PR113370]

The INTEGER_CST code uses the remainder bits in computations whether to use
whole constant or just part of it and extend it at runtime, and furthermore
uses it to avoid using all bits even when using the (almost) whole
constant.
The problem is that the prec % (2 * limb_prec) computation it uses is
appropriate only for the normal lowering of mergeable operations (where
we process 2 limbs at a time in a loop starting with least significant
limbs and process the remaining 0-2 limbs after the loop (there with
constant indexes).  For that case it is ok not to emit the upper
prec % (2 * limb_prec) bits into the constant, because those bits will be
extracted using INTEGER_CST idx and so will be used directly in the
statements as INTEGER_CSTs.
For other cases, where we either process just a single limb in a loop,
process it downwards (e.g. non-equality comparisons) or with some runtime
addends (some shifts), there is either just at most one limb lowered with
INTEGER_CST idx after the loop (e.g. for right shift) or before the loop
(e.g. non-equality comparisons), or all limbs are processed with
non-INTEGER_CST indexes (e.g. for left shift, when m_var_msb is set).
Now, the m_var_msb case is already handled through
  if (m_var_msb)
type = TREE_TYPE (op);
  else
/* If we have a guarantee the most significant partial limb
   (if any) will be only accessed through handle_operand
   with INTEGER_CST idx, we don't need to include the
partial
   limb in .rodata.  */
type = build_bitint_type (prec - rem, 1);
but for the right shifts or comparisons the prec - rem when rem was
prec % (2 * limb_prec) was incorrect, so the following patch fixes it
to use remainder for 2 limbs only if m_upwards_2limb and remainder for
1 limb otherwise.

2024-01-15  Jakub Jelinek  

PR tree-optimization/113370
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand): Only
set rem to prec % (2 * limb_prec) if m_upwards_2limb, otherwise
set it to just prec % limb_prec.

* gcc.dg/torture/bitint-48.c: New test.

[Bug tree-optimization/113370] wrong code with shift and _BitInt() at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed, thanks for the report.

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-15
   Priority|P3  |P1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
Confirmed.  The ICE means that loop->num_nodes is out-of-date.

I see an early exit created BB which is in the wrong loop.  This:

  for (auto exit : loop_exits)
{ 
  basic_block dest = main_loop_exit_block;
  if (exit != loop_exit)
{
  if (!alt_loop_exit_block)
{
  alt_loop_exit_block = split_edge (exit);

splits an edge to __assert_fail but is then re-wried

  edge res = redirect_edge_and_branch (
single_succ_edge (alt_loop_exit_block),
new_preheader);
  flush_pending_stmts (res);
  continue;

not sure why we split the edge before redirecting, swapping fixes the
testcase.  remove_bb_from_loops/add_bb_to_loop could also fixup with
the original order.

I'm testing swapping.

[Bug rtl-optimization/113390] [14 Regression] ICE: in model_update_limit_points_in_group, at haifa-sched.cc:1986 with -O2 --param=max-sched-region-insns=200 --param=max-sched-extend-regions-iters=2

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |14.0

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

--- Comment #4 from Jakub Jelinek  ---
The https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364#c9 patch doesn't fix
this.

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

--- Comment #7 from Jakub Jelinek  ---
The https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364#c9 patch doesn't fix
this.

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 57080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57080&action=edit
Further reduced

Reduced further, removes the warnings too.

Still has so many C++ layers in it though.

[Bug tree-optimization/113380] `(a CMP CST) | (a*a CMP CST1)` is not optimized as decent as with `||`

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Interesting - smells like fold-const.cc stuff not in match.pd.

It is not, In the `||` case, the ethread (ranger) is able to opimize away the
second part to either 0 or 1 due to having basic blocks. While in the `|` case
there is no basic block for ranger to anchor to.

I am not 100% sure how to solve this but an idea is if you have a `bool |
bool`, always create during gimplification `if (a) goto c; else if (b) goto c;
else goto d; ` Likewise for `bool & bool`.

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #4 from Alejandro Colomar  ---
On Mon, Jan 15, 2024 at 08:35:53AM +, rguenth at gcc dot gnu.org wrote:
> --- Comment #3 from Richard Biener  ---
> We could buffer stdin to a temporary file ... (of course that would defeat 
> it's
> purpose somewhat).

Not necessarily.  I use stdin for simplicity in small tests.  The
test suite runs some sh(1) scripts, which themselves do more or less:


#!/usr/bin/bash
set -Eeuf;
out="$(mktemp)";
CFLAGS=...
LIBS=...

cc $CFLAGS -o "$out" -x c - $LIBS 2>&1 <<__EOF__ \
| if ! grep -- '-Werror=pointer-sign' >/dev/null; then \
>&2 printf '%s\n' "$0:$LINENO: Expected error:
[-Werror=pointer-sign]"; \
exit 1; \
else \
true; \
fi;
#include 

int
main(void)
{
unsigned char  n;

str2i(signed char, &n, "0");
}
__EOF__

And a script can have several of those embedded C programs, without
really having so many .c files.

If the compiler chooses to use a temporary file to improve the
diagnostics, that's not a problem.

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alejandro Colomar from comment #4)
> 
> Not necessarily.  I use stdin for simplicity in small tests.  The
> test suite

Which testsuite is this?  I should note GCC uses dejagnu (and you can make your
own testsuite using that too for other compilers too) which allows you to do
things like:

```
#include 

int
main(void)
{
  unsigned char  n;
  str2i(signed char, &n, "0"); /* { dg-error "-Werror=pointer-sign" } */
}
```
Which is easier to maintain than shell scripts like you provided in comment #4.
 Note a simple dejagnu testsuite supports dg-error/dg-warning by default; GCC's
version of dg-error/dg-warning has more features though.

[Bug target/113156] [11/12/13/14 Regression] AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r14-7240-gf1b0b1e4454d160564090a4cc1fa649ccefdcb1e
Author: Andrew Pinski 
Date:   Mon Jan 15 10:31:36 2024 +0100

AVR: target/113156 - Fix ICE due to missing "Save" on -m[long-]double=
options.

Multilib options -mdouble= and -mlong-double= are not orthogonal:
TARGET_HANDLE_OPTION = avr-common.cc::avr_handle_option() sets them
such that  sizeof(double) <= sizeof(long double)  is always true.

gcc/
PR target/113156
* config/avr/avr.opt (-mdouble, -mlong-double): Add "Save" flag.
(-mbranch-cost): Set "Optimization" flag.

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Pilar Latiesa from comment #1)
> (In reply to Pilar Latiesa from comment #0)
> > I don't understand why all these functions are even instantiated as they
> > appear to be related to the vectorization of other algorithms.
> 
> Pragma messages are shown irrespectively of whether the function is
> instantiated.

Yeah, I don't know if Clang works differently (I don't think so?) or if those
pragmas are just misused. They come from the upstream PSTL project.

> 
> > i.e. is checking defined(_PSTL_USAGE_WARNINGS) instead of just
> > _PSTL_USAGE_WARNINGS. This logic doesn't seem right.
> 
> This change was made as part of r14-2109-g3162ca09dbdc2e:
> 
> - #if _PSTL_USAGE_WARNINGS
> + #if defined(_PSTL_USAGE_WARNINGS)
> 
> I don’t think this change is correct.

Good catch.

[Bug c++/113388] Calling explicit object member function without object argument inside a function that is not an implicit object member function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-15
 Ever confirmed|0   |1

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #12 from Lukas Grätz  ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++.  I fixed it by
> keeping callee-saved registers when exception is enabled.


I guess that exception throwing needs callee-saved registers, because it uses
stack unwinding to do something very similar to a return.


void f1(void) {
  CODE, compiler translation uses callee-saved %r12
  f2();
  CODE, compiler translation uses callee-saved %r12
}

void f2(void) {
  f3();
}

void f3(void) {
  CODE, compiler translation uses callee-saved %r12
  f4();
  while(1);
}

void f4(void) {
  CODE, uses loop unwinding functions
a) restores all callee-saved registers in f3(), f2()
b) restores %rsp and %rip from stack of f2()
  unreachable();
}

In effect, b) is a return from the call f2() in f1(), although it happens in
f4().

%r12 needs only to be saved in f1() and f3(). Gcc with -O2 would do that.
However, with your patch, %r12 would not be saved in f3() anymore. This can
lead to crashing in the second CODE block in f1().

The solution should require __attribute__((nothrow)) in addition to noreturn in
your optimization patch. The b) in f4() should/would be treated as a throw. So
none of f1(), f2(), f3() should have the attribute nothrow.

So in the example of this report, the signature of value() should be modified
to:

extern __attribute__((nothrow)) unsigned value(int i, int j, int k);

Only then it is safe to skip saving callee-saved registers. "nothrow" should
also be added to bar() and fn() in your test case pr38534-2.c.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems this is invalid variable sharing during RTL, I'm afraid we have tons of
open bugs against that, and I'm afraid I don't know anything what to do on the
bitint lowering side.
Bitint lowering creates 3 large variables:
  unsigned long bitint.8[75];
  unsigned long bitint.7[75];
  unsigned long bitint.6[100];
where bitint.6 corresponds to
  _3 = _2 % y_14(D);
and later when _3 isn't needed anymore to
  _8 = -y_14(D);
bitint.7 corresponds to
  _4 = -_3;
  _5 = (unsigned _BitInt(4745)) _4;
and bitint.8 corresponds to
  _7 = _5 * _6;
Reusing the same variable bitint.6 for 2 different _BitInt(6384) SSA_NAMEs
ought to be fine, they aren't live at the same time.
After lowering, we end up with:
  .DIVMODBITINT (0B, 0, &bitint.6, 6384, &D.2796, -8, &y, -6384);
  // Above fills in bitint.6 array
...
  loop which uses bitint.6 to compute bitint.7
  bitint.6 ={v} {CLOBBER(eos)};
...
  .MULBITINT (&bitint.8, 4745, &bitint.7, 4745, &D.2795, -8);
  // Above fills in bitint.8 array
...
  loop to compute bitint.6
...
  loop which uses bitint.6
...
  _21 = MEM[(unsigned long *)&bitint.8];
  _22 = (_BitInt(8)) _21;
  _18 = _22;
  return _18;
  // I.e. use bitint.8 for the return value

But unfortunately RTL expansion decides to use the same underlying memory for
bitint.6 and bitint.8 arrays, even when the second uses of bitint.6 happens
when bitint.8 is live.

Or am I using incorrect CLOBBER kind when an underlying variable is used for
more than one SSA_NAME?  Like should that be just eob rather than eos?

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Though, sed -i -e 's/CLOBBER_STORAGE_END/CLOBBER_OBJECT_END/'
gimple-lower-bitint.cc
doesn't help and the bogus variable sharing still happens.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #13 from Lukas Grätz  ---
(In reply to Lukas Grätz from comment #12)

>   CODE, uses loop unwinding functions
>a) restores all callee-saved registers in f3(), f2()
>b) restores %rsp and %rip from stack of f2()

I meant stack unwinding.  f3() and f2() can be in separate compilation units,
it needs is ".cfi_offset REGISTER, OFFSET" from the elf (also in the generated
assembly).

[Bug middle-end/113395] New: RTL expansion drops MEM_EXPR

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

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

Bug ID: 113395
   Summary: RTL expansion drops MEM_EXPR
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct S {
  signed m : 7;
  signed e : 2;
} g;

void
k()
{
  g.e ^= 1;
}

expands as

(insn 8 7 0 (parallel [
(set (mem/j/c:HI (reg/f:DI 100) [0 +0 S2 A32])
(xor:HI (mem/j/c:HI (reg/f:DI 100) [0 +0 S2 A32])
(reg:HI 101)))
(clobber (reg:CC 17 flags))
]) "t.c":9:7 -1
 (nil))

similar g.e = 1;

(insn 9 8 10 (set (reg:HI 102)
(mem/j/c:HI (reg/f:DI 101) [0 +0 S2 A32])) "t.c":9:7 -1
 (nil))
...
(insn 12 11 0 (set (mem/j/c:HI (reg/f:DI 101) [0 +0 S2 A32])
(reg:HI 104)) "t.c":9:7 -1
 (nil))

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #36 from JuzheZhong  ---
Hi, Patrick.

I just fixed a bug that will cause VSETVL PASS and AVL prop PASS bug.

Could you trigger a full run of SPEC with -O3 -ftrapping-math again ?

Thanks.

[Bug c/113378] _Static_assert diagnostics lack information when compiling stdin

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #6 from Alejandro Colomar  ---
On Mon, Jan 15, 2024 at 09:38:31AM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378
> 
> --- Comment #5 from Andrew Pinski  ---
> (In reply to Alejandro Colomar from comment #4)
> > 
> > Not necessarily.  I use stdin for simplicity in small tests.  The
> > test suite
> 
> Which testsuite is this?

Nothing standard.  Just a hand-written GNUmakefile that runs all scripts
within share/tests/.


TESTS  := $(shell $(FIND) $(TESTSDIR) -type f | $(GREP) '\.sh$$' |
$(SORT))
_TESTS := $(patsubst $(srcdir)/share/%,$(builddir)/%.ck.touch,$(TESTS))
_tests := $(patsubst
$(srcdir)/share/%,$(builddir)/%.ick.touch,$(TESTS))


_TESTSDIRS := $(patsubst $(srcdir)/share/%,$(builddir)/%/,$(shell
$(FIND) $(TESTSDIR) -type d | $(SORT)))


$(_TESTSDIRS): | $$(dir $$(@D))
$(info  MKDIR   $@)
$(MKDIR) $@


$(_TESTS): $(builddir)/%.ck.touch: $(srcdir)/share/% $(MK) $(TU_h)
$(_LIB_a) $(_LIB_so_v) | $$(@D)/
$(info  SH (test)   $@)
PKG_CONFIG_LIBDIR=$(PCDIR) $<
touch $@

$(_tests): $(builddir)/%.ick.touch: $(srcdir)/share/% $(MK) $(_tu_h)
$(_lib_a) $(_lib_so) | $$(@D)/
$(info  SH (test)   $@)
$<
touch $@


.PHONY: check
check: $(_TESTS)


.PHONY: installcheck
installcheck: $(_tests)


>  I should note GCC uses dejagnu (and you can make your
> own testsuite using that too for other compilers too) which allows you to do
> things like:

I know.  I want to learn to use it if I find some time, and replace my
custom scripts.

> ```
> #include 
> 
> int
> main(void)
> {
>   unsigned char  n;
>   str2i(signed char, &n, "0"); /* { dg-error "-Werror=pointer-sign" } */
> }
> ```
> Which is easier to maintain than shell scripts like you provided in comment 
> #4.
>  Note a simple dejagnu testsuite supports dg-error/dg-warning by default; 
> GCC's
> version of dg-error/dg-warning has more features though.

Thanks!

Have a lovely day,
Alex

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #4 from Jakub Jelinek  ---
Ah, so it really is the classical stack conflicts vs. ADDR_EXPR problem.
Before dom3 we have
  _2 = &bitint.6 + 8;
  ivtmp.40_3 = (unsigned long) _2;
from ivopts above the loop using bitint.6 and
  _44 = &bitint.6 + 8;
  ivtmp.28_43 = (unsigned long) _44;
above the second loop computing bitint.6, with
  bitint.6 ={v} {CLOBBER(eos)};
in between (or eob).
dom3 optimizes the latter to
  _44 = &MEM  [(void *)&bitint.6 + 8B];
  ivtmp.28_43 = ivtmp.40_3;
and later on all the visible uses of bitint.6 in the second part of the
function
after
  bitint.6 ={v} {CLOBBER(eos)};
disappear.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek  ---
> Seems this is invalid variable sharing during RTL, I'm afraid we have tons of
> open bugs against that, and I'm afraid I don't know anything what to do on the
> bitint lowering side.
> Bitint lowering creates 3 large variables:
>   unsigned long bitint.8[75];
>   unsigned long bitint.7[75];
>   unsigned long bitint.6[100];
> where bitint.6 corresponds to
>   _3 = _2 % y_14(D);
> and later when _3 isn't needed anymore to
>   _8 = -y_14(D);
> bitint.7 corresponds to
>   _4 = -_3;
>   _5 = (unsigned _BitInt(4745)) _4;
> and bitint.8 corresponds to
>   _7 = _5 * _6;
> Reusing the same variable bitint.6 for 2 different _BitInt(6384) SSA_NAMEs
> ought to be fine, they aren't live at the same time.
> After lowering, we end up with:
>   .DIVMODBITINT (0B, 0, &bitint.6, 6384, &D.2796, -8, &y, -6384);
>   // Above fills in bitint.6 array
> ...
>   loop which uses bitint.6 to compute bitint.7
>   bitint.6 ={v} {CLOBBER(eos)};
> ...
>   .MULBITINT (&bitint.8, 4745, &bitint.7, 4745, &D.2795, -8);
>   // Above fills in bitint.8 array
> ...
>   loop to compute bitint.6
> ...
>   loop which uses bitint.6
> ...
>   _21 = MEM[(unsigned long *)&bitint.8];
>   _22 = (_BitInt(8)) _21;
>   _18 = _22;
>   return _18;
>   // I.e. use bitint.8 for the return value
> 
> But unfortunately RTL expansion decides to use the same underlying memory for
> bitint.6 and bitint.8 arrays, even when the second uses of bitint.6 happens
> when bitint.8 is live.
> 
> Or am I using incorrect CLOBBER kind when an underlying variable is used for
> more than one SSA_NAME?  Like should that be just eob rather than eos?

I think it's OK, but likely the address-taken of bitint.8 somehow breaks
things.  Does RTL expansion properly handle internal-functions here?

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-7243-gafac1bd33657a5054f5e6ea6746c25bbb70b82f2
Author: Richard Biener 
Date:   Mon Jan 15 10:03:59 2024 +0100

tree-optimization/113385 - wrong loop father with early exit vectorization

The following avoids splitting an edge before redirecting it.  This
allows the loop father of the new block to be correct in the first
place.

PR tree-optimization/113385
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
First redirect, then split the exit edge.

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Should be fixed.

[Bug target/113156] [11/12/13/14 Regression] AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

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

commit r13-8223-gd73e585c72cd9c47992185a83fdd9bd28347029a
Author: Andrew Pinski 
Date:   Mon Jan 15 10:31:36 2024 +0100

AVR: target/113156 - Fix ICE due to missing "Save" on -m[long-]double=
options.

Multilib options -mdouble= and -mlong-double= are not orthogonal:
TARGET_HANDLE_OPTION = avr-common.cc::avr_handle_option() sets them
such that  sizeof(double) <= sizeof(long double)  is always true.

gcc/
PR target/113156
* config/avr/avr.opt (-mdouble, -mlong-double): Add "Save" flag.
(-mbranch-cost): Set "Optimization" flag.

(cherry picked from commit f1b0b1e4454d160564090a4cc1fa649ccefdcb1e)

[Bug target/113156] [11/12/13/14 Regression] AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:

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

commit r12-10097-g2bce77d6e17efd801b2a6fee72e511c0597dc5c2
Author: Andrew Pinski 
Date:   Mon Jan 15 10:31:36 2024 +0100

AVR: target/113156 - Fix ICE due to missing "Save" on -m[long-]double=
options.

Multilib options -mdouble= and -mlong-double= are not orthogonal:
TARGET_HANDLE_OPTION = avr-common.cc::avr_handle_option() sets them
such that  sizeof(double) <= sizeof(long double)  is always true.

gcc/
PR target/113156
* config/avr/avr.opt (-mdouble, -mlong-double): Add "Save" flag.
(-mbranch-cost): Set "Optimization" flag.

(cherry picked from commit f1b0b1e4454d160564090a4cc1fa649ccefdcb1e)

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #6 from Jakub Jelinek  ---
So, couldn't we attempt at least a partial workaround at add_scope_conflicts
time?
I mean, for SSA_NAME uses in statements with some caching try to check if those
SSA_NAMEs may contain addresses (or because of ivopts also in pointer-sized
integers) of particular DECL_RTL_IF_SET (op) == pc_rtx vars or set of them and
treat those as if they were the addresses too?
I mean where we call walk_stmt_load_store_addr_ops also check uses of SSA_NAMEs
which are based on those ADDR_EXPRs and treat those similarly.
It wouldn't handle say const or pure functions taking address of some var and
say returning something based on it, but perhaps could workaround the most
common issues in the wild with stack sharing.

[Bug c/113396] New: csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113396
   Summary: csmith: differences from -O2 to -O3
   Product: gcc
   Version: 14.0
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 57082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57082&action=edit
C source code

The attached Csmith generated code does this:

foundBugs $ ~/gcc/results/bin/gcc -w bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 130B5204
foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 130B5204
foundBugs $

[Bug middle-end/113395] RTL expansion drops MEM_EXPR

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

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

--- Comment #1 from Richard Biener  ---
Because of

#0  adjust_address_1 (memref=0x771e8db0, mode=E_HImode, offset=..., 
validate=1, adjust_address=1, adjust_object=1, size=...)
at /space/rguenther/src/gcc/gcc/emit-rtl.cc:2409
#1  0x011459af in narrow_bit_field_mem (mem=0x771e8db0, 
mode=HImode, bitsize=2, bitnum=7, new_bitnum=0x7fffc8c0)
at /space/rguenther/src/gcc/gcc/expmed.cc:453
#2  0x01145d1c in adjust_bit_field_mem_for_reg (pattern=EP_insv, 
op0=0x771e8db0, bitsize=2, bitnum=7, bitregion_start=..., 
bitregion_end=..., fieldmode=E_VOIDmode, new_bitnum=0x7fffc8c0)
at /space/rguenther/src/gcc/gcc/expmed.cc:511
#3  0x011483bb in store_integral_bit_field (op0=0x771e8db0, 
op0_mode=SImode, bitsize=2, bitnum=7, bitregion_start=..., 
bitregion_end=..., fieldmode=E_VOIDmode, value=0x770124a0, 
reverse=false, fallback_p=true)
at /space/rguenther/src/gcc/gcc/expmed.cc:1086
#4  0x011476a0 in store_bit_field_1 (str_rtx=0x771e8db0, 
bitsize=..., bitnum=..., bitregion_start=..., bitregion_end=..., 
fieldmode=E_VOIDmode, value=0x770124a0, reverse=false, 
fallback_p=true, undefined_p=false)
at /space/rguenther/src/gcc/gcc/expmed.cc:887
#5  0x01148c31 in store_bit_field (str_rtx=0x771e8db0, 
bitsize=..., bitnum=..., bitregion_start=..., bitregion_end=..., 
fieldmode=E_VOIDmode, value=0x770124a0, reverse=false, 
--Type  for more, q to quit, c to continue without paging--
) at /space/rguenther/src/gcc/gcc/expmed.cc:1194
#6  0x0117dde0 in store_field (target=0x771e8db0, bitsize=..., 
bitpos=..., bitregion_start=..., bitregion_end=..., mode=E_VOIDmode, 
exp=, alias_set=1, nontemporal=false, 
reverse=false) at /space/rguenther/src/gcc/gcc/expr.cc:8245
#7  0x01174b21 in expand_assignment (
to=, from=, 
nontemporal=false) at /space/rguenther/src/gcc/gcc/expr.cc:6303

and we run into

  if (maybe_ne (size, 0))
{
  /* Drop the object if the new right end is not within its bounds.  */
  if (adjust_object && maybe_gt (offset + size, attrs.size))
{
  attrs.expr = NULL_TREE;
  attrs.alias = 0;
}

as attrs.size is originally 1 and we are creating a two byte HImode access.

IMHO it's the fault of how we set up the initial memory attributes which
come via expand_assignment doing

  tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
 &unsignedp, &reversep, &volatilep);
..
  if (TREE_CODE (to) == COMPONENT_REF
  && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, &offset);
..
  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
..
  if (MEM_P (to_rtx))
{
  /* If the field is at offset zero, we could have been given the
 DECL_RTX of the parent struct.  Don't munge it.  */
  to_rtx = shallow_copy_rtx (to_rtx);
  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
  if (volatilep)
MEM_VOLATILE_P (to_rtx) = 1;

that's an unfortunate setup to eventually widen the setup.

RTL alias analysis then has to rely on find_base_term to perform it's
bogus optimistic points-to analysis.

[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|RTL expansion drops |RTL expansion of bitfield
   |MEM_EXPR|accesses drops MEM_EXPR
 Blocks||113255

--- Comment #2 from Richard Biener  ---
gcc.dg/tree-ssa/pr94969.c for example misses RTL PRE when we dumb down
find_base_term to be conservatively correct.  GIMPLE invariant motion
doesn't handle the involved aggregate copy which on RTL maps to SImode.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
[Bug 113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8

[Bug tree-optimization/113397] New: [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113397
   Summary: [14 Regression] ICE: SIGSEGV in tree_check
(tree.h:3611) with -fdump-ada-spec-slim on
gcc.c-torture/execute/pr22061-2.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

This fails on the gcc.c-torture/execute/pr22061-2.c testcase with
-fdump-ada-spec-slim

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fdump-ada-spec-slim
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/pr22061-2.c -wrapper
valgrind,-q
==1560== Invalid read of size 2
==1560==at 0xF0BC45: tree_check (tree.h:3611)
==1560==by 0xF0BC45: check_type_name_conflict(pretty_printer*, tree_node*)
(c-ada-spec.cc:1570)
==1560==by 0xF0E692: dump_ada_function_declaration(pretty_printer*,
tree_node*, bool, bool, bool, int) (c-ada-spec.cc:1654)
==1560==by 0xF0FFA3: dump_ada_declaration(pretty_printer*, tree_node*,
tree_node*, int) (c-ada-spec.cc:3135)
==1560==by 0xF11859: dump_ada_nodes (c-ada-spec.cc:826)
==1560==by 0xF11859: dump_ads (c-ada-spec.cc:3525)
==1560==by 0xF11859: dump_ada_specs(void (*)(char const*), int
(*)(tree_node*, cpp_operation)) (c-ada-spec.cc:3604)
==1560==by 0xE0D6BF: c_parse_final_cleanups() (c-decl.cc:13416)
==1560==by 0xEFAE00: c_common_parse_file() (c-opts.cc:1319)
==1560==by 0x150D66D: compile_file() (toplev.cc:447)
==1560==by 0xDE6B0B: do_compile (toplev.cc:2152)
==1560==by 0xDE6B0B: toplev::main(int, char**) (toplev.cc:2308)
==1560==by 0xDE82EA: main (main.cc:39)
==1560==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1560== 
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/pr22061-2.c:8:1: internal
compiler error: Segmentation fault
8 | }
  | ^
0x150d36f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0xf0bc45 tree_check(tree_node*, char const*, int, char const*, tree_code)
/repo/gcc-trunk/gcc/tree.h:3611
0xf0bc45 check_type_name_conflict
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:1570
0xf0e692 dump_ada_function_declaration
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:1654
0xf0ffa3 dump_ada_declaration
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:3135
0xf11859 dump_ada_nodes
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:826
0xf11859 dump_ads
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:3525
0xf11859 dump_ada_specs(void (*)(char const*), int (*)(tree_node*,
cpp_operation))
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:3604
0xe0d6bf c_parse_final_cleanups()
/repo/gcc-trunk/gcc/c/c-decl.cc:13416
0xefae00 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1319
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.

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

[Bug tree-optimization/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
This actually fails the same way with plain -fdump-ada-spec, but I disabled
that flag due to PR107978 and PR107977

[Bug tree-optimization/113281] [14 Regression] Wrong code due to vectorization of shift reduction and missing promotions

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

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

--- Comment #12 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:405096f908e1ceb0d6a1b5420ded20ad85ddae9e

commit r14-7244-g405096f908e1ceb0d6a1b5420ded20ad85ddae9e
Author: Juzhe-Zhong 
Date:   Mon Jan 15 09:22:40 2024 +0800

RISC-V: Adjust loop len by costing 1 when NITER < VF

Rebase in v3: Rebase to the trunk and commit it as it's approved by Robin.
Update in v2: Add dynmaic lmul test.

This patch fixes the regression between GCC 13.2.0 and trunk GCC (GCC-14)

GCC 13.2.0:

lui a5,%hi(a)
li  a4,19
sb  a4,%lo(a)(a5)
li  a0,0
ret

Trunk GCC:

vsetvli a5,zero,e8,mf2,ta,ma
li  a4,-32768
vid.v   v1
vsetvli zero,zero,e16,m1,ta,ma
addiw   a4,a4,104
vmv.v.i v3,15
lui a1,%hi(a)
li  a0,19
vsetvli zero,zero,e8,mf2,ta,ma
vadd.vi v1,v1,1
sb  a0,%lo(a)(a1)
vsetvli zero,zero,e16,m1,ta,ma
vzext.vf2   v2,v1
vmv.v.x v1,a4
vminu.vvv2,v2,v3
vsrl.vv v1,v1,v2
vslidedown.vi   v1,v1,17
vmv.x.s a0,v1
sneza0,a0
ret

The root cause we are vectorizing the codes inefficiently since we doesn't
cost len when NITERS < VF.
Leverage loop control of mask targets or rs6000 fixes the regression.

Tested no regression. Ok for trunk ?

PR target/113281

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc
(costs::adjust_vect_cost_per_loop): New function.
(costs::finish_cost): Adjust cost for LOOP LEN with NITERS < VF.
* config/riscv/riscv-vector-costs.h: New function.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr113281-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113281-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113281-5.c: New test.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #7 from Jakub Jelinek  ---
I believe such a change could workaround this PR, PR110115, PR111422, PR90348
among others just from quick search.

[Bug c/113396] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
foundBugs $ ~/gcc/results/bin/gcc -w  -O2  bug998.c -o two.exe
foundBugs $ ~/gcc/results/bin/gcc -w  -O3  bug998.c -o three.exe
foundBugs $ ./two.exe 1 > two.out
foundBugs $ ./three.exe 1 > three.out
foundBugs $ diff two.out three.out  | head -20
510,520c510,520
< ...checksum after hashing g_179.f2 : F8C8E936
< ...checksum after hashing g_179.f3 : 22C7AEC4
< ...checksum after hashing g_179.f4 : E057A6AE
< ...checksum after hashing g_179.f5 : 494E34F0
< ...checksum after hashing g_179.f6 : 72F55A7C
< ...checksum after hashing g_179.f7 : 9B53D63F
< ...checksum after hashing g_179.f8 : DD10C49F
< ...checksum after hashing g_179.f9 : 979E03A7
< ...checksum after hashing g_195 : 63EDBCE7
< ...checksum after hashing g_196 : C1F2B26B
< ...checksum after hashing g_226[i][j] : 835FC1
---
> ...checksum after hashing g_179.f2 : A0B13872
> ...checksum after hashing g_179.f3 : A6EAB221
> ...checksum after hashing g_179.f4 : 744D7BAB
> ...checksum after hashing g_179.f5 : 4D71F83C
> ...checksum after hashing g_179.f6 : 54EDEE43
> ...checksum after hashing g_179.f7 : B280A60F
> ...checksum after hashing g_179.f8 : ECCE643D
foundBugs $

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> So, couldn't we attempt at least a partial workaround at add_scope_conflicts
> time?
> I mean, for SSA_NAME uses in statements with some caching try to check if
> those SSA_NAMEs may contain addresses (or because of ivopts also in
> pointer-sized integers) of particular DECL_RTL_IF_SET (op) == pc_rtx vars or
> set of them and treat those as if they were the addresses too?
> I mean where we call walk_stmt_load_store_addr_ops also check uses of
> SSA_NAMEs which are based on those ADDR_EXPRs and treat those similarly.
> It wouldn't handle say const or pure functions taking address of some var
> and say returning something based on it, but perhaps could workaround the
> most common issues in the wild with stack sharing.

I belive we investigated such workarounds but they didn't seem to work?  Other
cases are concerned with address uses before loops (I think they start
lifetime "correctly" now) but CLOBBERs ending lifetime inside the loop.  The
dataflow problem then is confused with the backedge having the object not
live IIRC.

So what would your workaround do?  Not handle address mentions as starting
live but only its (possible) memory uses?

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #14 from Lukas Grätz  ---
Never mind my above comments. I just realized that attribute nothrow has no
effect in C, unless -fexceptions. So nothrow is not needed (only
-fno-exceptions). Furthermore, most noreturn functions throw in C++, so there
would be little potential optimization when exceptions are enabled.

What puzzles me, is that functions like exit() have different signatures in C
and C++. With "gcc -E -fexceptions somefile.cc" I get

  extern void exit (int __status)
throw () __attribute__ ((__noreturn__));

in C++ and in C I get with "gcc -E -fexceptions somefile.c"

  extern void exit (int __status)
__attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));

, although exceptions are explicitly enabled in both cases. But I guess this is
a problem in Glibc, not GCC.

I will really shut up now, promise!

[Bug tree-optimization/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #8)
> I belive we investigated such workarounds but they didn't seem to work? 
> Other
> cases are concerned with address uses before loops (I think they start
> lifetime "correctly" now) but CLOBBERs ending lifetime inside the loop.  The
> dataflow problem then is confused with the backedge having the object not
> live IIRC.
> 
> So what would your workaround do?  Not handle address mentions as starting
> live but only its (possible) memory uses?

I meant in addition to the current cases which start uses (ADDR_EXPRs in the
IL, loads and stores) also handle like that uses of SSA_NAMEs which can contain
those ADDR_EXPRs.
So, say add a mapping from SSA_NAME_VERSION to a bitmap (or vector?) of DECLs
and propagate through uses which addresses of decl they (may) refer to and then
when
add_scope_conflicts_1 sees uses of those SSA_NAMEs, visit_conflict those too.
So, say on the testcase from this PR, when seeing
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6 +
8B];
mark 3 -> bitint.6
  # ivtmp.40_39 = PHI 
mark 39 -> bitint.6
  # ivtmp.28_40 = PHI 
mark 40 -> bitint.6
  _147 = (void *) ivtmp.40_39;
mark 147 -> bitint.6
  ivtmp.40_38 = ivtmp.40_39 + 16;
mark 38 -> bitint.6
  _27 = (void *) ivtmp.28_40;
mark 27 -> bitint.6
  ivtmp.28_41 = ivtmp.28_40 + 16;
mark 48 -> bitint.6
  _98 = MEM[(unsigned long *)_147 + -8B];
don't do anything, this is a load from it, etc.
  if (ivtmp.40_38 != _57)
again, nothing, etc.
  _7 = (unsigned long) &bitint.6;
mark 7 -> bitint.6
  _57 = _7 + 600;
mark _57 -> bitint.6
  if (ivtmp.40_38 != _57)
nothing
  ivtmp.41_139 = (unsigned long) &MEM  [(void *)&bitint.7 +
8B];
mark 139 -> bitint.7
  # ivtmp.41_137 = PHI 
mark 137 -> bitint.7
  _146 = (void *) ivtmp.41_137;
mark 146 -> bitint.7
  ivtmp.41_138 = ivtmp.41_137 + 16;
mark 138 -> bitint.7
  .DIVMODBITINT (0B, 0, &bitint.6, 6384, &D.2796, -8, &y, -6384);
nothing
  _108 = MEM[(unsigned long *)&bitint.6 + 592B];
nothing, etc.
Basically, only handle statements which can propagate address (or pointer-sized
integer based on it) of a tracked variable or pointer arithmetics based on that
to other SSA_NAMEs.
Of course, big question is what kind of propagation to use for that.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #10 from Jakub Jelinek  ---
Example statements which should be handled during the propagation from the
other PRs:
  ivtmp.32_28 = (unsigned long) ∈
  _44 = &g + _43;
guess a plain
  _1234 = &whatever;
too.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #11 from Richard Biener  ---
So the key would be to make the object live again after a CLOBBER when such
address SSA name is used (but before any other explicit mention appears)?

The current algorithm relies on explitic mentions appearing, one original
idea was to turn those explicit mentions (or BLOCK starts) into
start-of-live CLOBBERs, but even that was shown to be not enough.

But yes, if we want to try to mitigate the problems somewhat without
doing a full solution then possibly even just looking at SSA defs
when POINTER_TYPE and the def is an ADDR_EXPR might work (in the
visit_* callbacks of the walk_stmt_load_store_addr_ops), no propagation
needed at all (basically just undo CSE virtually here for the simple
cases).

[Bug libstdc++/113398] New: no longer usable with -ffreestanding

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

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

Bug ID: 113398
   Summary:  no longer usable with -ffreestanding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This used to work with GCC 12 when compiled with -ffreestanding

#include 

// Defined by the user.
void* operator new(std::size_t n);
void operator delete(void*, std::size_t n);

int main()
{
  std::string s = "a string that needs to allocate from the heap";
  return s.size();
}


Since GCC 13 the -ffreestanding option also selects a freestanding libstdc++,
which doesn't allow std::string to be used.

The change was done intentionally, to provide a more clearly defined and
documented freestanding library, but it removes functionality that was being
used.

[Bug libstdc++/113398] no longer usable with -ffreestanding

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

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

--- Comment #1 from Jonathan Wakely  ---
In file included from /home/jwakely/gcc/13/include/c++/13.2.1/string:38,
 from free.cc:1:
/home/jwakely/gcc/13/include/c++/13.2.1/bits/requires_hosted.h:34:4: error:
#error "This header is not available in freestanding mode."
   34 | #  error "This header is not available in freestanding mode."
  |^

[Bug target/113247] RISC-V: Performance bug in SHA256 after enabling RVV vectorization

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:7be87b7d2e330afd14a7cc028f64d88f80e12f40

commit r14-7245-g7be87b7d2e330afd14a7cc028f64d88f80e12f40
Author: Juzhe-Zhong 
Date:   Mon Jan 15 20:00:14 2024 +0800

RISC-V: Fix regression (GCC-14 compare with GCC-13.2) of SHA256 from
coremark-pro

This patch fixes -70% performance drop from GCC-13.2 to GCC-14 with
-march=rv64gcv in real hardware.

The root cause is incorrect cost model cause inefficient vectorization
which makes us performance drop significantly.

So this patch does:

1. Adjust vector to scalar cost by introducing v to scalar reg move.
2. Adjust vec_construct cost since we does spend NUNITS instructions to
construct the vector.

Tested on both RV32/RV64 no regression, Rebase to the trunk and commit it
as it is approved by Robin.

PR target/113247

gcc/ChangeLog:

* config/riscv/riscv-protos.h (struct regmove_vector_cost): Add
vector to scalar regmove.
* config/riscv/riscv-vector-costs.cc (adjust_stmt_cost): Ditto.
* config/riscv/riscv.cc (riscv_builtin_vectorization_cost): Adjust
vec_construct cost.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls/reduc-19.c: Adapt test.
* gcc.target/riscv/rvv/autovec/vls/reduc-20.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/reduc-21.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/pr113247-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113247-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113247-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/pr113247-4.c: New test.

[Bug target/113247] RISC-V: Performance bug in SHA256 after enabling RVV vectorization

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #12 from JuzheZhong  ---
Fixed

[Bug other/113399] New: -ffold-mem-offsets should not be a target option

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

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

Bug ID: 113399
   Summary: -ffold-mem-offsets should not be a target option
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

For some reason, -ffold-mem-offsets is a target option and displayed with
--help=target, which it shold not.

> grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool Var(flag_fold_mem_offsets) Init(1)
Fold instructions calculating memory offsets to the memory access instruction
if possible.

Added in r14-4664

[Bug target/113156] [11/12/13/14 Regression] AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||opt-attribute

--- Comment #15 from Georg-Johann Lay  ---
Should work now on v12.4+ and v13.3+

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #11)
> So the key would be to make the object live again after a CLOBBER when such
> address SSA name is used (but before any other explicit mention appears)?
> 
> The current algorithm relies on explitic mentions appearing, one original
> idea was to turn those explicit mentions (or BLOCK starts) into
> start-of-live CLOBBERs, but even that was shown to be not enough.
> 
> But yes, if we want to try to mitigate the problems somewhat without
> doing a full solution then possibly even just looking at SSA defs
> when POINTER_TYPE and the def is an ADDR_EXPR might work (in the
> visit_* callbacks of the walk_stmt_load_store_addr_ops), no propagation
> needed at all (basically just undo CSE virtually here for the simple
> cases).

It couldn't be limited to just POINTER_TYPE, because it mostly is actually
pointer-sized unsigned integer from IVOPTs, but yes, even without full
propagation I think all the testcases I've mentioned could be solved by just
doing the short walks in PHI arguments or other SSA_NAME uses (only PR111422
needs the latter).
For this PR, we'd need to visit for ivtmp.40_3 uses in PHI args the def-stmt:
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6 +
8B];
for PR90348 ivtmp.32_28's def-stmt:
  ivtmp.32_28 = (unsigned long) ∈
for PR110115 ivtmp.27_2's def-stmt:
  ivtmp.27_2 = (unsigned long) &h;
fpr PR111422 _44's def-stmt:
  _44 = &g + _43;
So, if you think it is ok to use just a small hack rather than full propagation
(which could even handle const/pure calls perhaps if they return pointer or
pointer-sized integer), I can implement that too.  Even the full propagation
wouldn't handle everything of course, but could handle more than the small hack
(which would need to be limited to just say 4 def-stmts and wouldn't try to
look through PHIs).

[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|-ffold-mem-offsets should   |[14 Regression]
   |not be a target option  |-ffold-mem-offsets should
   ||not be a target option
   Target Milestone|--- |14.0

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
> 
> --- Comment #12 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #11)
> > So the key would be to make the object live again after a CLOBBER when such
> > address SSA name is used (but before any other explicit mention appears)?
> > 
> > The current algorithm relies on explitic mentions appearing, one original
> > idea was to turn those explicit mentions (or BLOCK starts) into
> > start-of-live CLOBBERs, but even that was shown to be not enough.
> > 
> > But yes, if we want to try to mitigate the problems somewhat without
> > doing a full solution then possibly even just looking at SSA defs
> > when POINTER_TYPE and the def is an ADDR_EXPR might work (in the
> > visit_* callbacks of the walk_stmt_load_store_addr_ops), no propagation
> > needed at all (basically just undo CSE virtually here for the simple
> > cases).
> 
> It couldn't be limited to just POINTER_TYPE, because it mostly is actually
> pointer-sized unsigned integer from IVOPTs, but yes, even without full
> propagation I think all the testcases I've mentioned could be solved by just
> doing the short walks in PHI arguments or other SSA_NAME uses (only PR111422
> needs the latter).
> For this PR, we'd need to visit for ivtmp.40_3 uses in PHI args the def-stmt:
>   ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6 +
> 8B];
> for PR90348 ivtmp.32_28's def-stmt:
>   ivtmp.32_28 = (unsigned long) ∈
> for PR110115 ivtmp.27_2's def-stmt:
>   ivtmp.27_2 = (unsigned long) &h;
> fpr PR111422 _44's def-stmt:
>   _44 = &g + _43;
> So, if you think it is ok to use just a small hack rather than full 
> propagation
> (which could even handle const/pure calls perhaps if they return pointer or
> pointer-sized integer), I can implement that too.  Even the full propagation
> wouldn't handle everything of course, but could handle more than the small 
> hack
> (which would need to be limited to just say 4 def-stmts and wouldn't try to
> look through PHIs).

I think we don't expect arbitrary complex obfuscation.  We do have
RPO order computed so propagation cost would be mostly a bunch of
bitmaps (possibly one per SSA name), but with PHIs we'd need to
iterate.  I wonder if this could be done along the propagation
add_scope_conflicts does itself - can we do this within
add_scope_conflicts_1 when for_conflict == false?  I'd think so
(though whether a change occured is more difficult to track?).

What would you then consider a mention that's not explicit?
Any that we couldn't further propagate to its uses?  Thus also

  mem = _1;

with _1 having the address of some local?

[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Priority|P3  |P1

[Bug c/111811] [14 Regression] ICE with vector float bitfield after error

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/113400] New: Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 113400
   Summary: Internal compiler error:  Segmentation fault,
regression in 13.2.1 compared to 13.2.0
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

We are getting this ICE since upgrading to 13.2.1.

$ g++ --version
g++ (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)

The attached files were produced with these command lines:

g++ -I/home/karen/work/build2/bpkg -I/home/karen/work/build2/bpkg
-D_GLIBCXX_ASSERTIONS -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_SHARED
-I/home/karen/work/build2/libbutl -I/home/karen/work/build2/libbutl
-DLIBBUTL_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BASH_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_IN_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BIN_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_C_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CC_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_CLI_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CXX_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_VERSION_SHARED -I/home/karen/work/build2/libbpkg
-I/home/karen/work/build2/libbpkg -DLIBBPKG_SHARED
-I/home/karen/work/odb/libodb -I/home/karen/work/odb/libodb -DLIBODB_BUILD2
-DLIBODB_SHARED -I/home/karen/work/odb/libodb-sqlite
-I/home/karen/work/odb/libodb-sqlite -DLIBODB_SQLITE_BUILD2
-DLIBODB_SQLITE_SHARED
-I/home/karen/work/build2/packaging/sqlite/sqlite/libsqlite3/libsqlite3 -W
-Wall -Wextra -Wno-unknown-pragmas -g -ggdb -fno-inline -fsanitize=address
-fsanitize=undefined -fno-omit-frame-pointer -fstack-protector-all
-Wno-maybe-uninitialized -Wno-free-nonheap-object -Wno-stringop-overread
-Wno-dangling-reference -Wno-unknown-pragmas -std=c++23 -finput-charset=UTF-8
-x c++ -MQ ^ -MD -E -fdirectives-only -MF
/home/karen/work/build2/bpkg/bpkg/manifest-utility.o.t -o
/home/karen/work/build2/bpkg/bpkg/manifest-utility.o.ii
/home/karen/work/build2/bpkg/bpkg/manifest-utility.cxx

g++ -I/home/karen/work/build2/bpkg -I/home/karen/work/build2/bpkg
-D_GLIBCXX_ASSERTIONS -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_SHARED
-I/home/karen/work/build2/libbutl -I/home/karen/work/build2/libbutl
-DLIBBUTL_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BASH_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_IN_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BIN_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_C_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CC_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_CLI_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CXX_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_VERSION_SHARED -I/home/karen/work/build2/libbpkg
-I/home/karen/work/build2/libbpkg -DLIBBPKG_SHARED
-I/home/karen/work/odb/libodb -I/home/karen/work/odb/libodb -DLIBODB_BUILD2
-DLIBODB_SHARED -I/home/karen/work/odb/libodb-sqlite
-I/home/karen/work/odb/libodb-sqlite -DLIBODB_SQLITE_BUILD2
-DLIBODB_SQLITE_SHARED
-I/home/karen/work/build2/packaging/sqlite/sqlite/libsqlite3/libsqlite3 -W
-Wall -Wextra -Wno-unknown-pragmas -g -ggdb -fno-inline -fsanitize=address
-fsanitize=undefined -fno-omit-frame-pointer -fstack-protector-all
-Wno-maybe-uninitialized -Wno-free-nonheap-object -Wno-stringop-overread
-Wno-dangling-reference -Wno-unknown-pragmas -std=c++23 -fdiagnostics-color
-finput-charset=UTF-8 -o bpkg/manifest-utility.o -c -x c++ -fpreprocessed
-fdirectives-only /home/karen/work/build2/bpkg/bpkg/manifest-utility.o.ii

In function ‘std::vector bpkg::package_b_info(const
common_options&, const dir_paths&, butl::b_info_flags)’:
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccemvm8K.out file, please attach this to
your bugreport.

[Bug c++/113400] Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 57083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57083&action=edit
Reproducer

[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/113400] Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
Created attachment 57084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57084&action=edit
Reproducer

[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.  I guess.

[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 112580 Summary: [14 Regression]:  g++.dg/modules/xtreme-header-4_b.C et al; 
ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580

   What|Removed |Added

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

[Bug libstdc++/113398] no longer usable with -ffreestanding

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
We could consider a macro that disables the  error,
which would mean "give me the full library even if it might not work, give it
to me straight, like a pear cider that's made from 100% pears".

For std::string we're still missing std::allocator (in gcc-13 but not trunk),
several of the __throw_xxx functions, and the strtol, strtof etc. functions
used for std::stoi, std::stof etc.

[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'

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

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

--- Comment #5 from Francois-Xavier Coudert  ---
Not entirely, xtreme-header_b.C is still failing, as indicated above. See
recently:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

Also, there are more failures with -m32 on the same x86_64-linux:

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-4_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-6_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

[Bug c++/113400] Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
 = 0;, std::vector::~vector ((struct vector *) );
$3 = void


looks like a duplicate of PR113347

[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-15

--- Comment #1 from Richard Biener  ---
confirmed

[Bug target/113356] [14 Regression][aarch64] ICE in try_fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:2203 since r14-6947-g4b67ec7ff5b1aa

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/643011.html

--- Comment #4 from Alex Coplan  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643011.html

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 57085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57085&action=edit
gcc14-pr113372.patch

The non-propagation workaround which seems to fix^H^H^Hworkaround all those 4
issues (PR90348 testcase actually doesn't FAIL anymore, but I've verified the
patch results in in and buf no longer being shared) can look like this.

[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

--- Comment #2 from Jakub Jelinek  ---
Bet it should be Optimization instead of Target.

[Bug other/113399] [14 Regression] -ffold-mem-offsets should not be a target option

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

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

--- Comment #3 from Jakub Jelinek  ---
And Common

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #15 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 57085 [details]
> gcc14-pr113372.patch
> 
> The non-propagation workaround which seems to fix^H^H^Hworkaround all those
> 4 issues (PR90348 testcase actually doesn't FAIL anymore, but I've verified
> the patch results in in and buf no longer being shared) can look like this.

+ || (INTEGRAL_TYPE_P (TREE_TYPE (use))
+ && TYPE_PRECISION (TREE_TYPE (use)) == POINTER_SIZE)))

ptrofftype_p (TREE_TYPE (use))

+{
+  gimple *g = SSA_NAME_DEF_STMT (use);
+  if (is_gimple_assign (g))
+   for (unsigned i = 1; i < gimple_num_ops (g); ++i)
+ {
+   tree op = gimple_op (g, i);
+   if (op && TREE_CODE (op) == ADDR_EXPR)

I think it should be enough to look at gimple_assing_rhs1, that works
for single non-invariant &a[i], for conversions and for offsetting of
an invariant address (pointer-plus).

I'd say OK with those changes.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #16 from Michael Matz  ---
A general remark: in principle I don't see problems with undoing a little CSE,
as proposed.  I.e. for each SSA name use, see if it (trivially, or
conservatively
or optimistically) refers to an address of a tracked DECL, and include those
in the dont-share set.

But I will remark that this then handles code that was invalid to start with
as if it were valid, and I'm not sure if this will change diagnostics outcome
in any way (it certainly will prevent the slot sharing and hence any
diagnostics
that are based on such sharing to happen, e.g. when dirtying memory at
lifetime-end).

What I mean is the classic anti-pattern in C:

   char * ptr;
   {
 char localarray[n];
 dosomething (localarray);
 ptr = localarray;
   }
   domore (ptr);

The proposed solution will make the reference to the SSA name of 'ptr',
even though it was invalid in the source, keep localarray[] to be conflicting
and hence unshared with any other surrounding storage.

Depending on how PHI nodes are handled this will also mean that an SSA name
can't ever be un-associated with a DECL anymore:

  char * ptr = someotherarray;
  if (cond1)
  {
char localarray[n];
ptr = localarray;
foo (ptr);
  }
  if (cond2) { char localarray[n]; ptr = localarray; foo(ptr); }
  if (!cond1 && !cond2)
foo (ptr);

Here we will have a PHI for ptr: 'ptr_3 = PHI'.  The question
is how the reference(s) to 'localarray' will be handled: does it lead to ptr_3
also referring to them or not.  I.e. usual question in PHI merging: optimistic
or pessimistic.

Note that the answer to the latter question might influence the whole
effectiveness of stack slot sharing.  IIRC the latter type of code was one
of the examples that explodes in stack usage without sharing (localarray[]
being instead local C++ objects; but I don't remember if references to them
could bleed out of scopes in the same way as above).

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> We will do it as a DR against all previous standards, as we do for most DRs.

That should have said "as we do for most issues", sorry. All the major impls
treat most library issues as DRs, applying the fixes to all affected standards
modes.

But as this particular issue changes operator<=> and is motivated by ranges,
I'm tempted to say it's only a DR against C++20, nothing older. If people want
it for older standards, they can contribute the patch to change the pre-C++20
operator!=, operator< etc. overloads.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Created attachment 57085 [details]
> > gcc14-pr113372.patch
> > 
> > The non-propagation workaround which seems to fix^H^H^Hworkaround all those
> > 4 issues (PR90348 testcase actually doesn't FAIL anymore, but I've verified
> > the patch results in in and buf no longer being shared) can look like this.
> 
> +   || (INTEGRAL_TYPE_P (TREE_TYPE (use))
> +   && TYPE_PRECISION (TREE_TYPE (use)) == POINTER_SIZE)))
> 
> ptrofftype_p (TREE_TYPE (use))

Aren't there targets where pointers are larger than sizetype?
I thought msp430, but that one uses __int20.

> I think it should be enough to look at gimple_assing_rhs1, that works
> for single non-invariant &a[i], for conversions and for offsetting of
> an invariant address (pointer-plus).

Is the invariant operand guaranteed to go first?  If it is pointer, guess
POINTER_PLUS_EXPR enforces that, and for sizetype addition guess an operand
can't be ADDR_EXPR, there would need to be a cast in a separate stmt.  So
perhaps ok.

As for Micha's fears, I can certainly try to dump statistics during
bootstrap/regtest on how many variables were shared and/or their cumulative
size without/with the patch and see if it has significant effects on real-world
code.

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Pilar Latiesa  ---

It seems that what is missing is a corresponding change in the macro definition
logic. It should have been changed to:

// Check the user-defined macro for warnings
#if defined(PSTL_USAGE_WARNINGS)
#define _PSTL_USAGE_WARNINGS
#endif

See
https://github.com/llvm/llvm-project/blob/5ccf19ded09f68bef43275c81c20b0e65f7c0b75/pstl/include/pstl/internal/pstl_config.h#L26

[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:86fac7ee1688bdec245a43f6d2ab49fb238892e4

commit r14-7247-g86fac7ee1688bdec245a43f6d2ab49fb238892e4
Author: Georg-Johann Lay 
Date:   Mon Jan 15 13:25:59 2024 +0100

AVR: target/107201: Make -nodevicelib work for all devices.

driver-avr.cc contains a spec that discriminates bwtween cores
and devices by means of a mmcu=avr* spec pattern.  This does not
work for new devices like AVR128* which also start with mmcu=avr
like all cores do.  The patch uses a new spec function in order to
tell apart cores from devices.

gcc/
PR target/107201
* config/avr/avr.h (EXTRA_SPEC_FUNCTIONS): Add no-devlib,
avr_no_devlib.
* config/avr/driver-avr.cc (avr_no_devlib): New function.
(avr_devicespecs_file): Use it to remove -nodevicelib from the
options for cores only.
* config/avr/avr-arch.h (avr_get_parch): New prototype.
* config/avr/avr-devices.cc (avr_get_parch): New function.

[Bug libgcc/113337] Uncaught rethrown exceptions don't invoke std::terminate if SEH-based unwinding is used

[matteo at mitalia dot net via Gcc-bugs]

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

--- Comment #1 from Matteo Italia  ---
Looking at this a bit deeper, I think that just putting a `return` in front of
`_Unwind_RaiseException (exc);` should be enough.

The bulk of the phase2 stuff that is done in unwind.inc for
`_Unwind_Resume_or_Rethrow`, i.e.

```
  gcc_assert (code == _URC_INSTALL_CONTEXT);

  uw_install_context (&this_context, &cur_context, frames);
```

is done directly in `_GCC_specific_handler`, and indeed if _that_ doesn't work
`_Unwind_ForcedUnwind_Phase2` can return only `_URC_END_OF_STACK` anyhow, which
would go to the `gcc_assert` codepath in unwind.inc.

[Bug libgcc/113337] Uncaught rethrown exceptions don't invoke std::terminate if SEH-based unwinding is used

[matteo at mitalia dot net via Gcc-bugs]

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

--- Comment #2 from Matteo Italia  ---
Created attachment 57086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57086&action=edit
Proposed patch (plain return in front of _Unwind_RaiseException)

[Bug target/113365] LONG DOUBLE: denormals: assigning a constant: factor 100 slow,

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #4 from newbie-02  ---
hello @Andrew Pinski,   

just if I'm allowed to add one more point / question:  

using the testing program, playing with optimization, I get  
the following results for binary64s ( doubles ):  

unoptimized:  
time: result:calculation:  
0.005571; 4.940656458412465442E-324; x2d = nextafter( 1E-323, 0.0 ) 
0.002029; 4.940656458412465442E-324; x2d = ( ( 1E-323 ) - 5E-324 ) 
0.005395; 1.482196937523739633E-323; x2d = nextafter( 1E-323, 1.0 ) 
0.002023; 1.482196937523739633E-323; x2d = ( ( 1E-323 ) + 5E-324 ) 
which points out that addition / subtraction are faster in denormals,  
or assignd at compile time despite x2d is defined volatile.  

optimized ( compiled with -O2 ): I mostly! get understandable results,  
( nextafter similar and ADD / SUB faster reg, compiler cheating?,  
but on some occasions ( ~10% of compile attempts ):  
time: result:calculation:  
0.009311; 4.940656458412465442E-324; x2d = nextafter( 1E-323, 0.0 ) 
0.000420; 4.940656458412465442E-324; x2d = ( ( 1E-323 ) - 5E-324 ) 
0.009668; 1.482196937523739633E-323; x2d = nextafter( 1E-323, 1.0 ) 
0.000423; 1.482196937523739633E-323; x2d = ( ( 1E-323 ) + 5E-324 ) 
which has ** ~doubled execution time for nextafters **.  

Is that something I should worry about? Somthing which could be improved?  
Either here by options or in gcc?

[Bug middle-end/113354] [14 Regression] : unable to find a register to spill on mips

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:76bc70387d936e3c929368c265ce71e8b239e7b7

commit r14-7248-g76bc70387d936e3c929368c265ce71e8b239e7b7
Author: Vladimir N. Makarov 
Date:   Mon Jan 15 10:19:39 2024 -0500

[PR113354][LRA]: Fixing LRA failure on building MIPS GCC

My recent patch for PR112918 triggered a hidden bug in LRA on MIPS.  A
pseudo is matched to a register constraint and assigned to a hard
registers at the first constraint sub-pass but later it is matched to
X constraint.  Keeping this pseudo in the register (MD0) prevents to
use the same register for another pseudo in the insn and this results
in LRA failure.  The patch fixes this by spilling the pseudo at the
constraint subpass when the chosen alternative constraint not require
hard register anymore.

gcc/ChangeLog:

PR middle-end/113354
* lra-constraints.cc (curr_insn_transform): Spill pseudo only used
in the insn if the corresponding operand does not require hard
register anymore.

[Bug tree-optimization/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r14-1143-g42d1612eb5c3b2ee327bc3336bfcbc43a0d0fc5b
but I'd say check_type_name_conflict expectations are just wrong, even when a
type has a TYPE_NAME which is a TYPE_DECL, it doesn't imply it has a DECL_NAME,
in this case the TYPE_DECL has been created just to make the gimplifier happy.