[Bug c++/13005] Pointer adjusted for derived class containing virtual function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #39 from Andrew Pinski  ---
-Wold-style-cast will warn about this and I think that might be best thing.
Since depending on where you the definition of Base::Base and the old style
cast, you will get a fix it note to use either static_cast or reinterpret_cast
. In the place where reinterpret_cast is done, it is incorrect.

[Bug target/36831] sparc-sun-solaris2.6: Bootstrap comparison failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Andrew Pinski  ---
So from the information in the bug report, not setting -O2 in CFLAGS works.
This means `gcc version 3.4.2` is miscompiling GCC 4.3.1.

Since both of these versions of GCC is over 16 years old now there is not much
we can do. So closing as invalid.

[Bug target/117292] [15 Regression] ICE: in aarch64_output_simd_imm, at config/aarch64/aarch64.cc:25422 at -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ra
   Last reconfirmed||2024-10-25
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
r15-4569-g22a37534c640ca


Changing pseudo 195 in operand 2 of insn 25 on equiv const_vector
 Considering alt=0 of insn 25:   (0) =w  (1) w  (2) w
2 Non-pseudo reload: reject+=2
2 Non input pseudo reload: reject++
  overall=9,losers=1,rld_nregs=1
 Considering alt=1 of insn 25:   (0) w  (1) 0  (2) Do
1 Matching alt: reject+=2
  overall=8,losers=1,rld_nregs=1
  Choosing alt 1 in insn 25:  (0) w  (1) 0  (2) Do {xorv4si3}
  Creating newreg=277 from oldreg=102, assigning class FP_REGS to r277
   25: r277:V4SI=r277:V4SI^const_vector
  REG_EQUAL r101:V4SI^const_vector
Inserting insn reload before:

[Bug target/117292] [15 Regression] ICE: in aarch64_output_simd_imm, at config/aarch64/aarch64.cc:25422 at -Os

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

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

--- Comment #1 from Andrew Pinski  ---
(insn:TI 25 34 17 (set (reg:V4SI 60 v28 [orig:102 _2 ] [102])
(xor:V4SI (reg:V4SI 60 v28 [orig:102 _2 ] [102])
(const_vector:V4SI [
(const_int 3 [0x3]) repeated x4
]))) "/app/example.cpp":20:36 1779 {xorv4si3}
 (expr_list:REG_EQUAL (xor:V4SI (reg:V4SI 63 v31 [orig:101
foo0_v512u32_0.0_1 ] [101])
(const_vector:V4SI [
(const_int 3 [0x3]) repeated x4
]))
(nil)))

[Bug c/117290] error: void value not ignored , pointing to the wrong location when ?: is used inside an if

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.6.4, 4.9.4

--- Comment #3 from Andrew Pinski  ---
Summary of GCC versions:
* 4.4.x and before: didn't print out the column but pointed to the end of the
`if()`
* 4.5.x printed out the column info but pointed to be the begning of the `if(`
or the end of `)` depending on if the `(` was on a different line from `if`.
* 4.6+ is the current behavior and uses the column info from the first operand
of the `?:` expression.

[Bug c/117290] error: void value not ignored , pointing to the wrong function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Reduced to:
```
void f(int t) {
 if (0 ? 0 : __builtin_exit(0))
   ;
}
```

[Bug other/16996] [meta-bug] code size improvements

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
Moved to a keyword instead.

[Bug c/117288] [15 Regression] LTO ICE in output_constructor_regular_field at varasm.cc:5644 on wolfssl-5.7.2 since r15-4377-gf9bac238840155

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

Summary|[15 Regression] LTO ICE in  |[15 Regression] LTO ICE in
   |output_constructor_regular_ |output_constructor_regular_
   |field at varasm.cc:5644 on  |field at varasm.cc:5644 on
   |wolfssl-5.7.2   |wolfssl-5.7.2 since
   ||r15-4377-gf9bac238840155

