[Bug c/107244] New: error: invalid position or size in ‘bit_insert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107244
   Summary: error: invalid position or size in ‘bit_insert_expr’
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, recent gcc trunk does this:

$ /home/dcb/gcc/results/bin/gcc -c -w -O2 bug856.c 2>&1 | more
apply.c: In function ‘unleash_all’:
apply.c:582:1: error: invalid position or size in ‘bit_insert_expr’
_ifc__16 = BIT_INSERT_EXPR <_ifc__2, 0, 0xffab (1
bi
ts)>;
during GIMPLE pass: ifcvt
apply.c:582:1: internal compiler error: verify_gimple failed

[Bug tree-optimization/107244] error: invalid position or size in ‘bit_insert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
The bug first seems to occur sometime between git hash 248c8aeebc49aae3
and 637e3668fdc17c4e, a day later.

Reduction running now.

[Bug tree-optimization/107244] [13 Regression] error: invalid position or size in ‘bit_insert_expr’ since r13-3219-g25413fdb2ac24933

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||andre.simoesdiasvieira@arm.
   ||com, marxin at gcc dot gnu.org
   Last reconfirmed||2022-10-13
 Ever confirmed|0   |1
Summary|error: invalid position or  |[13 Regression] error:
   |size in ‘bit_insert_expr’   |invalid position or size in
   ||‘bit_insert_expr’ since
   ||r13-3219-g25413fdb2ac24933

--- Comment #2 from Martin Liška  ---
Started with r13-3219-g25413fdb2ac24933.

[Bug tree-optimization/107244] [13 Regression] error: invalid position or size in ‘bit_insert_expr’ since r13-3219-g25413fdb2ac24933

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

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat pr107244.c
typedef char xchar;
struct monst {
  struct monst *nmon;
  short movement;
  char malign;
  xchar mx, my;
  unsigned : 7;
  unsigned : 7;
  unsigned : 11;
  unsigned mleashed : 1;
} *level_0, *unleash_all_mtmp;

void
unleash_all() {
  for (; unleash_all_mtmp; unleash_all_mtmp = level_0)
unleash_all_mtmp->mleashed = 0;
}

[Bug tree-optimization/107244] [13 Regression] error: invalid position or size in ‘bit_insert_expr’ since r13-3219-g25413fdb2ac24933

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

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

--- Comment #4 from Martin Liška  ---
Likely dup of PR107229.

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #26 from rguenther at suse dot de  ---
On Tue, 11 Oct 2022, jan.zizka at nokia dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
> 
> --- Comment #25 from Jan ?i?ka  ---
> I have backported all three patches but true that I didn't try to test without
> VN enhancement. Would it help if I'd try that with our production code and the
> reproducers? Or anything else I could try so that you'd know if the VM
> enhancement should be backported also?

They are clearly necessary to fix this bug.  What I'm unsure yet about
is the risk of generally enhancing VN for this diagnostic regression.
The enhancement itself is quite small and self-contained which is
why I'm still considering it ;)

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #24 from Uroš Bizjak  ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> Now I got more confused.

CCCmode means that single flag is tested, it uses EQ and NE, so "c" and "nc"
suffix is emitted. When CCmode is used, LTU/GEU operation on CCmode flags reg
produces "b" and "nb" suffix, which decodes to exactly the same assembly as "c"
and "nc" suffixes.

However, it looks that somewhere LTU/GEU is also generated with CCCmode flags
reg, and some fixup was introduced to put_condition_code to "fix" this
inconsistency. If LTU/GEU is valid only for CCmode, then the producers of
invalid RTX should be fixed.

[Bug modula2/107245] New: calling makeinfo with --no-headers produces invalid info files

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

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

Bug ID: 107245
   Summary: calling makeinfo with --no-headers produces invalid
info files
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

gcc/m2/Make-lang.in calls makeinfo with --no-headers and produces invalid info
files, which cannot be used within emacs or the with the info program.

[Bug c/107246] New: gcc trunk crash in verify_gimple_in_cfg

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107246
   Summary: gcc trunk crash in verify_gimple_in_cfg
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7c059880fca175589efc8e06ef458020a005658d/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7c059880fca175589efc8e06ef458020a005658d
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% gcc-tk -w -O0 a.c
%
% gcc-tk -w -O3 a.c
a.c: In function ‘e’:
a.c:8:1: error: invalid position or size operand to ‘bit_field_ref’
8 | e() {
  | ^
_ifc__16 = BIT_FIELD_REF <_ifc__15, 12, 0xffc0>;
during GIMPLE pass: ifcvt
a.c:8:1: internal compiler error: verify_gimple failed
0x205825e internal_error(char const*, ...)
???:0
0x10890f1 verify_gimple_in_cfg(function*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
%
% cat a.c
struct {
  long a;
  signed : 9;
  signed : 30;
  unsigned b : 12
} c;
d;
e() {
  for (; d;)
f(c.b);
}
%

Compiler explorer: https://godbolt.org/z/8aGhfE5PM

[Bug tree-optimization/107229] [13 Regression] ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed since r13-3219-g25413fdb2ac24933

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

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

--- Comment #4 from Martin Liška  ---
*** Bug 107246 has been marked as a duplicate of this bug. ***

[Bug c/107246] gcc trunk crash in verify_gimple_in_cfg

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug tree-optimization/107226] [13 regression] r13-3219-g25413fdb2ac249 caused a lot of testcase failures

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

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

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

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

commit r13-3268-g7f9a7465c863e482708d2a00f5f7ff91ae3a7e0b
Author: Andre Vieira 
Date:   Thu Oct 13 10:34:27 2022 +0100

vect: Don't pattern match BITFIELD_REF's of non-integrals [PR107226]

The original patch supported matching the vect_recog_bitfield_ref_pattern
for
BITFIELD_REF's where the first operand didn't have a INTEGRAL_TYPE_P type.
That means it would also match vectors, leading to regressions in targets
that
supported vectorization of those.

gcc/ChangeLog:

PR tree-optimization/107226
* tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern): Reject
BITFIELD_REF's with non integral typed first operands.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #7 from Kewen Lin  ---

One reduced test case is:



#include 
#include 

#define N 128
float fl[N];

__attribute__ ((noipa, optimize (0))) void
init ()
{
  for (int i = 0; i < N; i++)
fl[i] = i;
}

__attribute__ ((noipa)) float
foo (int n1)
{
  float sum0, sum1, sum2, sum3;
  sum0 = sum1 = sum2 = sum3 = 0.0f;

  int n = (n1 / 4) * 4;
  for (int i = 0; i < n; i += 4)
{
  sum0 += fabs (fl[i]);
  sum1 += fabs (fl[i + 1]);
  sum2 += fabs (fl[i + 2]);
  sum3 += fabs (fl[i + 3]);
}

  return sum0 + sum1 + sum2 + sum3;
}

__attribute__ ((optimize (0))) int
main ()
{
  init ();
  float res = foo (80);
  __builtin_printf ("res:%f\n", res);
  return 0;
}

 
incorrect result "res:670.00" vs expected result "res:3160.00"

It looks it exposes one bug in vectorization reduction support. The reduction
epilogue handling looks wrong, it generates gimple code like:

# vect_sum3_31.16_101 = PHI 
# vect_sum3_31.16_102 = PHI 
# vect_sum3_31.16_103 = PHI 
# vect_sum3_31.16_104 = PHI 
_105 = BIT_FIELD_REF ;
_106 = BIT_FIELD_REF ;
_107 = BIT_FIELD_REF ;
_108 = BIT_FIELD_REF ;
_109 = BIT_FIELD_REF ;
_110 = BIT_FIELD_REF ;
_111 = BIT_FIELD_REF ;
_112 = BIT_FIELD_REF ;
...

it doesn't consider the reduced results vect_sum3_31.16_10{1,2,3,4} from the
loop can be reduced again in loop exit block as they are in the same slp group.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Kewen Lin from comment #7)
> One reduced test case is:
> 
> 
> 
> #include 
> #include 
> 
> #define N 128
> float fl[N];
> 
> __attribute__ ((noipa, optimize (0))) void
> init ()
> {
>   for (int i = 0; i < N; i++)
> fl[i] = i;
> }
> 
> __attribute__ ((noipa)) float
> foo (int n1)
> {
>   float sum0, sum1, sum2, sum3;
>   sum0 = sum1 = sum2 = sum3 = 0.0f;
> 
>   int n = (n1 / 4) * 4;
>   for (int i = 0; i < n; i += 4)
> {
>   sum0 += fabs (fl[i]);
>   sum1 += fabs (fl[i + 1]);
>   sum2 += fabs (fl[i + 2]);
>   sum3 += fabs (fl[i + 3]);
> }
> 
>   return sum0 + sum1 + sum2 + sum3;
> }
> 
> __attribute__ ((optimize (0))) int
> main ()
> {
>   init ();
>   float res = foo (80);
>   __builtin_printf ("res:%f\n", res);
>   return 0;
> }
> 
>  
> incorrect result "res:670.00" vs expected result "res:3160.00"
> 
> It looks it exposes one bug in vectorization reduction support. The
> reduction epilogue handling looks wrong, it generates gimple code like:
> 
> # vect_sum3_31.16_101 = PHI 
> # vect_sum3_31.16_102 = PHI 
> # vect_sum3_31.16_103 = PHI 
> # vect_sum3_31.16_104 = PHI 
> _105 = BIT_FIELD_REF ;
> _106 = BIT_FIELD_REF ;
> _107 = BIT_FIELD_REF ;
> _108 = BIT_FIELD_REF ;
> _109 = BIT_FIELD_REF ;
> _110 = BIT_FIELD_REF ;
> _111 = BIT_FIELD_REF ;
> _112 = BIT_FIELD_REF ;
> ...
> 
> it doesn't consider the reduced results vect_sum3_31.16_10{1,2,3,4} from the
> loop can be reduced again in loop exit block as they are in the same slp
> group.

