[Bug d/119139] Regression with struct invariants

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

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

Iain Buclaw  changed:

   What|Removed |Added

URL||https://github.com/dlang/dm
   ||d/issues/20967

--- Comment #8 from Iain Buclaw  ---
Raised issue upstream, for now can just disable the setting of TREE_READONLY
for result declarations.

[Bug target/119172] New: [12/13/14 regression] macOS SDK version is not set by gcc

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

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

Bug ID: 119172
   Summary: [12/13/14 regression] macOS SDK version is not set by
gcc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

% cat b.c
int main (void) { return 0; }
% clang b.c
% otool -l a.out | grep sdk   
  sdk 15.2
% codesign -dvvv a.out 2>&1 | grep warning
% gcc-14 b.c  
% otool -l a.out | grep sdk   
  sdk n/a
% codesign -dvvv a.out 2>&1 | grep warning
Library validation warning=OS X SDK version before 10.9 does not support
Library Validation

When SDK is unset, the binaries cannot be later notarized:
https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Use-the-macOS-109-SDK-or-later

This was reported to projects like conda-forge
(https://github.com/conda/conda/issues/14025) and homebrew
(https://github.com/Homebrew/homebrew-core/issues/209981).

This behaviour was introduced in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624

[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Host||*-apple-darwin*
 Target||*-apple-darwin*
 Ever confirmed|0   |1
  Build||*-apple-darwin*
 Status|UNCONFIRMED |NEW
 CC||iains at gcc dot gnu.org
   Last reconfirmed||2025-03-09

[Bug c++/119154] GCC 15.0 std module with compiled with -O3 breaks when loaded with -O0 (not -O1, -O2 and -Ofast)

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #9 from Nathaniel Shead  ---
Confirmed.  Further reduced:

  // a.cpp
  export module foo;
  extern "C++" inline __attribute__((__gnu_inline__)) void bar() {}

  // b.cpp
  void bar();
  import foo;

g++ -fmodules -fno-module-lazy -S a.cpp b.cpp

b.cpp:2:12: internal compiler error: in import_export_decl, at cp/decl2.cc:3561
2 | import foo;
  |^
0x3cab7bf internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x3c76b30 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1722
0x105652e import_export_decl(tree_node*)
../../gcc/gcc/cp/decl2.cc:3561
0x105edfd c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5692
0x145346b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1397
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.

Worth noting that mixing flags between consumers and producers of modules is
likely to cause havoc in general... this isn't well tested at all yet.

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #5 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #1)
> Suspended until this is approved by the C committee for the names.

On the other hand, my experience with the C Committee is that they aren't the
best place to decide a name.  They completely messed it with _Countof, which
during some period was called _Lengthof.  I personally think that if the name
is your only concern, we should rather decide it ourselves and force them to
just take it.  Of course, we should decide something that they can take, and
not do something dumb, but I think leaving them the decision of a name is a bad
idea.




If you have doubts about the feature itself, I agree on consulting other
implementors, but if you only doubt the name, I'd say go ahead with this here. 
Any opinions?

[Bug tree-optimization/118922] [12/13/14/15 regression] Miscompile at -O2/3

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

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

--- Comment #23 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:7232c005afb5002cdfd0a2dbd0e8b8f2d80250ce

commit r15-7913-g7232c005afb5002cdfd0a2dbd0e8b8f2d80250ce
Author: Andrew Pinski 
Date:   Sat Mar 8 22:43:54 2025 -0800

phiopt: Fix value_replacement for middle bb having phi nodes [PR118922]

After r12-5300-gf98f373dd822b3, value_replacement would be able to look at
the
following cfg structure:
```
   [local count: 1014686024]:
  if (h_6 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 114863530]:
  # h_6 = PHI <0(4), 1(5)>

   [local count: 1073741824]:
  # f_8 = PHI <0(5), h_6(6)>
  _9 = f_8 ^ 1;
  a.0_10 = a;
  _11 = _9 + a.0_10;
  if (_11 != -117)
goto ; [94.50%]
  else
goto ; [5.50%]
```

value_replacement would incorrectly think the middle bb (6) was empty and
so it decides
to remove condition in bb5 and replacing it with 0 as the function thought
it was `h_6 ? 0 : h_6`.
But since the there is an incoming phi node to bb6 defining h_6 that is
incorrect.

The fix is to check if there is phi nodes in the middle bb and set
empty_or_with_defined_p to false.
This was not needed before r12-5300-gf98f373dd822b3 because the phi would
have been dead otherwise due to
other checks.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/118922

gcc/ChangeLog:

* tree-ssa-phiopt.cc (value_replacement): Set
empty_or_with_defined_p
to false when there is phi nodes for the middle bb.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr118922-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle  ---
(In reply to Matthew Krupcale from comment #6)
> (In reply to Paul Thomas from comment #5)
> 
--- snip ---
> 
> It looks like Andre Vehreschild suggested [4] on the fortran mailing list to:
> 
> 1. Add the testcase if it adds a new way.
> 2. Apply the backport if it applies simply and not to do so if it caused
> major issues.
> 
> There were no other responses back then in February, but I suppose you
> disagree with his stance? Or did you observe major issues with the backport?
> In any case, I can certainly try appealing to the mailing list again.
> 

Several of us have had some other burnng issues to deal with. I will take a
look at it this afternoon and if I can, I will backport it.

[Bug fortran/119054] [12/13/14/15 Regression] ICE on passing optional array to elemental procedure with -pedantic

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jerry DeLisle
:

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

commit r14-11395-ge4f886c463fffd0bd2b1c98fa668c20aab5b37d2
Author: Jerry DeLisle 
Date:   Fri Mar 7 18:33:29 2025 -0800

Fortran: Fix ICE in resolve.cc with -pedantic

Fixes an ICE in gfc_resolve_code when passing an
optional array to an elemental procedure with `-pedantic` enabled.
PR95446 added the original check, this patch fixes the case where the
other actual argument is an array literal (or something else other
than a variable).

PR fortran/119054

gcc/fortran/ChangeLog:

* resolve.cc (resolve_elemental_actual): When checking other
actual arguments to elemental procedures, don't check
attributes of literals and function calls.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr95446.f90: Expand test case to literals and
function calls.

Signed-off-by: Peter Hill 

(cherry picked from commit 3014f8787196d7c0d15d24195c8f07167968ff55)

[Bug c/119176] New: ICE: Segmentation fault at c_push_function_context()

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 119176
   Summary: ICE: Segmentation fault at c_push_function_context()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

Compiler Explorer: https://godbolt.org/z/KKq4jeTaK

Console:
:29:3: error: expected expression before '#pragma'
   29 |   _Pragma("GCC novector") for (int i = 0; i < DIST * 2; ++i) { 
   \
  |   ^~~
:14:3: note: in expansion of macro 'DO_TEST'
   14 |   M(sc) M(uc) M(ss) M(us) M(si) M(ui) M(sll) M(ull) M(float) M(double)
  |   ^
:47:15: note: in expansion of macro 'FOR_EACH_TYPE'
   47 | int const_1 = FOR_EACH_TYPE(DO_TEST);
  |   ^
:29:45: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'<' token
   29 |   _Pragma("GCC novector") for (int i = 0; i < DIST * 2; ++i) { 
   \
  | ^
:14:3: note: in expansion of macro 'DO_TEST'
   14 |   M(sc) M(uc) M(ss) M(us) M(si) M(ui) M(sll) M(ull) M(float) M(double)
  |   ^
:47:15: note: in expansion of macro 'FOR_EACH_TYPE'
   47 | int const_1 = FOR_EACH_TYPE(DO_TEST);
  |   ^
:29:57: error: expected identifier or '(' before '++' token
   29 |   _Pragma("GCC novector") for (int i = 0; i < DIST * 2; ++i) { 
   \
  | ^~
:14:3: note: in expansion of macro 'DO_TEST'
   14 |   M(sc) M(uc) M(ss) M(us) M(si) M(ui) M(sll) M(ull) M(float) M(double)
  |   ^
:47:15: note: in expansion of macro 'FOR_EACH_TYPE'
   47 | int const_1 = FOR_EACH_TYPE(DO_TEST);
  |   ^
:29:3: internal compiler error: Segmentation fault
   29 |   _Pragma("GCC novector") for (int i = 0; i < DIST * 2; ++i) { 
   \
  |   ^~~
:14:9: note: in expansion of macro 'DO_TEST'
   14 |   M(sc) M(uc) M(ss) M(us) M(si) M(ui) M(sll) M(ull) M(float) M(double)
  | ^
:47:15: note: in expansion of macro 'FOR_EACH_TYPE'
   47 | int const_1 = FOR_EACH_TYPE(DO_TEST);
  |   ^
0x25f8ee5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x260feb6 internal_error(char const*, ...)
???:0
0xa21351 c_push_function_context()
???:0
0xab28de c_parse_file()
???:0
0xb31559 c_common_parse_file()
???:0
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 returned: 1

[Bug c/119177] New: ICE: verify_cgraph_node failed

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 119177
   Summary: ICE: verify_cgraph_node failed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

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

Compiler Explorer: https://godbolt.org/z/zb8e3TTsh

Console:
:36:1: error: Alias and target's section differs
   36 | ;
  | ^
xt_init/6 (xt_init)
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: semantic_interposition artificial ifunc_resolver
  References: xt_init.resolver/7 (alias) 
  Referring: init_module/3 (alias) 
  Availability: overwritable
  Version info: next: xt_init.default/2 dispatcher: xt_init.resolver
  Function flags:
  Called by: 
  Calls: 
init_module/3 (init_module)
  Type: function definition analyzed alias
  Visibility: externally_visible semantic_interposition public
section:.init.text
  References: xt_init/6 (alias) 
  Referring: 
  Availability: available
  Function flags:
  Called by: 
  Calls: 
:36:1: internal compiler error: verify_cgraph_node failed
0x25f8ee5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x260feb6 internal_error(char const*, ...)
???:0
0xc03328 cgraph_node::verify_node()
???:0
0xbf1b74 symtab_node::verify()
???:0
0xbf2d57 symtab_node::verify_symtab_nodes()
???:0
0xeec9f6 symbol_table::remove_unreachable_nodes(_IO_FILE*)
???:0
0xc0bcdb symbol_table::finalize_compilation_unit()
???:0
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 returned: 1

[Bug c/119177] target_clones with section vs alias attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-09
   Keywords||ice-checking
 Ever confirmed|0   |1
Summary|ICE: verify_cgraph_node |target_clones with section
   |failed  |vs alias attribute
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. reduced testcase:
```
static int 
__attribute__((target_clones("default,avx"))) 
__attribute__((__section__(".init.text"))) 
xt_init(void) {}

int init_module(void)
__attribute__((__copy__(xt_init)))
__attribute__((alias("xt_init")));
```

[Bug c/119176] invalid use of `#pragma GCC novector` outside of a function causes an ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-03-09
   Keywords|error-recovery  |
Summary|ICE: Segmentation fault at  |invalid use of `#pragma GCC
   |c_push_function_context()   |novector` outside of a
   ||function causes an ICE
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
#pragma GCC novector
for (;;)
{
  int *a++;
}

``

[Bug other/119178] New: Optimization: (x != C) comparison can utilize (x - C) or (x ^ C) result

[Explorer09 at gmail dot com via Gcc-bugs]

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

Bug ID: 119178
   Summary: Optimization: (x != C) comparison can utilize (x - C)
or (x ^ C) result
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Explorer09 at gmail dot com
  Target Milestone: ---

This is an optimization opportunity that can benefit RISC-V, MIPS and other
processors that don't use condition codes for their compare-and-branch
instructions.

```c

#include 
unsigned int func1_a(unsigned int x) {
if (x != 0x555)
return (x ^ 0x555);
abort();
}

unsigned int func1_c(unsigned int x) {
unsigned int tmp = x ^ 0x555;
__asm__ ("" : "+r" (tmp));
if (tmp == 0)
abort();
return tmp;
}

unsigned int func2_a(unsigned int x) {
if (x != 0x555)
return (x - 0x555);
abort();
}

unsigned int func2_c(unsigned int x) {
unsigned int tmp = x - 0x555;
__asm__ ("" : "+r" (tmp));
if (tmp == 0)
abort();
return tmp;
}

```

The example code above can be tested in Compiler Explorer (godbolt.org).

func1_c() and func2_c() are the results I expected for func1_a() and func2_a()
to optimize to when using the `-Os` option.

* The second operand for `==` or `!=` comparison is a compile-time constant.
* The constant is small enough to fit the immediate operands of the "sub" and
"xor" instructions.
* The compare-and-branch instructions of RISC-V have only register operands
(cannot compare with immediate), and for these particular examples it's better
to calculate `(x - 0x555)` or `(x ^ 0x555)` first and compare that result with
zero.

[Bug rtl-optimization/119174] New: [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Bug ID: 119174
   Summary: [15 Regression] IRA allocating value live across a
call to call clobbered register
   Product: gcc
   Version: 15.0
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: ---

Since this change:

commit b191e8bdecf881d11c1544c441e38f4c18392a15 (HEAD)
Author: Richard Sandiford 
Date:   Thu Mar 6 11:06:25 2025 +

ira: Add new hooks for callee-save vs spills [PR117477]

Following on from the discussion in:

  https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675256.html

this patch removes TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE and
replaces it with two hooks: one that controls the cost of using an
extra callee-saved register and one that controls the cost of allocating
a frame for the first spill.

(The patch does not attempt to address the shrink-wrapping part of
the thread above.)
[ ... ]

IRA has started allocating a pseudo that is live across calls to a call
clobbered regsiter on msp430-elf.   Clearly not good.  Marking as a P1 until we
know if it's something generic or specific to msp430-elf.

This testcase with -Os:

__attribute__((__noipa__))
void f3(int x, int (*p3 []) (int))
{
  int i;
  int next = x;
  for (i = 0; i < x; i++)
next = p3[i](next);
}

Generates this loop + epilogue:

.L2:
CMP.W   @R1, R10 { JL   .L3  ; 22   [c=8 l=4]  cbranchhi4_real/0
; start of epilogue  ; 42   [c=0 l=0]  epilogue_start_marker
ADD.W   #2, R1   ; 43   [c=8 l=4]  addhi3/0
POPM.W  #1, r10  ; 44   [c=4 l=2]  popm
RET  ; 45   [c=4 l=2]  msp430_return
.L3:
MOV.W   @R13+, R14   ; 35   [c=4 l=2]  movhi/1
CALLR14  ; 16   [c=4 l=2]  call_value_internal
ADD.W   #1, R10  ; 18   [c=8 l=4]  addhi3/0
BR  #.L2 ; 48   [c=8 l=4]  jump


Note carefully how the value of R13 is live across the call at insn 16.  Then
verify R13 is in call_used_regs on the msp430-elf port.

Looking at the .ira dump we find insn 16:

(call_insn 16 15 30 3 (set (reg:HI 12 R12)
(call:HI (mem:HI (mem/f:HI (post_inc:HI (reg:HI 26 [ ivtmp.10 ])) [1
MEM[(int (*) (int) *)_18]+0 S2 A16]) [0 *_4 S2 A16])
(const_int 0 [0]))) "j.c":8:12 89 {call_value_internal}
 (expr_list:REG_INC (reg:HI 26 [ ivtmp.10 ])
(expr_list:REG_CALL_DECL (nil)
(nil)))
(expr_list:HI (use (reg:HI 12 R12))
(nil)))


So the pseudo is (reg:HI 26), and looking back to the actual allocation:


  Popping a3(r26,l0)  -- assign reg 13


So at this point we've lost.

I've also bisected an mcore-elf regression to the same change, but have not
debugged it as the testcase is more complex and GDB port for mcore faults, so
debugging is nontrivial.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Target||msp430-elf
 CC||hjl at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Priority|P3  |P1

[Bug fortran/103391] [12/13/14 Regression] ICE: gimplification failed since r7-4021-g574284e9c49687d8

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Paul Thomas :

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

commit r14-11394-gc6b2a359d348e2255cbf5b548540ecd8a5fa5a59
Author: Andre Vehreschild 
Date:   Tue Mar 4 12:56:20 2025 +0100

Fortran: Fix gimplification error on assignment to pointer [PR103391]

PR fortran/103391

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_trans_assignment_1): Do not use poly assign
for pointer arrays on lhs (as it is done for allocatables
already).

gcc/testsuite/ChangeLog:

* gfortran.dg/assign_12.f90: New test.

(cherry picked from commit 04909c7ecc023874c3444b85f88c60b7b7cc7778)

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug c++/119175] New: ICE segfault on lambda in requires clause of generic lambda in requires clause

[eczbek.void at gmail dot com via Gcc-bugs]

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

Bug ID: 119175
   Summary: ICE segfault on lambda in requires clause of generic
lambda in requires clause
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/5ar46j7hs

```
template
void from() requires requires {
[] requires requires {
[] {};
} {};
} {}

int main() {
from();
}
```


```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20250309/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-e270b8997854d56e8e8536fd1126de7541e3d826-binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250309 (experimental)
(Compiler-Explorer-Build-gcc-e270b8997854d56e8e8536fd1126de7541e3d826-binutils-2.42)
 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-fno-verbose-asm' '-S' '-std=c++20' '-v' '-freport-bug'
'-isystem' '/opt/compiler-explorer/libs/xieite/main/include' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-trunk-20250309/bin/../libexec/gcc/x86_64-linux-gnu/15.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/
-D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/xieite/main/include 
-quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -masm=intel
-mtune=generic -march=x86-64 -g -std=c++20 -version -fdiagnostics-color=always
-fno-verbose-asm -freport-bug -o /app/output.s
GNU C++20
(Compiler-Explorer-Build-gcc-e270b8997854d56e8e8536fd1126de7541e3d826-binutils-2.42)
version 15.0.1 20250309 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/include-fixed/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/compiler-explorer/libs/xieite/main/include

/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1

/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/../../../../include/c++/15.0.1/backward

/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/15.0.1/include

/opt/compiler-explorer/gcc-trunk-20250309/bin/../lib/gcc/x86_64-linux-gnu/1

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

[ulinl--- via Gcc-bugs]

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

Uwe Lohmann  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|WAITING |RESOLVED

--- Comment #8 from Uwe Lohmann  ---
 * I deleted the complete avr toolchain and rebuilt everything. avr-gcc was
built in accordance to https://gcc.gnu.org/install/configure.html.
Result: no change, still the reported error

* I originally used avr-libc-2.1.0. After the change described in
https://github.com/avrdudes/avr-libc/commit/5e6f28bd436e6f9749ecc5bc47f9035f1c1e7423,
the error disappeared.
Updated avr-lib to avr-libc-2.2.1; removed the prototypes as described in the
link above.
Result: Now OK.

Thanks for the support. Issue closed.

[Bug c++/119097] Modules treats non-ODR usages of constexpr values as exposure

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

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

Nathaniel Shead  changed:

   What|Removed |Added

Summary|Modules references internal |Modules treats non-ODR
   |linkage entity error|usages of constexpr values
   ||as exposure
 CC||nshead at gcc dot gnu.org

--- Comment #1 from Nathaniel Shead  ---
This is related to
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1815r2.html.

Specifically, only exposures of TU-local entities should error; the bodies of
inline functions will error, the bodies of non-inline should not.  Functions
defined in a class body are implicitly 'inline' (hence the errors when declared
in the header file) unless attached to a named module (hence the errors not
occurring when declared in the module).

That said, for this specific instance none of these cases should error; by
https://eel.is/c++draft/basic.link#14.4 we have:

"A declaration is an exposure if it either names a TU-local entity (defined
below), ignoring ... any reference to a non-volatile const object or reference
with internal or no linkage initialized with a constant expression that is not
an odr-use ([basic.def.odr])."

None of these usages are ODR-uses, so this should be OK.

[Bug target/119133] [14 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.cc:3896) with -O -fno-tree-ter and _Float16 since r14-1131

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Dimitar Dimitrov :

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

commit r15-7912-g1b21da6abf22f164adb5d03cc91ef09472d035db
Author: Dimitar Dimitrov 
Date:   Sun Mar 9 15:57:25 2025 +0200

testsuite: Require effective target float16 for test [PR119133]

The test spuriously failed on pru-unknown-elf due to missing support for
_Float16 type.

PR target/119133

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr119133.c: Require effective target float16.

Signed-off-by: Dimitar Dimitrov 

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It seems interesting to have a mem inside a mem for the call instruction.
> Also maybe the post_inc is what it is getting confused here .

Maybe that is correct here. the constraints support a mem there.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

[mkrupcale at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Matthew Krupcale  ---
(In reply to Paul Thomas from comment #5)

> Neither PR is a regression and defined assignment is so fundamentally
> incorrect, where defined assignment of components is concerned, that
> sticking plaster patches do not warrant a backport.

I understand that PR115265 and PR109066 may not be a regression (unless the
regression happened prior to version 5.5), but the segfault  certainly is
undesired behavior in what seems to be valid Fortran that is accepted and runs
without segfault by other compilers, and the patches [1,2] which fix it seem
quite simple to backport, even if component defined assignment is so poorly
implemented that it will require reworking in v16 [3].

> You could try appealing
> to the gfortran mailing list. If it is OK'd there, I would be happy to
> backport to 14-branch.

It looks like Andre Vehreschild suggested [4] on the fortran mailing list to:

1. Add the testcase if it adds a new way.
2. Apply the backport if it applies simply and not to do so if it caused major
issues.

There were no other responses back then in February, but I suppose you disagree
with his stance? Or did you observe major issues with the backport? In any
case, I can certainly try appealing to the mailing list again.

Best,
Matthew

[1]
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/resolve.cc;h=e8f780d1ef96413c0cd197ab36ddb1fd0fea866c;hp=b8c908b51e92c848b0ca4280d66d276c078d5a83;hb=27ff8049bbdb0a001ba46835cd6a334c4ac76573;hpb=4a4bd60fa08b9e1079ebead6cb8c3ce82c7f9ef6
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/resolve.cc;h=7f73d53e31ef11b8822974bf83e6c9fbd39fcb9f;hp=124f4ac4edcdca5406fd6b0e0e24cde95c4e5485;hb=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d;hpb=92a5c5100c25190622ca86b63586a598952546bf
[3] https://gcc.gnu.org/pipermail/fortran/2025-February/061688.html
[4] https://gcc.gnu.org/pipermail/fortran/2025-February/061689.htm

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #1 from Andrew Pinski  ---
It seems interesting to have a mem inside a mem for the call instruction.
Also maybe the post_inc is what it is getting confused here .

[Bug d/119139] [12/13/14/15 regression] Regression with struct invariants

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

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

Sam James  changed:

   What|Removed |Added

Summary|Regression with struct  |[12/13/14/15 regression]
   |invariants  |Regression with struct
   ||invariants
   Target Milestone|--- |12.5

[Bug d/119139] [12/13/14/15 regression] Regression with struct invariants

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2025-03-06 00:00:00 |2025-03-09

[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Target Milestone|--- |12.5

[Bug c++/119154] GCC 15.0 std module with compiled with -O3 breaks when loaded with -O0 (not -O1, -O2 and -Ofast)

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

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

--- Comment #10 from Nathaniel Shead  ---
Created attachment 60689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60689&action=edit
pr119154.patch

A minimal fix would be to avoid doing 'note_vague_linkage_fn' for 'gnu_inline'
functions in the postprocessing loop within module_state::read_cluster.  But
I'm not a fan of the way that DECL_INTERFACE_KNOWN is handled here; maybe
something like the attached patch would clean up some other possible issues?

We probably need to also copy across some duplicate_decls things to handle the
gnu_inline case better as well.

[Bug c/119173] New: Documentation for -Wzero-as-null-pointer-constant should move to Warning Options

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

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

Bug ID: 119173
   Summary: Documentation for -Wzero-as-null-pointer-constant
should move to Warning Options
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at gcc dot gnu.org
  Target Milestone: ---

it is still in C++ Dialect Options

[Bug rtl-optimization/117467] [15/16 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-7915-g4ed07a11ee2845c2085a3cd5cff043209a452441
Author: Jeff Law 
Date:   Sun Mar 9 13:28:10 2025 -0600

[rtl-optimization/117467] Avoid unnecessarily marking things live in
ext-dce

This is the first of what I expect to be a few patches to improve memory
consumption and performance of ext-dce.

While I haven't been able to reproduce the insane memory usage that Richi
saw,
I can certainly see how we might get there.  I instrumented ext-dce to dump
the
size of liveness sets, removed the memory allocation limiter, then compiled
the
appropriate file from specfp on rv64.

In my test I saw the liveness sets growing to absurd sizes as we worked
from
the last block back to the first.  Think 125k entries by the time we got
back
to the entry block which would mean ~30k live registers.  Simply no way
that's
correct.

The use handling is the primary source of problems and the code that I most
want to rewrite for gcc-16.  It's just a fugly mess.  I'm not terribly
inclined
to do that rewrite for gcc-15 though.  So these will be spot adjustments.

The most important thing to know about use processing is it sets up an
iterator
and walks that.  When a SET is encountered we actually manually
dive into the SRC/DEST and ideally terminate the iterator.

If during that SET processing we encounter something unexpected we let the
iterator continue normally, which causes iteration down into the SET_DEST
object.  That's safe behavior, though it can lead to too many objects as
being
marked live.

We can refine that behavior by trivially realizing that we need not process
the
SET_DEST if it is a naked REG (and probably for other cases too, but
they're
not expected to be terribly important).  So once we see the SET with a
simple
REG destination, we can bump the iterator to avoid having it dive into the
SET_DEST if something unexpected is seen on the SET_SRC side.

Fixing this alone takes us from 125k live objects to 10k live objects at
the
entry block.  Time in ext-dce for rv64 on the testcase goes from 10.81s to
2.14s.

Given this reduces the things considered live, this could easily result in
finding more cases for ext-dce to improve.  In fact a missed optimization
issue
for rv64 I've been poking at needs this patch as a prerequisite.

Bootstrapped and regression tested on x86_64.

Pushing to the trunk.

PR rtl-optimization/117467
gcc
* ext-dce.cc (ext_dce_process_uses): When trivially possible
advance
the iterator over the destination of a SET.

[Bug rtl-optimization/119178] Optimization: (x != C) comparison can utilize (x - C) or (x ^ C) result

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=3507
   Keywords||code-size
  Component|tree-optimization   |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
well the subtract case can be done even better for aarch64 than what you
recommend.

That is:
sub w0, w0, #1365
cbz w0, .L29

is better if written as:
subs w0, w0, #1365
c.eq .L29

Note that is recorded as PR 3507 already.

NOTE I suspect this optimization is worse in general when it comes to speed but
better for size.

For an example on RISCV we have:
li  a5,1365
beq a0,a5,.L9
xoria0,a0,1365
ret

vs
xoria0,a0,1365
beq a0,zero,.L15
ret

While in the first case the li might be "free" and the beq/xori could be issue
together. While in the second case you have an extra depedency due to the xori
before the beq.

This might be decent for -Os though.

[Bug rtl-optimization/117467] [15/16 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-7916-g7d3aec2a832ef47be547d9426187562e4548bae6
Author: Jeff Law 
Date:   Sun Mar 9 14:25:37 2025 -0600

[rtl-optimization/117467] Mark FP destinations as dead

The next step in improving ext-dce is to clean up a minor wart in the
set/clobber handling code.

In that code the safe thing to do is to not process a destination at all. 
That
will leave bits set in the live bitmaps for objects that may no longer be
live.
Of course with extraneous bits set we use more memory and do more work
managing
the bitmaps, but it's safe from a code correctness standpoint.

One case that is slipping through that we need to fix is scalar fp
destinations.  Essentially the code never tried to handle those and as a
result
would leave those entities live and bubble them up through the CFG.

In the testcase at hand this takes us from ~10k live objects at entry to
~4k
live objects at entry.  Time spent in ext-dce goes from 2.14s to .64s.

Bootstrapped and regression tested on x86_64.

PR rtl-optimization/117467
gcc/
* ext-dce.cc (ext_dce_process_sets): Handle FP destinations better.

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #9 from Peter Damianov  ---
Unfortunately my patch causes ICEs in functions that optimize separate sin+cos
calls to sincos/cexpi, for reasons I'm not completely sure of.

Like the following:

typedef struct { float x,y; } Vector2;

// Rotate vector by angle
Vector2 Vector2Rotate(Vector2 v, float angle)
{
Vector2 result = { 0 };

float cosres = cosf(angle);
float sinres = sinf(angle);

result.x = v.x*cosres - v.y*sinres;
result.y = v.x*sinres + v.y*cosres;

return result;
}


gcc internally optimizes this to a call to the cexpi builtin, and then that
builtin "evaluates" to sincos later (for targets which have it), otherwise
cexpi is used (which does not set errno).
Guarding this transformation behind -fno-math-errno probably would work, but it
would also unnecessarily pessimize the above code into separate sin and cos
calls. I think fixing this properly requires expanding the sincos builtin to be
able to emit separate sin and cos calls for targets which don't have sincos,
and then optimizing to sincos for the case of -fmath-errno.

[Bug rtl-optimization/118502] Add shrink wrapping testcase for vector::push_back

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2025-January |il/gcc-patches/2025-March/6
   |/673875.html|77156.html

--- Comment #6 from Andrew Pinski  ---
Posted a new version:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677156.html

And this one passes (again) on x86_64 specifically after r15-7895.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
After regression testing and confirming this bug is fixed by 14..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066#c8

Closing this one.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

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

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

--- Comment #8 from Jerry DeLisle  ---
I have backported cleanly and regression tested on 14 branch.  Will push
shortly.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #0)
> I've also bisected an mcore-elf regression to the same change, but have not
> debugged it as the testcase is more complex and GDB port for mcore faults,
> so debugging is nontrivial.

It would be useful to list which testcases fail on mcore-elf at least.

[Bug fortran/109066] Segfault when using defined assignment

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jerry DeLisle
:

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

commit r14-11396-gf6f90e015f642424ba0e94871d9389facaca5395
Author: Paul Thomas 
Date:   Sat Nov 16 15:56:10 2024 +

Fortran: Fix segmentation fault in defined assignment [PR109066]

2024-11-16  Paul Thomas  

gcc/fortran
PR fortran/109066
* resolve.cc (generate_component_assignments): If the temporary
for 'var' is a pointer and 'expr' is neither a constant or
a variable, change its attribute from pointer to allocatable.
This avoids assignment to a temporary point that has neither
been allocated or associated.

gcc/testsuite/
PR fortran/109066
* gfortran.dg/defined_assignment_12.f90: New test.

(cherry picked from commit 27ff8049bbdb0a001ba46835cd6a334c4ac76573)

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Hmm, msp430 still uses reload, I wonder if the problem is in reload rather than
IRA.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jeffrey A. Law from comment #0)
> > I've also bisected an mcore-elf regression to the same change, but have not
> > debugged it as the testcase is more complex and GDB port for mcore faults,
> > so debugging is nontrivial.
> 
> It would be useful to list which testcases fail on mcore-elf at least.

Note mcore also uses reload too (PR 113940).

I wonder if there is some bad interaction between reload and IRA after this
patch which using LRA fixes.

[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs

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

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

--- Comment #14 from Sam James  ---
Thanks. Please try to reproduce it manually next.

[Bug c++/119179] Allow the [[gnu:::uninitialized]] attribute on classes / non-static data members

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/119179] Allow the [[gnu:::uninitialized]] attribute on classes / non-static data members

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

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

--- Comment #1 from Andrew Pinski  ---
Do you have a good example where this should be used?
I am thinking using on uninitialized on a class is even more error-prone and
invasive rather than on variables themselves.

Even more this is a security feature so using uninitialized should be using
sparsely in the first place.

>are used as "buffers" on the stack are now automatically filled with byte 
>patterns.

This is exactly when you don't want this.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug rtl-optimization/71785] Computed gotos are mostly optimized away

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/39284] Computed gotos combined too aggressively

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #11)
> Andrew.  You're missing the point.  This scenario isn't the kind of thing
> that reload and LRA are supposed to fix.  They fix constraint problems.  ie,
> I got the wrong kind of register (wrong register file), or I can't really
> handlea  constant, so reload the value into a register, etc.
> 
> We have a pseudo live across a call and IRA allocates that pseudo to a call
> clobbered hard register.  That's an IRA bug in my book.

Then it is wrong even for aarch64 which allocates r1 to the pseduo case:
  Popping a3(r109,l0)  -- assign reg 1

I am trying to point out that it looks like LRA can fix this up (reload can do
it too in some but not all cases as shown by this bug). I do think it is wrong
at least for a missed optimization case where we need now to spill the register
to the stack across the call.

I see -fno-caller-saves fixes it too.

[Bug c++/119179] New: Allow the [[gnu:::uninitialized]] attribute on classes / non-static data members

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 119179
   Summary: Allow the [[gnu:::uninitialized]] attribute on classes
/ non-static data members
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

When building under -ftrivial-auto-var-init, certain classes that contain
buffers (e.g. for SBO) and/or are used as "buffers" on the stack are now
automatically filled with byte patterns. This may cause a performance hit in
sensitive code paths.

The [[gnu::uninitialized]] attribute can be used to prevent such a hit, but
that requires annotating all use sites. That's extremely invasive and
error-prone.

It would be much more ergonomic if one could annotate with the attribute the
class itself and/or certain non-static data members, so that every usage will
automatically avoid the byte filling.

[Bug fortran/119157] [15 Regression] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Thomas Koenig :

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

commit r15-7914-g9f5b508bc5c16ae11ea385f6031487a518f62c8f
Author: Thomas Koenig 
Date:   Sun Mar 9 19:35:06 2025 +0100

Use gfc_commit_symbol() to remove UNDO status instead of new function.

This is a cleaner version, removing an unneeded function and
making sure that no memory leaks can occur if callers change.

gcc/fortran/ChangeLog:

PR fortran/119157
* gfortran.h (gfc_pop_undo_symbol): Remove prototype.
* interface.cc (gfc_get_formal_from_actual_arglist): Use
gfc_commit_symbol() instead of gfc_pop_undo_symbol().
* symbol.cc (gfc_pop_undo_symbol): Remove.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #7 from Andrew Pinski  ---
Commenting out TARGET_LRA_P in msp430.cc and gets us code that works:
```
.L2:
CMP.W   R9, R10 { JL.L3
; start of epilogue
ADD.W   #2, R1
POPM.W  #2, r10
RET
.L3:
MOV.W   @R13+, R14
MOV.W   R13, @R1
CALLR14
ADD.W   #1, R10
MOV.W   @R1, R13
BR  #.L2

```

Not the best code as it should have been in R1 in the first place but code that
definitely works.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #6 from Jeffrey A. Law  ---
I think the mcore failure was graphite/interchange-0.

On the topic of reload vs LRA.  The code is broken before IRA hands off to
LRA/reload in the msp430 case.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Commenting out TARGET_LRA_P in msp430.cc and gets us code that works:
> ```
> .L2:
> CMP.W   R9, R10 { JL.L3
> ; start of epilogue
> ADD.W   #2, R1
> POPM.W  #2, r10
> RET
> .L3:
> MOV.W   @R13+, R14
> MOV.W   R13, @R1
> CALLR14
> ADD.W   #1, R10
> MOV.W   @R1, R13
> BR  #.L2
> 
> ```
> 
> Not the best code as it should have been in R1 in the first place but code
> that definitely works.

Wait `MOV.W   R13, @R1` is a store and `MOV.W   @R1, R13` is also a store. so
my comment about being in R1 is incorrect but that is definitely doing the
right thing and spilling it into a stack location across the call.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-03-09
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW

--- Comment #9 from Andrew Pinski  ---
Note the same effect can be seen on aarch64 (though not the wrong code part due
to reload vs LRA):

  Popping a3(r109,l0)  -- assign reg 1

And then getting:
.L2:
cmp w20, w19
bgt .L3
ldp x19, x20, [sp, 16]
ldp x29, x30, [sp], 48
ret
.L3:
.cfi_restore_state
ldr x2, [x1, x19, lsl 3]
str x1, [sp, 40]
add x19, x19, 1
blr x2
ldr x1, [sp, 40]
b   .L2

See the spill around the call.

[Bug tree-optimization/118922] [12/13/14 regression] Miscompile at -O2/3

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|15.0|
  Known to work||15.0
Summary|[12/13/14/15 regression]|[12/13/14 regression]
   |Miscompile at -O2/3 |Miscompile at -O2/3

--- Comment #24 from Andrew Pinski  ---
Fixed on the trunk will queue for backporting.

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #10 from Andrew Pinski  ---
So I think the wrong code is due to reload NOT being able to handle:
(mem/f:HI (post_inc:HI (reg:HI 26 [ ivtmp.10 ])) [1 MEM[(int (*) (int)
*)_18]+0 S2 A16])


That is if you look at:
```
void f3(int x, int (*p3 []) (int))
{
  int i;
  int next = x;
  for (i = 0; i < x; i++)
next = p3[0](next);
}

```

IRA produces:
```
  Popping a3(r30,l0)  -- assign reg 13
```

For:
```
(call_insn 14 13 28 3 (set (reg:HI 12 R12)
(call:HI (mem:HI (mem/f:HI (reg/f:HI 30 [ p3 ]) [1 *p3_7(D)+0 S2 A16])
[0 *_1 S2 A16])
(const_int 0 [0]))) "t.c":7:12 89 {call_value_internal}
 (expr_list:REG_CALL_DECL (nil)
(nil))
(expr_list:HI (use (reg:HI 12 R12))
(nil)))

```

Which reload is able to handle:
```
.L2:
CMP.W   2(R1), R10 { JL .L3
; start of epilogue
ADD.W   #4, R1
POPM.W  #1, r10
RET
.L3:
MOV.W   R13, @R1 ;;;<<< store
MOV.W   @R13, R14
CALLR14
ADD.W   #1, R10
MOV.W   @R1, R13 ;; << load
BR  #.L2
```


BUT then again this is less than optimal here. because we are doing the
save/restore of r13 around the function call.

[Bug c++/119180] New: GCC Accepts Non-Standard Variable-Length Arrays (VLAs) in C++ Without Warnings

[qurong at ios dot ac.cn via Gcc-bugs]

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

Bug ID: 119180
   Summary: GCC Accepts Non-Standard Variable-Length Arrays (VLAs)
in C++ Without Warnings
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qurong at ios dot ac.cn
  Target Milestone: ---

GCC compiles code containing variable-length arrays (VLAs) and lambda captures
of VLAs without diagnostics, while Clang/MSVC correctly reject it. This
violates C++ standard rules (C++11 §8.3.4) and may mislead developers into
writing non-portable code.  

**Steps to Reproduce**:  
1. Save the following code as `test.cpp`:  
   ```cpp  
   template   
   struct Container {  
   void f(int i) {  
   int ar[i]; // Non-standard VLA  
   [&ar] { (void)ar; }(); // Lambda capture of VLA  
   }  
   };  

   int main() {  
   Container obj;  
   obj.f(5);  
   return 0;  
   }  

2. Compile with GCC:

g++ -std=c++11 test.cpp  

Expected Result:
Compilation fails with errors about VLAs being forbidden in ISO C++, or at
least issues a warning when extensions are enabled.

Actual Result:
GCC compiles the code silently (or with -pedantic warns but still succeeds).

Environment:

Compiler: GCC 13.2.0

Flags: -std=c++11

Proposal:

Enhance Warnings:

Emit a warning by default for VLAs in C++ mode (similar to -Wvla in C).

Reject lambda captures of VLAs explicitly.

Documentation Update:

Clarify VLA support as a GNU extension in C++ mode.

Additional Notes:

Standard References:

C++11 §8.3.4: Array dimensions must be constant expressions.

C++11 §5.1.2: Lambda captures require complete types.

Impact: Non-portable code may fail on other compilers.

Compiler Explorer link: https://godbolt.org/z/YdEn56Gq1

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||qurong at ios dot ac.cn

--- Comment #26 from Xi Ruoyao  ---
*** Bug 119180 has been marked as a duplicate of this bug. ***

[Bug target/119168] [15 Regression] 5% 477.dealII slowdown since r15-7605-gc5752c1f01316a

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

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

--- Comment #2 from Filip Kastl  ---
I have seen noisier, but yeah.  And 5% isn't *that* much and the benchmark got
a bit better (as I wrote).  Maybe we could mark this as WONTFIX.  I'll probably
do it if nobody becomes interested in this.

[Bug tree-optimization/119181] New: Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

Bug ID: 119181
   Summary: Missed vectorization due to imperfect SLP discovery
for strided & interleaved load.
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

void
foo (double* a, double* __restrict b)
{
b[0] = a[0] * a[256];
b[1] = a[257] * a[1];
b[2] = a[2] * a[258];
b[3] = a[259] * a[3];
b[4] = a[260] * a[4];
b[5] = a[261] * a[5];
b[6] = a[6] * a[262];
b[7] = a[7] * a[263];
}

void
foo1 (double* a, double* __restrict b, double* c)
{
b[0] = a[0] * a[256];
b[1] = a[1] * a[257];
b[2] = a[2] * a[258];
b[3] = a[3] * a[259];
b[4] = a[4] * a[260];
b[5] = a[5] * a[261];
b[6] = a[6] * a[262];
b[7] = a[7] * a[263];
}

Foo1 can be vectorized but foo can't, it's because SLP discovery didn't build
a[0], a[1], a[2], , a[7] into same node, but build a[0] a[257], a[2],
a[259], a[260], a[261], a[6], a[7].


/app/example.cpp:4:10: note:   starting SLP discovery for node 0xb1488e0
/app/example.cpp:4:10: note:   get vectype for scalar type (group size 8):
double
/app/example.cpp:4:10: note:   vectype: vector(4) double
/app/example.cpp:4:10: note:   nunits = 4
/app/example.cpp:4:10: note:   Build SLP for _1 = *a_26(D);
/app/example.cpp:4:10: note:   Build SLP for _4 = MEM[(double *)a_26(D) +
2056B];
/app/example.cpp:4:10: note:   Build SLP for _7 = MEM[(double *)a_26(D) + 16B];
/app/example.cpp:4:10: note:   Build SLP for _10 = MEM[(double *)a_26(D) +
2072B];
/app/example.cpp:4:10: note:   Build SLP for _13 = MEM[(double *)a_26(D) +
2080B];
/app/example.cpp:4:10: note:   Build SLP for _16 = MEM[(double *)a_26(D) +
2088B];
/app/example.cpp:4:10: note:   Build SLP for _19 = MEM[(double *)a_26(D) +
48B];
/app/example.cpp:4:10: note:   Build SLP for _22 = MEM[(double *)a_26(D) +
56B];

NOTE it's different from PR114375 since there's no permuted mask load.

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like it is missing the commutativity property of multiply.

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #2 from Hongtao Liu  ---
(In reply to Andrew Pinski from comment #1)
> Looks like it is missing the commutativity property of multiply.
Note compiler options is with Ofast.

[Bug c++/119182] New: Compiler Fails to Diagnose Redefinition of Type Alias in Lambda Scope

[qurong at ios dot ac.cn via Gcc-bugs]

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

Bug ID: 119182
   Summary: Compiler Fails to Diagnose Redefinition of Type Alias
in Lambda Scope
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qurong at ios dot ac.cn
  Target Milestone: ---

The compiler silently accepts code that redefines a type alias (`using`) within
the same lambda scope, while Clang correctly issues a warning. This violates
C++17 §10.1.3, which prohibits redefining type aliases in the same scope and
requires a diagnostic.  

**Steps to Reproduce**:  
1. Save the following code as `test.cpp`:  
   ```cpp  
   template   
   struct Test {  
   int f() {  
   int x = 0;  
   [x = x, &r = x] {  
   using ty1 = int; // First definition  
   using ty1 = decltype(x); // Redefinition (invalid)  
   };  
   return 0;  
   }  
   };  

   int main() {  
   Test obj;  
   obj.f();  
   return 0;  
   }  
```

2. Compile with GCC:
g++ -std=c++17 test.cpp

Expected Result:
A diagnostic (error/warning) about the redefinition of ty1.

Actual Result:
GCC compile the code without any errors or warnings.

Environment:
Compiler: GCC 13.2.0
Flags: -std=c++17

Proposal:
Reject the code or emit a diagnostic for redefined type aliases in the same
scope, as required by the standard.

Additional Notes:
Standard Reference: C++17 §10.1.3:
"A type-name introduced by a using declaration shall be unique in the
declarative region in which it appears."
Clang Behavior: Correctly warns with warning: redefinition of type alias 'ty1'.

Compiler Explorer link: https://godbolt.org/z/xEMrnbrW4

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

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

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

--- Comment #19 from Li Pan  ---
> No you got it wrong.
> _121 will either be -1 or 0. _11 should be -1 or 0 too.
> So the question is what was the VEC_EXTRACT doing the right thing? Is it 0/-1 
> or 0/1? 

Oh, I see. Let me revisit the dump code.

> diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> index 92e6942b523..c484e9f3c70 100644
> --- a/gcc/config/riscv/autovec.md
> +++ b/gcc/config/riscv/autovec.md
> @@ -1451,14 +1451,16 @@ (define_expand "vec_extractqi"
> 
>  ;; Same for a BImode but still return a QImode.
>  (define_expand "vec_extractbi"
> -  [(set (match_operand:QI0 "register_operand")
> - (vec_select:QI
> +  [(set (match_operand:BI0 "register_operand")
> + (vec_select:BI
> (match_operand:VB_VLS 1 "register_operand")
> (parallel
>  [(match_operand  2 "nonmemory_operand")])))]
>"TARGET_VECTOR"
>  {
> -  emit_insn (gen_vec_extractqi (operands[0], operands[1], 
> operands[2]));
> +  rtl qir = gen_reg (QImode);
> +  emit_insn (gen_vec_extractqi (qir, operands[1], operands[2]));
> +  emit_move_insn (operands[0], gen_lowpart (BImode, qir));
>DONE;
>  })

Have a quick try as above change, seems still fail here.

[Bug fortran/118640] [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jerry DeLisle
:

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

commit r14-11398-g5cb69a5e4f136dd92c2182d6744aff2c12291a4f
Author: Paul Thomas 
Date:   Mon Jan 27 09:55:26 2025 +

Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]

2025-01-27  Paul Thomas  

gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not pick up the optional attribute from
the lhs.

gcc/testsuite/
PR fortran/118640
* gfortran.dg/pr118640.f90: New test.

(cherry picked from commit 3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d)

[Bug fortran/118640] [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
I backported this to follow the backport fixing PR115265. Regression tested to
confirm on gcc14. I backported the fix for PR109066.

A double jeapardy. I hope I did not mess everyone up.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

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

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

--- Comment #11 from Jerry DeLisle  ---
(In reply to Matthew Krupcale from comment #10)
> Thanks Jerry! I think you may also have to backport the fix [1] for PR118640
> to avoid regression on the 14 branch as well.
> 
> [1]
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d

Thanks for pointing that out. I overlooked it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640#c7

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #3 from Hongtao Liu  ---
void
foo (int* a, int* __restrict b)
{
b[0] = a[0] * a[256];
b[1] = a[257] * a[1];
b[2] = a[2] * a[258];
b[3] = a[259] * a[3];
b[4] = a[260] * a[4];
b[5] = a[261] * a[5];
b[6] = a[6] * a[262];
b[7] = a[7] * a[263];
}

void
foo1 (int* a, int* __restrict b)
b[0] = a[0] * a[256];
b[1] = a[1] * a[257];
b[2] = a[2] * a[258];
b[3] = a[3] * a[259];
b[4] = a[4] * a[260];
b[5] = a[5] * a[261];
b[6] = a[6] * a[262];
b[7] = a[7] * a[263];
}

Use int instead of double.

Looks like if both operands satisfy same STMT_VINFO_GROUPED_ACCESS as first
stmt, we'd better have a heuristic to choose more closer one?

in vect_build_slp_tree_1

 1360  || (ldst_p   
 1361  && (STMT_VINFO_GROUPED_ACCESS (stmt_info)
 1362  != STMT_VINFO_GROUPED_ACCESS (first_stmt_info))) 
 1363  || (ldst_p

[Bug target/119159] [15 Regression] 6% slowdown of 520.omnetpp_r on aarch64

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

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

--- Comment #1 from Filip Kastl  ---
>From the graph it looks like the slowdown is gone.  The benchmark exec time is
at its previous value.  I'm gonna wait for the automated benchmark to run again
and confirm this and then I'll close this PR.

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Hongtao Liu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Looks like it is missing the commutativity property of multiply.
> Note compiler options is with Ofast.

What i mean is the commutative property is not being taken into account, that
is the vectorizer misses the commutative property in some cases.

PR 115833 is a similar case where the commutative property is not being taken
into account.

[Bug c++/119182] Compiler Fails to Diagnose Redefinition of Type Alias in Lambda Scope

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

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

--- Comment #1 from Andrew Pinski  ---
clang does not warn here about ty1 being redeclared.

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #5 from Hongtao Liu  ---

> 
> Looks like if both operands satisfy same STMT_VINFO_GROUPED_ACCESS as first
> stmt, we'd better have a heuristic to choose more closer one?
If all grouped operations satisfy commutative property.

[Bug c++/119182] Compiler Fails to Diagnose Redefinition of Type Alias in Lambda Scope

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

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

--- Comment #3 from Andrew Pinski  ---
Rather `const int` vs `int`.

[Bug c++/119182] Compiler Fails to Diagnose Redefinition of Type Alias in Lambda Scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/119181] Missed vectorization due to imperfect SLP discovery for strided & interleaved load.

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

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

--- Comment #6 from Hongtao Liu  ---
void
foo (int* a, int* __restrict b, int* c)
{
b[0] = a[0] * c[256];
b[1] = c[257] * a[1];
b[2] = a[2] * c[258];
b[3] = c[259] * a[3];
b[4] = c[260] * a[4];
b[5] = c[261] * a[5];
b[6] = a[6] * c[262];
b[7] = a[7] * c[263];
}

BB vectorizer will retrying with swapped operand if different interleaving
chains in one node.

/app/example.cpp:4:10: note:   Build SLP for _1 = *a_26(D);
/app/example.cpp:4:10: note:   Build SLP for _4 = MEM[(int *)c_27(D) + 1028B];
/app/example.cpp:4:10: missed:   Build SLP failed: different interleaving
chains in one node _4 = MEM[(int *)c_27(D) + 1028B];
/app/example.cpp:4:10: note:   Build SLP for _7 = MEM[(int *)a_26(D) + 8B];
/app/example.cpp:4:10: note:   Build SLP for _10 = MEM[(int *)c_27(D) + 1036B];
/app/example.cpp:4:10: missed:   Build SLP failed: different interleaving
chains in one node _10 = MEM[(int *)c_27(D) + 1036B];
/app/example.cpp:4:10: note:   Build SLP for _13 = MEM[(int *)c_27(D) + 1040B];
/app/example.cpp:4:10: missed:   Build SLP failed: different interleaving
chains in one node _13 = MEM[(int *)c_27(D) + 1040B];
/app/example.cpp:4:10: note:   Build SLP for _16 = MEM[(int *)c_27(D) + 1044B];
/app/example.cpp:4:10: missed:   Build SLP failed: different interleaving
chains in one node _16 = MEM[(int *)c_27(D) + 1044B];
/app/example.cpp:4:10: note:   Build SLP for _19 = MEM[(int *)a_26(D) + 24B];
/app/example.cpp:4:10: note:   Build SLP for _22 = MEM[(int *)a_26(D) + 28B];
/app/example.cpp:4:10: note:   SLP discovery for node 0x10fbb9a0 failed
/app/example.cpp:4:10: note:   Re-trying with swapped operands of stmts 1 3 4 5 
/app/example.cpp:4:10: note:   starting SLP discovery for node 0x10fbba30
/app/example.cpp:4:10: note:   get vectype for scalar type (group size 8): int
/app/example.cpp:4:10: note:   vectype: vector(8) int
/app/example.cpp:4:10: note:   nunits = 8
/app/example.cpp:4:10: note:   Build SLP for _1 = *a_26(D);
/app/example.cpp:4:10: note:   Build SLP for _5 = MEM[(int *)a_26(D) + 4B];
/app/example.cpp:4:10: note:   Build SLP for _7 = MEM[(int *)a_26(D) + 8B];
/app/example.cpp:4:10: note:   Build SLP for _11 = MEM[(int *)a_26(D) + 12B];
/app/example.cpp:4:10: note:   Build SLP for _14 = MEM[(int *)a_26(D) + 16B];
/app/example.cpp:4:10: note:   Build SLP for _17 = MEM[(int *)a_26(D) + 20B];
/app/example.cpp:4:10: note:   Build SLP for _19 = MEM[(int *)a_26(D) + 24B];
/app/example.cpp:4:10: note:   Build SLP for _22 = MEM[(int *)a_26(D) + 28B];
/app/example.cpp:4:10: note:   SLP discovery for node 0x10fbba30 succeeded
/app/example.cpp:4:10: note:   starting SLP discovery for node 0x10fbbac0
/app/example.cpp:4:10: note:   get vectype for scalar type (group size 8): int
/app/example.cpp:4:10: note:   vectype: vector(8) int

[Bug c/119183] New: Compilation Timeout Issue

[xieym3 at zohomail dot com via Gcc-bugs]

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

Bug ID: 119183
   Summary: Compilation Timeout Issue
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xieym3 at zohomail dot com
  Target Milestone: ---

The following code snippet fails to complete compilation within a reasonable
timeframe using GCC versions 11.4.0, 14.2.0, and current trunk.
$ timeout 300 gcc -x c -std=c2x file.c
$ cat file.c
#include 
#include 
#include 
#include 
int test()
{
int a = rand();
if(a >= 0 )
return a*a + rand() + rand();
else
return rand() - 1;
}
void main(int argc,  char** argv){
float sum = 0.0;
sum -= ( ((( (12.0f)*( (1.0f)*( (1.0f)*( (1.0f)*( (1024.0f)*( (1024.0f)*(
(1.0f)*( (1.0f)*( (1.0f)*( (rand())*( (rand())*( (1024.0f)*( (1024.0f)*(
(12.0f)*( (1.0f)*( (1.0f)*( (1.0f)*( (test())*( (test())*( (1024.0f)*(
(1024.0f)*( (1.0f)*( (1.0f)*( (1.0f)*( (test())*( (test())*( (1024.0f)*(
(1024.0f)*( (12.0f)*( (1.0f)*( (1.0f)*( (1.0f)*( (1.0f)*( (test())*( (test())*(
(1024.0f)*( (1024.0f)*( (rand())-1.0*((3)*((4.0f)*(1024.0f)*(
(rand())-1.0*((3)*((4.0f)*(1024.0f)*(
(rand())-1.0*((3)*((4.0f)*(1024.0f)*(rand()*(-1)));
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/llm/install/gcc-14.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/llm/install/gcc-14.2.0/libexec/gcc/x86_64-pc-linux-gnu/14.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/llm/src/gcc-14.2.0/configure --enable-coverage
--enable-checking --disable-multilib --disable-shared --disable-bootstrap
--enable-languages=c,c++ --prefix=/data/xieym/llm/install/gcc-14.2.0
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (GCC)

Clang trunk successfully finish compilation the code within seconds.
Reproduction link: https://godbolt.org/z/1P96fhcT3.
Could this possibly be a bug?

[Bug c++/79378] lambda init-capture adds const

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||qurong at ios dot ac.cn

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

[Bug c++/79133] lambda capture shadowing parameter & decltype confusion

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/119174] [15 Regression] IRA allocating value live across a call to call clobbered register

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

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

--- Comment #11 from Jeffrey A. Law  ---
Andrew.  You're missing the point.  This scenario isn't the kind of thing that
reload and LRA are supposed to fix.  They fix constraint problems.  ie, I got
the wrong kind of register (wrong register file), or I can't really handlea 
constant, so reload the value into a register, etc.

We have a pseudo live across a call and IRA allocates that pseudo to a call
clobbered hard register.  That's an IRA bug in my book.

[Bug fortran/115265] Generic function for constructor not invoked for same-name derived type with procedure pointer component

[mkrupcale at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Matthew Krupcale  ---
Thanks Jerry! I think you may also have to backport the fix [1] for PR118640 to
avoid regression on the 14 branch as well.

[1]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3600b1ff14a459e84bb40bdfea7cd8d2ffd73d8d

[Bug c++/119180] GCC Accepts Non-Standard Variable-Length Arrays (VLAs) in C++ Without Warnings

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #1 from Xi Ruoyao  ---
Dup.

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

[Bug c++/119180] GCC Accepts Non-Standard Variable-Length Arrays (VLAs) in C++ Without Warnings

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

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

--- Comment #2 from Xi Ruoyao  ---
> Actual Result:
> GCC compiles the code silently (or with -pedantic warns but still succeeds).

"Warns but still succeeds" is a correct behavior.

The standard NEVER says "the code should be rejected."  It only says
"diagnostic is required" and warning IS a diagnostic.  Please stop assuming the
code must be rejected when the standard mandates a diagnostic.

> Impact: Non-portable code may fail on other compilers.

It's not a bug GCC supports its own extensions.  Please stop considering such
things as bugs.

The only real issue here is it's debatable if we should emit the warning by
default, and that is PR 110848.

[Bug c++/119180] GCC Accepts Non-Standard Variable-Length Arrays (VLAs) in C++ Without Warnings

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

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

--- Comment #3 from Andrew Pinski  ---
>with -pedantic warns but still succeeds

You need -pedantic-errors.

[Bug rtl-optimization/117467] [15/16 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #19 from Jeffrey A. Law  ---
Nuts. Busted most of the optimizations for rv64 with the change to the use side
handling.  I guess that's what I get for trying to generalize a pattern I was
seeing -- I'd tested the ad-hoc variant on rv64, but not the more general one. 
I'll deal with it tomorrow, it's too late tonight.