[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #21 from Mikael Morin  ---
(In reply to anlauf from comment #20)
> 
> This patch fails for me on several occasions including the testsuite.
> I guess the logic was intended as follows:
> 
Well, not really, it seems wasteful to use the heap for something known to be
useless anyway.
But I agree that your variant is probably safer.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #22 from Mikael Morin  ---
(In reply to anlauf from comment #20)
> (In reply to Mikael Morin from comment #18)
> > Created attachment 55300 [details]
> > Alternative patch v2
> 
> This patch fails for me on several occasions including the testsuite.

Obviously the stack shouldn't be used if the array can grow dynamically
(dynamic == true).
So the patch could be simplified further:

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1c7ea900ea1..cc1dddbeb33 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE)
 {
   /* A callee allocated array.  */
   gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #23 from Mikael Morin  ---
(In reply to Mikael Morin from comment #22)
> 
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
> index 1c7ea900ea1..cc1dddbeb33 100644
> --- a/gcc/fortran/trans-array.cc
> +++ b/gcc/fortran/trans-array.cc
> @@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
> stmtblock_t * post,
>  
>desc = info->descriptor;
>info->offset = gfc_index_zero_node;
> -  if (size == NULL_TREE || integer_zerop (size))
> +  if (size == NULL_TREE)
>  {
>/* A callee allocated array.  */
>gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

This regresses on pr108065.f90 (that's a few extra analyzer warnings),
and on pr69955.f90 (that's one extra __builtin_malloc).

[Bug d/110193] d_signed_or_unsigned_type is invoked for vector types

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

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

--- Comment #5 from Richard Biener  ---
I noticed this by instrumenting TYPE_PRECISION and ICEing when applied on
VECTOR_TYPEs.

[Bug middle-end/108410] x264 averaging loop not optimized well for avx512

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 12 Jun 2023, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
> 
> --- Comment #6 from Hongtao.liu  ---
> 
> > and the key thing to optimize is
> > 
> >   ivtmp_78 = ivtmp_77 + 4294967232; // -64
> >   _79 = MIN_EXPR ;
> >   _80 = (unsigned char) _79;
> >   _81 = {_80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> > _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> > _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> > _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> > _80, _80, _80, _80, _80, _80};
> > 
> > that is we want to broadcast a saturated (to vector element precision) 
> > value.
> 
> Yes, backend needs to support vec_pack_ssat_m, vec_pack_usat_m.

Can x86 do this?  We'd want to apply this to a scalar, so move ivtmp
to xmm, apply pack_usat or as you say below, the non-existing us_trunc
and then broadcast.

[Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP transformation with MIN_EXPR and known relation

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed, mine.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #24 from Mikael Morin  ---
(In reply to Mikael Morin from comment #23)
> 
> This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> and on pr69955.f90 (that's one extra __builtin_malloc).

This removes the regressions.  Not fully retested again.

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1c7ea900ea1..7ae7eacca0b 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE || (dynamic && integer_zerop (size)))
 {
   /* A callee allocated array.  */
   gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/110214] x86 backend lacks support for vec_pack_ssat_m and vec_pack_usat_m

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
The BB vectorizer would use the same vec_pack_[us]sat_m, to use these for
vectorizing we'd need pattern matching of saturating [truncation].

For the specific use-case in AXV512 masked epilog vectorization we can also
open-code this with internal-functions.

It might also be interesting to match these in STV?

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

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

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

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #30 from Marc Poulhiès  ---
Hello  Xi Ruoyao,

Your 3 patches are also fixing the regressions in the gcc-12 branch. Do you
plan on back-porting them on this release branch?

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
Here is the problem:

vmovd   .LC1(%rip), %xmm4   # 21[c=4 l=10]  *movv4qi_internal/4
...
vpmovzxbw   %xmm4, %xmm4# 22[c=10 l=6] 
sse4_1_zero_extendv8qiv8hi2/2
...
vpsrlvw %xmm1, %xmm4, %xmm1 # 24[c=4 l=6]  avx512vl_lshrvv8hi
...
vpmullw %xmm4, %xmm0, %xmm0 # 63[c=4 l=4]  *mulv8hi3/1


.LC1:
.byte   -52
.byte   -52
.byte   -52
.byte   -52

The compiler loads .LC1 (actually { 204, 204, 204, 204 } into %xmm4. Please
note that this only has 4 QImode elements. Following that, it uses VPMOVZXBW
which extends 8 QImode elements to 8 HImode elements. VPSRLVW actually uses
only 4 QImode elements, so everything is OK here.

However, VPMULLW needs all 8 QImode elements, but %xmm4 only has 4 loaded; the
high 4 elements are zero. This effectively clears high four elements from the
multiplication result, and this is what the testcase detects.

[Bug c++/105838] [10/11/12 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

--- Comment #23 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:2764335bd336f2360d465ffcaa8f2c33f7321ab4

commit r14-1705-g2764335bd336f2360d465ffcaa8f2c33f7321ab4
Author: Jason Merrill 
Date:   Tue Dec 6 18:10:48 2022 -0500

c++: build initializer_list in a loop [PR105838]

I previously applied this change in r13-4565 but reverted it due to
PR108071.  That PR was then fixed by r13-4712, but I didn't re-apply this
change then because we weren't making the array static; since r14-1500 for
PR110070 we now make the initializer array static, so let's bring this
back.

In situations where the maybe_init_list_as_range optimization isn't viable,
we can build an initializer_list with a loop over a constant array
of string literals.

This is represented using a VEC_INIT_EXPR, which required adjusting a
couple
of places that expected the initializer array to have the same type as the
target array and fixing build_vec_init not to undo our efforts.

PR c++/105838

gcc/cp/ChangeLog:

* call.cc (convert_like_internal) [ck_list]: Use
maybe_init_list_as_array.
* constexpr.cc (cxx_eval_vec_init_1): Init might have
a different type.
* tree.cc (build_vec_init_elt): Likewise.
* init.cc (build_vec_init): Handle from_array from a
TARGET_EXPR.  Retain TARGET_EXPR of a different type.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/initlist-opt5.C: New test.

[Bug rtl-optimization/110215] RA fails to allocate register when loop invariant lives across calls and eh

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
   Keywords|EH  |

--- Comment #3 from Richard Biener  ---
The issue is that we fail to sink

 d_29 = {t_28, t_28, t_28 t_28};

we compute a good place in select_best_block but then since it is at the
same loop depth as the original place we apply

  /* If BEST_BB is at the same nesting level, then require it to have
 significantly lower execution frequency to avoid gratuitous movement.  */
  if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
  /* If result of comparsion is unknown, prefer EARLY_BB.
 Thus use !(...>=..) rather than (...<...)  */
  && !(best_bb->count * 100 >= early_bb->count * threshold))
return best_bb;

and fail to sink.  I'm not exactly sure why we do the above - we probably
should when best_bb post-dominates early_bb, also if the sunk stmt
possibly (or provably) will enlarge lifetime of its uses (but that's also
hard to guess since we process sinking of the defs of the uses only
afterwards).  In this case we have a single use and a single def so
sinking shouldn't make things worse.  We could also weight in
spilling class of a reg here.

In our case we have the dominated block with a higher(!) count than
the dominating block which means the profile is corrupt.

With --param sink-frequency-threshold we sink the ctor and the feeding
division but still get

.L5:
movq(%rbx), %rax
pxor%xmm1, %xmm1
leaq0(%rbp,%rax), %rdx
.p2align 4,,10
.p2align 3
.L4:
movaps  (%rsp), %xmm0
addps   (%rax), %xmm0
addq$16, %rax
movaps  %xmm0, -16(%rax)
addps   %xmm0, %xmm1
cmpq%rax, %rdx
jne .L4
movaps  %xmm1, %xmm0
movhlps %xmm1, %xmm0
addps   %xmm0, %xmm1
movaps  %xmm1, %xmm0
shufps  $85, %xmm1, %xmm0
addps   %xmm1, %xmm0
.LEHB1:
call_Z1gf
addq$8, %rbx
cmpq%rbx, %r12
jne .L5

because we (rightfully so) refuse to sink into the outer loop.  What we
fail to do is hoist the reload out of the inner loop (I suppose
clang does exactly that).

We don't have any pass after reload that would perform loop invatiant motion,
I'm not sure how this situation is handled in general in RA - is a post-RA
pass optimizing the spill/reload placement "globally" usually done?

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

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

https://gcc.gnu.org/g:820d1aec89c43dbbc70d3d0b888201878388454c

commit r14-1706-g820d1aec89c43dbbc70d3d0b888201878388454c
Author: Richard Biener 
Date:   Mon Jun 12 10:17:26 2023 +0200

middle-end/110200 - genmatch force-leaf and convert interaction

The following fixes code GENERIC generation for (convert! ...)
which currently generates

  if (TREE_TYPE (_o1[0]) != type)
_r1 = fold_build1_loc (loc, NOP_EXPR, type, _o1[0]);
if (EXPR_P (_r1))
  goto next_after_fail867;
  else
_r1 = _o1[0];

where obviously braces are missing.

PR middle-end/110200
* genmatch.cc (expr::gen_transform): Put braces around
the if arm for the (convert ...) short-cut.

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

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

https://gcc.gnu.org/g:73ae34bb693038829c05bed30d7ac623e67bde2e

commit r13-7439-g73ae34bb693038829c05bed30d7ac623e67bde2e
Author: Richard Biener 
Date:   Mon Jun 12 10:17:26 2023 +0200

middle-end/110200 - genmatch force-leaf and convert interaction

The following fixes code GENERIC generation for (convert! ...)
which currently generates

  if (TREE_TYPE (_o1[0]) != type)
_r1 = fold_build1_loc (loc, NOP_EXPR, type, _o1[0]);
if (EXPR_P (_r1))
  goto next_after_fail867;
  else
_r1 = _o1[0];

where obviously braces are missing.

PR middle-end/110200
* genmatch.cc (expr::gen_transform): Put braces around
the if arm for the (convert ...) short-cut.

(cherry picked from commit 820d1aec89c43dbbc70d3d0b888201878388454c)

[Bug target/109456] `-ffixed-reg` cannot prevent using `reg` for ABI-mandated roles (argument register etc) and the behavior should be documented more clearly

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

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|`-ffixed` is ignored for|`-ffixed-reg` cannot
   |`a` registers on RISC-V.|prevent using `reg` for
   ||ABI-mandated roles
   ||(argument register etc) and
   ||the behavior should be
   ||documented more clearly

--- Comment #11 from Xi Ruoyao  ---
Not a RISCV-specific issue.

[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #8)
> ix86_expand_sse_fp_minmax failed since rtx_equal_p (cmp_op0, if_true) is
> false, 
> 
> 249(reg:DF 86 [ _1 ])  (if_true)
> 250(reg:DF 83 [ _2 ])  (if_false)
> 251(reg:DF 82 [ _1 ])  (cmp0_op0)
> 252(reg:DF 83 [ _2 ])  (cmp1_op1)
> 
> but here if_true is just a copy from cmp_op0 but with different REGNO,
> rtx_equal_p seems too conservative here.
> 

But if_convert didn't maintain DF_CHAIN info, and and backend can't get
DF_REG_DEF_* info to figure out if_true is just a single_set of cmp_op0.


With -march=x86-64-v2, gcc generates 

movsd   (%rdi), %xmm2
movsd   (%rsi), %xmm1
movapd  %xmm2, %xmm0
movapd  %xmm1, %xmm3
cmpltsd %xmm1, %xmm0
maxsd   %xmm2, %xmm3
blendvpd%xmm0, %xmm2, %xmm1
movsd   %xmm3, (%rsi)
movsd   %xmm1, (%rdi)
ret

Which can be further optimized: cmpltsd + blendvpd -> minsd

[Bug c++/110216] New: Outdated implementation of tuple_size requirements for structured binding

[gnaggnoyil at gmail dot com via Gcc-bugs]

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

Bug ID: 110216
   Summary: Outdated implementation of tuple_size requirements for
structured binding
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnaggnoyil at gmail dot com
  Target Milestone: ---

The following code is rejected with `g++ -std=c++20` as of GCC 13.1:

#include 

struct A { int x; };

namespace std
{
template<>
struct tuple_size<::A> {};
}

auto [x] = A{};

Clang 16.0 on the other hand accepts this code with `-std=c++20` flag.

Wording of N4849 (and also the latest working draft as of today) specifies the
expected behavior in [dcl.struct.bind]#4 as follows:

Otherwise, if the qualified-id std::tuple_size names a complete class
type with a member named value, ...

Therefore, the above code shouldn't follow the requirements specified in
[dcl.struct.bind]#4 as tuple-like types. Instead, it should follow those in
[dcl.struct.bind]#5 and do the binding to data members.

This behavior change was introduced by CWG 2386 and corresponding wording
change can be found at
https://github.com/cplusplus/draft/commit/498092ced200140801180dcc9c2878a49350f946

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
cprop1 pass does not consider paradoxical subreg and for (insn 22) claims that
it equals 8 elements of QImode:

(insn 21 19 22 4 (set (reg:V4QI 98)
(mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S4 A32]))
"pr110206.c":12:42 1530 {*movv4qi_internal}
 (expr_list:REG_EQUAL (const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])
(nil)))
(insn 22 21 23 4 (set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "pr110206.c":12:42 7471 {sse4_1_zero_extendv8qiv8hi2}
 (expr_list:REG_EQUAL (const_vector:V8HI [
(const_int 204 [0xcc]) repeated x8
])
(expr_list:REG_DEAD (reg:V4QI 98)
(nil

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #5 from Uroš Bizjak  ---
Recategorized as generic RTL optimization problem.

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)

> However, VPMULLW needs all 8 QImode elements, but %xmm4 only has 4 loaded;

To be consistent, VPSRLVW and VPMULLW use HImode elements.

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
> that it equals 8 elements of QImode:

8 elements of HImode.

[Bug target/110217] New: [avr] SREG: use BSET and BCLR instead of load/modify/write

[mx682x at gmail dot com via Gcc-bugs]

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

Bug ID: 110217
   Summary: [avr] SREG: use BSET and BCLR instead of
load/modify/write
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mx682x at gmail dot com
  Target Milestone: ---

Created attachment 55306
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55306&action=edit
patch file for gcc 13.1

Hello.

I'd like to suggest a patch that makes the compiler use bset and bclr
instructions when doing SREG &= 0x80 (or ~0x80) or similr. Right now, all
versions, as far as I know, are using in/andi(ori)/out instructions to change
the SREG.

[Bug tree-optimization/110218] New: sink pass heuristic not working in practice

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

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

Bug ID: 110218
   Summary: sink pass heuristic not working in practice
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

In r0-112722-g1cc17820c32e8b Jeff introduced --param sink-frequency-threshold
replacing

-  /* Move the expression to a post dominator can't reduce the number of
- executions.  */
-  if (dominated_by_p (CDI_POST_DOMINATORS, frombb, sinkbb))
-return false;

with

  /* If BEST_BB is at the same nesting level, then require it to have
 significantly lower execution frequency to avoid gratuitous movement.  */
  if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
  /* If result of comparsion is unknown, prefer EARLY_BB.
 Thus use !(...>=..) rather than (...<...)  */
  && !(best_bb->count * 100 >= early_bb->count * threshold))
return best_bb;

where the logic of course is that when best_bb post-dominates early_bb
then the counts should be the same.  Other than that the new logic
prevents some partial dead code elimination.

What the sinking pass does is, in addition to moving code to only
conditional executed places, it performs scheduling by moving the
code to the latest "best" basic block, not the earliest candidate.

The above logic might also catch EH and error control flow, avoiding
sinking along effective fallthru edges.  But rather than applying this
only at the end we should at least consider doing it in a loop
walking the dominators similar to the one selecting the best candidate

  while (temp_bb != early_bb)
{
  /* If we've moved into a lower loop nest, then that becomes
 our best block.  */
  if (bb_loop_depth (temp_bb) < bb_loop_depth (best_bb))
best_bb = temp_bb;

  /* Walk up the dominator tree, hopefully we'll find a shallower
 loop nest.  */
  temp_bb = get_immediate_dominator (CDI_DOMINATORS, temp_bb);
}

I'm seeing guessed profile where the dominated block has higher count
than the dominating block ...

Where to sink a stmt to in an effectively (ignoring error paths)
post-dominance region is a scheduling and register pressure problem
where also call ABI (in case of EH) matters.  Arguably that's none
of GIMPLEs business.

[Bug tree-optimization/110218] sink pass heuristic not working in practice

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
PR110215 motivated me to file this, but this heuristic has seen to causing
issues elsewhere as well.

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

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

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

commit r12-9694-gd5f72834a4817b180625a540b99f5c1934c2e0b8
Author: Richard Biener 
Date:   Mon Jun 12 10:17:26 2023 +0200

middle-end/110200 - genmatch force-leaf and convert interaction

The following fixes code GENERIC generation for (convert! ...)
which currently generates

  if (TREE_TYPE (_o1[0]) != type)
_r1 = fold_build1_loc (loc, NOP_EXPR, type, _o1[0]);
if (EXPR_P (_r1))
  goto next_after_fail867;
  else
_r1 = _o1[0];

where obviously braces are missing.

PR middle-end/110200
* genmatch.cc (expr::gen_transform): Put braces around
the if arm for the (convert ...) short-cut.

(cherry picked from commit 820d1aec89c43dbbc70d3d0b888201878388454c)

[Bug middle-end/110142] [14 Regression] x264 from SPECCPU 2017 miscompares from g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r14-1708-g3ad0ef34ccbe656a7a9e5962fe1173226104174a
Author: Andre Vieira 
Date:   Mon Jun 12 10:30:39 2023 +0100

vect: Don't pass subtype to vect_widened_op_tree where not needed [PR
110142]

This patch fixes an issue introduced by
g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
passed
to vect_widened_op_tree, when no subtype was to be used. This lead to an
errorneous use of IFN_VEC_WIDEN_MINUS.

gcc/ChangeLog:

PR middle-end/110142
* tree-vect-patterns.cc (vect_recog_widen_op_pattern): Don't pass
subtype to vect_widened_op_tree and remove subtype parameter, also
remove superfluous overloaded function definition.
(vect_recog_widen_plus_pattern): Remove subtype parameter and dont
pass
to call to vect_recog_widen_op_pattern.
(vect_recog_widen_minus_pattern): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/pr110142.c: New test.

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

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

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

commit r11-10856-g5bf1c33a5e619564e8602601cc1beebd99e1fb9e
Author: Richard Biener 
Date:   Mon Jun 12 10:17:26 2023 +0200

middle-end/110200 - genmatch force-leaf and convert interaction

The following fixes code GENERIC generation for (convert! ...)
which currently generates

  if (TREE_TYPE (_o1[0]) != type)
_r1 = fold_build1_loc (loc, NOP_EXPR, type, _o1[0]);
if (EXPR_P (_r1))
  goto next_after_fail867;
  else
_r1 = _o1[0];

where obviously braces are missing.

PR middle-end/110200
* genmatch.c (expr::gen_transform): Put braces around
the if arm for the (convert ...) short-cut.

(cherry picked from commit 820d1aec89c43dbbc70d3d0b888201878388454c)

[Bug tree-optimization/110219] New: [14 Regression] ICE: tree check: expected integer_cst, have real_cst in to_wide, at tree.h:6314 with _Complex float to int

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 110219
   Summary: [14 Regression] ICE: tree check: expected integer_cst,
have real_cst in to_wide, at tree.h:6314 with _Complex
float to int
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 55307
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55307&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre
testcase.c 
during GIMPLE pass: evrp
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: tree check: expected integer_cst, have
real_cst in to_wide, at tree.h:6314
8 | }
  | ^
0x851b7a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8899
0xd15336 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/repo/gcc-trunk/gcc/tree.h:3826
0xd15336 wi::to_wide(tree_node const*)
/repo/gcc-trunk/gcc/tree.h:6314
0xd159c2 wi::to_wide(tree_node const*)
/repo/gcc-trunk/gcc/tree.h:3570
0xd159c2 adjust_realpart_expr
/repo/gcc-trunk/gcc/gimple-range-fold.cc:538
0xd159c2 gimple_range_adjustment
/repo/gcc-trunk/gcc/gimple-range-fold.cc:563
0xd159c2 fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&,
fur_source&)
/repo/gcc-trunk/gcc/gimple-range-fold.cc:741
0x23c54b6 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/repo/gcc-trunk/gcc/gimple-range-fold.cc:594
0x23c597c fold_range(vrange&, gimple*, range_query*)
/repo/gcc-trunk/gcc/gimple-range-fold.cc:318
0x23be761 ranger_cache::get_global_range(vrange&, tree_node*, bool&)
/repo/gcc-trunk/gcc/gimple-range-cache.cc:1010
0x23b5bcc gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/repo/gcc-trunk/gcc/gimple-range.cc:311
0x1737079 range_query::value_of_stmt(gimple*, tree_node*)
/repo/gcc-trunk/gcc/value-query.cc:134
0x15febbf substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/repo/gcc-trunk/gcc/tree-ssa-propagate.cc:792
0x238035e dom_walker::walk(basic_block_def*)
/repo/gcc-trunk/gcc/domwalk.cc:311
0x15fdd05 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/repo/gcc-trunk/gcc/tree-ssa-propagate.cc:971
0x1702139 execute_ranger_vrp(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-vrp.cc:998
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ 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-1694-2023062131-g20643513b8d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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-1694-2023062131-g20643513b8d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230611 (experimental) (GCC)

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #25 from Mikael Morin  ---
(In reply to Mikael Morin from comment #24)
> (In reply to Mikael Morin from comment #23)
> > 
> > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > and on pr69955.f90 (that's one extra __builtin_malloc).
> 
> This removes the regressions.  Not fully retested again.
> 
Comment #23 is probably the more correct one.
Comment #24 works because of the double temporary.  Even if the first temporary
has NULL data component, the second one uses malloc unconditionally to set
data, and the argument is seen as present.

[Bug tree-optimization/110219] [14 Regression] ICE: tree check: expected integer_cst, have real_cst in to_wide, at tree.h:6314 with _Complex float to int

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug modula2/109952] Inconsistent HIGH values with 'ARRAY OF CHAR'

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r14-1710-ge8d41e031b9f52601249ec7e4c4215b851cc8ffe
Author: Eric Botcazou 
Date:   Mon Jun 12 11:34:38 2023 +0200

Fix oversight in latest change

gcc/
PR modula2/109952
* doc/gm2.texi (Standard procedures): Fix Next link.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

Rainer Orth  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Rainer Orth  ---
It is on sparc, but x86 still FAILs like before.

[Bug rtl-optimization/110220] New: ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

[daniel at rozsnyo dot com via Gcc-bugs]

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

Bug ID: 110220
   Summary: ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at rozsnyo dot com
  Target Milestone: ---

Created attachment 55308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55308&action=edit
Code that fails to compile

After I migrated from gcc-4.8/4.9 to recent versions, both the gcc-14.0.0 and
gcc-13.1.1 fail to compile my pretty large avr-mcu project at one specific
function/construct. While I have found a solution with making the code
differently constructed to not trigger the ICE, now that I found time, I did
reduce the output of the  -save-temps into a single function that triggers the
assertion.


during RTL pass: jump
insn-bug-minimal.c: In function ‘cmd_parse’:
insn-bug-minimal.c:184:1: internal compiler error: in patch_jump_insn, at
cfgrtl.cc:1295
  184 | }
  | ^
0x90de427 internal_error(char const*, ...)
???:0
0x820f6af fancy_abort(char const*, int, char const*)
???:0
0x835a3be redirect_edge_and_branch(edge_def*, basic_block_def*)
???:0
0x8dc2b15 cleanup_cfg(int)
???:0


The way to avoid this ICE is to comment out one of the switch(state) cases, or
move one of them before the switch into an if-statement (my current function
equivalent workaround).

My cross-compile toolchain is made by gentoo crossdev package.

The ICE seems to be present only at -Os for the attached minimal source:
avr-gcc -g -Os -Wall -mmcu=atxmega128a4u -std=gnu99 -c insn-bug-minimal.c -o
bug.o

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

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

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

--- Comment #9 from Gaius Mulley  ---
Created attachment 55309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55309&action=edit
Proposed fix v2

Here is a proposed fix, please can you test on your code?   It appears to work
with my short examples.

[Bug tree-optimization/110221] New: 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

Bug ID: 110221
   Summary: With AVX512 fully masking gfortran.dg/pr68146.f ICEs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The testcase ICEs with -march=znver4 --param vect-partial-vector-usage=2
because
invariant .COND_* functions with conditional masks that end up being invariant
get scheduled ahead of the loop by SLP.

This is similar to PR108979 but complicated by the conditional mask being
originally computed inside of the loop (so not vect_external_def).

[Bug tree-optimization/110222] New: Inefficient fully masked loop vectorization with AVX512

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

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

Bug ID: 110222
   Summary: Inefficient fully masked loop vectorization with
AVX512
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gfortran.dg/matmul_2.f90 with -march=znver4 --param vect-partial-vector-usage=2
shows the

  c(:,1:7:2) = matmul(a,b(:,1:7:2))

innermost loop vectorized with

  note:  vectorization_factor = 16, niters = 2

which means a statically known loop mask which is even power-of-two.  This
should be instead vectorized without masking and V2SImode vectors.  Similarly
for a theoretical niters = 3 or a niters < 4 this should use a smaller
(but masked) vector mode for vectorization, not the target preferred 512bit
size.

The x86 target currently chooses to not get costs with different vector modes
compared but in these cases statically selecting a better mode should be
possible.

[Bug tree-optimization/110223] New: Missed optimization vectorizing booleans comparisons

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

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

Bug ID: 110223
   Summary: Missed optimization vectorizing booleans comparisons
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

== truncate before bool

float a[1024], b[1024], c[1024], d[1024];
int k[1024];
_Bool res[1024];

int main ()
{
  int i;
  for (i = 0; i < 1024; i++)
res[i] = k[i] != ((i - 3) == 0);
}

vectorizes but does the bit clear before the truncate. Due to the high unroll
factor if done the other way around we can save the extra bitclears.

== reduce using unpack

float a[1024], b[1024], c[1024], d[1024];
_Bool k[1024];
_Bool res[1024];

int main ()
{
  int i;
  for (i = 0; i < 1024; i++)
res[i] = k[i] != (i == 0);
}

Doesn't vectorize as the compiler doesn't know how to compare different boolean
vector element sizes.  Because i is an integer the result is a V4SI backed
boolean type, vs the V16QI one for k[i].  So it has to compare 4 V4SI vectors
against 1 V16QI, it can do this by truncating the the 4 V4SI bools to 1 V16QI
bool.

== mask vs non-mask type

_Bool k[1024];
_Bool res[1024];

int main ()
{
  char i;
  for (i = 0; i < 64; i++)
res[i] = k[i] != (i == 0);
}

doesn't vectorize because the compiler doesn't know how to compare a boolean
mask vs a non-mask boolean.  There's a comment in the source code that this can
be done using a pattern (presumably casting the types earlier).

in my case I need these to work on gcond as well, not just assigns,  and since
we don't codegen conds, it might be better to handle them in vectorizable_*.

[Bug fortran/110224] New: Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

Bug ID: 110224
   Summary: Rejects valid: function reference with data pointer
result as lhs in assignment
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

According to 9.2 of the F18 standard, a function reference that returns a data
pointer is a variable and can be used in variable definition contexts. In
particular it can be used as the selector in an associate construct (11.1.3.1,
C1101), however gfortran rejects this as invalid as shown by the following
example

module mod
  type :: foo
real, pointer :: var
  contains
procedure :: var_ptr
  end type
contains
  function var_ptr(this) result(ref)
class(foo) :: this
real, pointer :: ref
ref => this%var
  end function
end module
program main
  use mod
  type(foo) :: x
  associate (var => x%var_ptr())
var = 1.0
  end associate
  !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED
end program

gfortran-20230612.f90:36:4:

   36 | var = 1.0
  |1
Error: ‘var’ at (1) associated to expression cannot be used in a variable
definition context (assignment)

[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow

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

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

--- Comment #4 from David Malcolm  ---
Thanks for fixing this Tim.

Keeping open to track backporting this to the gcc 13 branch.

[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))

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

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

--- Comment #2 from David Malcolm  ---
Thanks for fixing this Tim.

Keeping open to track backporting this to the gcc 13 branch.

[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

--- Comment #1 from Richard Biener  ---
So sth along the PR108979 patch doesn't help:

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 61e508fcb6c..be963aea16f 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3365,6 +3365,7 @@ vectorizable_call (vec_info *vinfo,
   if (internal_fn_p (cfn))
 mask_opno = internal_fn_mask_index (as_internal_fn (cfn));

+  bool is_invariant = true;
   for (i = 0; i < nargs; i++)
 {
   if ((int) i == mask_opno)
@@ -3383,6 +3384,8 @@ vectorizable_call (vec_info *vinfo,
 "use not simple.\n");
  return false;
}
+  if (dt[i] != vect_external_def && dt[i] != vect_constant_def)
+   is_invariant = false;

   /* We can only handle calls with arguments of the same type.  */
   if (rhs_type
@@ -3607,7 +3610,8 @@ vectorizable_call (vec_info *vinfo,
   scalar_dest = gimple_call_lhs (stmt);
   vec_dest = vect_create_destination_var (scalar_dest, vectype_out);

-  bool masked_loop_p = loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo);
+  bool masked_loop_p
+= !is_invariant && loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo);
   unsigned int vect_nargs = nargs;
   if (masked_loop_p && reduc_idx >= 0)
 {

[Bug c/110205] Some new warnings from clang for the range code

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  ---
There is a second set of patches coming, I will make sure anything that remains
from this list is addressed when they go in.

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

[admin--- via Gcc-bugs]

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

--- Comment #10 from Thorsten Otto  ---
Yes, thank you, that seems to work.

[Bug c++/110225] New: [14 regression] many ICEs after r14-1624-g28db36e2cfca1b

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

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

Bug ID: 110225
   Summary: [14 regression] many ICEs after
r14-1624-g28db36e2cfca1b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:28db36e2cfca1b7106adc8d371600fa3a325c4e2, r14-1624-g28db36e2cfca1b

I saw these on powerpc64 BE systems but not on LE systems.

FAIL: 25_algorithms/minmax/constrained.cc (test for excess errors)
FAIL: 25_algorithms/minmax/constrained.cc (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 102)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 102)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 106)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 106)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 109)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 109)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 113)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 113)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 114)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 114)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 116)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 116)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 34)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 34)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 44)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 44)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 62)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 62)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 68)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 68)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 74)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 74)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 93)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 93)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 94)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 94)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 98)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 98)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 99)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20  (test for errors, line 99)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-p1186.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth1.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth1.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth1.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth1.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth10.C  -std=gnu++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth10.C  -std=gnu++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth10.C  -std=gnu++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth10.C  -std=gnu++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth12.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth12.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth12.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth12.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth13.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth13.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth13.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth13.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/spaceship-synth14.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth14.C  -std=c++20 (internal compiler error:
Segmentation fault)
FAIL: g++.dg/cpp2a/spaceship-synth14.C  