The above doesn't look wrong (but may miss the rest of the IL).  On
x86_64 this looks like

   [local count: 105119324]:
  # sum0_41 = PHI 
  # sum1_39 = PHI 
  # sum2_37 = PHI 
  # sum3_35 = PHI 
  # vect_sum3_31.11_59 = PHI 
  _58 = BIT_FIELD_REF ;
  _57 = BIT_FIELD_REF ;
  _56 = BIT_FIELD_REF ;
  _55 = BIT_FIELD_REF ;
  _74 = _58 + _57;
  _76 = _56 + _74;
  _78 = _55 + _76;

   [local count: 118111600]:
  # prephitmp_79 = PHI <_78(4), 0.0(2)>
  return prephitmp_79;

when unrolling is applied, thus with a larger VF, you should ideally
see the vectors accumulated.

Btw, I've fixed a SLP reduction issue two days ago in r13-3226-gee467644c53ee2
though that looks unrelated?

When I force a larger VF on x86 by adding a int store in the loop I see

   [local count: 94607391]:
  # sum0_48 = PHI 
  # sum1_36 = PHI 
  # sum2_35 = PHI 
  # sum3_24 = PHI 
  # vect_sum3_32.16_110 = PHI 
  # vect_sum3_32.16_111 = PHI 
  # vect_sum3_32.16_112 = PHI 
  # vect_sum3_32.16_113 = PHI 
  _114 = BIT_FIELD_REF ;
  _115 = BIT_FIELD_REF ;
  _116 = BIT_FIELD_REF ;
  _117 = BIT_FIELD_REF ;
  _118 = BIT_FIELD_REF ;
  _119 = BIT_FIELD_REF ;
  _120 = BIT_FIELD_REF ;
  _121 = BIT_FIELD_REF ;
  _122 = BIT_FIELD_REF ;
  _123 = BIT_FIELD_REF ;
  _124 = BIT_FIELD_REF ;
  _125 = BIT_FIELD_REF ;
  _126 = BIT_FIELD_REF ;
  _127 = BIT_FIELD_REF ;
  _128 = BIT_FIELD_REF ;
  _129 = BIT_FIELD_REF ;
  _130 = _114 + _118;
  _131 = _115 + _119;
  _132 = _116 + _120;
  _133 = _117 + _121;
  _134 = _130 + _122;
  _135 = _131 + _123;
  _136 = _132 + _124;
  _137 = _133 + _125;
  _138 = _134 + _126;

see how the lanes from the different vectors are accumulated?  (yeah,
we should simply add the vectors!)

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #9 from Kewen Lin  ---
> 
> The above doesn't look wrong (but may miss the rest of the IL).  On
> x86_64 this looks like
> 
>[local count: 105119324]:
>   # sum0_41 = PHI 
>   # sum1_39 = PHI 
>   # sum2_37 = PHI 
>   # sum3_35 = PHI 
>   # vect_sum3_31.11_59 = PHI 
>   _58 = BIT_FIELD_REF ;
>   _57 = BIT_FIELD_REF ;
>   _56 = BIT_FIELD_REF ;
>   _55 = BIT_FIELD_REF ;
>   _74 = _58 + _57;
>   _76 = _56 + _74;
>   _78 = _55 + _76;
> 
>[local count: 118111600]:
>   # prephitmp_79 = PHI <_78(4), 0.0(2)>
>   return prephitmp_79;
> 

Yeah, it looks expected without unrolling.

> when unrolling is applied, thus with a larger VF, you should ideally
> see the vectors accumulated.
> 
> Btw, I've fixed a SLP reduction issue two days ago in
> r13-3226-gee467644c53ee2
> though that looks unrelated?

Thanks for the information, I'll double check it.

> 
> When I force a larger VF on x86 by adding a int store in the loop I see
> 
>[local count: 94607391]:
>   # sum0_48 = PHI 
>   # sum1_36 = PHI 
>   # sum2_35 = PHI 
>   # sum3_24 = PHI 
>   # vect_sum3_32.16_110 = PHI 
>   # vect_sum3_32.16_111 = PHI 
>   # vect_sum3_32.16_112 = PHI 
>   # vect_sum3_32.16_113 = PHI 
>   _114 = BIT_FIELD_REF ;
>   _115 = BIT_FIELD_REF ;
>   _116 = BIT_FIELD_REF ;
>   _117 = BIT_FIELD_REF ;
>   _118 = BIT_FIELD_REF ;
>   _119 = BIT_FIELD_REF ;
>   _120 = BIT_FIELD_REF ;
>   _121 = BIT_FIELD_REF ;
>   _122 = BIT_FIELD_REF ;
>   _123 = BIT_FIELD_REF ;
>   _124 = BIT_FIELD_REF ;
>   _125 = BIT_FIELD_REF ;
>   _126 = BIT_FIELD_REF ;
>   _127 = BIT_FIELD_REF ;
>   _128 = BIT_FIELD_REF ;
>   _129 = BIT_FIELD_REF ;
>   _130 = _114 + _118;
>   _131 = _115 + _119;
>   _132 = _116 + _120;
>   _133 = _117 + _121;
>   _134 = _130 + _122;
>   _135 = _131 + _123;
>   _136 = _132 + _124;
>   _137 = _133 + _125;
>   _138 = _134 + _126;
> 
> see how the lanes from the different vectors are accumulated?  (yeah,
> we should simply add the vectors!)

Yes, it's the same as what I saw on ppc64le, but the closely following dce6
removes the three vect_sum3_32 (in your dump, they are
vect_sum3_32.16_10{7,8,9}) as the subsequent joints don't actually use the
separated accumulated lane values (_138 -> sum0 ...) but only use
vect_sum3_32.16_110.

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #27 from Jan Žižka  ---
(In reply to rguent...@suse.de from comment #26)
> 
> They are clearly necessary to fix this bug.  What I'm unsure yet about
> is the risk of generally enhancing VN for this diagnostic regression.
> The enhancement itself is quite small and self-contained which is
> why I'm still considering it ;)

Understood. And I didn't report this, maybe I should have, with these
fixes we had another uninitialized value warning ... it was actually bug
so I did fix it ... but the interesting was that same/similar bug was
couple lines below and this one the compiler didn't complain about.
I'm not sure if all that could be related to your considerations but
if it would help I could create a reproducer for this particular case.
I guess it is false negative :-) of some sorts.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 13 Oct 2022, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
> 
> --- Comment #9 from Kewen Lin  ---
> > 
> > The above doesn't look wrong (but may miss the rest of the IL).  On
> > x86_64 this looks like
> > 
> >[local count: 105119324]:
> >   # sum0_41 = PHI 
> >   # sum1_39 = PHI 
> >   # sum2_37 = PHI 
> >   # sum3_35 = PHI 
> >   # vect_sum3_31.11_59 = PHI 
> >   _58 = BIT_FIELD_REF ;
> >   _57 = BIT_FIELD_REF ;
> >   _56 = BIT_FIELD_REF ;
> >   _55 = BIT_FIELD_REF ;
> >   _74 = _58 + _57;
> >   _76 = _56 + _74;
> >   _78 = _55 + _76;
> > 
> >[local count: 118111600]:
> >   # prephitmp_79 = PHI <_78(4), 0.0(2)>
> >   return prephitmp_79;
> > 
> 
> Yeah, it looks expected without unrolling.
> 
> > when unrolling is applied, thus with a larger VF, you should ideally
> > see the vectors accumulated.
> > 
> > Btw, I've fixed a SLP reduction issue two days ago in
> > r13-3226-gee467644c53ee2
> > though that looks unrelated?
> 
> Thanks for the information, I'll double check it.
> 
> > 
> > When I force a larger VF on x86 by adding a int store in the loop I see
> > 
> >[local count: 94607391]:
> >   # sum0_48 = PHI 
> >   # sum1_36 = PHI 
> >   # sum2_35 = PHI 
> >   # sum3_24 = PHI 
> >   # vect_sum3_32.16_110 = PHI 
> >   # vect_sum3_32.16_111 = PHI 
> >   # vect_sum3_32.16_112 = PHI 
> >   # vect_sum3_32.16_113 = PHI 
> >   _114 = BIT_FIELD_REF ;
> >   _115 = BIT_FIELD_REF ;
> >   _116 = BIT_FIELD_REF ;
> >   _117 = BIT_FIELD_REF ;
> >   _118 = BIT_FIELD_REF ;
> >   _119 = BIT_FIELD_REF ;
> >   _120 = BIT_FIELD_REF ;
> >   _121 = BIT_FIELD_REF ;
> >   _122 = BIT_FIELD_REF ;
> >   _123 = BIT_FIELD_REF ;
> >   _124 = BIT_FIELD_REF ;
> >   _125 = BIT_FIELD_REF ;
> >   _126 = BIT_FIELD_REF ;
> >   _127 = BIT_FIELD_REF ;
> >   _128 = BIT_FIELD_REF ;
> >   _129 = BIT_FIELD_REF ;
> >   _130 = _114 + _118;
> >   _131 = _115 + _119;
> >   _132 = _116 + _120;
> >   _133 = _117 + _121;
> >   _134 = _130 + _122;
> >   _135 = _131 + _123;
> >   _136 = _132 + _124;
> >   _137 = _133 + _125;
> >   _138 = _134 + _126;
> > 
> > see how the lanes from the different vectors are accumulated?  (yeah,
> > we should simply add the vectors!)
> 
> Yes, it's the same as what I saw on ppc64le, but the closely following dce6
> removes the three vect_sum3_32 (in your dump, they are
> vect_sum3_32.16_10{7,8,9}) as the subsequent joints don't actually use the
> separated accumulated lane values (_138 -> sum0 ...) but only use
> vect_sum3_32.16_110.