--- Comment #2 from Sergei Trofimovich  ---
Bisect landed on r15-4377-gf9bac238840155 "c: Speed up compilation of large
char array initializers when not using #embed".

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #411 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #409)
> (In reply to Oleg Endo from comment #407)
> > (In reply to John Paul Adrian Glaubitz from comment #406)
> > > (In reply to John Paul Adrian Glaubitz from comment #405)
> > > > File too large to be attached, so uploading it here:
> > > > 
> > > > https://people.debian.org/~glaubitz/pr-55212-404.tgz
> > > 
> > > Ping.
> > 
> > Can you try to reduce the case?  That would be helpful.
> > 
> > Basically, try to remove code from the .i / .ii file until it stops failing.
> > 
> > https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
> 
> I was hoping for Kaz to have another look. If he doesn't have the time, I
> can give it a try over the weekend.
> 
> Is there a good manual for reducing and testing intermediate files?

https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

+ common sense/experience.  Yes, it can take hours.  Having fast hardware for
repeated trial-and-error runs helps.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #410 from Kazumoto Kojima  ---
Created attachment 59432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59432&action=edit
a trial patch for c#404

It's difficult to see what is going on, because the test case is too huge. 
Looking at the postmortem debug, it seems that reload failed with f - r reg
move generated by LRA, perhaps in starvation of registers including fpu regs
and fpul.  That case might require reloading with memories which isn't handled
by the current movsf logic for LRA.

The patch falls back to movsf_ie for f - r moves when lra_in_progress is true.
Tested with c/c++ testsuite on devel/sh-lra.

[Bug target/117291] Simple but large test case uses up over 8M of stack and hits SEGV

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

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

--- Comment #1 from Peter Bergner  ---
Created attachment 59434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59434&action=edit
gzip'd test case that segvs

[Bug libgomp/71877] -fdump-tree-ompexp is generating incomplete code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
As far as I can tell GCC 6+ is correct so closing as invalid.

[Bug libgcc/68720] libgcc build failure on AIX 5.2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No feedback in over 8 years so closing and there is no way to reproduce the
issue either.

[Bug target/117292] [15 Regression] ICE: in aarch64_output_simd_imm, at config/aarch64/aarch64.cc:25422 at -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
So there is a mismatch in the constraint and predicates.

The predicates checks aarch64_reg_or_xor_imm which in turns checks
aarch64_simd_valid_xor_imm .

While the constraint is Do which checks aarch64_simd_valid_orr_imm which
accepts a little bit more than aarch64_simd_valid_xor_imm when SVE is turned
off.

[Bug c/117289] New: gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23

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

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

Bug ID: 117289
   Summary: gcc.dg/debug/ctf/ctf-function-pointers-2.c failure
with -std=gnu23
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: uecker at gcc dot gnu.org
  Target Milestone: ---

If the test gcc.dg/debug/ctf/ctf-function-pointers-2.c is built with -std=gnu23
(or a compiler defaulting to -std=gnu23), in addition to the options listed in
that test, it fails:

FAIL: gcc.dg/debug/ctf/ctf-function-pointers-2.c scan-assembler-times [\t
]0x1601[\t ]+[^\n]*ctt_info 1

A matching line now appears more than once.  The assembly diffs include:

+   .long   0   # ctt_name
+   .long   0x1601  # ctt_info
+   .long   0x3 # ctt_size or ctt_type
+   .long   0x2 # dtu_argv
+   .long   0   # dtu_argv_padding
+   .long   0   # ctt_name
+   .long   0xe00   # ctt_info
+   .long   0x6 # ctt_size or ctt_type

I suspect something to do with the C23 tag handling changes because I don't see
any reason for this to be different in C23 mode otherwise. (And it seems right
to me that this test should not have any more types etc. appearing in any kind
of debug info in C23 mode than in C17 mode.)

[Bug c/117288] [15 Regression] LTO ICE in output_constructor_regular_field at varasm.cc:5644 on wolfssl-5.7.2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug sanitizer/55799] AddressSanitizer with `-pg' option results in spurious errors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
I cannot even reproduce it using GCC 4.8.1. So closing as invalid.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 59428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59428&action=edit
gcc15-pr117201.patch

Untested fix.

[Bug target/117286] New: [RISC-V] internal compiler error: Segmentation fault `__riscv_vlmul_ext_v_f16mf2_f16m1`

[yibohe at pku dot edu.cn via Gcc-bugs]

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

Bug ID: 117286
   Summary: [RISC-V] internal compiler error: Segmentation fault
`__riscv_vlmul_ext_v_f16mf2_f16m1`
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yibohe at pku dot edu.cn
  Target Milestone: ---

For the following code with rvv intrinsics:
```
#include 
_Float16 a[10];
void func(){
  int placeholder0 = 10;
  _Float16* ptr_a = a;
  for (size_t vl; placeholder0 > 0; placeholder0 -= vl){
vl = __riscv_vsetvl_e16m1(placeholder0);
vfloat16mf2_t va = __riscv_vle16_v_f16mf2(ptr_a, vl);
vfloat16m1_t vb = __riscv_vlmul_ext_v_f16mf2_f16m1(va);
ptr_a += vl;
  }
}
```

ICE is triggered with option `-O1`, `-O2`, `-O3`, and `-Os`.
```
riscv64-unknown-elf-gcc -march=rv64gcv_zvfh -mabi=lp64d -Wno-psabi -static -O1
-freport-bug 1.c
during RTL pass: expand
1.c: In function 'func':
1.c:9:23: internal compiler error: Segmentation fault
9 | vfloat16m1_t vb = __riscv_vlmul_ext_v_f16mf2_f16m1(va);
  |   ^~~~
0x10439c3 crash_signal
../.././gcc/gcc/toplev.cc:319
0xc3c78d gen_lowpart_common(machine_mode, rtx_def*)
../.././gcc/gcc/emit-rtl.cc:1569
0xfe6e59 gen_lowpart_general(machine_mode, rtx_def*)
../.././gcc/gcc/rtlhooks.cc:48
0x1494ea2 riscv_vector::vlmul_ext::expand(riscv_vector::function_expander&)
const
../.././gcc/gcc/config/riscv/riscv-vector-builtins-bases.cc:1765
0x148e39b riscv_vector::function_expander::expand()
../.././gcc/gcc/config/riscv/riscv-vector-builtins.h:651
0x148e39b riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*)
../.././gcc/gcc/config/riscv/riscv-vector-builtins.cc:4703
0xb41cd4 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../.././gcc/gcc/builtins.cc:7769
0xc6d594 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../.././gcc/gcc/expr.cc:12361
0xb63e24 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../.././gcc/gcc/expr.h:316
0xb63e24 expand_call_stmt
../.././gcc/gcc/cfgexpand.cc:2865
0xb63e24 expand_gimple_stmt_1
../.././gcc/gcc/cfgexpand.cc:3932
0xb63e24 expand_gimple_stmt
../.././gcc/gcc/cfgexpand.cc:4077
0xb68d3f expand_gimple_basic_block
../.././gcc/gcc/cfgexpand.cc:6133
0xb6b5e7 execute
../.././gcc/gcc/cfgexpand.cc:6872
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cca2ogQP.out file, please attach this to
your bugreport.
```

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #59416|0   |1
is obsolete||

--- Comment #15 from Jakub Jelinek  ---
Created attachment 59430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59430&action=edit
gcc15-pr117249-2.patch

Updated version of the second patch.

[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats

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

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-4617-gecd6bee0913db1237424ea68b0b1ec252b024e9c
Author: David Malcolm 
Date:   Thu Oct 24 15:52:29 2024 -0400

analyzer: avoid implicit use of global_dc's pretty_printer [PR116613]

Previously, various places in the analyzer generated message strings
by cloning the diagnostic_context's pretty_printer, printing to that
pretty_printer's buffer, and then returning a copy of the buffer
contents.

This implicit use of a particular pretty printer doesn't work well for
the "multiple diagnostic output formats" case (PR other/116613), such as
differences in colorization, or in how phase 3 of formatting works.
Hence as enabling work towards that, the following patch reworks the
various functions returning a label_text string in favor of functions
that print to a specific pretty_printer, such as diagnotic_event's
"get_desc" vfunc, which becomes "print_desc".  This makes the particular
pretty_printer in use explicit in each case.

Previously, the various pending_diagnostic::describe_* vfuncs returned a
label_text, with the return of an empty string signifying that no
description could be generated.  With this patch, these vfuncs gain a
"pretty_printer &" param and a bool return value and now either print to
the pretty_printer and return true, or return false to signify the
"no description available" case.

No functional change intended.

gcc/analyzer/ChangeLog:
PR other/116613
* bounds-checking.cc
(concrete_buffer_overflow::describe_final_event): Convert return
type from label_text to bool.  Add "pp" param and either print to
it and return true, or return false.
(concrete_buffer_overflow::describe_final_event_as_bytes): Convert
to print to a pp rather than returning a label_text.
(concrete_buffer_overflow::describe_final_event_as_bits):
Likewise.
(class concrete_buffer_over_read): Analogous changes to above.
(class concrete_buffer_underwrite): Likewise.
(class concrete_buffer_under_read): Likewise.
(class symbolic_buffer_overflow): Likewise.
(class symbolic_buffer_over_read): Likewise.
* call-details.cc (class overlapping_buffers): Likewise.
* call-info.cc (call_info::print): Reimplement.
(class call_info::add_events_to_path::call_event): Convert
"get_desc" vfunc to "print_desc", dropping return type, adding
"pp" param, and printing to it.
(class succeed_or_fail_call_info): Likewise.
* call-info.h (class call_info): Likewise.
(class succeed_or_fail_call_info): Likewise.
* checker-event.cc (checker_event::dump): Reimplement.
(checker_event::prepare_for_emission): Update for change from
get_desc to print_desc.
(debug_event::get_desc): Convert to...
(debug_event::print_desc): ...this.
(precanned_custom_event::get_desc): Convert to...
(precanned_custom_event::print_desc): ...this.
(statement_event::get_desc): Convert to...
(statement_event::print_desc): ...this.
(region_creation_event_memory_space::get_desc): Convert to...
(region_creation_event_memory_space::print_desc): ...this.
(region_creation_event_capacity::get_desc): Convert to...
(region_creation_event_capacity::print_desc): ...this.
(region_creation_event_allocation_size::get_desc): Convert to...
(region_creation_event_allocation_size::print_desc): ...this.
(region_creation_event_debug::get_desc): Convert to...
(region_creation_event_debug::print_desc): ...this.
(function_entry_event::get_desc): Convert to...
(function_entry_event::print_desc): ...this.
(state_change_event::get_desc): Convert to...
(state_change_event::print_desc): ...this.
(state_change_event::get_meaning): Update for change to
pending_diagnostic::get_meaning_for_state_change.
(superedge_event::should_filter_p): Convert from usage of get_desc
to print_desc.
(start_cfg_edge_event::get_desc): Convert to...
(start_cfg_edge_event::print_desc): ...this.
(call_event::get_desc): Convert to...
(call_event::print_desc): ...this.
(return_event::get_desc): Convert to...
(return_event::print_desc): ...this.
(start_consolidated_cfg_edges_event::get_desc): Convert to...
(start_consolidated_cfg_edges_event::print_desc): ...this.
(inlined_call_event::get

[Bug c++/117285] New: Compilation fails when using template parameter packs to populate operator overload function arguments

[cuking998244353 at gmail dot com via Gcc-bugs]

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

Bug ID: 117285
   Summary: Compilation fails when using template parameter packs
to populate operator overload function arguments
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuking998244353 at gmail dot com
  Target Milestone: ---

The code at this link: https://godbolt.org/z/TK6xWGE84 compiles correctly in
clang, icc, and icx, but fails in gcc with an error.

[Bug tree-optimization/117277] [15 Regression] gcc.target/aarch64/store_lane_spill_1.c fails

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Target||aarch64
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2024-10-24
 Ever confirmed|0   |1
   Keywords|needs-bisection |

--- Comment #2 from Richard Biener  ---
The clobber emission in vectorizable_store is still there ... we're removing it
again here:

class loop *
vect_transform_loop (loop_vec_info loop_vinfo, gimple *loop_vectorized_call)
{
...
  stmt = gsi_stmt (si);
  /* During vectorization remove existing clobber stmts and
 prefetches.  */
  if (gimple_clobber_p (stmt)
  || gimple_call_builtin_p (stmt, BUILT_IN_PREFETCH))
{
  unlink_stmt_vdef (stmt);
  gsi_remove (&si, true);
  release_defs (stmt);

we have scheduled SLP completely already, so this messes things up.

I have to think about how to best re-structure vect_transform_loop.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 99175 Summary: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17  (test for 
errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175

   What|Removed |Added

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

[Bug c++/117285] Compilation fails when using template parameter packs to populate operator overload function arguments

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

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

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

Next time please attach the testcase or place it inline of the bug report.

[Bug target/116953] [avr] error: operands to %T/%t must be reg + const_int

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r15-4618-gca0ab7a0ac18911181e9161cfb8b87fb90039612
Author: Georg-Johann Lay 
Date:   Tue Oct 22 11:51:44 2024 +0200

AVR: target/116953 - Restore recog_data after calling jump_over_one_insn_p.

The previous fix for PR116953 is incomplete because references to
recog_data are escaping avr_out_sbxx_branch() in the form of %-operands
in the returned asm code template.  This patch reverts the previous fix,
and re-extracts the operands by means of extract_constrain_insn_cached()
after the call of jump_over_one_insn_p().

PR target/116953
gcc/
* config/avr/avr.cc (avr_out_sbxx_branch): Revert previous fix
for PR116953 (r15-4078).  Run extract_constrain_insn_cached
on the current insn after calling jump_over_one_insn_p.

[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats

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

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

--- Comment #31 from David Malcolm  ---
(In reply to Kamil Dudka from comment #27)
> Sounds good, looking forward to try out a new COPR build!

I've update the COPR to use the latest version of my patches:
  https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-latest/

The latest build:
  15.0.0-4.20241020git01f50ebfd97a.pr116613.v0.155 

contains:
* the existing -fdiagnostics-add-output= from the previous build
* a new -fdiagnostics-set-output= option, which I hope will allow you to get
rid of the extra json output mentioned in comment #19.
* fixed manpages; see man /opt/gcc-latest/share/man/man1/gcc.1 for
documentation on these features.

I've lightly tested the built rpm on my laptop.

I believe this also fixes the target-specific issues and issues with Fortran,
Modula 2 that I mentioned in comment #18, so I hope that I'm reasonably close
to being able to merge the remaining patches into trunk for gcc 15.

FWIW, the packaging sources for the COPR build are here:
 
https://github.com/davidmalcolm/pkg-gcc-latest/commit/c349c7bbb90aff2c247e91ce94be9b11a596a2e7

[Bug tree-optimization/117287] [13/14/15 Regression] assume attribute related miscompilation

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

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

--- Comment #1 from Jakub Jelinek  ---
_Z3bazj._assume.0 assume inferred range of x_2(D) (param x) = [irange] unsigned
int [9, 10] MASK 0x3 VALUE 0x8
   on-exit update x_2(D) in BB2 : [irange] unsigned int [9, 10] MASK 0x3 VALUE
0x8

The _Z3bazj._assume.0 function body is
   [local count: 1073741822]:
  _3 = x_2(D) + 4294967292;
  if (_3 <= 1)
goto ; [41.00%]
  else
goto ; [59.00%]

   [local count: 633507679]:
  if (x_2(D) == 9)
goto ; [34.00%]
  else
goto ; [66.00%]

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

   [local count: 418115066]:
  if (x_2(D) == 10)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 1073741824]:
  # iftmp.3_4 = PHI <1(4), 0(5)>
  return iftmp.3_4;
and so for x - 4U <= 1 should return 1 (i.e. [4,5] range), or for [9,9], or for
[10,10].

[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)

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

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

--- Comment #9 from Sam James  ---
(In reply to qinzhao from comment #8)
> for the reduced testing case, with my work-in-progress 3rd version of the
> patch + -fdiagnostics-explain-harder:
> t.c:15:15: warning: array subscript [0, 2] is outside array bounds of ‘const
> char *[2]’ [-Warray-bounds=]
>15 |   if (commands[comind] == "b" &&
>   |   ^~~~
>   ‘setval_internal_tilde’: events 1-2
> 4 | if (comind > sizeof(commands)/sizeof(commands[0])) {
>   |^
>   ||
>   |(1) t.c:15:24: warning: when the condition is evaluated
> to true
> ..

Showing the inline event here for the condition is very helpful indeed and
would make me happy, I think.

[Bug ipa/113197] [12/13/14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119 since r12-5177-g494bdadf28d0fb

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

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

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

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

commit r15-4612-gbcd56224d74cdd8dc3c77097de51e97bc7b6d181
Author: Dimitar Dimitrov 
Date:   Thu Oct 24 19:59:42 2024 +0300

testsuite: Require effective target pie for pr113197

The test for PR113197 explicitly enables PIE.  But targets without PIE
emit warnings when -fpie is passed (e.g. pru and avr), which causes the
test to fail.

Fix by adding an effective target requirement for PIE.

With this patch, the test now is marked as unsupported for
pru-unknown-elf.  Testing for x86_64-pc-linux-gnu passes with current
mainline, and fails if the fix from r15-4018-g02f4efe3c12cf7 is
reverted.

PR ipa/113197

gcc/testsuite/ChangeLog:

* gcc.dg/lto/pr113197_0.c: Require effective target pie.

Signed-off-by: Dimitar Dimitrov 

[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #8 from qinzhao at gcc dot gnu.org ---
for the reduced testing case, with my work-in-progress 3rd version of the patch
+ -fdiagnostics-explain-harder:
t.c:15:15: warning: array subscript [0, 2] is outside array bounds of ‘const
char *[2]’ [-Warray-bounds=]
   15 |   if (commands[comind] == "b" &&
  |   ^~~~
  ‘setval_internal_tilde’: events 1-2
4 | if (comind > sizeof(commands)/sizeof(commands[0])) {
  |^
  ||
  |(1) t.c:15:24: warning: when the condition is evaluated to
true
..
   15 |   if (commands[comind] == "b" &&
  |   
  |   |
  |   (2) t.c:15:24: warning: out of array bounds here
t.c:1:13: note: while referencing ‘commands’
1 | const char* commands[] = {"a", "b"};
  | ^~~~

looks like a helpful diagnostic.

[Bug tree-optimization/117287] New: [13/14/15 Regression] assume attribute related miscompilation

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

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

Bug ID: 117287
   Summary: [13/14/15 Regression] assume attribute related
miscompilation
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, jakub at gcc dot gnu.org,
pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org,
sjames at gcc dot gnu.org
Depends on: 117249
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #117249 +++

C++
static inline bool
foo (unsigned x)
{
  return x == 4 || x == 5 || x == 9 || x == 10;
}

int v;

[[gnu::noipa]] void
bar (const char *p)
{
  if (p[0] != (v ? 'a' : 'b') || p[1])
__builtin_abort ();
}

[[gnu::noipa]] void
baz (unsigned x)
{
  bool a = x == 5;
  [[assume (foo (x))]];
  bar (a ? "a" : "b");
}

int
main ()
{
  baz (4);
  v = 1;
  baz (5);
  v = 0;
  baz (9);
  baz (10);
}

is miscompiled on the trunk and 14/13 branches with -O2
--param=logical-op-non-short-circuit=0, the vrp1 pass decides to call bar
("b"); unconditionally, even when the assumption should result in [4,5][9,10]
range for x.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
[Bug 117249] [12/13/14/15 Regression] --disable-checking is broken since
r5-2450

[Bug tree-optimization/117287] [13/14/15 Regression] assume attribute related miscompilation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-24
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.4
 CC||amacleod at redhat dot com
 Ever confirmed|0   |1

[Bug testsuite/117261] New test cases from r15-4532-g36e91df7716d34 fail

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
I've committed Jakub's patch signed vs unsigned char issues in the new tests.

[Bug fortran/117264] Segfault when using assignment for allocatable class

[vterzi1996 at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Vladimir Terzi  ---
(In reply to anlauf from comment #9)
> After some search, I found a gfortran 13.3.0 (openSUSE 15.5, r13-8781),
> that fails also for
> 
> program p
>   type,abstract::t
>   end type t
>   type,extends(t)::tt
>   end type tt
>   class(t),allocatable::o
>   o=f()
> contains
>   function f() result(r) ! works
> class(t), allocatable :: r
> r=tt()
>   end
> end
> 
> the same as for the example in comment#0.
> 
> Note that it works with 12.3.0 and 12.4.1, 13.3.1 (at r13-9145),
> 14.2.1 (at r14-10831), and 15-trunk.  It looks like a temporary regression.
> 
> Can you update your compiler installation?

I updated GCC to version 14.2.0, and got another error for the code in the
first post (compiled with `-O0 -g`):
```
In file 'a.f90', around line 8: Error allocating 17510029503779062109 bytes:
Cannot allocate memory

Error termination. Backtrace:
#0  0x400858 in p
at a.f90:7
#1  0x4009d1 in main
at a.f90:7
```
And sometimes this error:
```
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f80f4a42b7f in ???
#1  0x400810 in p
at a.f90:7
#2  0x4009d1 in main
at a.f90:7
Segmentation fault (core dumped)
```
It's not deterministic.

[Bug tree-optimization/117287] [13/14/15 Regression] assume attribute related miscompilation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|build   |wrong-code

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #17 from Jakub Jelinek  ---
Given PR117287 I'm going to test just the #1 patch for now.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #16 from Jakub Jelinek  ---
So, the powerpc gengtype issue during --disable-checking build with those 2
patches is about whether
  gcc_assert (union_or_struct_p (kind));
in gengtype.cc (new_structure) is present or commented out, if it is present
and expands to [[assume (EXPR)]] then it doesn't work correctly, if it is e.g.
commented out, then it does.  And it doesn't matter which exact compiler is
used to compile that gengtype.o, can be stage1 from --enable-checking=release
or --disable-checking, both behave the same.
union_or_struct_p shouldn't have side-effects, it is
inline bool
union_or_struct_p (enum typekind kind)
{
  return (kind == TYPE_UNION
  || kind == TYPE_STRUCT
  || kind == TYPE_LANG_STRUCT
  || kind == TYPE_USER_STRUCT);
}
The new_structure function is only called with TYPE_UNION (several times) and
once with TYPE_STRUCT, so I suspect some assume related miscompilation.

[Bug target/117248] gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception

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

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

--- Comment #4 from John David Anglin  ---
The trap doesn't occur with the following change:

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 53f5400a961..112679f8701 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -10573,6 +10573,7 @@ vectorizable_slp_permutation_1 (vec_info *vinfo,
gimple_stmt_iterator *gsi,
  unsigned vnunits = TYPE_VECTOR_SUBPARTS (vtype)
.to_constant ();
  unsigned lane = active_lane[p.first].to_constant ();
+ gcc_assert (vnunits != 0);
  unsigned vi = (lane + p.second) / vnunits;
  unsigned vl = (lane + p.second) % vnunits;
  vperm.quick_push ({{p.first, vi}, vl});

Need to find out why vnunits is mishandled prior to call to
$$divU.  It's calculated and put into $r19 in the instruction
at 0x414dae44 but the value isn't copied to $r25 for
the call.

[Bug testsuite/117274] [14 Regression] New test case g++.dg/cpp2a/decomp10.C from r14-10826-g7de78f7353f125 fails

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

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

--- Comment #1 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jason Merrill
:

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

commit r14-10833-g2d47645cd47c9a84a69343b641a6ee741a85dc75
Author: Jason Merrill 
Date:   Thu Oct 24 11:13:30 2024 -0400

c++: remove dg-warning [PR117274]

This warning was added for GCC 15, don't expect it.

PR c++/117274
PR c++/117107

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/decomp10.C: Remove captured binding warning.

[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats

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

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

--- Comment #28 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-4610-gbf43fe6aa966eaf397ea3b8ebd6408d3d124e285
Author: David Malcolm 
Date:   Thu Oct 24 11:48:01 2024 -0400

Use unique_ptr in more places in pretty_printer/diagnostics [PR116613]

My forthcoming patches for PR other/116613 make much more use of
cloning of pretty_printers than before, so it makes sense as a
preliminary patch for the result of pretty_printer::clone to be a
std::unique_ptr, rather than add more manual uses of "delete".

On doing so, I noticed various other places where naked new/delete is
used for run-time configuration of diagnostics:
* the output format (text vs SARIF)
* client data hooks
* the option manager
* the URLifier

Hence this patch also makes use of std::unique_ptr and ::make_unique for
managing such client policy classes, and also for diagnostic_buffer's
per-format implementations.

Unfortunately we can't directly include  in our internal headers
but instead any of our TUs that make use of std::unique_ptr must #define
INCLUDE_MEMORY before including system.h.

Hence the bulk of this patch is taken up with adding a define of
INCLUDE_MEMORY to hundreds of source files: everything that includes
diagnostic.h or pretty-print.h (and thus anything transitively such as
includers of lto-wrapper.h, c-tree.h, cp-tree.h and rtl-ssa.h).

Thanks to Gaius Mulley for the parts of the patch that regenerated the
m2 files.

gcc/ada/ChangeLog:
PR other/116613
* gcc-interface/misc.cc: Add #define INCLUDE_MEMORY
* gcc-interface/trans.cc: Likewise.
* gcc-interface/utils.cc: Likewise.

gcc/analyzer/ChangeLog:
PR other/116613
* analyzer-logging.cc: Add #define INCLUDE_MEMORY
(logger::logger): Update for m_pp becoming a unique_ptr.
(logger::~logger): Likewise.
(logger::log_va_partial): Likewise.
(logger::end_log_line): Likewise.
* analyzer-logging.h (logger::get_printer): Likewise.
(logger::m_pp): Convert to a unique_ptr.
* analyzer.cc (make_label_text): Use
diagnostic_context::clone_printer and use unique_ptr.
(make_label_text_n): Likewise.
* bar-chart.cc: Add #define INCLUDE_MEMORY
* pending-diagnostic.cc (evdesc::event_desc::formatted_print):
Use diagnostic_context::clone_printer and use unique_ptr.
* sm-malloc.cc (sufficiently_similar_p): Likewise.
* supergraph.cc (supergraph::dump_dot_to_file): Likewise.

gcc/c-family/ChangeLog:
PR other/116613
* c-ada-spec.cc: Add #define INCLUDE_MEMORY.
* c-attribs.cc: Likewise.
* c-common.cc: Likewise.
* c-format.cc: Likewise.
* c-gimplify.cc: Likewise.
* c-indentation.cc: Likewise.
* c-opts.cc: Likewise.
* c-pch.cc: Likewise.
* c-pragma.cc: Likewise.
* c-pretty-print.cc: Likewise.  Add #include "make-unique.h".
(c_pretty_printer::clone): Use std::unique_ptr and ::make_unique.
* c-pretty-print.h (c_pretty_printer::clone): Use std::unique_ptr.
* c-type-mismatch.cc: Add #define INCLUDE_MEMORY.
* c-warn.cc: Likewise.

gcc/c/ChangeLog:
PR other/116613
* c-aux-info.cc: Add #define INCLUDE_MEMORY.
* c-convert.cc: Likewise.
* c-errors.cc: Likewise.
* c-fold.cc: Likewise.
* c-lang.cc: Likewise.
* c-objc-common.cc: Likewise.
(pp_markup::element_quoted_type::print_type): Use unique_ptr.
* c-typeck.cc: Add #define INCLUDE_MEMORY.
* gimple-parser.cc: Likewise.

gcc/cp/ChangeLog:
PR other/116613
* call.cc: Add #define INCLUDE_MEMORY.
* class.cc: Likewise.
* constexpr.cc: Likewise.
* constraint.cc: Likewise.
* contracts.cc: Likewise.
* coroutines.cc: Likewise.
* cp-gimplify.cc: Likewise.
* cp-lang.cc: Likewise.
* cp-objcp-common.cc: Likewise.
* cp-ubsan.cc: Likewise.
* cvt.cc: Likewise.
* cxx-pretty-print.cc: Likewise.  Add #include "cp-tree.h".
(cxx_pretty_printer::clone): Use std::unique_ptr and
::make_unique.
* cxx-pretty-print.h (cxx_pretty_printer::clone): Use
std::unique_ptr.
* decl2.cc: Add #define INCLUDE_MEMORY.
* dump.cc: Likewise.
* except.cc: Likewise.
* expr.cc: Likewise.
* friend.cc: Likewise.
* init.cc: Likewise.
* lambda.

[Bug c++/115007] [modules] ICE in maybe_clone_body when calling virtual destructor from instantiated template

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:058ed8705a7b38bef2c107b6ff5de243aebd57b4

commit r15-4620-g058ed8705a7b38bef2c107b6ff5de243aebd57b4
Author: Nathaniel Shead 
Date:   Wed Aug 21 00:50:53 2024 +1000

c++/modules: Prevent maybe_clone_decl being called multiple times
[PR115007]

The ICE in the linked PR is caused because maybe_clone_decl is not
prepared to be called on a declaration that has already had clones
created; what happens otherwise is that start_preparsed_function early
exits and never sets up cfun, causing a segfault later on.

To fix this we ensure that post_load_processing only calls
maybe_clone_decl if TREE_ASM_WRITTEN has not been marked on the
declaration yet, and (if maybe_clone_decls succeeds) marks this flag on
the decl so that it doesn't get called again later when finalising
deferred vague linkage declarations in c_parse_final_cleanups.

As a bonus this now allows us to only keep the DECL_SAVED_TREE around in
expand_or_defer_fn_1 for modules which have CMIs, which will have
benefits for LTO performance in non-interface TUs.

For clarity we also update the streaming code to do post_load_decls for
maybe in-charge cdtors rather than any DECL_ABSTRACT_P declaration, as
this is more accurate to the decls affected by maybe_clone_body.

PR c++/115007

gcc/cp/ChangeLog:

* module.cc (module_state::read_cluster): Replace
DECL_ABSTRACT_P with DECL_MAYBE_IN_CHARGE_CDTOR_P.
(post_load_processing): Check and mark TREE_ASM_WRITTEN.
* semantics.cc (expand_or_defer_fn_1): Use the more specific
module_maybe_has_cmi_p instead of modules_p.

gcc/testsuite/ChangeLog:

* g++.dg/modules/virt-6_a.C: New test.
* g++.dg/modules/virt-6_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 115007 Summary: [modules] ICE in maybe_clone_body when calling virtual 
destructor from instantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115007

   What|Removed |Added

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

[Bug c++/115007] [modules] ICE in maybe_clone_body when calling virtual destructor from instantiated template

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Nathaniel Shead  ---
Fixed for GCC 15.

[Bug c++/117285] variadic template operator+, operator- is rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Compilation fails when  |variadic template
   |using template parameter|operator+, operator- is
   |packs to populate operator+ |rejected
   |overload function arguments |

--- Comment #2 from Andrew Pinski  ---
Confirmed. operator- has the same issue.
Both operator- and operator+ have an unary operator and a binary operator. What
this variadic template is implementing both with the same template; GCC rejects
this all the time.

[Bug c++/64178] rejects-valid on variadic operator++

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

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

--- Comment #2 from Andrew Pinski  ---
It turns out GCC does not support variadic templates for any of the operators
that have 1/2 operand forms (operator-, operator+ too); see PR 117285 for that.

[Bug c++/113814] [modules] canonical types ICE with imported partial specialization matching existing template-id

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:6aba48a8cc128e54ee243d451ac9a843ff41c4f9

commit r15-4622-g6aba48a8cc128e54ee243d451ac9a843ff41c4f9
Author: Nathaniel Shead 
Date:   Thu Oct 24 18:10:52 2024 +1100

c++/modules: Propagate some missing flags on type definitions

Noticed while testing my fix for PR c++/113814.  Not all of these are
easily testable but I've tested a couple that were straight-forward.

For consistency also adds a new TYPE_WARN_IF_NOT_ALIGN_RAW flag to match
the decl version Nathan added.

gcc/cp/ChangeLog:

* module.cc (trees_in::read_class_def): Propagate some missing
flags from the streamed-in definition.

gcc/ChangeLog:

* tree.h (TYPE_WARN_IF_NOT_ALIGN_RAW): New accessor.
(TYPE_WARN_IF_NOT_ALIGN): Use it.
(SET_TYPE_WARN_IF_NOT_ALIGN): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/class-10_a.H: New test.
* g++.dg/modules/class-10_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug middle-end/117271] [13/14/15 regression] GCC trunk emits larger code at -Os than 12.4.0

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
   Keywords||missed-optimization

[Bug tree-optimization/117279] std::string bounds check from -D_GLIBCXX_ASSERTIONS not optimised out

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

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

--- Comment #4 from Richard Biener  ---
it's because p points to itself and thus p.ptr[index] "points to" p:

  p.ptr = &p.local_buf;
..
  _4 = p.ptr;
  _5 = _4 + index_11(D);
  _6 = *_5;
  _7 = (int) _6;
  __builtin_printf ("%c\n", _7);

points-to does not use range-info to see that _4 + index_11(D) doesn't
access p.ptr.  In the end any non-constant pointer offsetting will cause
us to consider the whole object.

This could in theory be improved with (static) range-info.

[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats

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

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

--- Comment #29 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r15-4615-gb3aa301db1b09b533b3635791a98d6bf906e9a15
Author: Thomas Schwinge 
Date:   Thu Oct 24 20:56:21 2024 +0200

Use unique_ptr in more places in pretty_printer/diagnostics:
'gcc/config/gcn/mkoffload.cc' [PR116613]

After recent commit bf43fe6aa966eaf397ea3b8ebd6408d3d124e285
"Use unique_ptr in more places in pretty_printer/diagnostics [PR116613]":

[...]
In file included from
../../source-gcc/gcc/config/gcn/mkoffload.cc:31:0:
../../source-gcc/gcc/diagnostic.h:29:3: error: #error "You must define
INCLUDE_MEMORY before including system.h to use diagnostic.h"
 # error "You must define INCLUDE_MEMORY before including system.h to
use diagnostic.h"
   ^
In file included from ../../source-gcc/gcc/diagnostic.h:34:0,
 from ../../source-gcc/gcc/config/gcn/mkoffload.cc:31:
../../source-gcc/gcc/pretty-print.h:29:3: error: #error "You must
define INCLUDE_MEMORY before including system.h to use pretty-print.h"
 # error "You must define INCLUDE_MEMORY before including system.h to
use pretty-print.h"
   ^
In file included from ../../source-gcc/gcc/diagnostic.h:34:0,
 from ../../source-gcc/gcc/config/gcn/mkoffload.cc:31:
../../source-gcc/gcc/pretty-print.h:280:16: error: 'unique_ptr' in
namespace 'std' does not name a template type
   virtual std::unique_ptr clone () const;
^
In file included from
../../source-gcc/gcc/config/gcn/mkoffload.cc:31:0:
../../source-gcc/gcc/diagnostic.h:585:32: error: 'std::unique_ptr' has
not been declared
   void set_output_format (std::unique_ptr
output_format);
^
[...]

PR other/116613
gcc/
* config/gcn/mkoffload.cc: Add '#define INCLUDE_MEMORY'.

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Currently __gnu_debug::vector::assign does:

  this->_M_invalidate_all();
  this->_M_update_guaranteed_capacity();

But I think it should be:

if (__old_data != _Base::data())
  {
this->_M_invalidate_all();
this->_M_update_guaranteed_capacity();
  }
else if (__old_size < _Base::size())
  this->_M_invalidate_after_nth(_Base::size());

where __old_data and __old_size are _Base::data() and _Base::size() before
calling _Base::assign.

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

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

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

--- Comment #13 from Jakub Jelinek  ---
unsigned char a = 193;
unsigned char *b = &a;

void
foo (void)
{
  unsigned char c[] = { 0, 2, 1, 1, 2, 1, 2, 2, 6, 2, 1, 1, 1, 1, 2, 2, 0,
2, 1, 1, 2, 1, 2, 2, 1, 2, 1, 1, 2, 1, 2, 2, 1, 2,
1, 1, 2, 1, 2, 2, 1, 1, 2, 4, 8, 8, 3, 3, 1, 1, 5,
4, 1, 1, 1, 0, 5, 5, 9, 4, 8, 8, 7, 0, 1, 1 };
}

int
main ()
{
  unsigned char c[] = { 193, 0, 0, 0, 1, 0, 1, 1, 1, 0, 1, 0, 5, 2, 3, 1, 0,
1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 4,
2, 2, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1,
1, 1, 0, 5, 3, 3, 1, 0, 1, 0, 0, 1, 0, 1, 0 };
  if (b[0] != c[0])
__builtin_abort ();
}

I think the bug is during WPA stage, it streams in 2 RAW_DATA_CSTs (one for
each CONSTRUCTOR), but streams out just one.

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> if (__old_data != _Base::data())
>   {
> this->_M_invalidate_all();
> this->_M_update_guaranteed_capacity();
>   }
> else if (__old_size < _Base::size())
>   this->_M_invalidate_after_nth(_Base::size());

I think we also want:

  else
this->_M_update_guaranteed_capacity();

For the case where new elements are inserted into existing capacity without
reallocating.

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> else if (__old_size < _Base::size())

And that should be > not <

[no subject]

[gg g via Gcc-bugs]

🙏ขออนุญาตแนะนำสำหรับเจ้าของธุรกิจ
ที่จดทะเบียนการค้า/พาณิชย์/ หจก. อุตสาหกรรมทั่วไป
ทุนหมุนเวียนระยะสั้น อนุมัติง่าย
☑️เริ่มต้น 1.5% - 0.5%
☑️อนุมัติสูงสุด 3,000,000 บาท
☑️ทราบผล ภายใน 30 นาที (หลังส่งเอกสารครบถ้วน)
☑️พร้อมลงพื้นที่ประเมินหน้างานและทำสัญญา
❌ไม่มีนโยบายเรียกชำระก่อนทำสัญญาทุกกรณี❌
✔️สนใจบริการของเราโทรด่วนหาเรา
ติดต่อ : 082-5928-519 คุณเอก
LINE : ID esc.credit
ต้องขออภัยอีกครั้งหากข้อความนี้เป็นเหตุรบกวนคะ🙏

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 59416 [details]
> gcc15-pr117249-2.patch
> 
> Untested patch to change the gcc_assert definition.

Unfortunately this doesn't work, there are various places which use gcc_assert
inside of comma expressions.
So, I think I'll just use statement expression around it and add GCC_VERSION >=
2007.

(In reply to Alexander Monakov from comment #12)
> On IRC Jakub mentioned gcc_assert (token() == TYPEDEF) in gengtype and Richi
> further noted
> 
> config/ia64/ia64.cc:gcc_assert ((code = recog_memoized (insn)) ==
> CODE_FOR_nop

I'm not convinced we need to change this one, yes, it has side-effects, but I
think the code doesn't really care if that wouldn't happen.

> df-scan.cc:gcc_assert (df_reg_chain_mark (DF_REG_DEF_CHAIN (i), i, true,
> false)

And neither this.  First of all, one could get here only in --disable-checking
build with explicit -fchecking, and I think nothing really cares if the
side-effects don't happen, this is just df verification which just attempts to
verify whether what df normally computed matches what would be computed from
scratch.

[Bug target/117283] New: [RISC-V] Miscompilation triggered by `__riscv_vsseg7e32_v_i32m1x7`, GCC 14.2.0 at `-O1`, `-O2`, `-O3`, and `-Os`.

[yibohe at pku dot edu.cn via Gcc-bugs]

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

Bug ID: 117283
   Summary: [RISC-V] Miscompilation triggered by
`__riscv_vsseg7e32_v_i32m1x7`, GCC 14.2.0 at `-O1`,
`-O2`, `-O3`, and `-Os`.
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yibohe at pku dot edu.cn
  Target Milestone: ---

For the following code with rvv intrinsics, I load data from a to c, and from b
to d.
There seems to be a miscompilation:
```
#include 
int printf(const char *, ...);
#define dataLen 520
int32_t a[dataLen]; int32_t b[dataLen];
int32_t c[dataLen]; int32_t d[dataLen];
int main(){
  int32_t tmp_a[dataLen] = {-48, 111, -33, 24, 127, -88, -60, -106, 62, 125,
-18, 120, 99, -94, 107, -70, 8, -105, -126, 127, 61, -75, 124, 21, 88, -79, 74,
105, -85, 6, -107, 31, -38, -52, 70, -55, 71, 19, 70, 18, 114, 75, 90, 81, 90,
-11, 33, 76, 1, -23, 54, -33, 89, 90, -128, 50, -28, 28, 7, -1, 12, 21, -86,
-32, 39, 94, 91, 22, -20, -81, 84, 71, -20, -113, -67, 71, -60, 48, -10, 15,
-42, 22, 67, 119, -103, -73, -89, 108, 58, 4, 12, 35, -59, -53, -33, -31, -108,
-25, -56, -112, 39, 111, -52, -104, -25, 5, 78, -28, -46, 33, 29, 22, -45,
-124, -33, -79, 87, 105, 122, 88, 94, -37, 94, 74, -118, 60, 115, -95, -128,
-114, -34, -26, -65, -75, -40, 125, 66, 88, 120, -119, 50, -44, 1, -41, -33,
-42, 48, 32, 45, 62, -77, -96, 110, -111, -100, -33, 21, -5, -17, 22, -77, -36,
68, 2, -25, -79, -110, -127, 43, 45, 70, 52, 7, -24, 26, -15, -3, -40, 55, 95,
71, -27, 70, 107, -10, 115, -85, 29, 125, -28, -111, 44, -61, 81, 89, -69, -8,
-23, 122, 52, 38, -101, -126, 5, -123, 26, 29, 81, 100, 43, -113, -66, -79,
-42, 113, 22, -69, 77, -5, -16, 8, -75, 124, -67, 98, -117, -24, -108, -38,
113, -123, -119, 120, 75, -116, -24, -95, 83, -86, 66, -85, -35, -79, -83, -63,
-72, -106, -47, -48, 86, -37, 9, -23, -125, 27, -75, -64, -73, -63, -114, -62,
93, 15, 94, -77, -16, -115, -17, -64, -113, -61, -85, -124, -50, 48, 30, -93,
52, 36, 92, 8, 75, 53, 63, -67, 13, -31, 62, 79, 48, 115, 54, 4, 88, -26, 77,
-71, 102, 80, -97, 57, 32, -108, -25, -85, 10, -105, -73, -14, -115, -33, -4,
-55, 6, -58, 6, 88, 25, 31, -32, 48, -87, 14, -111, 1, -1, 32, -74, 122, 79,
-41, -71, 93, 64, 34, 28, 81, 13, 96, 102, 50, 126, 107, -91, -86, 48, -66,
-106, -24, 101, -48, 122, -49, -77, 18, 112, -36, -128, -19, -82, -78, 106,
-52, 120, 19, 86, 74, -26, -53, -26, -71, -35, 122, -96, 46, 124, 51, -44, 50,
-113, 31, -59, -125, 81, -17, -15, 7, -36, -30, 85, -127, -60, 84, -17, -88,
64, 101, -104, -12, -36, 33, -34, -23, -121, 77, 8, 111, -60, 74, 89, 60, 127,
-48, -111, 88, -77, -114, -109, -110, 16, 27, 38, 13, -5, -111, 124, -4, 55,
-128, 87, -32, -54, -54, -100, -57, -12, 37, -31, 80, 50, 64, 32, 10, 5, 77,
127, 22, -11, -116, -4, -19, 96, -50, 0, 9, -80, 62, -48, -98, -128, -96, -25,
3, 68, 41, -47, -39, 70, 122, -8, -105, -112, -78, -38, 67, -111, 1, 22, -63,
27, 29, -122, -33, 74, 47, 109, 14, 51, 79, 72, 108, -26, -30, 60, 20, -55,
109, -3, 1, -103, -52, 73, -33, -127, -3, -22, 59, 83, -23, 5, -104, 53, 41,
98, 89, -83, -72, 63, 69, -10, };
  int32_t tmp_b[dataLen] = {56, 126, -104, -122, 36, -39, 78, 24, -51, 25, -59,
-51, 117, 53, -98, 79, 102, 61, -31, -109, 126, 31, -34, 6, -103, -70, -36,
-65, -65, 98, -121, -4, -19, -83, -40, -110, -12, 73, -74, 26, -56, -71, 66,
-70, -16, -110, -48, -46, -112, -74, -104, -25, 48, 122, 52, 37, -82, -14, 102,
104, -86, 44, 99, 105, -78, 45, -49, 18, -108, 115, -22, -58, -75, 107, 126,
-21, 45, -127, 42, 80, 36, -85, -7, 107, -14, -103, -52, -25, -78, 116, -67,
64, 49, 23, 74, 26, 77, -58, 68, 86, -73, -108, -54, 12, 96, 19, -4, -73, -112,
-7, -10, 102, -26, 99, 110, -26, 94, -72, -111, -68, -55, -100, 118, -56, -38,
124, 76, -61, 107, 43, -105, 25, -81, -42, 6, -126, -66, -57, 44, 57, -10,
-108, -9, -118, 33, -64, 15, 72, -33, 49, 105, 36, 30, 100, -62, 76, -8, -69,
-78, -11, -26, -46, 54, -16, -46, -17, -111, 92, -27, -29, -22, -83, -46, 2,
57, 105, -101, -28, -105, 94, -104, 1, 123, 97, 43, 41, 23, 107, -78, 97, -93,
-91, 33, 9, 69, -50, -81, 126, 90, 17, 29, 96, 33, 57, -113, -17, -2, -62, -59,
-21, 88, 2, 71, -23, 89, -8, -111, -80, 69, 64, 48, -114, 93, -14, -38, -68,
32, 65, 107, 1, -115, -80, -6, 101, -62, -108, 91, 123, -80, -124, -98, 42,
-15, 37, 30, 105, -67, 69, -125, -28, -46, -99, 53, -63, -124, 89, 78, 38, -69,
80, -108, 87, -53, 121, 51, 82, 108, 41, 1, -122, -25, 107, 99, 102, 25, 42,
-3, -75, -65, -112, 22, -105, 108, 76, -83, -121, -99, 33, 60, -91, 110, -77,
-66, -7, 59, 51, 124, -86, 13, 47, 82, -45, 27, 69, 107, -124, -8, -103, -1,
20, 117, 83, 85, -83, 112, 73, -116, 10, -110, 103, -14, -24, 19, -31, -122,
64, 25, -39, -73, -87, -53, -70, 61, 123, -47, 113, 83, -59, -99, -50, -119,
-66, -86, -98, -56, 49, -97, 62, 20, -57, 17, -75, 6, 119, 93, 102, 114, 65,
-118, -123, 90, -111, 37, -62, 

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org

--- Comment #5 from Nathaniel Shead  ---
Looking at recent posts to the gcc-testresults mailing list, and noting that a
number of fixes have been made to these testcases over the last couple of
years, I hazard that this bug is probably resolved?

[Bug sanitizer/117209] [13/14/15 Regression] ICE: verify_gimple failed with asan.

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

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

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

https://gcc.gnu.org/g:885143fa77599c44bfdd4e8e6b6987b7824db6ba

commit r15-4594-g885143fa77599c44bfdd4e8e6b6987b7824db6ba
Author: Jakub Jelinek 
Date:   Thu Oct 24 12:45:34 2024 +0200

asan: Fix up build_check_stmt gsi handling [PR117209]

gsi_safe_insert_before properly updates gsi_bb in gimple_stmt_iterator
in case it splits objects, but unfortunately build_check_stmt was in
some places (but not others) using a copy of the iterator rather than
the iterator passed from callers and so didn't propagate that to callers.
I guess it didn't matter much before when it was just using
gsi_insert_before as that really didn't change the iterator.
The !before_p case is apparently dead code, nothing is calling it with
before_p=false since around 4.9.

2024-10-24  Jakub Jelinek  

PR sanitizer/117209
* asan.cc (maybe_cast_to_ptrmode): Formatting fix.
(build_check_stmt): Don't copy *iter into gsi, perform all
the updates on iter directly.

* gcc.dg/asan/pr117209.c: New test.

[Bug sanitizer/117259] [12/13/14/15 Regression] warning: 'j.6' may be used uninitialized [-Wmaybe-unitialized] with -fsanitize=undefined

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

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

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

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

commit r15-4595-gb25d3201b6338d9f71c64f524ca2974d9a1f38e8
Author: Jakub Jelinek 
Date:   Thu Oct 24 12:56:19 2024 +0200

c++: Further fix for get_member_function_from_ptrfunc [PR117259]

The following testcase shows that the previous
get_member_function_from_ptrfunc
changes weren't sufficient and we still have cases where
-fsanitize=undefined with pointers to member functions can cause wrong code
being generated and related false positive warnings.

The problem is that save_expr doesn't always create SAVE_EXPR, it can skip
some invariant arithmetics and in the end it could be really large
expressions which would be evaluated several times (and what is worse, with
-fsanitize=undefined those expressions then can have SAVE_EXPRs added to
their subparts for -fsanitize=bounds or -fsanitize=null or
-fsanitize=alignment instrumentation).  Tried to just build1 a SAVE_EXPR
+ add TREE_SIDE_EFFECTS instead of save_expr, but that doesn't work either,
because cp_fold happily optimizes those SAVE_EXPRs away when it sees
SAVE_EXPR operand is tree_invariant_p.

So, the following patch instead of using save_expr or building SAVE_EXPR
manually builds a TARGET_EXPR.  Both types are pointers, so it doesn't need
to be destroyed in any way, but TARGET_EXPR is what doesn't get optimized
away immediately.

2024-10-24  Jakub Jelinek  

PR c++/117259
* typeck.cc (get_member_function_from_ptrfunc): Use
force_target_expr
rather than save_expr for instance_ptr and function.  Don't call it
for TREE_CONSTANT.

* g++.dg/ubsan/pr117259.C: New test.

[Bug target/117283] [RISC-V] Miscompilation triggered by `__riscv_vsseg7e32_v_i32m1x7`, GCC 14.2.0 at `-O1`, `-O2`, `-O3`, and `-Os`.

[yibohe at pku dot edu.cn via Gcc-bugs]

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

--- Comment #1 from Yibo He  ---
The data initialization is long, because I find that this bug is triggered when
long data input. If anyone has a better submission format for code like this,
please let me know.

[Bug libstdc++/117284] New: Debug Mode vector invalidates all iterators on assignment

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

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

Bug ID: 117284
   Summary: Debug Mode vector invalidates all iterators on
assignment
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I don't see why the iterator should be invalidated here:

#define _GLIBCXX_DEBUG
#include 

int main()
{
  std::vector v(3);
  auto i = v.begin();
  v.assign(2, 0);
  v.assign({1,2,3});
  return *i;
}

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #59415|0   |1
is obsolete||

--- Comment #14 from Jakub Jelinek  ---
Created attachment 59429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59429&action=edit
gcc15-pr117249-1.patch

Updated version of the first patch.

[Bug testsuite/117274] [14 Regression] New test case g++.dg/cpp2a/decomp10.C from r14-10826-g7de78f7353f125 fails

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, testsuite-fail
   Target Milestone|--- |14.3
Summary|New test case   |[14 Regression] New test
   |g++.dg/cpp2a/decomp10.C |case
   |from|g++.dg/cpp2a/decomp10.C
   |r14-10826-g7de78f7353f125   |from
   |fails   |r14-10826-g7de78f7353f125
   ||fails

[Bug c++/117107] [14/15 Regression] ICE with structured binding (not with std::tuple_size/tuple_element) and decltype inside a template

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

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

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

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

commit r14-10833-g2d47645cd47c9a84a69343b641a6ee741a85dc75
Author: Jason Merrill 
Date:   Thu Oct 24 11:13:30 2024 -0400

c++: remove dg-warning [PR117274]

This warning was added for GCC 15, don't expect it.

PR c++/117274
PR c++/117107

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/decomp10.C: Remove captured binding warning.

[Bug testsuite/117274] [14 Regression] New test case g++.dg/cpp2a/decomp10.C from r14-10826-g7de78f7353f125 fails

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/115274] [14/15 regression] Bogus -Wstringop-overread in SQLite source code

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #14 from qinzhao at gcc dot gnu.org ---
with my work-in-progress patch, for the creduced small testing case, I got the
following diagnostic when adding -fdiagnostics-explain-harder:
t_115274.c:4:25: warning: ‘strlen’ reading 1 or more bytes from a region of
size 0 [-Wstringop-overread]
4 | int b(char *d) { return strlen(d); }
  | ^
  ‘e’: events 1-2
4 | int b(char *d) { return strlen(d); }
  | ~
  | |
  | (2) out of array bounds here
..
8 |   if (c == 0)
  |  ^
  |  |
  |  (1) when the condition is evaluated to true
In function ‘e’:
cc1: note: source object is likely at address zero

Looks like a helpful diagnostic to the user.

[Bug c++/117280] Accessing a reference member of a volatile-qualified class glvalue is misinterpreted as volatile read

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #1 from Jiang An  ---
I've realize that the original example seems invalid because the temporary
object shouldn't be usable in constant evaluations (as it's of a volatile type
due to reference binding).

But this one (accidently?) has the same effects.


```
struct S { const int& ref; };
constexpr int n = 42;
constexpr volatile S s{n};

static_assert(s.ref == 42, "");
```

[Bug target/50779] always_inline function fails to inline

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
I suspect this was fixed in GCC 7 (via PR 88568) but I have no way to check
really. I did check the trunk and it compiles just fine.

[Bug c/117290] New: error: void value not ignored , pointing to the wrong function

[markgaleck at gmail dot com via Gcc-bugs]

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

Bug ID: 117290
   Summary: error: void value not ignored , pointing to the wrong
function
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markgaleck at gmail dot com
  Target Milestone: ---

Created attachment 59433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59433&action=edit
source SSCCE.c preprocessed with:

version of gcc: 10.1.0

$cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
(...)

command line that triggers the bug:

$gcc -Wall -lc SSCCE.c
SSCCE.c: In function ‘main’:
SSCCE.c:7:6: error: void value not ignored as it ought to be
7 |  if (access("", F_OK) ?
  |  ^~



Compiling this code snippet:

if (access("", F_OK) ?
0 ? 0 : exit(0) 
:
0)

gcc says:

foobar.c:7:6: error: void value not ignored as it ought to be
7 |  if (access("", F_OK) ?
  |  ^~

So it is pointing to "access", but that is not where the problem is.  The
problem is that the void return from "exit" is not ignored.

[Bug target/117291] New: Simple but large test case uses up over 8M of stack and hits SEGV

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

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

Bug ID: 117291
   Summary: Simple but large test case uses up over 8M of stack
and hits SEGV
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Compiling the attached simple but large test case, we seem to run out of stack
space which causes an ICE.  The test case declares 70K global variables and the
function just returns the sum of them all.

I'm not sure whether we consider this a bug or not, but thought I'd report to
see what others think.  Is running out of 8M of stack space in the compiler a
bug or not?

bergner@ltcden2-lp1:ICE$ ulimit -s
8192
bergner@ltcden2-lp1:ICE$ /opt/gcc-nightly/trunk/bin/gcc -S test.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
bergner@ltcden2-lp1:ICE$ ulimit -s unlimited
bergner@ltcden2-lp1:ICE$ /opt/gcc-nightly/trunk/bin/gcc -S test.c
bergner@ltcden2-lp1:ICE$ 


The gdb backtrace looks like:

#0  0x108e9274 in IS_ADHOC_LOC (loc=0) at
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/../libcpp/include/line-map.h:589
#1  0x138c6cb4 in get_location_from_adhoc_loc (set=0x77f5,
loc=2147524555)
at /home/bergner/gcc/gcc-fsf-mainline-base/libcpp/line-map.cc:312
#2  0x11f03a94 in get_nowarn_spec (expr=)
at /home/bergner/gcc/gcc-fsf-mainline-base/gcc/warning-control.cc:92
#3  0x11f03ca8 in warning_suppressed_p (expr=, opt=OPT_Woverflow)
at /home/bergner/gcc/gcc-fsf-mainline-base/gcc/warning-control.cc:123
#4  0x109e2970 in c_fully_fold_internal (expr=, in_init=false, maybe_const_operands=0x7fffd9d4, 
maybe_const_itself=0x7fffd9d5, for_int_const=false, lval=false) at
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/c/c-fold.cc:158
#5  0x109e3b20 in c_fully_fold_internal (expr=, in_init=false, maybe_const_operands=0x7fffd9d4, 
maybe_const_itself=0x7fffd9d5, for_int_const=false, lval=false) at
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/c/c-fold.cc:355
#6  0x109e3b20 in c_fully_fold_internal (expr=, in_init=false, maybe_const_operands=0x7fffd9d4, 
maybe_const_itself=0x7fffd9d5, for_int_const=false, lval=false) at
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/c/c-fold.cc:355
#7  0x109e3b20 in c_fully_fold_internal (expr=, in_init=false, maybe_const_operands=0x7fffd9d4, 
maybe_const_itself=0x7fffd9d5, for_int_const=false, lval=false) at
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/c/c-fold.cc:355
...

