[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/114297] [14 Regression] Yet more problems with "definition in block does not dominate use in block"

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Let me have a look.

[Bug debug/113519] [14 regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r14-9423-g0c4df2c3c38ca15c123e9a801b617e63256c83a3
Author: Eric Botcazou 
Date:   Mon Mar 11 09:24:50 2024 +0100

Fix placement of recently implemented DIE

It's the DIE added for enumeration types with reverse scalar storage order.

gcc/
PR debug/113519
PR debug/113777
* dwarf2out.cc (gen_enumeration_type_die): In the reverse case,
generate the DIE with the same parent as in the regular case.

gcc/testsuite/
* gcc.dg/sso-20.c: New test.
* gcc.dg/sso-21.c: Likewise.

[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct and __attribute__((__hardbool__))

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

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

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

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

commit r14-9423-g0c4df2c3c38ca15c123e9a801b617e63256c83a3
Author: Eric Botcazou 
Date:   Mon Mar 11 09:24:50 2024 +0100

Fix placement of recently implemented DIE

It's the DIE added for enumeration types with reverse scalar storage order.

gcc/
PR debug/113519
PR debug/113777
* dwarf2out.cc (gen_enumeration_type_die): In the reverse case,
generate the DIE with the same parent as in the regular case.

gcc/testsuite/
* gcc.dg/sso-20.c: New test.
* gcc.dg/sso-21.c: Likewise.

[Bug debug/113519] [14 regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
.

[Bug debug/113777] ICE: in add_child_die_after, at dwarf2out.cc:5785 with -g -fsso-struct and __attribute__((__hardbool__))

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
.

[Bug middle-end/114299] ICE: SIGSEGV: in dyn_cast (is-a.h:282) with -mgeneral-regs-only and __bf16

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-11
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Confirmed.  We gimplify

D.2427 = VIEW_CONVERT_EXPR( VEC_PERM_EXPR < {v, { 0.0, 0.0, 0.0, 0.0 }} ,
{TARGET_EXPR >>>, { 0.0, 0.0, 0.0, 0.0 }} , { 1, 2, 9, 0,
1, 10, 10, 8 } > )

and as we gimplify_init_constructor we bail out leaving the half gimplified
expression as

_3 = {TARGET_EXPR , { 0.0, 0.0, 0.0, 0.0 }}

but up gimplify_stmt will not propagate the error further, in particular
the important caller internal_get_tmp_var has allocated the destination
SSA name but we failed to gimplify it's defintion.

I have a workaround.

[Bug c/93631] [11/12/13/14 Regression] ICE on an invalid strcmp call in gimple_call_arg, at gimple.h:3258

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

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

--- Comment #14 from Jakub Jelinek  ---
Seems r12-8017-g71770a0ea920641c53912f725f5abd4413b38fd5 fixed this.

[Bug ada/114300] ICE when compiling a program that instantiates a package with a nested ghost package

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE when compiling a|ICE when compiling a
   |program that instantiates a |program that instantiates a
   |package with a nested ghost |package with a nested ghost
   |package.|package
   Last reconfirmed||2024-03-11

[Bug ada/114300] ICE when compiling a program that instantiates a package with a nested ghost package

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

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

--- Comment #1 from Eric Botcazou  ---
This has never compiled apparently.

[Bug tree-optimization/114293] [14 Regression] ICE: in verify_range, at value-range.cc:1132 at -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Like in PR110603, there is UB and we need to pick at most one of
the bounds, not both of them as they are in conflict.

[Bug tree-optimization/111798] [14 Regression] Recent change causing testsuite regression and poor code on mcore-elf

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
OK, so the abort () call is only elided during RTL optimization before the
change.  The change itself first manifests during ESRA as

 void testK ()
 {
-   x$j;
   unsigned int D.1835;
   static unsigned int s = 1388815473;
   unsigned int D.1834;
@@ -167,14 +157,13 @@
   _5 = () _51;
   sK.k = _5;
   x = sK;
-  x$j_55 = sK.j;
   y$k_36 = sK.k;
   _37 = (unsigned char) y$k_36;
   _38 = (unsigned char) _46;
   _39 = _37 + _38;
   _40 = () _39;
   _41 = (unsigned int) _40;
-  _6 = x$j_55;
+  _6 = x.j;
   _7 = sK.j;
   if (_6 != _7)
 goto ; [INV]

there are other uses of 'x' below, unchanged:

  else
goto ; [INV]

   :
  _8 = BIT_FIELD_REF ;
  _9 = BIT_FIELD_REF ;
  _10 = _8 ^ _9;
  _11 = _10 & 64;
  if (_11 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  abort ();

and with the change we now analyze those and run into

! Disqualifying sK - Address taken in a non-call-argument context.
! Disqualifying x - No or inhibitingly overlapping accesses.


That's because fold somehow transformed one but not the other bitfield
compares.

In particular we have the following two accesses

_8 = BIT_FIELD_REF ;
_6 = x.j;

where the first is offset = 0, size = 8 and the second offset = 7, size = 10

and those partially overlap.  Previous to the change SRA was doing a
not profitable change in the end causing it to leave 'x' around.

The interesting difference is in FRE though where without the change we
are able to elide the _6 != _7 compare but with it we fail.  That's because
SRA makes the load of sK.j available - while VN can see through the
x = sK assignment it won't derive a value from the result unless there's
a leader for it in the IL.

Swapping the compare to

  if (sK.j != x.j || x.l != sK.l)
abort ();

makes it optimized and the abort () call vanishes as well - in fact it
now vanishes already in DOM2, much before RTL optimization.

I don't think the SRA change is to be blamed for doing anything wrong, we're
running into natural limitations of CSE and premature folding inhibiting
SRA (which the SRA change itself was supposed to handle a bit better).

When there's actual wrong-code now on mcore this is a latent problem
uncovered by the change.

The missed-optimization is yet another "dead code elimination regression".

I don't see an easy way to solve the missed-optimization regression.  On the
VN side, when we just see

  x = sK;
  _3 = x.j;
  _4 = sK.j;

then visiting the x.j load, when running into x = SK, could eventually
also put sK.j into the hash table (with the same VARYING value we assign
to x.j).  This would require some extra bookkeeping as we actually compute
this expression already but do not keep it as alternate form to record
when we figure there's no actual leader for it.  Testcase:

struct X { int a; int b; } p, o;
void foo ()
{
  p = o;
  if (p.a != o.a)
__builtin_abort ();
}

Let me take this for this particular VN issue.

[Bug tree-optimization/114278] ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32

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

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

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

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

commit r14-9424-gdbe5ccda4dbbd064c703cd3ab2a58ea40f08dd1a
Author: Jakub Jelinek 
Date:   Mon Mar 11 11:00:54 2024 +0100

bitint: Avoid rewriting large/huge _BitInt vars into SSA after bitint
lowering [PR114278]

The following testcase ICEs, because update-address-taken subpass of
fre5 rewrites
  _BitInt(128) b;
  vector(16) unsigned char _3;

   [local count: 1073741824]:
  _3 = MEM  [(char * {ref-all})p_2(D)];
  MEM  [(char * {ref-all})&b] = _3;
  b ={v} {CLOBBER(eos)};
to
  _BitInt(128) b;
  vector(16) unsigned char _3;

   [local count: 1073741824]:
  _3 = MEM  [(char * {ref-all})p_2(D)];
  b_5 = VIEW_CONVERT_EXPR<_BitInt(128)>(_3);
but we can't have large/huge _BitInt vars in SSA form after the bitint
lowering except for function arguments loaded from memory, as expansion
isn't able to deal with those, it relies on bitint lowering to lower
those operations.
The following patch fixes that by setting DECL_NOT_GIMPLE_REG_P for
large/huge _BitInt vars after bitint lowering, such that we don't
rewrite them into SSA form.

2024-03-11  Jakub Jelinek  

PR tree-optimization/114278
* tree-ssa.cc (maybe_optimize_var): If large/huge _BitInt vars are
no
longer addressable, set DECL_NOT_GIMPLE_REG_P on them.

* gcc.dg/bitint-99.c: New test.

[Bug tree-optimization/114278] ICE: in extract_bit_field_1, at expmed.cc:1838 with memmove, _BitInt() and -O2 -fno-tree-dce -fno-tree-dse -fno-tree-ccp -m32

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/114299] ICE: SIGSEGV: in dyn_cast (is-a.h:282) with -mgeneral-regs-only and __bf16

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

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

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

https://gcc.gnu.org/g:119f5ae0455f02568159eafa9008a555605e7d71

commit r14-9425-g119f5ae0455f02568159eafa9008a555605e7d71
Author: Richard Biener 
Date:   Mon Mar 11 09:35:07 2024 +0100

middle-end/114299 - missing error recovery from gimplify failure

When internal_get_tmp_var fails to gimplify the value the temporary
SSA name is supposed to be initialized with we can leak SSA names
with a NULL SSA_NAME_DEF_STMT into the IL.  That's bad, so recover
from this by instead returning a decl in that case.

PR middle-end/114299
* gimplify.cc (internal_get_tmp_var): When gimplification
of VAL failed, return a decl.

* gcc.target/i386/pr114299.c: New testcase.

[Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #12)
> So I think we could solve this with a bit of help from the alias oracle.  We
> have  the routine ptrs_compare_unequal, but points-to-null is going to get
> in the way.
> 
> I think VRP and DOM have enough information to rule out NULL for both
> objects in question.  So if we could query the points-to information,
> ignoring NULL then we could likely solve this particular bug.
> 
> Essentially VRP or DOM would prove NULL isn't in the set of possible values
> at the comparison point.  Then we query the alias information ignoring NULL.
> Voila we compute a static result for the comparison of the two pointers and
> the problematical block becomes unreachable and the bogus warning goes away.
> 
> Richi, any thoughts in viability of such an API?

We now treat pt.null conservatively and track non-null-ness derived from
range-info in it.  That means when VRP/DOM can prove a pointer is always
not NULL they can do set_ptr_nonnull (p) on it.

This means the

  /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
 but those require pt.null to be conservatively correct.  */

is no longer true and we could finally implement it, like with

diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index e7c1c1aa624..5b6d9e0aa6a 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -479,9 +479,25 @@ ptrs_compare_unequal (tree ptr1, tree ptr2)
}
   return !pt_solution_includes (&pi->pt, obj1);
 }
-
-  /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
- but those require pt.null to be conservatively correct.  */
+  else if (TREE_CODE (ptr1) == SSA_NAME)
+{
+  struct ptr_info_def *pi1 = SSA_NAME_PTR_INFO (ptr1);
+  if (!pi1
+ || pi1->pt.vars_contains_restrict
+ || pi1->pt.vars_contains_interposable)
+   return false;
+  if (integer_zerop (ptr2) && !pi1->pt.null)
+   return true;
+  if (TREE_CODE (ptr2) == SSA_NAME)
+   {
+ struct ptr_info_def *pi2 = SSA_NAME_PTR_INFO (ptr2);
+ if (!pi2
+ || pi2->pt.vars_contains_restrict
+ || pi2->pt.vars_contains_interposable)
+ if (!pi1->pt.null || !pi2->pt.null)
+   return !pt_solutions_intersect (&pi1->pt, &pi2->pt);
+   }
+}

   return false;
 }


but the testcase shows the non-null-ness is only conditional which means
we'd have to use a range query above which necessarily falls back to
the global ranges given we don't have any context available here.  The
old EVRP adjusted global ranges during the walk but this is no longer done.

Note it's enough that one pointer is nonnull, so for your idea the
API could be extended with a bool one_ptr_nonnull parameter.

[Bug middle-end/114299] ICE: SIGSEGV: in dyn_cast (is-a.h:282) with -mgeneral-regs-only and __bf16

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/114302] New: [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

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

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

Bug ID: 114302
   Summary: [14 Regression] GCN regressions after: vect: Tighten
vect_determine_precisions_from_range [PR113281]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

If my tracking/bisecting is to be believed, commit
r14-8492-g1a8261e047f7a2c2b0afb95716f7615cba718cd1 "vect: Tighten
vect_determine_precisions_from_range [PR113281]" is causing a few
'scan-assembler' regressions for GCN, for all '-march'es; see full list below. 
(No execution test regressions, so presumably not wrong-code.)  Due to lack of
knowledge of the relevant parts, I can't tell what needs to be adjusted.

For example, for '-march=gfx90a', 'gcc.target/gcn/simd-math-5-char-16.c' we get
before vs. after:

--- before/simd-math-5-char-16-march=gfx90a.s 2024-03-04
10:49:00.532961673 +0100
+++ after/simd-math-5-char-16-march=gfx90a.s  2024-03-04
11:02:31.409941756 +0100
@@ -269,18 +269,20 @@
v_addc_co_u32   v7, s[22:23], 0, v7, s[22:23]
flat_load_ubyte v16, v[6:7] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v16, sext(v16) src0_sel:BYTE_0
v_add_co_u32v4, s[22:23], s34, v1
v_mov_b32   v5, s35
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
flat_load_ubyte v17, v[4:5] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v17, sext(v17) src0_sel:BYTE_0
s_add_u32   s40, s14, 80
s_addc_u32  s41, s15, 0
s_getpc_b64 s[42:43]
s_add_u32   s42, s42, __divv16hi3@rel32@lo+4
s_addc_u32  s43, s43, __divv16hi3@rel32@hi+4
-   v_mov_b32_sdwa  v9, sext(v17) src0_sel:BYTE_0
-   v_mov_b32_sdwa  v8, sext(v16) src0_sel:BYTE_0
+   v_mov_b32   v9, v17
+   v_mov_b32   v8, v16
s_swappc_b64s[18:19], s[42:43]
s_mov_b64   exec, 65535
v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:WORD_0
@@ -291,12 +293,13 @@
s_add_u32   s38, s14, 64
s_addc_u32  s39, s15, 0
s_getpc_b64 s[44:45]
-   s_add_u32   s44, s44, __modv16qi3@rel32@lo+4
-   s_addc_u32  s45, s45, __modv16qi3@rel32@hi+4
-   v_mov_b32   v9, v17
-   v_mov_b32   v8, v16
+   s_add_u32   s44, s44, __modv16si3@rel32@lo+4
+   s_addc_u32  s45, s45, __modv16si3@rel32@hi+4
+   v_mov_b32_sdwa  v9, sext(v17) src0_sel:WORD_0
+   v_mov_b32_sdwa  v8, sext(v16) src0_sel:WORD_0
s_swappc_b64s[18:19], s[44:45]
s_mov_b64   exec, 65535
+   v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:DWORD
v_add_co_u32v4, s[22:23], s38, v1
v_mov_b32   v5, s39
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
@@ -334,8 +337,11 @@
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
flat_load_ubyte v9, v[4:5] offset:0
s_waitcnt   0
+   v_mov_b32_sdwa  v9, sext(v9) src0_sel:BYTE_0
+   v_mov_b32_sdwa  v8, sext(v8) src0_sel:BYTE_0
s_swappc_b64s[18:19], s[44:45]
s_mov_b64   exec, 65535
+   v_mov_b32_sdwa  v8, v8 dst_sel:BYTE_0 dst_unused:UNUSED_PAD
src0_sel:DWORD
v_add_co_u32v4, s[22:23], s42, v1
v_mov_b32   v5, s43
v_addc_co_u32   v5, s[22:23], 0, v5, s[22:23]
@@ -557,5 +563,5 @@
 .LEFDE0:
.globl  __modsi3
.globl  __divsi3
-   .globl  __modv16qi3
+   .globl  __modv16si3
.globl  __divv16hi3

Due to no registers getting renamed, that one is the smallest of all before vs.
after 'diff's; but is illustrative of what generally happens, as far as I can
tell.

Let me know if you'd like me to provide any artifacts.

Full list:

@@ -607,28 +607,28 @@ PASS: gcc.target/gcn/simd-math-5-char-16.c (test for
excess errors)
XFAIL: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divmod16.i4@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divv16hi3@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__divv16qi3@rel32@lo 0
[-PASS:-]{+FAIL:+} gcc.target/gcn/simd-math-5-char-16.c
scan-assembler-times __modv16qi3@rel32@lo 1
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__udivv16qi3@rel32@lo 0
PASS: gcc.target/gcn/simd-math-5-char-16.c scan-assembler-times
__umodv16qi3@rel3

[Bug c++/114303] New: ICE with constexpr if and static_assert accessing captures across nested generic lambdas

[benbarsdell at gmail dot com via Gcc-bugs]

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

Bug ID: 114303
   Summary: ICE with constexpr if and static_assert accessing
captures across nested generic lambdas
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benbarsdell at gmail dot com
  Target Milestone: ---

Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105788 but the
backtrace is different.

https://godbolt.org/z/xMPeTo633

Repros with the following versions on Godbolt:
14.0.1 ICE (gcc trunk on Godbolt)
13.2: ICE
13.1: ICE
12.3: ICE
12.2: OK
12.1: OK
11.4: ICE
11.3: OK


#include 

int main() {
auto foo = [](auto level1) {
return [&](auto ) {
return [&](auto level3) {
if constexpr (decltype(level3)::value) {
static_assert(decltype(level1)::value, "");
}
return 0;
}(std::integral_constant());
}(0);
}(std::integral_constant());
}


:8:17: internal compiler error: trying to capture 'level1' in
instantiation of generic lambda
8 | if constexpr (decltype(level3)::value) {
  | ^~
0x265eabc internal_error(char const*, ...)
???:0
0xb86956 add_capture(tree_node*, tree_node*, tree_node*, bool, bool, unsigned
int*)
???:0
0xb869d9 add_default_capture(tree_node*, tree_node*, tree_node*)
???:0
0x16c682c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x16c68a9 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xc75f26 build_extra_args(tree_node*, tree_node*, int)
???:0
0xcab766 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xc919b3 instantiate_decl(tree_node*, bool, bool)
???:0
0xb54725 maybe_instantiate_decl(tree_node*)
???:0
...

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41

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

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

--- Comment #54 from Jakub Jelinek  ---
Slightly adjusted #c41 testcase, which indeed still fails with my patch at -O2:

int d[100], c;

static __attribute__((noinline))
int foo (int x, unsigned int y)
{
  if (y > 30)
++c;
  return x + y;
}

static int
bar (unsigned int x)
{
  if (x > 100)
__builtin_unreachable ();
  if (__builtin_expect (d[x] != 0, 1))
return d[x];
  for (int j = 0; j < 100; j++)
d[x] += foo (d[j], x & 1 ? x + 17 : x + 16);
  return d[x];
}

static int
baz (unsigned int x)
{
  if (x > 10)
__builtin_unreachable ();
  if (__builtin_expect (d[x] != 0, 1))
return d[x];
  for (int j = 0; j < 100; j++)
d[x] += foo (d[j], x & 1 ? x + 17 : x + 16);
  return d[x];
}

int
main ()
{
  int r = baz (1) + baz (2) + baz (3) + bar (4) + bar (30);
  if (c != 100)
__builtin_abort ();
  return r;
}

I still think we want both my patch and some fix for the jump functions, not
just the latter.
Anyway, can we in the spot my patch changed just walk all source->node->callees
cgraph_edges, for each of them find the corresponding cgraph_edge in the alias
and for each walk all the jump_functions recorded and union their m_vr?
Or is that something that can't be done in LTO for some reason?

[Bug libfortran/114304] New: [14 Regression] Rejects lapack test

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

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

Bug ID: 114304
   Summary: [14 Regression] Rejects lapack test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see

[  208s] make[1]: Entering directory
'/home/abuild/rpmbuild/BUILD/lapack-3.9.0/TESTING'
[  208s] DGEBAL: Testing the balancing of a DOUBLE PRECISION general matrix
[  208s] ./EIG/xeigtstd < dbal.in > dbal.out 2>&1
[  208s] make[1]: *** [Makefile:427: dbal.out] Error 2

> cat dbal.out 
At line 119 of file dchkbl.f (unit = 5, file = 'stdin')
Fortran runtime error: Semicolon not allowed as separator with DECIMAL='point'

Error termination. Backtrace:
#0  0x7efcc2c38b42 in ???
#1  0x7efcc2c3961e in ???
#2  0x7efcc2c3a17f in ???
#3  0x7efcc2e8dc75 in ???
#4  0x7efcc2e906f1 in ???
#5  0x7efcc2e9144d in ???
#6  0x7efcc2e921aa in ???
#7  0x7efcc2e97a00 in ???
#8  0x55b5f7e0a993 in dchkbl_.constprop.0
at /home/abuild/rpmbuild/BUILD/lapack-3.9.0/TESTING/EIG/dchkbl.f:119

which does

  READ( NIN, FMT = * )( SCALIN( I ), I = 1, N )

and the input has at its end

  2.494800386918399765D+291  1.582914569427869018D+175 
1.004336277661868922D+59  3.186183822264904554D-58  5.053968264940243633D-175 
0.40083367200179455560D-291;

0

[Bug libfortran/114304] [14 Regression] Rejects lapack test

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #1 from Richard Biener  ---
I'm not sure it's desirable/valid to reject these?

[Bug c++/114305] New: GCC doesn't use [[gnu::pure]] attribute on the inline function

[khim at google dot com via Gcc-bugs]

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

Bug ID: 114305
   Summary: GCC doesn't use [[gnu::pure]] attribute on the inline
function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khim at google dot com
  Target Milestone: ---

The following program is an illustration (https://godbolt.org/z/PYW34ccvP):

#include 

GNU_PURE1 extern size_t foo(size_t);

template 
GNU_PURE2 inline size_t test() {
return foo(size);
}

int test_func(int x, int y) {
return test() + test();
}

If GNU_PURE1 is [[gnu::pure]] then both gcc and clang optimize away second
call, if GNU_PURE2 is [[gnu::pure]] then only clang does that.

That means that it's impossible to add [[gnu::pure]] optimization on top of
function that's pure according to the docs but is not declared as such in the
header file.

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

Dimitar Yordanov  changed:

   What|Removed |Added

 CC||dimitar.yordanov at sap dot com

--- Comment #3 from Dimitar Yordanov  ---
Hi,

what I can further add as a detail to the code below is that in the error case
"begin" is after "range[0]" as calculated by get_pc_range

-
void
__register_frame_info_bases (const void *begin, struct object *ob,
 void *tbase, void *dbase)
{
 .

  // Register the object itself to know the base pointer on deregistration.
  btree_insert (®istered_frames, (uintptr_type) begin, 1, ob);

  // Register the frame in the b-tree
  uintptr_type range[2];
  get_pc_range (ob, range);
  btree_insert (®istered_frames, range[0], range[1] - range[0], ob);
-

and pc_begin comes from the following with "((encoding & 0x70) ==
DW_EH_PE_pcrel" being true

-
static const unsigned char *
read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
  const unsigned char *p, _Unwind_Ptr *val)
{

case DW_EH_PE_sdata8:
  result = u->s8;
  p += 8;

result += ((encoding & 0x70) == DW_EH_PE_pcrel
 ? (_Unwind_Internal_Ptr) u : base);

-
E.g. u->s8 has a value of 0xe6f8 u 0x7fa7fc22f908 and with that
result 0x7fa7fc22e000 which is lower as the begin 0x7fa7fc22f160

[Bug libfortran/114304] [14 Regression] Rejects lapack test

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Richard Biener  ---
Has been long fixed upstream.  Guess it's to be expectd.

[Bug rtl-optimization/112560] [14 Regression] ICE in try_combine on pr112494.c

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #56705|0   |1
is obsolete||

--- Comment #5 from Uroš Bizjak  ---
Created attachment 57666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57666&action=edit
Proposed v2 patch

New version of patch in testing.

This version handles change of the mode of CC reg outside comparison. Now we
scan the RTX and change the mode of the CC reg at the proper place. We are
guaranteed by find_single_use that cc_use_loc can be non-NULL only when exactly
one user follows the combined comparison.

In case of unsupported cc_use_insn combine will be undone. To avoid combine
failure, pushfl2 in i386.md is changed to accept all MODE_CC modes.

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[tneumann at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #4 from Thomas Neumann  ---
It looks like the code does not find an unwind frame when de-registering an
exception handler. Are you sure that you do not de-register a dynamic frame
twice?

Otherwise I would need a way to reproduce the problem, ideally with a binary. I
am also fine with remote access if that is easier for you. Or if that is not
possible you might want to add printf calls to btree_insert and btree_remove,
tracing their call arguments. Having such a tracer should allow us to reproduce
the problem even without the host program.

(And it would allow for detecting duplicate de-registrations, i.e., errors in
the host program. I had that problem in the past myself with JITed code).

[Bug tree-optimization/47255] Missed CSE optimization with inline functions, and __attribute__((const))

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||khim at google dot com

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

[Bug middle-end/114305] GCC doesn't use [[gnu::pure]] attribute on the inline function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Keywords|missed-optimization |
 Status|UNCONFIRMED |RESOLVED

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

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

[Bug c/114306] New: wrong diagnostic with -Waddress (enabled by -Wall)

[jochen447 at concept dot de via Gcc-bugs]

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

Bug ID: 114306
   Summary: wrong diagnostic with -Waddress (enabled by -Wall)
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jochen447 at concept dot de
  Target Milestone: ---

Created attachment 57667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57667&action=edit
minified test case

The compiler option -Waddress erroneously reports a warning for the attached
simplified test case (warn_gcc.c):

$ gcc -Waddress warn_gcc.c -o warn_gcc
warn_gcc.c: In function ‘func’:
warn_gcc.c:17:49: warning: the comparison will always evaluate as ‘true’ for
the address of ‘value’ will never be NULL [-Waddress]
   17 | return (condA>0 ? cont->value : (int*)NULL) ? "foo" : "bar";
  | ^
warn_gcc.c:13:9: note: ‘value’ declared here
   13 | int value[1];
  | ^

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/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='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --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-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.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
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

$ uname -a
Linux linux64c 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1
(2024-02-01) x86_64 GNU/Linux

$ cat /etc/debian_version
12.5

[Bug modula2/114295] incorrect error location if attempting to compile implementation module without a definition module

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-03-11

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug c/114306] wrong diagnostic with -Waddress (enabled by -Wall)

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

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

--- Comment #1 from Andrew Pinski  ---
I think the warning is correct as:
(condA>0 ? cont->value : (int*)NULL)

Here cont->value can never be null due to c rules.

The above can be simplified to just

`condA>0` then. See pr 102967 too.

[Bug libfortran/114304] [14 Regression] Rejects lapack test

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---
 CC||burnus at gcc dot gnu.org,
   ||jvdelisle at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
I think the semicolon is not permitted as item separator but if I have as input
  '1.234 134.23 abc'
or likewise:
  '1.234, 134.23 abc'
and
  read (..., * ) x(1:2)

it works – i.e. only reading two floats and then stopping before reading 'abc'.

But if I do the very same but replace ' abc' by ' ;', I get the error, which
seems to be rather inconsistent — what's the difference between 'abc' and ';'
in this case?

* * *

The message is new since
  r14-9050-ga71d87431d0c4e
  libgfortran: [PR105473] Fix checks for decimal='comma'.

Jerry, can you check?

[Bug c/102555] missing -Waddress comparing &p[0] to zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-11

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

[Bug libfortran/114304] [14 Regression] Rejects lapack test

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

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

--- Comment #4 from Tobias Burnus  ---
Created attachment 57668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57668&action=edit
Testcase

Testresults of the attached testcase:
   See also https://godbolt.org/z/q4rG61EvW

The attached testcase shows with ifort and flang:
   1.234350   1243.240   13.24000 a
   1.234350   1243.240   13.24000 a
   1.234350   1243.240   13.24000
   1.234350   1243.240   13.24000
   1.234350   1243.240   13.24000 ;
   1.234350   1243.240   13.24000 ;

With GCC mainline:
   1.23434997   1243.23999   13.238 a
   1.23434997   1243.23999   13.238 a
Fortran runtime error: Semicolon not allowed as separator with DECIMAL='point'

With GCC 13 (and 4.9):
   1.23434997   1243.23999   13.238 a
   1.23434997   1243.23999   13.238 a
   1.23434997   1243.23999   13.238
   1.23434997   1243.23999   13.238
Fortran runtime error: End of file

[Bug c/114306] wrong diagnostic with -Waddress (enabled by -Wall)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of at least PR 105628 .

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

[Bug c/103360] [meta-bug] bogus/missing -Waddress

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

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

Bug 114306 Summary: wrong diagnostic with -Waddress (enabled by -Wall)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114306

   What|Removed |Added

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

[Bug c/105628] [12/13/14 Regression] False positive with -Waddress

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

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

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

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jroemmler at altair dot com

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

[Bug c/105628] [12/13/14 Regression] False positive with -Waddress

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
So it turns out the change for ?: to warn for -Waddress was done on purpose.
See PR 102967  . PR 102967  is about the wrong location for the warning and
such but it was originally about the same type of expression.

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

[Bug c/103360] [meta-bug] bogus/missing -Waddress

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

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

Bug 105628 Summary: [12/13/14 Regression] False positive with -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105628

   What|Removed |Added

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

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

--- Comment #5 from Dimitar Yordanov  ---
> It looks like the code does not find an unwind frame when de-registering an 
> exception handler

>From what I understand so far the issue is already there when doing the
registration. There is twice a call to btree_insert:

btree_insert (®istered_frames, (uintptr_type) begin, 1, ob);
btree_insert (®istered_frames, range[0], range[1] - range[0], ob);

for those, calls when "range[0]" is before "begin" with the same "ob" the next
search for removing will return the slot where range[0] is not the one of
begin. Because of the way "btree_node_find_leaf_slot" works, doing a 

if (n->content.entries[index].base + n->content.entries[index].size > value)

which is true for the second insert call even if we want to find the slot for
the first insert.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and static_assert accessing captures across nested generic lambdas

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||11.4.0, 12.3.0, 13.1.0
  Known to work||11.3.0, 12.1.0, 12.2.0
Summary|ICE with constexpr if and   |[11/12/13/14 Regression]
   |static_assert accessing |ICE with constexpr if and
   |captures across nested  |static_assert accessing
   |generic lambdas |captures across nested
   ||generic lambdas
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-11

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
struct a
{
  static constexpr int value = 1;
};

int main() {
[](auto level1) {
return [&](auto ) {
return [&](auto level3) {
if constexpr (decltype(level3)::value) {
static_assert(decltype(level1)::value, "");
}
return 0;
}(a{});
}(0);
}(a{});
}
```

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #32 from Tobias Burnus  ---
See PR114304 for an issue that was caused by the fix in comment 27.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

--- Comment #2 from Andrew Pinski  ---
Note the static_assert is not needed, it could just be
`decltype(level1)::value` even.

[Bug libfortran/114304] [14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[14 Regression] Rejects |[14 Regression] libgfortran
   |lapack test |I/O – bogus "Semicolon not
   ||allowed as separator with
   ||DECIMAL='point'"

--- Comment #5 from Tobias Burnus  ---
I just noticed that the change
  libgfortran: [PR105473] Fix checks for decimal='comma'.
got also backported to
  r13-8411-g7ecea49245bc6aeb6c889a4914961f94417f16e5 
on Thu Mar 7, 2024.

Thus, GCC 13 is now affected as well!

[Disclaimer: I have not checked the spec, but it seems very much like a
wrong-code bug.]

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

--- Comment #6 from Dimitar Yordanov  ---
Before the fix for PR 110956 there was just one btree_insert call for the same
"ob"

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[tneumann at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #7 from Thomas Neumann  ---
Is it correct that in your case range[0]

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

--- Comment #8 from Dimitar Yordanov  ---
yes

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[tneumann at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #9 from Thomas Neumann  ---
I will check how we can handle such a situation. But how did this happen to
begin with? Is this regular code or did you do anything special? I am puzzled
how the unwinding table can be placed like that.

[Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959

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

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

--- Comment #14 from Richard Biener  ---
gcc.c-torture/execute/pr64242.c is one of the testcases FAILing (guess it's
invalid)

[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

--- Comment #10 from Dimitar Yordanov  ---
Valid question. Seeing others hitting the same issue and looking at the
backtrace I would think it is not directly in our code but comes with the usage
LLVMs LLJIT

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[tneumann at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #11 from Thomas Neumann  ---
Created attachment 57669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57669&action=edit
patch to handle overlapping ranges

Does this patch fix the problem for you? I think it should, but I would really
like to have a reproducer to make sure.

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[dimitar.yordanov at sap dot com via Gcc-bugs]

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

--- Comment #12 from Dimitar Yordanov  ---
> Does this patch fix the problem for you?
yes. The failing testcase is successful after the change. I'll schedule more
tests.

[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-03-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
Right, this is documented as unimplemented at
https://en.cppreference.com/w/cpp/compiler_support although it should also be
added to
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2023

[Bug c++/110565] [11/12/13/14 Regression] Incomplete note on why initializing int& with int is ill-formed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
The diagnostic was changed by r5-601-gd02f620dc0bb3b

Author: Jason Merrill
Date:   Wed May 14 17:48:07 2014

re PR c++/20332 (poor diagnostic when bind non lvalue to a reference for
default arguments)

PR c++/20332
PR c++/21631
* call.c (reference_binding): Treat lvalue/rvalue mismatch and
dropped cv-quals as a bad conversion.
(convert_like_real) [ck_ref_bind]: Explain them.
(compare_ics): Check badness before stripping reference
bindings.  Handle comparing bad reference bindings.
* typeck.c (comp_cv_qualification): Add overload that just takes
integers.
* cp-tree.h: Declare it.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Started with r13-6452 (which has been backported to 11/12).

[Bug tree-optimization/114071] gcc.dg/vect/pr37027.c etc. FAIL

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug tree-optimization/113557] gcc.dg/vect/vect-multi-peel-gaps.c FAILs

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:4e1fcf44bdc582e71408175d75e025f5be8b0e55

commit r14-9428-g4e1fcf44bdc582e71408175d75e025f5be8b0e55
Author: Rainer Orth 
Date:   Mon Mar 11 15:46:30 2024 +0100

testsuite: vect: Require vect_hw_misalign in
gcc.dg/vect/vect-cost-model-1.c etc. [PR98238]

Several gcc.dg/vect/vect-cost-model-?.c tests FAIL on 32 and 64-bit
Solaris/SPARC:

FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-3.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-3.c scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-5.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-5.c scan-tree-dump vect "LOOP VECTORIZED"

The dumps show

   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:7:30:
note: ==> examining statement: _3 = *_2;
   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:7:30:
missed: unsupported unaligned access
   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:8:6:
missed: not vectorized: relevant stmt not supported: _3 = *_2;

so I think the tests need to require vect_hw_misalign.  This is what
this patch does.

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/98238
* gcc.dg/vect/vect-cost-model-1.c (scan-tree-dump): Also require
vect_hw_misalign.
* gcc.dg/vect/vect-cost-model-3.c: Likewise.
* gcc.dg/vect/vect-cost-model-5.c: Likewise.

[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|11.5|14.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47559.html

--- Comment #8 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug tree-optimization/114071] gcc.dg/vect/pr37027.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47558.html
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |14.0

--- Comment #3 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug tree-optimization/113557] gcc.dg/vect/vect-multi-peel-gaps.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47558.html
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL

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

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

--- Comment #18 from Rainer Orth  ---
SPARC testsuite failures fixed for GCC 14.0.1.

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

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

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

--- Comment #9 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 57648 [details]
> gcc14-pr111284.patch
> 
> So, I've tried to fix this by constexpr evaluating the arguments passed to
> PARM_DECLs with TREE_ADDRESSABLE types in the caller as lvalues rather than
> rvaluea and later, if we try to evaluate the PARM_DECL in the callee as lval,
> lookup the value and use that, if it is rval constexpr evaluate again as
> rvalue.
> There is a complication for qualified type, say if the argument is const in
> the callee and caller is passing reference to non-const, adjust_temp_type
> can't handle that when it isn't a rvalue.
Interesting, hopefully this fixes the std::string testcases in PR111258 and
related PRs?

And perhaps the following augmented testcase from this PR with a constexpr dtor
that checks valid():

void non_constant();

struct self_locator {
self_locator() = default;
constexpr self_locator(const self_locator&) noexcept : this_{this} {}
constexpr self_locator& operator=(const self_locator&) noexcept { return
*this; }

constexpr bool valid() const noexcept { return this_ == this; }
constexpr ~self_locator() { if (!valid()) non_constant(); }

self_locator *this_ = this;
};

constexpr bool demonstrator(self_locator x) noexcept
{
return x.valid();
}

static_assert(demonstrator(self_locator{}), "");
static_assert([](self_locator x){ return x.valid(); }(self_locator{}), "");

[Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #15 from Andrew Macleod  ---
(In reply to Richard Biener from comment #13)
> (In reply to Jeffrey A. Law from comment #12)
> > So I think we could solve this with a bit of help from the alias oracle.  We
> > have  the routine ptrs_compare_unequal, but points-to-null is going to get
> > in the way.
> > 
> > I think VRP and DOM have enough information to rule out NULL for both
> > objects in question.  So if we could query the points-to information,
> > ignoring NULL then we could likely solve this particular bug.
> > 
> > Essentially VRP or DOM would prove NULL isn't in the set of possible values
> > at the comparison point.  Then we query the alias information ignoring NULL.
> > Voila we compute a static result for the comparison of the two pointers and
> > the problematical block becomes unreachable and the bogus warning goes away.
> > 
> > Richi, any thoughts in viability of such an API?
> 
> We now treat pt.null conservatively and track non-null-ness derived from
> range-info in it.  That means when VRP/DOM can prove a pointer is always
> not NULL they can do set_ptr_nonnull (p) on it.
> 
> This means the
> 
>   /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
>  but those require pt.null to be conservatively correct.  */
> 
> is no longer true and we could finally implement it, like with
> 
> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
> index e7c1c1aa624..5b6d9e0aa6a 100644
> --- a/gcc/tree-ssa-alias.cc
> +++ b/gcc/tree-ssa-alias.cc
> @@ -479,9 +479,25 @@ ptrs_compare_unequal (tree ptr1, tree ptr2)
> }
>return !pt_solution_includes (&pi->pt, obj1);
>  }
> -
> -  /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
> - but those require pt.null to be conservatively correct.  */
> +  else if (TREE_CODE (ptr1) == SSA_NAME)
> +{
> +  struct ptr_info_def *pi1 = SSA_NAME_PTR_INFO (ptr1);
> +  if (!pi1
> + || pi1->pt.vars_contains_restrict
> + || pi1->pt.vars_contains_interposable)
> +   return false;
> +  if (integer_zerop (ptr2) && !pi1->pt.null)
> +   return true;
> +  if (TREE_CODE (ptr2) == SSA_NAME)
> +   {
> + struct ptr_info_def *pi2 = SSA_NAME_PTR_INFO (ptr2);
> + if (!pi2
> + || pi2->pt.vars_contains_restrict
> + || pi2->pt.vars_contains_interposable)
> + if (!pi1->pt.null || !pi2->pt.null)
> +   return !pt_solutions_intersect (&pi1->pt, &pi2->pt);
> +   }
> +}
>  
>return false;
>  }
> 
> 
> but the testcase shows the non-null-ness is only conditional which means
> we'd have to use a range query above which necessarily falls back to
> the global ranges given we don't have any context available here.  The
> old EVRP adjusted global ranges during the walk but this is no longer done.
> 
You mean it lied?  because x_1 is not NULL until after _8 = *x_1(D); executes. 
It can still be NULL on that stmt can it not?   Did it reset the global value
afterwards?

Contextually ranger knows both are non-null at EVRP time:
a.0_27 : [irange] int[0:D.] * [1, +INF]
2->3  (T) x_1(D) : [irange] int * [1, +INF]
2->3  (T) a.0_27 :  [irange] int[0:D.] * [1, +INF]
2->4  (F) x_1(D) : [irange] int * [1, +INF]
2->4  (F) a.0_27 :  [irange] int[0:D.] * [1, +INF]

So we know x_1 is non-NULL after the de-reference for the rest of the block
(and function).  It also sets a.0_27 globally to be [1, +INF].


> Note it's enough that one pointer is nonnull, so for your idea the
> API could be extended with a bool one_ptr_nonnull parameter.

ranger currently sets a.0 globally to be non-null in EVRP.

[Bug modula2/114295] incorrect error location if attempting to compile implementation module without a definition module

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:8410402272038aae7e4b2bd76df38607a78cad95

commit r14-9429-g8410402272038aae7e4b2bd76df38607a78cad95
Author: Gaius Mulley 
Date:   Mon Mar 11 15:21:42 2024 +

PR modula2/114295 Incorrect location if compiling implementation without
definition

This patch fixes a bug which occurred if gm2 was asked to compile an
implementation module and could not find the definition module.  The error
location would be set to the SYSTEM module.  The bug occurred as the
module sym was created during the peep phase after which the few tokens are
destroyed and recreated during parsing.  The bug fix is to call
PutDeclared when the module is encountered during parsing which updates
the tokenno associated with the module.

gcc/m2/ChangeLog:

PR modula2/114295
* gm2-compiler/M2Batch.mod (MakeProgramSource): Call PutDeclared
if the module is known.
(MakeDefinitionSource): Ditto.
(MakeImplementationSource): Ditto.
* gm2-compiler/M2Comp.mod (ExamineHeader): New procedure.
(ExamineCompilationUnit): Rewrite.
(PeepInto): Rewrite.
* gm2-compiler/M2Error.mod (NewError): Remove default call to
GetTokenNo.
* gm2-compiler/M2Quads.mod (callRequestDependant): Push tokno with
Adr.
(BuildStringAdrParam): Ditto.
(doBuildBinaryOp): Push OperatorPos on the bool stack.
(BuildRelOp): Ditto.
* gm2-compiler/P2Build.bnf (SetType): Pass set token pos to
BuildSetType.
(PointerType): Pass pointer token pos to BuildPointerType.
* gm2-compiler/P2SymBuild.def (BuildPointerType): Add parameter
pointerpos.
(BuildSetType): Add parameter setpos.
* gm2-compiler/P2SymBuild.mod (BuildPointerType): Add parameter
pointerpos.  Build combined token and use it when creating a
pointer type.
(BuildSetType): Add parameter setpos.  Build combined token and
use it when creating a set type.
* gm2-compiler/SymbolTable.mod (DebugUnknownToken): New constant.
(CheckTok): New procedure function.
(MakeProcedure): Call CheckTok.
(MakeRecord): Ditto.
(MakeVarient): Ditto.
(MakeEnumeration): Ditto.
(MakeHiddenType): Ditto.
(MakeConstant): Ditto.
(MakeConstStringCnul): Ditto.
(MakeSubrange): Ditto.
(MakeTemporary): Ditto.
(MakeVariableForParam): Ditto.
(MakeParameterHeapVar): Ditto.
(MakePointer): Ditto.
(MakeSet): Ditto.
(MakeUnbounded): Ditto.
(MakeProcType): Ditto.

Signed-off-by: Gaius Mulley 

[Bug modula2/114295] incorrect error location if attempting to compile implementation module without a definition module

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #3 from Gaius Mulley  ---
Closing now the patch has been applied.

[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r14-9430-gc27b30552e6cc789425d3628d294dafc5f3a0861
Author: Richard Earnshaw 
Date:   Wed Mar 6 13:41:02 2024 +

gomp: testsuite: improve compatibility of bad-array-section-3.c [PR113428]

This test generates different warnings on ilp32 targets because the size
of an integer matches the size of a pointer.  Avoid this by using
signed char.

gcc/testsuite:

PR testsuite/113428
* gcc.dg/gomp/bad-array-section-c-3.c: Use signed char instead
of int.

[Bug target/114307] New: [ARM] GCC generates instruction that assembler rejects

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

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

Bug ID: 114307
   Summary: [ARM] GCC generates instruction that assembler rejects
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

Recently added vectorization test "gcc.dg/vect/pr113576.c" fails to build for
arm-linux-gnueabihf with:
===
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-linux-gnueabihf-gcc
--sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/arm-linux-gnueabihf/libc
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/vect/pr113576.c
-fdiagnostics-plain-output -O3 -lm -o ./pr113576.exe
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'
compiler exited with status 1
output is:
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'

comp_output (pruned) is:
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'

FAIL: gcc.dg/vect/pr113576.c (test for excess errors)
===

The toolchain uses tip-of-trunk binutils for the build.

The relevant configure flags are: --with-float=hard --with-fpu=vfpv3-d16
--with-mode=thumb --with-tune=cortex-a9 --with-arch=armv7-a

Full configure options are at
https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-build/lastSuccessfulBuild/artifact/artifacts/notify/configure-make.txt/*view*/

[Bug fortran/114308] New: ICE in fold_convert_loc, at fold-const.cc:2627

[asiancorporator at yahoo dot de via Gcc-bugs]

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

Bug ID: 114308
   Summary: ICE in fold_convert_loc, at fold-const.cc:2627
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asiancorporator at yahoo dot de
  Target Milestone: ---

I am getting an error when I tried to extend an array that is supposed to
contain instances inherited from abstract classes. Ran on macOS Sonoma 14.2.1
(M1) with gfortran 13.2.1.

module my_module
  implicit none
  private

  type, abstract, public :: a
  end type

  type, extends(a), public :: b
  end type
end

program main
  use my_module
  implicit none

  class(a), allocatable :: a_array(:)
  type(b) :: b_instance

  a_array = [b_instance] ! This line works
  a_array = [a_array, b_instance] ! This one throws an ICE
end program

Output:

main.f90   failed.
[ 50%] Compiling...
app/main.f90:20:58:

   20 |   a_array = [a_array, b_instance] ! This one throws an ICE
  |  1
internal compiler error: in fold_convert_loc, at fold-const.cc:2627
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
 Compilation failed for object " app_main.f90.o "
 stopping due to failed compilation
STOP 1

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick O'Neill  ---
Fixed - Thank you!

[Bug middle-end/114198] [14] RISC-V fixed-length vector -flto ICE: in vectorizable_load, at tree-vect-stmts.cc:10570

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
Fixed!

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
It appears sched-deps is O(N*M) given N reg_pending_barriers and M distinct
pseudos in a region (or even a basic block). For instance, on the following
testcase

#define x10(x) x x x x x x x x x x
#define x100(x) x10(x10(x))
#define x1(x) x100(x100(x))

void f(int);

void g(int *p)
{
#if 1
x1(f(*p++);)
#else
x1(asm("" :: "r"(*p++));)
#endif
}

gcc -O -fschedule-insns invokes add_dependence 2 times for each asm/call
after the first. There is a loop

  for (i = 0; i < (unsigned)deps->max_reg; i++)
{
  struct deps_reg *reg_last = &deps->reg_last[i];
  reg_last->sets = alloc_INSN_LIST (insn, reg_last->sets);
  SET_REGNO_REG_SET (&deps->reg_last_in_use, i);
}

that registers the insn with reg_pending_barrier != 0 in reg_last->sets of each
pseudo, and then all those reg_last->sets will be inspected on the next
reg_pending_barrier insn.

[Bug middle-end/114198] [14] RISC-V fixed-length vector -flto ICE: in vectorizable_load, at tree-vect-stmts.cc:10570

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick O'Neill  ---
Fixed on tip-of-tree!

[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627

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

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

--- Comment #1 from Andrew Pinski  ---
GCC before 7 didn't support this feature:
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug libfortran/114304] [14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #6 from Tobias Burnus  ---
[For completeness: The LAPACK testsuite change Richard mentioned in comment 2
is
https://github.com/Reference-LAPACK/lapack/commit/64e8a7500d817869e5fcde35afd39af8bc7a8086
- That's for g95 and was applied 2020.]

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

[rzinsly at ventanamicro dot com via Gcc-bugs]

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

--- Comment #3 from Raphael M Zinsly  ---
Created attachment 57670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57670&action=edit
proposed patch

I created this patch using the approach Jeff mentioned, I tested and it fixes
this bug.

[Bug middle-end/111126] Not always using czero.eqz

[rzinsly at ventanamicro dot com via Gcc-bugs]

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

--- Comment #3 from Raphael M Zinsly  ---
Created attachment 57671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57671&action=edit
proposed patch

This is the same patch I posted in PR114277, it fixes this bug as well.

[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Earnshaw  ---
Fixed

[Bug c++/114309] New: Undesirable warning with [[unlikely]]

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 114309
   Summary: Undesirable warning with [[unlikely]]
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

g++ warns over the following program which uses [[unlikely]] for aborting error
reporting and conditionally chooses between two error messages:

# /usr/local/products/gcc/13.1.0/bin/g++ -O2 -c ttt-if-dual-unlikely.C
ttt-if-dual-unlikely.C: In function ‘void if_dual_warning(int)’:
ttt-if-dual-unlikely.C:3:19: warning: both branches of ‘if’ statement marked as
‘unlikely’ [-Wattributes]
3 | #define barf(msg) [[unlikely]] crash(msg)
  |   ^~~~
ttt-if-dual-unlikely.C:22:5: note: in expansion of macro ‘barf’
   22 | barf("foo");
  | ^~~~

g++ is correct that both branches have [[unlikely]].  What is not correct is to
warn over it.  g++ should instead simply infer that the second "if" is itself
unlikely to be reached.

The standard, quoted from
https://en.cppreference.com/w/cpp/language/attributes/likely, clearly
contemplates this case:

"Applies to a statement to allow the compiler to optimize for the case where
paths of execution including that statement are less likely than any
alternative path of execution that does not include such a statement."

Note that the standard expressions itself in terms of "paths of execution"
whereas g++ appears to have a narrower "branches of `if'" world view.  I am not
sure whether that's relevant.

Issuing this warning is a made a bit worse by the lack of a simple, local way
to suppress the warning in the same way that "if ((var = val)) { ... }" is a
way to suppress the warning about assignment in condition.


# cat ttt-if-dual-unlikely.C
#include 

#define barf(msg) [[unlikely]] crash(msg)

void
crash (const char*msg)
{
  std::cerr << msg << std::endl;
  abort ();
}


void
if_dual_warning (int i)
{
  bool runtime_cond0 = i > 0;
  bool runtime_cond1 = i > 1;

  if (runtime_cond0) {
std::cerr << "Something\n";
  } else if (runtime_cond1) {
barf("foo");
  } else {
barf("bar");
  }
}

[Bug middle-end/111126] Not always using czero.eqz

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Raphael M Zinsly from comment #3)
> Created attachment 57671 [details]
> proposed patch
> 
> This is the same patch I posted in PR114277, it fixes this bug as well.

The question is which is more Canonical on gimple. the multiply or the
cond_expr.
I say the multiply.

Since the multiply is.
then  you just need to add the case to 
"/* Expand X*Y as X&-Y when Y must be zero or one.  */"
instead in expr.cc.

Though it does some costing which also needs/should be handled too.

[Bug c++/114309] Undesirable warning with [[unlikely]]

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #1 from M Welinder  ---
Created attachment 57672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57672&action=edit
Preprocessed source code

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #2 from Andrew Pinski  ---
The warning was added when this attribute was added in r9-4186-g2674fa47de9ecf
and even added a testcase for this warning g++.dg/cpp2a/attr-likely4.C .

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-11
 Ever confirmed|0   |1

--- Comment #7 from Jerry DeLisle  ---
I suppose we can put this error behind a -std= option. Just my luck it is
discovered right after I backport to 13. The semi-colon in this case is
intended to indicate the end of the line I think.

I will have to did through the standards a but.  If one is desperate to fix
this and we need to revert on 13, let me know.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510776.html

```
Would you please consider an error diagnostics for situations written in
test4.C?
Such situation is then silently ignored in profile_estimate pass:

Predictions for bb 2
  hot label heuristics of edge 2->4 (edge pair duplicate): 85.00%
  hot label heuristics of edge 2->3 (edge pair duplicate): 85.00%
```

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I think the warning is very much desirable.  It is not an error, just a warning
that the code does something weird.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #5 from Andrew Pinski  ---
Speficially this email:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/511208.html

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Raphael M Zinsly from comment #3)
> Created attachment 57670 [details]
> proposed patch
> 
> I created this patch using the approach Jeff mentioned, I tested and it
> fixes this bug.

As I mentioned in the other issue, there is an open question about which is
more Canonical.

I don't have this one listed on
https://gcc.gnu.org/wiki/GimpleCanonical#preview yet but I will add it. Because
there are 3 different ways of representing it.

[Bug target/114307] [ARM] GCC generates instruction that assembler rejects

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
>From a full assembler dump:

.syntax divided
@ 71 "/home/rearnsha/gnusrc/gcc/master/gcc/testsuite/gcc.dg/vect/tree-vect.h" 1
vorr d6, d6, d7
@ 0 "" 2
.arm
.syntax unified

So this is a problem with the test; it shouldn't be enabled for this target.

[Bug target/114307] [ARM] GCC generates instruction that assembler rejects

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

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

--- Comment #2 from Richard Earnshaw  ---
Note that it's clear from the .syntax markers that this is inline assembler
that's the source of the invalid instructions.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> I think the warning is very much desirable.  It is not an error, just a
> warning that the code does something weird.

Maybe it should have its own enable/disable and not tied to -Wattribute though.

[Bug middle-end/111126] Not always using czero.eqz

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

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

--- Comment #5 from Jeffrey A. Law  ---
Multiply as a canonical form of a conditional move/zero seems fairly
non-obvious relative to a conditional expression.

But I don't mind going with consensus on a canonical form.  After all we just
need to define one.

The bigger question is fixing the expansion.

We can expand as a multiply, x&-y or with a conditional-move like sequence.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #7 from Andrew Pinski  ---
Also this works just fine to disable the warning around the unlikely:
#define push_warning _Pragma("GCC diagnostic push")
#define pop_warning _Pragma("GCC diagnostic pop")
#define disable_warning _Pragma("GCC diagnostic ignored  \"-Wattributes\"")

#define barf(msg) do { push_warning disable_warning [[unlikely]] crash(msg);
pop_warning } while(0)

[Bug c/114310] New: [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

[p.nguyen at yahooinc dot com via Gcc-bugs]

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

Bug ID: 114310
   Summary: [aarch64] __sync_val_compare_and_swap fails on
__int128_t with newval = 0
   Product: gcc
   Version: 8.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.nguyen at yahooinc dot com
  Target Milestone: ---

I am encountering a compiler error when __sync_val_compare_and_swap is passed
__int128_t types and newval = 0. It does not occur when newval is not zero, or
a const volatile variable with the value of 0 is passed to it. This only fails
when using built-in aarch64 LSE instructions, enabled with -march=armv8.1-a or
greater. It does not have problems with -march=armv8-a. 

I have been able to replicate the issue on GCC 8.5.0, 10.3.1, 11.2.1, 11.4.0,
12.2.1 and 13.1.1 on linux-aarch64. 

I have attached a trivial test case, and also have a small result set on
godbolt: https://godbolt.org/z/ex9adPTPc

I am showing the output from Ubuntu 22.04.4 LTS with gcc 11.4.0

The command line options are: gcc -v -march=armv8.1-a -save-temps test.c

The complete compiler output is: 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --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-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
COLLECT_GCC_OPTIONS='-v' '-march=armv8.1-a' '-save-temps' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'a-'
 /usr/lib/gcc/aarch64-linux-gnu/11/cc1 -E -quiet -v -imultiarch
aarch64-linux-gnu test.c -march=armv8.1-a -mlittle-endian -mabi=lp64
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -o a-test.i
ignoring nonexistent directory "/usr/local/include/aarch64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/aarch64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/aarch64-linux-gnu/11/include
 /usr/local/include
 /usr/include/aarch64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-march=armv8.1-a' '-save-temps' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'a-'
 /usr/lib/gcc/aarch64-linux-gnu/11/cc1 -fpreprocessed a-test.i -quiet -dumpdir
a- -dumpbase test.c -dumpbase-ext .c -march=armv8.1-a -mlittle-endian
-mabi=lp64 -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -o a-test.s
GNU C17 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (aarch64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (aarch64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 52ed857e9cd110e5efaa797811afcfbb
test.c: In function ‘main’:
test.c:6:1: error: unrecognizable insn:
6 | }
  | ^
(insn 12 11 13 2 (parallel [
(set (reg:TI 92 [ _1 ])
(mem/v:TI (reg:DI 99) [-1  S16 A128]))
(set (mem/v:TI (reg:DI 99) [-1  S16 A128])
(unspec_volatile:TI [
(reg:TI 92 [ _1 ])
(const_int 0 [0])
(const_int 32773 [0x8005])
] UNSPECV_ATOMIC_CMPSW))
]) "test.c":4:31 -1
 (nil))
during RTL pass: vregs
test.c:6:1: internal compiler error: in extract_insn, at recog.c:2770
0xaeb1c7 internal_

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Also this works just fine to disable the warning around the unlikely:
> #define push_warning _Pragma("GCC diagnostic push")
> #define pop_warning _Pragma("GCC diagnostic pop")
> #define disable_warning _Pragma("GCC diagnostic ignored  \"-Wattributes\"")
> 
> #define barf(msg) do { push_warning disable_warning [[unlikely]] crash(msg);
> pop_warning } while(0)

Actually you don't even need the push/pop/disable.

This is enough to disable the warning:

#define barf(msg) do {  [[unlikely]] crash(msg); } while(0)

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Note, if all you want is just to avoid the -Wuninitialized warnings for Rust
copies from uninitialized, just wrap the memcpy into some noipa wrapper, then
the compiler won't know whether the data isn't initialized in there etc.
Or set no warning flag on the unitialized var (but that will turn off that
warning on all uses).

[Bug c++/109966] [13/14 Regression] ICE in gimplify_var_or_parm_decl, à gimplify.cc:3058

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

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

--- Comment #6 from Marek Polacek  ---
This looks like a failure of potential_prvalue_result_of to notice that there's
copy elision taking place (when initializing a field of the array arr).