[Bug c++/118340] fold expression is very slow to compile when used to initialize a variable

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
CCing author of || fix

[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Maybe the code sinking change.

[Bug target/118348] [15 Regression] [SVE] HACCKernels seems to miscompile with VLS SVE after 0c5c0c959c2e592b84739f19ca771fa69eb8dfee

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |15.0
Summary|[SVE] HACCKernels seems to  |[15 Regression] [SVE]
   |miscompile with VLS SVE |HACCKernels seems to
   |after   |miscompile with VLS SVE
   |0c5c0c959c2e592b84739f19ca7 |after
   |71fa69eb8dfee   |0c5c0c959c2e592b84739f19ca7
   ||71fa69eb8dfee

[Bug tree-optimization/118344] [15 regression] Crash at -O3 in ifcombine

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/118348] [15 Regression] [SVE] HACCKernels seems to miscompile with VLS SVE after 0c5c0c959c2e592b84739f19ca771fa69eb8dfee

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

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

--- Comment #2 from Andrew Pinski  ---
I suspect this can be reproduced before with -fno-vect-cost since that revision
is a cost model change.

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Created attachment 60070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60070&action=edit
loop2_unroll dump

[Bug target/118348] [15 Regression] [SVE] HACCKernels seems to miscompile with VLS SVE after 0c5c0c959c2e592b84739f19ca771fa69eb8dfee

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

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

--- Comment #1 from Tamar Christina  ---
Thanks for the report, taking a look