[Bug target/117292] [15 Regression] ICE: in aarch64_output_simd_imm, at config/aarch64/aarch64.cc:25422 at -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/117292] New: [15 Regression] ICE: in aarch64_output_simd_imm, at config/aarch64/aarch64.cc:25422 at -Os

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117292
   Summary: [15 Regression] ICE: in aarch64_output_simd_imm, at
config/aarch64/aarch64.cc:25422 at -Os
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -Os testcase.c 
during RTL pass: final
testcase.c: In function 'foo0':
testcase.c:41:1: internal compiler error: in aarch64_output_simd_imm, at
config/aarch64/aarch64.cc:25422
   41 | }
  | ^
0x26c25de internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0xc50e93 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1580
0x957d62 aarch64_output_simd_imm(rtx_def*, unsigned int, simd_immediate_check)
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:25422
0xf699fa final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2774
0xf69f3b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2887
0xf6a14d final_1
/repo/gcc-trunk/gcc/final.cc:1978
0xf6ad88 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4241
0xf6ad88 execute
/repo/gcc-trunk/gcc/final.cc:4319
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.


$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-4622-20241025083800-g6aba48a8cc1-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-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-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r15-4622-20241025083800-g6aba48a8cc1-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241024 (experimental) (GCC)

[Bug c/117288] New: [15 Regression] LTO ICE in output_constructor_regular_field at varasm.cc:5644 on wolfssl-5.7.2

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

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

