[Bug c/112449] Arithmetic operations can produce signaling NaNs

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

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

--- Comment #11 from Richard Biener  ---
(In reply to post+gcc from comment #10)
> The standard says
> 
> > This annex does not require the full support for signaling NaNs specified 
> > in IEC 60559. This
> annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs.
> Where specification of
> signaling NaNs is not provided, the behavior of signaling NaNs is
> implementation-defined (either
> treated as an IEC 60559 quiet NaN or treated as an IEC 60559 signaling NaN).

I don't see implement-c.texi saying anything about this.  Joseph, can you
improve documentation here?

> I have no idea how that allows a situation where the *output* of an
> operation becomes signaling -- that can't usually happen no matter whether
> the inputs are signaling or quiet.
> 
> But that seems to be the common interpretation.
> 
> Still, it seems important that `pow(1.0, 0.0/0.0)` returns `1.0` and not a
> NaN. That's what the `pow` docs say. So for this there must be a guarantee
> that `0.0/0.0` is a quiet NaN.

GCC will not create an sNaN out of nowhere.  But unless you enable
-fsignaling-nans it is unspecified whether and when an sNaN will become
a quiet NaN as GCC - as you observed - will happily elide x * 1.0 even
when 'x' might be a sNaN (basically with -fno-signaling-nans GCC assumes that
inputs are _never_ sNaN).

The -fsignaling-nans might also need clarification to make it more obvious
what omitting it means.

[Bug ada/112461] [14 regression] Simple return inside extended return loses updates to return object value

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112464] [14 Regression] ICE avx512 with -ftrapv since r14-5076

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
(In reply to Robin Dapp from comment #2)
> I tested
> 
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index a544bc9b059..257fd40793e 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -7084,7 +7084,7 @@ vectorize_fold_left_reduction (loop_vec_info
> loop_vinfo,
>  opmask, &vec_opmask);
>  }
>  
> -  gimple *sdef = scalar_dest_def_info->stmt;
> +  gimple *sdef = vect_orig_stmt (scalar_dest_def_info)->stmt;
> 
> overnight on x86 and aarch64.  This seems to help for the reduced testcase.
> 
> It appears as if we "look through" a statement pattern in
> vect_finish_replace_stmt but not before when we replace the newly created
> vector statement's lhs.  Then the lhs is the statement pattern's lhs while
> in vect_finish_replace_stmt we assert that it's from the statement the
> pattern replaced.

Hmm, that will only work if the orig stmt is the root of the pattern
sequence.  But otherwise it looks correct to me.

[Bug libstdc++/112467] [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112464] [14 Regression] ICE avx512 with -ftrapv since r14-5076

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

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

--- Comment #4 from Robin Dapp  ---
Is there another way to make it more robust?

Or does the existing

