[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
GCC considered this as a flex-array.  Does the C standard not allow this with
data[]?

[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-4489-g5c11d748564c7ce3b096e87ad350fcddd493e45e
Author: Andrew Pinski 
Date:   Mon Dec 5 09:09:52 2022 +0100

tree-optimization/107956 - ICE with NULL call LHS

The following adds a missing check for a NULL call LHS in the
vector pattern recognizer.

PR tree-optimization/107956
* tree-vect-patterns.cc (vect_recog_mask_conversion_pattern):
Check for NULL LHS on masked loads.

[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:16debfadbd759f9933b4a62029661f01188ad928

commit r12-8959-g16debfadbd759f9933b4a62029661f01188ad928
Author: Andrew Pinski 
Date:   Mon Dec 5 09:09:52 2022 +0100

tree-optimization/107956 - ICE with NULL call LHS

The following adds a missing check for a NULL call LHS in the
vector pattern recognizer.

PR tree-optimization/107956
* tree-vect-patterns.cc (vect_recog_mask_conversion_pattern):
Check for NULL LHS on masked loads.

(cherry picked from commit 5c11d748564c7ce3b096e87ad350fcddd493e45e)

[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.2.1, 13.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|12.2.1, 13.0|12.2.0

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

[Bug sanitizer/107963] Support __attribute__((disable_sanitizer_instrumentation))

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Richard Biener  ---
Yep, that would just be confusing.  If "not unpoison the shadow for *a" is
useful and no_sanitize("all") shouldn't cover that then no_unpoison_shadow
would have been better.

[Bug plugins/107964] [13] missing plugin header contracts.h

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.  Thanks for noticing and the fix.

[Bug plugins/107964] [13] missing plugin header contracts.h

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:824542bec24c09319fa55922a0162209a5f64963

commit r13-4490-g824542bec24c09319fa55922a0162209a5f64963
Author: Scott Snyder 
Date:   Mon Dec 5 09:20:11 2022 +0100

plugins/107964 - install contracts.h

contracts.h is included by cp-tree.h so needs to be installed for
plugins.

PR plugins/107964
gcc/cp/
* Make-lang.in (CP_PLUGIN_HEADERS): Install contracts.h

[Bug tree-optimization/107967] The gcc commit 2f7f9edd28d caused the glibc make check fails.

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 CC||jakub at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
I think there have been followup fixes to that commit, but I'm not sure about
the glibc testsuite state

[Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

--- Comment #2 from Jonathan Wakely  ---
They're nothing the printers can do. You're asking to print them out before
they are initialized, so they try to interpret garbage as values. The
OverflowError is just because some uninitialized std::string cannot be printed.

This should really be reported as a gdb bug. Gdb knows if the object's
initialization had finished, so it should not try to print variables at all
before their lifetime has begun, especially not via python printers.

It might make sense to display the variable name with a value like , but even that is debatable. The C++ standard is very clear that none
of those variables exists yet at your breakpoint, and gdb contradicts its own
documentation:

"These are all variables (declared either static or automatic) accessible at
the point of execution of the selected frame."

[Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #2)
> They're nothing the printers can do. You're asking to print them out before
> they are initialized, so they try to interpret garbage as values. The
> OverflowError is just because some uninitialized std::string cannot be
> printed.
> 
> This should really be reported as a gdb bug. Gdb knows if the object's
> initialization had finished, so it should not try to print variables at all
> before their lifetime has begun, especially not via python printers.
> 
> It might make sense to display the variable name with a value like  lifetime>, but even that is debatable. The C++ standard is very clear that
> none of those variables exists yet at your breakpoint, and gdb contradicts
> its own documentation:
> 
> "These are all variables (declared either static or automatic) accessible at
> the point of execution of the selected frame."

I'm not so sure.  For

struct X { X(); int i; };

X::X () { i = 42; }

int main()
{
  X x;
  return 0;
}

GCC emits

 <1><6e>: Abbrev Number: 9 (DW_TAG_subprogram)
<6f>   DW_AT_external: 1
<6f>   DW_AT_name: (indirect string, offset: 0xf): main
<73>   DW_AT_decl_file   : 1
<74>   DW_AT_decl_line   : 5
<75>   DW_AT_decl_column : 5
<76>   DW_AT_type: <0x67>
<7a>   DW_AT_low_pc  : 0x15
<82>   DW_AT_high_pc : 0x1b
<8a>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<8c>   DW_AT_GNU_all_tail_call_sites: 1
<8c>   DW_AT_sibling : <0x9e>
 <2><90>: Abbrev Number: 10 (DW_TAG_variable)
<91>   DW_AT_name: x
<93>   DW_AT_decl_file   : 1
<94>   DW_AT_decl_line   : 7
<95>   DW_AT_decl_column : 5
<96>   DW_AT_type: <0x2d>
<9a>   DW_AT_location: 2 byte block: 91 6c  (DW_OP_fbreg: -20)

so gdb has no idea that x only becomes live after the call to the CTOR
(or during that).  Instead GCC says it lives throughout the whole
function on the frame.  Even the original IL from the frontend has no
hint that would allow the middle-end to emit different DWARF.

[Bug c/107969] New: ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

Bug ID: 107969
   Summary: ICE in extract_insn, at recog.cc:2791 since
r13-3292-gc2565a31c1622ab0
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The follow crashes:

$ cat prec.c
int i;
__bf16 f;

void
bar() { i *= 0 <= f; }

$ gcc prec.c -Ofast -fexcess-precision=16 -m32 -msoft-float -c
prec.c: In function ‘bar’:
prec.c:5:22: error: unrecognizable insn:
5 | bar() { i *= 0 <= f; }
  |  ^
(insn 10 9 12 2 (set (reg:CCFP 17 flags)
(compare:CCFP (reg:SF 89)
(reg:SF 90))) "prec.c":5:11 -1
 (nil))
during RTL pass: vregs
prec.c:5:22: internal compiler error: in extract_insn, at recog.cc:2791
0x75acd4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:108
0x75acf0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:116
0x7592b5 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.cc:2791
0xb88100 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.cc:1611
0xb88100 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.cc:1985
0xb88100 execute
/home/marxin/Programming/gcc/gcc/function.cc:2034
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.

[Bug c/107969] ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-05

[Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

--- Comment #4 from Richard Biener  ---
I would suggest to make the pretty-printers more robust with respect to memory
errrors (can those errors be catched and the printing avoided somehow?)

[Bug target/107970] New: ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

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

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

Bug ID: 107970
   Summary: ICE in extract_insn, at recog.cc:2791 since
r13-2730-gd0c73b6c85677e67
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu

The following crashes:

$ cat ice.i
float *foo_p;

void
foo(float *__restrict q) {
  foo_p[0] = __builtin_truncf(q[0]);
  foo_p[1] = __builtin_truncf(q[1]);
}

$ gcc -m32 -Ofast -m3dnowa -mavx512vpopcntdq ice.i -c
ice.i: In function ‘foo’:
ice.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 7 6 8 2 (set (reg:V2SF 84 [ vect__3.8 ])
(unspec:V2SF [
(reg:V2SF 86 [ vect__1.7 ])
(const_int 11 [0xb])
] UNSPEC_ROUND)) "ice.i":5:14 -1
 (nil))
during RTL pass: vregs
ice.i:7:1: internal compiler error: in extract_insn, at recog.cc:2791
0x75acd4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:108
0x75acf0 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.cc:116
0x7592b5 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.cc:2791
0xb88100 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.cc:1611
0xb88100 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.cc:1985
0xb88100 execute
/home/marxin/Programming/gcc/gcc/function.cc:2034
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.

[Bug target/107970] ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0

[Bug target/107969] ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

--- Comment #1 from Andrew Pinski  ---
Almost nobody uses msoft-float on x86_64 or even i386 these days.

[Bug c/107971] New: linking an assembler object creates an executable stack

[contact--- via Gcc-bugs]

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

Bug ID: 107971
   Summary: linking an assembler object creates an executable
stack
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cont...@alexander-pick.com
  Target Milestone: ---

Created attachment 54011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54011&action=edit
simple testcase for the issue

I encountered a strange behavior with gcc and linking an assembler object.
Doing so will create a binary with executable stack. A testcase is attached.

The code will compile a very simple assembler file as an object and link it to
an object compiled from C. The binary will have an executable stack by default
which isn't that great from a security point of view. Setting "-z noexecstack"
as a workaround is the only way to prevent this.

31:   STACK off0x vaddr 0x paddr
0x align 2**4
32- filesz 0x memsz 0x flags rwx

[Bug tree-optimization/107967] The gcc commit 2f7f9edd28d caused the glibc make check fails.

[caiyinyu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from caiyinyu  ---
I tested with latest gcc(commit 102f3cef568), and these fails still exist.
My gcc configuration:

../configure --prefix=/usr --libdir=/usr/lib64 --disable-bootstrap 
--enable-__cxa_atexit --enable-threads=posix --with-system-zlib
--enable-libstdcxx-time --enable-checking=release --enable-default-pie
--enable-languages=c,c++

[Bug c/107971] linking an assembler object creates an executable stack

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Gcc just invokes the assembly. The problem is legacy assembly code might still
use an executable stack.
Best way to fix this is for you to add the option. There is nothing gcc is
going to change to be different here.
Also the assembler is not part of gcc. Most likely you are using gnu binutils.

[Bug target/107969] ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

--- Comment #2 from Martin Liška  ---
Sure, it's a result of option fuzzing, I admit.

[Bug c/107971] linking an assembler object creates an executable stack

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

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

--- Comment #2 from Andrew Pinski  ---
You can use the assembler note to communicate to the linker that the assembly
code does not use executable stack. This is all documented in the linker
documentation and is not part of gcc documentation.

[Bug tree-optimization/107839] spurious "may be used uninitialized" warning while all uses are under "if (c)"

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:44c8402d35160515b3c09fd2bc239587e0c32a2b

commit r13-4491-g44c8402d35160515b3c09fd2bc239587e0c32a2b
Author: Richard Biener 
Date:   Fri Dec 2 14:52:20 2022 +0100

tree-optimization/107833 - invariant motion of uninit uses

The following fixes a wrong-code bug caused by loop invariant motion
hoisting an expression using an uninitialized value outside of its
controlling condition causing IVOPTs to use that to rewrite a defined
value.  PR107839 is a similar case involving a bogus uninit diagnostic.

PR tree-optimization/107833
PR tree-optimization/107839
* cfghooks.cc: Include tree.h.
* tree-ssa-loop-im.cc (movement_possibility): Wrap and
make stmts using any ssa_name_maybe_undef_p operand
to preserve execution.
(loop_invariant_motion_in_fun): Call mark_ssa_maybe_undefs
to init maybe-undefined status.
* tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p,
ssa_name_set_maybe_undef, ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Move ...
* tree-ssa.cc: ... here.
* tree-ssa.h (ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Declare.
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): Define.

* gcc.dg/torture/pr107833.c: New testcase.
* gcc.dg/uninit-pr107839.c: Likewise.

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:44c8402d35160515b3c09fd2bc239587e0c32a2b

commit r13-4491-g44c8402d35160515b3c09fd2bc239587e0c32a2b
Author: Richard Biener 
Date:   Fri Dec 2 14:52:20 2022 +0100

tree-optimization/107833 - invariant motion of uninit uses

The following fixes a wrong-code bug caused by loop invariant motion
hoisting an expression using an uninitialized value outside of its
controlling condition causing IVOPTs to use that to rewrite a defined
value.  PR107839 is a similar case involving a bogus uninit diagnostic.

PR tree-optimization/107833
PR tree-optimization/107839
* cfghooks.cc: Include tree.h.
* tree-ssa-loop-im.cc (movement_possibility): Wrap and
make stmts using any ssa_name_maybe_undef_p operand
to preserve execution.
(loop_invariant_motion_in_fun): Call mark_ssa_maybe_undefs
to init maybe-undefined status.
* tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p,
ssa_name_set_maybe_undef, ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Move ...
* tree-ssa.cc: ... here.
* tree-ssa.h (ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Declare.
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): Define.

* gcc.dg/torture/pr107833.c: New testcase.
* gcc.dg/uninit-pr107839.c: Likewise.

[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I'm testing a variant of the patch that instead makes the argument pass-through
work the same as the PHI pass-through which instead does

 if (!m_ptr_qry.get_ref (arg, phi, &aref, 0)
 || (aref.deref == 0
 && POINTER_TYPE_P (TREE_TYPE (aref.ref
   continue;

thus disallows aref.deref == 0 with pointer type which is what happens in
this case as well.

OTOH it doesn't make much sense to me either - but then the .get_ref
documentation is very sparse and the API very complicated.

I _think_ that the get_ref (via compute_objsize) returns the object
that 'arg' references (points-to) in aref.ref, but how aref.deref
is then set is a mystery to me.  It _seems_ that we want to have
< 0 here as martin indicated but that would mean the PHI case is
wrong as well (and the POINTER_TYPE_P check very odd).  It also
seems that for the call case we might want to call
check_dangling_uses (var, aref.ref, true) for aref.deref == 0?

I'm going to test this piecewise.

[Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|libstdc++   |debug
   Last reconfirmed||2022-12-05
 CC||jason at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> so gdb has no idea that x only becomes live after the call to the CTOR
> (or during that).  Instead GCC says it lives throughout the whole
> function on the frame.

That's clearly a GCC bug then, because that is not how C++ works.

> Even the original IL from the frontend has no
> hint that would allow the middle-end to emit different DWARF.

So let's change component to 'debug'. There's definitely nothing the libstdc++
printers can do here.

(In reply to Richard Biener from comment #4)
> I would suggest to make the pretty-printers more robust with respect to
> memory errrors (can those errors be catched and the printing avoided
> somehow?)

There's no single type of error reported in such cases (e.g. the OverflowError
shown above depends on the specific values of the uninitialized bytes, even the
same printer won't fail with the same error every time). The only way to be
more robust is to catch *all* exceptions, and swallow all errors from any point
in the printers. That then hides real errors, and makes them impossible to
develop/debug. It would mean changes in at least 50 places, which would all
have to be individually disabled to allow real errors to propagate when trying
to debug or improve the printers. I don't want to do that.

[Bug tree-optimization/107839] spurious "may be used uninitialized" warning while all uses are under "if (c)"

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||13.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 107839 Summary: spurious "may be used uninitialized" warning while all uses 
are under "if (c)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839

   What|Removed |Added

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

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Liška  ---
Thanks, now I can reproduce and it:

Thread 1 "isql" received signal SIGSEGV, Segmentation fault.
0x7634da54 in Firebird::MemPool::releaseMemory (flagExtent=false,
object=) at
/home/marxin/Programming/firebird-4.0.2/src/common/classes/alloc.cpp:2402
2402pool->releaseBlock(block, !flagExtent);
(gdb) bt
#0  0x7634da54 in Firebird::MemPool::releaseMemory (flagExtent=false,
object=) at
/home/marxin/Programming/firebird-4.0.2/src/common/classes/alloc.cpp:2402
#1  Firebird::MemPool::deallocate (block=) at
/home/marxin/Programming/firebird-4.0.2/src/common/classes/alloc.cpp:2683
#2  Firebird::MemPool::globalFree (block=) at
/home/marxin/Programming/firebird-4.0.2/src/common/classes/alloc.cpp:2671
#3  Firebird::MemoryPool::globalFree (block=) at
/home/marxin/Programming/firebird-4.0.2/src/common/classes/alloc.cpp:2836

it crashes because releaseMemory is called with object == NULL:

void MemPool::releaseMemory(void* object, bool flagExtent) FB_NOTHROW
{
if (object)
{

LTO create a .part clone where it assumes object can't be null. That's true for
'this' pointer, which should never be null.

can be fixed with:
-O2 -flto=auto -flifetime-dse=1 -fno-delete-null-pointer-checks

please build the software with -fsanitize=undefined,address and investigate
where it violates that.

[Bug tree-optimization/107967] [13 regression] The gcc commit 2f7f9edd28d caused the glibc make check fails.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|The gcc commit 2f7f9edd28d  |[13 regression] The gcc
   |caused the glibc make check |commit 2f7f9edd28d caused
   |fails.  |the glibc make check fails.

[Bug c/107971] linking an assembler object creates an executable stack

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

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

--- Comment #3 from Andrew Pinski  ---
https://sourceware.org/binutils/docs-2.39/ld/Options.html#index-_002d_002dwarn_002dexecstack

```
Note: ELF format input files specify that they need an executable stack by
having a .note.GNU-stack section with the executable bit set in its section
flags. They can specify that they do not need an executable stack by having
that section, but without the executable flag bit set. If an input file does
not have a .note.GNU-stack section present then the default behaviour is target
specific. For some targets, then absence of such a section implies that an
executable stack is required. This is often a problem for hand crafted
assembler files.
```

Added emphasize is mine.

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

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

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

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

https://gcc.gnu.org/g:4500baaccb6e4d696e223c338bbdf7705c3646dd

commit r13-4492-g4500baaccb6e4d696e223c338bbdf7705c3646dd
Author: Jakub Jelinek 
Date:   Mon Dec 5 11:17:42 2022 +0100

range-op-float: Fix up multiplication and division reverse operation
[PR107879]

While for the normal cases it seems to be correct to implement
reverse multiplication (op1_range/op2_range) through division
with float_binary_op_range_finish, reverse division (op1_range)
through multiplication with float_binary_op_range_finish or
(op2_range) through division with float_binary_op_range_finish,
as e.g. following testcase shows for the corner cases it is
incorrect.
Say on the testcase we are doing reverse multiplication, we
have [-0., 0.] range (no NAN) on lhs and VARYING on op1 (or op2).
We implement that through division, because x from
lhs = x * op2
is
x = lhs / op2
For the division, [-0., 0.] / VARYING is computed (IMHO correctly)
as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still
0 and 0 / 0 is NAN and ditto 0 / NAN.  And then we just
float_binary_op_range_finish, which figures out that because lhs
can't be NAN, neither operand can be NAN.  So, the end range is
[-0., 0.].  But that is not correct for the reverse multiplication.
When the result is 0, if op2 can be zero, then x can be anything
(VARYING), to be precise anything but INF (unless result can be NAN),
because anything * 0 is 0 (or NAN for INF).  While if op2 must be
non-zero, then x must be 0.  Of course the sign logic
(signbit(x) = signbit(lhs) ^ signbit(op2)) still holds, so it actually
isn't full VARYING if both lhs and op2 have known sign bits.
And going through other corner cases one by one shows other differences
between what we compute for the corresponding forward operation and
what we should compute for the reverse operations.
The following patch is slightly conservative and includes INF
(in case of result including 0 and not NAN) in the ranges or
0 in the ranges (in case of result including INF and not NAN).
The latter is what happens anyway because we flush denormals to 0,
and the former just not to deal with all the corner cases.
So, the end test is that for reverse multiplication and division
op2_range the cases we need to adjust to VARYING or VARYING positive
or VARYING negative are if lhs and op? ranges both contain 0,
or both contain some infinity, while for division op1_range the
corner case is if lhs range contains 0 and op2 range contains INF or vice
versa.  Otherwise I believe ranges from the corresponding operation
are ok, or could be slightly more conservative (e.g. for
reverse multiplication, if op? range is singleton INF and lhs
range doesn't include any INF, then x's range should be UNDEFINED or
known NAN (depending on if lhs can be NAN), while the division computes
[-0., 0.] +-NAN; or similarly if op? range is only 0 and lhs range
doesn't include 0, division would compute +INF +-NAN, or -INF +-NAN,
or (for lack of multipart franges -INF +INF +-NAN just VARYING +-NAN),
while again it is UNDEFINED or known NAN.

Oh, and I found by code inspection wrong condition for the division's
known NAN result, due to thinko it would trigger not just when
both operands are known to be 0 or both are known to be INF, but
when either both are known to be 0, or at least one is known to be INF.

2022-12-05  Jakub Jelinek  

PR tree-optimization/107879
* range-op-float.cc (foperator_mult::op1_range): If both
lhs and op2 ranges contain zero or both ranges contain
some infinity, set r range to zero_to_inf_range depending on
signbit_known_p.
(foperator_div::op2_range): Similarly for lhs and op1 ranges.
(foperator_div::op1_range): If lhs range contains zero and op2
range contains some infinity or vice versa, set r range to
zero_to_inf_range depending on signbit_known_p.
(foperator_div::rv_fold): Fix up condition for returning known NAN.

[Bug c/107971] linking an assembler object creates an executable stack

[contact--- via Gcc-bugs]

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

--- Comment #4 from Alexander Pick  ---
Thanks a lot for the explanation. Do you think that it is worth reporting it to
binutils as the text in the link also says that there should be a warning
unless the option to have an executable stack is explicitly specified? In the
test case there is no such warning. I also tried to link the objects with LD
directly - same result and also no warning.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
Summary|[13 regression] The gcc |[13 regression] The gcc
   |commit 2f7f9edd28d caused   |commit r13-3923 caused the
   |the glibc make check fails. |glibc make check fails.

--- Comment #3 from Jakub Jelinek  ---
r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d

Note, I've just committed the PR107879 fix, but that one is for the reverse
operations.
And, we have still unresolved the PR107608 which on the other side could very
well be related or the cause of this.
BTW, Aldy, is there a way to disable all range related optimizations through
some command line option?  In the past, -fno-tree-vrp would do the trick, but
now that the ranger is used in lots of passes, I don't know what else to use.

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

--- Comment #6 from Jonathan Wakely  ---
Reading symbols from p...
(gdb) start
Temporary breakpoint 1 at 0x4022ea: file p.cc, line 18.
Starting program: /tmp/p 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at p.cc:18
18  }

Why is the location for the 'start' breakpoint the closing brace of main() ?!

(gdb) n
9   vector test{"test", "test2"};
(gdb) info locals
test = std::vector of length 5, capacity 38 = {" ", , "", 
  , }
blabla = ""
b = 32767

The errors here seem reasonable, but they depend entirely on the garbage that
happens to be in the uninitialized variables. Different garbage will produce
worse errors.


(gdb) disable pretty-printer
200 printers disabled
0 of 200 printers enabled
(gdb) info locals
test = {, std::allocator >,
std::allocator,
std::allocator > > >> = {
_M_impl = {, std::allocator > >> =
{,
std::allocator > >> = {}, },
,
std::allocator >, std::allocator, std::allocator > > >::_Vector_impl_data> =
{_M_start = 0x77e2e9a0 <(anonymous namespace)::moneypunct_cache_wf>, 
_M_finish = 0x77e2ea40 <(anonymous
namespace)::moneypunct_cache_wt>, 
_M_end_of_storage = 0x77e2ee60 <(anonymous
namespace)::moneypunct_cache_ct>}, }}, }

Even with the printers disabled (which is what would happen if the printers
caught all exceptions and didn't show anything) we get nonsense.
moneypunct_cache_wf, moneypunct_cache_wt, and moneypunch_cache_ct are global
variables inside libstdc++.so, but the uninitialized pointers in the
std::vector just happen to point at them.

blabla = {_M_dataplus = {> = {>
= {}, }, 
_M_p = 0x77e2ede0 <(anonymous namespace)::moneypunct_cache_cf>
"x9\342\367\377\177"}, _M_string_length = 140737352232672, {
_M_local_buf =
"\300\357\342\367\377\177\000\000\002\316\314\367\377\177\000",
_M_allocated_capacity = 140737352232896}}

This is all garbage.

b = 32767

At least with an uninitialized int we just get an arbitrary int value, not
nonsense.

But none of these variables should be live yet, so gdb shouldn't even try to
show their values.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #3)
> r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
> 
> Note, I've just committed the PR107879 fix, but that one is for the reverse
> operations.
> And, we have still unresolved the PR107608 which on the other side could
> very well be related or the cause of this.
> BTW, Aldy, is there a way to disable all range related optimizations through
> some command line option?  In the past, -fno-tree-vrp would do the trick,
> but now that the ranger is used in lots of passes, I don't know what else to
> use.

Not really, as ranger clients are spread around various passes.  

I think you could return false from irange::supports_p() and
frange::supports_p() and that would block everyone using ranger.  It would
certainly stop range_of_expr and range_of_edge, which are the main workhorses.

If this is needed, perhaps we could check some global flag from these functions
to provide a way to disable ranger.  But I don't think it could be
-fno-tree-vrp because DOM uses ranger, but VRP is disabled for -O1.  Perhaps
some internal --param flag if this is only needed internally?

Richi at one time suggested that we should probably formalize what we mean by
range propagation and document what we are and aren't allowed to do.  Or
perhaps document that VRP might happen even for -fno-tree-vrp (as that's
definitely happening at -O1 through DOM's use of ranger (and previously evrp)).

[Bug middle-end/106805] [13 Regression] Undue optimisation of floating-point comparisons

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:109148dd16e4bcd50faee19c49082de69d0ba26e

commit r13-4493-g109148dd16e4bcd50faee19c49082de69d0ba26e
Author: Jakub Jelinek 
Date:   Mon Dec 5 11:54:45 2022 +0100

match.pd: Don't fold nan < x etc. for -ftrapping-math [PR106805]

As reported in the PR, the following pr106805.c testcase is miscompiled
with the default -ftrapping-math, because we fold all the comparisons into
constants and don't raise any exceptions.

The match.pd pattern handles just simple comparisons, from those
EQ/NE are quiet and don't raise exceptions on anything but sNaN, while
GT/GE/LT/LE are signaling and do raise exceptions even on qNaN.

fold_relational_const handles this IMHO correctly:
  /* Handle the cases where either operand is a NaN.  */
  if (real_isnan (c0) || real_isnan (c1))
{
  switch (code)
{
case EQ_EXPR:
case ORDERED_EXPR:
  result = 0;
  break;

case NE_EXPR:
case UNORDERED_EXPR:
case UNLT_EXPR:
case UNLE_EXPR:
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
  result = 1;
  break;

case LT_EXPR:
case LE_EXPR:
case GT_EXPR:
case GE_EXPR:
case LTGT_EXPR:
  if (flag_trapping_math)
return NULL_TREE;
  result = 0;
  break;

default:
  gcc_unreachable ();
}

  return constant_boolean_node (result, type);
}
by folding the signaling comparisons only if -fno-trapping-math.
The following patch does the same in match.pd.

Unfortunately the pr106805.c testcase still fails, but no longer because of
match.pd, but on the trunk because of the still unresolved ranger problems
(same issue as for fold-overflow-1.c etc.) and on 12 branch (and presumably
trunk too) somewhere during expansion the comparisons are also expanded
into constants (which is ok for -fno-trapping-math, but not ok with that).

Though, I think the patch is a small step in the direction, so I'd like
to commit this patch without the gcc.dg/pr106805.c testcase for now.

2022-12-05  Jakub Jelinek  

PR middle-end/106805
* match.pd (cmp @0 REAL_CST@1): Don't optimize x cmp NaN
or NaN cmp x to false/true for cmp >/>=/

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #13 from Brjd  ---
I am not sure how I can run only this patched test against the newly built gcc.
Would you post instruction how it is done. I know it can run in the build tree
when building gcc itself, but never test it against the testsuite when ready. I
unpack the source, patch the test and then what next?

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #14 from Brjd  ---
Maybe it is better if we test it in the next release 12.3 or 13.1 since now the
test will be correct, ok, but when building source with the compiler, it will
not make any difference and make no problems at all?

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

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

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

--- Comment #15 from Martin Liška  ---
Sure, I'm pretty sure about what's the problem, so you can wait for 13.1 or
12.3 where I would like to get the fix.

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

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

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

--- Comment #10 from Alexander Monakov  ---
If anyone is confused like I was, the commit actually includes a testcase, but
the addition is not mentioned in the Changelog. I was sure the server-side
receive hook was supposed to reject such incomplete Changelog, though?

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

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

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

--- Comment #11 from Martin Liška  ---
> I was sure the
> server-side receive hook was supposed to reject such incomplete Changelog,
> though?

New files in test-suite are not mandatory by the hook and corresponding
ChangeLog entries are generated automatically.

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #16 from Brjd  ---
I mean that as I can see, your patch makes changes only to the test and  not to
the compiler ? If it does not, and it changes the compiler source also, then I
have to rebuild the whole compiler to test it again. But If only the test is
misconfigured, forget about it, and the compiler works great, then I will use
it for the next build. Thank you a lot.

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

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

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

--- Comment #17 from Martin Liška  ---
(In reply to Brjd from comment #16)
> I mean that as I can see, your patch makes changes only to the test and  not
> to the compiler ?

No, it also modifies:
gcc/config/i386/i386-builtins.cc

which is part of the compiler itself.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #21 from Tomasz Kłoczko  ---
On emore time.
You are commenting under GNU C Compilet issue during linking firebird binaries
linking.
*COMPILER* (not firebird) is core dumping.

Please discuss firebird issue opening ticket on
https://github.com/FirebirdSQL/firebird/issues/

[Bug lto/107078] LTO is causing that firebird build is core dumping

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #22 from Sam James  ---
(In reply to Tomasz Kłoczko from comment #21)
> On emore time.
> You are commenting under GNU C Compilet issue during linking firebird
> binaries linking.
> *COMPILER* (not firebird) is core dumping.
> 
> Please discuss firebird issue opening ticket on
> https://github.com/FirebirdSQL/firebird/issues/

It is definitely isql which is segfaulting. The Makefile uses a binary just
built to try do some bits and the binary-just-built crashes.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

--- Comment #23 from Martin Liška  ---
(In reply to Tomasz Kłoczko from comment #21)
> On emore time.
> You are commenting under GNU C Compilet issue during linking firebird
> binaries linking.
> *COMPILER* (not firebird) is core dumping.

I see isql crashing, not GCC compiler! Show me compiler invocation that
crashes.

> 
> Please discuss firebird issue opening ticket on
> https://github.com/FirebirdSQL/firebird/issues/

I provided an explanation of why the built binary with LTO is crashing because
it has undefined behavior. Feel free to take any comments I provided and put
that to:
https://github.com/FirebirdSQL/firebird/issues/7308

[Bug c/107971] linking an assembler object creates an executable stack

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
The warning is new in binutils-2.39 (the latest release at this time), perhaps
your linker is older.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #2 from Siddhesh Poyarekar  ---
The standard does not allow the nesting, but gcc supports it as an extension.

The middle end does see the array as a flex array correctly, but
tree-object-size doesn't seem to do the right thing consistently enough.  Or
rather, the current behaviour seems a bit mixed up, which is why I want to try
and specify the behaviour for tree-object-size more clearly with all
combinations of -fstrict-flex-array and arrays, i.e. nested or otherwise.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
When writing tree-object-size.c, the intent was to find some balance between
catching up dangerous cases and allowing what a lot of programs in the wild use
and it took about a year to stabilize that.  Sure, with a new non-default
option that requests stricter behavior it is possible to change it.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #7 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return _1;
> > with
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return  Inf;
> > (I think this is still correct)
> 
> Note this is also a pessimization code-generation wise since if we
> preserve the multiplication the result is readily available in a
> register but as optimized we have another constant pool entry and load.
> 
> So we might want to consider not propagating constants generated by
> operations
> we cannot eliminate.  If the only consumer is a compare-and-branch we
> can of course still end up with a seemingly dead stmt, so this would be only
> for the missed optimization.

Up to y'all if this is the way to go, but here are some thoughts...

Off the top of my head, we have VRP and DOM propagating constants.  Technically
also simplify_using_ranges, but it's only called from VRP/DOM, and it currently
only works with integers, so we should be ok here.

I think we could limit propagation in may_propagate_copy() which both VRP and
DOM gate on.  VRP uses it through its use of substitute_and_fold_engine and DOM
uses it directly.  Would this work?

Would we need to pass an additional argument to may_propagate_copy() (edge or
statement) or can we determine validity by only looking at:

  bool may_propagate_copy (tree dest, tree orig, bool dest_not_phi_arg_p)

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #18 from Brjd  ---
Then rebuild is necessary and impending 
  gcc/config/i386/i386-builtins.cc for the compiler ?
  gcc/testsuite/gcc.target/i386/builtin_target.c  for the test ?
  gcc/doc/extend.texi is not needed since I am not building docs?

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

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

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

--- Comment #19 from Martin Liška  ---
(In reply to Brjd from comment #18)
> Then rebuild is necessary and impending 
>   gcc/config/i386/i386-builtins.cc for the compiler ?
>   gcc/testsuite/gcc.target/i386/builtin_target.c  for the test ?

Yes.

[Bug tree-optimization/107972] New: backward propagation of finite property not performed

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

Bug ID: 107972
   Summary: backward propagation of finite property not performed
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

Here is another example where with the help of the FP ranger capabilities the
compiler should generate better code than it does today (trunk):

double f(double a, double b)
{
  if (!__builtin_isfinite(a))
return -1.0;

  double res = a + b;
  if (! __builtin_isfinite(res))
__builtin_unreachable();
  return res;
}

The condition guaranteed by the __builtin_unreachable implies that neither a
nor b cannot be finite.  Hence the initial comparison can be elided.

The same is true for - and * and also for the first operand of /.

[Bug tree-optimization/107972] backward propagation of finite property not performed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For * I've posted such a patch today (but guess I should add a testcase):
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607832.html
For + and - I guess we can't do easily the sign bit computation, so we could
just in
the reverse ops do if lhs must be finite (not inf nor nan), then the operand we
compute must be finite too.

[Bug c/107973] New: wrong warning with -Werror -fsanitize=address

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 107973
   Summary: wrong warning with -Werror -fsanitize=address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

when compiling openssl-1.1.1s with the following workflow:

$ wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz
$ tar xf openssl-1.1.1s.tar.gz
$ cd openssl-1.1.1s
$ ./config  --strict-warnings enable-asan
$ make

I get this unexpected warning (error)

gcc  -I. -Iinclude -fPIC -pthread -m64 -fsanitize=address
-fno-omit-frame-pointer -g -Wa,--noexecstack -Wall -O3 -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wshadow -Wformat
-Wtype-limits -Wundef -Werror -Wmissing-prototypes -Wstrict-prototypes
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM
-DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG  -MMD -MF
ssl/s3_enc.d.tmp -MT ssl/s3_enc.o -c -o ssl/s3_enc.o ssl/s3_enc.c
In function 'ssl3_generate_key_block',
inlined from 'ssl3_setup_key_block' at ssl/s3_enc.c:290:11:
ssl/s3_enc.c:48:20: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   48 | buf[j] = c;
  | ~~~^~~
ssl/s3_enc.c: In function 'ssl3_setup_key_block':
ssl/s3_enc.c:21:19: note: at offset 16 into destination object 'buf' of size 16
   21 | unsigned char buf[16], smd[SHA_DIGEST_LENGTH];
  |   ^~~
cc1: all warnings being treated as errors


this happens with:
gcc version 12.2.1 20221130 (GCC)
gcc version 11.3.1 20221205 (GCC) 
gcc version 10.4.1 20221205 (GCC)

but did not happen with:
gcc version 9.5.0 (GCC)

nor does it happen with:
gcc version 13.0.0 20221130 (experimental) (GCC)

It is pretty annoying because this happens in CI builds
once we change from ubuntu-20.04 (gcc9) to ubuntu-22.04 (gcc11)

[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-4494-gd492d50f644811327c5976e2c918ab6d906ed40c
Author: Richard Biener 
Date:   Mon Dec 5 10:13:13 2022 +0100

tree-optimization/106868 - bogus -Wdangling-pointer diagnostic

The testcase shows we mishandle the case where there's a pass-through
of a pointer through a function like memcpy.  The following adjusts
handling of this copy case to require a taken address and adjust
the PHI case similarly.

PR tree-optimization/106868
* gimple-ssa-warn-access.cc
(pass_waccess::gimple_call_return_arg_ref):
Inline into single user ...
(pass_waccess::check_dangling_uses): ... here and adjust the
call and the PHI case to require that ref.aref is the address
of the decl.

* gcc.dg/Wdangling-pointer-pr106868.c: New testcase.

[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.2.0
  Known to work||13.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar, thanks for the report and sorry for the long silence.

[Bug bootstrap/107960] opt-gather.awk seems to ignore lines lines that start with whitespace

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-05
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-12-05
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Lemme address this.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-05
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug c/107973] wrong warning with -Werror -fsanitize=address

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed on master since r13-1268-g8c99e307b20c502e, note that sanitizers tens to
increase false-positives of warnings:

https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
```
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers.

```

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

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

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

--- Comment #13 from Martin Liška  ---
> As a hack I've removed them manually:
> FOR_EACH_BB_FN (bb, cfun)
> {
> gimple_stmt_iterator gsi = gsi_after_labels (bb);
> if (!gsi_end_p (gsi) && gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT)
> gsi_remove (&gsi, true);
> }
> in pass_if_to_switch::execute before return TODO_cleanup_cfg;, but that
> didn't help.

@Richi: Can you please take a look why TODO_cleanup_cfg doesn't help us here?

[Bug tree-optimization/40635] [12/13 Regression] bogus name and location in 'may be used uninitialized' warning

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #26 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #25)
> So current status is if you add -fno-inline, you can see the proper
> uninitialized warning in get_tcp_socket, but we only get the declaration
> site of s42, not the use site.  So still broken, just in a different way
> then the original report.

I think for this issue we have duplicates - the use is on the GIMPLE_RETURN
but those do not have locations (since we forcefully merge them), instead
a PHI merge arg should but that doesn't have a location either in this case
which is where we are lost.

We start with

  [t.c:29:12] D.2772 = s42;
  [t.c:29:12] return D.2772;

lowered to

  [t.c:29:12] D.2772 = s42;
  [t.c:29:12] goto ;
  :
  return D.2772;

and with a CFG

   :
  [t.c:29:12] D.2772 = s42;

   :
  return D.2772;

SSA:

   :
  # _8 = PHI <[t.c:21:20] _25(4), [t.c:28:16] _27(9), [t.c:29:12] _26(10)>
  return _8;

thread1 causes the arg to split and lose locations:

@@ -47,18 +82,23 @@
   [t.c:18:34 discrim 1] if (_2 != 0B)
 goto ; [96.34%]
   else
-goto ; [3.66%]
+goto ; [3.66%]

-   [local count: 75773864]:
-  # s42_4 = PHI <[t.c:19:15] s42_19(5), [t.c:19:15] s42_19(6), s42_17(D)(2)>
-  # x_6 = PHI <[t.c:22:13] 0(5), [t.c:22:13] x_21(6), [t.c:17:7] 0(2)>
+   [local count: 4159022]:
+  # s42_9 = PHI 
+  # x_7 = PHI <[t.c:17:7] 0(2)>
+  goto ; [100.00%]
+
+   [local count: 71614842]:
+  # s42_4 = PHI <[t.c:19:15] s42_19(5), [t.c:19:15] s42_19(6)>
+  # x_6 = PHI <[t.c:22:13] 0(5), [t.c:22:13] x_21(6)>
   [t.c:27:8] if (x_6 < 0)
-goto ; [0.73%]
+goto ; [0.78%]
   else
-goto ; [99.27%]
+goto ; [99.22%]

-   [local count: 113634474]:
-  # _8 = PHI <[t.c:21:20] -1(4), [t.c:29:12] s42_4(7), [t.c:21:20] -1(3)>
+   [local count: 113634474]:
+  # _8 = PHI <[t.c:21:20] -1(4), s42_4(8), [t.c:21:20] -1(3), s42_9(7)>
   return _8;

and the location is stripped by SSA update replacing _4 with its reaching
def _4 (sic!) but running into

  gimple *stmt = SSA_NAME_DEF_STMT (reaching_def);
  gphi *other_phi = dyn_cast  (stmt);

  /* Single element PHI nodes  behave like copies, so get the
 location from the phi argument.  */
  if (other_phi
  && gimple_phi_num_args (other_phi) == 1)
locus = gimple_phi_arg_location (other_phi, 0);
  else
locus = gimple_location (stmt);

using the location of the _4 def (a multi-arg PHI) which is (as usual)
UNKNOWN_LOCATION.  Fixing that fixes the location on the edge from 7
and avoids some work but then I wonder why we adjust the PHI arg location
_at all_ here (arguably we might want to replace UNKNOWN_LOCATION with
a more meaningful location but not a meaningful location with
UNKNOWN_LOCATION as we do here).

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #20 from Brjd  ---
The test gcc/testsuite/gcc.target/i386/builtin_target.c  is patched.

But  gcc/config/i386/i386-builtins.cc  looks like it is from another version.

I attached it as i386-builtins-orig-12.2.0.cc to compare them and asking if you
could correct it with your patch.

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #21 from Brjd  ---
Created attachment 54012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54012&action=edit
i386-builtins-orig-12.2.0.cc

[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #31 from Jason Merrill  ---
(In reply to David Binderman from comment #30)
> gcc looks to be a trailer on this issue. It's not about standards conformance,
> its about making it easy for users to find bugs.

But under GCC it's not a bug, it just works.  Clang is welcome to adopt the
same semantics.  But I'm also happy to accept the patch in comment #17 once it
includes testing.

And GCC should build with -Wconditionally-supported so we support bootstrapping
with compilers that make different choices.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 5 Dec 2022, siddhesh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
> 
> --- Comment #2 from Siddhesh Poyarekar  ---
> The standard does not allow the nesting, but gcc supports it as an extension.

Does it allow the nesting when nested in a union?

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to Jakub Jelinek from comment #0)
> > > ... but then
> > > comes dom2 and happily replaces
> > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > >   return _1;
> > > with
> > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > >   return  Inf;
> > > (I think this is still correct)
> > 
> > Note this is also a pessimization code-generation wise since if we
> > preserve the multiplication the result is readily available in a
> > register but as optimized we have another constant pool entry and load.
> > 
> > So we might want to consider not propagating constants generated by
> > operations
> > we cannot eliminate.  If the only consumer is a compare-and-branch we
> > can of course still end up with a seemingly dead stmt, so this would be only
> > for the missed optimization.
> 
> Up to y'all if this is the way to go, but here are some thoughts...
> 
> Off the top of my head, we have VRP and DOM propagating constants. 
> Technically also simplify_using_ranges, but it's only called from VRP/DOM,
> and it currently only works with integers, so we should be ok here.
> 
> I think we could limit propagation in may_propagate_copy() which both VRP
> and DOM gate on.  VRP uses it through its use of substitute_and_fold_engine
> and DOM uses it directly.  Would this work?

I don't think may_propagate_copy is the correct vehicle.  Instead the
substitute_and_fold_engine could only substitute from defs with no
side-effects - IIRC it already refrains from propagating _into_ defs
that will be removed after the propagation.

[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #22 from Brjd  ---
Maybe not changing now is the correct way for now since I may change it blindly
not knowing completely what I am doing. Let the developers correct it and will
include it in next releases. The compiler is excellent and at least it may
build older sourced while the newer ones will be waiting for revisions.

[Bug middle-end/87489] [10/11/12/13 Regression] Spurious -Wnonnull warning

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2020-06-03 00:00:00 |2022-12-5

--- Comment #19 from Richard Biener  ---
(In reply to Andrew Church from comment #5)
> Simpler testcase (based on the testcase in bug 87041):
> 
> extern int strcmp(const char *a, const char *b) __attribute__((nonnull(1,
> 2)));
> int foo(void) {
> const char * const s = 0;
> if (s)
> return strcmp(s, "");
> else
> return 2;
> }
> 
> foo.c: In function 'foo':
> foo.c:5:16: warning: null argument where non-null required (argument 1)
> [-Wnonnull]
>  return strcmp(s, "");
> ^~

This one warns in the frontend where we substituted the const char * const s
initializer:

#0  warning_at (location=258981, opt=697, gmsgid=0x2fe4c10 "argument %u null
where non-null expected")
at /home/rguenther/src/trunk/gcc/diagnostic.cc:1876
#1  0x00d2bf3b in check_nonnull_arg (ctx=0x7fffc440,
param=, param_num=1)
at /home/rguenther/src/trunk/gcc/c-family/c-common.cc:5822
#2  0x00d2d22a in check_function_arguments_recurse (callback=0xd2bcdc
, 
ctx=0x7fffc440, param=, param_num=1,
opt=OPT_Wnonnull)
at /home/rguenther/src/trunk/gcc/c-family/c-common.cc:6195
#3  0x00d2b4c9 in check_function_nonnull (ctx=..., nargs=2,
argarray=0x7640bc60)
at /home/rguenther/src/trunk/gcc/c-family/c-common.cc:5621
#4  0x00d2cc9b in check_function_arguments (loc=258981,
fndecl=, 
fntype=, nargs=2, argarray=0x7640bc60,
arglocs=0x7fffc4a0)
at /home/rguenther/src/trunk/gcc/c-family/c-common.cc:6071
#5  0x00c3fad6 in build_function_call_vec (loc=258981, arg_loc=...,
function=, 
params=0x7640bc58 = {...}, origtypes=0x7640be60 = {...},
orig_fundecl=)
at /home/rguenther/src/trunk/gcc/c/c-typeck.cc:3319
#6  0x00c40294 in c_build_function_call_vec (loc=258981, arg_loc=...,
function=, 
params=0x7640bc58 = {...}, origtypes=0x7640be60 = {...}) at
/home/rguenther/src/trunk/gcc/c/c-typeck.cc:3387
#7  0x00ca02bb in c_parser_postfix_expression_after_primary
(parser=0x76275c60, expr_loc=258981, expr=...)
at /home/rguenther/src/trunk/gcc/c/c-parser.cc:11245


Re-confirmed for the other cases.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #5 from Siddhesh Poyarekar  ---
(In reply to rguent...@suse.de from comment #4)
> Does it allow the nesting when nested in a union?

data[] cannot be nested directly in a union (i.e. union { char d; char data[];
} is invalid) but something like below is allowed, again as a gcc extension,
not by the standard.  The standard AFAICT doesn't allow anything other than the
flex array directly at the end of the top level struct.

typedef struct {
  unsigned pad;
  union {
struct {char d; char data[];} f1;
struct {char d; char data[];} f2;
  } flex;
} S2;

In fact this is the use case that led me into this rabbithole.

[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Known to work||13.0
   Keywords||needs-bisection
Summary|[12/13 Regression]  |[12 Regression]
   |-Warray-bounds for  |-Warray-bounds for
   |unreachable code inlined|unreachable code inlined
   |from std::sort()|from std::sort()

--- Comment #5 from Richard Biener  ---
This seems to be fixed on trunk - can somebody bisect what did so?

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

--- Comment #13 from Richard Biener  ---
There's been some changes on trunk but the preprocessed source doesn't work
there.

[Bug tree-optimization/40635] [12/13 Regression] bogus name and location in 'may be used uninitialized' warning

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:0d14720f93a8139a7f234b2762c361e8e5da99cc

commit r13-4495-g0d14720f93a8139a7f234b2762c361e8e5da99cc
Author: Richard Biener 
Date:   Mon Dec 5 16:03:21 2022 +0100

middle-end/40635 - SSA update losing PHI arg loations

The following fixes an issue where SSA update loses PHI argument
locations when updating PHI nodes it didn't create as part of the
SSA update.  For the case where the reaching def is the same as
the current argument opt to do nothing and for the case where the
PHI argument already has a location keep that (that's an indication
the PHI node wasn't created as part of the update SSA process).

PR middle-end/40635
* tree-into-ssa.cc (rewrite_update_phi_arguments): Only
update the argument when the reaching definition is different
from the current argument.  Keep an existing argument
location.

* gcc.dg/uninit-pr40635.c: New testcase.

[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
r13-2894-gbe4a6551ed37c1e7dbdfb9400fc2e2b5d40c5be2 made the warning go away.

[Bug c++/107974] New: compiler can't find source file in path that is longer than 255 characters

[cristian.adam at gmail dot com via Gcc-bugs]

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

Bug ID: 107974
   Summary: compiler can't find source file in path that is longer
than 255 characters
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cristian.adam at gmail dot com
  Target Milestone: ---

Created attachment 54013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54013&action=edit
clang long path

Given the following path "c:\Projects\C++\this is a rather long path for a path
on windows where long paths are a problem with the limit of two hundred fifty
characters but there is a solution which implies adding a registry key and
configuring the project to include a manifest\hello.cpp"

g++ (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 12.2.0 is not able to
compile the source file.

The error reported is:
cc1plus.exe: fatal error: hello.cpp: No such file or directory

Note that LLVM MinGW 15.0.0's clang.exe was able to compile the file just fine.

[Bug target/107957] [AVR] Missed optimization in access to upper-half of a variable

[mrjjot at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jacek Wieczorek  ---
A little correction - I just noticed my mistake. Assembly for rawr() is in fact
correct. Apparently this happens only for variables longer than 16 bits.

[Bug c++/107974] compiler can't find source file in path that is longer than 255 characters

[cristian.adam at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Cristian Adam  ---
Visual C++ 2022 also suffers from the same problem, see
https://developercommunity.visualstudio.com/t/compiler-cant-find-source-file-in-path/10221576

For some reason clang is working fine.

[Bug c++/107974] compiler can't find source file in path that is longer than 255 characters

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

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

--- Comment #2 from Andrew Pinski  ---
GCC just does:
file->fd = open (file->path, O_RDONLY | O_NOCTTY | O_BINARY, 0666);

[Bug target/107969] ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 54014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54014&action=edit
gcc13-pr107969.patch

Indeed, because libgcc doesn't define the functions that soft-float uses.
Anyway, this patch should fix that.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #9 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #8)
> (In reply to Aldy Hernandez from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > (In reply to Jakub Jelinek from comment #0)
> > > > ... but then
> > > > comes dom2 and happily replaces
> > > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > > >   return _1;
> > > > with
> > > >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> > > >   return  Inf;
> > > > (I think this is still correct)
> > > 
> > > Note this is also a pessimization code-generation wise since if we
> > > preserve the multiplication the result is readily available in a
> > > register but as optimized we have another constant pool entry and load.
> > > 
> > > So we might want to consider not propagating constants generated by
> > > operations
> > > we cannot eliminate.  If the only consumer is a compare-and-branch we
> > > can of course still end up with a seemingly dead stmt, so this would be 
> > > only
> > > for the missed optimization.
> > 
> > Up to y'all if this is the way to go, but here are some thoughts...
> > 
> > Off the top of my head, we have VRP and DOM propagating constants. 
> > Technically also simplify_using_ranges, but it's only called from VRP/DOM,
> > and it currently only works with integers, so we should be ok here.
> > 
> > I think we could limit propagation in may_propagate_copy() which both VRP
> > and DOM gate on.  VRP uses it through its use of substitute_and_fold_engine
> > and DOM uses it directly.  Would this work?
> 
> I don't think may_propagate_copy is the correct vehicle.  Instead the
> substitute_and_fold_engine could only substitute from defs with no
> side-effects - IIRC it already refrains from propagating _into_ defs
> that will be removed after the propagation.

So where do you suggest we clamp this?  The uses I can think of are VRP
(various places in tree-ssa-propagate.cc) and DOM (cprop_operand).

[Bug target/107969] ICE in extract_insn, at recog.cc:2791 since r13-3292-gc2565a31c1622ab0

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

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

--- Comment #4 from Jakub Jelinek  ---
I mean should fix the ICE, nothing else.

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #14 from Thiago Macieira  ---
Created attachment 54015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54015&action=edit
qfutureinterface.cpp preprocessed [gcc trunk-20221205]

(In reply to Richard Biener from comment #13)
> There's been some changes on trunk but the preprocessed source doesn't work
> there.

Uploaded the updated preprocessed source with current trunk, from roughly the
same Qt commit (I chose a date just before this bug report was opened).

I can still reproduce this issue with the minimal original sources and these
preprocessed, but somehow not with the actual qfutureinterface.cpp, either then
or now.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to caiyinyu from comment #2)
> I tested with latest gcc(commit 102f3cef568), and these fails still exist.

Do the glibc test logs provide some details on what exactly failed, if it is a
wrong-code issue or if the testcase expects some floating point exception that
isn't triggered?

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

[cristian.adam at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Cristian Adam  ---
I've used the manifest tool from Visual C++ (mt.exe) to inject this manifest:





http://schemas.microsoft.com/SMI/2016/WindowsSettings";>
true




with the command line:
mt.exe -nologo -manifest "cc1plus.exe.manifest"
-outputresource:"cc1plus.exe;#1"

And I was able to compile the hello.cpp source file!

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

[cristian.adam at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Cristian Adam  ---
The manifest file is being mentioned at
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

[cristian.adam at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Cristian Adam  ---
Created attachment 54016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54016&action=edit
gcc long path working

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-12-05

--- Comment #6 from Andrew Pinski  ---
I would suspect this is a standard issue with all mingw projects so maybe it is
best to talk with them on how to solve this overall.

[Bug tree-optimization/107975] New: [13 Regression] frange ICE since r13-4492

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

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

Bug ID: 107975
   Summary: [13 Regression] frange ICE since r13-4492
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

My r13-4492-g4500baaccb6e4d696e223c338bbdf7705c3646dd change caused ICE on:
double
foo (double x, double y)
{
  if (x == 42.0)
return 1.0;
  double r = x * y;
  if (!__builtin_isnan (r))
__builtin_unreachable ();
  return r;
}

[Bug tree-optimization/107975] [13 Regression] frange ICE since r13-4492

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |13.0
   Last reconfirmed||2022-12-05
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #13 from David Faust  ---
Created attachment 54017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54017&action=edit
DATASEC entries for extern funcs

Applies on top of 54002: updated patch
Adds emission of DATASEC entries for extern funcs. Rough, needs cleanup.

[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Jason Merrill  ---
A lot of the problem here is that building a std::string involves building a
std::allocator temporary to pass to the string constructor, and then we
need to wait until the entire array is built before we can destroy any of them:
https://eel.is/c++draft/class.temporary#5 says we can only destroy temporaries
early if there was no initializer for that array element.  So for each element
of the initializer we have another EH region for its allocator temporary.

We could do better for the general case by creating a parallel array of
temporaries and using the same single cleanup region for it as for the array of
strings.  This seems like a worthwhile general optimization.

We might be able to do better for the specific case by recognizing that
std::allocator has no data and nothing cares about its address, so we can go
ahead and destroy it after initializing the string, and reuse the stack slot. 
This also saves stack space.

[Bug tree-optimization/107975] [13 Regression] frange ICE since r13-4492

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

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

--- Comment #1 from Jakub Jelinek  ---
The testcase was guessed from the
https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
report.

[Bug tree-optimization/107973] wrong warning with -Werror -fsanitize=address

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Thanks,

I see a very similar warning with
m68k-linux-gnu-gcc but without sanitizer:

crypto/modes/cfb128.c: In function 'CRYPTO_cfb128_encrypt':
crypto/modes/cfb128.c:117:33: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
  117 | ivec[n] = c;
  | ^~~
crypto/modes/cfb128.c:27:42: note: at offset 16 into destination object 'ivec'
of size [0, 16]
   27 |unsigned char ivec[16], int *num,
  |~~^~~~
cc1: all warnings being treated as errors

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #5 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
> 
> using difference_type = iterator_t>;
> 
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things.

I would never do that.

However, I see that you seem to have considered this issue elsewhere, in
format#L2561:

if constexpr (!is_integral_v
|| sizeof(__n) > sizeof(size_t))
  {
// __int128 or __detail::__max_diff_type
auto __m = (decltype(__n))(size_t)-1;
if (__n > __m)
  __n = __m;
  }

[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #10)
> A lot of the problem here is that building a std::string involves building a
> std::allocator temporary to pass to the string constructor, and then
> we need to wait until the entire array is built before we can destroy any of
> them: https://eel.is/c++draft/class.temporary#5 says we can only destroy
> temporaries early if there was no initializer for that array element.  So
> for each element of the initializer we have another EH region for its
> allocator temporary.
> 
> We could do better for the general case by creating a parallel array of
> temporaries and using the same single cleanup region for it as for the array
> of strings.  This seems like a worthwhile general optimization.
> 
> We might be able to do better for the specific case by recognizing that
> std::allocator has no data and nothing cares about its address, so we can go
> ahead and destroy it after initializing the string, and reuse the stack
> slot.  This also saves stack space.

Even if we don't emit a loop (which I still think is the way to go for larger
initializers because anything else means just too large code), can't there for
the larger initializers simply be some variable holding a counter how many
initializers have been already initialized and a single EH region that will
perform all the cleanups based on that counter?

[Bug testsuite/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #7 from Jeffrey A. Law  ---
Yea, I think that's a better solution than simply disabling the whole ieee
directory on the rx.  It appears to DTRT for inf-2 which was the problematical
test.

Consider it pre-approved.

[Bug tree-optimization/107976] New: ICE: SIGSEGV (stack overflow) in emit_case_dispatch_table (stmt.cc:783) with large --param=jump-table-max-growth-ratio-for-speed

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107976
   Summary: ICE: SIGSEGV (stack overflow) in
emit_case_dispatch_table (stmt.cc:783) with large
--param=jump-table-max-growth-ratio-for-speed
   Product: gcc
   Version: 13.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: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc
--param=jump-table-max-growth-ratio-for-speed=1813160384 testcase.c 
x86_64-pc-linux-gnu-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.


Program received signal SIGSEGV, Segmentation fault.
0x0138aa18 in emit_case_dispatch_table (index_expr=0x7770be58,
index_type=0x7771f5e8, case_list=..., default_label=0x7771a2c0,
default_edge=0x778d23f0, minval=0x77885fc0, maxval=0x778b59d8,
range=0x778d7a98, stmt_bb=0x778ad600) at
/repo/gcc-trunk/gcc/stmt.cc:783
783   memset (labelvec, 0, ncases * sizeof (rtx));
(gdb) list
778 
779   /* Get table of labels to jump to, in order of case index.  */
780 
781   ncases = tree_to_shwi (range) + 1;
782   labelvec = XALLOCAVEC (rtx, ncases);
783   memset (labelvec, 0, ncases * sizeof (rtx));
784 
785   for (unsigned j = 0; j < case_list.length (); j++)
786 {
787   simple_case_node *n = &case_list[j];
(gdb) p ncases
$1 = 69108865