I do - the epilog is even vectorized and it works fine at runtime.

[Bug tree-optimization/107229] [13 Regression] ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed since r13-3219-g25413fdb2ac24933

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

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

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

https://gcc.gnu.org/g:9f0d4adabe2035886a1aa8d2ca990a90de000613

commit r13-3270-g9f0d4adabe2035886a1aa8d2ca990a90de000613
Author: Andre Vieira 
Date:   Thu Oct 13 12:09:38 2022 +0100

ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]

The bitposition calculation for the bitfield lowering in loop if conversion
was
not taking DECL_FIELD_OFFSET into account, which meant that it would result
in
wrong bitpositions for bitfields that did not end up having representations
starting at the beginning of the struct.

gcc/ChangeLog:

PR tree-optimization/107229
* tree-if-conv.cc (get_bitfield_rep): Fix bitposition calculation.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/pr107229-1.c: New test.
* gcc.dg/vect/pr107229-2.c: New test.
* gcc.dg/vect/pr107229-3.c: New test.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #11 from Kewen Lin  ---
> > > Btw, I've fixed a SLP reduction issue two days ago in
> > > r13-3226-gee467644c53ee2
> > > though that looks unrelated?
> > 
> > Thanks for the information, I'll double check it.
> > 

To rebase to r13-3226 or even the latest trunk doesn't help.

> 
> I do - the epilog is even vectorized and it works fine at runtime.

You meant the code on x86 is all fine? and the case doesn't show the "res"
difference? hmm, it's weird.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 13 Oct 2022, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107160
> 
> --- Comment #11 from Kewen Lin  ---
> > > > Btw, I've fixed a SLP reduction issue two days ago in
> > > > r13-3226-gee467644c53ee2
> > > > though that looks unrelated?
> > > 
> > > Thanks for the information, I'll double check it.
> > > 
> 
> To rebase to r13-3226 or even the latest trunk doesn't help.

:/

> > 
> > I do - the epilog is even vectorized and it works fine at runtime.
> 
> You meant the code on x86 is all fine? and the case doesn't show the "res"
> difference? hmm, it's weird.

Yes.  I'll try to look at cross compiler IL.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #13 from Martin Liška  ---
A bit reduced test-case that can be compiled with cross compiler:

$ cat pr107160.c
#define N 16
float fl[N];

__attribute__ ((noipa, optimize (0))) void
init ()
{
  for (int i = 0; i < N; i++)
fl[i] = 1 << i;
}

__attribute__ ((noipa)) float
foo (int n)
{
  float sum0, sum1, sum2, sum3;
  sum0 = sum1 = sum2 = sum3 = 0.0f;

  for (int i = 0; i < n; i += 4)
{
  sum0 += __builtin_fabs (fl[i]);
  sum1 += __builtin_fabs (fl[i + 1]);
  sum2 += __builtin_fabs (fl[i + 2]);
  sum3 += __builtin_fabs (fl[i + 3]);
}

  return sum0 + sum1 + sum2 + sum3;
}

__attribute__ ((optimize (0))) int
main ()
{
  init ();
  float res = foo (N);
  __builtin_printf ("res:%f\n", res);
  return 0;
}

x86_64:
./a.out 
res:65535.00

ppc64le:
./a.out
res:15.00

so the result is wrong, it sums only first 4 elements (and not 16).

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #14 from Richard Biener  ---
Aha, so the issue is that we have a vectorized epilogue here and the epilogue
of _that_ ends up doing


   [local count: 94607391]:
  # sum0_48 = PHI 
  # sum1_47 = PHI 
  # sum2_46 = PHI 
  # sum3_45 = PHI 
  # vect_sum3_31.16_101 = PHI 
  # vect_sum3_31.16_102 = PHI 
  # vect_sum3_31.16_103 = PHI 
  # vect_sum3_31.16_104 = PHI 
  _105 = BIT_FIELD_REF ;
  _106 = BIT_FIELD_REF ;
...
this is from the main vect

   [local count: 81467476]:
  # sum0_135 = PHI 
  # sum1_136 = PHI 
  # sum2_137 = PHI 
  # sum3_138 = PHI 
  # vect_sum3_50.25_159 = PHI 
this is from the epilogue

   [local count: 105119324]:
  # sum0_15 = PHI 
  # sum1_77 = PHI 
  # sum2_75 = PHI 
  # sum3_13 = PHI 
  # _160 = PHI 
  _161 = BIT_FIELD_REF <_160, 32, 0>;
  _162 = BIT_FIELD_REF <_160, 32, 32>;
  _163 = BIT_FIELD_REF <_160, 32, 64>;
  _164 = BIT_FIELD_REF <_160, 32, 96>;
  _74 = _161 + _162;
  _76 = _74 + _163;
  _78 = _76 + _164;

so we fail to accumulate the main loops accumulators and just
use the first one.  On x86 the vectorized epilogue uses a smaller
vector size but the same number of accumulators.

It seems it's simply unexpected to have the unrolled SLP reduction
and a vectorized epilogue with the same vector mode (but not unrolled).

I can reproduce the failure when patching the x86 cost model to force
unrolling by 2 (maybe we want a --param to force that to aid debugging...).

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Biener  ---
I think that either vect_find_reusable_accumulator should punt on this or
vect_create_epilog_for_reduction shouldn't register this accumulator.
The caller of vect_find_reusable_accumulator checks for vec_num == 1
(in the epilog) but we register for vec_num == 2.  For SLP reductions
we "fail" to reduce to a single accumulator.

  int vec_num = vec_oprnds0.length ();
  gcc_assert (vec_num == 1 || slp_node);


The following fixes this:

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 1996ecfee7a..b1442a93581 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -6232,7 +6232,8 @@ vect_create_epilog_for_reduction (loop_vec_info
loop_vinfo,
 }

   /* Record this operation if it could be reused by the epilogue loop.  */
-  if (STMT_VINFO_REDUC_TYPE (reduc_info) == TREE_CODE_REDUCTION)
+  if (STMT_VINFO_REDUC_TYPE (reduc_info) == TREE_CODE_REDUCTION
+  && vec_num == 1)
 loop_vinfo->reusable_accumulators.put (scalar_results[0],
   { orig_reduc_input, reduc_info });

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> > Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> > Now I got more confused.
> 
> CCCmode means that single flag is tested, it uses EQ and NE, so "c" and "nc"
> suffix is emitted. When CCmode is used, LTU/GEU operation on CCmode flags
> reg produces "b" and "nb" suffix, which decodes to exactly the same assembly
> as "c" and "nc" suffixes.
> 
> However, it looks that somewhere LTU/GEU is also generated with CCCmode
> flags reg, and some fixup was introduced to put_condition_code to "fix" this
> inconsistency. If LTU/GEU is valid only for CCmode, then the producers of
> invalid RTX should be fixed.

grep -e ltu -e geu *.md, it looks like most places use CCmode for LTU, only
below cases use CCCmode, maybe we should use CCmode for all of those and "fix"
put_condition_code?