[Bug rtl-optimization/118350] New: [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

Bug ID: 118350
   Summary: [12/13/14/15 Regression] Wrong number of loop
iterations starting with r7-3839-gde0a3fa38e2ad8
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

static volatile unsigned long x = 0;
static unsigned int y = 0;
int main (void)
{
  {
  l:
++x;
--y;
if (y)
  goto l;
  }
  if (x != 0x1ul)
__builtin_abort ();
}

On s390x compiling this e.g. via gcc -O2 -funroll-loops leads to wrong code. 
At the end of doloop2 we have:

(insn 6 2 75 2 (set (reg:SI 62 [ y_lsm.6 ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 y+0 S4 A32]))
1507 {*movsi_zarch}
 (nil))
(note 75 6 72 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 72 75 73 9 (parallel [
(set (reg:SI 78)
(plus:SI (reg:SI 62 [ y_lsm.6 ])
(const_int -1 [0x])))
(clobber (reg:CC 33 %cc))
]) -1
 (nil))
(insn 73 72 74 9 (parallel [
(set (reg:SI 79)
(plus:SI (reg:SI 78)
(const_int 1 [0x1])))
(clobber (reg:CC 33 %cc))
]) -1
 (nil))

That means reg 79 contains the initial value of y which is zero.  During
doloop2 we substitute the newly computed niter which is

(insn 281 184 196 37 (set (reg:SI 82)
(lshiftrt:SI (reg:SI 79)
(const_int 3 [0x3]))) -1
 (nil))

wich resulted from unroll2

desc->niter_expr =
  simplify_gen_binary (UDIV, desc->mode, old_niter,
   gen_int_mode (max_unroll + 1, desc->mode));

Since old_niter is just y which is initially zero, dividing it by the number of
loop unrollings (in this case 8) leads to wrong code, i.e., the loop is
executed 8 times more which means the final value of x is not 0x1 but
0x8.

Although bisection stops at r7-3839-gde0a3fa38e2ad8 this doesn't seem to be the
culprit to me since it is not affecting the computation of niters.

[Bug target/118348] [15 Regression] [SVE] HACCKernels seems to miscompile with VLS SVE after 0c5c0c959c2e592b84739f19ca771fa69eb8dfee

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

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

--- Comment #3 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #2)
> I suspect this can be reproduced before with -fno-vect-cost since that
> revision is a cost model change.

No it's the commit that enables the conditional store optimization for AArch64.

I suspect it's a wrong mask and the mask is writing too much data.
Should be easy to track down.

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Created attachment 60071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60071&action=edit
loop2_doloop dump

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

Sam James  changed:

   What|Removed |Added

 CC||pthaugen at us dot ibm.com
   Target Milestone|--- |12.5

[Bug target/118330] Improving calling convention for 32-bit ARM target

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #2 from David Brown  ---
(In reply to Andrew Pinski from comment #1)
> Note you could also work with the upstream arm eabi definition here: 
> https://github.com/ARM-software/abi-aa

Yes, that is certainly a possibility I considered.  I also considered
registering an issue with the "ARM GNU Toolchain" folks here:



That's the group that puts together the most commonly used packaging of gcc for
embedded ARM, along with libraries and all the associated code generation
tools.

However, I believe this could be a feature that would be of use in many gcc
targets.  And I thought it best to at least talk about the practical aspects of
implementation here first.  

If this is something that the gcc developers can see being useful on multiple
targets and can be implemented as an extension (such as using a function
attribute rather than as a full new ABI), then that would be great from my
viewpoint.  

If, on the other hand, the gcc developers feel this is a major change and
should only come about via a new ABI from ARM, then the "abi-aa" github project
is the route to go.  The end results that way would be better too - no need for
function attributes, and compatibility across different compilers.  I suspect,
however, that that route would take much longer to lead to results.

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Stefan Schulze Frielinghaus from comment #0)
> Although bisection stops at r7-3839-gde0a3fa38e2ad8 this doesn't seem to be
> the culprit to me since it is not affecting the computation of niters.


https://inbox.sourceware.org/gcc-patches/c8e17e19-7468-2377-66c4-5ce6eb2ff...@linux.vnet.ibm.com/

[Bug target/118351] New: [15 Regression] 6% regression in 470.lbm_r in SPECCPU 2006 on AArch64

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

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

Bug ID: 118351
   Summary: [15 Regression] 6% regression in 470.lbm_r in SPECCPU
2006 on AArch64
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: wilco at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

There is a 6% regression on lbm in SPECCPU2006 on Neoverse-V1 after this
change:

commit c5db3f50bdf34ea96fd193a2a66d686401053bd2
Author: Wilco Dijkstra 
Date:   Fri Nov 1 14:40:26 2024 +

AArch64: Switch off early scheduling

The hot loop seems to now spill simple constants instead of rematerializing
them through an fmov.

The same regression also shows up in lbm in SPECCPU 2017 but only with PGO.

[Bug target/118351] [15 Regression] 6% regression in 470.lbm_r in SPECCPU 2006 on AArch64

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

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

--- Comment #1 from Andrew Pinski  ---
lbm is very very sensitive to register pressure.

[Bug target/118351] [15 Regression] 6% regression in 470.lbm_r in SPECCPU 2006 on AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/118351] [15 Regression] 6% regression in 470.lbm_r in SPECCPU 2006 on AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
> The hot loop seems to now spill simple constants instead of rematerializing 
> them through an fmov.

Hmm, might be related to PR 102178.

[Bug target/118351] [15 Regression] 6% regression in 470.lbm_r in SPECCPU 2006 on AArch64

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> > The hot loop seems to now spill simple constants instead of rematerializing 
> > them through an fmov.
> 
> Hmm, might be related to PR 102178.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178#c28 :
"If in the future we have a target which can move double immediate into fp regs
we can introduce some target hooks to deal with equiv double constant.  But
right now I think there is no need for the new hook." 

[Bug c++/94243] Missed C++ front-end devirtualizations from Clang testsuite

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

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

--- Comment #2 from Andrew Pinski  ---
Split the first one off to PR 118352, the rest deal with static_cast.

[Bug c++/118352] New: final virtual dtor allows for class to be treated as final for devirtualization

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

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

Bug ID: 118352
   Summary: final virtual dtor allows for class to be treated as
final for devirtualization
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Split off from PR 94243 since the others there have static_cast being involved
while this one does not.

Take:
```
namespace Test2a {
  struct A {
virtual ~A() final {}
virtual int f();
  };

  // CHECK-LABEL: define i32 @_ZN6Test2a1fEPNS_1AE
  int f(A *a) {
// CHECK: call i32 @_ZN6Test2a1A1fEv
return a->f();
  }
}
```

The front-end should be able to treat the `A` class as being final for
devirtualization reasons because a class cannot extend it.

[Bug c++/58140] -Wnon-virtual-dtor shouldn't fire for classes declared final

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Looks like this was missed when PR 62232 was created and fixed.  Anyways this
has been fixed since GCC 5. Dup.

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

[Bug c++/62232] -Wnon-virtual-dtor shouldn't warn on final classes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tudorb at gmail dot com

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

[Bug c++/118352] final virtual dtor allows for class to be treated as final for devirtualization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2025-01-08
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
I think the fix is to change resolves_to_fixed_type_p to check if there is a
virtual dtor and if it is final if !CLASSTYPE_FINAL.

I will try this for GCC 16.

[Bug middle-end/118334] Missing internals documentation for: INT_N, FRACTIONAL_INT_MODE, PARTIAL_INT_MODE

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Georg-Johann Lay from comment #2)
>   Optionally, NAME is the new name of the mode.  NAME is the
>   name of the mode.

What does this mean?!

It seems confusing to me that INT_MODE and FRACTIONAL_MODE declare a new mode
named by the first argument, but PARTIAL_INT_MODE is named by the _third_
argument. For extra confusion the first argument is named consistently with
INT_MODE and FRACTIONAL_INT_MODE but has a different meaning.

[Bug c++/118349] Suggestion for new warning: -Wtemplate-depth= (like -ftemplate-depth= but a warning instead of an error)

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #0)
> for users who are okay with template usage, but just
> don't want it to get out of hand.

What does "get out of hand" mean?  What unwanted consequence would you be
preventing with this check?

The point of imposing a limit is so that buggy code with infinite recursion
will (hopefully) stop compiling before the system runs out of memory. So it's a
check to make accidental infinite recursion fail sooner, rather than grind to a
halt later.

I'm not aware of a good use case for "I want some templates, but not too much".

[Bug c++/118349] Suggestion for new warning: -Wtemplate-depth= (like -ftemplate-depth= but a warning instead of an error)

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

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

--- Comment #3 from Sam James  ---
People already misunderstand the current option as well (PR65042). It'd just
get worse.

[Bug libstdc++/118341] Missing -D_GLIBCXX_ASSERTIONS checks for

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

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

--- Comment #3 from Jonathan Wakely  ---
The debug bitset also does checking in its reference type, but only for C++98:

  // In C++11 we rely on normal reference type to preserve the property
  // of bitset to be use as a literal.
  // TODO: Find another solution.
#if __cplusplus >= 201103L
  typedef typename _Base::reference reference;
#else
  // bit reference:
  class reference
  : private _Base::reference
, public __gnu_debug::_Safe_iterator_base
  {

That should be revisited.

[Bug tree-optimization/118353] New: Implement greedy algorithm for switch jump table cluster finding

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

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

Bug ID: 118353
   Summary: Implement greedy algorithm for switch jump table
cluster finding
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: ak at gcc dot gnu.org
  Target Milestone: ---

In the switchlower pass the algorithm for finding jump table clusters is at
least quadratic.  There haven't been any concrete problems reported yet, but
theoretically, this could cause long compilation times in some specific cases.

It would be nice to avoid these problems.  To do that we could implement a
greedy algorithm for finding jump table clusters which wouldn't necessarily
find the optimal clustering but would run quickly.  We could switch to this
algorithm when --param switch-lower-slow-alg-max-cases is exceeded (when the
switch has more than this number of cases).  This would be similar to how
switch bit test clustering is currently done.

This was previously discussed in pr118032.

[Bug rtl-optimization/118266] [15 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591 by r15-5863-g5ab3f091b3eb42

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

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

--- Comment #16 from H.J. Lu  ---
ree turns:

(insn 27 26 139 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "x.ii":14:17 discrim 1 283 {*addsi_1}
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 139 27 28 2 (set (reg/v:SI 42 r14 [orig:102 i ] [102])
(const_int 0 [0])) "x.ii":14:17 discrim 1 96 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(note 28 139 124 2 NOTE_INSN_DELETED)
(insn 124 28 125 2 (set (reg/f:SI 41 r13 [142])
(plus:SI (reg:SI 43 r15 [146])
(const_int 4 [0x4]))) 264 {*leasi}
 (nil))
(insn 125 124 43 2 (set (reg/f:SI 40 r12 [143])
(plus:SI (reg:SI 43 r15 [146])
(const_int 8 [0x8]))) 264 {*leasi}
 (nil))
(insn 43 125 74 2 (set (reg/f:DI 6 bp [145])
(zero_extend:DI (reg/f:SI 7 sp))) "x.ii":15:9 175 {*zero_extendsidi2}
 (nil))

into

(insn 27 26 155 2 (parallel [
(set (reg:DI 6 bp) 
(zero_extend:DI (plus:SI (reg/f:SI 7 sp) 
(const_int 16 [0x10]
(clobber (reg:CC 17 flags))
]) "x.ii":14:17 discrim 1 296 {addsi_1_zext}
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 155 27 139 2 (set (reg:DI 7 sp) 
(reg:DI 6 bp)) "x.ii":14:17 discrim 1 -1
 (nil))
(insn 139 155 28 2 (set (reg/v:SI 42 r14 [orig:102 i ] [102])
(const_int 0 [0])) "x.ii":14:17 discrim 1 96 {*movsi_internal}
 (expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(note 28 139 124 2 NOTE_INSN_DELETED)
(insn 124 28 125 2 (set (reg/f:SI 41 r13 [142])
(plus:SI (reg:SI 43 r15 [146])
(const_int 4 [0x4]))) 264 {*leasi}
 (nil))
(insn 125 124 74 2 (set (reg/f:SI 40 r12 [143])
(plus:SI (reg:SI 43 r15 [146])
(const_int 8 [0x8]))) 264 {*leasi}
 (nil))

[Bug rtl-optimization/118266] [15 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591 by r15-5863-g5ab3f091b3eb42

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

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

--- Comment #15 from H.J. Lu  ---
ree generates:

(insn 155 27 139 2 (set (reg:DI 7 sp) 
(reg:DI 6 bp)) "x.ii":14:17 discrim 1 -1
 (nil))

It restores SP from BP.

[Bug c++/118349] Suggestion for new warning: -Wtemplate-depth= (like -ftemplate-depth= but a warning instead of an error)

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #4)
> Yes, it's just a hypothetical example, I probably wouldn't actually use such
> a low value myself, but rather would determine an appropriate value
> experimentally on a project-by-project basis.

I argue there is no appropriate value.

> It's mostly just a style thing; I find that the deeper template nesting gets
> in a project, the harder to understand I find it to be.

Surely that's true of any nesting, including deeply nested functions. Why is it
particular to templates?

> Also excessive
> template depth can lead to code size bloat; I've seen this in some projects
> that abuse certain boost templates, for example.

Template bloat has nothing to do with instantiation *depth*, it's a design
problem. Non-dependent code can (and sometimes should) be hoisted out into
bases or functions that can be shared by different specializations.

But you know what such hoisting does? It *increases* instantiation depth.
Reducing the use of templates doesn't necessarily reduce code size. Sensible
use of template can reduces code size (by avoiding code duplication) and the
instantiation depth is an incidental implementation detail, not a sign of good
or bad use of templates.


> (In reply to Sam James from comment #3)
> > People already misunderstand the current option as well (PR65042). It'd just
> > get worse.
> 
> This actually seems like a perfect example of a case where the user should
> have been using -Wtemplate-depth= (if it had existed) instead of
> -ftemplate-depth=.

There was no justification given for using -ftemplate-depth in that PR so it's
also not justification for -Wtemplate-depth.

[Bug target/80782] Configure options to use llvm/clang assembler on Mac

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #17 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #16)

Why not use `llas` (which only needs LLVM) instead of `clang` (which needs LLVM
+ clang)?
I have seen in some ticket that you have built gcc, setting your `llas` (from
7.1.1?) as the assembler.

[Bug target/118329] avr defines __int24 but doesn't define __GLIBCXX_TYPE_INT_N_0

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

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

--- Comment #8 from Georg-Johann Lay  ---
(In reply to Jonathan Wakely from comment #0)
> avr uses FRACTIONAL_INT_MODE while e.g. msp430 uses PARTIAL_INT_MODE,
> don't remember the difference
The comments in machmode.def propose that PARTIAL_INT_MODE defines a mode with
the same size but a lower precision, whereas FRACTIONAL_INT_MODE defines a new
mode with a smaller size (dunno if that implies that the new precision must be
a multiple or 8?).

One more difference is that PARTIAL_INT_MODE's new mode is in class
PARTIAL_INT, whereas FRACTIONAL_INT_MODE's is in class INT.

Though that's mostly guessing as the documentation is poor and incomplete.

[Bug target/80782] Configure options to use llvm/clang assembler on Mac

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

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

--- Comment #18 from Iain Sandoe  ---
(In reply to Sergey Fedorov from comment #17)
> (In reply to Iain Sandoe from comment #16)
> 
> Why not use `llas` (which only needs LLVM) instead of `clang` (which needs
> LLVM + clang)?
> I have seen in some ticket that you have built gcc, setting your `llas`
> (from 7.1.1?) as the assembler.

because most (I would say almost all) people who build GCC for macOS use the
existing installation of Xcode to provide the assembler and linker.  For the
latest OS versions, building the linker is not even possible - the new one is
closed source.

So, we _could_ require building the [cctools/LLVM] "binutils" for macOS - but
we would then need to support a linker that works on "latest".  That's a step
I've been reluctant to take because it adds more support work where we're
already overloaded.

[Bug tree-optimization/118361] New: [meta-bug] Expensive arithmetic instead of a simple bit test

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

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

Bug ID: 118361
   Summary: [meta-bug] Expensive arithmetic instead of a simple
bit test
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

This PR collects PRs that suffer from very expensive code where a simple
test-bit-and-branch would be perfectly fine.

* Most of the PRs are NOT a "missed optimization" but have been introduced
DELIBERATELY like PR118012 in match.pd.

* On AVR, bit tests are cheap. No extra register pressure, no pipeline
disruption, etc.

* AVR is an 8-bit archtiecture without a barrel shifter.  AVR doesn't have MUL,
or multiplication like mulhi3 or mulsi3 is very expensive.  Even negsi2 is
expensive (costs 7 instructions and register pressure).  Signed / unsigned
bit-extraction is alse expensive, in particular when the are performed on the
full mode size.

* Many parts of the tree optimizers / match.pd don't even try to work out
costs.  Same for parts of the RTL lowering middel-end.

* RTX costs may be a bad proxy for real costs, e.g. a library call for mulsi3
is "just a CALL" but still ill when a bit test could do the job (and the source
spells out a bit test).

[Bug target/118357] New: risc-v xtheadvector did not handle the logic of vsetvl properly

[shuizhuyuanluo at gmail dot com via Gcc-bugs]

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

Bug ID: 118357
   Summary: risc-v xtheadvector did not handle the logic of vsetvl
properly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shuizhuyuanluo at gmail dot com
  Target Milestone: ---

original issue https://github.com/XUANTIE-RV/xuantie-gnu-toolchain/issues/24

this issue can be reproduced with upstream gcc too



quote:

the XTheadVector did not handle the logic of vsetvl properly and still simply
reused RVV 1.0. In RVV 1.0, the vsetvli zero,zero,e32,m8 indicates that avl
does not change (avl = 16), but in XTheadVector, it indicates that avl takes
the maximum value (avl = 32). This results in out-of-bounds occurring when the
vector var is stored.



minimal testcase

-
riscv64-unknown-linux-gnu-gcc -march=rv64gc_xtheadvector fp16.c -o fp16 -O2
-static
qemu-riscv64 -cpu c906fdv ./fp16
a = -8  -7  -6  -5  -4  -3  -2  -1  0  1  2  3  4  5  6  7  
a = -8  -7  -6  -5  -4  -3  -2  -1  0  1  2  3  4  5  6  7  
Segmentation fault (core dumped)

-
#include 
#include 

int main()
{
float a[16] = {-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7};

fprintf(stderr, "a = ");
for (int i=0; i<16; i++)
{
fprintf(stderr, "%.0f  ", a[i]);
}
fprintf(stderr, "\n");

float* ptr = a;

int n = 16;
while (n > 0)
{
size_t vl = __riscv_vsetvl_e32m8(n);

// fp32 -> fp16 -> fp32
vfloat32m8_t _p = __riscv_vle32_v_f32m8(ptr, vl);
vfloat16m4_t _half = __riscv_vfncvt_f_f_w_f16m4(_p, vl);
vfloat32m8_t _out = __riscv_vfwcvt_f_f_v_f32m8(_half, vl);
__riscv_vse32_v_f32m8(ptr, _out, vl);

ptr += vl;
n -= vl;
}

fprintf(stderr, "a = ");
for (int i=0; i<16; i++)
{
fprintf(stderr, "%.0f  ", a[i]);
}
fprintf(stderr, "\n");

return 0;
}

[Bug middle-end/116860] [15 Regression] New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails

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

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

ptomsich at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  
|konstantinos.eleftheriou@vr
   ||ull.eu
   Last reconfirmed||2025-01-08
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/118301] Feature request: CLI parament std with explicit experimental values

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

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

--- Comment #6 from Richard Sandiford  ---
(In reply to Jonathan Wakely from comment #5)
> We already have -std=c++2a for that and it doesn't solve anything.
You obviously know better than me :), but I thought c++2a was used for things
that aren't yet fully specified.  Here it's about something that is fully
specified but whose GCC implementation isn't fully supported/is still
experimental.  If we release with -std=c++20 while support for C++20 is still
considered experimental then -std=c++2a (being a different option) doesn't
cover that case.

[Bug rtl-optimization/118358] New: [15 Regression] LRA hangs on xstormy16

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

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

Bug ID: 118358
   Summary: [15 Regression] LRA hangs on xstormy16
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Tamar's recent changes for affine folding to improve exchange2's performance on
some architectures is causing xstormy16 to go into an infinite loop in LRA
compiling the attached testcase (slightly simplified from gcc.dg/20020426-2.c).

Compile with -O2 with an xstormy16-elf cross compiler to observe the hang. 
This could well be a problem with the xstormy port; I haven't tried to asses
that.

/* PR optimization/6475
   Distilled from zlib sources.  */
/* { dg-do run } */
/* { dg-options "-O2" } */
/* { dg-options "-O2 -frename-registers -fomit-frame-pointer -fPIC -mtune=i686"
{ target { { i?86-*-* x86_64-*-* } && { ia32 && fpic } } 
} } */
/* { dg-skip-if "exceeds eBPF stack limit" { bpf-*-* } } */

extern void exit (int);

typedef struct
{
  union
  {
struct
{
  unsigned char a3;
  unsigned char a4;
} a2;
unsigned int a5;
  } a0;
  unsigned int a1;
} A;

static int
foo (unsigned int *b, unsigned int n, unsigned int s, const unsigned int *d,
 const unsigned int *e, A **t, unsigned int *m, A *hp, unsigned int *hn,
 unsigned int *v)
{
  unsigned int a, c[15 + 1], f;
  int g, h;
  unsigned int i, j, k;
  int l;
  unsigned int ee;
  unsigned int *p;
  A *q, r, *u[15];
  int w;
  unsigned int x[15 + 1], *xx;
  int y;
  unsigned int z;
  for (j = 1; j <= 15; j++)
if (c[j])
  break;
  if ((unsigned int) l < j)
l = j;
  for (i = 15; i; i--)
if (c[i])
  break;
  g = i;
  for (y = 1 << j; j < i; j++, y <<= 1)
if ((y -= c[j]) < 0)
  return -3;
  h = -1;
  z = 0;
  for (; k <= g; k++)
{
  while (k > w + l)
{
  h++;
  w += l;
  if ((f = 1 << (j = k - w)) > a + 1)
;
  z = 1 << j;
  if (*hn + z > 1440)
return -3;
  u[h] = q = hp + *hn;
  r.a0.a2.a4 = (unsigned char) l;
  r.a1 = (unsigned int) (q - u[h - 1] - j);
}
  for (j = i >> w; j < z; j += f)
q[j] = r;
  for (j = 1 << (k - 1); i & j; j >>= 1)
i ^= j;
  while ((i & ee) != x[h])
{
  h--;
  w -= l;
}
}
  return y != 0 && g != 1 ? (-5) : 0;
}

unsigned int a[19] = { 3, 4, 0, 2, 2, [17] = 3, 3 };
unsigned int d[19];
A h[1440];

int
main (void)
{
  unsigned int b = 0, c = 0;
  A *e = 0;
  foo (a, 19, 19, 0, 0, &e, &b, h, &c, d);
  exit (0);
}

[Bug target/118356] RISC-V: -falign-labels=0 should (probably) default to 4

[schwab--- via Gcc-bugs]

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

--- Comment #5 from Andreas Schwab  ---
There are jump_align and loop_align members in the struct riscv_tune_param
which set the defaults for -falign-jumps and -falign-loops, but nothing sets
them to non-NULL yet.

[Bug fortran/118337] [15 Regression] Fortran *.mod compatibility

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

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

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

https://gcc.gnu.org/g:21ee71afa72746367cab7847f950448f04607dd2

commit r15-6704-g21ee71afa72746367cab7847f950448f04607dd2
Author: Jakub Jelinek 
Date:   Wed Jan 8 20:07:47 2025 +0100

fortran: Bump MOD_VERSION to "16" [PR118337]

As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and
GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic
modules, because new entries have been added to those modules in the
middle,
causing changes in the constants emitted in the *.mod files.

Also, I fear modules produced with GCC 15 with -funsigned and using
UNSIGNED
in the modules will be unreadable by GCC 14.

The following patch just bumps MOD_VERSION for this.

Note, a patch for accepting also MOD_VERSION "15" has been posted
incrementally.

2025-01-08  Jakub Jelinek  

PR fortran/118337
* module.cc (MOD_VERSION): Bump to "16".

[Bug rtl-optimization/118266] [15 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591 by r15-5863-g5ab3f091b3eb42

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

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

--- Comment #18 from Matthias Klose  ---
yes, that fixes the cross build based on trunk 20250108. Thanks!

[Bug c++/118365] New: try to define an overloaded function template for a namespace, without having first declared it in that namespace

[ing.russomauro at gmail dot com via Gcc-bugs]

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

Bug ID: 118365
   Summary: try to define an overloaded function template for a
namespace, without having first declared it in that
namespace
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ing.russomauro at gmail dot com
  Target Milestone: ---

This bug comes from a wrong implementation of the swap idiom, where I was
trying to define an overload of std::swap.

The code is correctly rejected by clang and MVSC, it uses concepts but I guess
simpler cases may be constructed:


https://godbolt.org/z/TvqK7Kv4z


#include 
#include 
#include 

template
concept C = requires (T a){a.x;};

template
void std::swap(T& lhs, T& rhs) {
std::cout << "overloaded swap\n";
}

struct S{
int x;
};

int main(){
S a, b;
std::swap(a,b);
}

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from David Malcolm  ---
Do we have a tracker bug for "UX fixes for porting to GCC 15" yet?  This one
feels important for that.

[Bug rtl-optimization/118266] [15 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591 by r15-5863-g5ab3f091b3eb42

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #60072|0   |1
is obsolete||

--- Comment #19 from H.J. Lu  ---
Created attachment 60077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60077&action=edit
A revised patch

This is the revised patch I am checking in.

[Bug c++/118347] Nested template class name inside template class with default parameter is not treated as a dependent template name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Looks like this was changed by PR 94057 which implemented DR 1710. 

clang explictly says no to implementing DR 1710/1812:
https://clang.llvm.org/cxx_dr_status.html


https://gcc.gnu.org/projects/cxx-dr-status.html says it has it implemented.

So I am going out on a limb to say no other compiler implements this defect
report except for GCC.

So invalid.

[Bug c++/118347] Nested template class name inside template class with default parameter is not treated as a dependent template name

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

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

--- Comment #4 from Andrew Pinski  ---
The key here is:
https://timsong-cpp.github.io/cppwp/n4868/temp.names#4.sentence-4

Which says:
In these contexts, a < token is always assumed to introduce a
template-argument-list.

The context reffered to here is "typename-specifier ([temp.res]),
elaborated-type-specifier ([dcl.type.elab]), using-declaration
([namespace.udecl]), or class-or-decltype ([class.derived])" .

In case of comment #0, the context is a class-or-decltype context.

So yes this is invalid.

[Bug c++/118346] Access to member inherited from virtual base class forbidden in GCC with temporary null pointer instance

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-01-09

--- Comment #1 from Andrew Pinski  ---
Confirmed. The error message was last changed with r0-44513-g50ad96428042fa .

[Bug libgcc/118369] New: Multilib bootstrap on Debian 12 fails due to missing asm/errno.h

[iii at linux dot ibm.com via Gcc-bugs]

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

Bug ID: 118369
   Summary: Multilib bootstrap on Debian 12 fails due to missing
asm/errno.h
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iii at linux dot ibm.com
  Target Milestone: ---

I'm trying to bootstrap gcc with multilib on cfarm422. It is running debian 12,
and as far as I can see all the necessary cross packages are installed.

./configure && make fails with:

[...]/gcc/build1/./gcc/xgcc -B[...]/gcc/build1/./gcc/
-B/usr/local/x86_64-linux-gnu/bin/  -B/usr/local/x86_64-linux-gnu/lib/../lib32/
-B/usr/local/x86_64-linux-gnu/lib/ -isystem /usr/local/x86_64-linux-gnu/include
-isystem /usr/local/x86_64-linux-gnu/sys-include   -fno-checking -g -O2 -m32
-O2  -g -O2 -DIN_GCC   -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection
-mshstk -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/.
-I../../../../libgcc/../gcc -I../../../../libgcc/../include
-I../../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/bits/errno.h:26,
 from /usr/include/errno.h:28,
 from ../../../../libgcc/../gcc/tsystem.h:101,
 from ../../../../libgcc/libgcc2.c:27:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or
directory
1 | #include 
  |  ^

However, running ./configure with the same flags as the distro-built GCC
succeeds.

The minimal set of working options appears to be: --prefix=/usr
--build=x86_64-linux-gnu. This ultimately adds -isystem
/usr/x86_64-linux-gnu/include to the problematic GCC invocation, which makes
the issue go away.

I have two concerns here:

- Is it okay that the argument-less ./configure does not work?

- Is it okay that the -m32 libgcc build relies on headers from
/usr/x86_64-linux-gnu/include and not from /usr/i686-linux-gnu/include?

[Bug c/118373] New: gcc-14.2 kernel panic on alderlake cpus

[lancethepants at gmail dot com via Gcc-bugs]

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

Bug ID: 118373
   Summary: gcc-14.2 kernel panic on alderlake cpus
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lancethepants at gmail dot com
  Target Milestone: ---

I'm the maintainer of linux firewall distro (Tomato64) and I've recently
received several reports of what appears to be kernel panics on alderlake cpus.
After several weeks of troubleshooting I've narrowed it down to when our
toolchain was updated from gcc-14.1 to gcc-14.2.

When I go to our latest build, which has the alderlake issue and revert
gcc-14.2 to gcc-14.1 (and also binutils 2.43.1 to 2.42, although I don't think
is relevant), the kernel panics go away.  Similarly when I go to our last known
good build that does not have the alderlake issue, and I make the singular
change from gcc-14.1 to gcc-14.2, the kernel panics show up.

We have experienced this issue over a range of kernel from 6.10.x, 6.11.x and
6.12.x. All the kernels we've run since the upgrade to gcc-14.2.

Kernel panics have been reported on the following alderlake cpus
n100
n305

Kernel panics do not appear on these reported cpus, including some 11th gen
ones.
Intel 11th Gen N5105
Intel I3-1115G4
Intel Celeron 3215U
Intel Celeron J6412
Intel i7-7550U
Intel i5-2400

The issue does not appear when running the firewall distro in Proxmox on an
alderlake device, only when running bare metal.

Also on one aarch64 device I support we do not see this issue.

We carry only a few kernel patches found here.
https://github.com/tomato64/tomato64/tree/master/tomato64/board/x86_64/linux-patches

And the kernel config here if relevant
https://github.com/tomato64/tomato64/blob/master/tomato64/board/x86_64/linux.config

Sorry not a very technical report, but I wanted to see if there's already known
issues with this combination.

[Bug c/118373] gcc-14.2 kernel panic on alderlake cpus

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

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

--- Comment #1 from Sam James  ---
Please include the full output from a kernel panic (so we can see the
backtrace).

We will also need you to do the following:
a) bisect GCC;
b) obtain a build-tree built before and after the bad commit (then can bisect
by objects, but I can explain how to do that once you have it)

[Bug tree-optimization/63644] Kahan Summation with fast-math, pattern not always recognized

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work|10.1.0, 7.1.0   |
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Blocks||114527
   Last reconfirmed||2025-01-09

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It is kinda of vectorized:
> 
>   :
>   # vect_vec_iv_.37_29 = PHI  1.0001490116119384765625e-1, 2.000298023223876953125e-1,
> 3.0011920928955078125e-1, 4.00059604644775390625e-1 }(4)>
>   # ivtmp.43_16 = PHI 
>   vect_vec_iv_.37_30 = vect_vec_iv_.37_29 + { 4.00059604644775390625e-1,
> 4.00059604644775390625e-1, 4.00059604644775390625e-1,
> 4.00059604644775390625e-1 };
>   vect_s_10.38_32 = vect_vec_iv_.37_29 + { 1.0001490116119384765625e-1,
> 1.0001490116119384765625e-1, 1.0001490116119384765625e-1,
> 1.0001490116119384765625e-1 };
>   ivtmp.43_13 = ivtmp.43_16 + 1;
>   if (ivtmp.43_13 >= bnd.33_20)
> goto ;
>   else
> goto ;
> 
> But then the vectorization part is removed:
>   :
>   _33 = BIT_FIELD_REF ;
> 
> 
> This is odd.

I was misunderstanding what was happening.

GCC vectorized the loop but that just decreased the number of iterations by a
factor of 4 but really. We should just produce n * tenth here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114527
[Bug 114527] [meta-bug] missed sccp (final value) optimizations

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-01-09
 Status|UNCONFIRMED |WAITING
   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
Since you are using buildroot to do the build. You might want to ask them too.

Also is the kernel panic random or is it the same all the time?

If it is the same all the time, what is the panic? It might be useful to
disassamble around where the panic is located.  Maybe a bad instruction is
being executed. That is the kernel was not built for a generic CPU and is
executing on a different kind of cpu that is specified from the compiler
options.

Provide the full build log of the kernel with `V=1` since that is 100%
important to get how gcc is being invoked.

[Bug tree-optimization/63644] Kahan Summation with fast-math, pattern not always recognized

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

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

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
```
float counter(int maxl) {
   float tenth=0.1f;
   float sum = tenth; 
   int n=0;
   while(n

[Bug fortran/118372] Bogus error when passing polymorphic-result function

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Comment on attachment 60078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60078
Code that demonstrates the issue

This fixed on gfortran version 15. I have not checked 14 yet.

[Bug fortran/118372] Bogus error when passing polymorphic-result function

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

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

--- Comment #2 from Jerry DeLisle  ---
Also appears to be OK on 14 as well.

[Bug c/118375] New: Fixits for feature test macros (FTMs)

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

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

Bug ID: 118375
   Summary: Fixits for feature test macros (FTMs)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We don't currently include any hints for feature test macros (FTMs) but this
came up quite a lot with the C99/GCC 14 porting work especially.

For example, with this in C:
```
// no _GNU_SOURCE defined
#include 

int main() {
char* x = program_invocation_name;
}
```

We get:
```
:1:1: error: expected identifier or '(' before '/' token
1 | /#include 
  | ^
:1:2: error: stray '#' in program
1 | /#include 
  |  ^
Compiler returned: 1
```

We could emit fixits for these. Note that this is rarely an issue for C++ (see
PR11196 and so on).

(See also PR115735 where we've discussed scraping some information out of glibc
docs.)

(dave, I've cc'd you on this for completeness but it hasn't come up in this
cycle and it *tends* to be more of an issue with either older glibc or musl, as
we've moved towards including more in _DEFAULT_SOURCE for glibc in recent years
to avoid people getting this wrong.)

[Bug middle-end/118377] New: [15 Regression] ICE when using C division operator with svint8 and svint16

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

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

Bug ID: 118377
   Summary: [15 Regression] ICE when using C division operator
with svint8 and svint16
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: soumyaa at gcc dot gnu.org
  Target Milestone: ---

When using the C division operator with svint8 and svint16 SVE ACLE vectors,
the following ICE occurs:

during GIMPLE pass: veclower
test.c: In function ‘foo’:
test.c:4:1: internal compiler error: in to_constant, at poly-int.h:592
4 | foo (svint16_t x)
  | ^~~
0x2366fab internal_error(char const*, ...)
../../gcc_src/gcc/diagnostic-global-context.cc:517
0x81b1b3 fancy_abort(char const*, int, char const*)
../../gcc_src/gcc/diagnostic.cc:1722
0x80902f poly_int<2u, unsigned long>::to_constant() const
../../gcc_src/gcc/poly-int.h:592
0x130096b poly_int<2u, unsigned long>::to_constant() const
../../gcc_src/gcc/poly-int.h:590
0x130096b nunits_for_known_piecewise_op
../../gcc_src/gcc/tree-vect-generic.cc:92
0x130096b expand_vector_piecewise
../../gcc_src/gcc/tree-vect-generic.cc:294
0x130152b expand_vector_operation
../../gcc_src/gcc/tree-vect-generic.cc:1159
0x130400b expand_vector_operations_1
../../gcc_src/gcc/tree-vect-generic.cc:2243
0x1305e33 expand_vector_operations
../../gcc_src/gcc/tree-vect-generic.cc:2274
0x1305e33 execute
../../gcc_src/gcc/tree-vect-generic.cc:2326

Testcase (compiled with -mcpu=neoverse-v2):

#include 

svint16_t
foo (svint16_t x)
{
  return x / 4;
}

This most likely happens because SVE integer division using SDIV/UDIV is only
supported for 32-bit and 64-bit modes, and the middle-end does not have a
proper fallback if any other types are forced.

[Bug c++/118381] GCC ignores missing 'noexcept'/`throw()` specifier for friend declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||3.4.6, 4.6.4
Summary|GCC ignores missing |GCC ignores missing
   |'noexcept' specifier for|'noexcept'/`throw()`
   |friend declaration  |specifier for friend
   ||declaration

--- Comment #1 from Andrew Pinski  ---
Confirmed, looks not to be a regression either. 

A C++98 testcase:
```
struct S
{  
  void f() throw(){}
};


class C
{
  friend void S::f();
};
int main()
{
  C ci;
}
```

[Bug c/118376] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1152 with -Wsign-conversion

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
Valgrind reports uninitialised uses, all from the same stack allocation:

$ x86_64-pc-linux-gnu-gcc -Wsign-conversion testcase.c -wrapper
valgrind,-q,--track-origins=yes
==2541== Conditional jump or move depends on uninitialised value(s)
==2541==at 0x2F52D4B: line_maps::can_be_stored_compactly_p(unsigned long,
source_range, void*, unsigned int) const (line-map.cc:156)
==2541==by 0x2F54814: line_maps::get_or_create_combined_loc(unsigned long,
source_range, void*, unsigned int) (line-map.cc:197)
==2541==by 0x1A374DB: set_source_range(tree_node*, source_range)
(tree.cc:14731)
==2541==by 0xF78BE8: set_c_expr_source_range (c-parser.cc:97)
==2541==by 0xF78BE8: c_parser_cast_expression(c_parser*, c_expr*)
(c-parser.cc:10338)
==2541==by 0xF78DBF: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.cc:10113)
==2541==by 0xF7A383: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.cc:9808)
==2541==by 0xF7ABC4: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.cc:9721)
==2541==by 0xF7F6E3: c_parser_expr_list(c_parser*, bool, bool,
vec**, unsigned long*, tree_node**, vec*, unsigned int*) (c-parser.cc:13950)
==2541==by 0xF90AF0: c_parser_postfix_expression_after_primary(c_parser*,
unsigned long, c_expr) (c-parser.cc:13589)
==2541==by 0xF71684: c_parser_postfix_expression(c_parser*)
(c-parser.cc:13185)
==2541==by 0xF76D4A: c_parser_unary_expression(c_parser*)
(c-parser.cc:10504)
==2541==by 0xF789CB: c_parser_cast_expression(c_parser*, c_expr*)
(c-parser.cc:10345)
==2541==  Uninitialised value was created by a stack allocation
==2541==at 0xF71550: c_parser_postfix_expression(c_parser*)
(c-parser.cc:11326)
==2541== 
==2541== Conditional jump or move depends on uninitialised value(s)
...

[Bug c++/118382] [c++17] extern variable for template with default template argument should be invalid

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-09
  Known to fail||7.1.0
Summary|GCC fails to detect |[c++17] extern variable for
   |erroneous implicit template |template with default
   |argument specification in   |template argument should be
   |extern class declaration|invalid
   |for template class with |
   |default argument|
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Note clang's error message is not good either.

Looks like it was introduced when automatic deduction of template arguments for
types was added.

[Bug tree-optimization/115340] Loop/SLP vectorization possible inefficiency

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 8 Jan 2025, rdapp.gcc at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115340
> 
> --- Comment #6 from rdapp.gcc at gmail dot com ---
> >> Another thought I had as we already know that SLP handles this more 
> >> gracefully:
> >> Would it make sense to "just" defer to BB vectorization and have loop
> >> vectorization not do anything, provided we could detect the pattern with
> >> certainty?  That would still be special casing the situation but 
> >> potentially
> >> less intrusive than "Hail Mary" unrolling.
> >
> > Yes, I would expect costing to ensure we don't loop vectorize it, but then
> > we don't (and can't easily IMO) compare loop vectorization to
> > basic-block vectorization after unrolling cost-wise, so ...
> 
> Sure, I see the predicament.
> 
> Just to make sure I understand:  If we performed virtual unrolling (and
> re-rolling) in the vectorizer couldn't we "natively" recognize and vectorize
> this pattern and no special handling would be necessary if we e.g.
> attempted VF=16?

The issue is that I can't see how to "natively" recognize this, or rather
how to represent this with the current vectorizer capabilities short of
a bunch of very ugly hacks.

That is, all dataref and dependence analysis work on the original IL
and only after those we determine the VF.  But for this case to work
we'd ideally swap this around - always do unroll by VF and then do
all the analysis as if VF == 1.  But that's a much larger and more
invasive change (and one I can't easily see working out in the end).

> So the attempt to recognize during early unroll would be a stop gap until
> that's fully working and in place (which might take longer than one GCC 
> cycle)?

Yeah, but eventually this is a similar category like other high-level
loop transforms that enable vectorization.

Richard.

[Bug fortran/118337] [15 Regression] Fortran *.mod compatibility

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

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

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

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

commit r15-6724-gc5e71d22d632889860ef079d4b0bff21eef8a660
Author: Jakub Jelinek 
Date:   Thu Jan 9 08:25:49 2025 +0100

fortran: Accept "15" modules for compatibility [PR118337]

Based on the comments in the PR, I've tried to write a patch which would
try to keep backwards compatibility with the GCC 11-14 *.mod files.
This means reordering the *.def files, so that the entries present already
in GCC 11-14 come before the ones new in GCC 15, and tweaking modules.cc
such that it can accept that ordering and while it has a newer MOD_VERSION,
it accepts even the previous one when loading modules.

2025-01-09  Jakub Jelinek  

PR fortran/118337
* module.cc (COMPAT_MOD_VERSIONS): Define.
(use_iso_fortran_env_module): Don't assume all NAMED_INTCSTs come
first followed by NAMED_UINTCSTs.
(gfc_use_module): Accept also COMPAT_MOD_VERSIONS for
compatibility.
* iso-c-binding.def: Reorder entries so that the GCC 14 ones come
before the ones new in GCC 15.
* iso-fortran-env.def: Likewise.

[Bug libgomp/118379] [PATCH] Avoid unused-variable-error when configured with 'CFLAGS=-DNDEBUG'

[one.last.kiss at outlook dot com via Gcc-bugs]

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

--- Comment #2 from shynur  ---
Thanks.  I sent it to gcc-patc...@gcc.gnu.org .

[Bug c++/118383] New: Constexpr default copy-assign operator of derived class with virtual base seems should not be allowed before C++23

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 118383
   Summary: Constexpr default copy-assign operator of derived
class with virtual base seems should not be allowed
before C++23
   Product: gcc
   Version: 15.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: ---

Consider the following code:



struct base { };
struct derived : virtual base {
constexpr derived& operator=(derived const&) = default;
};



https://godbolt.org/z/evns8zEqq

It appears that the default 'operator=' here inside a class with a virtual base
class is not permitted to be declared as constexpr function until
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2448r2.html#onwards-to-constexpr-classes,
 which targets for C++23. That means the code above should not be accepted
before that.


https://timsong-cpp.github.io/cppwp/n4861/dcl.fct.def.default#3.sentence-1
(C++20):

An explicitly-defaulted function that is not defined as deleted may be declared
constexpr or consteval only if it is constexpr-compatible ([special]).


See discussion on LLVM bug tracker:
https://github.com/llvm/llvm-project/issues/97266

[Bug target/118380] GCC is not optimizing computataion and code with avx intrinsics.

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #3 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #2)
>   _205 = __builtin_ia32_vbroadcastss256 (_200);
> 
> 
> There is not much the gimple level can do with that.

Rewrite with generic code doesn't help.

float tmp = *((float *) matrix1[j] + i);
 mmv[i] = __extension__(__m256){tmp, tmp, tmp, tmp, tmp, tmp, tmp,
tmp};

[Bug tree-optimization/117927] [15 Regression] Invalid rotate optimization

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

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

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

https://gcc.gnu.org/g:2cbd4409bcfaba2bd4200412090fd06db1948369

commit r15-6725-g2cbd4409bcfaba2bd4200412090fd06db1948369
Author: Jakub Jelinek 
Date:   Thu Jan 9 08:30:12 2025 +0100

match.pd: Avoid introducing UB in the a r<< (32-b) -> a r>> b optimization
[PR117927]

As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar
match.pd optimization which has been introduced in GCC 15 can introduce
UB which wasn't there before, in particular if b is equal at runtime
to bitsize, then a r<< 0 is turned into a r>> bitsize.

The following patch fixes it by optimizing it early only if VRP
tells us the count isn't equal to the bitsize, and late into
a r>> (b & (bitsize - 1)) if bitsize is power of two and the subtraction
has single use, on various targets the masking then goes away because
its rotate instructions do masking already.  The latter can't be
done too early though, because then the expr_not_equal_to case is
basically useless and we introduce the masking always and can't find out
anymore that there was originally no masking.  Even cfun->after_inlining
check would be too early, there is forwprop before vrp, so the patch
introduces a new PROP for the start of the last forwprop pass.

2025-01-09  Jakub Jelinek  
Andrew Pinski  

PR tree-optimization/117927
* tree-pass.h (PROP_last_full_fold): Define.
* passes.def: Add last= parameters to pass_forwprop.
* tree-ssa-forwprop.cc (pass_forwprop): Add last_p non-static
data member and initialize it in the ctor.
(pass_forwprop::set_pass_param): New method.
(pass_forwprop::execute): Set PROP_last_full_fold in
curr_properties
at the start if last_p.
* match.pd (a rrotate (32-b) -> a lrotate b): Only optimize either
if @2 is known not to be equal to prec or if during/after last
forwprop the subtraction has single use and prec is power of two;
in
that case transform it into orotate by masked count.

* gcc.dg/tree-ssa/pr117927.c: New test.

[Bug tree-optimization/117927] [15 Regression] Invalid rotate optimization

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/117930] Improve rotates by C - x or C + x where C is multiple of bitsize on x86

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

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

Bug 117927 Summary: [15 Regression] Invalid rotate optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117927

   What|Removed |Added

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

[Bug fortran/118337] [15 Regression] Fortran *.mod compatibility

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/118375] Fixits for feature test macros (FTMs)

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

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

--- Comment #1 from Sam James  ---
I find this comes up most with people using -std=c99/c11/whatever instead of
-std=gnu* and not realising the implications of that.

[Bug target/118363] [15 regression] RISC-V: excess errors in c-c++-common/gomp/dispatch-11.c with zvls > 128b

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

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

Sam James  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |15.0

--- Comment #1 from Sam James  ---
See
https://inbox.sourceware.org/gcc-regression/202501082000.508k0hgq3159...@shliclel4214.sh.intel.com/T/#u.

Probably fixed by r15-6721-g1bb367b5cdb9fa77733d87d97483fb57480ef6fe?

[Bug target/118380] GCC is not optimizing computataion and code with avx intrinsics.

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

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

--- Comment #2 from Andrew Pinski  ---
  _205 = __builtin_ia32_vbroadcastss256 (_200);


There is not much the gimple level can do with that.

[Bug c++/118382] New: GCC fails to detect erroneous implicit template argument specification in extern class declaration for template class with default argument

[wangbopku15 at gmail dot com via Gcc-bugs]

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

Bug ID: 118382
   Summary: GCC fails to detect erroneous implicit template
argument specification in extern class declaration for
template class with default argument
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangbopku15 at gmail dot com
  Target Milestone: ---

The following code seems to have some problems:

~~

template 
struct D{};

extern D d;

~~

In a template class declaration(not definition), the template arguments must be
explicitly specified, which means the '<>' specifier should not be eliminated
here. The correct version might be like:

~

template 
struct D{};

extern D<> d;

~

EDG, Clang, and ICC reject the first one and accept the second, but GCC seems
to accept both:

https://godbolt.org/z/55b1vrrP5

[Bug target/118380] GCC is not optimizing computataion and code with avx intrinsics.

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 60081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60081&action=edit
testcase: -O3 -march=znver4

Next time attach the testcase

[Bug target/118348] [15 Regression] [SVE] HACCKernels seems to miscompile with VLS SVE after 0c5c0c959c2e592b84739f19ca771fa69eb8dfee

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

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

Tamar Christina  changed:

   What|Removed |Added

   Last reconfirmed||2025-1-9

--- Comment #4 from Tamar Christina  ---
I'm not sure this one is caused by my commit.

It fails for me before g:0c5c0c959c2e592b84739f19ca771fa69eb8dfee already.

i.e. at g:913bab282d9 it still fails for me with -Ofast and
-msve-vector-bits=128.

I will non the less still fix it.

[Bug c++/118381] New: GCC ignores missing 'noexcept' specifier for friend declaration

[wangbopku15 at gmail dot com via Gcc-bugs]

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

Bug ID: 118381
   Summary: GCC ignores missing 'noexcept' specifier for friend
declaration
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangbopku15 at gmail dot com
  Target Milestone: ---

GCC does not generate errors on the following code:



struct S
{  
  void f()
noexcept{}
};


class C
{
  friend void S::f();
};


int main()
{
  C ci;
}



As a comparison, clang rejects it with:



:10:18: error: 'f' is missing exception specification 'noexcept'
   10 |   friend void S::f();
  |  ^  
  |  noexcept
:3:8: note: previous declaration is here
3 |   void f()
  |^
1 error generated.



EDG with:



"", line 10: error: allowing all exceptions is incompatible with
previous function "S::f" (declared at line 3)
friend void S::f();
  ^

"", line 16: warning: variable "ci" was declared but never referenced
C ci;
  ^

1 error detected in the compilation of "".



See https://godbolt.org/z/T9q7Pfa9q

[Bug c++/118383] [c++-14,17,20] Constexpr default copy-assign operator of derived class with virtual base seems should not be allowed before C++23

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. Looks like it was introduced in GCC 6 when constexpr operator=
> was added for C++14.

That is r6-7277-gb47d1d904d5397 .

[Bug c++/118383] [c++-14,17,20] Constexpr default copy-assign operator of derived class with virtual base seems should not be allowed before C++23

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> That is r6-7277-gb47d1d904d5397 .

https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443662.html

[Bug tree-optimization/105769] [12/13/14 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #25 from Andrew Pinski  ---
I highly doubt the patches series will be backported to GCC 14 though.

[Bug c/118384] New: unexpected call to __muldi3 generated for riscv target

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

Bug ID: 118384
   Summary: unexpected call to __muldi3 generated for riscv target
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fanghuaqi at vip dot qq.com
  Target Milestone: ---

Hi there,

I am trying to compile source code using riscv gcc 14.2 like below:

cat test.c

#include "stdint.h"
uint64_t muldi3(uint64_t a, uint64_t b)
{

uint64_t Product;

Product = 0;
while (a) {
if (a & 1) {
Product += b;
}
a >>= 1;
b <<= 1;
}

return Product;
}

riscv64-unknown-elf-gcc  -march=rv32ec -mabi=ilp32e   -Os  test.c -c -o test.o

riscv64-unknown-elf-readelf -s test.o

Symbol table '.symtab' contains 13 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1:  0 FILELOCAL  DEFAULT  ABS test.c
 2:  0 SECTION LOCAL  DEFAULT1 .text
 3:  0 SECTION LOCAL  DEFAULT3 .data
 4:  0 SECTION LOCAL  DEFAULT4 .bss
 5:  0 NOTYPE  LOCAL  DEFAULT1 $xrv32e2p0_c2p0_[...]
 6:  0 SECTION LOCAL  DEFAULT6 .note.GNU-stack
 7: 0026 0 NOTYPE  LOCAL  DEFAULT1 .L3
 8: 0012 0 NOTYPE  LOCAL  DEFAULT1 .L2
 9:  0 SECTION LOCAL  DEFAULT5 .comment
10:  0 SECTION LOCAL  DEFAULT7 .riscv.attributes
11:    106 FUNCGLOBAL DEFAULT1 muldi3
12:  0 NOTYPE  GLOBAL DEFAULT  UND __muldi3


You can see the generated object file required a external UND __muldi3 , but
actually I am implementing it now.

And if I switch it to gcc 13.2, this issue will dispear, there will no 12:
 0 NOTYPE  GLOBAL DEFAULT  UND __muldi3 line.

Thanks

[Bug c++/118383] [c++-14,17,20] Constexpr default copy-assign operator of derived class with virtual base seems should not be allowed before C++23

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-09
  Known to fail||6.1.0
Summary|Constexpr default   |[c++-14,17,20] Constexpr
   |copy-assign operator of |default copy-assign
   |derived class with virtual  |operator of derived class
   |base seems should not be|with virtual base seems
   |allowed before C++23|should not be allowed
   ||before C++23

--- Comment #1 from Andrew Pinski  ---
Confirmed. Looks like it was introduced in GCC 6 when constexpr operator= was
added for C++14.

[Bug tree-optimization/118353] Implement greedy algorithm for switch jump table cluster finding

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

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

--- Comment #4 from Filip Kastl  ---
Huh.  Then either

a) We spend a lot of time in the jump table finding algorithm.  That would mean
that there are large switch statements in GCC code specific for those
architectures.  Btw, those switch statements would have to have the property
that there are few bit test lowering opportunities (otherwise bit tests would
basically split the switch into smaller chunks that jump table finding wouldn't
have problem with).  Or maybe bit test lowering is disabled entirely on those
architectures?
b) Jump table finding is too eager.  Lowering parts of a switch statement as
jump tables can lead to slower code on these architectures and in GCC this
happens frequently enough to slow the compiler down significantly.

Those are the two explanations that come to my mind.

[Bug c++/118385] New: A temporary expression bound to a reference member in a mem-initializer is ill-formed

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 118385
   Summary: A temporary expression bound to a reference member in
a mem-initializer is ill-formed
   Product: gcc
   Version: 15.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: ---

https://eel.is/c++draft/class.base.init#8:

~~~

A temporary expression bound to a reference member in a mem-initializer is
ill-formed.
[Example 5: 

struct A {
  A() : v(42) { }   // error
  const int& v;
};

— end example]

~~~

The example above does not trigger the corresponding error in gcc:

https://godbolt.org/z/ao1jMxz69

[Bug c/118384] unexpected call to __muldi3 generated for riscv target

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #1 from Huaqi  ---
This issue also present in arm-eabi-gcc toolchain 14.x, but not present in
13.x.

compiler option chosen is -Os -mcpu=cortex-m0

chose m0 due it don't have a multiply hw unit

see https://godbolt.org/z/941TbMKGc

14.x will generate bl  __aeabi_lmul, but 13.x will not.

[Bug c++/99093] [missed optimization] Missed devirtualization involving internal-linkage class type (but only sometimes)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-09
 Ever confirmed|0   |1

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

[Bug libgomp/118379] New: [PATCH] Avoid unused-variable-error when configured with 'CFLAGS=-DNDEBUG'

[one.last.kiss at outlook dot com via Gcc-bugs]

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

Bug ID: 118379
   Summary: [PATCH] Avoid unused-variable-error when configured
with 'CFLAGS=-DNDEBUG'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: one.last.kiss at outlook dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

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

When configured with CFLAGS=-DNDEBUG, the process of make always failed.
The attached patch fixed it.

Just a small change.

[Bug libgomp/118379] [PATCH] Avoid unused-variable-error when configured with 'CFLAGS=-DNDEBUG'

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

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

--- Comment #1 from Andrew Pinski  ---
Patches should send to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug tree-optimization/118380] New: GCC is not optimizing computataion and code with avx intrinsics.

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

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

Bug ID: 118380
   Summary: GCC is not optimizing computataion and code with avx
intrinsics.
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vekumar at gcc dot gnu.org
  Target Milestone: ---

For the test case in the given link 
https://godbolt.org/z/MP88MaTva

LLVM is able to optimize the loop and computations hapenning completely.
GCC is not able to do so. 

Arrays are defined locally and may not be the case with real world application. 
Nevertheless GCC can also optimize this case.

[Bug target/91722] gcc generates sub-optimal assembly when AVX instructions are used.

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

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

--- Comment #3 from Andrew Pinski  ---
  _9 = __builtin_ia32_vbroadcastss256 (&signbit);
  _4 = __builtin_ia32_andnps256 (_9, to_3(D));
  _6 = __builtin_ia32_andps256 (_9, from_5(D));
  _7 = __builtin_ia32_orps256 (_6, _4); [tail call]

[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Thanks for clarification.  I'm way to unfamiliar with the vectorizer.  At some
point, when I was skimming over the code, I got the impression that also other
modes than those defined by the backend may appear in intermediate expressions.

Anyhow, bootstrap and regtest are running.

[Bug target/118377] ICE when using C division operator with svint8 and svint16

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-01-09
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
Confirmed. I am not sure we can call this a regression since we were rejecting
this before. And now should be accepting it.

[Bug c/118376] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1152 with -Wsign-conversion

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

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

--- Comment #1 from Andrew Pinski  ---
I can't reproduce this ...

[Bug c++/118374] New: Missing fixit for underlying enum type

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

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

Bug ID: 118374
   Summary: Missing fixit for underlying enum type
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
Blocks: 118371
  Target Milestone: ---

This is from https://bugs.gentoo.org/938230.

```
enum Flags : uint8_t {};
```

We emit:
```
:1:12: error: found ':' in nested-name-specifier, expected '::'
1 | enum Flags : uint8_t {};
  |^
  |::
:1:6: error: 'Flags' has not been declared
1 | enum Flags : uint8_t {};
  |  ^
:1:22: error: expected unqualified-id before '{' token
1 | enum Flags : uint8_t {};
  |  ^
Compiler returned: 1
```

.. which is confusing for folks if uint8_t used to come in via a header.
Upstreams don't usually struggle with this but sometimes packagers do who
haven't seen it before.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118371
[Bug 118371] [meta-bug] tracker bug for UX issues affecting porting to GCC 15

[Bug c++/118374] Missing fixit for underlying enum type

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=938115

--- Comment #1 from Sam James  ---
I should say: while the error could be better of course.. in reality, the files
usually have a use of uint8_t or similar lower down which *does* trigger the
fixit, so it's not too important. But that doesn't help if people get
overwhelmed by the output.

[Bug target/118356] RISC-V: -falign-labels=0 should (probably) default to 4

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Jeffrey A. Law  ---
Right.  The bits in place are the way they are so that each uarch known to GCC
can select the code aligments they want/need.

I don't have enough information to set suitable values for any uarch other than
the Ventana designs.  The plan was to upstream the rest of the V1 bits which
would have been the first user of this capability, but once the V1 design was
shelved it didn't make sense to upstream any of the cost/scheduling bits for
it.

Someone with a deep understanding of a particular uarch needs to submit a patch
setting suitable values for that uarch.

That will almost certainly include certain tradeoffs based on where the uarch
is most likely going to be used.  For example, deeply embedded where codesize
is particularly important likely won't want any code alignments.  While other
uarchs (say targetting a server market) are going to be more likely to want
code alignments to improve performance, even if it means slightly larger
codesize.

Right now I don't see anything actionable here.

[Bug c/118376] New: ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1152 with -Wsign-conversion

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 118376
   Summary: ICE: in linemap_ordinary_map_lookup, at
libcpp/line-map.cc:1152 with -Wsign-conversion
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Wsign-conversion testcase.c 
testcase.c: In function 'foo':

testcase.c:6:25: warning: conversion to 'int' from 'long long int' may change
the sign of the result [-Wsign-conversion]
testcase.c:6:3: internal compiler error: in linemap_ordinary_map_lookup, at
libcpp/line-map.cc:1152
6 |   __builtin_memset (&x, (long long) __builtin_stdc_rotate_right (x, 0),
1);
  |   ^~~~
0x2ddb561 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xef802b fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1722
0x2e67d37 linemap_ordinary_map_lookup
/repo/gcc-trunk/libcpp/line-map.cc:1152
0x2e6a51b linemap_unwind_to_first_non_reserved_loc(line_maps const*, unsigned
long, line_map const**)
/repo/gcc-trunk/libcpp/line-map.cc:1844
0x2e12a6c expand_location_1
/repo/gcc-trunk/gcc/input.cc:254
0x2e1583d linemap_client_expand_location_to_spelling_point(line_maps const*,
unsigned long, location_aspect)
/repo/gcc-trunk/gcc/input.cc:1208
0x2de8c17 maybe_add_location_range
/repo/gcc-trunk/gcc/diagnostic-show-locus.cc:1424
0x2de939b layout
/repo/gcc-trunk/gcc/diagnostic-show-locus.cc:1373
0x2df002f diagnostic_source_print_policy::print(pretty_printer&, rich_location
const&, diagnostic_t, diagnostic_source_effect_info*) const
/repo/gcc-trunk/gcc/diagnostic-show-locus.cc:3331
0x2df01a6 diagnostic_context::maybe_show_locus(rich_location const&,
diagnostic_source_printing_options const&, diagnostic_t, pretty_printer&,
diagnostic_source_effect_info*)
/repo/gcc-trunk/gcc/diagnostic-show-locus.cc:3293
0x102e27a diagnostic_show_locus(diagnostic_context*,
diagnostic_source_printing_options const&, rich_location*, diagnostic_t,
pretty_printer*, diagnostic_source_effect_info*)
/repo/gcc-trunk/gcc/diagnostic.h:1110
0x102e27a c_diagnostic_text_finalizer
/repo/gcc-trunk/gcc/c-family/c-opts.cc:180
0x2dd9259 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic-format-text.cc:246
0x2dc6032 diagnostic_context::report_diagnostic(diagnostic_info*)
/repo/gcc-trunk/gcc/diagnostic.cc:1483
0x2dc636d diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic.cc:1614
0x2dda263 warning_at(unsigned long, diagnostic_option_id, char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:185
0x10584a8 conversion_warning
/repo/gcc-trunk/gcc/c-family/c-warn.cc:1380
0xfc67d8 convert_and_check(unsigned long, tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/c-family/c-common.cc:1839
0xf3e331 convert_for_assignment
/repo/gcc-trunk/gcc/c/c-typeck.cc:7912
0xf417d9 convert_argument
/repo/gcc-trunk/gcc/c/c-typeck.cc:4124
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20250109094235-r15-6723-gb37628e4ae7e5e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20250109094235-r15-6723-gb37628e4ae7e5e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20250109 (experimental) (GCC)

[Bug c/118376] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1152 with -Wsign-conversion

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

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

--- Comment #2 from Sam James  ---
I can on one machine and not another.

The one I can is `gcc version 15.0.0 20250108 (experimental)
21ee71afa72746367cab7847f950448f04607dd2 (Gentoo 15.0. p, commit
f6d3d0becd191f48aca221595377e39e53708adf)`

The one I can't is `gcc version 15.0.0 20250108 (experimental)
c42261d89538c416464c2191e4c72ec002a43cd0 (Gentoo Hardened 15.0. p, commit
f6d3d0becd191f48aca221595377e39e53708adf)`.

[Bug target/118378] New: mod with svint32_t ICEs

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

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

Bug ID: 118378
   Summary: mod with svint32_t ICEs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: belagod at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include 

svint32_t
foo (svint32_t x, svint32_t y)
{
  return x % y;
}
```

We currently ICEs but we could do as:
```
svint32_t
foo (svint32_t x, svint32_t y)
{
  svint32_t z = (x / y) ;
  return x - z*y;
}
```

[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||85316
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2025-01-09
 Status|UNCONFIRMED |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases