[Bug tree-optimization/117572] Missing optimization after SCCP due to rewriting for overflow

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> probably.  You should be able to write small testcases doing the integer
> conversions manually btw.

Simplified testcase then:
```
typedef __SIZE_TYPE__ size_t;
extern char o[3];
extern char p[11];
char* f(void)
{
  size_t t = (size_t)&o[0];
  t += (size_t)&p[2];
  t -= (size_t)&p;
  return (char*)t;
}
```

LLVM is able to optimize this to just `&o[2];`.

[Bug middle-end/105654] transparent_union, function pointer and different types arguments causes null pointer to be passed

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

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

--- Comment #7 from Andrew Pinski  ---
```
...
get_bool(_Bool *out);

union __attribute__((transparent_union)) some_pointer {
void *as_void_ptr;
_Bool* as_bool_ptr;
};

void generic_get(union some_pointer);

static typeof(generic_get) *get =
get_bool;
...
(*get)(&value);  // call through function pointer
```

I am not sure this is defined code at all. Even though the argument passing
between the 2 function types are defined to be the same; the union and pointer
are 2 different types and GCC considers that to true.

I think strongswan needs to remove this kind of hacks. And just use `void*` as
the argument type and then cast it to the correct type inside the function.

[Bug demangler/117578] demangler does not handle large mangled string sometimes

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|cxa_demangle cannot deal|demangler does not handle
   |with long names |large mangled string
   ||sometimes
   Last reconfirmed||2024-11-14
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|libstdc++   |demangler

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

[Bug target/117580] New: [meta-bug] Tagets should have a defined _BitInt ABI and implement that ABI

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

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

Bug ID: 117580
   Summary: [meta-bug] Tagets should have a defined _BitInt ABI
and implement that ABI
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Depends on: 115393
Blocks: 102989
  Target Milestone: ---

Instead of recording the targets support work in PR 102989, link against this
bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
[Bug 102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115393
[Bug 115393] MIPS: implement _BitInt of C23

[Bug target/117581] New: Riscv support for _BitInt

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

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

Bug ID: 117581
   Summary: Riscv support for _BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: riscv

Riscv ABI needs to be defined, see
 for that. And
then support needs to be added to the backend.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117582] New: arm implementation of _BitInt

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

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

Bug ID: 117582
   Summary: arm implementation of _BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: arm*-*-*

The ABI has been defined just not the implementation has been done for arm.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug tree-optimization/117601] Another missing optimization after rewrite of SCCP for overflow

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

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

--- Comment #2 from Andrew Pinski  ---
looking into this slightly more, there needs to have a check on INTEGER_CST@1
if less than the size of the array if o is an array. (otherwise only allow 1).

[Bug tree-optimization/115771] [12/13/14 regression] false positive -Wstringop-overread with -O2

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Sam James from comment #3)
> > Fixed by r15-571-g1e0ae1f52741f7 on trunk which definitely isn't
> > backportable.
> > 
> > Some additional notes:
> > * 8.5.0 works, 9.1.0 doesn't (broken by r9-5549-g8f10fb5065db28)
> > * 10.2 works, 10.3 doesn't (broken by r10-9646-g42c22a4d724b4a)
> > 
> > Not bisected for why 10.2 works and doubt it's worth bothering.
> 
> The reason why GCC 10.1.0/10.2.0 worked was due to the same reason why it
> was broken by r10-9646 (or rather why PR 98265 regressed), that is inlining
> changes.

Plus:
>* 8.5.0 works, 9.1.0 doesn't (broken by r9-5549-g8f10fb5065db28)

Most likely changed inlining too.

[Bug target/117604] RISCV Generalized Reverse (grev, grevi, rev) are not supported in gcc-14.1.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>Assembler messages:
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share/rvintrin.h:151:
Error: unrecognized opcode `greviw t3,t3,24'

This error message is from the assembler. GCC does not directly contain the
assembler, you need to report this to binutils since I suspect you got the
assembler from there.  (https://sourceware.org/bugzilla/ ).

[Bug target/117604] RISCV Generalized Reverse (grev, grevi, rev) are not supported in gcc-14.1.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|MOVED   |INVALID

--- Comment #2 from Andrew Pinski  ---
> in bit manipulation manual riscv-bitmanip-1.0.0.pdf Generalized Reverse is 
> not described but in previous versions like 0.92 described in details 

Actually if it was removed from the spec 1.0, then it was implemented when the
zbc extension was added to binutils in the end. GNU binutils only implemented
the 1.0 spec.

[Bug libgcc/117600] New: [15 regression] libgcc arm build doesn't respect --disable-werror

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

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

Bug ID: 117600
   Summary: [15 regression] libgcc arm build doesn't respect
--disable-werror
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: clyon at gcc dot gnu.org
  Target Milestone: ---

See PR117537 which of course was a valuable find, but --disable-werror is
(especially) useful when bisecting with newer compilers in the future.

[Bug libgcc/117537] [15 regression] Failed cross build for aarch64_be-unknown-linux-gnu (libgcc/config/libbid/bid_conf.h:847:25: error: missing braces around initializer [-Werror=missing-braces])

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

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

--- Comment #5 from Sam James  ---
Thank you for the quick fix!

[Bug tree-optimization/117601] New: Another missing optimization after rewrite of SCCP for overflow

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

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

Bug ID: 117601
   Summary: Another missing optimization after rewrite of SCCP for
overflow
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

>From looking at PR 117572, after a quick hack to match to do simple
reassociation with respect to pointer addition/minus, there is still some stuff
to optimize:
```
  _386 = (sizetype) &o;
  _390 = _386 + 2;
  h_391 = (char *) _390;
  h_392 = h_391 + 1;
  _394 = h_392 - &o;
  _395 = (int) _394;
```

Seems like h_391 could be optimized to just:
`&o p+ 2 ` . 
Which means _395 is just 3.

That is this:
```
typedef __SIZE_TYPE__ size_t;
extern char o[3];
int f(void)
{
  size_t t = (size_t)&o[0];
  t += 2;
  char *t1 = (char*)t;
  t1 += 1;
  return t1 - &o[0];
}
```

Which does get optimized to 3 at the RTL level

[Bug tree-optimization/117572] Missing optimization after SCCP due to rewriting for overflow

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

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

--- Comment #3 from Andrew Pinski  ---
After adding a hack like:
```
(simplify
 (minus (plus:c @2 (convert ADDR_EXPR@0)) (convert @1))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @1, &diff))