Bug ID: 117288
   Summary: [15 Regression] LTO ICE in
output_constructor_regular_field at varasm.cc:5644 on
wolfssl-5.7.2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially observed ICE on wolfssl-5.7.2 built in LTO mode.

Current gcc-master from r15-4622-g6aba48a8cc128e still crashes.

Single-file reproducer:

// $ cat api.c
typedef unsigned char byte;

__attribute__((noipa)) static void use(const void*) {}

static void test_wolfSSL_dtls_send_ch(void)
{
byte ch_msg[81] = {
0x16, 0xfe, 0xfd, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0xfa, 0x01, 0x00, 0x01,
0xee, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0xee, 0xfe, 0xfd, 0xc0, 0xca, 0xb5, 0x6f, 0x3d,
0x23, 0xcc, 0x53, 0x9a, 0x67, 0x17, 0x70, 0xd3,
0xfb, 0x23, 0x16, 0x9e, 0x4e, 0xd6, 0x7e, 0x29,
0xab, 0xfa, 0x4c, 0xa5, 0x84, 0x95, 0xc3, 0xdb,
0x21, 0x9a, 0x52, 0x00, 0x00, 0x00, 0x36, 0x13,
0x01, 0x13, 0x02, 0x13, 0x03, 0xc0, 0x2c, 0xc0,
0x2b, 0xc0, 0x30, 0xc0, 0x2f, 0x00, 0x9f, 0x00,
0x9e,
};

use(&ch_msg);
}