cut CCCmode---
i386.md:   (ltu (reg:CCC FLAGS_REG) (const_int 0))
i386.md:(compare:CCC (neg:QI (geu:QI (reg:CC_CCC FLAGS_REG) (const_int
0)))
i386.md: (ltu:QI (reg:CC_CCC FLAGS_REG) (const_int 0]
i386.md:  (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0
i386.md:(neg:SWI (ltu:SWI (reg:CCC FLAGS_REG) (const_int 0])

cut ends---

cut CCmode---
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md: (ltu: (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md: (ltu: (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md: (ltu: (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md: (ltu: (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0)))
i386.md:   (ltu (reg:CC FLAGS_REG) (const_int 0))
i386.md:(ltu: (reg:CC FLAGS_REG) (const_int 0))
i386.md:(ltu: (reg:CC FLAGS_REG) (const_int 0))
i386.md:  (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))]
i386.md:   (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
i386.md:   (ltu: (reg:CC FLAGS_REG) (const_int 0)
i386.md: (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md: (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:(ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:   (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int 0))
i386.md:(ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:(ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md: (plus:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:(ltu:SWI (reg:CC FLAGS_REG) (const_int
0)))
i386.md:  (ltu:SWI (reg:CC FLAGS_REG) (const_int
0
i386.md:   (ltu:SWI (reg:CC FLAGS_REG) (const_int
0))
i386.md:  (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:(ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))
i386.md: (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0)))
i386.md:(ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))
i386.md:  (if_then_else:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int
0))
i386.md:  (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:  (plus:DWIH (plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int
0))
i386.md:(ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:(ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:(ltu:QI (reg:CC FLAGS_REG) (const_int 0)))
i386.md:(neg:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0]
i386.md:(neg:SWI (ltu:SWI (reg:CC FLAGS_REG) (const_int 0])

cut ends

[Bug tree-optimization/107247] New: SLP reduction results fail to reduce to a single accumulator

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

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

Bug ID: 107247
   Summary: SLP reduction results fail to reduce to a single
accumulator
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

float fl[128];
int x[128];
float
foo (int n1)
{
  float sum0, sum1, sum2, sum3;
  sum0 = sum1 = sum2 = sum3 = 0.0f;

  int n = (n1 / 4) * 4;
  for (int i = 0; i < n; i += 4)
{
  sum0 += fabs (fl[i]);
  sum1 += fabs (fl[i + 1]);
  sum2 += fabs (fl[i + 2]);
  sum3 += fabs (fl[i + 3]);
  x[i] = 1;
}

  return sum0 + sum1 + sum2 + sum3;
}

shows how we fail to reduce the SLP reduction accumulators to a single one
before extracting the elements:

   [local count: 567644343]:
  # sum0_37 = PHI 
  # sum1_39 = PHI 
  # sum2_41 = PHI 
  # sum3_43 = PHI 
  # i_45 = PHI 
  # vectp_fl.8_89 = PHI 
  # vect_sum3_43.15_102 = PHI 
  # vect_sum3_43.15_103 = PHI 
  # vect_sum3_43.15_104 = PHI 
  # vect_sum3_43.15_105 = PHI 
...
  vect__12.14_98 = ABS_EXPR ;
  vect__12.14_99 = ABS_EXPR ;
  vect__12.14_100 = ABS_EXPR ;
  vect__12.14_101 = ABS_EXPR ;
  vect_sum3_32.16_106 = vect__12.14_98 + vect_sum3_43.15_102;
  vect_sum3_32.16_107 = vect__12.14_99 + vect_sum3_43.15_103;
  vect_sum3_32.16_108 = vect__12.14_100 + vect_sum3_43.15_104;
  vect_sum3_32.16_109 = vect__12.14_101 + vect_sum3_43.15_105;
...

   [local count: 94607391]:
  # sum0_48 = PHI 
  # sum1_36 = PHI 
  # sum2_35 = PHI 
  # sum3_24 = PHI 
  # vect_sum3_32.16_110 = PHI 
  # vect_sum3_32.16_111 = PHI 
  # vect_sum3_32.16_112 = PHI 
  # vect_sum3_32.16_113 = PHI 
  _114 = BIT_FIELD_REF ;
  _115 = BIT_FIELD_REF ;
  _116 = BIT_FIELD_REF ;
  _117 = BIT_FIELD_REF ;
  _118 = BIT_FIELD_REF ;
  _119 = BIT_FIELD_REF ;
  _120 = BIT_FIELD_REF ;
  _121 = BIT_FIELD_REF ;
  _122 = BIT_FIELD_REF ;
  _123 = BIT_FIELD_REF ;
  _124 = BIT_FIELD_REF ;
  _125 = BIT_FIELD_REF ;
  _126 = BIT_FIELD_REF ;
  _127 = BIT_FIELD_REF ;
  _128 = BIT_FIELD_REF ;
  _129 = BIT_FIELD_REF ;
  _130 = _114 + _118;
  _131 = _115 + _119;
  _132 = _116 + _120;
  _133 = _117 + _121;
  _134 = _130 + _122;
  _135 = _131 + _123;
  _136 = _132 + _124;
  _137 = _133 + _125;
  _138 = _134 + _126;
  _139 = _135 + _127;
  _140 = _136 + _128;
  _141 = _137 + _129;
...

instead of doing vector adds and a single series of extracts.

[Bug tree-optimization/107247] SLP reduction results fail to reduce to a single accumulator

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-10-13

--- Comment #1 from Richard Biener  ---
I have a patch.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

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

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

commit r13-3273-g5cbaf84c191b9a3e3cb26545c808d208bdbf2ab5
Author: Richard Biener 
Date:   Thu Oct 13 14:24:05 2022 +0200

tree-optimization/107160 - avoid reusing multiple accumulators

Epilogue vectorization is not set up to re-use a vectorized
accumulator consisting of more than one vector.  For non-SLP
we always reduce to a single but for SLP that isn't happening.
In such case we currenlty miscompile the epilog so avoid this.

PR tree-optimization/107160
* tree-vect-loop.cc (vect_create_epilog_for_reduction):
Do not register accumulator if we failed to reduce it
to a single vector.

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

[Bug target/107160] [12/13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[13 regression] |[12/13 regression]
   |r13-2641-g0ee1548d96884d|r13-2641-g0ee1548d96884d
   |causes verification failure |causes verification failure
   |in spec2006 |in spec2006
   Priority|P3  |P2
   Target Milestone|13.0|12.3

--- Comment #17 from Richard Biener  ---
Fixed on trunk, but I think the issue is latent on the GCC 12 branch, queueing
for backports.  I am testing a followup fixing the missed optimization
(PR107247).

[Bug rtl-optimization/107248] New: Sparc V8 Invalid Stack Pointer Code

[dennis.borde at ohb dot de via Gcc-bugs]

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

Bug ID: 107248
   Summary: Sparc V8 Invalid Stack Pointer Code
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dennis.borde at ohb dot de
  Target Milestone: ---

Created attachment 53700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53700&action=edit
source code to trigger the bug

Environment: GCC V7.1.0, Sparc V8, RTEMS V4.8.0

When compiling with optimization level -O2 (including -fschedule-insns2) the
compiler generates code like this:

(1) add %sp, 0x50, %g1
(2) add %sp, 0x50, %sp
(3) add %g1, %o0, %o0
(4) ld [ %o0 + -8 ], %o0

In line (2) the stack pointer is moved by 80 bytes forward, which means memory
is "freed".
In line (4) it accesses the "freed" stack memory.

When an interrupt occurs in between line (2) and (4) it will overwrite the
stack data and "corrupt" it for the reading in line (4).

E.g.: As part of the RTEMS _ISR_Handler() the interrupt stack frame is stored
(see label symbol save_isf). For more information see RTEMS source code.
However, this is just one example to show the order of instructions above is
not safe. It is not important for the bug itself.

Work-around: Compile with -fno-schedule-insns2

With the work-around the generated code looks like this:
(1) add %sp, 0x50, %g1
(2) add %g1, %o0, %o0
(3) ld [ %o0 + -8 ], %o0
(4) add %sp, 0x50, %sp 

Here the stack memory is "freed" (4) after the access (3).

It seems to be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/107248] Sparc V8 Invalid Stack Pointer Code

[dennis.borde at ohb dot de via Gcc-bugs]

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

--- Comment #1 from Dennis Borde  ---
Created attachment 53701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53701&action=edit
gcc -v output

[Bug analyzer/107249] New: ipa-sra.cc:3030:1: error: insertion out of range in 'bit_insert_expr'

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

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

Bug ID: 107249
   Summary: ipa-sra.cc:3030:1: error: insertion out of range in
'bit_insert_expr'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

In stage3, build fails:

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-13/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/g
nu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o ipa-sra.o -MT ipa-sra.o
-MMD -MP -MF ./.deps/ipa-sra.TPo ../../gcc/gcc/ipa-sra.cc
../../gcc/gcc/ipa-sra.cc: In function 'void
{anonymous}::process_edge_to_unknown_caller(cgraph_edge*)':
../../gcc/gcc/ipa-sra.cc:3030:1: error: insertion out of range in
'bit_insert_expr'
 3030 | process_edge_to_unknown_caller (cgraph_edge *cs)
  | ^~
_ifc__83 = BIT_INSERT_EXPR <_ifc__78, 0, 18446744073709551584 (1 bits)>;
../../gcc/gcc/ipa-sra.cc:3030: confused by earlier errors, bailing out
make[3]: *** [Makefile:1146: ipa-sra.o] Error 1

[Bug middle-end/107208] [aarch64] _complex integer return types could be improved

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #3 from vfdff  ---
it seems releted to targetm.calls.function_value called by assign_parms, who
return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
the following changes, then choose a pair of DI for the int case
```
@@ -20333,7 +20333,7 @@ aarch64_vfp_is_call_or_return_candidate (machine_mode
mode,
   *count = 1;
   new_mode = mode;
 }
-  else if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
+  else if (COMPLEX_MODE_P (mode))

```

[Bug ipa/107249] ipa-sra.cc:3030:1: error: insertion out of range in 'bit_insert_expr'

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-13
  Component|analyzer|ipa
 Status|UNCONFIRMED |WAITING
 CC||andre.simoesdiasvieira@arm.
   ||com, marxin at gcc dot gnu.org
   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Likely fixed with r13-3270-g9f0d4adabe2035886a1aa8d2ca990a90de000613, can you
please re-try?

[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249

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

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

--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Seurer, Peter,

Adding something like: { xfail { powerpc*-*-* && { ! powerpc_vsx_ok } } } }
should xfail all powerpc architectures that don't support this no?

[Bug target/105773] [Aarch64] Failure to optimize and+cmp to tst

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:1cccf644ff92ac1145abdbf255d1862dd787875b

commit r13-3274-g1cccf644ff92ac1145abdbf255d1862dd787875b
Author: Wilco Dijkstra 
Date:   Thu Oct 13 14:41:55 2022 +0100

[AArch64] Improve bit tests [PR105773]

Since AArch64 sets all flags on logical operations, comparisons with zero
can be combined into an AND even if the condition is LE or GT. Add a new
CC_NZV mode used by ANDS/BICS/TST instructions.

gcc/
PR target/105773
* config/aarch64/aarch64.cc (aarch64_select_cc_mode): Allow
GT/LE for merging compare with zero into AND.
(aarch64_get_condition_code_1): Add CC_NZVmode support.
* config/aarch64/aarch64-modes.def: Add CC_NZV.
* config/aarch64/aarch64.md: Use CC_NZV in cmp+and patterns.

gcc/testsuite/
PR target/105773
* gcc.target/aarch64/ands_2.c: Test for ANDS.
* gcc.target/aarch64/bics_2.c: Test for BICS.
* gcc.target/aarch64/tst_2.c: Test for TST.
* gcc.target/aarch64/tst_imm_split_1.c: Fix test.

[Bug target/105773] [Aarch64] Failure to optimize and+cmp to tst

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #3 from Wilco  ---
Fixed.

[Bug tree-optimization/107226] [13 regression] r13-3219-g25413fdb2ac249 caused a lot of testcase failures

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #3 from Hongtao.liu  ---
Fixed.

[Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-13
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Reduced:

$ cat 106848_a.H
typedef enum memory_order { memory_order_seq_cst } memory_order;

$ cat 106848_b.C
import "106848_a.H";

memory_order x;

$ g++ -fmodules-ts -g 106848_a.H 106848_b.C
106848_b.C:3:14: error: type variant differs by TYPE_MAX_VALUE

[Bug tree-optimization/107247] SLP reduction results fail to reduce to a single accumulator

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

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

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

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

commit r13-3276-ge5139d18dfb8130876ea59178e8471fb1b34bb80
Author: Richard Biener 
Date:   Thu Oct 13 14:56:01 2022 +0200

tree-optimization/107247 - reduce SLP reduction accumulator

The following makes sure to reduce a multi-vector SLP reduction
accumulator to a single vector using vector operations if
easily possible (if the number of lanes in the vector type is
a multiple of the number of scalar accumulators).

PR tree-optimization/107247
* tree-vect-loop.cc (vect_create_epilog_for_reduction):
Reduce multi vector SLP reduction accumulators.  Check
the adjusted number of accumulator vectors against
one for the re-use in the epilogue.

[Bug tree-optimization/107247] SLP reduction results fail to reduce to a single accumulator

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
This is now fixed for the cases not requiring permutations.  One could think of
a three-lane SLP reduction with three four component vectors being reduced
by first "expanding" to four "three component" vectors, summing them and then
extracting from the lower three lanes.  Likewise for a six-lane SLP reduction
which would get a more complex extraction of two-vector, six-lane pairs.

Unless a compelling case comes along I don't consider these important.

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

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

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

Bug 107247 Summary: SLP reduction results fail to reduce to a single accumulator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107247

   What|Removed |Added

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

[Bug tree-optimization/107250] New: Load unnecessarily happens before malloc

[jmuizelaar at mozilla dot com via Gcc-bugs]

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

Bug ID: 107250
   Summary: Load unnecessarily happens before malloc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmuizelaar at mozilla dot com
  Target Milestone: ---

The following code will be compiled with the load of next happening before the
call to malloc. This generates worse code than if the load is delayed until
after the call to malloc.


struct Foo {
Foo* next;
};
void ctx_push(Foo* f) {
Foo tmp = { f->next };
Foo *n = (Foo*)malloc(sizeof(Foo));
*n = tmp;
f->next = n;
}

Manually moving the load in this example improves the generated code:

struct Foo {
Foo* next;
};

void ctx_push(Foo* f) {
Foo *n = (Foo*)malloc(sizeof(Foo));
Foo tmp = { f->next };
*n = tmp;
f->next = n;
}

https://gcc.godbolt.org/z/TnMj1c636

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:3130e70dab1e64a7b014391fe941090d5f3b6b7d

commit r13-3277-g3130e70dab1e64a7b014391fe941090d5f3b6b7d
Author: Marek Polacek 
Date:   Tue Oct 11 14:16:54 2022 -0400

c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test.  At this point
start_preparsed_function hasn't yet set current_function_decl.
expand_vec_init_expr then leads to maybe_splice_retval_cleanup which
checks DECL_CONSTRUCTOR_P (current_function_decl) without checking that
c_f_d is non-null first.  It seems correct that c_f_d is null here, so
it seems to me that maybe_splice_retval_cleanup should check c_f_d as
in the following patch.

PR c++/106925

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Check
current_function_decl.
Make the bool const.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-defarg3.C: New test.

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:8794633003318113e03147a727e63f5d55b350ab

commit r12-8829-g8794633003318113e03147a727e63f5d55b350ab
Author: Marek Polacek 
Date:   Tue Oct 11 14:16:54 2022 -0400

c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test.  At this point
start_preparsed_function hasn't yet set current_function_decl.
expand_vec_init_expr then leads to maybe_splice_retval_cleanup which
checks DECL_CONSTRUCTOR_P (current_function_decl) without checking that
c_f_d is non-null first.  It seems correct that c_f_d is null here, so
it seems to me that maybe_splice_retval_cleanup should check c_f_d as
in the following patch.

PR c++/106925

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Check
current_function_decl.
Make the bool const.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-defarg3.C: New test.

(cherry picked from commit 3130e70dab1e64a7b014391fe941090d5f3b6b7d)

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/102872] If statement is always false but not figured out at gimple level

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

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

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

https://gcc.gnu.org/g:6cc3394507a2303a18891d34222c53f679256c37

commit r13-3281-g6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod 
Date:   Wed Oct 5 10:42:07 2022 -0400

propagate partial equivs in the cache.

Adjust on-entry cache propagation to look for and propagate both full
and partial equivalences.

gcc/
PR tree-optimization/102540
PR tree-optimization/102872
* gimple-range-cache.cc (ranger_cache::fill_block_cache):
Handle partial equivs.
(ranger_cache::range_from_dom): Cleanup dump output.

gcc/testsuite/
* gcc.dg/pr102540.c: New.
* gcc.dg/pr102872.c: New.

[Bug tree-optimization/102540] [12/13 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885

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

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

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

https://gcc.gnu.org/g:6cc3394507a2303a18891d34222c53f679256c37

commit r13-3281-g6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod 
Date:   Wed Oct 5 10:42:07 2022 -0400

propagate partial equivs in the cache.

Adjust on-entry cache propagation to look for and propagate both full
and partial equivalences.

gcc/
PR tree-optimization/102540
PR tree-optimization/102872
* gimple-range-cache.cc (ranger_cache::fill_block_cache):
Handle partial equivs.
(ranger_cache::range_from_dom): Cleanup dump output.

gcc/testsuite/
* gcc.dg/pr102540.c: New.
* gcc.dg/pr102872.c: New.

[Bug c/107251] New: RISC-V linux kernel compiled with -mno-relax generates a lot of local symbols

[xnox at ubuntu dot com via Gcc-bugs]

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

Bug ID: 107251
   Summary: RISC-V linux kernel compiled with -mno-relax generates
a lot of local symbols
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xnox at ubuntu dot com
  Target Milestone: ---

Previous reported at
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1036

$ du -h btrfs.ko.*
76M btrfs.ko.riscv64
42M btrfs.ko.x86_64

$ strip --strip-debug btrfs.ko.x86_64
$ riscv64-linux-gnu-strip --strip-debug btrfs.ko.riscv64 

$ du -h btrfs.ko.*
17M btrfs.ko.riscv64
2.8Mbtrfs.ko.x86_64

$ strip --strip-debug --discard-locals btrfs.ko.x86_64
$ riscv64-linux-gnu-strip --strip-debug --discard-locals btrfs.ko.riscv64

$ du -h btrfs.ko.*
4.2Mbtrfs.ko.riscv64
2.8Mbtrfs.ko.x86_64

The above demonstrates that RISCV kernel modules are compiled with -mno-relax
option, and yet a lot of relocation symbols are emitted and remain in the
modules keeping their size very large.

Over on github issue it was mentioned that "There is a known problem with GNU
as that we still emit extra symbols and relocations when -mno-relax is used.
Kernel modules are compiled -mno-relax. So fixing this would help reduce the
symtab size." However I was unable to find a bug report pointing this out.

Could you please ensure that when compiling code, the extra symbols and
relocations are not emitted, or otherwise stripped? Such that calling
--discard-locals would have no particular effect on the binary sizes. It is
inconvenient for distributions to call --discard-locals on riscv, even when
otherwise one is keeping the rest of the debug symbols for example.

I have observed this with gcc-10 and upwords, and most recently with gcc-12. I
can try newer builds of gcc and/or any patches to confirm behaviour.

[Bug c++/107252] New: False positive stringop-overflow, warning disappears if I remove unrelated code!

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 107252
   Summary: False positive stringop-overflow, warning disappears
if I remove unrelated code!
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Created attachment 53702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53702&action=edit
Preprocessed source

Hi, 

I'm getting a false positive in the following reduced example (preprocessed
source attached):

#include 
#include 


class Test : public ::testing::Test
{
 public:
std::vector x_{};
};

struct Bar
{
std::vector a;
std::vector b;
};

TEST_F(Test, Test1)
{
const std::vector x{1};
const std::vector y(2, 1);

std::vector z;
z.insert(z.end(), x.begin(),x.end());

Bar bar{};
bar.a = z;
}

TEST_F(Test, Test2)
{
const std::vector z{
1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24,
25, 26
};
Bar bar{};
bar.a = x_;
}


In file included from
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/algorithm:60,
 from
/opt/compiler-explorer/libs/googletest/trunk/googlemock/include/gmock/gmock-actions.h:137,
 from
/opt/compiler-explorer/libs/googletest/trunk/googlemock/include/gmock/gmock.h:56,
 from :1:
In static member function 'static _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = unsigned char; bool _IsMove = true]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:497:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:524:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:531:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II =
move_iterator; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:624:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = std::move_iterator;
_ForwardIterator = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = move_iterator; _ForwardIterator = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:185:15,
inlined from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
move_iterator; _ForwardIterator = unsigned char*; _Tp =
unsigned char]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:373:37,
inlined from '_ForwardIterator
std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator,
_ForwardIterator, _Allocator&) [with _InputIterator = unsigned char*;
_ForwardIterator = unsigned char*; _Allocator = allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:399:2,
inlined from 'void std::vector<_Tp, _Alloc>::_M_range_insert(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = __gnu_cxx::__normal_iterator >; _Tp = unsigned char; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/vector.tcc:801:9,
inlined from 'void std::vector<_Tp, _Alloc>::_M_insert_dispatch(iterator,
_InputIterator, _InputIterator, std::__false_type) [with _InputIterator =
__gnu_cxx::__normal_iterator
>; _Tp = unsigned char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_vector.h:1779:19,
inlined from 'std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = __gnu_cxx::__normal_iterator >;  = void; _Tp = unsigned
char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-2

[Bug tree-optimization/107252] False positive stringop-overflow, warning disappears if I remove unrelated code!

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c++ |tree-optimization

--- Comment #1 from Andrew Pinski  ---
I suspect inlining heuristics kick in differently when you remove unused code.

[Bug tree-optimization/107250] Load unnecessarily happens before malloc

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
On the other hand, dispatching the load before malloc is useful if you expect
it to miss in the caches. If you wrote the code with that in mind, and the
compiler moved the load anyway, a manual workaround to *that* would be more
invasive.

[Bug bootstrap/107253] New: gcc does not compile with XCode 14.0.1 / clang 14.0.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

Bug ID: 107253
   Summary: gcc does not compile with XCode 14.0.1 / clang 14.0.0
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The linking during bootstrap on Darwin 21.6.0 with Xcode 14.0.1 chokes on the
error message below, the configure line has been:
../configure --prefix=/usr/local/ --with-gmp=/usr/local/
--with-mpfr=/usr/local/ --with-mpr=/usr/local/ --with-isl=/usr/local/
--enable-checking=release
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
--enable-languages=c,c++,fortran,lto,objc,obj-c++

0  0x101ac7ffa  __assert_rtn + 139
1  0x1018fb28d 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 4989
2  0x1018ebf8f  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 207
3  0x1019629d4  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 2036
4  0x101965fa0  ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 48
5  0x7ff806eb134a  _dispatch_client_callout2 + 8
6  0x7ff806ec28f5  _dispatch_apply_invoke + 213
7  0x7ff806eb1317  _dispatch_client_callout + 8
8  0x7ff806ec0c0c  _dispatch_root_queue_drain + 673
9  0x7ff806ec125c  _dispatch_worker_thread2 + 160
10  0x7ff807064f8a  _pthread_wqthread + 256
A linker snapshot was created at:
/tmp/libstdc++.6.dylib-2022-10-13-180147.ld-snapshot
ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more
atoms allocated than expected"), function parse, file
macho_relocatable_file.cpp, line 2061.
collect2: error: ld returned 1 exit status
make[6]: *** [libstdc++.la] Error 1
make[5]: *** [all-recursive] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[1]: *** [stage1-bubble] Error 2

The failing link command was:
libtool: link:  /usr/local/packages/gcc_trunk/_build/./gcc/xgcc -shared-libgcc
-B/usr/local/packages/gcc_trunk/_build/./gcc -nostdinc++
-L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/src
-L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-apple-darwin21.6.0/bin/
-B/usr/local/x86_64-apple-darwin21.6.0/lib/ -isystem
/usr/local/x86_64-apple-darwin21.6.0/include -isystem
/usr/local/x86_64-apple-darwin21.6.0/sys-include   -fno-checking -dynamiclib 
-o .libs/libstdc++.6.dylib  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o
.libs/compatibility-thread-c++0x.o  
.libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o
.libs/libstdc++.lax/libsupc++convenience.a/atexit_thread.o
.libs/libstdc++.lax/libsupc++convenience.a/atomicity.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_alloc.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_array_length.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_array_new.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_cast.o
.libs/libstdc++.lax/libsupc++convenience.a/bad_typeid.o
.libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o
.libs/libstdc++.lax/libsupc++convenience.a/cp-demangle.o
.libs/libstdc++.lax/libsupc++convenience.a/del_op.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opa.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opant.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o
.libs/libstdc++.lax/libsupc++convenience.a/del_ops.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opsa.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opv.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opva.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opvant.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opvs.o
.libs/libstdc++.lax/libsupc++convenience.a/del_opvsa.o
.libs/libstdc++.lax/libsupc++convenience.a/dyncast.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_call.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_globals.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o
.libs/libstdc++.lax/libsupc++convenience.a/eh_ptr.o
.libs/libstdc++.lax/libsupc++convenience.a/e

[Bug bootstrap/107253] gcc does not compile with XCode 14.0.1 / clang 14.0.0

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

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

--- Comment #1 from Andrew Pinski  ---
Ok, this is definitely Apple's bug, the linker should not be crashing
(asserting).

[Bug bootstrap/107253] gcc does not compile with XCode 14.0.1 / clang 14.0.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Andrew Pinski  ---
https://stackoverflow.com/questions/73714336/xcode-update-to-version-2395-ld-compile-problem-occurs-computedatomcount-m
https://github.com/Homebrew/discussions/discussions/3659
https://developer.apple.com/forums/thread/714565

Looks like a known issue with Apple's linker and they are working on a fix. NOT
a GCC bug so closing as moved. There is no workaround except downgrading to
Xcode 13.x.

[Bug tree-optimization/107254] New: Wrong vectorizer code (GCC 11 only, Fortran)

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

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

Bug ID: 107254
   Summary: Wrong vectorizer code (GCC 11 only, Fortran)
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

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

The following code gives the wrong result (-1. instead of
0.) with gfortran 11.3 (also tested with the 11.3.1 20221007
prerelease) when given the options
`-O2 -ftree-vectorize -march=core-avx`
for x86_64.

There's no issue with GCC 9,10, and 12. It could be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107212 except that bug also
affects GCC 12.

This issue came up from testing the reference LAPACK with -ftree-vectorize
enabled, where many more tests failed with recent GCC (11/12), see
https://github.com/easybuilders/easybuild-easyconfigs/issues/16380

$ gfortran -O2 -ftree-vectorize -march=core-avx2 dhgeqz2.f90; ./a.out 
  -1. 
$ gfortran -Wall -O2 dhgeqz2.f90; ./a.out 
   0.


subroutine dlartg( f, g, s, r )
  implicit none
  double precision :: f, g, r, s
  double precision :: d, p

  d = sqrt( f*f + g*g )
  p = 1.d0 / d
  if( abs( f ) > 1 ) then
 s = g*sign( p, f )
 r = sign( d, f )
  else
 s = g*sign( p, f )
 r = sign( d, f )
  end if
end subroutine

subroutine dhgeqz( n, h, t )
  implicit none
  integern
  double precision   h( n, * ), t( n, * )
  integerjc
  double precision   c, s, temp, temp2, tempr
  temp2 = 10d0
  call dlartg( 10d0, temp2, s, tempr )
  c = 0.9d0
  s = 1.d0
  do jc = 1, n
 temp = c*h( 1, jc ) + s*h( 2, jc )
 h( 2, jc ) = -s*h( 1, jc ) + c*h( 2, jc )
 h( 1, jc ) = temp
 temp2 = c*t( 1, jc ) + s*t( 2, jc )
 ! t(2,2)=-s*t(1,2)+c*t(2,2)=-0.9*0+1*0=0
 t( 2, jc ) = -s*t( 1, jc ) + c*t( 2, jc )
 t( 1, jc ) = temp2
  enddo
end subroutine dhgeqz

program test
  implicit none
  double precision h(2,2), t(2,2)  
  h = 0
  t(1,1) = 1
  t(2,1) = 0
  t(1,2) = 0
  t(2,2) = 0
  call dhgeqz( 2, h, t )
  print *,t(2,2)
end program test

[Bug fortran/85541] ICE with parameterized derived type (PDT) and allocate

[aarograh at umich dot edu via Gcc-bugs]

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

aarograh at umich dot edu changed:

   What|Removed |Added

 CC||aarograh at umich dot edu

--- Comment #4 from aarograh at umich dot edu ---
I've also encountered issues with this in gcc 8.3.  Here's my even simpler
example that shows the error.  The commented code hints at the more complex
functionality that I'm actually working toward.

MODULE testMod
IMPLICIT NONE
PUBLIC

TYPE :: cache(n)
  INTEGER,LEN :: n
  REAL :: a(n)
ENDTYPE cache

TYPE :: parent
  TYPE(cache(1)),ALLOCATABLE :: cache
ENDTYPE parent
ENDMODULE testMod

PROGRAM test
  USE testMod
  TYPE(cache(1)),ALLOCATABLE :: testcache
  TYPE(parent) :: testparent

  ALLOCATE(cache(1) :: testcache)
  WRITE(*,*) testcache%n
  WRITE(*,*) testcache%a
  !ALLOCATE(cache(1) :: testparent%cache)
  !WRITE(*,*) testparent%cache%n
  !WRITE(*,*) testparent%cache%a
ENDPROGRAM test


f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2545
0x5c6ca5 gfc_get_derived_type(gfc_symbol*, int)
../../gcc-8.3.0-source/gcc/fortran/trans-types.c:2545
0x748aa8 gfc_get_derived_type(gfc_symbol*, int)
../../gcc-8.3.0-source/gcc/fortran/trans-types.c:2691
0x749498 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc-8.3.0-source/gcc/fortran/trans-types.c:1203
0x74975c gfc_sym_type(gfc_symbol*)
../../gcc-8.3.0-source/gcc/fortran/trans-types.c:2272
0x74975c gfc_sym_type(gfc_symbol*)
../../gcc-8.3.0-source/gcc/fortran/trans-types.c:2230
0x6f443d gfc_get_symbol_decl(gfc_symbol*)
../../gcc-8.3.0-source/gcc/fortran/trans-decl.c:1739
0x6f6ff8 gfc_create_module_variable
../../gcc-8.3.0-source/gcc/fortran/trans-decl.c:5024
0x6f6ff8 gfc_create_module_variable
../../gcc-8.3.0-source/gcc/fortran/trans-decl.c:4941
0x6bd202 do_traverse_symtree
../../gcc-8.3.0-source/gcc/fortran/symbol.c:4179
0x6f98b3 gfc_generate_module_vars(gfc_namespace*)
../../gcc-8.3.0-source/gcc/fortran/trans-decl.c:5496
0x6d5459 gfc_generate_module_code(gfc_namespace*)
../../gcc-8.3.0-source/gcc/fortran/trans.c:2201
0x6886bb translate_all_program_units
../../gcc-8.3.0-source/gcc/fortran/parse.c:6112
0x6886bb gfc_parse_file()
../../gcc-8.3.0-source/gcc/fortran/parse.c:6328
0x6cefbf gfc_be_parse_file
../../gcc-8.3.0-source/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (GCC 11 only, Fortran)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 11.3.0
Summary|Wrong vectorizer code (GCC  |[11 Regression] Wrong
   |11 only, Fortran)   |vectorizer code (GCC 11
   ||only, Fortran)
   Keywords||wrong-code
  Known to work||10.4.0, 12.1.0
   Target Milestone|--- |11.4
 Target||x86_64-linux-gnu

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #5)
> Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058332.html

Harald, I looked at your patch and agree that simplification should be done.
I don't know why I did not do it when I wrote walk_array_constructor().

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #26 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #24)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> > Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> > Now I got more confused.
> 
> CCCmode means that single flag is tested, it uses EQ and NE, so "c" and "nc"
> suffix is emitted. When CCmode is used, LTU/GEU operation on CCmode flags
> reg produces "b" and "nb" suffix, which decodes to exactly the same assembly
> as "c" and "nc" suffixes.
> 
> However, it looks that somewhere LTU/GEU is also generated with CCCmode
> flags reg, and some fixup was introduced to put_condition_code to "fix" this
> inconsistency. If LTU/GEU is valid only for CCmode, then the producers of
> invalid RTX should be fixed.

EQ and NE are only used to set FLAGS_REG in CCCmode from 2 integer operands.
LTU/GEU are only used to check FLAGS_REG against constant 0.  This is very
consistent.  simplify_const_relational_operation has

 /* We can't simplify MODE_CC values since we don't know what the
 actual comparison is.  */
  if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC)
return 0;

In case of the comparison in CCCmode with constant op0 and op1, it should
let the backend perform the actual comparison.

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

[amacleod at redhat dot com via Gcc-bugs]

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

Bug 102540 Summary: [12/13 Regression] Dead Code Elimination Regression at -O3 
since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540

   What|Removed |Added

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

[Bug tree-optimization/102872] If statement is always false but not figured out at gimple level

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Macleod  ---
fixed.

[Bug tree-optimization/107252] False positive stringop-overflow, warning disappears if I remove unrelated code!

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Galvez  ---
To clarify, even removing things from the second function has an impact on the
first function (which is where the warning comes from). Shouldn't both
functions be independent?

[Bug tree-optimization/102540] [12/13 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #14 from Andrew Macleod  ---
fixed.

[Bug tree-optimization/107252] False positive stringop-overflow, warning disappears if I remove unrelated code!

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Carlos Galvez from comment #2)
> To clarify, even removing things from the second function has an impact on
> the first function (which is where the warning comes from). Shouldn't both
> functions be independent?

No because inlining heuristics takes into account the whole translation unit so
removing things changes how much inlining happens or where it happens (etc.).

The diagnostic with the warning is dependent on the inlining and optimization.

Someone will need to look into the debug dumps to understand what exactly is
going on though.

[Bug libstdc++/103621] stable_sort could call std::__merge_sort_with_buffer directly in typical case

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

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

François Dumont  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 CC||fdumont at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from François Dumont  ---
I think it has been fixed by:
commit 63d182fb86e47323ac50d9368845d712e1f7da89
Author: François Dumont 
Date:   Thu Jan 21 19:30:47 2021 +0100

libstdc++: Enhance branching in std::inplace_merge and std::stable_sort

When we manage to allocate a buffer of the expected size we can simplify
the code to
perform the expected algorithm.

libstdc++-v3/ChangeLog:

* include/bits/stl_algo.h
(__merge_adaptive): Adapt to merge only when buffer is large
enough..
(__merge_adaptive_resize): New, adapt merge when buffer is too
small.
(__inplace_merge): Adapt, use latter.
(__stable_sort_adaptive): Adapt to sort only when buffer is large
enough.
(__stable_sort_adaptive_resize): New, adapt sort when buffer is too
small.
(__stable_sort): Adapt, use latter.


Let us know otherwise.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #27 from H.J. Lu  ---
Another oddity is

  (set (pc) (if_then_else
   (eq (reg:CCO FLAGS_REG) (const_int 0))
   (label_ref (match_operand 3))
   (pc)))]

CCOmode means that the overflow flag is tested.  EQ means that the flag is set
and NE
means unset.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Harald, I looked at your patch and agree that simplification should be done.
> I don't know why I did not do it when I wrote walk_array_constructor().

Because you had only nice Fortran code in mind and for testing?

Well, I was wondering where the necessary simplifications would fit best.
walk_array_constructor is just one place, and if it hasn't happened before,
then it needs to be ensured there.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #8 from Steve Kargl  ---
On Thu, Oct 13, 2022 at 06:43:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
> 
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #6)
> > Harald, I looked at your patch and agree that simplification should be done.
> > I don't know why I did not do it when I wrote walk_array_constructor().
> 
> Because you had only nice Fortran code in mind and for testing?
> 

Yep!  This probably is the root of 90% of Gerhard's bug reports.

If regtesting complete ok, and Mikael doesn't find any additional
problems.  Please commit.

[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (GCC 11 only, Fortran)

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-13
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed with r12-2051-g7d810646d421f697 and started with
r11-2453-gc89366b12ff4f362.

@Richi: Can you please take a look?

[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (GCC 11 only, Fortran)

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Fixed with r12-2051-g7d810646d421f697 and started with
> r11-2453-gc89366b12ff4f362.

If so there might be a latent bug still 

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #8)
> If regtesting complete ok,

This is the case.

> and Mikael doesn't find any additional problems.  Please commit.

The only thing I was fearing^Wexpecting is that he finds a better place
for the fix.

When varying various related testcases, one encounters from time to time
the error "Array operands are incommensurate" (ARITH_INCOMMENSURATE).
This seems to go back all the way to the beginnings of gfortran (r0-58166),
and there is no helpful commit message.  However, this error message can
lead to confusion, and there are related PRs.

Do you know the history of this?

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #10 from Steve Kargl  ---
On Thu, Oct 13, 2022 at 07:09:28PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
> 
> --- Comment #9 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #8)
> > If regtesting complete ok,
> 
> This is the case.
> 
> > and Mikael doesn't find any additional problems.  Please commit.
> 
> The only thing I was fearing^Wexpecting is that he finds a better place
> for the fix.
> 
> When varying various related testcases, one encounters from time to time
> the error "Array operands are incommensurate" (ARITH_INCOMMENSURATE).
> This seems to go back all the way to the beginnings of gfortran (r0-58166),
> and there is no helpful commit message.  However, this error message can
> lead to confusion, and there are related PRs.
> 
> Do you know the history of this?
> 

Unfortunately, no.  I believe g95 came into GCC as gfortran in the
tree-ssa branch (under cvs).  At one time, one could check on-line
the branches under subversion.  I cannot find a tree-ssa branch under
git with the on-line repository.  I suspect this dates back to g95, 
and falls under the development where one assumes only correctly
written standard conforming Fortran is fed into gfortran.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #11 from Mikael Morin  ---
(In reply to Steve Kargl from comment #8)
> If regtesting complete ok, and Mikael doesn't find any additional
> problems.  Please commit.

Unfortunately, I think there is one problem.
Generally speaking, I don't like doing too much at parsing stage, and
especially simplifying.  It's too early in my opinion.

Here is an example, where the array simplifies using the host-associated
parameter value instead of calling the contained function with the same name
hiding it.  It is admittedly somewhat artificial.

module m
  implicit none
  integer, parameter :: a(*) = [ 7, 11 ]
contains
  subroutine bug
real :: b(1)
b = [ real :: (a(1)) ]
print *, b
if (any(b /= [ 14. ])) stop 1
  contains
function a(c)
  integer :: a, c
  a = c + 13
end function a
  end subroutine bug
end module m

program p
  use m
  call bug
end program p

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #11)
> Here is an example, where the array simplifies using the host-associated
> parameter value instead of calling the contained function with the same name
> hiding it.  It is admittedly somewhat artificial.

But it is a valid (counter-)example ... :-(

Symptoms: invalid declarations, such as

real :: b(1) = [ real :: (a(1)) ]

or

real, parameter :: b(1) = [ real :: (a(1)) ]

are not diagnosed, also not by the Intel compiler, but by NAG:

Error: pr93483-mm.f90, line 6: Reference to non-intrinsic function A in
constant expression

So this looks like a can of worms...

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #13 from Steve Kargl  ---
On Thu, Oct 13, 2022 at 07:35:30PM +, mikael at gcc dot gnu.org wrote:
> 
> --- Comment #11 from Mikael Morin  ---
> (In reply to Steve Kargl from comment #8)
> > If regtesting complete ok, and Mikael doesn't find any additional
> > problems.  Please commit.
> 
> Unfortunately, I think there is one problem.
> Generally speaking, I don't like doing too much at parsing stage, and
> especially simplifying.  It's too early in my opinion.
> 
> Here is an example, where the array simplifies using the host-associated
> parameter value instead of calling the contained function with the same name
> hiding it.  It is admittedly somewhat artificial.
> 

If might be artificial, but "wrong code" is not a pleasant
side effect.

There is array.cc:gfc_resolve_array_constructor().  I haven't
looked to see when, or even if, this is called when compiling
the examples that Gerhard, Harald, and you have devised.

[Bug analyzer/107210] [13 Regression] ICE in tree_to_uhwi, at tree.cc:6392 since r13-3168-gf09b99550a3c6cd1

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:99da523359e933385484eb3b8f854a98f1b4

commit r13-3285-g99da523359e933385484eb3b8f854a98f1b4
Author: David Malcolm 
Date:   Thu Oct 13 16:05:35 2022 -0400

analyzer: fix ICE introduced in r13-3168 [PR107210]

gcc/analyzer/ChangeLog:
PR analyzer/107210
* svalue.cc (constant_svalue::maybe_fold_bits_within): Only
attempt to extract individual bits when tree_fits_uhwi_p.

gcc/testsuite/ChangeLog:
PR analyzer/107210
* gfortran.dg/analyzer/pr107210.f90: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107210] [13 Regression] ICE in tree_to_uhwi, at tree.cc:6392 since r13-3168-gf09b99550a3c6cd1

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above patch

[Bug target/107248] Sparc V8 Invalid Stack Pointer Code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-13
   Keywords||ABI, wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Looks like for sparc_leaf_function_p, there is a missing a emit_insn
(gen_frame_blockage ()) .

Which was added in the non leaf case with r0-114040-ge98b1defdd2c6b .

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Is it conceivable that a somewhat weaker form of simplification, which
addresses the parentheses as well as the basic unary and binary operators
could still be used for the time being?

There is simplify_intrinsic_op; it just needs to be made non-static.
And seems to work here, also for Mikael's example.

So on top of the posted patch,

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 9bec299f160..4e937a4990f 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1207,7 +1207,7 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   e = c->expr;

   if (e->expr_type == EXPR_OP)
-   gfc_simplify_expr (e, 0);
+   simplify_intrinsic_op (e, 0);

   if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
  && !e->ref && e->value.constructor)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 10bb098d136..37dceacbb54 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3627,6 +3627,7 @@ gfc_expr *gfc_build_conversion (gfc_expr *);
 void gfc_free_ref_list (gfc_ref *);
 void gfc_type_convert_binary (gfc_expr *, int);
 bool gfc_is_constant_expr (gfc_expr *);
+bool simplify_intrinsic_op (gfc_expr *, int);
 bool gfc_simplify_expr (gfc_expr *, int);
 bool gfc_try_simplify_expr (gfc_expr *, int);
 int gfc_has_vector_index (gfc_expr *);

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #14)
> Is it conceivable that a somewhat weaker form of simplification, which
> addresses the parentheses as well as the basic unary and binary operators
> could still be used for the time being?
> 
> There is simplify_intrinsic_op; it just needs to be made non-static.
> And seems to work here, also for Mikael's example.
> 
> So on top of the posted patch,

Argh, this doesn't work.  My fault.

[Bug ipa/107249] ipa-sra.cc:3030:1: error: insertion out of range in 'bit_insert_expr'

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

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

John David Anglin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #2 from John David Anglin  ---
Yes.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #16 from Steve Kargl  ---
On Thu, Oct 13, 2022 at 08:56:55PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
> 
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to anlauf from comment #14)
> > Is it conceivable that a somewhat weaker form of simplification, which
> > addresses the parentheses as well as the basic unary and binary operators
> > could still be used for the time being?
> > 
> > There is simplify_intrinsic_op; it just needs to be made non-static.
> > And seems to work here, also for Mikael's example.
> > 
> > So on top of the posted patch,
> 
> Argh, this doesn't work.  My fault.
> 

gfc_simplify_expr will call simplify_intrinsic_op.  Thisi, I think,
leads to arith.cc:gfc_uplus and arith.cc:gfc_parentheses.  These
simply copy the expression to a new expression without trying to reduce
the expression, and then returns.  For unary plus, instead of copying
the expression, gfortran could copy the operand.  For parentheses,
one would need to walk the expression to see if it can be reduced.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #28 from Segher Boessenkool  ---
> So the issue is with the consumer:
> 
> (insn 50 49 51 2 (parallel [
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags)
> (const_int 0 [0]
> (clobber (reg:CC 17 flags))
> ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
>  (expr_list:REG_DEAD (reg:CCC 17 flags)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> 
> There are many similar patterns in different backends.  They work as long as
> the flags register isn't a known constant since simplify-rtx.cc leaves them
> alone.  They become a problem only when the flags register is a known
> constant.

Such patterns are fine.  The problem is that this consumer of MODE_CC does not
fit together with the producer of that reg 17: it only has meaning together,
that
is how this stuff works; and it has no meaning at all like this.

[Bug target/107248] wrong scheduling of stack adjustment in leaf function at -O2

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
Summary|Sparc V8 Invalid Stack  |wrong scheduling of stack
   |Pointer Code|adjustment in leaf function
   ||at -O2
   Keywords|ABI |
 Target|sparc-rtems |sparc-*-*

--- Comment #3 from Eric Botcazou  ---
Yes, it's the same bug as on ARM and MIPS, but one decade later...

[Bug target/107248] wrong scheduling of stack adjustment in leaf function at -O2

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #29 from Segher Boessenkool  ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> Now I got more confused.

(eq (reg:CCC 17) (const_int 0))  means that the comparison that did set reg 17
returned "equal".

CCCmode is just like CCmode, but *only* the carry flag is valid.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #30 from Segher Boessenkool  ---
(In reply to H.J. Lu from comment #26)
> LTU/GEU are only used to check FLAGS_REG against constant 0.

That is not what
  (ltu (reg 17) (const_int 0))
means though?

Together with a previous
  (set (reg 17) (compare A B))

it means the result of A <= B.

There is no actual comparison with 0, that is just notation.

> simplify_const_relational_operation has
> 
>  /* We can't simplify MODE_CC values since we don't know what the
>  actual comparison is.  */
>   if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC)
> return 0;

And combine *does* know how to find the actual comparison, in many cases.  Some
other passes can as well, there is no magic involved, you just need to look at
other insns as well (just one really, the CC setter).

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #31 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #29)
> (In reply to Hongtao.liu from comment #23)
> > looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> > (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> > Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
> > Now I got more confused.
> 
> (eq (reg:CCC 17) (const_int 0))  means that the comparison that did set reg
> 17
> returned "equal".
> 

Isn't the meaning of MODE_CC comparison only known to the backend? On x86, EQ
in

  (set (pc) (if_then_else
   (eq (reg:CCO FLAGS_REG) (const_int 0))
   (label_ref (match_operand 3))
   (pc)))]

doesn't evaluate to true when (reg:CCO FLAGS_REG) is 0.  It is true when
(reg:CCO FLAGS_REG) is set.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #32 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #30)
> (In reply to H.J. Lu from comment #26)
> > LTU/GEU are only used to check FLAGS_REG against constant 0.
> 
> That is not what
>   (ltu (reg 17) (const_int 0))
> means though?
> 
> Together with a previous
>   (set (reg 17) (compare A B))
> 
> it means the result of A <= B.

That is correct.

> There is no actual comparison with 0, that is just notation.

True.  But simplify-rtx.cc simplifies

(ltu (reg 17) (const_int 0))

to false when reg 17 is set.

> > simplify_const_relational_operation has
> > 
> >  /* We can't simplify MODE_CC values since we don't know what the
> >  actual comparison is.  */
> >   if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC)
> > return 0;
> 
> And combine *does* know how to find the actual comparison, in many cases. 
> Some
> other passes can as well, there is no magic involved, you just need to look
> at
> other insns as well (just one really, the CC setter).

Use the actual comparison isn't issue.  The issue is how

(ltu (reg 17) (const_int 0))

should be simplified when reg 17 is known to be set.

[Bug c++/107255] New: ation and definition of a template function which vary in use of concept auto syntax are interpreted as ambiguous overloadsdeclar

[enolan at alumni dot cmu.edu via Gcc-bugs]

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

Bug ID: 107255
   Summary: ation and definition of a template function which vary
in use of concept auto syntax are interpreted as
ambiguous overloadsdeclar
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

This is a rejects-valid bug where GCC has trouble determining that a
declaration and definition which vary only in their use of concept auto syntax
are for the same function and not multiple ambiguous overloads.

Compiler explorer link: https://godbolt.org/z/4Tjcz49d9

Minimal reproduction:

template 
concept Foo = true;

void bar(Foo auto);

template 
void bar(F) {}

void baz() {
bar(0);
}

> the exact version of GCC

gcc version 12.2.1 20220819 (Red Hat 12.2.1-2) (GCC)

> the system type

Fedora release 38 (Rawhide)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ -std=c++20 poc.cpp

> the compiler output

poc.cpp: In function ‘void baz()’:
poc.cpp:10:8: error: call of overloaded ‘bar(int)’ is ambiguous
   10 | bar(0);
  | ~~~^~~
poc.cpp:4:6: note: candidate: ‘void bar(auto:1) [with auto:1 = int]’
4 | void bar(Foo auto);
  |  ^~~
poc.cpp:7:6: note: candidate: ‘void bar(F) [with F = int]’
7 | void bar(F) {}
  |  ^~~

[Bug c++/107256] New: Contradictory circular noexcept-specifier is accepted

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 107256
   Summary: Contradictory circular noexcept-specifier is accepted
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

This code snipet is currently accepted by gcc while the noexcept-specifier
cannot be meaningful.

struct Weird {
static void f() noexcept(!noexcept(Weird::f())) {}
};

Godbolt link: https://godbolt.org/z/hqnha3aPd

The code was rejected by gcc 9 and earlier versions, but with a seemly
incorrect reason (error: incomplete type 'Weird' used in nested name
specifier). According to CWG DR 1330 and current wording in [class.mem.general]
/7, the noexcept-specifier establishes a complete-class context, so Weird is
complete inside it.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #3 from Jiang An  ---
https://cplusplus.github.io/LWG/issue3793 has been submitted.

Such requirement was originally added by N0700
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0700.pdf), but
intented target types were unknown.

[Bug target/107160] [12 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

--- Comment #18 from Kewen Lin  ---
Thanks for the prompt fix! I just verified it fixed the SPEC2006 447.dealII
regression perfectly.

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
Awesome, thanks a lot for the quick fix!

[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (GCC 11 only, Fortran)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #3 from Richard Biener  ---
(In reply to Martin Liška from comment #1)
> Fixed with r12-2051-g7d810646d421f697 and started with
> r11-2453-gc89366b12ff4f362.
> 
> @Richi: Can you please take a look?

Can you bisect with -fno-vect-cost-model?  The r11-2453-gc89366b12ff4f362 just
affects cost modeling.

And yes, the "fix" eventually just hides a SLP pattern bug.