(plus @2 { build_int_cst_type (type, diff); })
(simplify
 (minus (plus:c @2 (convert @0)) (convert ADDR_EXPR@1))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with { poly_int64 diff; }
   (if (ptr_difference_const (@0, @1, &diff))
(plus @2 { build_int_cst_type (type, diff); })
```


For the original testcase we get:
```
  _386 = (sizetype) &o;
  _390 = _386 + 2;
  h_391 = (char *) _390;
  h_392 = h_391 + 1;
  _394 = h_392 - &o;
  _395 = (int) _394;
```

Seems like h_391 could be optimized to just:
`&o p+ 2 ` . 
Which means _395 is just 3.

Filed that as PR 117601.

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4

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

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

--- Comment #7 from Sam James  ---
For completeness: 9 started with r9-2287-g47ca20b4f69986 (i.e. we got better at
optimising and exposed it).

[Bug target/117603] New: RISC-V: testsuite: Architecture string mutation is not robust

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

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

Bug ID: 117603
   Summary: RISC-V: testsuite: Architecture string mutation is not
robust
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitar at gcc dot gnu.org
  Target Milestone: ---

The DejaGnu routine "add_options_for_riscv_v" erroneously strips the "e"
architecture modifier when it mutates the architecture string to add vector
extensions.  This results in spurious test case failures like:
  FAIL: gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c (test
for excess errors)
  Excess errors:
  xgcc: error: '-march=rv32cv': first ISA subset must be 'e', 'i' or 'g'

GCC has been configured for RV32EC with:
  ./configure \
  --target=riscv32-none-elf   \
  --with-multilib-generator="rv32ec-ilp32e--" \
  --with-abi=ilp32e   \
  --with-arch=rv32ec

[Bug tree-optimization/115771] [12/13/14 regression] false positive -Wstringop-overread with -O2

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> Fixed by r15-571-g1e0ae1f52741f7 on trunk which definitely isn't
> backportable.
> 
> Some additional notes:
> * 8.5.0 works, 9.1.0 doesn't (broken by r9-5549-g8f10fb5065db28)
> * 10.2 works, 10.3 doesn't (broken by r10-9646-g42c22a4d724b4a)
> 
> Not bisected for why 10.2 works and doubt it's worth bothering.

The reason why GCC 10.1.0/10.2.0 worked was due to the same reason why it was
broken by r10-9646 (or rather why PR 98265 regressed), that is inlining
changes.

[Bug tree-optimization/115771] [12/13/14 regression] false positive -Wstringop-overread with -O2

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |needs-testcase
 Ever confirmed|0   |1
  Known to work||8.5.0
  Known to fail||14.2.1, 9.1.0
Summary|false postiv|[12/13/14 regression] false
   |-Wstringop-overread with|positive
   |-O2 |-Wstringop-overread with
   ||-O2
 CC||sjames at gcc dot gnu.org
   Target Milestone|--- |12.5
   Last reconfirmed||2024-11-15

--- Comment #3 from Sam James  ---
Fixed by r15-571-g1e0ae1f52741f7 on trunk which definitely isn't backportable.

Some additional notes:
* 8.5.0 works, 9.1.0 doesn't (broken by r9-5549-g8f10fb5065db28)
* 10.2 works, 10.3 doesn't (broken by r10-9646-g42c22a4d724b4a)

Not bisected for why 10.2 works and doubt it's worth bothering.

Likely adding a testcase for?

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #35 from Sam James  ---
Reverted again in r15-5280-g72677e1119dc40.

[Bug target/117585] New: IA64 BitInt support

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

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

Bug ID: 117585
   Summary: IA64 BitInt support
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: ia64

I doubt there will be an update to the IA64 ABI but maybe someone will handle
adding the support


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #117 from Andrew Pinski  ---
Note I am opening a bug report per target for BitInt support and linking to PR
117580 . e.g. PR 117581 for RISCV, PR 117582 for arm, PR 117583 for big-endian
aarch64 and PR 117584 for PPC.

I think this bug report should be closed as fixed for GCC 14 then.

[Bug target/117584] New: PowerPC ABI for BitInt needs to be done

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

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

Bug ID: 117584
   Summary: PowerPC ABI for BitInt needs to be done
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: powerpc*-*

PowerPC (32bit, 64bit v1 or v2) does not define a BitInt ABI nor have an
implementation


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117583] New: big-endian aarch64 BitInt support

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

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

Bug ID: 117583
   Summary: big-endian aarch64 BitInt support
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: aarch64

The ABI is defined just currently aarch64_bitint_type_info does:
  if (TARGET_BIG_END)
return false;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r15-5295-gf70c1d517e09c4dde421774a8cec591ca3c479a0
Author: Harald Anlauf 
Date:   Thu Nov 14 21:38:04 2024 +0100

Fortran: fix passing of NULL() actual argument to character dummy
[PR104819]

Ensure that character length is set and passed by the call to a procedure
when its dummy argument is NULL() with MOLD argument present, or set length
to either 0 or the callee's expected character length.  For assumed-rank
dummies, use the rank of the MOLD argument.  Generate temporaries for
passed arguments when needed.

PR fortran/104819

gcc/fortran/ChangeLog:

* trans-expr.cc (conv_null_actual): Helper function to handle
passing of NULL() to non-optional dummy arguments of non-bind(c)
procedures.
(gfc_conv_procedure_call): Use it for character dummies.

gcc/testsuite/ChangeLog:

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

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4

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

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

Sam James  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |Miscompile with -O2/3 and   |Miscompile with -O2/3 and
   |-O0/1   |-O0/1 since
   ||r6-4133-ga8fc25795155d4
   Keywords|needs-bisection |
 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Sam James  ---
Started with r6-4133-ga8fc25795155d4.

[Bug target/117595] New: ICE: SIGSEGV in mark_jump_label_1 (jump.cc:1051) with -mbig-endian and _Atomic enum

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117595
   Summary: ICE: SIGSEGV in mark_jump_label_1 (jump.cc:1051) with
-mbig-endian and _Atomic enum
   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: riscv64-unknown-linux-gnu

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

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -mbig-endian testcase.c -wrapper
valgrind,-q,--num-callers=100
==25540== Invalid read of size 1
==25540==at 0x1599FAC: mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
(jump.cc:1051)
==25540==by 0x159A136: mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
(jump.cc:1180)
==25540==by 0x159A081: mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
(jump.cc:1174)
==25540==by 0x159A136: mark_jump_label_1(rtx_def*, rtx_insn*, bool, bool)
(jump.cc:1180)
==25540==by 0x159AA6C: mark_all_labels (jump.cc:335)
==25540==by 0x159AA6C: rebuild_jump_labels_1(rtx_insn*, bool) (jump.cc:74)
==25540==by 0x1239581: (anonymous
namespace)::pass_expand::execute(function*) (cfgexpand.cc:6961)
==25540==by 0x16935DA: execute_one_pass(opt_pass*) (passes.cc:2660)
==25540==by 0x1693ECF: execute_pass_list_1(opt_pass*) (passes.cc:2769)
==25540==by 0x1693F08: execute_pass_list(function*, opt_pass*)
(passes.cc:2780)
==25540==by 0x127B135: expand (cgraphunit.cc:1846)
==25540==by 0x127B135: cgraph_node::expand() (cgraphunit.cc:1799)
==25540==by 0x127C049: output_in_order (cgraphunit.cc:2196)
==25540==by 0x127C049: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2402)
==25540==by 0x127EFF7: compile (cgraphunit.cc:2316)
==25540==by 0x127EFF7: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2590)
==25540==by 0x17D8262: compile_file() (toplev.cc:480)
==25540==by 0x10687BE: do_compile (toplev.cc:2211)
==25540==by 0x10687BE: toplev::main(int, char**) (toplev.cc:2371)
==25540==by 0x106A97A: main (main.cc:39)
==25540==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==25540== 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:2:19: internal compiler error: Segmentation fault
2 | void foo() { e++; }
  |   ^
0x33d881e internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0x17d7bdf crash_signal
/repo/gcc-trunk/gcc/toplev.cc:323
0x1599fac mark_jump_label_1
/repo/gcc-trunk/gcc/jump.cc:1051
0x159a136 mark_jump_label_1
/repo/gcc-trunk/gcc/jump.cc:1180
0x159a081 mark_jump_label_1
/repo/gcc-trunk/gcc/jump.cc:1174
0x159a136 mark_jump_label_1
/repo/gcc-trunk/gcc/jump.cc:1180
0x159aa6c mark_all_labels
/repo/gcc-trunk/gcc/jump.cc:335
0x159aa6c rebuild_jump_labels_1
/repo/gcc-trunk/gcc/jump.cc:74
0x1239581 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6961
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1

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

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

--- Comment #3 from Sam James  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
> 
> You can hit the bug in GCC 7/8 by `s/c = 1/c = -1/`.

I don't see it with 7.4.1 20191114 when bisecting with either of the files.

/tmp/a.c:
```
int printf(const char *, ...);
int a, c;
long b;
short d;
long e(long f, long h, long i) {
  for (long g = f; g <= h; g += i)
b += g;
  return b;
}
int main() {
  c = 1;
  for (; c >= 0; c--)
;
  for (; e(d + 40, d + 76, c + 51) < 4;)
;
  printf("%X\n", a);
}
``

/tmp/a2.c:
```
int printf(const char *, ...);
int a, c;
long b;
short d;
long e(long f, long h, long i) {
  for (long g = f; g <= h; g += i)
b += g;
  return b;
}
int main() {
  c = -1;
  for (; c >= 0; c--)
;
  for (; e(d + 40, d + 76, c + 51) < 4;)
;
  printf("%X\n", a);
}
```

```
$ /tmp/gcc-pfx/bin/gcc /tmp/a.c -o /tmp/a -O2 -fwrapv && /tmp/a
0
$ /tmp/gcc-pfx/bin/gcc /tmp/a2.c -o /tmp/a -O2 -fwrapv && /tmp/a
0
```

What am I missing?

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Ivan Zrno from comment #3)
> (In reply to Ivan Zrno from comment #2)
> > Created attachment 59601 [details]
> > example project cmake and main.cpp
> 
> I have attached a simple CMakeLists.txt and main.cpp file. When executing a
> clean CMake build (compile and link) then no .su file is generated.

looks like this is a cmake issue where  -fstack-usage is not done on the link.
I showed you directly how it works with gcc commands, it is not for us to
figure out how cmake (badly) works.

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

[ivan.zrno2 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ivan Zrno  ---
(In reply to Ivan Zrno from comment #2)
> Created attachment 59601 [details]
> example project cmake and main.cpp

I have attached a simple CMakeLists.txt and main.cpp file. When executing a
clean CMake build (compile and link) then no .su file is generated.

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

[ivan.zrno2 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ivan Zrno  ---
Created attachment 59601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59601&action=edit
example project cmake and main.cpp

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

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

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

--- Comment #5 from Sam James  ---
```
/usr/bin/cmake -S/tmp/files -B/tmp/files --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /tmp/files/CMakeFiles
/tmp/files//CMakeFiles/progress.marks
make  -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/tmp/files'
make  -f CMakeFiles/MyProgram.dir/build.make CMakeFiles/MyProgram.dir/depend
make[2]: Entering directory '/tmp/files'
cd /tmp/files && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/files
/tmp/files /tmp/files /tmp/files
/tmp/files/CMakeFiles/MyProgram.dir/DependInfo.cmake "--color="
make[2]: Leaving directory '/tmp/files'
make  -f CMakeFiles/MyProgram.dir/build.make CMakeFiles/MyProgram.dir/build
make[2]: Entering directory '/tmp/files'
[ 50%] Building CXX object CMakeFiles/MyProgram.dir/main.cpp.o
/usr/bin/c++   -fstack-usage -flto -MD -MT CMakeFiles/MyProgram.dir/main.cpp.o
-MF CMakeFiles/MyProgram.dir/main.cpp.o.d -o
CMakeFiles/MyProgram.dir/main.cpp.o -c /tmp/files/main.cpp
[100%] Linking CXX executable MyProgram
/usr/bin/cmake -E cmake_link_script CMakeFiles/MyProgram.dir/link.txt
--verbose=1
/usr/bin/c++ -Wl,--dependency-file,CMakeFiles/MyProgram.dir/link.d
CMakeFiles/MyProgram.dir/main.cpp.o -o MyProgram
make[2]: Leaving directory '/tmp/files'
[100%] Built target MyProgram
make[1]: Leaving directory '/tmp/files'
/usr/bin/cmake -E cmake_progress_start /tmp/files/CMakeFiles 0
```

pinskia is right. It doesn't pass -fstack-usage again. This is wrong. If I pass
that in, it works.

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> ```
> $ /tmp/gcc-pfx/bin/gcc /tmp/a.c -o /tmp/a -O2 -fwrapv && /tmp/a
> 0
> $ /tmp/gcc-pfx/bin/gcc /tmp/a2.c -o /tmp/a -O2 -fwrapv && /tmp/a
> 0
> ```
> 
> What am I missing?

I was just testing with `-O3` (and not -fwrapv). And that failed in GCC 7.4.0.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

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

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

--- Comment #38 from Andrew Pinski  ---
Hmm, something changed in GCC 14  The original testcase now works so does
the testcase in PR 93105 .

[Bug c++/117602] New: bogus error with nested lambda

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

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

Bug ID: 117602
   Summary: bogus error with nested lambda
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This should compile in C++20:

```
void
g ()
{
  [&](decltype([&](decltype([=](decltype([&](decltype([&]() {})) {})) {}))
{})){};
  [&](decltype([&](decltype([&](decltype([&](decltype([&]() {})) {})) {}))
{})){};
  [=](decltype([=](decltype([=](decltype([=](decltype([&]() {})) {})) {}))
{})){};
}
```

but we say:
error: non-local lambda expression cannot have a capture-default

[Bug target/117603] RISC-V: testsuite: Architecture string mutation is not robust

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

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

Dimitar Dimitrov  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||RISC-V
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dimitar at gcc dot 
gnu.org
   Last reconfirmed||2024-11-15

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Denis Chertykov :

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

commit r15-5293-gfe1486e118d72d660284af43cb739e20d094b585
Author: Denis Chertykov 
Date:   Fri Nov 15 00:50:36 2024 +0400

The fix for PR117191

Wrong code appears after dse2 pass because it removes necessary insns.
(ie insn 554 - store to frame spill slot)
This happened because LRA pass doesn't cleanup the code exactly like reload
does.
The reload1.c has a special pass for such cleanup.
The reload removes CLOBBER insns with spill slots like this:
(insn 202 184 186 7 (clobber (mem/c:TI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [3 %sfp+1 S16 A8])) -1
 (nil))

Fragment from reload1.c:
   

  reload_completed = 1;

  /* Make a pass over all the insns and delete all USEs which we inserted
 only to tag a REG_EQUAL note on them.  Remove all REG_DEAD and
REG_UNUSED
 notes.  Delete all CLOBBER insns, except those that refer to the
return
 value and the special mem:BLK CLOBBERs added to prevent the scheduler
 from misarranging variable-array code, and simplify (subreg (reg))
 operands.  Strip and regenerate REG_INC notes that may have been moved
 around.  */

  for (insn = first; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
  {
rtx *pnote;

if (CALL_P (insn))
  replace_pseudos_in (& CALL_INSN_FUNCTION_USAGE (insn),
  VOIDmode, CALL_INSN_FUNCTION_USAGE (insn));

if ((GET_CODE (PATTERN (insn)) == USE
 /* We mark with QImode USEs introduced by reload itself.  */
 && (GET_MODE (insn) == QImode
 || find_reg_note (insn, REG_EQUAL, NULL_RTX)))
|| (GET_CODE (PATTERN (insn)) == CLOBBER
&& (!MEM_P (XEXP (PATTERN (insn), 0))
|| GET_MODE (XEXP (PATTERN (insn), 0)) != BLKmode
|| (GET_CODE (XEXP (XEXP (PATTERN (insn), 0), 0)) !=
SCRATCH
&& XEXP (XEXP (PATTERN (insn), 0), 0)
!= stack_pointer_rtx))
&& (!REG_P (XEXP (PATTERN (insn), 0))
|| ! REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0)
  {
delete_insn (insn);
continue;
  }
   


LRA have a similar place where it removes unnecessary insns, but not
CLOBBER insns with
memory spill slots. It's `lra_final_code_change' function.

I just mark a CLOBBER insn with pseudo spilled to memory for removing it
later together
with LRA temporary CLOBBER insns.

PR rtl-optimization/117191
gcc/
* lra-spills.cc (spill_pseudos): Mark a CLOBBER insn with pseudo
spilled to memory for removing it later together with LRA temporary
CLOBBER insns.

[Bug fortran/107067] [OpenMP] ICE with metadirective block statements

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

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||ice-on-invalid-code

--- Comment #2 from Tobias Burnus  ---
I concur that it is invalid:

* 'parallel' implies that a structured block must follow
  (And begin/end metadirective also implies that something with an
end-directive
   must follow, e.g. a structured block or something else delimited by the
   directive [like 'begin declare variant/target' or 'begin assumes' in
C/C++].)

* BLOCK as first (executable) statement implies that it is a
  "strictly structured block", where the end-directive is optional but
  must immediately follow the END BLOCK.

(In between it was not properly specified, but as 5.1 permits BLOCK and defined
'strictly-structured block' - and has this definition, we seemingly found it
before and not after the release.)

[Bug target/117594] New: [15] RISC-V: Miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117594
   Summary: [15] RISC-V: Miscompile at -O3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
unsigned a;
short b, d, e;
long long c;
int main() {
  short h = d;
  short *z = &h;
  for (_Bool i = 0; i < 1; i = 1)
for (unsigned j = 0; j < (z[i] ?: 10); j += 3) {
  a -= 9;
  b -= ~e;
}
  __builtin_printf("%u\n", a);
}

Commands:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -O3 red.c -o user-config.out -fno-strict-aliasing
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve32x=true,zve64d=true,zve64f=true,zve64x=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 
> user-config.out
0

> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -O2 red.c -o user-config.out -fno-strict-aliasing
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve32x=true,zve64d=true,zve64f=true,zve64x=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 
> user-config.out
4294967260

Found via fuzzer

[Bug target/117594] [15] RISC-V: Miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Testcase that doesn't underflow:
unsigned a;
short b, d, e;
long long c;
int main() {
  short h = d;
  short *z = &h;
  for (_Bool i = 0; i < 1; i = 1)
for (unsigned j = 0; j < (z[i] ?: 10); j += 3) {
  a += 9;
  b -= ~e;
}
  __builtin_printf("%u\n", a);
}

> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -O2 red.c -o user-config.out -fno-strict-aliasing
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve32x=true,zve64d=true,zve64f=true,zve64x=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 
> user-config.out
36

[Bug target/117599] New: LoongArch support for BitInt

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

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

Bug ID: 117599
   Summary: LoongArch support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

The ABI needs to be defined:
https://github.com/loongson/la-abi-specs/issues/13.

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

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #8 from Sam James  ---
Assigning based on
https://inbox.sourceware.org/gcc-patches/6017e9f1-0e5d-4261-97e5-238442bb4...@gmail.com/.

[Bug target/117604] New: RISCV Generalized Reverse (grev, grevi, rev) are not supported in gcc-14.1.0

[akhilesh.k at samsung dot com via Gcc-bugs]

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

Bug ID: 117604
   Summary: RISCV Generalized Reverse (grev, grevi, rev) are not
supported in gcc-14.1.0
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

During bit manipulation verification I observed grevw, greviw instructions are
not unimplemented.

https://raw.githubusercontent.com/riscv/riscv-bitmanip/master/bitmanip-draft.pdf

Seems Generalized Reverse (grev, grevi, rev) are not supported in gcc-14.1.0 

in bit manipulation manual riscv-bitmanip-1.0.0.pdf Generalized Reverse is not
described but in previous versions like 0.92 described in details 

Is Generalized Reverse feature under development or dropped ?

I am using gcc-14.1 release and used https://github.com/riscv/riscv-crypto
performance tool for  bit manipulation.



/home/akhilesh.k/Toolchains/vd/gcc-14//bin/riscv64-none-linux-gnu-gcc -Wall
-I/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include
-I/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share
-O3 -march=rv64gcvzba_zbb_zbc_zbs_zknd_zkne_zksed_zknh_zbkb  -mabi=lp64d
-D__ZSCRYPTO=1 -c -o
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/obj/sm3/reference/sm3.o
sm3/reference/sm3.c
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share/rvintrin.h:
Assembler messages:
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share/rvintrin.h:151:
Error: unrecognized opcode `greviw t3,t3,24'
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share/rvintrin.h:151:
Error: unrecognized opcode `greviw t4,t4,24'
/home/akhilesh.k/git/riscv-crypto/build/benchmarks/rv64-zscrypto/include/riscvcrypto/share/rvintrin.h:151:
Error: unrecognized opcode `greviw t3,t3,24'

[Bug target/52517] Bug in PPC pointer arithmetic

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

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

--- Comment #3 from Andrew Pinski  ---
```
by the equivalent
M = ((unsigned long*)(B))[x/4];
```

Note that is not equivalent and would cause this to be undefined. 

Only `M = *(unsigned long*)(B + x);` is well defined.

[Bug c++/117602] bogus error with nested lambda

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/117602] bogus error with nested lambda

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Marek Polacek  ---
Started with r9-2543-g774fb6c4eb205e.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

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

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

--- Comment #39 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #38)
> Hmm, something changed in GCC 14  The original testcase now works so
> does the testcase in PR 93105 .

Oh it was the fix for PR 113255 .

[Bug tree-optimization/117601] Another missing optimization after rewrite of SCCP for overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-15
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This hunk to match.pd fixes this:
```
(simplify
 (convert (plus@2 (convert ADDR_EXPR@0) INTEGER_CST@1))
 (if (POINTER_TYPE_P (type)
  && tree_nop_conversion_p (TREE_TYPE(@2), TREE_TYPE (@0))
  && tree_nop_conversion_p (TREE_TYPE(@0), type))
  (pointer_plus @0 @1)))
```
And combined with the "hack" in PR 117572, we can almost optimize the original
testcase there.

The only issue is we don't recongize the above until it is too late for DSE to
happen and we end up with still in .optimized:
```
  h_391 = &o + 2;
  n = 3;
  o ={v} {CLOBBER(eos)};
  q[1] = 1;
  c = &p;
  *h_391 = 0;
  o ={v} {CLOBBER(eos)};
```

Though this is enough to workaround the issue reported in PR 117426.

[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Richard Biener from comment #9)
> So the first pass that makes things difficult is reassoc which transforms
> 
>   _51 = (unsigned long) &MEM  [(void *)&str + 2B];
>   _4 = (unsigned long) __i_44;
>   _65 = _51 - _4;
>   _48 = _65 + 18446744073709551615;
>   _46 = _48 > 13;
>   if (_46 != 0)
> 
> to
> 
>   _51 = (unsigned long) &MEM  [(void *)&str + 2B];
>   _4 = (unsigned long) __i_44;
>   _12 = -_4;
>   _119 = _51 + 18446744073709551615;
>   _48 = _119 - _4;
>   _46 = _48 > 13;
>   if (_46 != 0)

 That is related to PR 117572.

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

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

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

--- Comment #22 from Sam James  ---
(In reply to Jan Hubicka from comment #19)
> With Jakub's __builtin_operator_new we now optimize out the code if main is
> renamed to something else.  With main we know it is executed once and we
> keep destructor offline which prevents from matching new/delete pairs.
> 

Which testcase did you see that with? comment 0 and comment 17 look the same
with or without main renaming.

Also, maybe we should move that into its own PR if it's an issue still.

[Bug tree-optimization/116426] [13/14/15 Regression] bogus -Wnull-dereference warning since r13-1268-g8c99e307b20c50

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[13/14/15 Regression] bogus |[13/14/15 Regression] bogus
   |-Wnull-dereference warning  |-Wnull-dereference warning
   ||since
   ||r13-1268-g8c99e307b20c50

--- Comment #6 from Sam James  ---
(In reply to Andrew Pinski from comment #5)
> There is a missed optimization that happened between GCC 12 and 13 for -O1+.
> Looks like a missing jump thread with a missed null check removal.

r13-1268-g8c99e307b20c50

[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0

--- Comment #5 from Sam James  ---
Fixed on trunk by r15-5109-g417b4cc9bf2180.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0

--- Comment #6 from Sam James  ---
Fixed on trunk by r15-5109-g417b4cc9bf2180 (both original + tamar's).

[Bug tree-optimization/110819] Missed optimization: when vector's size is 0 but vector::reserve has been called.

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |15.0

--- Comment #5 from Sam James  ---
Fixed on trunk by r15-5109-g417b4cc9bf2180.

[Bug tree-optimization/96945] unused std::vector is not always optimized away

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug middle-end/116868] GCC trunk doesn't eliminate a superfluous new/delete pair

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.

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

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

Sam James  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Sam James  ---
I don't think DSE does know about DECL_IS_OPERATOR_DELETE_P still though, so
maybe should keep it open.

[Bug target/117586] s390{,x} ABI for BitInt needs to be done

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-14
 Status|UNCONFIRMED |NEW

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

[Bug target/117592] implement SPARC support for BitInt

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-14
Summary|sparc support for BitInt|implement SPARC support for
   ||BitInt
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Little-endian support on the SPARC has been dead for long though.

[Bug target/117587] New: BPF support for BitInt

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

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

Bug ID: 117587
   Summary: BPF support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: bpf

BPF does not define a BitInt ABI nor have an implementation.

As mentioned on IRC, once the psABI change is figured out, little-endian
support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug rtl-optimization/116781] [lra][avr] internal compiler error: in cselib_invalidate_regno, at cselib.cc:2545

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

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

Denis Chertykov  changed:

   What|Removed |Added

 CC||denisc at gcc dot gnu.org

--- Comment #1 from Denis Chertykov  ---
Probably we have a wring definition of "*tablejump_split" 

The patch:

diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
index aae8a696a63..a26309650f2 100644
--- a/gcc/config/avr/avr.md
+++ b/gcc/config/avr/avr.md
@@ -7653,7 +7653,7 @@
 (unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
-   (clobber (match_dup 0))
+   (clobber (match_scratch:HI 2 "=X,X,0"))
(clobber (const_int 0))]
   "!AVR_HAVE_EIJMP_EICALL"
   "#"
@@ -7759,7 +7759,7 @@
(parallel [(set (pc)
(unspec:HI [(match_dup 7)] UNSPEC_INDEX_JMP))
   (use (label_ref (match_dup 3)))
-  (clobber (match_dup 7))
+  (clobber (scratch:HI))
   (clobber (match_dup 8))])]
   ""
   {

[Bug fortran/107067] [OpenMP] ICE with metadirective block statements

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
IIUC this should be a regular error and not an ICE; the parallel directive is
block-associated, which in this case is only the following block.  If the call
comes before the block, then I guess the block is everything up to the "end
metadirective".  See the definitions of "strictly structured block" and
"loosely structured block" in the glossary.

[Bug target/117596] New: avr support for BitInt

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

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

Bug ID: 117596
   Summary: avr support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: denisc at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: avr

avr does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug c/117548] ICE when redeclaring function with a compatible type involving C23 structure compatibility

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-14
   Assignee|unassigned at gcc dot gnu.org  |uecker at gcc dot 
gnu.org
 Status|UNCONFIRMED |NEW

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

Yes, there is a bug in how typedefs are handled. Thanks for reporting!

[Bug target/117586] New: s390{,x} ABI for BitInt needs to be done

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

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

Bug ID: 117586
   Summary: s390{,x} ABI for BitInt needs to be done
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

s390{,x} does not define a BitInt ABI nor have an implementation.

As mentioned on IRC, once the psABI change is figured out, little-endian
support will be easiest, but some work will need to be done on the libgcc side,
currently the dfp <-> _BitInt conversion functions are written only for BID,
not for DPD, although the DPD ones could be fairly similar, just with
encoding/decoding the format differently.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.

[Bug target/117589] New: hppa support for BitInt

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

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

Bug ID: 117589
   Summary: hppa support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: danglin at gcc dot gnu.org, law at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: hppa

hppa does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117593] New: amdgcn support for BitInt

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

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

Bug ID: 117593
   Summary: amdgcn support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: ams at gcc dot gnu.org, julian at codesourcery dot com
Blocks: 117580
  Target Milestone: ---
Target: sparc

amdgcn does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117591] New: sh support for BitInt

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

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

Bug ID: 117591
   Summary: sh support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, olegendo at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: sh

sh does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117483] [15 Regression] ICE: in merge, at config/riscv/riscv-vsetvl.cc:2106

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Should be fixed on the trunk now.

[Bug target/117584] PowerPC ABI for BitInt needs to be done

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
As mentioned on IRC, once the psABI change is figured out, little-endian
support will be easiest, but some work will need to be done on the libgcc side,
currently the dfp <-> _BitInt conversion functions are written only for BID,
not for DPD, although the DPD ones could be fairly similar, just with
encoding/decoding the format differently.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.

[Bug target/117590] New: nvptx support for BitInt

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

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

Bug ID: 117590
   Summary: nvptx support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org, vries at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: hppa

nvptx does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117588] New: m68k support for BitInt

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

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

Bug ID: 117588
   Summary: m68k support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: jemarch at gcc dot gnu.org, unassigned at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: m68k

m68k does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug target/117592] New: sh support for BitInt

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

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

Bug ID: 117592
   Summary: sh support for BitInt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: davem at redhat dot com, ebotcazou at gcc dot gnu.org
Blocks: 117580
  Target Milestone: ---
Target: sparc

sparc does not define a BitInt ABI nor have an implementation.

Once the psABI change is figured out, little-endian support will be easiest.

The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays).  Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).

As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).

If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI

[Bug ada/117538] Tracebacks don’t include the load address of PIE executables

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

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

Sam James  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org
  Component|target  |ada

--- Comment #3 from Sam James  ---
np. I'll change it back to Ada as it's more likely to not be missed then, and
it's really a target library issue as opposed to a backend one.

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

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

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

--- Comment #6 from Sam James  ---
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto says 
> To use the link-time optimizer, -flto and optimization options should be 
> specified at compile time and during the final link. It is recommended that 
> you compile all the files participating in the same link with the same 
> options and also specify those options at link time.

But really, you should pass as many of the same options as possible. It is not
just about optimisation, but e.g. -Werror needs to be repeated (because of late
warnings, I fixed that in Meson a little while ago).

We don't stream every single option and it would waste time/memory/disk to do
that, and it may even cause issues if people deliberately don't want to do
something at link-time when testing or similar.

Note that you're not using the native CMake support for LTO which is
INTERPROCEDURAL_OPTIMIZATION. If that is enabled, maybe it handles this
properly for you. If not, please file a CMake bug (and link it here).

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1

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

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

Sam James  changed:

   What|Removed |Added

  Known to work|6.5.0   |5.4.0
  Known to fail||6.1.0

--- Comment #5 from Sam James  ---
5.4 works then and 6.1 doesn't

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

--- Comment #8 from Andrew Pinski  ---
>From the GCC point of view, it is works for me ...

[Bug target/117591] [SH] support for BitInt

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

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|sh support for BitInt   |[SH] support for BitInt
   Last reconfirmed||2024-11-14

[Bug fortran/117474] Excessive memory usage during parser stage in interface blocks with types having type-bound procedures

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
I've created meta-bug pr117597 to track issues related to excessive memory
usage so that this one is not lost.

Potential bug in GCCJIT when evaluating bitfield constant with an internal global variable

[Schrodinger ZHU Yifan via Gcc-bugs]

Hi,

Could you help me confirm whether the situation I summarized in 
https://gist.github.com/SchrodingerZhu/84a334f8666b567800624446d354b568#file-gimple-c-L4
 is a bug for GCCJIT or not? Once confirmed, I can try to file it to tracker if 
needed.

Thanks!

Yifan



Schrodinger ZHU Yifan, Ph.D. Student
Computer Science Department, University of Rochester

Personal Email: i...@zhuyi.fan
Work Email: yifan...@rochester.edu
Website: https://www.cs.rochester.edu/~yzhu104/Main.html
Github: SchrodingerZhu
GPG Fingerprint: BA02CBEB8CB5D8181E9368304D2CC545A78DBCC3

signature.asc
Description: OpenPGP digital signature

[Bug lto/117598] New: -fstack-usage not working with -flto (regression?)

[ivan.zrno2 at gmail dot com via Gcc-bugs]

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

Bug ID: 117598
   Summary: -fstack-usage not working with -flto (regression?)
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.zrno2 at gmail dot com
  Target Milestone: ---

I am experiencing the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98922 just with a newer version of
gcc. 

With link time optimization, -flto, the compiler doesn't create any *.su files. 

Compiling a hello world main.cpp file with
"/usr/bin/g++ -g -fstack-usage -flto -o main.cpp.o -c main.cpp" doesn't create
a main.cpp.su file.

It also doesnt work with "-flto=auto"

The same happens with gcc 13.3.

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-11-14
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>"/usr/bin/g++ -g -fstack-usage -flto -o main.cpp.o -c main.cpp" doesn't create 
>a main.cpp.su file.


This won't create a stack usage file as the default is thin LTO files and are
not fully compiled yet. It is only fully compiled when linked.

Can you provide the full steps you are doing?

because this is what I just did and get a .su file out of it:
```
[apinski@xeond2 trt]$ cat main.cc
int main() {}
[apinski@xeond2 trt]$ ~/upstream-gcc/bin/gcc -g -fstack-usage -flto -o
main.cc.o -c main.cc
[apinski@xeond2 trt]$ ~/upstream-gcc/bin/gcc -g -fstack-usage -flto main.cc.o
[apinski@xeond2 trt]$ ls -altr
total 76
drwxr-xr-x. 14 apinski apinski 32768 Nov 14 14:32 ..
-rw-r--r--.  1 apinski apinski15 Nov 14 14:32 main.cc
-rw-r--r--.  1 apinski apinski  4688 Nov 14 14:32 main.cc.o
drwxr-xr-x.  2 apinski apinski  4096 Nov 14 14:32 .
-rw-r--r--.  1 apinski apinski27 Nov 14 14:32 a.ltrans0.ltrans.su
-rwxr-xr-x.  1 apinski apinski 18816 Nov 14 14:32 a.out
```

Do you expect a .su when using -c and -flto? When you can't. it will only be in
the final link for LTO.

[Bug c/117548] ICE when redeclaring function with a compatible type involving C23 structure compatibility

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

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

--- Comment #2 from uecker at gcc dot gnu.org ---
Created attachment 59599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59599&action=edit
patch

Tentative patch.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

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

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

--- Comment #36 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:012f5a22bac26a898ab66655965b07ac23201fdd

commit r15-5291-g012f5a22bac26a898ab66655965b07ac23201fdd
Author: Martin Jambor 
Date:   Thu Nov 14 20:55:06 2024 +0100

ipa: Rationalize IPA-VR computations across pass-through jump functions

Currently ipa_value_range_from_jfunc and
propagate_vr_across_jump_function contain similar but not same code
for dealing with pass-through jump functions.  This patch puts these
common bits into one function which can also handle comparison
operations.

gcc/ChangeLog:

2024-11-01  Martin Jambor  

PR ipa/114985
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): New function.
(ipa_value_range_from_jfunc): Move the common functionality to the
above new function, adjust the rest so that it works with it well.
(propagate_vr_across_jump_function): Likewise.

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

Denis Chertykov  changed:

   What|Removed |Added

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

--- Comment #12 from Denis Chertykov  ---
Fix committed.

[Bug target/113934] Switch avr to LRA

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

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

Bug 117191 Summary: [avr][dse2][lra] wrong dead store elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117191

   What|Removed |Added

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

[Bug target/117594] [15] RISC-V: Miscompile at -O3

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

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

--- Comment #4 from Li Pan  ---
I can reproduce this.

└─(07:29:53 on master⚑ ✭)──>
QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0
~/bin/qemu/bin/qemu-riscv64 test.elf   
 ──(Fri,Nov15)─┘
0  
   
   
   
/0.2s┌─(~/gcc/444/riscv-gnu-toolchain/gcc)(pli@panli:pts/5)─┐
└─(07:30:10 on master⚑ ✭)──>
QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0
~/bin/qemu/bin/qemu-riscv64 test.elf   
 ──(Fri,Nov15)─┘
72 

I also have a vlen=256 dev-board and got the same value (72) as qemu. All above
are built with  -Ofast -ffast-math.

[Bug lto/117598] -fstack-usage not working with -flto (regression?)

[ivan.zrno2 at gmail dot com via Gcc-bugs]

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

Ivan Zrno  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #7 from Ivan Zrno  ---
Thanks for all the help, I think I found the explanation.

I need to set the compile time options AND THE link time options.


target_compile_options(MyProgram PRIVATE -fstack-usage)
target_link_options(MyProgram PRIVATE -fstack-usage)

just setting the compile time options is not enough.

It also doesn't matter if I manually add -flto or set the CMAKE
INTERPROCEDURAL_OPTIMIZATION to ON

[Bug target/117594] [15] RISC-V: Miscompile at -O3

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

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

--- Comment #2 from Robin Dapp  ---
What's the expected output of the latter test case?
I'm seeing 36 no matter what I try, -O3, -O2 without 'v', etc.
Even with an x86 GCC.

And, looking at the loop
for (unsigned j = 0; j < (z[i] ?: 10); j += 3) {
a += 9;
}
with z[i] = h = d = 0, i.e. j < 10, a = 36 looks correct?

[Bug target/117594] [15] RISC-V: Miscompile at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
Yep 36 looks correct but I get a zero for -O3:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -O3 red.c -o user-config.out -fno-strict-aliasing
> QEMU_CPU=rv64,vlen=128,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve32x=true,zve64d=true,zve64f=true,zve64x=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 
> user-config.out
0

Tested using:
gcc: r15-5287-ge5d6e857af9
qemu: v9.1.1

[Bug target/56504] -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML)

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c/117548] [15 regression] ICE when redeclaring function with a compatible type involving C23 structure compatibility

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE when redeclaring|[15 regression] ICE when
   |function with a compatible  |redeclaring function with a
   |type involving C23  |compatible type involving
   |structure compatibility |C23 structure compatibility
 Status|NEW |ASSIGNED

[Bug target/117538] Tracebacks don’t include the load address of PIE executables

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #2 from simon at pushface dot org ---
(In reply to Sam James from comment #1)
> https://inbox.sourceware.org/gcc-patches/A4C571BE-67E5-4AF6-9BCB-
> f3479216a...@pushface.org/

Thanks, I was just about to link that myself

[Bug c/117548] [15 regression] ICE when redeclaring function with a compatible type involving C23 structure compatibility

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
  Known to fail||15.0
  Known to work||14.2.1

[Bug target/117538] Tracebacks don’t include the load address of PIE executables

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/a4c571be-67e5-4af6-9bcb-f3479216a...@pushface.org/

[Bug fortran/117597] New: [meta-bug] excessive memory usage by gfortran frontend

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

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

Bug ID: 117597
   Summary: [meta-bug] excessive memory usage by gfortran frontend
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

This is a meta-bug to track problems related to excessive memory usage by
the gfortran frontend (f951).

[Bug tree-optimization/117556] [15 Regression] gcc.dg/vect/vect-live-slp-3.c fails to SLP with variable-length vectors

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/117553] [15 regression] stage2 ada compiler miscompiled after r15-5069-g32cf28ccc9e77c

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed then.

[Bug tree-optimization/117556] [15 Regression] gcc.dg/vect/vect-live-slp-3.c fails to SLP with variable-length vectors

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

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

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

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

commit r15-5227-g4b4aa47ed296968507b2fde70d2e651129ff3b36
Author: Richard Biener 
Date:   Wed Nov 13 14:43:27 2024 +0100

tree-optimization/117556 - SLP of live stmts from load-lanes

The following fixes SLP live lane generation for load-lanes which
fails to analyze for gcc.dg/vect/vect-live-slp-3.c because the
VLA division doesn't work out but it would also wrongly use the
transposed vector defs I think.  The following properly disables
the actual load-lanes SLP node from live lane processing and instead
relies on the SLP permute node representing the live lane where we
can use extract-last to extract the last lane.  This also fixes
the reported Ada miscompile.

PR tree-optimization/117556
PR tree-optimization/117553
* tree-vect-stmts.cc (vect_analyze_stmt): Do not analyze
the SLP load-lanes node for live lanes, but only the
permute node.
(vect_transform_stmt): Likewise for the transform.

* gcc.dg/vect/vect-live-slp-3.c: Expect us to SLP even for
VLA vectors (in single-lane mode).

[Bug tree-optimization/117553] [15 regression] stage2 ada compiler miscompiled after r15-5069-g32cf28ccc9e77c

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-5227-g4b4aa47ed296968507b2fde70d2e651129ff3b36
Author: Richard Biener 
Date:   Wed Nov 13 14:43:27 2024 +0100

tree-optimization/117556 - SLP of live stmts from load-lanes

The following fixes SLP live lane generation for load-lanes which
fails to analyze for gcc.dg/vect/vect-live-slp-3.c because the
VLA division doesn't work out but it would also wrongly use the
transposed vector defs I think.  The following properly disables
the actual load-lanes SLP node from live lane processing and instead
relies on the SLP permute node representing the live lane where we
can use extract-last to extract the last lane.  This also fixes
the reported Ada miscompile.

PR tree-optimization/117556
PR tree-optimization/117553
* tree-vect-stmts.cc (vect_analyze_stmt): Do not analyze
the SLP load-lanes node for live lanes, but only the
permute node.
(vect_transform_stmt): Likewise for the transform.

* gcc.dg/vect/vect-live-slp-3.c: Expect us to SLP even for
VLA vectors (in single-lane mode).

[Bug tree-optimization/116578] vectorizer SLP transition issues / dependencies

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

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

Bug 117556 Summary: [15 Regression] gcc.dg/vect/vect-live-slp-3.c fails to SLP 
with variable-length vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117556

   What|Removed |Added

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