[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

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

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

Sam James  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
Summary|[15 regression] Missed  |[15 regression] Missed
   |optimization with with  |optimization with with
   |std::vector resize in loop  |std::vector resize in loop
   ||since
   ||r15-575-gda73261ce7731b

--- Comment #2 from Sam James  ---
r15-575-gda73261ce7731b

Confirmed with a revert too (as in just before that commit, as it doesn't
revert cleanly on trunk and I didn't try massage it).

I'm very surprised by this as I was under the impression the prange stuff was
an initial stub (new class of range) rather than with anything especially wired
with it yet -- I must have misread something.

andrew?

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

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

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

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> [...]
> I'm very surprised by this as I was under the impression the prange stuff
> was an initial stub (new class of range) rather than with anything
> especially wired with it yet -- I must have misread something.
> 

(I should say: I thought it was a clone of irange to start with, with
adaptations planned, rather than - as it really is - already a set of some
initial diff. impls.)

[Bug c/117164] ICE building gcc.dg/nested-func-12.c with -std=gnu23

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from uecker at gcc dot gnu.org ---

TYPE_CANONICAL is not set for structures of variable size. 

What is puzzling here is that semantically we only have one struct type. I
assume the type is duplicated somehow during inlining, probably because the
variable it depends on is duplicated in the parent function, and then it does
not understand anymore that the types are compatible.

[Bug fortran/117225] ICE with -funsigned in gfc_match_sym_complex_part

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4f9b1735ab5eaf93d07d65c81d83cd123a8f3478
 (no idea why this
does not show up in the PR).

[Bug fortran/116025] Experimental implementation of unsigned integers for Fortran

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

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

Bug 117225 Summary: ICE with -funsigned in gfc_match_sym_complex_part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117225

   What|Removed |Added

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

[Bug tree-optimization/107467] [12/13/14 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #13 from Sam James  ---
(In reply to Sam James from comment #12)
> This seems to work on trunk now.

Fixed on trunk by r15-626-ga5b3721c06646b for PR115110, then see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110#c8 which refers to
r15-512-g9b7cad5884f21c which sounds a lot like the fix for this.

[Bug c/105863] RFE: C23 #embed

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

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

--- Comment #18 from Thomas Schwinge  ---
The C23 '#embed' support still needs to be documented on
.

[Bug libstdc++/117221] Add smoketest for alternative compiler for libstdc++ headers (like CXX_UNDER_TEST)

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Related: bug 103324 for a more general smoketest

[Bug ipa/115815] [13/14 Regression] ICE: in purge_all_uses, at ipa-param-manipulation.cc:632 with -O2 -flto and incorrect usage of attribute destructor

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #11 from Sam James  ---
Thank you Martin! (And no worries, I was just going over some backports which
looked like they were missing/stuck after I handled some others.)

[Bug ipa/115815] [13 Regression] ICE: in purge_all_uses, at ipa-param-manipulation.cc:632 with -O2 -flto and incorrect usage of attribute destructor

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c/117164] ICE building gcc.dg/nested-func-12.c with -std=gnu23

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---
Adding debug_tree for lhs and fntype in verify_gimple right before the "invalid
conversion in gimple call"  (should the debug_generic_stmt already give me this
information somehow?)

 
used unsigned ignored TI
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:10
size 
unit-size 
align:128 warn_if_not_align:0 context  abstract_origin >
unit-size 
used unsigned ignored DI
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:10
size 
unit-size 
align:64 warn_if_not_align:0 context  abstract_origin 
value-expr 
arg:0  arg:1 >>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
fields 
used decl_0 BLK ../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:18
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 0
offset 
bit-offset  context
> context 
pointer_to_this  chain >
nothrow
arg:0 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality>
var 
def_stmt _7 = __builtin_alloca_with_align (_5, 32);
version:7>
arg:1 
constant 0>>
 
used unsigned ignored TI
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:10
size 
unit-size 
align:128 warn_if_not_align:0 context >
unit-size 
used unsigned ignored DI
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:10
size 
unit-size 
align:64 warn_if_not_align:0 context 
value-expr 
arg:0  arg:1 >>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
fields 
decl_0 BLK ../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:9:18 size
 unit-size 
align:32 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 0
offset 
bit-offset  context
> context 
pointer_to_this  chain >
type_6 QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
arg-types >>
pointer_to_this >
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c: In function ‘main’:
../gcc/gcc/testsuite/gcc.dg/nested-func-12.c:45:1: error: invalid conversion in
gimple call

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

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

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

--- Comment #5 from Sam James  ---
so with irange, evrp discovers _17's range earlier, but with prange, it doesn't
(only does so in vrp1?

[Bug c++/117224] New: warning states "this" is explicit by-copy capture but it's an explicit by-reference capture

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

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

Bug ID: 117224
   Summary: warning states "this" is explicit by-copy capture but
it's an explicit by-reference capture
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case:
...
$ cat test.cc
#include 

class X
{
 public:
  X (int v) {
value = v;
  }

  X (const X& a) {
value = a.value;
printf ("copy constructor\n");
  }

  int value;

  int f (void) {
auto l = [=, THIS] {
  return value + 2;
};

return l ();
  }
};

int
main (void)
{
  X a (3);

  return a.f ();
}
...

As documented [1], a "this" capture means a by-reference capture (so, copy
constructor is not called), and a "*this" means a by-copy capture (so, copy
constructor is called):
...
$ g++ test.cc -DTHIS="this"
$ ./a.out 
$ g++ test.cc -DTHIS="*this"
$ ./a.out 
copy constructor
$
...

Sofar the sanity check.

With -pedantic, we run into this warning:
...
$ g++ test.cc -DTHIS="this" -pedantic
test.cc: In member function ‘int X::f()’:
: warning: explicit by-copy capture of ‘this’ with by-copy
capture default only available with ‘-std=c++20’ or ‘-std=gnu++20’
[-Wc++20-extensions]
test.cc:18:18: note: in expansion of macro ‘THIS’
   18 | auto l = [=, THIS] {
  |  ^~~~
...

The text of the warning is incorrect: the warning states that "this" is an
explicit by-copy capture, but it's an explicit by-reference capture.

Clang show this warning text instead:
...
$ clang++ test.cc -DTHIS="this" -pedantic
test.cc:18:18: warning: explicit capture of 'this' with a capture default of
'=' is a C++20 extension [-Wc++20-extensions]
   18 | auto l = [=, THIS] {
  |  ^
:1:14: note: expanded from macro 'THIS'
1 | #define THIS this
  |  ^
1 warning generated.
...

[1] https://en.cppreference.com/w/cpp/language/lambda

[Bug c/117164] ICE building gcc.dg/nested-func-12.c with -std=gnu23

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-checking

--- Comment #4 from uecker at gcc dot gnu.org ---
.

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

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

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

--- Comment #4 from Sam James  ---
With prange, evrp has:
```
[-Global Exported: _17 = [irange] long int [-INF, -1][1, +INF]-]
```
and then vrp1 has:
```
[...]
{+Global Exported: _69 = [prange] int * [1, +INF]+}
Global Exported: _68 = [irange] long unsigned int [0, 0]
{+Global Exported: _67 = [irange] long int [0, 0]+}
Global Exported: _82 = [irange] long unsigned int [0, 9223372036854775804] MASK
0x7fff VALUE 0x0
int main ()
{
@@ -91,7 +93,6 @@ int main ()
  int * _44;
  int * _53;
  int * _61;
[-  long int _67;-]
  int * _69;
  long unsigned int _82;
  long unsigned int _95;
@@ -101,7 +102,6 @@ int main ()
  int * _130;
  long unsigned int _149;
  long unsigned int _156;
[-  long unsigned int _161;-]
[...]


Then forwprop3 ends up keeping bbs 9/10/11/15/12 and it all goes wrong from
there.

[Bug fortran/117225] New: ICE with -funsigned in gfc_match_sym_complex_part

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

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

Bug ID: 117225
   Summary: ICE with -funsigned in gfc_match_sym_complex_part
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The test case

program main
  unsigned, parameter :: u = 7u
  print *,mod(-(u+1u),u)
end program main

ICEs:

 gfortran -funsigned unsigned_38.f90 
f951: interner Compiler-Fehler: gfc_match_sym_complex_part(): Bad type
0xa35eff diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../trunk/gcc/diagnostic.h:1062
0xa35eff gfc_report_diagnostic
../../trunk/gcc/fortran/error.cc:248
0xa35eff gfc_internal_error(char const*, ...)
../../trunk/gcc/fortran/error.cc:882
0xab1f17 match_sym_complex_part
../../trunk/gcc/fortran/primary.cc:1475
0xab344b match_complex_part
../../trunk/gcc/fortran/primary.cc:1494
0xab344b match_complex_constant
../../trunk/gcc/fortran/primary.cc:1527
0xab36f9 gfc_match_literal_constant(gfc_expr**, int)
../../trunk/gcc/fortran/primary.cc:1635
0xa74b25 match_primary
../../trunk/gcc/fortran/matchexp.cc:150
0xa74b25 match_level_1
../../trunk/gcc/fortran/matchexp.cc:212
0xa74b25 match_mult_operand
../../trunk/gcc/fortran/matchexp.cc:268
0xa74f18 match_add_operand
../../trunk/gcc/fortran/matchexp.cc:357
0xa7532c match_level_2
../../trunk/gcc/fortran/matchexp.cc:473
0xa753b6 match_level_3
../../trunk/gcc/fortran/matchexp.cc:552
0xa754ef match_level_4
../../trunk/gcc/fortran/matchexp.cc:600
0xa754ef match_and_operand
../../trunk/gcc/fortran/matchexp.cc:694
0xa756c6 match_or_operand
../../trunk/gcc/fortran/matchexp.cc:723
0xa757d6 match_equiv_operand
../../trunk/gcc/fortran/matchexp.cc:766
0xa758e8 match_level_5
../../trunk/gcc/fortran/matchexp.cc:812
0xa74a04 gfc_match_expr(gfc_expr**)
../../trunk/gcc/fortran/matchexp.cc:871
0xab2807 match_actual_arg
../../trunk/gcc/fortran/primary.cc:1798

[Bug tree-optimization/113676] [12 Regression] Miscompilation tree-vrp __builtin_unreachable

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-19
 Ever confirmed|0   |1

[Bug fortran/117225] ICE with -funsigned in gfc_match_sym_complex_part

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2

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

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

--- Comment #4 from uecker at gcc dot gnu.org ---

A bit nicer test:

void b();
int e(int *c, struct d { [[gnu::vector_size(4)]] char an[*c]; } *)
{
   (void)sizeof(struct d);
   return 0;
}
void f() {
  int a = 0;
  if (e(&a, 0))
b();
}

https://godbolt.org/z/Wb79jb7Te

[Bug rtl-optimization/114960] [12/13/14/15 Regression] fails to clean up vector casts

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug rtl-optimization/110393] [13 regression] ICE at -O3 with "-fselective-scheduling2 -fPIC": in move_op_ascend, at sel-sched.cc:6150

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||14.2.0, 14.2.1, 15.0
 Ever confirmed|0   |1
Summary|ICE at -O3 with |[13 regression] ICE at -O3
   |"-fselective-scheduling2|with
   |-fPIC": in move_op_ascend,  |"-fselective-scheduling2
   |at sel-sched.cc:6150|-fPIC": in move_op_ascend,
   ||at sel-sched.cc:6150
   Last reconfirmed||2024-10-19
  Known to fail||12.4.0, 12.4.1, 13.3.0,
   ||13.3.1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Sam James  ---
13.3 is broken, 14 and 15 are fine.

[Bug rtl-optimization/110391] [12/13/14/15 Regression] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-19

[Bug rtl-optimization/115568] [12/13/14/15 Regression] wrong code at -O2 with "-fno-tree-sink -fno-tree-ter -fschedule-insns" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug middle-end/109856] [13/14/15 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Ever confirmed|0   |1
 CC||sjames at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug ipa/114790] [12/13/14/15 regression] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #3 from Georg-Johann Lay  ---
Maybe this one is related to the fact that LRA doesn't set strict when it is in
strict-RTL mode?  For example, with your latest test case:

$avr-gcc foo.c -S -mlra -O1 -mmcu=atmega128 -fdump-rtl-final
-mlog=legitimate_address_p

...
avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
reload_completed=0 ra_in_progress=1 (reg_renumber):(r28 ---> r28)
(plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1]))

avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
reload_completed=0 ra_in_progress=1 (reg_renumber):(r28 ---> r28)
(plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1]))

avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
(plus:HI (reg/f:HI 32 __SP_L__)
(const_int 1 [0x1]))

avr_legitimate_address_p[f:postreload(323)]: ret=1, mode=QI strict=0
reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
(plus:HI (reg/f:HI 32 __SP_L__)
(const_int 1 [0x1]))

avr_legitimate_address_p[f:split2(327)]: ret=1, mode=QI strict=0
reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
(plus:HI (reg/f:HI 32 __SP_L__)
(const_int 1 [0x1]))

...

i.e. strict=0 in all calls, and hence the backend returns ret=1 for SP+const
addresses.

[Bug modula2/115328] The FORWARD keyword is not implemented

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

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

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

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

https://gcc.gnu.org/g:8d6d6d537fdc754a429b08091422c307188f3c82

commit r15-4503-g8d6d6d537fdc754a429b08091422c307188f3c82
Author: Andrew Pinski 
Date:   Wed Sep 4 12:11:43 2024 -0700

phiopt: do factor_out_conditional_operation for all phis [PR112418]

Sometimes factor_out_conditional_operation can factor out
an operation that causes a phi node to become the same element.
Other times, we want to factor out a binary operator because
it can improve code generation, an example is PR 110015 (openjpeg).

Note this includes a heuristic to decide if factoring out the operation
is profitable or not. It can be expanded to include a better live range
extend detector. Right now it has a simple one where if it is live on a
dominating path, it is considered a live or if there are a small # of
assign statements (defaults to 5), then it does not extend the live range
too much.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/112418

gcc/ChangeLog:

* tree-ssa-phiopt.cc (is_factor_profitable): New function.
(factor_out_conditional_operation): Add merge argument. Remove
arg0/arg1 arguments. Return bool instead of the new phi.
Early return for virtual ops. Call is_factor_profitable to
check if the factoring would be profitable.
(pass_phiopt::execute): Call factor_out_conditional_operation
on all phis instead of just singleton phi.
* doc/invoke.texi (--param phiopt-factor-max-stmts-live=):
Document.
* params.opt (--param=phiopt-factor-max-stmts-live=): New opt.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/factor_op_phi-1.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-2.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-3.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-4.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/112418] factor_out_conditional_operation could be done for more phis

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

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

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

Bug 112418 Summary: factor_out_conditional_operation could be done for more phis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418

   What|Removed |Added

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

[Bug c/113688] verify_type fails for compatible structs with FAM in C23

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---

The issue is that struct with ISO C99 flexible array member and GNU zero-sized
extension will have different mode but we may want to them to be compatible.

[Bug tree-optimization/112418] factor_out_conditional_operation could be done for more phis

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

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

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

https://gcc.gnu.org/g:8d6d6d537fdc754a429b08091422c307188f3c82

commit r15-4503-g8d6d6d537fdc754a429b08091422c307188f3c82
Author: Andrew Pinski 
Date:   Wed Sep 4 12:11:43 2024 -0700

phiopt: do factor_out_conditional_operation for all phis [PR112418]

Sometimes factor_out_conditional_operation can factor out
an operation that causes a phi node to become the same element.
Other times, we want to factor out a binary operator because
it can improve code generation, an example is PR 110015 (openjpeg).

Note this includes a heuristic to decide if factoring out the operation
is profitable or not. It can be expanded to include a better live range
extend detector. Right now it has a simple one where if it is live on a
dominating path, it is considered a live or if there are a small # of
assign statements (defaults to 5), then it does not extend the live range
too much.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/112418

gcc/ChangeLog:

* tree-ssa-phiopt.cc (is_factor_profitable): New function.
(factor_out_conditional_operation): Add merge argument. Remove
arg0/arg1 arguments. Return bool instead of the new phi.
Early return for virtual ops. Call is_factor_profitable to
check if the factoring would be profitable.
(pass_phiopt::execute): Call factor_out_conditional_operation
on all phis instead of just singleton phi.
* doc/invoke.texi (--param phiopt-factor-max-stmts-live=):
Document.
* params.opt (--param=phiopt-factor-max-stmts-live=): New opt.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/factor_op_phi-1.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-2.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-3.c: New test.
* gcc.dg/tree-ssa/factor_op_phi-4.c: New test.

Signed-off-by: Andrew Pinski 

[Bug c/117230] New: ICE: in sizeof_pointer_memaccess_warning, at c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess

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

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

Bug ID: 117230
   Summary: ICE: in sizeof_pointer_memaccess_warning, at
c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
#include 
int *a __attribute__((vector_size(4)));
b = strncat(b, a, sizeof(a));

***
Command Lines:
$ gcc -Wsizeof-pointer-memaccess mutant.c
mutant.c:3:1: warning: data definition has no type or storage class
3 | b = strncat(b, a, sizeof(a));
  | ^
mutant.c:3:1: error: type defaults to 'int' in declaration of 'b'
[-Wimplicit-int]
mutant.c:3:1: internal compiler error: tree check: expected none of
vector_type, have vector_type in sizeof_pointer_memaccess_warning, at
c-family/c-warn.cc:987
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x2685609 tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
???:0
0xdb6650 tree_not_check(tree_node*, char const*, int, char const*, tree_code)
???:0
0x10812bf sizeof_pointer_memaccess_warning(unsigned int*, tree_node*,
vec*, tree_node**, bool (*)(tree_node*,
tree_node*))
???:0
0xef06ce c_parse_file()
???:0
0x101444a 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.

Also ICE on trunk.
Compiler Explorer: https://godbolt.org/z/KTb9611x4

[Bug testsuite/113502] gcc.target/aarch64/vect-early-break-cbranch.c and gcc.target/aarch64/sve/vect-early-break-cbranch.c testcase are too sensitive

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/117230] [14/15 Regression] ICE: in sizeof_pointer_memaccess_warning, at c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-checking,
   ||ice-on-valid-code
Summary|ICE: in |[14/15 Regression] ICE: in
   |sizeof_pointer_memaccess_wa |sizeof_pointer_memaccess_wa
   |rning, at   |rning, at
   |c-family/c-warn.cc:987 with |c-family/c-warn.cc:987 with
   |-Wsizeof-pointer-memaccess  |-Wsizeof-pointer-memaccess
   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.3

--- Comment #1 from Andrew Pinski  ---
Confirmed here is a slightly better/portable testcase:
```
typedef int intv1 __attribute__((vector_size(sizeof(int;

void f(intv1 *a, char *b) {
  __builtin_memcpy(b, a, sizeof(a));
}
```

Started with r14-2150-gfe48f2651334bc which adds the check for vector types for
TYPE_PRECISION BUT the bug was there before really just not showing up before.

Maybe there should be a check that type is an integral type before checking the
precision here will fix it too.
  else if ((TYPE_PRECISION (TREE_TYPE (type))
== TYPE_PRECISION (char_type_node))
   || strop)

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce since r15-1901-g98914f9eba5f19

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/107467] [12/13/14 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

Sam James  changed:

   What|Removed |Added

  Known to work||15.0
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
   |Miscompilation involing -Os |Miscompilation involing -Os
   |, -flto and |, -flto and
   |-fno-strict-aliasing since  |-fno-strict-aliasing since
   |r12-656-ga564da506f52be66   |r12-656-ga564da506f52be66
   Keywords||needs-bisection

--- Comment #12 from Sam James  ---
This seems to work on trunk now.

[Bug middle-end/109856] [13 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||needs-bisection
Summary|[13/14/15 regression]   |[13 regression]
   |-Wnull-dereference false|-Wnull-dereference false
   |positive in Emacs itree.c   |positive in Emacs itree.c
   |(regression from GCC 12)|(regression from GCC 12)
  Known to fail||13.3.1
  Known to work||14.2.1, 15.0

--- Comment #2 from Sam James  ---
14 and 15 are fine.

[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-19

[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2

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

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

--- Comment #5 from uecker at gcc dot gnu.org ---

The underlying issue appears to be that we somehow do not recognize the struct
as a variable modified type if it has the attribute. The change referenced
above then does not handle size expression correctly which was previously done
in gimplify_parameters (but this was wrong for other reasons).

void e(int c)
{
goto foo;
[[maybe_unused]] struct d { [[gnu::vector_size(4)]] char an[c]; } q;
foo:
}

void f(int c)
{
goto bar;
[[maybe_unused]] struct d { char an[c]; } q;
bar:
}

https://godbolt.org/z/q76h8xf4K

[Bug target/117223] ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with custom flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/113506] ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -Os -fno-tree-coalesce-vars -finline-stringops

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

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

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

[Bug tree-optimization/117226] New: wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu

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

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

Bug ID: 117226
   Summary: wrong code at -O{s,2,3} with "-fno-tree-forwprop" on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

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

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


[518] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241019 (experimental) (GCC) 
[519] % 
[519] % gcctk -O3 small.c; ./a.out
[520] % 
[520] % gcctk -O3 -fno-tree-forwprop small.c
[521] % ./a.out
Aborted
[522] % 
[522] % cat small.c
int a = 128, b, d;
long e = -2, c;
int main() {
  char f = a;
  int g = f;
  c = (g < 0) - e;
  unsigned char h = g;
  b = h % c;
  d = 9 << b;
  if (d > 1)
__builtin_abort();
  return 0;
}

[Bug target/115042] [14/15 Regression] valgrind test fails to compile on armv7

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

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

--- Comment #2 from Sam James  ---
There was also https://dev.gnupg.org/T6892 and https://dev.gnupg.org/T7226.
ofc, it's really (also) a bug in the package, but it's interesting that it came
up in libgcrypt for arm (and x86) too.

[Bug modula2/117228] New: Move modula2 plugin into 'build-gcc/gcc/m2/'

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

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

Bug ID: 117228
   Summary: Move modula2 plugin into 'build-gcc/gcc/m2/'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

I noticed that the modula2 plugin gets built in 'build-gcc/gcc/plugin/' --
should we move it into 'build-gcc/gcc/m2/plugin/'?

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

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Sam James from comment #2)
> Looks like trunk works now?

Maybe r15-3138-ga9f5e23aba1a6f ?

[Bug target/117163] Missing macro to round to nearest floating-point value

[paul at hpkfft dot com via Gcc-bugs]

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

--- Comment #6 from Paul Caprioli  ---
One day, those older compilers will be considered ancient.  Code written using
AVX512 intrinsics isn't the most portable anyway, and programmers are always
able to define their own macros (or just type a 0) if they want to support old
compilers.  A similar situation arises whenever a new feature is added to
GCC--the new thing cannot be used if one wants to support older compilers.

Yes, _MM_FROUND_TO_NEAREST_INT is 0.  So is EXIT_SUCCESS.  Neither one can be
used with _mm512_add_round_ps(a, b, rounding) by someone with a sense of
craftsmanship.

This is the first patch I've submitted to GCC.  I apologize for not knowing the
proper tracking protocol.  If there is anything more I can do, I welcome any
advice, either here or via private email.

Best regards,
Paul

[Bug target/117163] Missing macro to round to nearest floating-point value

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Paul Caprioli from comment #6)
> This is the first patch I've submitted to GCC.  I apologize for not knowing
> the proper tracking protocol.  If there is anything more I can do, I welcome
> any advice, either here or via private email.

See "Pinging patches, Getting patches applied" section of
https://gcc.gnu.org/contribute.html

If you do not receive a response to a patch that you have submitted within two
weeks or so, it may be a good idea to chase it by sending a follow-up e-mail to
the same list(s). Patches can occasionally fall through the cracks. Please be
sure to include a brief summary of the patch and the URL of the entry in the
mailing list archive of the original submission.

[Bug target/113609] EQ/NE comparison between avx512 kmask and -1 can be optimized with kxortest with checking CF.

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #2)
> You will have to provide jcc and setcc patterns to fully handle mode change.

cmov was also missed here, filed PR 117232. I found it via some phiopt
improvement I am working on and noticed pr113609-1.c testcase was failing.

[Bug sanitizer/117233] New: UBSAN should catch undefined behavior in realloc

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 117233
   Summary: UBSAN should catch undefined behavior in realloc
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

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

ISO C 23 § 7.24.3.7 specifies that realloc (ptr, 0), when ptr is non-null, is
"undefined behavior".

It would be very useful if the UBSAN would catch such invocations, because this
corner of realloc's specification is a real portability hassle, cf.
https://sourceware.org/bugzilla/show_bug.cgi?id=12547 .

How to reproduce:
 foo.c 
#include 
#include 
#include 
int main ()
{
  char *p = malloc (200);
  printf ("%p", p);
  errno = 0;
  char *q = realloc (p, 0);
  printf (" %p %d\n", q, errno);
}
===
$ gcc -Wall -fsanitize=undefined -std=gnu23 foo.c
$ ASAN_OPTIONS="abort_on_error=0 allocator_may_return_null=1" ./a.out 
0x1eaa2b0 (nil) 0
$ ASAN_OPTIONS="abort_on_error=0 allocator_may_return_null=0" ./a.out 
0x5a52b0 (nil) 0

Expected: Some error report from UBSAN.

[Bug libstdc++/116754] libstdc++ std::ranges::copy performance issue

[addmlbx at gmail dot com via Gcc-bugs]

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

--- Comment #7 from df fd  ---
I only spotted typo: I've written `can not` instead of `can now`, sorry, my bad

[Bug c/117023] [C2y] Implement N3322, Allow zero length operations on null pointers

[bruno at clisp dot org via Gcc-bugs]

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

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #2 from Bruno Haible  ---
Created attachment 59394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59394&action=edit
test case n3322.c

According to
https://sourceware.org/pipermail/libc-alpha/2024-October/160375.html, N3322 has
been accepted for inclusion in ISO C.

The instrumentation of the following functions therefore should NOT produce
runtime errors or crashes any more:

  bsearch
  qsort
  memccpy
  strndup
  wcsncpy
  wcsncmp
  wcsncat

How to reproduce:
$ gcc -fsanitize=undefined,address -O0 -fno-omit-frame-pointer -ggdb n3322.c
$ ./a.out
n3322.c:25:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:26:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:29:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:30:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:35:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:46:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:47:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:52:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:53:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:54:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:54:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:60:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:61:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
AddressSanitizer:DEADLYSIGNAL
=
==2745541==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x7febd4efef34 bp 0x7ffca7ab7440 sp 0x7ffca7ab6bd8 T0)
==2745541==The signal is caused by a READ memory access.
==2745541==Hint: address points to the zero page.
#0 0x7febd4efef34 in __sanitizer::internal_wcslen(wchar_t const*)
../../../../gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_libc.cpp:288
#1 0x7febd4e710bc in wcsncat
../../../../gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:7093
#2 0x401a97 in main /home/bruno/n3322.c:61
#3 0x7febd45b3d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#4 0x7febd45b3e3f in __libc_start_main_impl ../csu/libc-start.c:392
#5 0x4011a4 in _start (/home/bruno/a.out+0x4011a4)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
../../../../gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_libc.cpp:288 in
__sanitizer::internal_wcslen(wchar_t const*)
==2745541==ABORTING

Dissection of runtime errors:

bsearch:
n3322.c:25:3: runtime error: null pointer passed as argument 2, which is
declared to never be null

qsort:
n3322.c:26:3: runtime error: null pointer passed as argument 1, which is
declared to never be null

memccpy:
n3322.c:29:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:30:3: runtime error: null pointer passed as argument 2, which is
declared to never be null

strndup:
n3322.c:35:3: runtime error: null pointer passed as argument 1, which is
declared to never be null

wcsncpy:
n3322.c:46:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:47:3: runtime error: null pointer passed as argument 2, which is
declared to never be null

wcsncmp:
n3322.c:52:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:53:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:54:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
n3322.c:54:3: runtime error: null pointer passed as argument 2, which is
declared to never be null

wcsncat:
n3322.c:60:3: runtime error: null pointer passed as argument 2, which is
declared to never be null
n3322.c:61:3: runtime error: null pointer passed as argument 1, which is
declared to never be null
and the call to internal_wcslen.

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

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

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

--- Comment #9 from Jerry DeLisle  ---
Created attachment 59395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59395&action=edit
Patch to clean-up dg-do run directives.

This patch cleans up the dg-do run options and adds in a -O option for one test
so it will pass.  I do not want to try modifying the test machinery, but
inline_matmul_1.f90 needs it to pass. Anyone have anu thoughts on this?

[Bug c++/117231] New: Incorrect code generation for std::generator

[winmikedows at hotmail dot com via Gcc-bugs]

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

Bug ID: 117231
   Summary: Incorrect code generation for std::generator
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: winmikedows at hotmail dot com
  Target Milestone: ---

With GCC trunk, the following minimal usage of std::generator results in
incorrect code:
```cpp
#include 
#include 
#include 

std::generator get_seq()
{
std::vector data_{1, 2, 3};
for (auto item : data_)
co_yield item;
}

int main()
{
for (auto item : get_seq())
std::println("{}", item);
}
```
The expected result, and what is outputted by GCC 14.2, is "1 2 3" on three
lines. However, with the GCC trunk, only a single 0 is outputted. See
https://godbolt.org/z/fE1593c9h.

[Bug tree-optimization/117234] New: A few tree codes are marked as trapping when they can't

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

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

Bug ID: 117234
   Summary: A few tree codes are marked as trapping when they
can't
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization, TREE
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
#include 

#define vect4f __attribute__((vector_size(4*sizeof(float

svfloat32_t f(float a)
{
  try {
return svdup_f32(a);
  }  catch(...)
  { __builtin_trap (); }
}

float f1(float a)
{
  try {
return __builtin_assoc_barrier (a);
  }  catch(...)
  { __builtin_trap (); }
}
```

We should be able to remove the catch for this as vec_duplicate_expr is not a
trapping code.

`-O2 -fnon-call-exceptions -march=armv9-a`

[Bug tree-optimization/117235] New: [15 Regression] trapping fp statement can be moved across another trapping fp statement

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

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

Bug ID: 117235
   Summary: [15 Regression] trapping fp statement can be moved
across another trapping fp statement
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: major
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, float b, float c, float d, int x, int y)
{
float e;
float t;
if (a)
{
e = x;
t = c/d;
} else
{
e = y;
t = d/c;
}
return e + t;
}
```

At `-O2 -ftrapping-math`, the conversion from int to fp can moved after the
division.

Noticed while working on improving phiopt.
This was introduced by r15-4503-g8d6d6d537fdc75 . 

The simple fix is is_factor_profitable should return false if the statement can
trap and is not the last statement.
Though the more complex one is not check aliveness and then return false if
another statement can trap but I don't think that will be that profitable
really.

[Bug tree-optimization/117055] [meta-bug] GCC15+ O2 vectorization enhancement

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-19
   Keywords||meta-bug
 Ever confirmed|0   |1
   Target Milestone|--- |15.0

[Bug lto/117201] [15 regression] libqrencode-4.1.1 miscompiled with LTO

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords|needs-bisection |

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

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
Looks like trunk works now?

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #2 from denisc at gcc dot gnu.org ---
Comment on attachment 59393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59393
Simplified testcase

void
f ()
{
  volatile char c[0];
  c[0] = 0;
}

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

denisc at gcc dot gnu.org changed:

   What|Removed |Added

 CC||denisc at gcc dot gnu.org

--- Comment #1 from denisc at gcc dot gnu.org ---
Created attachment 59393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59393&action=edit
Simplified testcase

Very simple testcase

[Bug modula2/117227] New: Missing modula2 plugin dependencies

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

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

Bug ID: 117227
   Summary: Missing modula2 plugin dependencies
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

I like doing incremental GCC builds, which generally works fine (within reason,
of course).

Recently I ran into a case where some GCC diagnostics changes had gone in, and
after that, 'make check-gcc-m2' had ~100 '[-PASS:-]{+FAIL:+}' regressions, due
to:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
during GIMPLE pass: runtime_exception_inevitable
In function ‘_M2_modulusoverflow_fini’:
cc1gm2: internal compiler error: tree check: expected tree that contains
‘identifier’ structure, have ‘function_decl’ in examine_function_decl, at
m2/plugin/m2rte.cc:210
0x21702e5 internal_error(char const*, ...)
[...]/source-gcc/gcc/diagnostic-global-context.cc:517
0x8d5fd9 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
[...]/source-gcc/gcc/tree.cc:9180
0xbcf355 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
[...]/source-gcc/gcc/tree.h:3787
0x7fe496e0cc61 examine_function_decl
[...]/source-gcc/gcc/m2/plugin/m2rte.cc:210
0x7fe496e0cd80 execute
[...]/source-gcc/gcc/m2/plugin/m2rte.cc:271

I noticed that 'build-gcc/gcc/plugin/m2rte.so' had not been rebuilt; after 'rm
build-gcc/gcc/plugin/m2rte.so' plus another incremental 'make' to rebuild the
plugin, these FAILs were back to PASSes.  Therefore, I conclude that there are
some missing modula2 plugin dependencies;
'gcc/m2/Make-lang.in:plugin/m2rte$(soext)' or thereabouts?

[Bug c++/117219] strict aliasing documentation maybe should mention C++20's std::bit_cast

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
We should also mention the modern bit utilities from PR117030 for c2y once
that's implemented.

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop

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

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

--- Comment #1 from Sam James  ---
Bisecting.

[Bug target/117223] New: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117223
   Summary: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx
barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with custom
flags
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

This might need RTL checking enabled.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fnon-call-exceptions -fprofile-generate
-finline-stringops -mstringop-strategy=libcall -fno-tree-coalesce-vars
testcase.c -Wno-psabi
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: RTL check: expected elt 2 type 'B',
have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495
   16 | }
  | ^
0x2c8a8be internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0x8388b7 rtl_check_failed_type1(rtx_def const*, int, int, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:751
0x78341b BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1495
0x786b33 BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4384
0x786b33 set_block_for_insn(rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/rtl.h:1500
0x786b33 add_insn_before(rtx_insn*, rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4379
0x1135bf0 emit_pattern_before_noloc
/repo/gcc-trunk/gcc/emit-rtl.cc:4647
0x1056dfd commit_one_edge_insertion(edge_def*)
/repo/gcc-trunk/gcc/cfgrtl.cc:2106
0x105c121 commit_edge_insertions()
/repo/gcc-trunk/gcc/cfgrtl.cc:2168
0x103c790 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6971
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-r15-4479-20241018160457-g3a12ac40325-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-r15-4479-20241018160457-g3a12ac40325-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241016 (experimental) (GCC)

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce since r15-1901-g98914f9eba5f19

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-19
 Ever confirmed|0   |1

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce

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

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

Sam James  changed:

   What|Removed |Added

Version|unknown |15.0
   Keywords||wrong-code
   Target Milestone|--- |15.0
  Component|tree-optimization   |rtl-optimization
Summary|wrong code at -O{s,2,3} |[15 regression] wrong code
   |with "-fno-tree-forwprop"   |at -O{s,2,3} with
   |on x86_64-linux-gnu |"-fno-tree-forwprop" on
   ||x86_64-linux-gnu with
   ||ext-dce
 CC||law at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Bisected to r15-1901-g98914f9eba5f19.

[Bug modula2/115328] The FORWARD keyword is not implemented

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

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

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

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

commit r15-4497-ge751639e3d20efe97186faa7dca33e7761ba1e79
Author: Gaius Mulley 
Date:   Sat Oct 19 13:30:28 2024 +0100

PR modula2/115328 The FORWARD keyword is not implemented

This patch implements the FORWARD keyword found in the ISO standard.
The patch checks incoming parameters against the prior declaration
found in definition/forward sections and will issue an error based
on virtual tokens highlighing the full parameter declaration.

gcc/m2/ChangeLog:

PR modula2/115328
* gm2-compiler/M2MetaError.def: Extend comment documentating
new format specifiers.
* gm2-compiler/M2MetaError.mod (GetTokProcedure): New declaration.
(doErrorScopeModule): New procedure.
(doErrorScopeForward): Ditto.
(doErrorScopeMod): Reimplement.
(doErrorScopeFor): New procedure.
(declarationMod): Ditto.
(doErrorScopeDefinition): Ditto.
(doErrorScopeDef): Reimplement.
(declaredDef): New procedure.
(declaredFor): Ditto.
(doErrorScopeProc): Ditto.
(declaredVar): Ditto.
(declaredType): Ditto.
(declaredFull): Ditto.
* gm2-compiler/M2Options.mod (SetAutoInit): Add missing
return type.
(GetDumpGimple): Remove duplicate implementation.
* gm2-compiler/M2Quads.def (DupFrame): New procedure.
* gm2-compiler/M2Quads.mod (DupFrame): New procedure.
* gm2-compiler/M2Reserved.def (ForwardTok): New variable.
* gm2-compiler/M2Reserved.mod (ForwardTok): Initialize variable.
* gm2-compiler/M2Scaffold.mod (DeclareArgEnvParams): Add
tokno parameter for call to PutParam.
* gm2-compiler/P0SymBuild.def (EndForward): New procedure.
* gm2-compiler/P0SymBuild.mod (EndForward): New procedure.
* gm2-compiler/P0SyntaxCheck.bnf (BlockAssert): New procedure.
(ProcedureDeclaration): Reimplement rule.
(PostProcedureHeading): New rule.
(ForwardDeclaration): Ditto.
(ProperProcedure): Ditto.
* gm2-compiler/P1Build.bnf (ProcedureDeclaration): Reimplement
rule.
(PostProcedureHeading): New rule.
(ForwardDeclaration): Ditto.
(ProperProcedure): Ditto.
* gm2-compiler/P1SymBuild.def (Export): Removed unnecessary
export.
(EndBuildForward): New procedure.
* gm2-compiler/P1SymBuild.mod (StartBuildProcedure): Reimplement.
(EndBuildProcedure): Ditto.
(EndBuildForward): Ditto.
* gm2-compiler/P2Build.bnf (ProcedureDeclaration): Reimplement
rule.
(PostProcedureHeading): New rule.
(ForwardDeclaration): Ditto.
(ProperProcedure): Ditto.
* gm2-compiler/P2SymBuild.def (BuildProcedureDefinedByForward):
New procedure.
(BuildProcedureDefinedByProper): Ditto.
(CheckProcedure): Ditto.
(EndBuildForward): Ditto.
* gm2-compiler/P2SymBuild.mod (EndBuildProcedure): Reimplement.
(EndBuildForward): New procedure.
(BuildFPSection): Reimplement to allow forward declaration or
checking of parameters.
(BuildProcedureDefinedByProper): New procedure.
(BuildProcedureDefinedByForward): Ditto
(FailParameter): Remove.
(ParameterError): New procedure.
(ParameterMismatch): Ditto.
(EndBuildFormalParameters): Add parameter number check.
(GetComparison): New procedure function.
(GetSourceDesc): Ditto.
(GetCurSrcDesc): Ditto.
(GetDeclared): New procedure.
(ReturnTypeMismatch): Ditto.
(BuildFunction): Reimplement.
(CheckProcedure): New procedure.
(CheckFormalParameterSection): Reimplement using ParameterError.
* gm2-compiler/P3Build.bnf (ProcedureDeclaration): Reimplement
rule.
(PostProcedureHeading): New rule.
(ForwardDeclaration): Ditto.
(ProperProcedure): Ditto.
* gm2-compiler/P3SymBuild.def (Export): Remove unnecessary export.
(EndBuildForward): New procedure.
* gm2-compiler/P3SymBuild.mod (EndBuildForward): New procedure.
* gm2-compiler/PCBuild.bnf (ProcedureDeclaration): Reimplement
rule.
(PostProcedureHeading): New rule.
(ForwardDeclaration): Ditto.
(ProperProcedure): Ditto.
* gm2-compiler/PCSymBuild.def (EndBuildForward): New procedure.
* gm2-compiler/PCSymBuild.mod (EndBuildForward): Ditto.
*

[Bug target/117229] New: "libcpp, c, middle-end: Optimize initializers using #embed in C" vs. GCN '-march=gfx908'

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

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

Bug ID: 117229
   Summary: "libcpp, c, middle-end: Optimize initializers using
#embed in C" vs. GCN '-march=gfx908'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org, jakub at 
gcc dot gnu.org
  Target Milestone: ---
Target: GCN

For '--target=amdgcn-amdhsa', the recent commit
r15-4375-g1844a4aa6615c2252303e70d41bdb18e7c5664c6 "libcpp, c, middle-end:
Optimize initializers using #embed in C" is causing:

PASS: gcc.dg/cpp/embed-1.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/cpp/embed-1.c execution test

PASS: c-c++-common/cpp/embed-1.c  -Wc++-compat  (test for excess errors)
[-PASS:-]{+FAIL:+} c-c++-common/cpp/embed-1.c  -Wc++-compat  execution test

PASS: c-c++-common/cpp/embed-19.c  -Wc++-compat  (test for excess errors)
[-PASS:-]{+FAIL:+} c-c++-common/cpp/embed-19.c  -Wc++-compat  execution
test

PASS: c-c++-common/cpp/embed-2.c  -Wc++-compat  (test for excess errors)
[-PASS:-]{+FAIL:+} c-c++-common/cpp/embed-2.c  -Wc++-compat  execution test

..., but only for '-march=gfx908', but not for '-march=gfx1100'.

Both are using LLVM 15.0.7 tools, in case that should be relevant.

All other C23 '#embed' test cases PASS.

These execution test FAILs are 'GCN Kernel Aborted'; I've not investigated
further.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #4 from denisc at gcc dot gnu.org ---
After IRA we have:
---
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(28){ }u-1(32){ }u-1(34){ }}
;; lr  in  28 [r28] 29 [r29] 32 [__SP_L__] 34 [argL]
;; lr  use 28 [r28] 29 [r29] 32 [__SP_L__] 34 [argL]
;; lr  def
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 0 2 (set (mem/v:QI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [0 c[0]+0 S1 A8])
        (const_int 0 [0])) "a.c":5:8 86 {movqi_insn_split}
     (expr_list:REG_DEAD (reg:QI 29 r29)
        (nil)))
;;  succ:       EXIT [always]  count:1073741824 (estimated locally, freq
1.) (FALLTHRU) a.c:6:1
;; lr  out 28 [r28] 32 [__SP_L__] 34 [argL]
---

We have only one executable insn in test function `a' after IRA:
(insn 5 2 0 2 (set (mem/v:QI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [0 c[0]+0 S1 A8])
        (const_int 0 [0])) "a.c":5:8 86 {movqi_insn_split}
     (expr_list:REG_DEAD (reg:QI 29 r29)
        (nil)))

(reg:HI 28) is a frame pointer register Y or R28,r29 
LRA tries to eliminate frame pointer to stack pointer and uses
TARGET_FRAME_POINTER_REQUIRED hook.

The hook:
static bool
avr_frame_pointer_required_p (void) 
{
  return (cfun->calls_alloca
  || cfun->calls_setjmp
  || cfun->has_nonlocal_label
  || crtl->args.info.has_stack_args
  || get_frame_size () > 0);
}

The hook return `true' because frame size is 0.

After LRA we have:
---
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(32){ }}
;; lr  in  32 [__SP_L__] 33 [__SP_H__]
;; lr  use 32 [__SP_L__] 33 [__SP_H__]
;; lr  def
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 8 2 (set (mem/v:QI (plus:HI (reg/f:HI 32 __SP_L__)
                (const_int 1 [0x1])) [0 c[0]+0 S1 A8])
        (const_int 0 [0])) "a.c":5:8 86 {movqi_insn_split}
     (nil))
;;  succ:       EXIT [always]  count:1073741824 (estimated locally, freq
1.) (FALLTHRU) a.c:6:1
;; lr  out 32 [__SP_L__]
---

insn 5 has a wrong address. AVR can't use (reg/f:HI 32 __SP_L__) as an address
register.

Probably we have two bugs:
1. AVR port assumes that LRA (or reload) can eliminate frame pointer to stack
pointer (if no args and frame size = 0). It's wrong for this testcase;
2. LRA made a wrong elimination (may be because of AVR port have a wrong insn
definition or something else)

[Bug libstdc++/117220] [15 regression] is broken with Clang (stl_iterator.h:1080:42: error: an attribute list cannot appear here)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug libstdc++/117221] Add smoketest for alternative compiler for libstdc++ headers (like CXX_UNDER_TEST)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
I have my own:

$ ls ~/src/gcc/extra_tests/clang-smoke-test/
Makefileatomic.cc constexpr.ofunctional.o  link_string
memory.o  random.cc  ranges.o  srcloc.cc  stdatomic.cc   stop_token.o
all_headers.cc  atomic.o  depr.ccis_same.cclink_string.cc 
net.ccrandom.o   span.cc   srcloc.o   stdatomic.ovariant.cc
all_headers.o   constexpr.cc  functional.cc  is_same.o memory.cc  
net.o ranges.cc  span.ostacktrace.cc  stop_token.cc  variant.o

I just forget to run them.

To add this to the testsuite we'll need DG directive or effective target that
checks whether clang++ is in the PATH and is usable.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #5 from denisc at gcc dot gnu.org ---
(In reply to Georg-Johann Lay from comment #3)
> Maybe this one is related to the fact that LRA doesn't set strict when it is
> in strict-RTL mode?  For example, with your latest test case:
> 
> $avr-gcc foo.c -S -mlra -O1 -mmcu=atmega128 -fdump-rtl-final
> -mlog=legitimate_address_p
> 
> ...
> avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
> reload_completed=0 ra_in_progress=1 (reg_renumber):(r28 ---> r28)
> (plus:HI (reg/f:HI 28 r28)
> (const_int 1 [0x1]))
> 
> avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
> reload_completed=0 ra_in_progress=1 (reg_renumber):(r28 ---> r28)
> (plus:HI (reg/f:HI 28 r28)
> (const_int 1 [0x1]))
> 
> avr_legitimate_address_p[f:reload(322)]: ret=1, mode=QI strict=0
> reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
> (plus:HI (reg/f:HI 32 __SP_L__)
> (const_int 1 [0x1]))
> 
> avr_legitimate_address_p[f:postreload(323)]: ret=1, mode=QI strict=0
> reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
> (plus:HI (reg/f:HI 32 __SP_L__)
> (const_int 1 [0x1]))
> 
> avr_legitimate_address_p[f:split2(327)]: ret=1, mode=QI strict=0
> reload_completed=1 ra_in_progress=0 (reg_renumber):(r32 ---> r32)
> (plus:HI (reg/f:HI 32 __SP_L__)
> (const_int 1 [0x1]))
> 
> ...
> 
> i.e. strict=0 in all calls, and hence the backend returns ret=1 for SP+const
> addresses.

Our messages crossed.
I have to analyze your information.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #6 from denisc at gcc dot gnu.org ---
At least, our main problem is that we have a frame pointer usage without frame
size.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #7 from denisc at gcc dot gnu.org ---
Clarification for simplified test case:
1. frame size is 0 (because a declaration of a local array has a zero size);
2. we have a local variable which can be addressable (althought it have a zero
size)

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
(In reply to Sam James from comment #3)
> (In reply to Sam James from comment #2)
> > [...]
> > I'm very surprised by this as I was under the impression the prange stuff
> > was an initial stub (new class of range) rather than with anything
> > especially wired with it yet -- I must have misread something.
> > 
> 
> (I should say: I thought it was a clone of irange to start with, with
> adaptations planned, rather than - as it really is - already a set of some
> initial diff. impls.)

It is suppose to just be an irange clone ATM, as far as I know. With all
range-op operations now going thru dispatch to prange implementations, its
possible there is a missing operation or slightly different interaction
somewhere. I'll have a look

[Bug libstdc++/117216] wrong sign for complex sqrt(-x-i0) (for targets without C99 math)

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #1 from vincenzo Innocente  ---
sorry last entry in the bug report should have been

innocent@vinmacscreen binary64 % c++ -O3 -march=native sqrt.cpp
-D_GLIBCXX_USE_C99_COMPLEX=0; ./a.out
(-4,-0) (0,2)
4 -3.14159
-0 positive
-0 negative
(1.22465e-16,-2)

to demonstrate the defect for no C99 math

[Bug middle-end/109856] [13 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12) since r13-3596-ge7310e24b1c0ca

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

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

Sam James  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com
Summary|[13 regression] |[13 regression]
   |-Wnull-dereference false|-Wnull-dereference false
   |positive in Emacs itree.c   |positive in Emacs itree.c
   |(regression from GCC 12)|(regression from GCC 12)
   ||since
   ||r13-3596-ge7310e24b1c0ca
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110080,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110249

--- Comment #4 from Sam James  ---
For the original testcase, it broke with r13-3596-ge7310e24b1c0ca (I won't
bother bisecting with the param). It was fixed by r14-4141-gbf6b107e2a3423. I
don't know how backportable that is, unfortunately, but CC'd andrew.

Could you file a new bug for the tar case? These bugs are always highly
dependent on what (missed) optimisation (didn't) happen.

[Bug tree-optimization/117234] A few tree codes are marked as trapping when they can't

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-20
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
I am going to implement this.

Most of the time this does not show up. Either because people use -ffast-math
or these 2 tree codes are less used at this point.

[Bug tree-optimization/117235] [15 Regression] trapping fp statement can be moved across another trapping fp statement since r15-4503-g8d6d6d537fdc75

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 59397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59397&action=edit
Patch which I am testing

Already did a quick test by running `tree-ssa.exp` but I doubt there will be
any regressions.

[Bug c++/117231] [15 regression] Incorrect code generation for std::generator

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Summary|Incorrect code generation   |[15 regression] Incorrect
   |for std::generator  |code generation for
   ||std::generator

[Bug target/117229] [15 regression] "libcpp, c, middle-end: Optimize initializers using #embed in C" vs. GCN '-march=gfx908'

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug tree-optimization/117235] [15 Regression] trapping fp statement can be moved across another trapping fp statement

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Last reconfirmed||2024-10-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-20

--- Comment #7 from Sam James  ---
Thanks Andrew

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

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

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

--- Comment #4 from Sam James  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Sam James from comment #2)
> > Looks like trunk works now?
> 
> Maybe r15-3138-ga9f5e23aba1a6f ?

Let me check.

[Bug middle-end/117236] New: -Wnull-dereference false positive in GNU tar (regression from GCC 12)

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 117236
   Summary: -Wnull-dereference false positive in GNU tar
(regression from GCC 12)
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

[Sam James asked me in Bug 109856, Comment 4 to file a separate bug report for
this test case.]

This is gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) on x86-64. Compile
attachment 55337 with:

gcc -O2 -S -Wnull-dereference w.i

The output is:

w.i: In function ‘_write_volume_label.part.0’:
w.i:9290:30: warning: potential null pointer dereference [-Wnull-dereference]
 9290 |   label->header.typeflag = 'V';
  |   ~~~^
w.i:9290:30: warning: potential null pointer dereference [-Wnull-dereference]

This is a false positive. I don't see the false positive when compiling with
GCC 12; it appears that it was introduced in GCC 13.

[Bug middle-end/109856] [13 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12) since r13-3596-ge7310e24b1c0ca

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #5 from Paul Eggert  ---
(In reply to Sam James from comment #4)
> Could you file a new bug for the tar case?

Sure, filed as new Bug 117236.

[Bug libstdc++/116754] libstdc++ std::ranges::copy performance issue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 13.4 and 14.3, thanks for the report

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

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

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

--- Comment #10 from Andrew Pinski  ---
For aarch64 we could also solve this at the rtl level by simplifying:
(if_then_else:SI (ne (reg:SI 108 [ inputD.4415 ])
(const_int 0 [0]))
(neg:SI (reg:SI 108 [ inputD.4415 ]))
(const_int 0 [0]))

into:
(neg:SI (reg:SI 108 [ inputD.4415 ]))


Trying 2, 38 -> 17:
2: r104:SI=r108:SI
  REG_DEAD r108:SI
   38: cc:CC=cmp(r104:SI,0)
   17: x0:SI={(cc:CC!=0)?-r104:SI:0}
  REG_DEAD cc:CC
  REG_DEAD r104:SI
Failed to match this instruction:
(set (reg/i:SI 0 x0)
(if_then_else:SI (ne (reg:SI 108 [ inputD.4415 ])
(const_int 0 [0]))
(neg:SI (reg:SI 108 [ inputD.4415 ]))
(const_int 0 [0])))

I am going to implement that first and then implement the phiopt change.

[Bug preprocessor/114423] Incorrectly placed caret in the message about expanded _Pragma

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

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

Lewis Hyatt  changed:

   What|Removed |Added

   Keywords|patch   |

--- Comment #5 from Lewis Hyatt  ---
The incorrect caret is fixed for GCC 15. Now it points to the _Pragma token
like other cases. I am leaving the PR open for now, in case we want to circle
back and improve diagnostics for all _Pragmas sometime.

[Bug preprocessor/114423] Incorrectly placed caret in the message about expanded _Pragma

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:65c5bbe1c92f9c08e99d3a37c136f2ef9804a37f

commit r15-4505-g65c5bbe1c92f9c08e99d3a37c136f2ef9804a37f
Author: Lewis Hyatt 
Date:   Fri Mar 22 12:55:27 2024 -0400

diagnostics: libcpp: Improve locations for _Pragma lexing diagnostics
[PR114423]

libcpp is not currently set up to be able to generate valid
locations for tokens lexed from a _Pragma string. Instead, after obtaining
the tokens, it sets their locations all to the location of the _Pragma
operator itself. This makes things like _Pragma("GCC diagnostic") work well
enough, but if any diagnostics are issued during lexing, prior to resetting
the token locations, those diagnostics get issued at the invalid
locations. Fix that up by adding a new field pfile->diagnostic_override_loc
that instructs libcpp to issue diagnostics at the alternate location.

libcpp/ChangeLog:

PR preprocessor/114423
* internal.h (struct cpp_reader): Add DIAGNOSTIC_OVERRIDE_LOC
field.
* directives.cc (destringize_and_run): Set the new field to the
location of the _Pragma operator.
* errors.cc (cpp_diagnostic_at): Support DIAGNOSTIC_OVERRIDE_LOC to
temporarily issue diagnostics at a different location.
(cpp_diagnostic_with_line): Likewise.

gcc/testsuite/ChangeLog:

PR preprocessor/114423
* c-c++-common/cpp/pragma-diagnostic-loc.c: New test.
* c-c++-common/cpp/diagnostic-pragma-1.c: Adjust expected output.
* g++.dg/pch/operator-1.C: Likewise.

[Bug middle-end/109856] [13 regression] -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #3 from Paul Eggert  ---
(In reply to Sam James from comment #2)
> 14 and 15 are fine.
Although GCC 14 is fine with the first attachment, I am still seeing problems
when I compile the second one (attachment 55337) with gcc (GCC) 14.2.1 20240912
(Red Hat 14.2.1-3) on x86-64. I still see the same false positive that I
reported in Comment 1.

[Bug target/117232] New: EQ/NE comparison between avx512 kmask and -1 can be optimized with kxortest with checking CF when using cmov

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

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

Bug ID: 117232
   Summary: EQ/NE comparison between avx512 kmask and -1 can be
optimized with kxortest with checking CF when using
cmov
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

This is expansion of PR 113609 which showed when I improved phiopt's factor
operations to handle more than just 1 operand operations.

New reduced testcase that fails to use kortestw (even without my phiopt
improvements):
```
#include 

int
cmp_vector_je_mask64_t(__m512i a, __m512i b, int c, int d) {
__mmask64 k = _mm512_cmpeq_epi8_mask (a, b);
return k == (__mmask64) -1 ? c : d;
}
```

GCC currently produces:
```
vpcmpb  $0, %zmm1, %zmm0, %k0
kmovq   %k0, %rax
cmpq$-1, %rax
movl%edi, %eax
cmovne  %esi, %eax
ret
```

While LLVM produces:
```
movl%edi, %eax
vpcmpneqd   %zmm1, %zmm0, %k0
kortestw%k0, %k0
cmovnel %esi, %eax
vzeroupper
retq
```

[Bug sanitizer/117233] UBSAN should catch undefined behavior in realloc

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #1 from Bruno Haible  ---
Setting UBSAN_OPTIONS does not appear to have an influence either.

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> Note the loop one looks like:
>   if (input_4(D) != 0)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 105119324]:
>   _1 = (unsigned int) input_4(D);
>   _3 = -_1;
>   value_2 = (int) _3;
> 
>[local count: 118111600]:
>   # value_10 = PHI 
> 
>  CUT 
> Which avoids undefined overflow for INT_MIN.

After r14-4889-g0fc13e8c0e39c5 in phiopt we have:
```
   [local count: 118111600]:
  if (input_3(D) != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]:
  _1 = (unsigned int) input_3(D);
  _7 = -_1;

   [local count: 118111600]:
  # _11 = PHI <_7(3), 0(2)>
```

There are 2 ways of handling this. First is to handle the TODO in
factor_out_conditional_operation:
  /* TODO: handle more than just casts here. */

Which help others. So I think I am going to implement that way.
Once we handle that we will end up with `input_3 != 0 ? input_3 : 0` which then
will then reduce down to just input_3.

So the operations that should be simple to handle are NEGATIVE_EXPR, ABS_EXPR
and ABSU_EXPR. If we only handle those for 0, it should be the safest form. And
could be expanded later on for other values.

Interaction of "general-regs-only" and "interrupt" attributes for arm-none-eabi target

[Christian Schmidt]

Hello everyone,

First of all, I am not sure if this is a bug - or if I am holding it wrong.

I am trying to compile some interrupt handlers marked as such, on a 
platform with hard-float and neon.


The gcc command line for this project is
arm-none-eabi-gcc -std=gnu23 -O2 -Wall -Werror -Wextra -Wpedantic 
-Wshadow -pipe -mcpu=cortex-a5 -mfpu=vfpv4-d16 -mfloat-abi=hard 
-ffunction-sections -fdata-sections -flto


and the code that I am trying to compile, for its various variations 
(note that the "used" attribute is only here to suppress extra warnings 
about unused functions that are not related to the behavior in question, 
and are not there in the actual code):


Line 1:
static void __attribute__ ((used,interrupt("IRQ"))) irq_1 (void) { }
This line is supposed to fail since there is hard-float and NEON 
extensions - and it does:
general-regs-only.c:1:1: error: FP registers might be clobbered despite 
'interrupt' attribute: compile with '-mgeneral-regs-only' 
[-Werror=attributes]


So, in line 2, let's do as suggested (for this one function):
static void __attribute__ 
((used,target("general-regs-only"),interrupt("IRQ"))) irq_2 (void) { }
general-regs-only.c:2:1: error: FP registers might be clobbered despite 
'interrupt' attribute: compile with '-mgeneral-regs-only' 
[-Werror=attributes]


It's not working. Let's switch order for line 3:
static void __attribute__ 
((used,interrupt("IRQ"),target("general-regs-only"))) irq_3 (void) { }
This compiles, but only as long as line 2 exists. If line 2 is commented 
out, it fails all the same.


static void __attribute__ ((used,general-regs-only,interrupt("IRQ"))) 
irq_4 (void) { }

general-regs-only.c:4:41: error: expected ')' before '-' token
general-regs-only.c:4:69: error: expected identifier or '(' before ')' token

This is more of a documentation error. The documentation at 
https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html mentions 
this attribute first thing on the page, and it is invalid, and has to be 
shoved through target("general-regs-only") instead (maybe? but it still 
does not work as expected).


I can, in order to compile, successfully use a pragma:

#pragma GCC push_options
#pragma GCC target("general-regs-only")
static void __attribute__ ((used,interrupt("IRQ"))) irq_5 (void) { }
#pragma GCC pop_options

But I'd say attributes should work. The dependency in the example of 
failing in line 2, but then succeeding in line 3 - if, and only if, line 
2 is active - seems to indicate to me that the attribute is attached to 
the wrong function, either for the purpose of checking, for assembly 
generation, or both.


The identical behavior is experienced with
arm-none-eabi-gcc-14 (Gentoo 14.2.1_p20240921 p1) 14.2.1 20240921
arm-none-eabi-gcc-15 (Gentoo 15.0.0_pre20241006 p15) 15.0.0 20241006 
(experimental)
Older version do not support sufficient parts of the C23 standard for my 
codebase.


I have attached the four lines of test source to be compiled with
arm-none-eabi-gcc -std=gnu23 -O2 -Wall -Werror -Wextra -Wpedantic 
-Wshadow -pipe -mcpu=cortex-a5 -mfpu=vfpv4-d16 -mfloat-abi=hard 
-ffunction-sections -fdata-sections -flto -c -o general-regs-only.o 
general-regs-only.c

for reproduction.

Am I just holding it wrong, or is this worth being posted to the bug 
tracker?


Best regards,
Chrisstatic void __attribute__ ((used,interrupt("IRQ"))) irq_1 (void) { }
static void __attribute__ ((used,target("general-regs-only"),interrupt("IRQ"))) irq_2 (void) { }
static void __attribute__ ((used,interrupt("IRQ"),target("general-regs-only"))) irq_3 (void) { }
static void __attribute__ ((used,general-regs-only,interrupt("IRQ"))) irq_4 (void) { }

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Jerry DeLisle  ---
Regarding comments #1 and #2, there is no difference between using the C or the
! 

Regarding "dg-do  run" with two spaces vs. "dg-do run" with one space, I used a
simple bash script with sed to change all these to single spaces.  The result
is more test variations are run on about 83 of the affected cases. One of the
test cases, inline_matmul_1.f90 fails one test. This failue is avoided by add
-O at the end of the options.

diff --git a/gcc/testsuite/gfortran.dg/inline_matmul_1.f90
b/gcc/testsuite/gfortran.dg/inline_matmul_1.f90
index b0d5a037b4f..9c241fd12d4 100644
--- a/gcc/testsuite/gfortran.dg/inline_matmul_1.f90
+++ b/gcc/testsuite/gfortran.dg/inline_matmul_1.f90
@@ -1,5 +1,5 @@
-! { dg-do  run }
-! { dg-options "-ffrontend-optimize -fdump-tree-optimized -Wrealloc-lhs" }
+! { dg-do run }
+! { dg-options "-ffrontend-optimize -fdump-tree-optimized -Wrealloc-lhs -O" }
 ! PR 37131 - check basic functionality of inlined matmul, making
 ! sure that the library is not called, with and without reallocation.

[Bug c/117023] [C2y] Implement N3322, Allow zero length operations on null pointers

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #3 from Bruno Haible  ---
The runtime errors regarding bsearch, qsort, memccpy, wcsncpy, wcsncmp, wcsncat
need to be fixed in the glibc header files.

However, the runtime error regarding strndup and the crash in wcsncat come from
GCC proper.

[Bug tree-optimization/64700] Sink common code through PHI

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> +FAIL: gcc.target/i386/pr113609-1.c scan-assembler-times kortest 17
> +FAIL: gcc.target/i386/pr113609-2.c scan-assembler-times [ t]+je 4
> +FAIL: gcc.target/i386/pr113609-2.c scan-assembler-times [ t]+sete 4
> 
> This needs to be looked more into but I think it is just a testcase issue.

PR 117232 for the missed optimization part (kortest). The je/sete scan will be
a testcase issue which I will update in the new patch.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #8 from Segher Boessenkool  ---
(In reply to denisc from comment #2)
> Comment on attachment 59393 [details]
> Simplified testcase
> 
> void
> f ()
> {
>   volatile char c[0];
>   c[0] = 0;
> }

That is invalid C code, of course (an out of bounds access).