void
vect_finish_replace_stmt (vec_info *vinfo,
  stmt_vec_info stmt_info, gimple *vec_stmt)
{
  gimple *scalar_stmt = vect_orig_stmt (stmt_info)->stmt;

have the same problem?

[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Andrew Pinski from comment #2)
> new_stmt = build_call_internal (ifn, res_op);
> 
> static gcall *
> build_call_internal (internal_fn fn, gimple_match_op *res_op)
> {
>   if (direct_internal_fn_p (fn))
> {
>   tree_pair types = direct_internal_fn_types (fn, res_op->type,
>   res_op->ops);
>   if (!direct_internal_fn_supported_p (fn, types, OPTIMIZE_FOR_BOTH))
> return NULL; // here.
> }
> 
> 
> Causes copysign to return NULL here 
> 
> I suspect the pattern should be changed to:
> /* Transform fneg (fabs (X)) -> copysign (X, -1).  */
> (simplify
>  (negate (abs @0))
>  (if (direct_internal_fn_supported_p (IFN_COPYSIGN, type, OPTIMIZE_FOR_BOTH))
>   (IFN_COPYSIGN @0 { build_minus_one_cst (type); })))

But that's already implicitly done, so I fail to see how it makes a difference?
Or do you say it might make a difference for consumers which look at
the gimple_match_op () result (which has the toplevel not committed to
gimple *, and thus not "rejected" yet)?

I suppose we could change things to reject it earlier but then the idea
is of course that "unsupported" intermediate .COPYSIGN could be further
simplified, avoiding the need to actually output it.

> Notice the check against direct_internal_fn_supported_p here.
> 
> This is similar to the (trunc)copysign((extend)..) pattern.
> 
> /* Simplify (trunc)copysign ((extend)x, (extend)y) to copysignf (x, y),
>x,y is float value, similar for _Float16/double.  */
> (for copysigns (COPYSIGN_ALL)
>  (simplify
>   (convert (copysigns (convert@2 @0) (convert @1)))

[Bug tree-optimization/112469] [14 Regression] ICE: eliminate_stmt, at tree-ssa-sccvn.cc:6944

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
So we value-number

vect_prephitmp_11.23_50 = .COND_NEG (_55, vect__29.18_40, { -1, -1, -1, -1, -1,
-1, -1, -1 });

as

{ 4294967295, 4294967294, 4294967293, 4294967292, 4294967291, 4294967290,
4294967289, 4294967288 }

where the former is signed int V8SI and the latter unsigned int V8SI.  Happens
via

Value numbering stmt = vect_prephitmp_11.23_50 = .COND_NEG (_55,
vect__29.18_40, { -1, -1, -1, -1, -1, -1, -1, -1 });
Applying pattern match.pd:5031, generic-match-1.cc:9440
Match-and-simplified .COND_NEG (_55, vect__29.18_40, { -1, -1, -1, -1, -1, -1,
-1, -1 }) to { 4294967295, 4294967294, 4294967293, 4294967292, 4294967291,
4294967290, 4294967289, 4294967288 }

where _55 == { -1, -1, -1, -1, -1, -1, -1, -1 } and
vect__29.18_40 == { 1, 2, 3, 4, 5, 6, 7, 8 } and we have

  vector(8) unsigned int vect__29.18;

I think the .COND_NEG result has the wrong sign.  We fold this from a
VEC_COND_EXPR during vectorization:

Value numbering stmt = vect_prephitmp_11.23_50 = VEC_COND_EXPR ;
Matching expression match.pd:2187, gimple-match-4.cc:67
Applying pattern match.pd:5926, gimple-match-3.cc:3142
Setting value number of vect_prephitmp_11.23_50 to vect_prephitmp_11.23_50
(changed) 
Matching expression match.pd:2187, gimple-match-4.cc:67
Applying pattern match.pd:5926, gimple-match-3.cc:3142
Applying pattern match.pd:8968, gimple-match-3.cc:19689
gimple_simplified to _55 = vect_vec_iv_.17_38 != { 0, 0, 0, 0, 0, 0, 0, 0 };
vect_prephitmp_11.23_50 = .COND_NEG (_55, vect__29.18_40, { -1, -1, -1, -1, -1,
-1, -1, -1 });

which is

(for uncond_op (UNCOND_UNARY)
 cond_op (COND_UNARY)
..
 (simplify
  (vec_cond @0 @1 (view_convert? (uncond_op@3 @2)))
   (with { tree op_type = TREE_TYPE (@3); }
(if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
&& is_truth_type_for (op_type, TREE_TYPE (@0)))
 (cond_op (bit_not @0) @2 @1)

and because of the view_convert? lacks a view_convert in the result:

diff --git a/gcc/match.pd b/gcc/match.pd
index f559bfa4f2b..2b5e9554020 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8965,7 +8965,7 @@ and,
(with { tree op_type = TREE_TYPE (@3); }
 (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op),
op_type)
 && is_truth_type_for (op_type, TREE_TYPE (@0)))
- (cond_op (bit_not @0) @2 @1)
+ (cond_op (bit_not @0) (view_convert @2) @1)

 (for uncond_op (UNCOND_UNARY)
  cond_op (COND_LEN_UNARY)

fixes this.

[Bug tree-optimization/112469] [14 Regression] ICE: eliminate_stmt, at tree-ssa-sccvn.cc:6944

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

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

--- Comment #6 from JuzheZhong  ---
Thanks Richard.

I tried your patch. It does fix this issue.

But I wonder whether we should also adjust the following COND_LEN_UNARY too ?

Like this:

diff --git a/gcc/match.pd b/gcc/match.pd
index f559bfa4f2b..145ea925fa9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8965,7 +8965,7 @@ and,
(with { tree op_type = TREE_TYPE (@3); }
 (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op),
op_type)
 && is_truth_type_for (op_type, TREE_TYPE (@0)))
- (cond_op (bit_not @0) @2 @1)
+ (cond_op (bit_not @0) (view_convert @2) @1)

 (for uncond_op (UNCOND_UNARY)
  cond_op (COND_LEN_UNARY)
@@ -8980,7 +8980,7 @@ and,
(with { tree op_type = TREE_TYPE (@3); }
 (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op),
op_type)
 && is_truth_type_for (op_type, TREE_TYPE (@0)))
- (cond_op (bit_not @0) @2 @1 @4 @5)
+ (cond_op (bit_not @0) (view_convert @2) @1 @4 @5)

[Bug tree-optimization/112469] [14 Regression] ICE: eliminate_stmt, at tree-ssa-sccvn.cc:6944

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

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

--- Comment #7 from Richard Biener  ---
Yes, I'm testing a more complete patch right now.

[Bug tree-optimization/112464] [14 Regression] ICE avx512 with -ftrapv since r14-5076

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Robin Dapp from comment #4)
> Is there another way to make it more robust?
> 
> Or does the existing
> 
> void
> vect_finish_replace_stmt (vec_info *vinfo,
> stmt_vec_info stmt_info, gimple *vec_stmt)
> {
>   gimple *scalar_stmt = vect_orig_stmt (stmt_info)->stmt;
> 
> have the same problem?

Well, yeah, it also implicitly assumes that.  I couldn't come up with
the "correct" assert quickly, so I didn't suggest any.  That is, just
go with your patch.

[Bug c/112463] ternary operator / -Wsign-compare inconsistency

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #3 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #2)
> One problem with -Wsign-conversion is that it is not enabled with
> -Wextra/-Wall .

However, I don't understand why -Wsign-compare is enabled by -Wextra but not
-Wsign-conversion, while these are similar warnings.

Note that when compiling GNU MPFR, *both* give lots of false positives (which
could be avoided, at least for most of them, if PR38470 were fixed).

[Bug ada/112446] Switch -gnatyz included in -gnatyg

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-10

[Bug ada/112461] [14 regression] premature finalization with nested return inside extended one

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[14 regression] Simple  |[14 regression] premature
   |return inside extended  |finalization with nested
   |return loses updates to |return inside extended one
   |return object value |
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2023-11-10
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Yes, by commit 2e135bdb28d386b0cda2ee7e35338ad06136042d, but the issue was
preexisting if the return type is limited.  The fix is upcoming.

[Bug ada/112461] [14 regression] premature finalization with nested return inside extended one

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug target/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

--- Comment #9 from 김대영 <22s302h0659 at sonline20 dot sen.go.kr> ---
```
#include 
#define M_1  0xad5d6da  /* 1010110101011101011011011010 */
char g_1 = -1;
short g_2 = -1;

char v1 = -1;
short v2 = 1;

int main(){
char l_1 = -1;
short l_2 = -1;
printf("char g_1   = %d\n", g_1);
printf("char l_1   = %d\n", l_1);
printf("(char)M_1  = %d\n\n\n", (char)M_1);

printf("short g_2  = %d\n", g_2);
printf("short l_2  = %d\n", l_2);
printf("(short)M_1 = %d\n\n\n", (short)M_1);


printf("(char)-1 <= (short)1 = %s \n\n", (char)-1 <= (short)1 ? "True"
: "False");

printf("char v1= %d\n", v1);
printf("short  v2  = %d\n\n", v2);

printf("v1 <= v2 = %s \n", v1 <= v2 ? "True" : "False");


return 0;
}
```
I have been continuously investigating bugs recently. The above code proves
that it cannot reliably handle 'char' type as signed. Additionally, testing in
the s390x native environment with GCC versions 9, 11.4.0, and 12 consistently
revealed the same bug.

```
root@a92c2f395400:~# gcc -o test test.c -O0
root@a92c2f395400:~# ./test
char g_1   = 255
char l_1   = 255
(char)M_1  = 218


short g_2  = -1
short l_2  = -1
(short)M_1 = -10534


(char)-1 <= (short)1 = False

char v1= 255
short  v2  = 1

v1 <= v2 = False
root@a92c2f395400:~# gcc -o test test.c -O2
root@a92c2f395400:~# ./test
char g_1   = 255
char l_1   = 255
(char)M_1  = 218


short g_2  = -1
short l_2  = -1
(short)M_1 = -10534


(char)-1 <= (short)1 = False

char v1= 255
short  v2  = 1

v1 <= v2 = True
```

[Bug rtl-optimization/112474] New: MIPS: missed optimization for assigning HI reg to zero

[lis8215 at gmail dot com via Gcc-bugs]

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

Bug ID: 112474
   Summary: MIPS: missed optimization for assigning HI reg to zero
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lis8215 at gmail dot com
  Target Milestone: ---

Created attachment 56550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56550&action=edit
the patch

At the moment GCC emits move $0 to a GPR register and then move to HI (mthi)
from that register as part of DI/TI MADD operation.

It is feasible to avoid such copying when intermediate register isn't used
anymore and reword RTL to emit only `mthi $0`.

So the following output:
...
move $3, $0
mthi $3
; reg dead $3
...

Can be simply reworded as:
...
move $3, $0 ; << will be removed by DCE later
mthi $0
...

Silly patch, which doing such optimization, provided.

Thanks.

[Bug c/112449] Arithmetic operations can produce signaling NaNs

[post+gcc at ralfj dot de via Gcc-bugs]

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

--- Comment #12 from post+gcc at ralfj dot de ---
> GCC will not create an sNaN out of nowhere.

That's the part I was hoping for. :)  I just don't think it obviously follows
from any docs (the C standard or GCC docs).

[Bug rtl-optimization/112474] MIPS: missed optimization for assigning HI reg to zero

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Siarhei Volkau  ---
Minimal example for showcase the issue:

#include 

uint64_t mthi_example(uint32_t a, uint32_t b, uint32_t c, uint32_t d)
{
uint64_t ret;
ret = (uint64_t)a * b + (uint64_t)c * d + 1u;
return ret;
}

compile command:
  mipsel-*-gcc -O2 -mips32

[Bug target/112313] [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE, 'during RTL pass: vregs': 'error: unrecognizable insn'

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Fix written and committed by Andrew as r14-5316-g8da8b922576212

"The problem was a missed case in the vector reduction expand code."

See also https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635982.html


commit 8da8b9225762126ca41b12243d6531cd41a831b3
Author: Andrew Stubbs 
Date:   Fri Nov 10 09:43:21 2023 +

amdgcn: Fix vector min/max ICE

The DImode min/max instructions need a clobber that SImode does not, so
add the special case to the reduction expand code.

gcc/ChangeLog:

* config/gcn/gcn.cc (gcn_expand_reduc_scalar): Add clobber to
DImode
min/max instructions.

[Bug target/112313] [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE, 'during RTL pass: vregs': 'error: unrecognizable insn'

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

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

Andrew Stubbs  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ams at gcc dot gnu.org

--- Comment #2 from Andrew Stubbs  ---
This is now fixed.

[Bug tree-optimization/112469] [14 Regression] ICE: eliminate_stmt, at tree-ssa-sccvn.cc:6944

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

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

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

https://gcc.gnu.org/g:20aa06490ab57da7729a24bae7c4ec2f5918ec91

commit r14-5317-g20aa06490ab57da7729a24bae7c4ec2f5918ec91
Author: Richard Biener 
Date:   Fri Nov 10 09:56:01 2023 +0100

middle-end/112469 - fix missing converts in vec_cond_expr simplification

The following avoids type inconsistencies in .COND_op generated by
simplifications of VEC_COND_EXPRs.

PR middle-end/112469
* match.pd (cond ? op a : b -> .COND_op (cond, a, b)): Add
missing view_converts.

* gcc.dg/torture/pr112469.c: New testcase.

[Bug tree-optimization/112469] [14 Regression] ICE: eliminate_stmt, at tree-ssa-sccvn.cc:6944

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/112475] New: [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

Bug ID: 112475
   Summary: [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in
output_operand: invalid expression as operand
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

ICE with when compiled with
  g++ -fsanitize=undefined -fopenmp  -I ompvv
for the SOLLVE_VV, https://github.com/SOLLVE/sollve_vv/ , testcases:

  tests/5.2/unified_shared_mem/test_target_PureVirDestr.cpp
  tests/5.0/application_kernels/declare_target_base_and_derived_class.cpp

[The ICE is not new, I see it also with GCC 8,9,10,11,12,13.]


internal compiler error: output_operand: invalid expression as operand

0xf186f3 output_operand_lossage(char const*, ...)
../../repos/gcc-trunk-commit/gcc/final.cc:3190
0x16886db assemble_integer_with_op(char const*, rtx_def*)
../../repos/gcc-trunk-commit/gcc/varasm.cc:2845
0x16886db default_assemble_integer(rtx_def*, unsigned int, int)
../../repos/gcc-trunk-commit/gcc/varasm.cc:2861
0x168876d assemble_integer(rtx_def*, unsigned int, unsigned int, int)
../../repos/gcc-trunk-commit/gcc/varasm.cc:2877
0x1692c12 output_constant
../../repos/gcc-trunk-commit/gcc/varasm.cc:5302
0x1691902 output_constructor_regular_field
../../repos/gcc-trunk-commit/gcc/varasm.cc:5612
0x1691902 output_constructor
../../repos/gcc-trunk-commit/gcc/varasm.cc:5878
0x1693aa5 assemble_variable_contents
../../repos/gcc-trunk-commit/gcc/varasm.cc:2231

[Bug target/112308] [14 Regression] GCN: 'error: literal operands are not supported' for 'v_add_co_u32'

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Andrew Stubbs :

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

commit r14-5318-ge24b0fed9234716c146aaf6f8c1b39170e43a6f3
Author: Andrew Stubbs 
Date:   Fri Nov 10 11:13:55 2023 +

amdgcn: Fix v_add constraints (pr112308)

The instruction doesn't allow "B" constants for the vop3b encoding (used
when
the cc register isn't VCC), so fix the pattern and all the insns that might
get
split to it post-reload.

Also switch to the new constraint format for ease of adding new
alternatives.

gcc/ChangeLog:

PR target/112308
* config/gcn/gcn-valu.md (add3): Fix B
constraint
and switch to the new format.
(add3_dup): Likewise.
(add3_vcc): Likewise.
(add3_vcc_dup): Likewise.
(add3_vcc_zext_dup): Likewise.
(add3_vcc_zext_dup_exec): Likewise.
(add3_vcc_zext_dup2): Likewise.
(add3_vcc_zext_dup2_exec): Likewise.

[Bug target/112308] [14 Regression] GCN: 'error: literal operands are not supported' for 'v_add_co_u32'

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

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

Andrew Stubbs  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Stubbs  ---
This should be fixed now.

[Bug tree-optimization/110221] With AVX512 fully masking gfortran.dg/pr68146.f ICEs

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-10
 CC||rsandifo at gcc dot gnu.org
 Blocks||53947

--- Comment #2 from Richard Biener  ---
So in this case the stmt requiring the loop mask is only "indirectly" invariant
as the mask itself is inside of the loop but with invariant operands.

What works is avoiding to schedule internal def vectorized stmts outside of the
loop.  That will then leave possible invariant motion to the LIM pass, at
least when no loop masking/len is required.  So I'm testing the following.

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 3e5814c3a31..80e279d8f50 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -9081,6 +9081,16 @@ vect_schedule_slp_node (vec_info *vinfo,
   /* Emit other stmts after the children vectorized defs which is
 earliest possible.  */
   gimple *last_stmt = NULL;
+  if (auto loop_vinfo = dyn_cast  (vinfo))
+   if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
+   || LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo))
+ {
+   /* But avoid scheduling internal defs outside of the loop when
+  we might have only implicitly tracked loop mask/len defs.  */
+   gimple_stmt_iterator si
+ = gsi_after_labels (LOOP_VINFO_LOOP (loop_vinfo)->header);
+   last_stmt = *si;
+ }
   bool seen_vector_def = false;
   FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
if (SLP_TREE_DEF_TYPE (child) == vect_internal_def)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug middle-end/112475] [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

--- Comment #1 from Tobias Burnus  ---
Reduced testcase:

#pragma omp declare target
struct Surface { virtual double sag(); };
#pragma omp end declare target
Surface main_devPtr;
main() {
#pragma omp target
  main_devPtr.sag();
}


Printing in 'output_constant' (varasm.cc:5302) the value of 'exp' shows:

 _ZTI7Surface;
version:6>

[Bug rtl-optimization/112476] New: [14 Regression] unrecognizable insn with -O2 -march=la464 on loongarch64

[xen0n at gentoo dot org via Gcc-bugs]

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

Bug ID: 112476
   Summary: [14 Regression] unrecognizable insn with -O2
-march=la464 on loongarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xen0n at gentoo dot org
  Target Milestone: ---
Target: loongarch64-linux-gnu

Created attachment 56551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56551&action=edit
Minimized reproducer

The attached code minified from Skia, ICEs with "unrecognizable insn" when
compiled with SIMD apparently active and the backend wanting to do something
with it.

According to my preliminary debugging: the bug disappears when the extra layer
of wrapping function is removed, when the two "&a" arguments get changed, and
when the memcpy is rewritten to a simple pointer dereference.

[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction

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

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

--- Comment #15 from JuzheZhong  ---
Hi,Richard.
Confirmed Robin's patch doesn't help with this issue.

The root cause of this issue is failed to recognize it as possible
vectorization of conditional reduction which means is_cond_scalar_reduction
is FALSE.

I have this following patch which bootstrap on X86 and regtest passed
also passed on aarch64. This following patch can enhance if-conv
conditional reduction recognition.

diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index a8c915913ae..2bdd3710a65 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -1784,14 +1784,119 @@ is_cond_scalar_reduction (gimple *phi, gimple **reduc,
tree arg_0, tree arg_1,
   r_nop2 = strip_nop_cond_scalar_reduction (*has_nop, r_op2);

   /* Make R_OP1 to hold reduction variable.  */
+  gimple *nonphi_use_stmt = NULL;
   if (r_nop2 == PHI_RESULT (header_phi)
   && commutative_tree_code (reduction_op))
 {
   std::swap (r_op1, r_op2);
   std::swap (r_nop1, r_nop2);
 }
-  else if (r_nop1 != PHI_RESULT (header_phi))
-return false;
+  else if (r_nop1 == PHI_RESULT (header_phi))
+;
+  else
+{
+  /* Analyze the statement chain of STMT so that we could teach generate
+better if-converison code sequence.  We are trying to catch this
+following situation:
+
+  loop-header:
+  reduc_1 = PHI <..., reduc_2>
+  ...
+  if (...)
+  tmp1 = reduc_1 + rhs1;
+  tmp2 = tmp1 + rhs2;
+  tmp3 = tmp2 + rhs3;
+  ...
+  reduc_3 = tmpN-1 + rhsN-1;
+
+  reduc_2 = PHI 
+
+  and convert to
+
+  reduc_2 = PHI <0, reduc_1>
+  tmp1 = rhs1;
+  tmp2 = tmp1 + rhs2;
+  tmp3 = tmp2 + rhs3;
+  ...
+  reduc_3 = tmpN-1 + rhsN-1;
+  ifcvt = cond_expr ? reduc_3 : 0;
+  reduc_1 = reduc_1 +/- ifcvt;  */
+  if (num_imm_uses (PHI_RESULT (header_phi)) != 2)
+   return false;
+  if (!ANY_INTEGRAL_TYPE_P (TREE_TYPE (PHI_RESULT (phi)))
+ && !(FLOAT_TYPE_P (TREE_TYPE (PHI_RESULT (phi)))
+  && !HONOR_SIGNED_ZEROS (TREE_TYPE (PHI_RESULT (phi)))
+  && !HONOR_SIGN_DEPENDENT_ROUNDING (TREE_TYPE (PHI_RESULT (phi)))
+  && !HONOR_NANS (TREE_TYPE (PHI_RESULT (phi)
+   return false;
+  gimple *prev_use_stmt, *curr_use_stmt;
+  use_operand_p use;
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, PHI_RESULT (header_phi))
+   {
+ prev_use_stmt = curr_use_stmt = USE_STMT (use_p);
+ if (is_gimple_assign (curr_use_stmt))
+   {
+ if (TREE_CODE (gimple_assign_lhs (curr_use_stmt)) != SSA_NAME)
+   return false;
+ if (*has_nop)
+   {
+ if (!CONVERT_EXPR_CODE_P (
+   gimple_assign_rhs_code (curr_use_stmt)))
+   return false;
+   }
+ else
+   {
+ if (gimple_assign_rhs_code (curr_use_stmt) != reduction_op)
+   return false;
+   }
+
+ bool visited_p = false;
+ nonphi_use_stmt = curr_use_stmt;
+ while (!visited_p)
+   {
+ if (!single_imm_use (gimple_assign_lhs (prev_use_stmt), &use,
+  &curr_use_stmt)
+ || gimple_bb (curr_use_stmt) != gimple_bb (stmt)
+ || !is_gimple_assign (curr_use_stmt)
+ || TREE_CODE (gimple_assign_lhs (curr_use_stmt))
+  != SSA_NAME
+ || gimple_assign_rhs_code (curr_use_stmt) !=
reduction_op)
+   return false;
+ if (curr_use_stmt == stmt)
+   {
+ if (*has_nop)
+   {
+ if (!single_imm_use (gimple_assign_lhs (
+nonphi_use_stmt),
+  &use, &curr_use_stmt))
+   return false;
+ r_op1 = gimple_assign_lhs (nonphi_use_stmt);
+ r_nop1 = PHI_RESULT (header_phi);
+ nonphi_use_stmt = curr_use_stmt;
+   }
+ else
+   r_op1 = PHI_RESULT (header_phi);
+
+ if (*has_nop)
+   {
+ if (!single_imm_use (gimple_assign_lhs (stmt), &use,
+  &curr_use_stmt))
+   return false;
+ r_op2 = gimple_assign_lhs (stmt);
+ r_nop2 = gimple_assign_lhs (curr_use_stmt);
+   }
+ else
+   r_op2 = gimple_assign_lhs (stmt);
+ visited_p = true;
+   }
+   

[Bug libstdc++/112473] integer_sequence accepts non-integer types

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

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

--- Comment #2 from Jonathan Wakely  ---
Ah it changed in C++20, previously it said "T shall be an integral type" so was
just UB.

[Bug libstdc++/112473] integer_sequence accepts non-integer types

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

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

--- Comment #3 from Jonathan Wakely  ---
Although you couldn't use std::pair as a NTTP until C++20 anyway.

[Bug tree-optimization/112430] [14 Regression] ICE: verify_ssa failed, missing definition since r14-1837-g43a3252c42af12

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction

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

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

--- Comment #16 from Richard Biener  ---
it's not exactly clear what the transform is you propose.  it looks like a
re-association but SSA names do not match up but the transform only replaces
a single op with 0!?

[Bug c++/112477] New: Assignment of value-initialized iterators differs from value-initialization

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 112477
   Summary: Assignment of value-initialized iterators differs from
value-initialization
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

In debug mode there seems to be a difference between a value-initialized
iterator, and an iterator that gets assigned from a value-initialized iterator.

Testcase: https://gcc.godbolt.org/z/hW7d7Pao3

#define _GLIBCXX_DEBUG
#include 

int main() {
using M = std::map;
using I = M::iterator;

M map{ {1, 1}, {2, 2} };

I it1 = map.begin();
it1 = I{};

I it2{};
(void)(it1 == it2); 
}

Results in 

  Error: attempt to compare a singular iterator to a 
  singular (value-initialized) iterator.


It's not entirely clear to me why this shouldn't "just work™", although this is
probably threading the needle; assignment *from* a singular iterator isn't
really discussed in https://eel.is/c++draft/iterator.requirements.general#7 nor
in https://eel.is/c++draft/forward.iterators#2 . 

(One may argue that this last sentence was added by N3644, when iterators still
required copiability, so copying a value-constructed iterator should have value
semantics and the result be indistinguishable from value-initializing...)

[Bug tree-optimization/110221] With AVX512 fully masking gfortran.dg/pr68146.f ICEs

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

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

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

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

commit r14-5320-ge5f1956498251a4973d52c8aad3faf34d0443169
Author: Richard Biener 
Date:   Fri Nov 10 12:39:11 2023 +0100

tree-optimization/110221 - SLP and loop mask/len

The following fixes the issue that when SLP stmts are internal defs
but appear invariant because they end up only using invariant defs
then they get scheduled outside of the loop.  This nice optimization
breaks down when loop masks or lens are applied since those are not
explicitly tracked as dependences.  The following makes sure to never
schedule internal defs outside of the vectorized loop when the
loop uses masks/lens.

PR tree-optimization/110221
* tree-vect-slp.cc (vect_schedule_slp_node): When loop
masking / len is applied make sure to not schedule
intenal defs outside of the loop.

* gfortran.dg/pr110221.f: New testcase.

[Bug tree-optimization/110221] With AVX512 fully masking gfortran.dg/pr68146.f ICEs

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

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

Bug 110221 Summary: With AVX512 fully masking gfortran.dg/pr68146.f ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110221

   What|Removed |Added

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

[Bug rtl-optimization/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
   Keywords||ice-on-valid-code
Summary|[14 Regression] |Unrecognizable insn with
   |unrecognizable insn with|-O2 -march=la464 on
   |-O2 -march=la464 on |loongarch64
   |loongarch64 |

--- Comment #1 from Xi Ruoyao  ---
It's not a regression because GCC 13 does not support LSX.

[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction

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

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

--- Comment #17 from JuzheZhong  ---
Sorry for confusing and not enough information.

I am trying to transform:

+  reduc_1 = PHI <..., reduc_2>
+  ...
+  if (...)
+  tmp1 = reduc_1 + rhs1;
+  tmp2 = tmp1 + rhs2;
+  tmp3 = tmp2 + rhs3;
+  ...
+  reduc_3 = tmpN-1 + rhsN-1;
+
+  reduc_2 = PHI 

First transform the first statement:

tmp1 = reduc_1 + rhs1; into  tmp1 = rhs1 + 0;

Then it will become bogus data move assignment: tmp1 = rhs1.
The later PASS will eliminate it.

Then, transform the reduction PHI: 

reduc_1 = PHI <..., reduc_2>

into if-convert statement:

reduc_1 = PHI <_ifc__35(8), 0(18)>

Thid, transform 

+  reduc_3 = tmpN-1 + rhsN-1;
+
+  reduc_2 = PHI 

into :

reduc_3 = tmpN-1 + rhsN-1;
_ifc__35 = .COND_ADD (condition, reduc_1, reduc_3, reduc_1);


So finally:

result_1 = PHI <_ifc__35(8), 0(18)>
...
tmp1 = rhs1;
tmp2 = tmp1 + rhs2;
tmp3 = tmp2 + rhs3;
...
reduc_3 = tmpN-1 + rhsN-1;
_ifc__35 = .COND_ADD (condition, reduc_1, reduc_3, reduc_1);

[Bug middle-end/112475] [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

--- Comment #2 from Jakub Jelinek  ---
Slightly further cleaned up:

#pragma omp declare target
struct S { virtual double foo (); };
#pragma omp end declare target
S s;

int
main ()
{
#pragma omp target
  s.foo ();
}

The problem is that ubsan_expand_vptr_ifn assumes the 4th argument to
.UBSAN_VPTR is is_gimple_min_invariant which can be put into static variable,
but the
data mapping violates this, turns the original &_ZTI1S into mapping of _ZTI1S
variable
and so the argument no longer is constant.
Now, on the ubsan_expand_vptr_ifn side we could certainly work around that by
not using a global const variable in that case, but automatic variable into
which we'd fill all the details at runtime, at the expense of ubsan not being
able to diagnose problems just the first time they are encountered, but all the
time (ubsan stores there after reporting a problem small change which makes it
ignore subsequent errors on the same spot) and slower runtime performance.
But the more important question is what we actually want to do with the _ZTI*,
_ZTS* and _ZTV* vars, if we want to map them, or pretend they are declare
target, or something else.
Consider also
#include 

__attribute__((noipa)) void
bar (const std::type_info &x)
{
}

void
foo ()
{
  bar (typeid (long));
}

int
main ()
{
#pragma omp target
  bar (typeid (int));
}
etc.
So, before working around this in ubsan, I think it would be good to discuss
what we want.  E.g. the _ZTI/_ZTS/_ZTV var references in declare target
functions, target regions and declare target variable initializers could be
auto-discovered during the auto declare target function discovery and marked,
...
With _ZTI/_ZTS it is easier, with _ZTV which contains also the virtual method
pointers
the question is if we mark all methods declare target, or fill in NULLs or what
else we do, I admit I haven't paid much attention what the latest OpenMP
standard currently requires for virtual method calls.

[Bug tree-optimization/112464] [14 Regression] ICE avx512 with -ftrapv since r14-5076

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

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

commit r14-5322-gd7b971cf61ae0091dbc777c9aa056e6f1293da2f
Author: Robin Dapp 
Date:   Fri Nov 10 08:56:18 2023 +0100

vect: Look through pattern stmt in fold_left_reduction.

It appears as if we "look through" a statement pattern in
vect_finish_replace_stmt but not before when we replace the newly
created vector statement's lhs.  Then the lhs is the statement pattern's
lhs while in vect_finish_replace_stmt we assert that it's from the
statement the pattern replaced.

This patch uses vect_orig_stmt on the scalar destination's definition so
the replaced statement is used everywhere.

gcc/ChangeLog:

PR tree-optimization/112464

* tree-vect-loop.cc (vectorize_fold_left_reduction): Use
vect_orig_stmt on scalar_dest_def_info.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112464.c: New test.

[Bug middle-end/111253] [11/12/13 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8036-gf1e717bd8b043e07e74accff3235d04e6eb719cc
Author: Richard Biener 
Date:   Thu Aug 31 13:53:21 2023 +0200

middle-end/111253 - partly revert r11-6508-gabb1b6058c09a7

The following keeps dumping SSA def stmt RHS during diagnostic
reporting only for gimple_assign_single_p defs which means
memory loads.  This avoids diagnostics containing PHI nodes
like

  warning: 'realloc' called on pointer '*_42 = PHI .t_mem_caches' with nonzero offset 40

instead getting back the previous behavior:

  warning: 'realloc' called on pointer '*.t_mem_caches' with
nonzero offset 40

PR middle-end/111253
gcc/c-family/
* c-pretty-print.cc (c_pretty_printer::primary_expression):
Only dump gimple_assign_single_p SSA def RHS.

gcc/testsuite/
* gcc.dg/Wfree-nonheap-object-7.c: New testcase.

(cherry picked from commit e3ece7684b02c47d2b259899cf8009d6bdcccaf3)

[Bug tree-optimization/111489] [12/13 Regression] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:06ee3438a4fcf98031fccda8ea8ff592a41cf218

commit r13-8039-g06ee3438a4fcf98031fccda8ea8ff592a41cf218
Author: Richard Biener 
Date:   Wed Sep 20 08:40:34 2023 +0200

tree-optimization/111489 - turn uninit limits to params

The following turns MAX_NUM_CHAINS and MAX_CHAIN_LEN to params which
allows to experiment with raising them.  For the testcase in PR111489
raising MAX_CHAIN_LEN from 5 to 8 avoids the bogus diagnostics
at -O2, at -O3 we need a MAX_CHAIN_LEN of 6.

PR tree-optimization/111489
* doc/invoke.texi (--param uninit-max-chain-len): Document.
(--param uninit-max-num-chains): Likewise.
* params.opt (-param=uninit-max-chain-len=): New.
(-param=uninit-max-num-chains=): Likewise.
* gimple-predicate-analysis.cc (MAX_NUM_CHAINS): Define to
param_uninit_max_num_chains.
(MAX_CHAIN_LEN): Define to param_uninit_max_chain_len.
(uninit_analysis::init_use_preds): Avoid VLA.
(uninit_analysis::init_from_phi_def): Likewise.
(compute_control_dep_chain): Avoid using MAX_CHAIN_LEN in
template parameter.

(cherry picked from commit b8a2a12464d25c45a51c14a025e8e2d3ca8ebeb0)

[Bug tree-optimization/111397] [12/13 Regression] Spurious warning "'({anonymous})' is used uninitialized" when calling a __returns_twice__ function (-Wuninitialized -O2)

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:049ec9b981d1f4f97736061d5cf7d0ae990b57d7

commit r13-8037-g049ec9b981d1f4f97736061d5cf7d0ae990b57d7
Author: Richard Biener 
Date:   Wed Sep 13 09:28:34 2023 +0200

tree-optimization/111397 - missed copy propagation involving abnormal dest

The following extends the previous enhancement to copy propagation
involving abnormals.  We can easily replace abnormal uses by not
abnormal uses and only need to preserve the abnormals in PHI arguments
flowing in from abnormal edges.  This changes the may_propagate_copy
argument indicating we are not propagating into a PHI node to indicate
whether we know we are not propagating into a PHI argument from an
abnormal PHI instead.

PR tree-optimization/111397
* tree-ssa-propagate.cc (may_propagate_copy): Change optional
argument to specify whether the PHI destination doesn't flow in
from an abnormal PHI.
(propagate_value): Adjust.
* tree-ssa-forwprop.cc (pass_forwprop::execute): Indicate abnormal
PHI dest.
* tree-ssa-sccvn.cc (eliminate_dom_walker::before_dom_children):
Likewise.
(process_bb): Likewise.

* gcc.dg/uninit-pr111397.c: New testcase.

(cherry picked from commit 92ea12ea99fce546772a40b7bbc2ea850db9b1be)

[Bug tree-optimization/111489] [12/13 Regression] Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8040-g5ee6e01fba873580f0ee6c88a3f733e79af2e8a3
Author: Richard Biener 
Date:   Wed Sep 20 08:44:43 2023 +0200

tree-optimization/111489 - raise --param uninit-max-chain-len to 8

This raises --param uninit-max-chain-len to avoid a bogus diagnostic
for the large testcase in PR111489.

PR tree-optimization/111489
* params.opt (-param uninit-max-chain-len=): Raise default to 8.

* gcc.dg/uninit-pr111489.c: New testcase.

(cherry picked from commit daf175e8170c18f59cc42c916005698437446272)

[Bug tree-optimization/111614] [11/12/13 Regression] ICE at -O2: verify_gimple failed since r14-2282-gf703d2fd3f0

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8042-g8e8599fc8079cdc2a9ef934c765613e2f0a4cdf9
Author: Richard Biener 
Date:   Thu Sep 28 09:41:30 2023 +0200

tree-optimization/111614 - missing convert in
undistribute_bitref_for_vector

The following adjusts a flawed guard for converting the first vector
of the sum we create in undistribute_bitref_for_vector.

PR tree-optimization/111614
* tree-ssa-reassoc.cc (undistribute_bitref_for_vector): Properly
convert the first vector when required.

* gcc.dg/torture/pr111614.c: New testcase.

(cherry picked from commit 88d79b9b03eccf39921d13c2cbd1acc50aeda126)

[Bug tree-optimization/111583] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8041-gb28be88c311f1bc4c62309906177ab3d97800deb
Author: Richard Biener 
Date:   Fri Sep 29 11:08:18 2023 +0200

tree-optimization/111583 - loop distribution issue

The following conservatively fixes loop distribution to only
recognize memset/memcpy and friends when at least one element
is going to be processed.  This avoids having an unconditional
builtin call in the IL that might imply the source and destination
pointers are non-NULL when originally pointers were not always
dereferenced.

With -Os loop header copying is less likely to ensure this.

PR tree-optimization/111583
* tree-loop-distribution.cc (find_single_drs): Ensure the
load/store are always executed.

* gcc.dg/tree-ssa/pr111583-1.c: New testcase.
* gcc.dg/tree-ssa/pr111583-2.c: Likewise.

(cherry picked from commit 962ca7149d652e4077a2259886e5cd2ea3cea0ab)

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

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8044-gffb0615cf1aa628ca8aa10bda31fe1bc554eccf3
Author: Richard Biener 
Date:   Mon Oct 16 12:50:46 2023 +0200

middle-end/111818 - failed DECL_NOT_GIMPLE_REG_P setting of volatile

The following addresses a missed DECL_NOT_GIMPLE_REG_P setting of
a volatile declared parameter which causes inlining to substitute
a constant parameter into a context where its address is required.

The main issue is in update_address_taken which clears
DECL_NOT_GIMPLE_REG_P from the parameter but fails to rewrite it
because is_gimple_reg returns false for volatiles.  The following
changes maybe_optimize_var to make the 1:1 correspondence between
clearing DECL_NOT_GIMPLE_REG_P of a register typed decl and
actually rewriting it to SSA.

PR middle-end/111818
* tree-ssa.cc (maybe_optimize_var): When clearing
DECL_NOT_GIMPLE_REG_P always rewrite into SSA.

* gcc.dg/torture/pr111818.c: New testcase.

(cherry picked from commit ce55521bcd149fdc431f1d78e706b66d470210ae)

[Bug tree-optimization/111764] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8043-gdb010f96743a4f289975a0432209c38ec34635e9
Author: Richard Biener 
Date:   Thu Oct 12 09:09:46 2023 +0200

tree-optimization/111764 - wrong reduction vectorization

The following removes a misguided attempt to allow x + x in a reduction
path, also allowing x * x which isn't valid.  x + x actually never
arrives this way but instead is canonicalized to 2 * x.  This makes
reduction path handling consistent with how we handle the single-stmt
reduction case.

PR tree-optimization/111764
* tree-vect-loop.cc (check_reduction_path): Remove the attempt
to allow x + x via special-casing of assigns.

* gcc.dg/vect/pr111764.c: New testcase.

(cherry picked from commit 05f98310b54da95e468d799f4a910174320cccbb)

[Bug tree-optimization/111445] [12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-1077-g57bf3751511

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8038-gbd7800a3a73fa07b4688c75edcaaaf923802f020
Author: Richard Biener 
Date:   Fri Oct 20 15:08:49 2023 +0200

tree-optimization/111445 - simple_iv simplification fault

The following fixes a missed check in the simple_iv attempt
to simplify (signed T)((unsigned T) base + step) where it
allows a truncating inner conversion leading to wrong code.

PR tree-optimization/111445
* tree-scalar-evolution.cc (simple_iv_with_niters):
Add missing check for a sign-conversion.

* gcc.dg/torture/pr111445.c: New testcase.

(cherry picked from commit 9692309ed6b625f0fb358c0e230404b5603f69a6)

[Bug tree-optimization/111917] [11/12/13 Regression] ICE in as_a, at is-a.h:255 since GCC-7

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:28d9e033a8e95c024e27cb495db610aac37a0f88

commit r13-8045-g28d9e033a8e95c024e27cb495db610aac37a0f88
Author: Richard Biener 
Date:   Mon Oct 23 11:25:17 2023 +0200

tree-optimization/111917 - bougs IL after guard hoisting

The unswitching code to hoist guards inserts conditions in wrong
places.  The following fixes this, simplifying code.

PR tree-optimization/111917
* tree-ssa-loop-unswitch.cc (hoist_guard): Always insert
new conditional after last stmt.

* gcc.dg/torture/pr111917.c: New testcase.

(cherry picked from commit d96bd4aade170fcd86f5f09b68b770dde798e631)

[Bug tree-optimization/111583] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||13.2.1
 Status|ASSIGNED|RESOLVED

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

[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Should be fixed now.

[Bug target/112438] RISC-V: Wrong auto-vectorization on induction variable of RVV

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-5326-gfb906061e10662280f602886c3659ac1c7522a37
Author: Juzhe-Zhong 
Date:   Fri Nov 10 20:20:11 2023 +0800

Middle-end: Fix bug of induction variable vectorization for RVV

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

1. Since SELECT_VL result is not necessary always VF in non-final
iteration.

Current GIMPLE IR is wrong:

...
_35 = .SELECT_VL (ivtmp_33, VF);
_21 = vect_vec_iv_.8_22 + { VF, ... };

E.g. Consider the total iterations N = 6, the VF = 4.
Since SELECT_VL output is defined as not always to be VF in non-final
iteration
which needs to depend on hardware implementation.

Suppose we have a RVV CPU core with vsetvl doing even distribution workload
optimization.
It may process 3 elements at the 1st iteration and 3 elements at the last
iteration.
Then the induction variable here: _21 = vect_vec_iv_.8_22 + { POLY_INT_CST
[4, 4], ... };
is wrong which is adding VF, which is 4, actually, we didn't process 4
elements.

It should be adding 3 elements which is the result of SELECT_VL.
So, here the correct IR should be:

  _36 = .SELECT_VL (ivtmp_34, VF);
  _22 = (int) _36;
  vect_cst__21 = [vec_duplicate_expr] _22;

2. This issue only happens on non-SLP vectorization single rgroup since:

 if (LOOP_VINFO_USING_DECREMENTING_IV_P (loop_vinfo))
{
  tree iv_type = LOOP_VINFO_RGROUP_IV_TYPE (loop_vinfo);
  if (direct_internal_fn_supported_p (IFN_SELECT_VL, iv_type,
  OPTIMIZE_FOR_SPEED)
  && LOOP_VINFO_LENS (loop_vinfo).length () == 1
  && LOOP_VINFO_LENS (loop_vinfo)[0].factor == 1 && !slp
  && (!LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
  || !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant ()))
LOOP_VINFO_USING_SELECT_VL_P (loop_vinfo) = true;
}

3. This issue doesn't appears on nested loop no matter
LOOP_VINFO_USING_SELECT_VL_P is true or false.

Since:

  # vect_vec_iv_.6_5 = PHI <_19(3), { 0, ... }(5)>
  # vect_diff_15.7_20 = PHI 
  _19 = vect_vec_iv_.6_5 + { 1, ... };
  vect_diff_9.8_22 = .COND_LEN_ADD ({ -1, ... }, vect_vec_iv_.6_5,
vect_diff_15.7_20, vect_diff_15.7_20, _28, 0);
  ivtmp_1 = ivtmp_4 + 4294967295;
  
   [local count: 6549826]:
  # vect_diff_18.5_11 = PHI 
  # ivtmp_26 = PHI 
  _28 = .SELECT_VL (ivtmp_26, POLY_INT_CST [4, 4]);
  goto ; [100.00%]

Note the induction variable IR: _21 = vect_vec_iv_.8_22 + { POLY_INT_CST
[4, 4], ... }; update induction variable
independent on VF (or don't care about how many elements are processed in
the iteration).

The update is loop invariant. So it won't be the problem even if
LOOP_VINFO_USING_SELECT_VL_P is true.

Testing passed, Ok for trunk ?

PR tree-optimization/112438

gcc/ChangeLog:

* tree-vect-loop.cc (vectorizable_induction): Bugfix when
LOOP_VINFO_USING_SELECT_VL_P.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112438.c: New test.

[Bug libstdc++/112477] Assignment of value-initialized iterators differs from value-initialization

[dangelog at gmail dot com via Gcc-bugs]

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

Giuseppe D'Angelo  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Giuseppe D'Angelo  ---
Sorry, I've accidentally selected the wrong component.

[Bug target/112435] [14 regression] GCC generates assembly which gas rejects with AVX when building ncnn (Error: unsupported instruction `vblendps') since r14-96-gc2dac2e5fbbcdd

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/112438] RISC-V: Wrong auto-vectorization on induction variable of RVV

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #15 from JuzheZhong  ---
Fixed

[Bug tree-optimization/111967] [12/13/14 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13/14 Regression]
   |during GIMPLE pass: evrp|during GIMPLE pass: evrp
   |ICE: in operator[], at  |ICE: in operator[], at
   |vec.h:910 with -O2  |vec.h:910 with -O2
   |-fno-tree-forwprop  |-fno-tree-forwprop
   |-fdump-tree-evrp-all|-fdump-tree-evrp-all since
   ||r12-4694
   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r12-4694-gcb153222404e2e149aa65a4b3139b09477551203

[Bug c/112478] New: riscv: asm clobbers not honored

[Michael at MichaelKloos dot com via Gcc-bugs]

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

Bug ID: 112478
   Summary: riscv: asm clobbers not honored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Michael at MichaelKloos dot com
  Target Milestone: ---

A recent commit (bisected): 

71f906498ada9ec2780660b03bd6e27a93ad350c 
RISC-V: far-branch: Handle far jumps and branches for functions larger than 1MB 

Seems to have broken call inline asm clobbers for for the $ra register.  

I attempted to build a riscv32-rv32ia3-linux-musl cross compiler on a
x86_64-pc-linux-gnu system.  I succeeded in building the compiler and using it
to build my target binary.  However, the target binary was crashing.  On
inspection, I discovered that __muldi3 from libgcc was calling __mulsi3, but
not saving the ra (link) register.  Upon return from __mulsi3, an infinate loop
was entered between the reentry point and the end of the function, as the
return instruction was now pointing back at the reentry point.  The
intermediate code formed a loop that moved and loaded data off the stack
pointer until the program segfaulted.  libgcc makes the call to __mulsi3 with
inline assembly and sets ra as one of the clobbered registers.  

Some of the configure options used are --disable-multilib --with-arch=rv32ia
--with-abi=ilp32 --enable-checking=none

--enable-checking=none is there to work around another build-time bug which I
will file separately.  

If you need more information, let me know.

[Bug target/112478] riscv: asm clobbers not honored

[Michael at MichaelKloos dot com via Gcc-bugs]

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

--- Comment #1 from Michael T. Kloos  ---
Added Andrew Waterman to CC list

[Bug middle-end/112475] [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

--- Comment #3 from Tobias Burnus  ---
> I admit I haven't paid much attention what the latest OpenMP standard 
> currently requires for virtual method calls.

OpenMP 5.0 "2.12.5 target Construct" [175:25-26] has:

"The effect of invoking a virtual member function of an object on a device
other than the device on which the object was constructed is implementation
defined"

BTW: The "5.0" testcase of sollve_vv (see comment 0) does inside the target
region:
  ptr = new S1();
which looks fine (valid 5.0).

* * *

In OpenMP 5.1, I cannot find anything :-/

* * *

OpenMP 5.2 [287:8-14] has in "13.8 target Construct" the following; note the
second bullet point:

" C++ ---
• The run-time type information (RTTI) of an object can only be accessed from
the device on which it was constructed.

• Invoking a virtual member function of an object on a device other than the
device on which the object was constructed results in unspecified behavior,
unless the object is accessible and was constructed on the host device.

• If an object of polymorphic class type is destructed, virtual member
functions of any previously existing corresponding objects in other device data
environments must not be invoked."

* * *

Thus, besides the dynamic allocation inside the device region, we need to
handle since 5.2 also the case the class instance was created on the host.

In either case, we need to have the virtual table on the device side (and all
relevant member functions, the latter should be the case due to the delimited
'declare target').

For the cases that a class was instantiated on the host and is used on the
device side, we need to:
(a) convert the host pointer to a device pointer for the vtable
(b) and then the pointers to the member functions in the vtable.

For the latter, we already have support for 'indirect' where
   fun_ptr ();
is automatically converted (on the device side, only) to
   GOMP_target_map_indirect_ptr (fun_ptr) ();

Thus, on the 'declare' side, the 'vtable' needs to be handled as well (created
on the device + have an 'indirect') - and, the easier part, 'declare target'
for virtual functions must automatically imply 'indirect'.

And on the usage side, GOMP_target_map_indirect_ptr calls have to be inserted
both for the vtable access and the member function access via the vtable.

[Bug c++/96917] decltype(auto) variable initialized with lambda by-reference capture has incorrect type

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:705ab7927c81b77503d229513fac991106617766

commit r14-5330-g705ab7927c81b77503d229513fac991106617766
Author: Patrick Palka 
Date:   Fri Nov 10 10:58:04 2023 -0500

c++: decltype of capture proxy [PR79378, PR96917]

We typically don't see capture proxies in finish_decltype_type because
process_outer_var_ref is a no-op within an unevaluated context and so a
use of a captured variable within decltype resolves to the captured
variable, not the capture.  But we can see them during decltype(auto)
deduction and for decltype of an init-capture, which suggests we need to
handle capture proxies specially within finish_decltype_type after all.
This patch adds such handling.

PR c++/79378
PR c++/96917

gcc/cp/ChangeLog:

* semantics.cc (finish_decltype_type): Handle an id-expression
naming a capture proxy specially.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto7.C: New test.
* g++.dg/cpp1y/lambda-init20.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/79378] lambda init-capture adds const

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:705ab7927c81b77503d229513fac991106617766

commit r14-5330-g705ab7927c81b77503d229513fac991106617766
Author: Patrick Palka 
Date:   Fri Nov 10 10:58:04 2023 -0500

c++: decltype of capture proxy [PR79378, PR96917]

We typically don't see capture proxies in finish_decltype_type because
process_outer_var_ref is a no-op within an unevaluated context and so a
use of a captured variable within decltype resolves to the captured
variable, not the capture.  But we can see them during decltype(auto)
deduction and for decltype of an init-capture, which suggests we need to
handle capture proxies specially within finish_decltype_type after all.
This patch adds such handling.

PR c++/79378
PR c++/96917

gcc/cp/ChangeLog:

* semantics.cc (finish_decltype_type): Handle an id-expression
naming a capture proxy specially.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto7.C: New test.
* g++.dg/cpp1y/lambda-init20.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/79620] decltype() inside a lambda capturing-by-value

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0410b754e56c0868203c2412e0585ba070ea938d

commit r14-5331-g0410b754e56c0868203c2412e0585ba070ea938d
Author: Patrick Palka 
Date:   Fri Nov 10 10:58:06 2023 -0500

c++: decltype of (by-value captured reference) [PR79620]

The capture_decltype handling in finish_decltype_type wasn't looking
through implicit INDIRECT_REF (added by convert_from_reference), which
caused us to incorrectly resolve decltype((r)) to float& below.  This
patch fixes this, and adds an assert to outer_automatic_var_p to help
prevent against such bugs.

We still don't fully accept the example ultimately because for the
decltype inside the lambda's trailing return type, at that point we're
in lambda type scope but not yet in lambda function scope that the
capture_decltype handling looks for (which is an orthogonal bug).

PR c++/79620

gcc/cp/ChangeLog:

* cp-tree.h (STRIP_REFERENCE_REF): Define.
* semantics.cc (outer_var_p): Assert REFERENCE_REF_P is false.
(finish_decltype_type): Look through implicit INDIRECT_REF when
deciding whether to call capture_decltype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-decltype3.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/79378] lambda init-capture adds const

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/96917] decltype(auto) variable initialized with lambda by-reference capture has incorrect type

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/54366] [meta-bug] decltype issues

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

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

Bug 96917 Summary: decltype(auto) variable initialized with lambda by-reference 
capture has incorrect type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96917

   What|Removed |Added

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

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 96917 Summary: decltype(auto) variable initialized with lambda by-reference 
capture has incorrect type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96917

   What|Removed |Added

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

[Bug c++/79620] decltype() inside a lambda capturing-by-value

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 79620 Summary: decltype() inside a lambda capturing-by-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79620

   What|Removed |Added

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

[Bug jit/111396] Segfault when using -flto with libgccjit

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #2 from Antoni  ---
Created attachment 56554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56554&action=edit
Patch fixing the issue

[Bug c++/63192] non-mutable lambda capture by value on reference does not apply const

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=79620 |
 CC||ppalka at gcc dot gnu.org

--- Comment #8 from Patrick Palka  ---
This seems to be a dup of the recently fixed PR79620.

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

[Bug c++/79620] decltype() inside a lambda capturing-by-value

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=63192 |
 CC||dacamara.cameron at gmail dot 
com

--- Comment #6 from Patrick Palka  ---
*** Bug 63192 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 63192 Summary: non-mutable lambda capture by value on reference does not 
apply const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63192

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/110752] decltype in lambda loses const qualifier unless lambda is mutable

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
dup of PR86697 it seems

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

[Bug c++/86697] decltype for lambda capture gives wrong type

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jzwinck at gmail dot com

--- Comment #3 from Patrick Palka  ---
*** Bug 110752 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111967] [12/13/14 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/112475] [UBSAN][OpenMP] ICE during GIMPLE pass: sanopt in output_operand: invalid expression as operand

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

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

--- Comment #4 from Jakub Jelinek  ---
• The run-time type information (RTTI) of an object can only be accessed from
the device on which it was constructed.
is weird, because RTTI can be queried not just on objects, but on types, and
there doesn't need to be any object associated with that type.

[Bug c++/92101] Class template partial specializations with class NTTP does not work

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Patrick Palka  ---
This appears to be a dup of PR93083 which has since been fixed for GCC >= 10.3.

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

[Bug c++/93083] [C++20] copy deduction rejected when doing CTAD for NTTP

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

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

--- Comment #11 from Patrick Palka  ---
*** Bug 92101 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111792] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-3414-g0cfc9c953d0221

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Indeed, doesn't reproduce since
r14-4786-gd118738e71cf4615f170fff8dabe66442206d008
Was that a fix for this or just made the bug latent?
In any case, we should add the testcase to the testsuite...

[Bug c++/96917] decltype(auto) variable initialized with lambda by-reference capture has incorrect type

[andrey.vihrov at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Andrey Vihrov  ---
Thanks!

[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r14-5333-gdf66fa08578a28b3acc8bdb6257b68c245a6a0fa
Author: Vladimir N. Makarov 
Date:   Fri Nov 10 11:14:46 2023 -0500

[IRA]: Check autoinc and memory address after temporary equivalence
substitution

My previous RA patches to take register equivalence into account do
temporary register equivalence substitution to find out that the
equivalence can be consumed by insns.  The insn with the substitution is
checked on validity using target-depended code.  This code expects that
autoinc operations work on register but this register can be substituted
by equivalent memory.  The patch fixes this problem.  The patch also adds
checking that the substitution can be consumed in memory address too.

gcc/ChangeLog:

PR target/112337
* ira-costs.cc: (validate_autoinc_and_mem_addr_p): New function.
(equiv_can_be_consumed_p): Use it.

gcc/testsuite/ChangeLog:

PR target/112337
* gcc.target/arm/pr112337.c: New.

[Bug target/112478] riscv: asm clobbers not honored

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Waterman  ---
Although I sketched the first draft of this patch, it’s Jeff Law who brought it
to fruition. He is more suited to help than I am.

[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||prathamesh3492 at gcc dot 
gnu.org
   Keywords|needs-bisection |

--- Comment #2 from Jakub Jelinek  ---
Started with r14-807-g8b18714fbb1ca9812b33b3de75fe6ba4a57d4946

[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

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

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
HI, sorry for the breakage, will take a look.

Thanks,
Prathamesh

[Bug target/82242] IRA spills allocno in loop body if it crosses throwing call outside the loop

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

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

--- Comment #5 from Alexander Monakov  ---
The small testcase from comment 3 is now improved on trunk, possibly thanks to
work in PR 110215.

[Bug c/112479] New: Missing -Woverflow warnings with bit fields with assignment of a constant

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

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

Bug ID: 112479
   Summary: Missing -Woverflow warnings with bit fields with
assignment of a constant
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

I noticed that -Woverflow misses some cases of -Woverflow.

DISCLAIMER: It might be that some sign/unsigned promotion makes it desirably
that no warning is shown. Still, as a mere user, I find it odd to see no
warning.

* * *

I did notice that Clang's -Wbitfield-constant-conversion warning (also on by
default) shows a rather similar pattern of warning vs. no warning. However,
Clang does warn for the following two assignments:

  s.b = 2; // MISSING diagnostic for 2 -> -2
  s.b = 3; // MISSING diagnostic for 3 -> -1

Thus, there is at least some inconsistency with regards to the warning between
GCC and Clang

* * *

/* Either of the following warning is shown by GCC, if any:
warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes value
from ‘1’ to ‘-0’ [-Woverflow]
warning: unsigned conversion from ‘int’ to ‘unsigned char:1’ changes value from
‘-3’ to ‘1’ [-Woverflow]
*/

void
my_signed()
{
  struct { int a:1, b:2; } s;
  s.a = -3; // Diagnosed: from ‘-3’ to ‘-1’
  s.a = -2; // Diagnosed: from ‘-2’ to ‘0’
  s.a = -1; // valid
  s.a = 0; // valid
  s.a = 1; // MISSING diagnostic for 1 -> -1
  s.a = 2; // Diagnosed: from ‘2’ to ‘0’
  s.a = 3; // Diagnosed: from ‘3’ to ‘-1’

  s.b = -3; // Diagnosed: from ‘-3’ to ‘1’
  s.b = -2; // valid
  s.b = -1; // valid
  s.b = 0; // valid
  s.b = 1; // valid
  s.b = 2; // MISSING diagnostic for 2 -> -2
  s.b = 3; // MISSING diagnostic for 3 -> -1
  s.b = 4; // Diagnosed: from ‘4’ to ‘0’
}

void
my_unsigned()
{
  struct { unsigned a:1, b:2; } u;
  u.a = -3; // Diagnosed: from ‘-3’ to ‘1’
  u.a = -2; // Diagnosed: from ‘-2’ to ‘0’
  u.a = -1; // MISSING diagnostic for -1 -> 1
  u.a = 0; // valid
  u.a = 1; // valid
  u.a = 2; // Diagnosed: from ‘2’ to ‘0’
  u.a = 3; // Diagnosed: from ‘3’ to ‘1’

  u.b = -3; // Diagnosed: from ‘-3’ to ‘1’
  u.b = -2; // MISSING diagnostic for -2 -> 2
  u.b = -1; // MISSING diagnostic for -1 -> 3
  u.b = 0; // valid
  u.b = 1; // valid
  u.b = 2; // valid
  u.b = 3; // valid
  u.b = 4; // Diagnosed: from ‘4’ to ‘0’
}

[Bug target/112435] [14 regression] GCC generates assembly which gas rejects with AVX when building ncnn (Error: unsupported instruction `vblendps') since r14-96-gc2dac2e5fbbcdd

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 56553 [details]
> gcc14-pr112435.patch
> 
> Untested fix.

https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635760.html ?

But I think your patch might be better ... though that includes more testcases.

[Bug libstdc++/112480] New: optional::reset emits inefficient code when T is trivially-destructible

[gnu at kosak dot com via Gcc-bugs]

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

Bug ID: 112480
   Summary: optional::reset emits inefficient code when T is
trivially-destructible
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu at kosak dot com
  Target Milestone: ---

Created attachment 56556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56556&action=edit
the .ii file from -save-temps

Hello,

The assembly output of this program shows that the generated code tests whether
a flag is zero, and if not, sets it to zero. This uses a compare and a branch,
when the optimal code could just force the flag to zero unconditionally with
one instruction. The emitted code is going to be non-optimal in this way for
any trivially-destructible T.

```
#include 

void func(std::optional &x) {
x.reset();
}
```

Relevant assembly on x86_64, invoked with g++ -S -O3 test.cc
```
_Z4funcRSt8optionalIiE:
.LFB266:
.cfi_startproc
endbr64
cmpb$0, 4(%rdi)
je  .L1
movb$0, 4(%rdi)
.L1:
ret
.cfi_endproc
```

The non-optimal code arises because optional::reset() needs to decide
whether or not to call ~T(), and this decision depends on whether or not the
optional is currently holding a value. However, if T is trivially destructible,
~T() is a no-op, so the test and branch is kind of a waste.

One way this could be addressed is via this one-line change to
/usr/include/c++/13/optional:

```
--- optional.ORIG   2023-11-10 19:01:35.843372670 +
+++ optional2023-11-10 19:22:53.525894777 +
@@ -314,7 +314,7 @@
   constexpr void
   _M_reset() noexcept
   {
-   if (this->_M_engaged)
+   if (is_trivially_destructible_v<_Tp> || this->_M_engaged)
  _M_destroy();
   }
 };

```
With this change in place, the emitted assembly is
```
_Z4funcRSt8optionalIiE:
.LFB266:
.cfi_startproc
endbr64
movb$0, 4(%rdi)
ret
.cfi_endproc
```

Output from g++ -v:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 13.2.0-4ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-XYspKM/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-XYspKM/gcc-13-13.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-4ubuntu3)
```

[Bug c++/109122] std::ranges::find segfaults with gcc (trunk but not 12.2) on godbolt

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 56557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56557&action=edit
reduction but not best though

[Bug modula2/110779] SysClock can not read the clock

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

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

--- Comment #20 from Gaius Mulley  ---
Created attachment 56558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56558&action=edit
Proposed fix (libgm2/acinclude.m4 and libgm2/configure.host)

Here is a proposed patch for a new file libgm2/acinclude.m4 and
libgm2/configure.host.  These were taken from libstdc++-v3 and heavily pruned.
I've seen it bootstrap under netbsd, freebsd, aarch64 linux, x86_64 linux.

acinclude.m4 provides the missing autoconf functions.

[Bug modula2/110779] SysClock can not read the clock

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

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

--- Comment #21 from Gaius Mulley  ---
I've just noticed that the patch doesn't address the issue of
GLIBCXX_IS_NATIVE.

[Bug libstdc++/112467] [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #6 from Sam James  ---
I hit the same when building Firefox with Clang which figures.

[Bug libstdc++/112480] optional::reset emits inefficient code when T is trivially-destructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I feel like the compiler should be able to do that anyway.

_M_destroy() is:

_M_engaged = false;
_M_payload._M_value.~_Stored_type();

For a trivially destructible type the second statement is a no-op, so we have:

  if (_M_engaged)
_M_engaged = false;

The compiler should turn that into _M_engaged = false.

The suggested change is wrong though, because it runs the trivial destructor
unconditionally, even if there is no object within its lifetime. Clang will
diagnose that during constant evaluation (although gcc doesn't, which I think
is a known bug).

For example:

#include 

constexpr bool f()
{
  std::optional opt(1);
  opt = std::nullopt;
  opt = std::nullopt;
  return true;
}

static_assert(f());


opt.cc:10:15: error: static assertion expression is not an integral constant
expression
static_assert(f());
  ^~~
/home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/optional:282:2:
note: destruction of member '_M_value' of union with active member '_M_empty'
is not allowed in a constant expression
_M_payload._M_value.~_Stored_type();
^
/home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/optional:313:4:
note: in call to '&opt._Optional_base::_M_payload->_M_destroy()'
  _M_destroy();
  ^
/home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/optional:465:45:
note: in call to '&opt._Optional_base::_M_payload->_M_reset()'
  { static_cast<_Dp*>(this)->_M_payload._M_reset(); }
^
/home/jwakely/gcc/latest/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/optional:831:8:
note: in call to '&opt->_M_reset()'
this->_M_reset();
  ^
opt.cc:6:7: note: in call to '&opt->operator=({})'
  opt = std::nullopt;
  ^
opt.cc:10:15: note: in call to 'f()'
static_assert(f());
  ^
1 error generated.


We could do:

  constexpr void
  _M_reset() noexcept
  {
if constexpr (is_trivially_destructible_v<_Tp>)
  {
if (!std::__is_constant_evaluated())
  {
this->_M_engaged = false;
return;
  }
  }

if (this->_M_engaged)
  _M_destroy();
  }


Yuck

[Bug libstdc++/112467] [14 Regression] libstdc++ fails to build on clang: bits/stl_bvector.h:189:23: error: '__assume__' attribute cannot be applied to a statement

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
This seems to work:

--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -185,8 +185,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 void
 _M_assume_normalized() const
 {
+#if __has_attribute(__assume__) && !defined(__clang__)
   unsigned int __ofst = _M_offset;
   __attribute__ ((__assume__ (__ofst < unsigned(_S_word_bit;
+#endif
 }

 _GLIBCXX20_CONSTEXPR

[Bug c++/109122] std::ranges::find segfaults with gcc (trunk but not 12.2) on godbolt

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
The problem seems to be with pretty printing a reference/pointer to a pointer
to member function type:

template
concept C = requires (T t, F f) { (t.*f)(); };

struct A;

static_assert(C);

[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)

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

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

--- Comment #14 from Sam James  ---
(In reply to Alexander Monakov from comment #13)
> Note to self: check how control_flow_insn_p relates.

Did you have a chance to look at this bit? matoro asked me to cherry-pick it
downstream but it's in generic code from a skim so...

[Bug target/112481] New: [14 Regression] RISCV: ICE: Segmentation fault when compiling pr110817-3.c

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112481
   Summary: [14 Regression] RISCV: ICE: Segmentation fault when
compiling pr110817-3.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56559&action=edit
-freport-bug output

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gc -mabi=lp64d -O1 
> ../gcc/gcc/testsuite/gcc.c-torture/execute/pr110817-3.c -freport-bug
during RTL pass: expand
../gcc/gcc/testsuite/gcc.c-torture/execute/pr110817-3.c: In function 'main':
../gcc/gcc/testsuite/gcc.c-torture/execute/pr110817-3.c:10:28: internal
compiler error: Segmentation fault
   10 |   volatile signed int t = x[0];
  |   ~^~~
0x16626a3 crash_signal
../../../gcc/gcc/toplev.cc:316
0x120ff7f emit_move_insn(rtx_def*, rtx_def*)
../../../gcc/gcc/expr.cc:4249
0x1221488 expand_constructor
../../../gcc/gcc/expr.cc:8970
0x120c148 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:11245
0x120c959 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:10860
0x120f354 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../../gcc/gcc/expr.h:310
0x120f354 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../../gcc/gcc/expr.cc:8627
0x1203e9a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../../gcc/gcc/expr.cc:10628
0x120c8dd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:10856
0x120a786 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:12011
0x120c959 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:10860
0x120f354 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../../gcc/gcc/expr.h:310
0x120f354 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../../gcc/gcc/expr.cc:8627
0x12031c6 do_store_flag
../../../gcc/gcc/expr.cc:13283
0x12042cf expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../../gcc/gcc/expr.cc:10292
0x120c8dd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:10856
0x120471a expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../../gcc/gcc/expr.cc:9049
0x120471a expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../../gcc/gcc/expr.h:310
0x120471a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../../gcc/gcc/expr.cc:9377
0x120c8dd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:10856
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Currently bisecting:
good: 879cf9ff45d94065d89e24b71c6b27c7076ac518
bad: a5922427c29fad177251d89cc946d1c5bfc135eb

-freport-bug output attached

[Bug target/112481] [14 Regression] RISCV: ICE: Segmentation fault when compiling pr110817-3.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0