static void test_wc_AesEaxVectors(void)
{
typedef struct {
byte key[32];
int key_length;
byte iv[32];
int iv_length;
byte aad[16 * 2];
int aad_length;
byte msg[16 * 5];
int msg_length;
byte ct[16 * 5];
int ct_length;
} AadVector;

const AadVector vector =
{
/* key, key length  */
{0x00, }, 16,
/* iv, iv length  */
{0x4f, }, 16,
/* aad, aad length  */
{0x00}, 0,
/* msg, msg length  */
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22,
 0x33, 0x33, 0x33, 0x33, 0x33, 0x33, 0x33, 0x33,
 0x33, 0x33, 0x33, 0x33, 0x33, 0x33, 0x33, 0x33,
 0x44, 0x44, 0x44, 0x44, 0x44, 0x44, 0x44, 0x44,
 0x44, 0x44, 0x44, 0x44, 0x44, 0x44, 0x44, 0x44}, 80,
/* ct, ct length  */
{0xe9, }, 80,
};

use(vector.msg);
}

int main(void) {
use(&test_wc_AesEaxVectors);
use(&test_wolfSSL_dtls_send_ch);
}

Crashing:

$ gcc/xgcc -Bgcc api.c -o a.bug -flto
during RTL pass: final
api.c: In function ‘test_wc_AesEaxVectors’:
api.c:65:1: internal compiler error: in output_constructor_regular_field, at
varasm.cc:5644
   65 | }
  | ^
