[Bug tree-optimization/115925] [14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
/* x | C -> C if we know that x & ~C == 0.  */
(simplify
 (bit_ior SSA_NAME@0 INTEGER_CST@1)
 (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
  && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
  @1))
#endif


Again ...

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

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

[Bug tree-optimization/115925] [14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
ANTIC_OUT[8] := { i_9 (0009), _3 (0003), _18 (0018), {bit_ior_expr,_3,_18}
(0023) }
[changed] ANTIC_IN[8] := { i_9 (0009), _3 (0003),
{mem_ref<0B>,addr_expr<&f>}@.MEM_14 (0005), {nop_expr,f.5_5} (0018),
{bit_ior_expr,_3,_18} (0023) }
S[8] := { i_9 (0009), _3 (0003), {bit_ior_expr,_3,_18} (0023) }
Matching expression match.pd:196, gimple-match-6.cc:22
Matching expression match.pd:172, gimple-match-9.cc:30
Matching expression match.pd:172, gimple-match-9.cc:30
Matching expression match.pd:194, gimple-match-6.cc:39
Matching expression match.pd:172, gimple-match-9.cc:30
Applying pattern match.pd:1667, gimple-match-1.cc:9521
Applying pattern match.pd:1460, gimple-match-1.cc:1214

Dup of bug 115494.

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

[Bug tree-optimization/115872] [12/13/14/15 regression] ICE in fab pass (error: missing definition with -g & -O3)

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r15-2038-gf27bf48e0204524ead795fe618cd8b1224f72fd4
Author: liuhongt 
Date:   Fri Jul 12 09:39:23 2024 +0800

Fix SSA_NAME leak due to def_stmt is removed before use_stmt.

-  _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0);
-  # DEBUG old => (long int) _5
+  _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0,
__atomic_fetch_or_8);
+  # DEBUG old => NULL
   # DEBUG BEGIN_STMT
-  # DEBUG D#2 => _5 & 1
+  # DEBUG D#2 => NULL
...
-  _10 = ~_5;
-  _8 = (_Bool) _10;
-  # DEBUG ret => _8
+  _8 = _6 == 0;
+  # DEBUG ret => (_Bool) _10

confirmed.  convert_atomic_bit_not does this, it checks for single_use
and removes the def, failing to release the name (which would fix this up
IIRC).

Note the function removes stmts in "wrong" order (before uses of LHS
are removed), so it requires larger surgery.  And it leaks SSA names.

gcc/ChangeLog:

PR target/115872
* tree-ssa-ccp.cc (convert_atomic_bit_not): Remove use_stmt after
use_nop_stmt is removed.
(optimize_atomic_bit_test_and): Ditto.

gcc/testsuite/ChangeLog:

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

[Bug fortran/99798] ICE when compiling a variant of pr87907

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #6 from Mikael Morin  ---
Fixed for 15.1 and 14.2, closing.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 58663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58663&action=edit
Reduced testcase based on suggestion

Reduced testcase based on comment #8.
Notes on it, you need a and b be different types so there is a cast for b to
anchor the range on it inside the if. The input value of a does not matter in
this case as since flag is sets a to 1.