[Bug c++/110226] New: GCC ignores include of non-existent header

[jpegqs at gmail dot com via Gcc-bugs]

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

Bug ID: 110226
   Summary: GCC ignores include of non-existent header
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpegqs at gmail dot com
  Target Milestone: ---

Try compiling this code with g++:

#if __has_include("quadmath123.h")
#endif
#include 

You shouldn't have "quadmath123.h", but GCC will compile this without error.
Reproduced in every version of GCC since __has_include was supported (GCC
4.9.2).

Occurs in Boost headers when  is not installed.

[Bug c++/110226] GCC ignores include of non-existent header

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Last reconfirmed||2023-06-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-1718-gbf470895905e9152424076d1630a9d2c60de023b
Author: Gaius Mulley 
Date:   Mon Jun 12 15:25:39 2023 +0100

PR modula2/110126 variables are reported as unused when referenced by ASM
fix

This patch fixes the trash list of the asm statement.  It introduces a
separate build procedure for trashed elements.

gcc/m2/ChangeLog:

PR modula2/110126
* gm2-compiler/M2Quads.def (BuildAsmElement): Remove
trash parameter.
(BuildAsmTrash): New procedure.
* gm2-compiler/M2Quads.mod (BuildAsmTrash): New procedure.
(BuildAsmElement): Remove trash parameter.
* gm2-compiler/P3Build.bnf (AsmTrashList): Rewrite.