0x23f9bcf diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x240b89b internal_error(char const*, ...)
???:0
0x23f6aa0 fancy_abort(char const*, int, char const*)
???:0
0x125a968 output_constructor(tree_node*, unsigned long, unsigned int, bool,
oc_outer_state*)
???:0
0x12597a3 output_constant(tree_node*, unsigned long, unsigned int, bool, bool)
???:0
0x1259847 assemble_constant_contents(tree_node*, char const*, unsigned int,
bool)
???:0
0x125ff82 output_constant_def_contents(rtx_def*)
???:0
0x1260064 mark_constants_in_pattern(rtx_def*)
???:0
0x12658e2 assemble_start_function(tree_node*, char const*)
???:0
0x9b29dd (anonymous namespace)::pass_final::execute(function*)
???:0
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.
lto-wrapper: fatal error: gcc/xgcc returned 1 exit status
compilation terminated.
/nix/store/vcvhwiilizhijk7ywyn58p9l005n9sbn-binutils-2.43.1/bin/ld: ошибка:
lto-wrapper failed
collect2: error: ld returned 1 exit status

$ gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer --enable-languages=c
CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0' --enable-lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241024 (experimental) (GCC)

[Bug c/117288] [15 Regression] LTO ICE in output_constructor_regular_field at varasm.cc:5644 on wolfssl-5.7.2

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Sergei Trofimovich  ---
I did not bisect but I strongly suspect r15-4377-gf9bac238840155.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #409 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #407)
> (In reply to John Paul Adrian Glaubitz from comment #406)
> > (In reply to John Paul Adrian Glaubitz from comment #405)
> > > File too large to be attached, so uploading it here:
> > > 
> > > https://people.debian.org/~glaubitz/pr-55212-404.tgz
> > 
> > Ping.
> 
> Can you try to reduce the case?  That would be helpful.
> 
> Basically, try to remove code from the .i / .ii file until it stops failing.
> 
> https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

I was hoping for Kaz to have another look. If he doesn't have the time, I can
give it a try over the weekend.

Is there a good manual for reducing and testing intermediate files?

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Seems to have been fixed between r15-3043-g64028d626a5 and
r15-3205-g9522fc8bb78.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|4.6.3   |4.7.0

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #13 from Hans-Peter Nilsson  ---
The proposal makes sense to me too, particularly after reading the docs.
(Unless there's already a way to silence the warning for particular
constructs?)
Why are you all talking about C++?  Yes, the docs mention C++ but this is a
request for C.

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

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

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Hans-Peter Nilsson from comment #13)
> The proposal makes sense to me too, particularly after reading the docs.
> (Unless there's already a way to silence the warning for particular
> constructs?)
> Why are you all talking about C++?  Yes, the docs mention C++ but this is a
> request for C.

Because Wunterminated-string-initialization was added to warn about a
difference between c and c++ too.

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

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

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

--- Comment #15 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #14)
> 
> > Why are you all talking about C++?  Yes, the docs mention C++ but this is a
> > request for C.
> 
> Because Wunterminated-string-initialization was added to warn about a
> difference between c and c++ too.

Again: yes, the docs mention C++, but this is a request for C.

[Bug c/117291] Simple but large test case uses up over 8M of stack and hits SEGV

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

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

--- Comment #2 from Andrew Pinski  ---
I am not sure if there is not much to be done.
The front-end is recusive here:
  /* Binary operations evaluating both arguments (increment and
 decrement are binary internally in GCC).  */
  orig_op0 = op0 = TREE_OPERAND (expr, 0);
  orig_op1 = op1 = TREE_OPERAND (expr, 1);
  op0 = c_fully_fold_internal (op0, in_init, maybe_const_operands,
   maybe_const_itself, for_int_const,
   op0_lval);
  STRIP_TYPE_NOPS (op0);
  /* The RHS of a MODIFY_EXPR was fully folded when building that
 expression for the sake of conversion warnings.  */
  if (code != MODIFY_EXPR)
op1 = c_fully_fold_internal (op1, in_init, maybe_const_operands,
 maybe_const_itself, for_int_const, false);
  STRIP_TYPE_NOPS (op1);

  if (for_int_const && (TREE_CODE (op0) != INTEGER_CST
|| TREE_CODE (op1) != INTEGER_CST))
goto out;

[Bug c/117291] Simple but large test case uses up over 8M of stack and hits SEGV

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-10-25
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
How do you generate this code from a code generator?

I don't think this is a bug. If it was code in the wild, then I would say this
might be something we should look into but since I suspect this was generated
from a code generator then it is not as important.

[Bug c/117291] Simple but large test case uses up over 8M of stack and hits SEGV

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

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

--- Comment #3 from Andrew Pinski  ---
You could possibility change this function to use a worklist instead. But I am
not sure having a tree depth this large is in normal code.

[Bug c/117290] error: void value not ignored , pointing to the wrong location when ?: is used inside an if

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

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

--- Comment #2 from Andrew Pinski  ---
This has the same issue:
```
void f(int t) {
 if (0 ?  __builtin_exit(0) : 0)
   ;
}
```

[Bug tree-optimization/117279] std::string bounds check from -D_GLIBCXX_ASSERTIONS not optimised out

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
I think this is a dup.

[Bug tree-optimization/117282] New: Miss optimization to eliminate strlen computation

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 117282
   Summary: Miss optimization to eliminate strlen computation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

GCC could handle elimination of strlen call if its result is only used as a
boolean flag, like:

void foo(char *s)
{
if (strlen(s))
printf("OK\n");
}

But it fails to do similar strength reduction on a loop that explicitly
implements the semantics of strlen computation, here are some examples:

void foo(char *s)
{
char *t;

for (t = s; ; t++) {
if (!*t)
break;
}

if (t != s)
printf("OK\n");

}

void foo(char *s)
{
int i;

for (i = 0; i < 1; i++) {
if (!s[i])
break;
}

if (i)
printf("OK\n");
}

Besides, it seems to be a common usage that strlen's result would be cast to
"int" or "unsigned int". Since such conversion might involves non-trivial
integer truncation, the above elimination should not be applied for sure.

void foo(char *s)
{
if ((unsigned)strlen(s))  // strlen is not eliminable
printf("OK\n");
}

Normally, with workload in reality, a string or data object would not be super
large, for which measurement up to gigabytes would be rare case. So the
conversion would not introduce alteration of result, could be ignored regarding
the elimination.

Currently, gcc has a code-model option -mcmodel, which specifies scale of
data/text segment. Is it feasible that we rely on this option to peel away
conversion losslessly in this optimization? If so, there is one point that
needs to be clearly defined or extended. 

Take aarch64 for example, given -mcmodel=small, it only states that static data
is within 4G bytes. However, for such kind of small application, it could
allocate a dynamic data at runtime exceeding 4G, which is not only possible,
but also common-seen. 

To target the subtle difference around here, could we introduce a new option
like -mcmodel-dyn{=tiny/small/large} as a supplement to -mcmodel, which says
that dynamic data object has limit constraint in the similar way of -mcmodel,
its default value is unlimited {=large)?

[Bug c++/117281] New: Concepts and variadic template: internal compiler error

[weidmann at acm dot org via Gcc-bugs]

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

Bug ID: 117281
   Summary: Concepts and variadic template: internal compiler
error
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weidmann at acm dot org
  Target Milestone: ---

g++ (Compiler-Explorer-Build-gcc--binutils-2.42) 14.2.0

Getting an internal compiler error when compiling the following code with 'g++
-std=c++20'

#include 
#include 

template using always_string = std::string;

template typename T> struct first_ok {
T value;
};

first_ok first;

template typename T> struct second_ok {
T value;
};

second_ok second;

template typename T> struct triggers_bug {
T value;
};

triggers_bug bad;

[Bug target/106329] No optimization for SVE pfalse predicate

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

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

Jennifer Schmitz  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jschmitz at gcc dot 
gnu.org
Version|12.1.0  |15.0
 Status|NEW |ASSIGNED

--- Comment #2 from Jennifer Schmitz  ---
.

[Bug c++/107084] Program does not link with Standard Library Header Unit but with correspoding #include

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Nathaniel Shead  ---
This appears to work now, so fixed.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 107084 Summary: Program does not link with Standard Library Header Unit but 
with correspoding #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107084

   What|Removed |Added

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

[Bug c++/117272] CWG2518 static_assert(false) when returning

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Kellnberger from comment #0)
> Since gcc 13 this is valid code:
> 
> ```C++
> template void f(){
> static_assert(false);
> }

Only because this function template is never instantiated.

> int main() {
> 
> }
> ```
> 
> This is as well:
> 
> ```C++
> #include 
> 
> template void f(){
> if constexpr(std::is_same_v) {
> 
> } else {
> static_assert(false);
> }
> }
> 
> int main() {
> f();
> }
> ```
> 
> The `static_assert(false)` is ignored if it is not reached due to
> templating.

It's not that it's not "reached", because this isn't about control flow. It's
about whether it's in a discarded statement or not. A discarded statement in a
function template is not instantiated at all. The static_assert is not even
part of the function when the type is int.

> If I placed it into the `if` block instead the code would be
> ill-formed.

Yes, because when the type is int the static_assert(false) would be
instantiated.

> By the same logic the following should be valid, but it is not.

No, because it's literally not "the same logic".

In your last example the static_assert(false) is not in a discarded statement
so is always instantiated by every specialization of the function. It's just
like your first example which is ill-formed if ever called. Returning "before"
the static_assert doesn't make any difference. A static_assert is checked when
the function is instantiated at compile time, not when it's executed at
runtime.

[Bug tree-optimization/117282] Miss optimization to eliminate strlen computation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/117282] Miss optimization to eliminate strlen computation

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>Is it feasible that we rely on this option to peel away conversion losslessly 
>in this optimization?

No because you could do a malloc of a big size. The smallest limit for an
example is 39bits addressing on aarch64 (512GB) for the VA space.


Othewise, in first case, we have missing a VRP:
  if (_9 == 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 955630224]:
  # t_10 = PHI 
  t_6 = t_10 + 1;
  _1 = MEM[(char *)t_6];
  if (_1 == 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 105119324]:
  if (s_4(D) != t_6)
goto ; [60.08%]
  else
goto ; [39.92%]


t_6 can never be s_4(D) due to pointer overflowing being undefined.

in the second case we could peel off the first iteration of the loop and it
would work:
;;   basic block 3, loop depth 1, count 1063004408 (estimated locally, freq
15.3607), maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 [98.9% (guessed)]  count:993801746 (estimated locally, freq
14.3607) (TRUE_VALUE,EXECUTABLE)
;;2 [always]  count:69202658 (estimated locally, freq 1.)
(FALLTHRU,EXECUTABLE)
  # RANGE [irange] unsigned long [0, ]
  # ivtmp.18_19 = PHI 
  # VUSE <.MEM_8(D)>
  _3 = MEM[(charD.10 *)s_7(D) + ivtmp.18_19 * 1];
  if (_3 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]
;;succ:   5 [5.5% (guessed)]  count:58465242 (estimated locally, freq
0.8448) (TRUE_VALUE,EXECUTABLE)
;;4 [94.5% (guessed)]  count:1004539166 (estimated locally,
freq 14.5159) (FALSE_VALUE,EXECUTABLE)

;;   basic block 4, loop depth 1, count 1004539166 (estimated locally, freq
14.5159), maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [94.5% (guessed)]  count:1004539166 (estimated locally,
freq 14.5159) (FALSE_VALUE,EXECUTABLE)
  # RANGE [irange] unsigned long [1, 1]
  ivtmp.18_18 = ivtmp.18_19 + 1;
  if (ivtmp.18_18 != 1)
goto ; [98.93%]
  else
goto ; [1.07%]
;;succ:   3 [98.9% (guessed)]  count:993801746 (estimated locally, freq
14.3607) (TRUE_VALUE,EXECUTABLE)
;;6 [1.1% (guessed)]  count:10737420 (estimated locally, freq
0.1552) (FALSE_VALUE,EXECUTABLE)

So multiple cases.

Does this code show up in a benchmark?

[Bug tree-optimization/117282] Miss optimization to eliminate strlen computation

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

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

--- Comment #2 from Andrew Pinski  ---
>could we introduce a new option like -mcmodel-dyn{=tiny/small/large} as a 
>supplement to -mcmode

This would cause too many confusion really. especially depending on the
definition of your tiny/small/large. I rather see other optimizations happen in
before this kind of hacks.

[Bug c++/117281] Concepts and variadic template: internal compiler error

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

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

--- Comment #3 from Andrew Pinski  ---
here is the ICE on the trunk:
```
:11:27: internal compiler error: tree check: accessed elt 2 of
'tree_vec' with 1 elts in tsubst, at cp/pt.cc:16464
   11 | triggers_bug bad;
  |   ^
0x28739d5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2889c95 internal_error(char const*, ...)
???:0
0x99cda5 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0xce2954 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xb0c5da tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*)
???:0
0xce7763 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xcd6fd9 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
???:0
0xd18b2c finish_template_type(tree_node*, tree_node*, int)
???:0
0xc9b47a c_parse_file()
???:0
0xdf4e29 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

[Bug c++/117281] Concepts and variadic template: internal compiler error

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

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

--- Comment #2 from Andrew Pinski  ---
New reduced testcase:
```
template struct always_string{};

template concept t = true;

template typename T> struct triggers_bug {
T value;
};

triggers_bug bad;
```

To show it is unrelated to a type alias.

[Bug c++/117281] Concepts and variadic template: internal compiler error

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||67491
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-24

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```

template using always_string = int;

template concept t = true;

template typename T> struct triggers_bug {
T value;
};

triggers_bug bad;
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug tree-optimization/117282] Miss optimization to eliminate strlen computation

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #3 from Feng Xue  ---
(In reply to Andrew Pinski from comment #2)
> >could we introduce a new option like -mcmodel-dyn{=tiny/small/large} as a 
> >supplement to -mcmode
> 
> This would cause too many confusion really. especially depending on the
> definition of your tiny/small/large. I rather see other optimizations happen
> in before this kind of hacks.

This code piece(with conversion) exists in SIR17 523.xalanc, 7% improvement if
optimized.

"tiny/small/large" is from "-mcmodel", target specific, or define a middle-end
aware option like: -fdata-object-size="size-limit", default value is hardware
address space. For normal 64-bit "small" application, we could set
"-fdata-object-size=2^32". Actually, this option could also help VRP,
especially pointer-difference operation.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 111049 Summary: spurious stringop-overflow depending on structure pointer 
arithmetic with certain sized structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111049

   What|Removed |Added

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