[Bug middle-end/115863] [15 Regression] zlib-1.3.1 miscompilation since r15-1936-g80e446e829d818

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Li Pan from comment #8)
> (In reply to Richard Biener from comment #7)
> > (In reply to Uroš Bizjak from comment #6)
> > > Please note that w/o .SAT_TRUNC the compiler is able to optimize hot loop 
> > > in
> > > compress2 to:
> > > 
> > >[local count: 536870912]:
> > >   _18 = MIN_EXPR ;
> > >   iftmp.0_11 = (unsigned int) _18;
> > >   stream.avail_out = iftmp.0_11;
> > >   left_37 = left_8 - _18;
> > > 
> > > while .SAT_TRUNC somehow interferes with this optimization to produce:
> > > 
> > >[local count: 536870912]:
> > >   _45 = MIN_EXPR ;
> > >   iftmp.0_11 = .SAT_TRUNC (left_8);
> > >   stream.avail_out = iftmp.0_11;
> > >   left_37 = left_8 - _45;
> > 
> > it looks like whatever recognizes .SAT_TRUNC doesn't pay attention that
> > there are other uses of the MIN_EXPR and thus the MIN_EXPR stays live.
> > 
> > IIRC :s on (match (...) is ignored (and that's good IMO) at the moment so
> > the user of the match predicate has to check.
> 
> Thanks Richard.
> Yes, the .SAT_TRUNC doesn't pay any attention the other possible use of
> MIN_EXPR.
> 
> As your suggestion, we may need one additional check here (like
> gimple_unsigned_sat_trunc() && no_other_MIN_EXPR_use_after_sat_trunc_p ())
> before we build the SAT_TRUNC call.
> Sorry I didn't get the point here why we need to do this, could you please
> help to explain a bit more about it? Like wrong code or something else in
> above
> sample code.

I'd amend the captured ops, like

(match (unsigned_integer_sat_trunc @0 @2)
 (convert (min@2 @0 INTEGER_CST@1))

(match (unsigned_integer_sat_trunc @0 @2)
 (bit_ior:c (negate (convert (gt@2 @0 INTEGER_CST@1)))

and in the transform do

  if (gimple_unsigned_integer_sat_trunc (lhs, ops, NULL)
&& has_single_use (ops[1])
&& direct_internal_fn_supported_p (IFN_SAT_TRUNC,

that would be the most simple way to avoid this.  Note it avoids the
alternate use for both the MIN_EXPR and the compare (for the 2nd pattern
it might be required to have more ops to check that, the convert and also the
negate).  I think you can't do

(match (unsigned_integer_sat_trunc @0 @2 @3 @4)
 (convert (min@2@3@4 @0 INTEGER_CST@1))

at the moment, but the machinery actually supports it for the case of
(convert?@1 (op@2 ...  where @1 and @2 refer to the same object when
the compare is not there.  So it might be a matter of amending parsing
here - of course it's a bit ugly.

Having a helper that can tell there's no external uses of a SSA chain
denoted by two end-points, namely the match root (the first op
you give to gimple_unsigned_integer_sat_trunc) and the "tail", the
matched ops[0] would be a nice thing to have.  Note that ops[0] is
the "wrong" root, so I think we want to match the real relevant
root which would be the compare in one case and the min in the other.
>From that the requirement would be

  tree op = ops[0];
  while (single_imm_use (op, &use_p, &use_stmt))
{
  auto def = single_ssa_def_operand (use_stmt, SSA_OP_USE);
  op = DEF_FROM_PTR (def);
  if (op == lhs)
return true;
}
  return false;

and maybe call such helper gimple_isolated_expr_p (tree def, tree leaf);
where in principle this could support multiple leafs (just repeat the
above for each leaf).

The match.pd machinery could support this itself of course, you can
either add single_use () conditionals yourself, implement :s on the
individual operands or have a way to mark the whole expression in this
way.

So the easiest way is to do.  My above remarks are for some more general
utility.

(match (unsigned_integer_sat_trunc @0)
 (convert (min@2 @0 INTEGER_CST@1))
 (if (INTEGRAL_TYPE_P (type) && TYPE_UNSIGNED (type)
  && TYPE_UNSIGNED (TREE_TYPE (@0))
  && single_use (@2))

[Bug sanitizer/81598] -fsanitize=enum does not detect range violation

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org

--- Comment #10 from Nathaniel Shead  ---
(In reply to Julien Blanc from comment #9)
> I recently ran into this while trying to use -fsanitize=enum for the
> codebase. The situation is worse for C++ enum class : since you can only
> assign them with static_cast, no load check can be done (clang also fails to
> detect such cases).
> 
> Here’s a sample code that should trigger but does not :
> 
> #include 
>   
> enum class Foo
> {
> foo1 = 0,
> foo2 = 1
> };
> std::ostream& operator<<(std::ostream& o, Foo foo)
> {
> switch(foo)
> {
> case Foo::foo1:
> return o << "foo1";
> case Foo::foo2:
> return o << "foo2";
> }
> return o << "unknown";
> }
> int main()
> {
> Foo foo = static_cast(3);
> std::cout << foo << std::endl;
> return 0;
> }
> 
> 
> $ g++ -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover enum.cpp 
> $ ./a.out 
> unknown
> $
> 
> Note that clang++ is no better :
> 
> $ clang++-7 -fsanitize=enum -fsanitize=undefined -fno-sanitize-recover=all
> enum.cpp 
> $ ./a.out 
> unknown
> $
> 
> But i’d expect both checkers to detect such misuse. While it could be valid
> code, there’s a high chance that its a bug. Ideally an attribute could be
> used if it is expected behaviour.

FWIW I don't think this particular case is UB; an 'enum class' has fixed
underlying type (int by default), and so the valid values are any that fit in
the range of 'int'.

In particular this is relevant because 'std::byte' is defined like `enum class
byte : unsigned char {};`, and providing such values should not cause a
warning/error.

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|531.deepsjeng_r fails to|[14/15 Regression]
   |verify with -O3 |531.deepsjeng_r fails to
   |-march=znver4 --param   |verify with -O3
   |vect-partial-vector-usage=2 |-march=znver4 --param
   ||vect-partial-vector-usage=2
  Known to fail||14.1.1, 15.0
  Known to work||13.3.0
   Target Milestone|--- |14.2

--- Comment #2 from Richard Biener  ---
Verified on trunk as well, works with 13.3

[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #13 from LIU Hao  ---
(In reply to LIU Hao from comment #12)
> Created attachment 58662 [details]
> test patch

This fixes the issue for me on x86_64-w64-mingw32.

Note this is actually not target-specific; all targets that implement COMDAT
but not as weak symbols are affected. `decl_binds_to_current_def_p` already
contains a check for weak symbols, so the issue is invisible if COMDAT is
implemented as weak symbols, for example on Linux.

[Bug tree-optimization/115933] New: wrong code at -O1 with "-fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 115933
   Summary: wrong code at -O1 with "-fno-tree-loop-optimize
-ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression as it doesn't reproduce with 14.1 and
earlier.

Compiler Explorer: https://godbolt.org/z/5PoGKzzcx

[550] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240715 (experimental) (GCC) 
[551] % 
[551] % gcctk -O1 -fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse
small.c
[552] % ./a.out
Aborted
[553] % 
[553] % cat small.c
int a, b;
unsigned c() {
  int d, e = d = 2;
  if (a < 0)
for (e = 0; e < 1; e++)
  d = 0;
  b = e;
  return d;
}
int main() {
  c();
  if (b != 2)
__builtin_abort();
  return 0;
}

[Bug tree-optimization/115766] [12/13/14 Regression] wrong code at optimization levels -O2, -O3

[bic60176 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Bi6c  ---
Created attachment 58664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58664&action=edit
reduced testcase

I reduced the testcase and removed the csmith dependency.

[Bug tree-optimization/115766] [12/13/14 Regression] wrong code at optimization levels -O2, -O3

[bic60176 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Bi6c  ---
Created attachment 58665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58665&action=edit
preprocessed file w/o csmith.h dependency

Preprocessed file w/o csmith.h dependency

[Bug tree-optimization/115766] [12/13/14 Regression] wrong code at optimization levels -O2, -O3

[bic60176 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Bi6c  ---
The discrepancy also appeared when compiling with optimization level -Os

[Bug middle-end/115913] [11/12/13/14/15 Regression] ICE with pragma GCC pop_options with diagnostic

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|15.0|11.5

[Bug middle-end/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |15.0

[Bug ada/115918] [15 regression] Bootstrap failure in GNAT with --with-build-config=bootstrap-lto --enable-languages=c,ada,c++,lto

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug rtl-optimization/115933] [15 Regression] wrong code at -O1 with "-fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|wrong code at -O1 with  |[15 Regression] wrong code
   |"-fno-tree-loop-optimize|at -O1 with
   |-ftree-vrp -fno-tree-ch |"-fno-tree-loop-optimize
   |-fgcse" on x86_64-linux-gnu |-ftree-vrp -fno-tree-ch
   ||-fgcse" on x86_64-linux-gnu
   Keywords||needs-bisection
   Target Milestone|--- |15.0
   Last reconfirmed||2024-07-15

--- Comment #1 from Andrew Pinski  ---
Confirmed.  The gimple level looks ok.

Ifcvt (ce2) seems not to like:

```
(insn 4 3 18 3 (set (reg/v:SI 99 [ d ])
(const_int 2 [0x2])) "/app/example.c":3:16 89 {*movsi_internal}
 (nil))
(insn 18 4 5 3 (set (reg/v:SI 100 [ e ])
(const_int 0 [0])) "/app/example.c":5:19 discrim 1 89 {*movsi_internal}
 (nil))
(insn 5 18 40 3 (set (reg/v:SI 99 [ d ])
(reg/v:SI 100 [ e ])) "/app/example.c":6:9 89 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 100 [ e ])
(nil)))
(insn 40 5 20 3 (set (reg/v:SI 100 [ e ])
(const_int 1 [0x1])) "/app/example.c":5:25 discrim 3 89
{*movsi_internal}
 (nil))
```
as a if bb.

[Bug rtl-optimization/115928] [15 regression] ICE on valid code at -O2 with "-fgcse-sm" on x86_64-linux-gnu: in merge_clobber_groups, at rtl-ssa/accesses.cc:757

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Version|unknown |15.0

[Bug rtl-optimization/115932] [15 Regression] performance regression after r15-1619-g3b9b8d6cfdf593

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||missed-optimization

[Bug rtl-optimization/115928] [15 regression] ICE on valid code at -O2 with "-fgcse-sm" on x86_64-linux-gnu: in merge_clobber_groups, at rtl-ssa/accesses.cc:757

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-15
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
bitboard.o is miscompiled.  All of the following individually

bitboard.cpp:466:19: optimized: loop vectorized using 64 byte vectors
bitboard.cpp:456:19: optimized: loop vectorized using 64 byte vectors
bitboard.cpp:301:19: optimized: loop vectorized using 64 byte vectors

but not

bitboard.cpp:395:23: optimized: loop vectorized using 32 byte vectors
bitboard.cpp:391:23: optimized: loop vectorized using 64 byte vectors
bitboard.cpp:369:23: optimized: loop vectorized using 32 byte vectors
bitboard.cpp:369:23: optimized: loop vectorized using 16 byte vectors

are enough to trigger failure.

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

--- Comment #4 from Richard Biener  ---
The loops are

for (i = 0; i < 64; i++) {
KnightMoves[i] = 0;

if (Rank(i) > 0) { 
if (Rank(i) > 1) {
if (File(i) > 0) KnightMoves[i] |= Mask[i-17];
if (File(i) < 7) KnightMoves[i] |= Mask[i-15];
}
if (File(i) > 1) KnightMoves[i] |= Mask[i-10];
if (File(i) < 6) KnightMoves[i] |= Mask[i-6];
}

if (Rank(i) < 7) {
if (Rank(i) < 6) {
if (File(i) > 0) KnightMoves[i] |= Mask[i+15];
if (File(i) < 7) KnightMoves[i] |= Mask[i+17];
}
if (File(i) > 1) KnightMoves[i] |= Mask[i+6];
if (File(i) < 6) KnightMoves[i] |= Mask[i+10];
}
}

for (i = 0; i < 64; i++) {
if (File(i) == FileA) {
KingPressureMask[i] = KingSafetyMask[i + 1];
} else if (File(i) == FileH) {
KingPressureMask[i] = KingSafetyMask[i - 1];
} else {
KingPressureMask[i] = KingSafetyMask[i];
}   
} 

for (i = 0; i < 64; i++) {
if (File(i) == FileA) {
KingPressureMask1[i] = KingSafetyMask1[i + 1];
} else if (File(i) == FileH) {
KingPressureMask1[i] = KingSafetyMask1[i - 1];
} else {
KingPressureMask1[i] = KingSafetyMask1[i];
}   
}  

the last loop is

   [local count: 145013]:

   [local count: 9271420]:
  # i_38 = PHI <_1526(215), 0(302)>
  # ivtmp_1427 = PHI 
  _296 = i_38 & 7;
  _1526 = i_38 + 1;
  _380 = _296 == 0;
  _1371 = &KingSafetyMask1[_1526];
  _298 = .MASK_LOAD (_1371, 64B, _380);
  _804 = _296 == 7;
  _1370 = (unsigned int) i_38;
  _1369 = _1370 + 4294967295;
  _299 = (int) _1369;
  _1368 = &KingSafetyMask1[_299];
  _300 = .MASK_LOAD (_1368, 64B, _804);
  _301 = KingSafetyMask1[i_38];
  _ifc__1431 = _804 ? _300 : _301;
  _336 = _380 ? _298 : _ifc__1431;
  KingPressureMask1[i_38] = _336;
  ivtmp_1430 = ivtmp_1427 - 1;
  if (ivtmp_1430 != 0)
goto ; [98.44%]
  else
goto ; [1.56%]

   [local count: 9126407]:
  goto ; [100.00%]

vectorized as

   [local count: 579464]:
  # vect_vec_iv_.194_1737 = PHI <_1915(215), { -15, -14, -13, -12, -11, -10,
-9, -8, -7, -6, -5, -4, -3, -2, -1, 0 }(198)>
  # vectp_KingSafetyMask1.198_1768 = PHI  [(void *)&KingSafetyMask1 + -112B](198)>
  # vectp_KingSafetyMask1.204_1878 = PHI  [(void *)&KingSafetyMask1 + -128B](198)>
  # vectp_KingSafetyMask1.208_2015 = PHI  [(void *)&KingSafetyMask1 + -120B](198)>
  # vectp_KingPressureMask1.216_2023 = PHI
 [(void
*)&KingPressureMask1 + -120B](198)>
  # ivtmp_2028 = PHI 
  # loop_mask_1995 = PHI <_1989(215), { 0, 0, 0, 0, 0, 0, 0, 0 }(198)>
  # loop_mask_1860 = PHI <_1990(215), { 0, 0, 0, 0, 0, 0, 0, 0 }(198)>
  _1915 = vect_vec_iv_.194_1737 + { 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16 };
  vect__296.195_1901 = vect_vec_iv_.194_1737 & { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7 };
  mask__380.196_1920 = vect__296.195_1901 == { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 };
  mask_patt_1854.197_1855 = [vec_unpack_lo_expr] mask__380.196_1920;
  mask_patt_1854.197_1733 = [vec_unpack_hi_expr] mask__380.196_1920;
  vec_mask_and_1997 = mask_patt_1854.197_1855 & loop_mask_1860;
  vect_patt_1732.200_1998 = .MASK_LOAD (vectp_KingSafetyMask1.198_1768, 128B,
vec_mask_and_1997);
  vectp_KingSafetyMask1.198_1865 = vectp_KingSafetyMask1.198_1768 + 64;
  vec_mask_and_2002 = mask_patt_1854.197_1733 & loop_mask_1995;
  vect_patt_1732.201_2003 = .MASK_LOAD (vectp_KingSafetyMask1.198_1865, 128B,
vec_mask_and_2002);
  mask__804.202_1876 = vect__296.195_1901 == { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7 };
  mask_patt_1734.203_2005 = [vec_unpack_lo_expr] mask__804.202_1876;
  mask_patt_1734.203_2007 = [vec_unpack_hi_expr] mask__804.202_1876;
  vec_mask_and_2010 = mask_patt_1734.203_2005 & loop_mask_1860;
  vect_patt_1772.206_2012 = .MASK_LOAD (vectp_KingSafetyMask1.204_1878, 512B,
vec_mask_and_2010);
  vectp_KingSafetyMask1.204_2013 = vectp_KingSafetyMask1.204_1878 + 64;
  vec_mask_and_1980 = mask_patt_1734.203_2007 & loop_mask_1995;
  vect_patt_1772.207_1981 = .MASK_LOAD (vectp_KingSafetyMask1.204_2013, 512B,
vec_mask_and_1980);
  vect__301.210_1882 = .MASK_LOAD (vectp_KingSafetyMask1.208_2015, 64B,
loop_mask_1860);
  vectp_KingSafetyMask1.208_2018 = vectp_KingSafetyMask1.208_2015 + 64;
  vect__301.211_2019 = .MASK_LOAD (vectp_KingSafetyMask1.208_2018, 64B,
loop_mask_1995);
  vect_patt_1775.213_2021 = VEC_COND_EXPR ;
  vect_patt_1775.213_2022 = VEC_COND_EXPR ;
  vect_patt_1897.215_1984 = VEC_COND_EXPR ;
  vect_patt_1897.215_1985 = VEC_COND_EXPR ;
  .MASK_STORE (vectp_KingPressureMask1.216_2023, 64B, loop_mask_1860,
vect_patt_1897.215_1984);
  vectp_KingPressureMask1.216_2026 = vectp_KingPressureMask1.216_2023 + 64;
  .MASK_STORE (vectp_KingPressureMask1.216_2026, 64B, loop_mask_1995,
vect_patt_1

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #5 from Richard Biener  ---
The following fails with -O3 -mavx512vl --param vect-partial-vector-usage=2
-mtune=znver4 -mprefer-vector-width=512 but succeeds with -mtune=cascadelake.

typedef __UINT64_TYPE__ BITBOARD;
BITBOARD KingPressureMask1[64], KingSafetyMask1[64];

void __attribute__((noinline))
foo()
{
  int i;

  for (i = 0; i < 64; i++) {
  if ((i & 7) == 0) {
  KingPressureMask1[i] = KingSafetyMask1[i + 1];
  } else if ((i & 7) == 7) {
  KingPressureMask1[i] = KingSafetyMask1[i - 1];
  } else {
  KingPressureMask1[i] = KingSafetyMask1[i];
  }
  }
}

BITBOARD verify[64] = {1, 1, 2, 3, 4, 5, 6, 6, 9, 9, 10, 11, 12, 13, 14, 14,
17, 17, 18, 19, 
  20, 21, 22, 22, 25, 25, 26, 27, 28, 29, 30, 30, 33, 33, 34, 35, 36, 37, 38, 
  38, 41, 41, 42, 43, 44, 45, 46, 46, 49, 49, 50, 51, 52, 53, 54, 54, 57, 57, 
  58, 59, 60, 61, 62, 62};

int main()
{
  for (int i = 0; i < 64; ++i)
KingSafetyMask1[i] = i;
  foo ();
  for (int i = 0; i < 64; ++i)
if (KingPressureMask1[i] != verify[i])
  __builtin_abort ();
  return 0;
}

[Bug c++/101992] new object was created erroneously when co_await on function call that return lvalue reference

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #1 from Arsen Arsenović  ---
Fixed in r12-9435-g6fd32842404ac1.

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

[Bug c++/105406] [11 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||lbqq at gmail dot com

--- Comment #8 from Arsen Arsenović  ---
*** Bug 101992 has been marked as a duplicate of this bug. ***

[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused

[michal.jankovic59 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Michal Jankovič  ---
(In reply to Arsen Arsenović from comment #6)
> hi, thanks for the patch.  could you propose it on the ML?  patches seldom
> get noticed here on BZ (see also https://gcc.gnu.org/contribute.html )

Hi, I have submitted it on the ML multiple times, I couldn't get the owner of
the coroutines code to review it though.

I Guess it's time to try again :)

[Bug ipa/110057] Missed devirtualization opportunities

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

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to user202729 from comment #16)
> That sound like a good idea, thanks. I thought about this some time earlier
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413#c3) but I did not know
> how to check the implementation of `destroy()`.

You only need to know if Alloc::destroy exists or not.

> Nevertheless, this does not handle the case of devirtualization in vector
> access (e.g. `v[0].f()` where v is a vector and method f is virtual). What
> do you think?

I don't think that optimization would be valid. Users could do disgusting
things like this (as long as sizeof(Base) == sizeof(Derived)):

std::vector v(1);
v[0].~Base();
::new((void*)v.data()) Derived();
v[0].f();
v[0].~Derived();
::new((void*)v.data()) Base();

I'm not even 100% convinced that the destructor optimization is valid, but I
think any time there is pointer arithmetic on the vector's storage, the dynamic
types of objects in the array must match the static types. Arguably the v[0]
access above already requires that, so maybe the code above isn't valid, but I
don't think it's entirely clear from the standard.

This certainly seems to be allowed:

std::vector v(1);
Base* p = v.data();
p->~Base();
::new((void*)p) Derived();
p->f();
p->~Derived();
::new((void*)p->) Base();

If we can be sure that v[0] requires the static and dynamic types to match,
then we could do something like:

  reference
  operator[](size_type __n) _GLIBCXX_NOEXCEPT
  {
__glibcxx_requires_subscript(__n);
#ifdef __cpp_rtti
if (typeid(this->_M_impl._M_start[__n]) != typeid(value_type))
  __builtin_unreachable();
#endif
return *(this->_M_impl._M_start + __n);
  }

I have no idea whether that would help anything, or if the use of typeid would
actually pessimize things.

> Apart from that, being do you think it is common for the user to override
> `destroy()` (in a template specialization) but still call the destructor
> inside it? In that case the proposal would not optimize that case.

I don't really care about that, we can't handle every case.

[Bug c++/115923] different diagnostic if using qualified name vs not for missing template arguments

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/115915] gcc fails to detect invalid friend declaration of classes in different namespaces

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> The question is does that friend is naming `::extent` or is naming
> `std_1::extent` using the `using namespace` statement. I suspect GCC and EDG
> think it is `::extent` while clang and MSVC think it is `std_1::extent`.

Right, GCC is declaring a new type named extent in the namespace enclosing S.

[Bug sanitizer/81598] -fsanitize=enum does not detect range violation

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Julien Blanc from comment #9)
> But i’d expect both checkers to detect such misuse.

No, Nathaniel is correct that there is no UB here, so nothing for the sanitizer
to complain about. The documented behaviour is in terms of "a value outside the
range of values for the enum type" and that's not possible for a scoped enum
type.

> While it could be valid
> code, there’s a high chance that its a bug.

I disagree, but in any case it's certainly not UB.

The purpose of -fsanitize=enum is not to detect loads of values that don't
correspond to any enumerator (because that's not necessarily a bug, and is a
very common idiom in C and C++). It's to detect loads of values that are
undefined because the enum cannot represent those values.

[Bug c++/102707] template coroutine generated code failed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Known to fail||11.4.0
  Known to work||12.1.0

--- Comment #3 from Jonathan Wakely  ---
It was fixed by r12-8307: "c++, coroutines: Avoid expanding within templates
[PR103868]"

[Bug target/115934] New: [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Bug ID: 115934
   Summary: [15 Regression] nvptx vs. ivopts: replace
constant_multiple_of with
aff_combination_constant_multiple_p [PR114932]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Recent commit r15-1809-g735edbf1e2479fa2323a2b4a9714fae1a0925f74 "ivopts:
replace constant_multiple_of with aff_combination_constant_multiple_p
[PR114932]" is causing one regression for nvptx target:

PASS: gcc.dg/tree-ssa/pr43378.c (test for excess errors)
PASS: gcc.dg/tree-ssa/pr43378.c scan-tree-dump-times ivopts "rite_[0-9]* =
rite_[0-9]* - element" 1
[-PASS:-]{+FAIL:+} gcc.dg/tree-ssa/pr43378.c scan-tree-dump-times ivopts
"left_[0-9]* = left_[0-9]* \\+ element|left_[0-9]* = element_[0-9]*\\(D\\) \\+
left" 1

Before (or, with this commit locally reverted), we have no 'diff' between the
previous dump file: 'pr43378.c.186t.slp1' vs. 'pr43378.c.188t.ivopts', but now
there's this:

--- pr43378.c.186t.slp1   2024-07-15 11:48:57.498943077 +0200
+++ pr43378.c.188t.ivopts 2024-07-15 11:48:57.498943077 +0200
@@ -3,6 +3,18 @@

 void foo (int left, int rite, int element)
 {
+  unsigned int _1;
+  unsigned int _2;
+  unsigned int _11;
+  unsigned int _12;
+  unsigned int _13;
+  unsigned int _17;
+  unsigned int _19;
+  unsigned int _20;
+  unsigned int _21;
+  unsigned int _22;
+  unsigned int _23;
+  
[local count: 118111600]:
   if (left_4(D) <= rite_5(D))
 goto ; [89.00%]
@@ -12,12 +24,23 @@
[local count: 105119324]:

[local count: 955630224]:
-  # left_14 = PHI 
   # rite_15 = PHI 
+  _17 = (unsigned int) left_4(D);
+  _2 = (unsigned int) rite_5(D);
+  _1 = _2 + _17;
+  _13 = (unsigned int) rite_15;
+  _11 = -_13;
+  _12 = _1 + _11;
+  left_14 = (int) _12;
   rite_8 = rite_15 - element_7(D);
   bar (left_14, rite_8, element_7(D));
-  left_10 = element_7(D) + left_14;
-  if (rite_8 >= left_10)
+  _19 = (unsigned int) left_4(D);
+  _20 = (unsigned int) rite_5(D);
+  _21 = _19 + _20;
+  _22 = (unsigned int) rite_8;
+  _23 = _21 - _22;
+  left_18 = (int) _23;
+  if (rite_8 >= left_18)
 goto ; [89.00%]
   else
 goto ; [11.00%]

(I've not yet looked any deeper.)

[Bug fortran/115935] New: Extend lowering memset for array when it's a component reference

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

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

Bug ID: 115935
   Summary: Extend lowering memset for array when it's a component
reference
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

subroutine test_dt (dt, y)
   implicit none
   real :: y (10, 20, 30)
   type t
  real :: x(10, 20, 30)
   end type t
   type(t) :: dt
   y = 0
   dt% x = 0
end subroutine

With trunk, it generates memset for 'y' but not for dt%x.
That happens because copyable_array_p returns false for dt%x,
because expr->ref->next is non NULL:

  /* First check it's an array.  */
  if (expr->rank < 1 || !expr->ref || expr->ref->next)
return false;

and gfc_full_array_ref_p(expr) bails out if expr->ref->type != REF_ARRAY.

Link to ML discussion:
https://gcc.gnu.org/pipermail/fortran/2024-July/060664.html

Thanks,
Prathamesh

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

--- Comment #1 from Tamar Christina  ---
Hi, thanks for the report, could you tell me a target triple I can use for
nvptx?

[Bug ipa/110057] Missed devirtualization opportunities

[user202729 at protonmail dot com via Gcc-bugs]

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

--- Comment #18 from user202729  ---
(In reply to Jonathan Wakely from comment #17)
> I don't think that optimization would be valid. Users could do disgusting
> things like this (as long as sizeof(Base) == sizeof(Derived)):
> 
> std::vector v(1);
> v[0].~Base();
> ::new((void*)v.data()) Derived();
> v[0].f();
> v[0].~Derived();
> ::new((void*)v.data()) Base();

According to "n.m." on StackOverflow, that code is illegal
https://stackoverflow.com/questions/76380436/is-placement-new-of-derived-type-within-a-vector-array-of-base-type-legal#comment134688951_76380436

So I guess we're safe if the comment is correct. (Same for the vector
destructor case)

> This certainly seems to be allowed:
> 
> std::vector v(1);
> Base* p = v.data();
> p->~Base();
> ::new((void*)p) Derived();
> p->f();
> p->~Derived();
> ::new((void*)p->) Base();

The clause seems to apply just as well, you cannot access the newly constructed
`Derived` object through `p`.

Further reading:
https://stackoverflow.com/questions/62642542/were-all-implementations-of-stdvector-non-portable-before-stdlaunder

> If we can be sure that v[0] requires the static and dynamic types to match,
> then we could do something like:
> 
>   reference
>   operator[](size_type __n) _GLIBCXX_NOEXCEPT
>   {
>   __glibcxx_requires_subscript(__n);
> #ifdef __cpp_rtti
> if (typeid(this->_M_impl._M_start[__n]) != typeid(value_type))
>   __builtin_unreachable();
> #endif
>   return *(this->_M_impl._M_start + __n);
>   }
> 
> I have no idea whether that would help anything, or if the use of typeid
> would actually pessimize things.

It turns out that the compiler can currently prove (with optimization enabled)
that `typeid::operator==` is pure, so it wouldn't pessimize things. If you want
to be extra careful I suppose `#if __OPTIMIZE__` is an option.

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

--- Comment #2 from Thomas Schwinge  ---
The most simple one: '--target=nvptx-none'.  :-)

[Bug target/115936] New: [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Bug ID: 115936
   Summary: [15 Regression] GCN vs. ivopts: replace
constant_multiple_of with
aff_combination_constant_multiple_p [PR114932]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

Recent commit r15-1809-g735edbf1e2479fa2323a2b4a9714fae1a0925f74 "ivopts:
replace constant_multiple_of with aff_combination_constant_multiple_p
[PR114932]" is causing one regression for '--target=amdgcn-amdhsa' (tested
'-march=gfx908', '-march=gfx1100'):

@@ -98531,8 +98547,9 @@ PASS: gcc.dg/torture/pr101173.c   -O0  (test for
excess errors)
PASS: gcc.dg/torture/pr101173.c   -O0  execution test
PASS: gcc.dg/torture/pr101173.c   -O1  (test for excess errors)
PASS: gcc.dg/torture/pr101173.c   -O1  execution test
{+FAIL: gcc.dg/torture/pr101173.c   -O2  (internal compiler error:
verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.dg/torture/pr101173.c   -O2  (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} gcc.dg/torture/pr101173.c   -O2  [-execution
test-]{+compilation failed to produce executable+}
PASS: gcc.dg/torture/pr101173.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
PASS: gcc.dg/torture/pr101173.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
PASS: gcc.dg/torture/pr101173.c   -O3 -g  (test for excess errors)

[...]/source-gcc/gcc/testsuite/gcc.dg/torture/pr101173.c: In function
'main':
[...]/source-gcc/gcc/testsuite/gcc.dg/torture/pr101173.c:5:5: error:
invalid (pointer) operands 'plus_expr'
ivtmp.39_65 = ivtmp.39_59 + 0B;
during GIMPLE pass: ivopts
[...]/source-gcc/gcc/testsuite/gcc.dg/torture/pr101173.c:5:5: internal
compiler error: verify_gimple failed
0x20dcb22 internal_error(char const*, ...)
[...]/source-gcc/gcc/diagnostic-global-context.cc:491
0x11fe23e verify_gimple_in_cfg(function*, bool, bool)
[...]/source-gcc/gcc/tree-cfg.cc:5678
0x1092710 execute_function_todo
[...]/source-gcc/gcc/passes.cc:2089
0x1092c5b execute_todo
[...]/source-gcc/gcc/passes.cc:2143

[Bug ipa/110057] Missed devirtualization opportunities

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

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to user202729 from comment #18)
> (In reply to Jonathan Wakely from comment #17)
> The clause seems to apply just as well, you cannot access the newly
> constructed `Derived` object through `p`.

That's easily solved by accessing the new object through the pointer returned
by the new expression:

std::vector v(1);
Base* p = v.data();
p->~Base();
p = ::new((void*)p) Derived();
p->f();
p->~Base();
::new((void*)p) Base();

By the time anything is accessed through the vector's internal pointers, an
object of the original type has been restored at that location, which meets all
the requirements of [basic.life] p7.

But that means v[0].f() wouldn't be valid, only p->f(), so adding information
about the dynamic type to vector::operator[] would be allowed.

[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/618
   ||449.html

--- Comment #8 from Jonathan Wakely  ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598254.html

Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618449.html

Looks like Iain responded both times, although that's not approval.

[Bug middle-end/115863] [15 Regression] zlib-1.3.1 miscompilation since r15-1936-g80e446e829d818

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

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

--- Comment #13 from Li Pan  ---
Thanks Richard and Bizjak.

Got the point here, and let me have a try for the improvement.

[Bug c/115937] New: duplicate .plt in module's elf header

[ellery1016 at 163 dot com via Gcc-bugs]

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

Bug ID: 115937
   Summary: duplicate .plt in module's elf header
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ellery1016 at 163 dot com
  Target Milestone: ---

My system: aarch64
Kernel version: linux-4.19
GCC version: 10.3.1 & 7.3.0

I changed my gcc from 7.3.0 to 10.3.1 and recompiled kernel code.

After new kernel installed and rebooted, some call trace printed in dmesg as
below:
```
Jul 10 15:39:59 localhost kernel: sysfs: cannot create duplicate filename
'/module/virtio/sections/.plt'
Jul 10 15:39:59 localhost kernel: CPU: 94 PID: 831 Comm: systemd-udevd Not
tainted 4.19.90.rc1.aarch64 #1
Jul 10 15:39:59 localhost kernel: Hardware name: QEMU KVM Virtual Machine, BIOS
0.0.0 02/06/2015
Jul 10 15:39:59 localhost kernel: Call trace:
Jul 10 15:39:59 localhost kernel:  dump_backtrace+0x0/0x190
Jul 10 15:39:59 localhost kernel:  show_stack+0x28/0x34
Jul 10 15:39:59 localhost kernel:  dump_stack+0xa4/0xe8
Jul 10 15:39:59 localhost kernel:  sysfs_warn_dup+0x70/0x90
Jul 10 15:39:59 localhost kernel:  sysfs_add_file_mode_ns+0x19c/0x1d0
Jul 10 15:39:59 localhost kernel:  create_files+0xa8/0x200
Jul 10 15:39:59 localhost kernel:  internal_create_group+0x178/0x210
Jul 10 15:39:59 localhost kernel:  sysfs_create_group+0x30/0x40
Jul 10 15:39:59 localhost kernel:  add_sect_attrs+0x174/0x200
Jul 10 15:39:59 localhost kernel:  mod_sysfs_setup+0x1e8/0x210
Jul 10 15:39:59 localhost kernel:  load_module+0x46c/0x820
Jul 10 15:39:59 localhost kernel:  __se_sys_finit_module+0xb8/0x120
Jul 10 15:39:59 localhost kernel:  __arm64_sys_finit_module+0x28/0x34
Jul 10 15:39:59 localhost kernel:  el0_svc_common+0x7c/0x134
Jul 10 15:39:59 localhost kernel:  el0_svc_handler+0x3c/0x7c
Jul 10 15:39:59 localhost kernel:  el0_svc+0x8/0x1f8
```
In fact, it seemed that all kernel modules met the problem "cannot create
duplicate filename .plt"，which causes directory "sections" doesn't exist any
more under /sys/modules/.Meanwhile all the modules installed successfully,and
the system works fine so far.

As a test, I wrote a simple module like:
```
#include 
#include 
#include 

MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");
MODULE_AUTHOR("qink");
MODULE_DESCRIPTION("Test elf plt");

static __init int test_plt_init(void)
{
printk("Inset a new test module.\n");
return 0;
}

static __exit void test_plt_exit(void)
{
printk("New test module exits.\n");
}

module_init(test_plt_init);
module_exit(test_plt_exit);
```

My makefile is like:
```
obj-m :=test_plt.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD :=$(shell pwd)  
modules :  
$(MAKE) -C $(KDIR) M=$(PWD) modules
clean :  
rm -f *.o .*.cmd *.symvers
```

And I compiled with gcc 10.3.1 and insmod it, the same message showed again,
while I did the same thing on a gcc 7.3.0 system and there was no such message.

Since it seemed like a problem with somthing called ".plt", I used readelf -S
to see what is is.
The result with module test_plt.ko compiled with gcc 7.3.0:
```
There are 37 section headers, starting at offset 0x2a910:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .note.gnu.build-i NOTE   0040
   0024     A   0 0 4
  [ 2] .text PROGBITS   0064
       AX   0 0 1
  [ 3] .init.textPROGBITS   0064
   0028    AX   0 0 4
  [ 4] .rela.init.text   RELA   00017278
   0060  0018   I  34 3 8
  [ 5] .exit.textPROGBITS   008c
   001c    AX   0 0 4
  [ 6] .rela.exit.text   RELA   000172d8
   0048  0018   I  34 5 8
  [ 7] .modinfo  PROGBITS   00a8
   00ce     A   0 0 8
  [ 8] .rodata.str1.8PROGBITS   0178
   0038  0001 AMS   0 0 8
  [ 9] .eh_frame PROGBITS   01b0
   005c     A   0 0 8
  [10] .rela.eh_frameRELA   00017320
   0030  0018   I  34 9 8
  [11] __mcount_loc  PROGBITS   0210
   00

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[Mayshao-oc at zhaoxin dot com via Gcc-bugs]

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

--- Comment #37 from Mayshao-oc at zhaoxin dot com ---
vmovdqu is also atomic in Zhaoxin processors if it meets three requirements:
1. the address of its memory operand must be 16-byte aligned
2. vmovdqu is vex.128 not vex.256
3. the memory type of the address is WB

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

[Mayshao-oc at zhaoxin dot com via Gcc-bugs]

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

--- Comment #38 from Mayshao-oc at zhaoxin dot com ---
vmovdqu is also atomic in Zhaoxin processors if it meets three requirements:
1. the address of its memory operand must be 16-byte aligned
2. vmovdqu is vex.128 not vex.256
3. the memory type of the address is WB
(In reply to Richard Henderson from comment #36)
> (In reply to Mayshao-oc from comment #34)
> > (In reply to Jakub Jelinek from comment #17)
> > > Fixed for AMD on the library side too.
> > > We need a statement from Zhaoxin and VIA for their CPUs.
> > 
> > Sorry for the late reply.
> > We guarantee that VMOVDQA will be an atomic load or store provided 128 bit
> > aligned address in Zhaoxin processors, provided that the memory type is WB.
> > Can we extend this patch to Zhaoxin processors as well?
> 
> Is VMOVDQU atomic, provided the address is aligned in Zhaoxin processors?
> 
> In QEMU, we make use of this additional guarantee from AMD.
> We also reference this gcc bugzilla entry for documentation.  :-)

(In reply to Richard Henderson from comment #36)
> (In reply to Mayshao-oc from comment #34)
> > (In reply to Jakub Jelinek from comment #17)
> > > Fixed for AMD on the library side too.
> > > We need a statement from Zhaoxin and VIA for their CPUs.
> > 
> > Sorry for the late reply.
> > We guarantee that VMOVDQA will be an atomic load or store provided 128 bit
> > aligned address in Zhaoxin processors, provided that the memory type is WB.
> > Can we extend this patch to Zhaoxin processors as well?
> 
> Is VMOVDQU atomic, provided the address is aligned in Zhaoxin processors?
> 
> In QEMU, we make use of this additional guarantee from AMD.
> We also reference this gcc bugzilla entry for documentation.  :-)

[Bug c++/110635] Segmentation fault when the awaiter's await_resume in initial-suspend returns a class type.

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

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

Arsen Arsenović  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-15
 Ever confirmed|0   |1
 CC||arsen at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

--- Comment #1 from Arsen Arsenović  ---
confirmed, I've debugged it a bit also, in the following (coroutines.cc:4224
vicinity):

  if (initial_await != error_mark_node)
{
  /* Build a compound expression that sets the
 initial-await-resume-called variable true and then calls the
 initial suspend expression await resume.
 In the case that the user decides to make the initial await
 await_resume() return a value, we need to discard it and, it is
 a reference type, look past the indirection.  */
  if (INDIRECT_REF_P (initial_await))
initial_await = TREE_OPERAND (initial_await, 0);
  tree vec = TREE_OPERAND (initial_await, 3);
  tree aw_r = TREE_VEC_ELT (vec, 2);
  aw_r = convert_to_void (aw_r, ICV_STATEMENT, tf_warning_or_error);
  tree update = build2 (MODIFY_EXPR, boolean_type_node, i_a_r_c,
boolean_true_node);
  aw_r = cp_build_compound_expr (update, aw_r, tf_warning_or_error);
  TREE_VEC_ELT (vec, 2) = aw_r;
}

... the code does not anticipate that initial_await is a TARGET_EXPR, and so it
fails because it tries to alter a non-existent element 2 (which is meant to
correspond to the await_resume of the initial_suspend_awaiter)

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Tamar Christina  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-07-15
 Ever confirmed|0   |1

--- Comment #3 from Tamar Christina  ---
mine.

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||tnfchris at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-07-15
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #1 from Tamar Christina  ---
odd thing to iCE on, mine.

[Bug rtl-optimization/115929] [15 regression] ICE on valid code at -O{2,3} with "-fschedule-insns" on x86_64-linux-gnu: Segmentation fault

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-15
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

[Bug c++/115938] New: gcc allows inheriting base class with private destructor during virtual inheritance

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 115938
   Summary: gcc allows inheriting base class with private
destructor during virtual inheritance
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

The following code is accepted by the latest version of GCC but rejected by
clang, MSVC and EDG:

~~
class A
{
 protected:
  virtual ~A(){};
};

class B : virtual A
{
 public:
  virtual ~B(){};
};

class C:B
{
public:
~C(){};
};

C c;

~~

The code seems to be invalid. Because class "B" private inherits "A" ,the dtor
of "A" should be private in "B" and cannot be accessed in "C". When it's not
under a virtual inheritance case, the problem does not exist.

Please check https://godbolt.org/z/jd71dWKfs

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

--- Comment #6 from Richard Biener  ---
t.c:9:17: note:  misalignment for fully-masked loop: 15

so in the first iteration only the last element should be active.  But

  # loop_mask_58 = PHI <_100(10), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>
  # loop_mask_57 = PHI <_101(10), { 0, 0, 0, 0, 0, 0, 0, 0 }(2)>

is then wrong and

  # vect_vec_iv_.6_46 = PHI <_47(10), { -15, -14, -13, -12, -11, -10, -9, -8,
-7, -6, -5, -4, -3, -2, -1, 0 }(2)>
  _47 = vect_vec_iv_.6_46 + { 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16 };
  vect__1.7_49 = vect_vec_iv_.6_46 & { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7 };

are the values for { 1, 2, ... } thus the next iteration (not
relevant for this particular induction use).

There are then un(loop-)masked uses of the mask derived from vect__1.7_49
in

  vect_patt_15.25_84 = VEC_COND_EXPR ;

but ultimatively the loop mask is applied in its uses via .MASK_STORE.

I have a fix.

[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused

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

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

--- Comment #9 from Arsen Arsenović  ---
a ping might suffice then (Iain also wants to see this optimization, it'd seem)

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[macro at orcam dot me.uk via Gcc-bugs]

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

--- Comment #15 from Maciej W. Rozycki  ---
(In reply to Uroš Bizjak from comment #13)
> CC Maciej if he can test the patch on his Alpha system.

It takes about a day to complete and I had to rerun the libstdc++3
subdirectory due to an intermittent failure.  Eventually there were
no regressions, but there were no progressions either, meaning that
the reduced reproducer should I think be converted into a test case.

Owing to the load of other commitments over the weekend I have run
out of time to do that, but I can see if I can see if I can look
into it over the coming days unless someone beats me to it.

[Bug testsuite/115826] vect-tsvc-s1281.c fails on arm-*-* due to -ffast-math being required for vectorization tests

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

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

--- Comment #2 from Torbjorn SVENSSON  ---
Adding /* { dg-add-options ieee } */ to
gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c did not change any of the
flags that gcc was invoked with.

I experimented a bit more and found that adding -fno-finite-math-only did allow
the test case to PASS. Is this a suitable solution?

I sent a patch adding the -fno-finite-math-only fix to the ML in hope it would
save some time if accepted.
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657273.html

If acceptable, I would like to backport it to releases/gcc-14.

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Tamar Christina  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

--- Comment #2 from Tamar Christina  ---
Looks like IVopts has generated an invalid gimple:

ivtmp.39_65 = ivtmp.39_59 + 0B;

where the IVs are DI mode and the offset is a pointer.
This comes from this weird candidate:

Candidate 8:
  Var befor: ivtmp.39_59
  Var after: ivtmp.39_65
  Incr POS: before exit test
  IV struct:
Type:   sizetype
Base:   0
Step:   0B
Biv:N
Overflowness wrto loop niter:   No-overflow

Looks like this invalid candidate was always generated, but was not selected
before as the old constant_multiple_of bailed out due to the operand_equal_p
constraining the type of the arguments.

Question is why this invalid candidate was generated at all, and that's due to:

  /* Record common candidate with initial value zero.  */
  basetype = TREE_TYPE (iv->base);
  if (POINTER_TYPE_P (basetype))
basetype = sizetype;
  record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);

which for the case the type is a pointer changes the base but not the step.
this makes base + step no longer valid gimple.

So I believe fix is:

diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 5fc188ae3f8..d590d6a9b78 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -3547,7 +3547,8 @@ add_iv_candidate_for_use (struct ivopts_data *data,
struct iv_use *use)
   basetype = TREE_TYPE (iv->base);
   if (POINTER_TYPE_P (basetype))
 basetype = sizetype;
-  record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);
+  record_common_cand (data, build_int_cst (basetype, 0),
+ fold_convert (basetype, iv->step), use);


which fixes the ICE. Will regtest and submit.

[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #10 from Iain Sandoe  ---
actually I thought I explained the issue in email to Michal - that we need to
make some changes for correctness to these mechanisms and therefore that we
should defer the optimisation until those are done.

I have Michal's patch in my local queue and we now have some funding to take
things forward.  This optimisation is 100% on the TODO.

[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||ldalessandro at gmail dot com

--- Comment #2 from Arsen Arsenović  ---
*** Bug 114142 has been marked as a duplicate of this bug. ***

[Bug c++/114142] [coroutines]: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have reference_type in lookup_base, at cp/search.cc:252

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #2 from Arsen Arsenović  ---
seems to be exactly PR104981

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

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Uroš Bizjak  ---
Created attachment 58666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58666&action=edit
Cleaned up testcase

Can you please test this slightly cleaned up testcase?

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #16)

> Can you please test this slightly cleaned up testcase?

Just put it in gcc/testsuite/gcc.target/alpha and do:

make -k check-gcc RUNTESTFLASG=alpha.exp=pr115526.c

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Uroš Bizjak  ---
> make -k check-gcc RUNTESTFLASG=alpha.exp=pr115526.c

s/RUNTESTFLASG/RUNTESTFLAGS/

[Bug libstdc++/115939] New: Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

[halfflat at gmail dot com via Gcc-bugs]

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

Bug ID: 115939
   Summary: Cannot unambiguously compare iterators in
std::unordered_map with mapped type
std::expected>
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: halfflat at gmail dot com
  Target Milestone: ---

Created attachment 58667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58667&action=edit
Preprocessed .ii file from example code

Consider the following code:


#include 
#include 
#include 

struct Y {};
std::unordered_map> m;
bool r = m.begin()==m.end();


When compiled with g++ -c -std=c++23 -pedantic we get an "ambiguous overload
for ‘operator==’" error. This issue has been replicated on Compiler Explorer
(https://godbolt.org/z/cqoedqKbr). It is not clear to me if this results from a
fundamental issue in the standard library specification or is a consequence of
the implementation in libstdc++.

The original context of the bug was in code that was attempting to use a
std::unordered_map (std::string_view)>> (where failure was a separately defined type). 

Compiler output below:

% g++ -v -save-temps  -c -std=c++23 -pedantic bug.cc
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitea.artixlinux.org/packages/gcc/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.1 20240507 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++23' '-Wpedantic'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
bug.cc -mtune=generic -march=x86-64 -std=c++23 -Wpedantic -fpch-preprocess -o
bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../x86_64-pc-linux-gnu/include"
ignoring nonexistent directory "/home/sam/pkg/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++23' '-Wpedantic'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.1.1/cc1plus -fpreprocessed bug.ii -quiet
-dumpbase bug.cc -dumpbase-ext .cc -mtune=generic -march=x86-64 -Wpedantic
-std=c++23 -version -o bug.s
GNU C++23 (GCC) version 14.1.1 20240507 (x86_64-pc-linux-gnu)
compiled by GNU C version 14.1.1 20240507, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 79593118236b8aa0b562fa91bdea97d6
bug.cc:7:19: error: ambiguous overload for ‘operator==’ (operand types are
‘std::unordered_map >::iterator’ {aka
‘std::__detail::_Insert_base >, std::allocator > >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::iterator’} and ‘std::unordered_map >::iterator’ {aka ‘std::__detail::_Insert_base >, std::allocator > >, std::__detail::_Select1st, std::equal_to,
std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits >::iterator’})
7 | bool r = m.begin()==m.end();
  |  ~^
  | ||
  | |_Node_iterator<[...],[...],[...]>
  | _Node_iterator<[...],[...],[...]>
In file included from bug.cc:2:
/usr/include/c++/14.1.1/expected:1133:9: note: candidate: ‘constexpr bool
std::operator==(const expected<_Tp, _Er>&, const _Up&) [with _Up =
__detail::_Node_iterat

[Bug c++/115940] New: ICE: tree check: expected record_type or union_type or qual_union_type, have translation_unit_decl in maybe_dummy_object, at cp/tree.cc:4379

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115940
   Summary: ICE: tree check: expected record_type or union_type or
qual_union_type, have translation_unit_decl in
maybe_dummy_object, at cp/tree.cc:4379
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces a segfault during tree_check_failed when compiling the
provided code with the specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:Please refer to the attachment. 

***
Command Lines:
# g++ BlockRegion.i -O3 -march=native -flto -fsanitize=address,undefined
-fno-omit-frame-pointer -Wall -Wextra -Wpedantic -Wshadow -Wconversion
-Wdouble-promotion -fstack-protector-all -fno-strict-aliasing -Wstrict-overflow
-Wnull-dereference -Wformat=2 -Wformat-signedness -c -o BlockRegion.o
:1:3: warning: style of line directive is a GCC extension
1 | # 1 "PFA/BlockRegion.c"
  |   ^
PFA/BlockRegion.c:1:3: warning: style of line directive is a GCC extension
: warning: style of line directive is a GCC extension
:1:3: warning: style of line directive is a GCC extension
PFA/BlockRegion.c:1:3: warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/BlockRegion.xcc:16:3:
warning: style of line directive is a GCC extension
In file included from
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/BlockRegion.xcc:16:
PFA/PFA._h:1:3: warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/PFA.xcc:19:3:
warning: style of line directive is a GCC extension
In file included from
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/PFA.xcc:19:
PFA/PFA.h:1:3: warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/PFA.xcc:1:3:
warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/PFA.xcc:22:3:
warning: style of line directive is a GCC extension
In file included from
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/PFA.xcc:22:
/work1/monat/tmp/include/CCL.h:1:3: warning: style of line directive is a GCC
extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/CCL/CCL.xcc:1:3:
warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/CCL/CCL.xcc:20:3:
warning: style of line directive is a GCC extension
In file included from
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/CCL/CCL.xcc:20:
/work1/monat/tmp/include/BSL.h:1:3: warning: style of line directive is a GCC
extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/BSL/BSL.xcc:1:3:
warning: style of line directive is a GCC extension
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/BSL/BSL.xcc:19:3:
warning: style of line directive is a GCC extension
In file included from
/home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/CDT/BSL/BSL.xcc:19:
/work1/monat/tmp/include/CDT.h:4:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:5:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:6:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:7:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:8:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:9:3: warning: style of line directive is a GCC
extension
/work1/monat/tmp/include/CDT.h:10:3: warning: style of line directive is a GCC
extension
/wo

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

--- Comment #4 from Tamar Christina  ---
This one looks a bit like costing,

before the patch IVopts had:

:
inv_expr 1: -element_7(D)
inv_expr 2: (signed int) rite_5(D) - (signed int) element_7(D)

and after the patch it generates a few more alternatives:


:
inv_expr 1: -element_7(D)
inv_expr 2: ((signed int) left_4(D) + (signed int) rite_5(D)) - (signed
int) element_7(D)
inv_expr 3: (signed int) left_4(D) + (signed int) rite_5(D)
inv_expr 4: (signed int) rite_5(D) - (signed int) element_7(D)
inv_expr 5: ((signed int) rite_5(D) - (signed int) element_7(D)) + (signed
int) left_4(D)
inv_expr 6: ((signed int) rite_5(D) + (signed int) element_7(D)) + (signed
int) left_4(D)
inv_expr 7: ((signed int) left_4(D) - (signed int) element_7(D)) + (signed
int) rite_5(D)

Before it decided it needed two separate IVs to satisfy these invariants:

Initial set of candidates:
  cost: 122 (complexity 0)
  reg_cost: 114
  cand_cost: 8
  cand_group_cost: 0 (complexity 0)
  candidates: 7, 9
   group:0 --> iv_cand:7, cost=(0,0)
   group:1 --> iv_cand:9, cost=(0,0)
   group:2 --> iv_cand:9, cost=(0,0)
   group:3 --> iv_cand:7, cost=(0,0)
  invariant variables: 1
  invariant expressions: 1

Original cost 122 (complexity 0)

Final cost 122 (complexity 0)

Selected IV set for loop 1 at
../gcc-dsg/gcc/testsuite/gcc.dg/tree-ssa/pr43378.c:7, 10 avg niters, 2 IVs:
Candidate 7:
  Var befor: left_14
  Var after: left_10
  Incr POS: orig biv
  IV struct:
Type:   int
Base:   left_4(D)
Step:   element_7(D)
Biv:N
Overflowness wrto loop niter:   Overflow
Candidate 9:
  Depend on inv.exprs: 1
  Var befor: rite_15
  Var after: rite_8
  Incr POS: orig biv
  IV struct:
Type:   int
Base:   rite_5(D)
Step:   -element_7(D)
Biv:N
Overflowness wrto loop niter:   Overflow


with the patch it decided it only needed the one IV:

Initial set of candidates:
  cost: 109 (complexity 0)
  reg_cost: 97
  cand_cost: 4
  cand_group_cost: 8 (complexity 0)
  candidates: 9
   group:0 --> iv_cand:9, cost=(4,0)
   group:1 --> iv_cand:9, cost=(0,0)
   group:2 --> iv_cand:9, cost=(0,0)
   group:3 --> iv_cand:9, cost=(4,0)
  invariant variables: 1
  invariant expressions: 1, 3

Initial set of candidates:
  cost: 109 (complexity 0)
  reg_cost: 97
  cand_cost: 4
  cand_group_cost: 8 (complexity 0)
  candidates: 9
   group:0 --> iv_cand:9, cost=(4,0)
   group:1 --> iv_cand:9, cost=(0,0)
   group:2 --> iv_cand:9, cost=(0,0)
   group:3 --> iv_cand:9, cost=(4,0)
  invariant variables: 1
  invariant expressions: 1, 3

Original cost 109 (complexity 0)

Final cost 109 (complexity 0)

Selected IV set for loop 1 at
../gcc-dsg/gcc/testsuite/gcc.dg/tree-ssa/pr43378.c:7, 10 avg niters, 1 IVs:
Candidate 9:
  Depend on inv.exprs: 1
  Var befor: rite_15
  Var after: rite_8
  Incr POS: orig biv
  IV struct:
Type:   int
Base:   rite_5(D)
Step:   -element_7(D)
Biv:N
Overflowness wrto loop niter:   Overflow

It realizes it can satisfy both IVs using 1 candidate and picks it because it
thinks the costs are much lower.
I don't however see an implementation of TARGET_ADDRESS_COST for the target.

On AArch64 for instance this is rejected by costing because the combined IV
requires more registers:

Initial set of candidates:
  cost: 17 (complexity 0)
  reg_cost: 5
  cand_cost: 4
  cand_group_cost: 8 (complexity 0)
  candidates: 9
   group:0 --> iv_cand:9, cost=(4,0)
   group:1 --> iv_cand:9, cost=(0,0)
   group:2 --> iv_cand:9, cost=(0,0)
   group:3 --> iv_cand:9, cost=(4,0)
  invariant variables: 1
  invariant expressions: 1, 3

Improved to:
  cost: 14 (complexity 0)
  reg_cost: 6
  cand_cost: 8
  cand_group_cost: 0 (complexity 0)
  candidates: 7, 9
   group:0 --> iv_cand:7, cost=(0,0)
   group:1 --> iv_cand:9, cost=(0,0)
   group:2 --> iv_cand:9, cost=(0,0)
   group:3 --> iv_cand:7, cost=(0,0)
  invariant variables: 1
  invariant expressions: 1

Original cost 14 (complexity 0)

Final cost 14 (complexity 0)

Selected IV set for loop 1 at /app/example.c:4, 10 avg niters, 2 IVs:

I'll have to take a look at what happens when a target has no cost model for
IVopts.

[Bug tree-optimization/115843] [14/15 Regression] 531.deepsjeng_r fails to verify with -O3 -march=znver4 --param vect-partial-vector-usage=2

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #7 from Richard Biener  ---
Note while on the GCC 14 branch with the fix as posted I see the correct

movl$-128, %eax
vpxor   %xmm2, %xmm2, %xmm2
kxorb   %k4, %k4, %k4
kmovb   %eax, %k1
vmovdqu64   KingSafetyMask1-56(%rip), %zmm0{%k1}{z}
vmovdqu64   KingSafetyMask1-48(%rip), %zmm1{%k1}{z}
movl$64, %eax
kmovb   %eax, %k2
..

oddly enough on trunk while there's

(insn 5 26 76 2 (set (reg:QI 4 si [orig:113 loop_mask_57 ] [113])
(const_int -128 [0xff80])) "t.c":6:1 91 {*movqi_internal}
 (expr_list:REG_EQUAL (const_int -128 [0xff80])
(nil)))
(insn:TI 76 5 92 2 (set (reg:QI 73 k5 [orig:113 loop_mask_57 ] [113])
(reg:QI 4 si [orig:113 loop_mask_57 ] [113])) "t.c":6:1 91
{*movqi_internal}
 (expr_list:REG_DEAD (reg:QI 4 si [orig:113 loop_mask_57 ] [113])
(nil)))

in .dfinish there's

movl$-128, %esi
kmovw   %esi, %k5

in the assembly and we leak extra set bits into %k5.  I have a debug patch
which then causes the testcase to fail again on trunk but not on the branch.
How do we end up with kmovw from the above insns?  It looks like
*movqi_internal might benefit from the new [] syntax - maybe
alternatives/attributes got mixed up?

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

--- Comment #3 from Richard Biener  ---
iv->step should never be a pointer type

[Bug plugins/112520] gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so ICE (segmentation fault) with Python 3.12+

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
Same error occurs on hppa-unknown-linux-gnu:

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-
PyList_Append.c -fdiagnostics-plain-output
-fplugin=./analyzer_cpython_plugin.so
 -fanalyzer -I/usr/include/python3.12 -I/usr/include/python3.12 -S -o
cpython-pl
ugin-test-PyList_Append.s
*** WARNING *** there are active plugins, do not report this as a bug unless
you
 can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_ANALYZER_INIT | analyzer_cpython_plugin
during IPA pass: analyzer
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-PyList_Ap
pend.c: In function 'test_PyListAppend_6':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-PyList_Ap
pend.c:76:3: internal compiler error: Segmentation fault
0x8a3a73 crash_signal
../../gcc/gcc/toplev.cc:319
0xf77bb0ac get_field_by_name
   
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plug
in.c:75
0xf77bb0ac ana::kf_PyList_Append::impl_call_pre(ana::call_details const&) const
   
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plug
in.c:609
0xc6c57f ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*
)
../../gcc/gcc/analyzer/region-model.cc:1718
0xc6de27 ana::region_model::on_stmt_pre(gimple const*, bool*,
ana::region_model_
context*)
../../gcc/gcc/analyzer/region-model.cc:1355
0xc39f97 ana::exploded_node::on_stmt_pre(ana::exploded_graph&, gimple const*,
ana::program_state*, bool*, bool*, ana::region_model_context*)
../../gcc/gcc/analyzer/engine.cc:1593
0xc3a1f7 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*,
ana::path_context*)
../../gcc/gcc/analyzer/engine.cc:1515
0xc3c953 ana::exploded_graph::process_node(ana::exploded_node*)
../../gcc/gcc/analyzer/engine.cc:4125
0xc3d9c7 ana::exploded_graph::process_worklist()
../../gcc/gcc/analyzer/engine.cc:3516
0xc3fd6b ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:6210
0xc4104b ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:6308
0xc2fb7b execute
../../gcc/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |15.0

--- Comment #5 from Richard Biener  ---
Yup, one IV instead of two and

+  _17 = (unsigned int) left_4(D);
+  _2 = (unsigned int) rite_5(D);
+  _1 = _2 + _17;
+  _13 = (unsigned int) rite_15;
+  _11 = -_13;
+  _12 = _1 + _11;
+  left_14 = (int) _12;

failing to identify and hoist the invariant part of left_4(D) + rite_5(D) -
rite_15.  I guess IVOPTs is only able to hoist fully invariants, not
invariant parts when rewriting a use.

[Bug target/115936] [15 Regression] GCN vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Richard Biener from comment #3)
> iv->step should never be a pointer type

That's what I initially thought too.  My suspicion is that there is some code
that tries to create the 0 offset.

I'll try to track down where the IV is created.

0 + 0B is a weird candidate either way.

[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #10 from Arsen Arsenović  ---
possibly fixed in 13.1 by r13-4479-g58a7b1e354530d ?

I cannot reproduce with https://gcc.gnu.org/bugzilla/attachment.cgi?id=49811

[Bug target/115934] [15 Regression] nvptx vs. ivopts: replace constant_multiple_of with aff_combination_constant_multiple_p [PR114932]

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge  ---
Tamar, Richard, thanks for having a look.

(In reply to Tamar Christina from comment #4)
> This one looks a bit like costing, [...]

I see.  So we (I) shall later re-visit this PR in context of

"[nvptx PATCH] Implement rtx_costs target hook for nvptx backend", and, if
necessary, follow-up work:

> I don't however see an implementation of TARGET_ADDRESS_COST for the target.

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113208
 CC||ppalka at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
It seems this is fixed on trunk since r15-521-g6ad7ca1bb90573?

I see that trunk now emits the shallow() ctor:

shallow::shallow() [base object constructor]:
mov DWORD PTR [rdi], 0
ret
use_shallow::s_zstr:
.zero   4

[Bug plugins/112520] gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so ICE (segmentation fault) with Python 3.12+

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

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

--- Comment #5 from John David Anglin  ---
Likely caused by a NULL argument passed to strcmp in get_field_by_name.

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[dilfridge at gentoo dot org via Gcc-bugs]

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

--- Comment #19 from Andreas K. Huettel  ---
Sorry for the delay here, the machine I have access to is quite slow. 
It spent ~2 days building unmodified git master and is now running the
testsuite as baseline...

[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

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

--- Comment #7 from LIU Hao  ---
Yes, looks so.

[Bug c++/104384] coroutines: Heap corruption when initializing struct with co_await

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #3 from Arsen Arsenović  ---
fixed by r13-4479-g58a7b1e354530d

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

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||brandt.milo2 at gmail dot com

--- Comment #8 from Arsen Arsenović  ---
*** Bug 98401 has been marked as a duplicate of this bug. ***

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||max at duempel dot org

--- Comment #7 from Arsen Arsenović  ---
*** Bug 104384 has been marked as a duplicate of this bug. ***

[Bug c++/107288] coroutines: Double-free of temporaries created in statement following co_await

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||arsen at gcc dot gnu.org

--- Comment #5 from Arsen Arsenović  ---
fixed by r13-4479-g58a7b1e354530d

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

[Bug c++/107239] Coroutine code generation bug

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||arsen at gcc dot gnu.org

--- Comment #4 from Arsen Arsenović  ---
fixed by r13-4479-g58a7b1e354530d

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

[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #11 from Arsen Arsenović  ---
checked - it is

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

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #9 from Arsen Arsenović  ---
*** Bug 107239 has been marked as a duplicate of this bug. ***

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||hodges.r at gmail dot com

--- Comment #10 from Arsen Arsenović  ---
*** Bug 107288 has been marked as a duplicate of this bug. ***

[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Arsen Arsenović from comment #10)
> possibly fixed in 13.1 by r13-4479-g58a7b1e354530d ?
>
> I cannot reproduce with https://gcc.gnu.org/bugzilla/attachment.cgi?id=49811

Indeed. I modified that to add a global int count and then in the
lifetime_tester destructor did `if (count++) abort();` to make it easier to
test automatically. The double destruction was fixed by the commit suggested by
Arsen.

[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I think this is the expected (no pun intended) behaviour. It's a consequence of
std::any being constructible from anything, so the operator== for expected
is a candidate for ... well ... anything. Your std::expected can
be constructed from nearly every possible type, so the equality comparison
considers a conversion to std::expected to be viable, and then use
the operator== for std::expected.

It doesn't help that the operator== is a hidden friend, so only found by ADL,
because your unordered_map::iterator has std::expected as an
associated class, so the hidden friend is a candidate.

The way libstdc++ defines the equality operator for unordered_map::iterator
also involves conversions, from unordered_map::iterator to its
_Node_iterator_base base class, so the C++ standard considers them ambiguous.
Without -pedantic GCC does the right thing.

I see two possible solutions to this, but neither of them is possible for you.

Firstly, I have a C++ standard proposal to constrain operator==(expected,
U), so that it will not be viable if std::expected is not equality
comparable with U (which ti isn't in this case, because U is the
unordered_map::iterator).

Secondly, we could add operator== for the actual iterator type, so that there's
no derived-to-base conversion needed to find a candidate.

I think the only workarounds available to you are to not use -pedantic, and to
not use std::any in this way, where it greedily converts from anything.

[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

[halfflat at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Sam Yates  ---
Thank you for the prompt assessment! A standards proposal or DR does seem like
the more robust solution for the longer term.

In the interim, for my application, I am boxing-up the std::any in another
struct [1] and unboxing as required; this breaks the chain of implicit
conversions. Ultimately this code will need to be buildable in C++20 and I will
use a back-ported std::expected workalike which can implement your proposed
restriction on operator==.


[1] This, basically:
template 
struct box {
template 
explicit box(Ts&&... ts): value(std::forward(ts)...) {}
T value;
};

[Bug c++/115858] Incompatibility of coroutines and alloca()

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-07-15
 Status|UNCONFIRMED |NEW
 CC||arsen at gcc dot gnu.org

--- Comment #1 from Arsen Arsenović  ---
current precedent in other toolchains:

- MSVC: rejects alloca entirely in coroutines
- clang: permits alloca in coroutines in many cases.  by my crude testing, it
seems to only fail if the size is dynamic and the use of the allocated region
goes over a suspension point.  this makes sense, but I'm unsure how involved of
a change it is

for now, best to mark it a 'sorry', as we do with VLAs, rather than produce
bugprone code

[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

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

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

--- Comment #3 from Jonathan Wakely  ---
Created attachment 58668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58668&action=edit
Add operator== overloads for hash table iterators

(In reply to Jonathan Wakely from comment #1)
> Secondly, we could add operator== for the actual iterator type, so that
> there's no derived-to-base conversion needed to find a candidate.

This patch implements this change. The new operator== overloads are exact
matches, so no derived-to-base or user-defined conversions are required.

I'll get to work on the std::expected proposal (which I expect will get treated
as a DR for C++23 by all implementers, certainly in libstdc++). Once I've
drafted that proposal, I'll push the corresponding code changes to libstdc++.

N.B. this slightly modified example shows why the patch needs so many new
overloads:

#include 
#include 
#include 

struct Y {};
std::unordered_map> m;
bool r = m.begin()==m.cend();

Using m.cend() means we need overloads for comparing iterator to const_iterator
(which is why the comparisons were defined on the base class in the first
place, since they only need to be done once and they work for both iterator and
const_iterator ... unless there is some other candidate that's viable).

[Bug c++/115858] Incompatibility of coroutines and alloca()

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Arsen Arsenović from comment #1)
> - clang: permits alloca in coroutines in many cases.  by my crude testing,
> it seems to only fail if the size is dynamic and the use of the allocated
> region goes over a suspension point.  this makes sense, but I'm unsure how
> involved of a change it is

So this makes sense for LLVM really since local variables are always `alloca'd`
on the stack and then optimized away. So the lowering pass for coroutines seems
to happen on LLVM bitcode rather than clang AST.

[Bug c++/115941] New: g++ compiler version 15 doesn't fails to build when g++ 12 does (may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247)

[vincent.lebourlot at starqube dot com via Gcc-bugs]

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

Bug ID: 115941
   Summary: g++ compiler version 15 doesn't fails to build when
g++ 12 does (may be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.lebourlot at starqube dot com
  Target Milestone: ---

Here is a minimal code that doesn't compile with gcc 15 trunk version 

```
gcc-15/bin/g++ --version
g++ (GCC) 15.0.0 20240715 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

```

```cpp
#include 
#include 
#include 
#include 

class piece{
public:
std::string_view view;
piece(const void*)=delete;
templateexplicit piece(const
char(&s)[n])noexcept:view(s,n-1){}
};

class NLargeStringPiece{};

class string{
private:
std::arrayvalue;
public:
string(const void*)=delete;
templatestring(const char(&s)[n])noexcept:value(){}
templateexplicit string(const
Args&...args)requires(std::conjunction_v,std::is_constructible>...>):value(){}

};

int main() noexcept{
std::vector>foo{{{"foo","foo"}}};
   
std::vector>bar{{{"bar","bar"},{"bar","bar"}}};
return 0;
}
```

and the error being printed: 

```
 ❯/usr/local/gcc/gcc-12.3/bin/g++
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp -o
/home/lebourlot/gcc15/StarQube/Sources/Scratch/Scratch.exe -std=c++2b -g -Wall
-fPIC -pie -static-libstdc++ -gdwarf-4 -pthread -maes -msse4.1 -isystem
/usr/local/include
 ❯/usr/local/gcc/gcc-15/bin/g++
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp -o
/home/lebourlot/gcc15/StarQube/Sources/Scratch/Scratch.exe -std=c++2b -g -Wall
-fPIC -pie -static-libstdc++ -gdwarf-4 -pthread -maes -msse4.1 -isystem
/usr/local/include
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp: In function
‘int main()’:
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp:27:87: error:
converting to ‘string’ from initializer list would use explicit constructor
‘string::string(const Args& ...) requires 
conjunction_v,
std::is_constructible >...> [with Args = {char [4],
char [4]}]’
   27 |
std::vector>bar{{{"bar","bar"},{"bar","bar"}}};
  |
  ^
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp:21:51: note:
‘string::string(const Args& ...) requires 
conjunction_v,
std::is_constructible >...> [with Args = {char [4],
char [4]}]’ declared here
   21 | templateexplicit string(const
Args&...args)requires(std::conjunction_v,std::is_constructible>...>):value(){}
  |   ^~
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp:27:87: error:
converting to ‘string’ from initializer list would use explicit constructor
‘string::string(const Args& ...) requires 
conjunction_v,
std::is_constructible >...> [with Args = {char [4],
char [4]}]’
   27 |
std::vector>bar{{{"bar","bar"},{"bar","bar"}}};
  |
  ^
/home/lebourlot/gcc15/StarQube/Sources/Scratch/ToolScratch.cpp:21:51: note:
‘string::string(const Args& ...) requires 
conjunction_v,
std::is_constructible >...> [with Args = {char [4],
char [4]}]’ declared here
   21 | templateexplicit string(const
Args&...args)requires(std::conjunction_v,std::is_constructible>...>):value(){}
  |   ^~
[1]876699 exit 1 /usr/local/gcc/gcc-15/bin/g++  -o  -std=c++2b -g -Wall
-fPIC -pie  -gdwarf-4 
```

[Bug c++/115941] g++ compiler version 15 doesn't fails to build when g++ 12 does (may be related to PR 109247)

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

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

--- Comment #1 from Andrew Pinski  ---
It is not related to  PR 109247 since it is rejected in GCC 13.1.0 rather than
13.3.0.

[Bug c++/115941] g++ compiler version 15 doesn't fails to build when g++ 12 does (may be related to PR 109247)

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It is not related to  PR 109247 since it is rejected in GCC 13.1.0 rather
> than 13.3.0.

s/rather than 13.3.0/rather than just 13.3.0+/.

[Bug c++/97755] Explicit default constructor is called during copy-list-initialization with a warning only

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

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

--- Comment #2 from Andrew Pinski  ---
pedwarn does change into an error with -pedantic-errors .

[Bug c++/115941] g++ compiler version 15 doesn't fails to build when g++ 12 does (may be related to PR 109247)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Related to PR 84849 and PR 60027.

Note other compilers don't always implement the correct rules when it comes
initializer list and explicit constructors.


See https://cplusplus.github.io/CWG/issues/1228.html which was closed as NAD
but currently only GCC implements it correctly.

[Bug c++/113916] gcc allows overriding a non-deleted private base class dtor with a defaulted dtor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/90790] Using override on a private overridden destructor shall produce an error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rush102333 at gmail dot com

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

[Bug tree-optimization/109573] [11 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8

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

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

--- Comment #15 from seurer at gcc dot gnu.org ---
Note that we see this on powerpc64 if the compiler is built with checks.

/home/seurer/gcc/git/build/gcc-11.5.0-RC-20240712/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-11.5.0-RC-20240712/gcc/testsuite/g++/../../
exceptions_enabled3737800.cc -fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-11.5.0-RC-20240712/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-11.5.0-RC-20240712/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/libstdc++-v3/testsuite/util
-fmessage-length=0 -S -o exceptions_enabled3737800.s
FAIL: g++.dg/vect/pr109573.cc  -std=c++2a (test for excess errors)
Excess errors:
during GIMPLE pass: slp
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/testsuite/g++.dg/vect/pr109573.cc:81:6:
internal compiler error: in vectorizable_live_operation, at
tree-vect-loop.c:8886
0x1139479b vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-loop.c:8886
0x113477a7 can_vectorize_live_stmts
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-stmts.c:10663
0x11377a43 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-stmts.c:11047
0x113b356f vect_schedule_slp_node
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:6393
0x113c457f vect_schedule_slp_node
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:6206
0x113c457f vect_schedule_scc
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:6555
0x113c431f vect_schedule_scc
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:6536
0x113c4d1f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:6671
0x113c68e7 vect_slp_region
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:5074
0x113c8047 vect_slp_bbs
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:5186
0x113c864b vect_slp_function(function*)
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vect-slp.c:5272
0x113d1dd3 execute
/home/seurer/gcc/git/gcc-11.5.0-RC-20240712/gcc/tree-vectorizer.c:1450

[Bug c++/115938] gcc allows inheriting base class with private destructor during virtual inheritance

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rush102333 at gmail dot com

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

[Bug target/115937] duplicate .plt in module's elf header

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-07-15
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
what version of binutils are you using?

GCC does not generate plts directly. Rather it is jut refers to the plt symbol.

[Bug target/115937] duplicate .plt in module's elf header

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

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

--- Comment #2 from Andrew Pinski  ---
>I changed my gcc from 7.3.0 to 10.3.1 and recompiled kernel code.


Did you change binutils version too?