Signed-off-by: Gaius Mulley 

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #12 from Gaius Mulley  ---
Many thanks for the bug report and for testing the patches!
Closing now the patches have been applied.

[Bug target/110227] New: gcc generates invalid AVX-512 code

[joseph.weening at gmail dot com via Gcc-bugs]

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

Bug ID: 110227
   Summary: gcc generates invalid AVX-512 code
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joseph.weening at gmail dot com
  Target Milestone: ---

gcc version 13.1.0 (GCC)
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.1.0/configure --prefix=/usr/local/gcc/13.1.0
--disable-multilib --enable-languages=c,c++,fortran
--with-gmp=/usr/local/gmp/6.2.1 --with-mpc=/usr/local/mpc/1.3.1
--with-mpfr=/usr/local/mpfr/4.2.0 --with-isl=/usr/local/isl/0.24

The following program generates an error:
  /tmp/ccAuHFqz.s: Assembler messages:
  /tmp/ccAuHFqz.s:28: Error: unsupported instruction `vpcmpeqd'
The assembly code contains
vpcmpeqd %xmm16, %xmm16, %xmm16
which perhaps is invalid for xmm registers above 15.

#include 

__attribute__((noinline))
static void vswap(int32_t *x) {
  __m256i x0 = _mm256_loadu_si256((__m256i *) (&x[0]));
  __m256i x1 = _mm256_loadu_si256((__m256i *) (&x[1]));
  _mm256_storeu_si256((__m256i *) (&x[0]),(x1));
  _mm256_storeu_si256((__m256i *) (&x[1]),(x0));
}

void vproc(int32_t *x) {
  for (int32_t p=4; p>=1; p>>=1) {
if (p == 4) {
  __m256i mask = _mm256_set_epi32(0, 0, 0, 0, -1, -1, -1, -1);
  __m256i x0 = _mm256_loadu_si256((__m256i *) (&x[0]));
  x0 = _mm256_xor_si256(x0, mask);
  _mm256_storeu_si256((__m256i *) (&x[0]),(x0));
}
vswap(x);
  }
}

[Bug target/110227] gcc generates invalid AVX-512 code

[joseph.weening at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Joe Weening  ---
Sorry, forgot to include the command line:

$ gcc -march=cooperlake -O3 -c bug.c

[Bug c/110205] Some new warnings from clang for the range code

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

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

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

https://gcc.gnu.org/g:0ddc8c7871fdc7748315d9c09fcf29c2607a1077

commit r14-1735-g0ddc8c7871fdc7748315d9c09fcf29c2607a1077
Author: Andrew MacLeod 
Date:   Mon Jun 12 09:47:43 2023 -0400

Add some overrides.

PR tree-optimization/110205
* range-op-float.cc (range_operator::fold_range): Add default FII
fold routine.
* range-op-mixed.h (class operator_gt): Add missing final
overrides.
* range-op.cc (range_op_handler::fold_range): Add RO_FII case.
(operator_lshift ::update_bitmask): Add final override.
(operator_rshift ::update_bitmask): Add final override.
* range-op.h (range_operator::fold_range): Add FII prototype.

[Bug c++/110225] [14 regression] many ICEs after r14-1624-g28db36e2cfca1b

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Looks like this was fixed.  Thanks!

[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
   Last reconfirmed||2023-06-12
 Ever confirmed|0   |1
Summary|gcc generates invalid   |[13/14 Regression] gcc
   |AVX-512 code|generates invalid AVX-512
   ||code
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Semi-Reduced testcase:
```
#include 

void f()
{
  __m256i mask = _mm256_set_epi32(0, 0, 0, 0, -1, -1, -1, -1);
  register __m256i reg asm("xmm16") = mask;
  asm(""::"v"(reg));
}
```

Most likely introduced by r13-2804-ga282f086ef26d9 .

[Bug c/77650] struct with a nested flexible array followed by another member accepted

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
the patch for this documentation change in GCC has been posted and approved
at:https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620148.html

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
Summary|ICE in patch_jump_insn, at  |[13/14 Regression] ICE in
   |cfgrtl.cc:1295 - avr/xmega  |patch_jump_insn, at
   ||cfgrtl.cc:1295 - avr/xmega
  Known to work||12.1.0
   Keywords||ice-on-valid-code
  Known to fail||13.1.0, 14.0

--- Comment #1 from Andrew Pinski  ---
Looks like a latent bug in the RTL optimizers.

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 55310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55310&action=edit
Reduced as I can get it

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

[daniel at rozsnyo dot com via Gcc-bugs]

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

--- Comment #3 from Daniel Rozsnyo  ---
The ICE is triggered in gcc 13 and 14 versions only.

Added gcc 11 and 12 to my gentoo crossdev - it compiles without ICE assertion
on those.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #35 from Marek Polacek  ---
(In reply to Boris Kolpackov from comment #34)
> Would like to echo other's comments: getting a large number false positives
> in our codebase (build2). Thankfully this warning seems to only be enabled
> with -Wextra and not with -Wall as stated in #106393.

Yup.  I'm also planning to add a bunch of tweaks to significantly reduce the
number of false positives (and devise a way for users to easily suppress the
warning by adding a pragma around the class).  That work ought to happen in GCC
14.

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

--- Comment #4 from Andrew Pinski  ---
#2  0x00dfafd8 in patch_jump_insn (insn=0x77775360,
old_label=0x7760c840, new_bb=0x7776a000) at ../../gcc/cfgrtl.cc:1295
1295  gcc_assert (JUMP_LABEL (insn) == old_label);
(gdb) p debug_rtx(insn)
(jump_insn 143 142 139 3 (parallel [
(set (pc)
(if_then_else (gtu (reg:HI 57)
(const_int 6 [0x6]))
(label_ref 60)
(pc)))
(clobber (scratch:QI))
]) "t.c":12:9 683 {*cbranchhi4}
 (nil))
$1 = void

Which is checking the state before the switch table.

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-12
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
(In reply to Daniel Rozsnyo from comment #3)
> The ICE is triggered in gcc 13 and 14 versions only.
> 
> Added gcc 11 and 12 to my gentoo crossdev - it compiles without ICE
> assertion on those.

Yes it looks like it is only in GCC 13+. I tested it via https://godbolt.org/ .

[Bug preprocessor/110226] __has_include on a header causes GCC to ignore an non-existent header afterwards

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |preprocessor
 Depends on||80753

--- Comment #1 from Andrew Pinski  ---
I suspect it is a dup of bug 80753.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753
[Bug 80753] __has_include and __has_include_next taints subsequent I/O errors

[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

[fabio at cannizzo dot net via Gcc-bugs]

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

--- Comment #5 from Fabio Cannizzo  ---
> Well, there is nothing magic on exactly 0x55 immediate, there are 256
> possible immediates, most of them use all of A, B, C, some of them use just
> A, B, others just B, C, others just A, C, others just A, others just B,
> others just C, others none of them.

Indeed I meant 0x55 just as an example.

[Bug preprocessor/110226] __has_include on a header causes GCC to ignore an non-existent header afterwards

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Actually it is a dup of bug 80753.

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

[Bug preprocessor/80753] __has_include and __has_include_next taints subsequent I/O errors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jpegqs at gmail dot com

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

[Bug middle-end/110228] New: [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

Bug ID: 110228
   Summary: [14 Regression] llvm-16 miscompilation on small case
switch, minimized
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

I initially observed the failure as an llvm-16 (and older) single test failure
when built by r14-1704-gff83d1b47aadcd : 

- TEST 'LLVM :: ExecutionEngine/JITLink/X86/MachO_weak_references.s' FAILED

It is caused by  ObjectLinkingLayerJITLinkContext::lookup() miscompilation.

I extracted the following minimized example from it:

#include 

using M = std::vector;

static M s_lm{1};

__attribute__((noipa))
static const M & clm(void) {
return s_lm;
}

__attribute__((noipa))
static void bug(unsigned * p) {
const M & Symbols = clm();

for (unsigned v : Symbols) {
  int LookupFlags;
  switch (v) {
  // never used
  case 0:
LookupFlags = 0;
break;
  // always executed for a given input
  case 1:
LookupFlags = 1;
break;
  }
  *p = LookupFlags;
}
}

__attribute__((noipa))
int main() {
unsigned r = 42;
bug(&r);
if (r != 1) __builtin_trap();
}

Triggering:

$ g++ bug.cc -o bug -O1 -std=c++11 && ./bug
Illegal instruction (core dumped)
$ g++ bug.cc -o bug -O0 -std=c++11 && ./bug

Note: the program traverses vector of 1 element of value 1. Somehow on -O1 it
manages to miss `LookupFlags = 1;` store and does something else.

$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
--with-gmp-include=/0wz52f16y71ywjvc2rs9r7lw2axyl3fw3jma12azg88jia6k1srk/include
--with-gmp-lib=/1ri6zpg87f38gjqjg3hxxfwg9i4fk3hwr1d4c8saiic61pkmzvza/lib
--with-mpfr-include=/18rzsbmvdk9f7qcy0iynsiabalafwfhjjv9i38q7h5ckvz3z86hz/include
--with-mpfr-lib=/1dza8r46l2racn05l78c9iy3ibj1mp02bn45cwrfrg2rxqf05icg/lib
--with-mpc=/1pg6d47qa8b4l9mq51cvzkkd1jjjbqbvmlm6c9cyzw3kmsf4a10i
--with-native-system-header-dir=/16q46gpr64lcgbhkdnyigap3mc07g762vn2ckl6zqa12c1ww1kmp/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1
--with-isl=/16g549izckw0akjcgs6x4rps7swlqi0ff8i4xfs4cj36l7kdilpv
--disable-bootstrap --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
This has to do with uninitialized variables 

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 55311
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55311&action=edit
reduced testcase without vector

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2023-06-12
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
I am 99% sure this was exposed by r14-1597-g64d90d06d2db43538c8a45 .

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

--- Comment #4 from Andrew Pinski  ---
Phiopt does this:
```
v_13 == 1 ? 1 : LookupFlags_6
Matching expression match.pd:1990, gimple-match-5.cc:23
Matching expression match.pd:1990, gimple-match-5.cc:23
Matching expression match.pd:2479, gimple-match-4.cc:35
Matching expression match.pd:2482, gimple-match-3.cc:66
Matching expression match.pd:2489, gimple-match-2.cc:58
Matching expression match.pd:1947, gimple-match-7.cc:20
Applying pattern match.pd:4742, gimple-match-7.cc:15326
Folded into the sequence:
_17 = v_13 == 1;
_18 = LookupFlags_6 | _17;
Removing basic block 5
;; basic block 5, loop depth 1
;;  pred:   4
;;  succ:   6
```
As zero_one_valued_p returns true for LookupFlags_6 because
tree_nonzero_bits/get_nonzero_bits returns 1 for it.

So it is ranger in the end that returns that it has a nonzero bits of 1.
Which is completely wrong as LookupFlags_6 is defined by:
  # LookupFlags_6 = PHI 


Which has an uninitialized variable in it which is not defined at what its
value would be 

[Bug c++/110229] New: Segment fault on git clone

[larry9 at ffdlr dot com via Gcc-bugs]

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

Bug ID: 110229
   Summary: Segment fault on git clone
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larry9 at ffdlr dot com
  Target Milestone: ---

Created attachment 55312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55312&action=edit
Where gdb was at the segfault

The file is initializing a very large vector. An array doesn't cause the
segment fault. It needs to be compiled -O1 too, -O0 doesn't segfault. The file
needs some 12GiB to compile and took 5 hours with the debug cc1plus to get to
the fault. It also takes more or less entries between my machines and versions.
I found this with v11.3 under Ubuntu 22.04 but I did a git clone and compiled
with -O0 -ggdb to get the trace starting like

/net/larry/bin64/g++-git-dbg/libexec/gcc/x86_64-linux-gnu/14.0.0/cc1plus -quiet
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE bug.sh.cpp -quiet -dumpbase
bug.sh.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -O1 -o /tmp/bug.sh.s

#0  0x00c45f4c in gt_ggc_mx_lang_tree_node (x_p=0x7ffcef0f18a0) at
./gt-cp-tree.h:104
#1  0x00c466fd in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:494
#2  0x00c466fd in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:494
#3  0x00c466fd in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:494

I have included the gdb output as an attachment

The code is too large to be an attachment. It could easily be generated by a
script, but I don't know the rules on that one.

typedef unsigned long long int  size_t;

class psuedo_vector {
public:
  ~psuedo_vector() {
delete[] data_;
  }
  psuedo_vector(size_t sz) {
data_ = new int[sz];
  }
  int&  operator[] (size_t index) {
return data_[index];
  }
private:
  int*  data_;
};

psuedo_vector  V(2673938);

void
init_v()
{
  V[19]=19;
  V[20]=20;
...
  V[2589823]=2589823;
  V[2589824]=2589824;
}

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

--- Comment #5 from Andrew Pinski  ---
Note the original code definitely has an uninitialized variable in it.
The enum is defined as:
enum class SymbolLookupFlags { RequiredSymbol, WeaklyReferencedSymbol };

Which always has an underlying type  so all values (not just 0/1) are valid for
SymbolLookupFlags .

[Bug c++/110229] Segment fault with initializer an array (unrolled) in a function

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

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

--- Comment #1 from Andrew Pinski  ---
>It could easily be generated by a script, but I don't know the rules on that 
>one.
Attaching the script is ok for this case.

[Bug middle-end/110228] [14 Regression] llvm-16 miscompilation on small case switch, minimized

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

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

--- Comment #6 from Andrew Pinski  ---
Adding :

default:__builtin_unreachable();

Makes the testcase in this report work.
Maybe there should be an assert in LLVM's code too ...

[Bug c++/110229] Segment fault with initializer an array (unrolled) in a function

[larry9 at ffdlr dot com via Gcc-bugs]

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

--- Comment #2 from Larry Fiedler  ---
Created attachment 55313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55313&action=edit
script to make the c++ file that segfaults

[Bug middle-end/110229] Segment fault with initializer an array (unrolled) in a function

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

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

--- Comment #3 from Andrew Pinski  ---
By the way it is just a stack overflow while GCC is doing a mark and sweep GC .

[Bug middle-end/110229] Segment fault with initializer an array (unrolled) in a function

[larry9 at ffdlr dot com via Gcc-bugs]

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

--- Comment #4 from Larry Fiedler  ---
Yes, I should have experimented with changing the stack size.
The structure is now done as an initializer list of an array with no problems.

[Bug tree-optimization/110219] [14 Regression] ICE: tree check: expected integer_cst, have real_cst in to_wide, at tree.h:6314 with _Complex float to int

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-12
 Ever confirmed|0   |1

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

[Bug target/110105] ARM GCC: underoptimization: expected vfma.f16, actual vcvtb-vfma.f32-vcvtb

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Pavel M  ---
To: rsand...@gcc.gnu.org

Thanks! I confused __fp16 with _Float16.

However, if __fp16 is only a “storage type”, then why this code:
__fp16 mul(__fp16 x, __fp16 y)
{
return x * y;
}

compiled with -O3 -mfpu=fp-armv8 -march=armv8.2-a+fp16

leads to this code:
mul:
vmul.f16s0, s0, s1
bx  lr

Here we see vmul.f16 instead of half->float->vmul.f32->float->half.

As a user, I expect half->float->vmul.f32->float->half (because __fp16 is only
a “storage type”).

Where is the conversions and mul.f32?

P.S. If optimizer does this, then as I remember, half->float->op->float->half
does not always produce the same result as half->op->half. The difference in
result may be +/-1 (last) bit. Any comments?

[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r14-1738-gae193f9008e02683e27f3c87f3b06f38e103b1d0
Author: Jeff Law 
Date:   Mon Jun 12 12:52:10 2023 -0600

[committed] [PR rtl-optimization/101188] Fix reload_cse_move2add ignoring
clobbers

So as Georg-Johann discusses in the BZ, reload_cse_move2add can generate
 incorrect code when optimizing code with clobbers.  Specifically in the
case where we try to optimize a sequence of 4 operations down to 3
operations we can reset INSN to the next instruction and continue the loop.

That skips the code to invalidate objects based on things like REG_INC
nodes, stack pushes and most importantly clobbers attached to the current
insn.

This patch factors all of the invalidation code used by reload_cse_move2add
into a new function and calls it at the appropriate time.

Georg-Johann has confirmed this patch fixes his avr bug and I've had it in
my tester over the weekend.  It's bootstrapped and regression tested on
aarch64, m68k, sh4, alpha and hppa.  It's also regression tested
successfully
on a wide variety of other targets.

gcc/
PR rtl-optimization/101188
* postreload.cc (reload_cse_move2add_invalidate): New function,
extracted from...
(reload_cse_move2add): Call reload_cse_move2add_invalidate.

gcc/testsuite
PR rtl-optimization/101188
* gcc.c-torture/execute/pr101188.c: New test

[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
bug 71762 comment #7 is very much related to the issue here (and maybe even the
same).

[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
(In reply to Jakub Jelinek from comment #3)
> And I must say I don't immediately see easy rules how to find out from the
> immediate value which set is which, so unless we find some easy rule for
> that, we'd need to hardcode the mapping between the 256 values to a bitmask
> which inputs are actually used.

Well, that's really easy. The immediate is just a eight-entry look-up table
from any possible input bit triple to the output bit. The leftmost operand
corresponds to the most significant bit in the triple, so to check if the
operation vpternlog(A, B, C, I) is invariant w.r.t A you check if nibbles of I
are equal. Here we have 0x55, equal nibbles, and the operation is invariant
w.r.t A.

Similarly, to check if it's invariant w.r.t B we check if two-bit groups in I
come in pairs, or in code: (I & 0x33) == ((I >> 2) & 0x33). For 0x55 both sides
evaluate to 0x11, so again, invariant w.r.t B.

Finally, checking invariantness w.r.t C is (I & 0x55) == ((I >> 1) & 0x55).

[Bug tree-optimization/110218] sink pass heuristic not working in practice

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

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

--- Comment #2 from Jeffrey A. Law  ---
So what I think was happening was that we would sink past a bunch of
conditionals that were never going to be true thinking that we were moving to a
deeper control nest.  So the idea was to use the frequency information to avoid
movements that weren't likely to improve anything.

I don't remember how I selected the param's value though.  I've got no
objection to adjusting how this works.

[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.

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

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

--- Comment #8 from Andrew Pinski  ---
So the `&` case with r14-1597-g64d90d06d2db43538c8a45 should be ok always I
think as you are anding with a known non-uninitialized variable (that is always
0 or 1) that will produce a value which is known to be 0 or 1. It is one that
produces `|` that exposes the issue here. Even if gimple level says it is 0/1,
doing a `|` will produce an uninitialized value still and the upper bits are
not defined and things go off in the weeds then.

[Bug c++/110216] Outdated implementation of tuple_size requirements for structured binding

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Alias||cwg2386
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-12

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

[Bug c++/110216] tuple_size requirements for structured binding has not been updated after DR 2386

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

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/projects/cxx-dr-status.html

listed as ? there.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #55297|0   |1
is obsolete||

--- Comment #26 from anlauf at gcc dot gnu.org ---
Created attachment 55314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55314&action=edit
Revised/extended testcase

Testcase extended to check more code variations for intrinsic non-character
types and for empty derived type.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #25)
> (In reply to Mikael Morin from comment #24)
> > (In reply to Mikael Morin from comment #23)
> > > 
> > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > 
> > This removes the regressions.  Not fully retested again.
> > 
> Comment #23 is probably the more correct one.
> Comment #24 works because of the double temporary.  Even if the first
> temporary has NULL data component, the second one uses malloc
> unconditionally to set data, and the argument is seen as present.

Are you sure that you haven't mixed up those two?

When trying with my extended testcase, and looking at the tree dump,
I see a double temporary for the call

call i ([real:: y])

where the data pointer to the first allocation is clobbered later.
So I would rather go with the version from comment #24.

The said line is actually very old code ... ;-)

If you don't object, I'll package the patch with testcases and submit.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #28 from Mikael Morin  ---
(In reply to anlauf from comment #27)
> (In reply to Mikael Morin from comment #25)
> > (In reply to Mikael Morin from comment #24)
> > > (In reply to Mikael Morin from comment #23)
> > > > 
> > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > 
> > > This removes the regressions.  Not fully retested again.
> > > 
> > Comment #23 is probably the more correct one.
> > Comment #24 works because of the double temporary.  Even if the first
> > temporary has NULL data component, the second one uses malloc
> > unconditionally to set data, and the argument is seen as present.
> 
> Are you sure that you haven't mixed up those two?
> 
> When trying with my extended testcase, and looking at the tree dump,
> I see a double temporary for the call
> 
> call i ([real:: y])
> 
> where the data pointer to the first allocation is clobbered later.
> So I would rather go with the version from comment #24.
> 
Let's rephrase:
When (or rather if) we manage to remove the double temporary, we'll regress
with comment #24, not with comment #23.
The reallocation remains by the way, it's only pushed one step away.
Try this for example:

call i([real:: y, y])


> If you don't object, I'll package the patch with testcases and submit.

No problem, I think we are safe with the second temporary.

[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer

[adam.swartz--- via Gcc-bugs]

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

--- Comment #10 from Adam Swartz  ---
I have a program with 130+ .o files that would need the keepfile option.  Is
there a way to pass all of the object files to the linker with a single
keepfile option?  I cannot find any doc on the keepfile linker option.

Thanks,
Adam

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #29 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #28)
> (In reply to anlauf from comment #27)
> > (In reply to Mikael Morin from comment #25)
> > > (In reply to Mikael Morin from comment #24)
> > > > (In reply to Mikael Morin from comment #23)
> > > > > 
> > > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > > 
> > > > This removes the regressions.  Not fully retested again.
> > > > 
> > > Comment #23 is probably the more correct one.
> > > Comment #24 works because of the double temporary.  Even if the first
> > > temporary has NULL data component, the second one uses malloc
> > > unconditionally to set data, and the argument is seen as present.
> > 
> > Are you sure that you haven't mixed up those two?
> > 
> > When trying with my extended testcase, and looking at the tree dump,
> > I see a double temporary for the call
> > 
> > call i ([real:: y])
> > 
> > where the data pointer to the first allocation is clobbered later.
> > So I would rather go with the version from comment #24.
> > 
> Let's rephrase:
> When (or rather if) we manage to remove the double temporary, we'll regress
> with comment #24, not with comment #23.
> The reallocation remains by the way, it's only pushed one step away.
> Try this for example:
> 
> call i([real:: y, y])

I do see the reallocation, but in the case of the patch in #24 it is a
realloc of a NULL, which is well-defined nowadays.

But I do not see a regression.  On the contrary, every else seems unchanged.

>  
> > If you don't object, I'll package the patch with testcases and submit.
> 
> No problem, I think we are safe with the second temporary.

Besides the issue with one or two temporaries, is there anything else?

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #30 from Mikael Morin  ---
(In reply to anlauf from comment #29)
> (In reply to Mikael Morin from comment #28)
> > (In reply to anlauf from comment #27)
> > > (In reply to Mikael Morin from comment #25)
> > > > (In reply to Mikael Morin from comment #24)
> > > > > (In reply to Mikael Morin from comment #23)
> > > > > > 
> > > > > > This regresses on pr108065.f90 (that's a few extra analyzer 
> > > > > > warnings),
> > > > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > > > > 
> > > > > This removes the regressions.  Not fully retested again.
> > > > > 
> > > > Comment #23 is probably the more correct one.
> > > > Comment #24 works because of the double temporary.  Even if the first
> > > > temporary has NULL data component, the second one uses malloc
> > > > unconditionally to set data, and the argument is seen as present.
> > > 
> > > Are you sure that you haven't mixed up those two?
> > > 
> > > When trying with my extended testcase, and looking at the tree dump,
> > > I see a double temporary for the call
> > > 
> > > call i ([real:: y])
> > > 
> > > where the data pointer to the first allocation is clobbered later.
> > > So I would rather go with the version from comment #24.
> > > 
> > Let's rephrase:
> > When (or rather if) we manage to remove the double temporary, we'll regress
> > with comment #24, not with comment #23.
> > The reallocation remains by the way, it's only pushed one step away.
> > Try this for example:
> > 
> > call i([real:: y, y])
> 
> I do see the reallocation, but in the case of the patch in #24 it is a
> realloc of a NULL, which is well-defined nowadays.
> 
> But I do not see a regression.  On the contrary, every else seems unchanged.
> 
> >  
> > > If you don't object, I'll package the patch with testcases and submit.
> > 
> > No problem, I think we are safe with the second temporary.
> 
> Besides the issue with one or two temporaries, is there anything else?

Now that I think again, I'm not even sure we would regress.
My concern was that the data would remain NULL after the realloc(NULL, 0), and
the argument would not be seen as present.  With the second temporary, all is
well.

That's all there is.

[Bug testsuite/110230] New: new test case gcc.target/powerpc/pr109932-1.c in r14-1705-g2764335bd336f2 fails for 32 bits

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

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

Bug ID: 110230
   Summary: new test case gcc.target/powerpc/pr109932-1.c in
r14-1705-g2764335bd336f2 fails for 32 bits
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:2764335bd336f2360d465ffcaa8f2c33f7321ab4, r14-1705-g2764335bd336f2
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
powerpc.exp=gcc.target/powerpc/pr109932-1.c"
FAIL: gcc.target/powerpc/pr109932-1.c  (test for errors, line 14)
FAIL: gcc.target/powerpc/pr109932-1.c (test for excess errors)
# of unexpected failures2


commit ff83d1b47aadcdaf80a4fda84b0dc00bb2cd3641 (HEAD)
Author: Kewen Lin 
Date:   Mon Jun 12 01:08:22 2023 -0500

rs6000: Guard __builtin_{un,}pack_vector_int128 with vsx [PR109932]



spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr109932-1.c
-m32 -fdiagnostics-plain-output -maltivec -mno-vsx -S -o pr109932-1.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr109932-1.c:8:22:
error: '__int128' is not supported on this target
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr109932-1.c: In
function 'testVectorInt128Pack':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr109932-1.c:14:3:
note: use '-flax-vector-conversions' to permit conversions between vectors with
differing element types or numbers of subparts
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr109932-1.c:14:15:
error: incompatible types when assigning to type '__vector signed int' {aka
'__vector(4) int'} from type '__vector __int128' {aka '__vector(1)
'}
compiler exited with status 1

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #30)
> Now that I think again, I'm not even sure we would regress.
> My concern was that the data would remain NULL after the realloc(NULL, 0),
> and the argument would not be seen as present.  With the second temporary,
> all is well.

OK, I'll add that variant to the testcases.  Better safe than sorry... ;-)

> That's all there is.

OK, I'll then package it.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #32 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059435.html

[Bug c++/110231] New: unhelpful diagnostic when constructing through initializer_list

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

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

Bug ID: 110231
   Summary: unhelpful diagnostic when constructing through
initializer_list
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

#include 

struct Point {
int first;
int second;
};

struct Inner {
Inner(std::initializer_list);
};

Inner i = {{.x=1, .y=1}, {.x=2, .z=2}};

This is wrong, because I wrote .z=2 instead of .y=2. The error, even on trunk,
is:

:12:38: error: could not convert '{{1, 1}, {2, 2}}' from
'' to 'Inner'
   12 | Inner i = {{.x=1, .y=1}, {.x=2, .z=2}};
  |  ^
  |  |
  |  

This gives no indication of the problem is. 

Compare that to:

Point p = {.x=2, .z=2};

which fails with the quite clear message:

:17:22: error: 'Point' has no non-static data member named 'z'
   17 | Point p = {.x=2, .z=2};
  |  ^

Even the latter could be better - if the members were first and second and I
wrote frist, it just says no member named 'frist' instead of giving a hint, but
pointing to the specific problem is significantly better than... not.

[Bug c++/110231] unhelpful diagnostic when constructing through initializer_list

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||90475

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 90475.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90475
[Bug 90475] Diagnostic for designated initializer could be a lot better

[Bug modula2/110189] Using an unknown TYPE as argument to VAL gives ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-06-12
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Thanks for the bug report - I've reproduced the error and have a patch in
progress.