[Bug middle-end/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu

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

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

--- Comment #10 from Richard Biener  ---
vec<> doesn't really support "large" vectors:

  unsigned m_alloc : 31;
  unsigned m_using_auto_storage : 1;
  unsigned m_num;

so it's basically using 'int'.  I guess we should make that
alloc = (alloc * 3 / 2) use size_t though or simply do (alloc / 2) * 3
since we know alloc >= 16 here so the rounding error isn't important.

Still ICEing on overflow here would be desirable.

[Bug tree-optimization/61338] too many permutation in a vectorized "reverse loop"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

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

[Bug tree-optimization/112892] MAX, VEC_PERM> could be just VEC_PERM,...,c>

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Turns out this is a dup of bug 61338 .

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

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Hongyu Wang  changed:

   What|Removed |Added

 CC||wwwhhhyyy333 at gmail dot com

--- Comment #9 from Hongyu Wang  ---
(In reply to Hongtao Liu from comment #4)
> there're 2 reasons.

> 2. There's still spills for (subreg:DF (reg: V8DF) since
> ix86_modes_tieable_p return false for DF and V8DF.
> 

There could be some issue in sra that the aggregates are not properly
scalarized due to size limit.

The sra considers maximum aggregate size using move_ratio * UNITS_PER_WORD, but
here the aggregate Dual, 2l> actually contains several V8DF
component that can be handled in zmm under avx512f. 

Add --param sra-max-scalarization-size-Ospeed=2048 will eliminate those spills

So for sra we can consider using MOVE_MAX * move_ratio as the size limit for
Ospeed which represents real backend instruction count.

[Bug target/112891] [10/11/12/13/14 Regression] Missing vzeroupper insert.

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

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

--- Comment #3 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #2)
> (In reply to Hongtao Liu from comment #1)
> > Aaused by r10-3477-g2a2e3a0dfcbe08, Can be fixed by revert the patch.
> > 
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -15032,14 +15032,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
> >if (avx_upper_reg_found)
> > return AVX_U128_DIRTY;
> > 
> > -  /* If the function is known to preserve some SSE registers,
> > -RA and previous passes can legitimately rely on that for
> > -modes wider than 256 bits.  It's only safe to issue a
> > -vzeroupper if all SSE registers are clobbered.  */
> > -  const function_abi  = insn_callee_abi (insn);
> > -  if (vzeroupper_pattern (PATTERN (insn), VOIDmode)
> > - || !hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
> > -abi.mode_clobbers (V4DImode)))
> > +  if (vzeroupper_pattern (PATTERN (insn), VOIDmode))
> > return AVX_U128_ANY;
> > 
> >return AVX_U128_CLEAN;
> Remove this regressed many testcases
> 
> So it looks like we need to handle ix86_avx_u128_mode_after 
> 
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -15177,7 +15177,14 @@ ix86_avx_u128_mode_after (int mode, rtx_insn *insn)
>bool avx_upper_reg_found = false;
>note_stores (insn, ix86_check_avx_upper_stores, _upper_reg_found);
> 
> -  return avx_upper_reg_found ? AVX_U128_DIRTY : AVX_U128_CLEAN;
> +  if (avx_upper_reg_found)
> +   return AVX_U128_DIRTY;
> +
> +  const function_abi  = insn_callee_abi (insn);
> +  if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
> + abi.mode_clobbers (V4DImode)))
> +   return AVX_U128_ANY;
> +  return  AVX_U128_CLEAN;
>  }

Also for sibcall, we should return AVX_U128_CLEAN for
ix86_avx_u128_mode_needed.

[Bug middle-end/112895] New: ICE: error reporting routines re-entered. (in check_tag cp/class.cc:1474) with -fdiagnostics-format=sarif-stderr on simple C++ code

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112895
   Summary: ICE: error reporting routines re-entered. (in
check_tag cp/class.cc:1474) with
-fdiagnostics-format=sarif-stderr on simple C++ code
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  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 56823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56823=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fdiagnostics-format=sarif-stderr testcase.C

internal compiler error: error reporting routines re-entered.
{"$schema":
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json;,
 "version": "2.1.0",
 "runs": [{"tool": {"driver": {"name": "GNU C++17",
   "fullName": "GNU C++17 (GCC) version 14.0.0
20231207 (experimental) (x86_64-pc-linux-gnu)",
   "version": "14.0.0 20231207 (experimental)",
   "informationUri": "https://gcc.gnu.org/gcc-14/;,
   "rules": [{"id": "-Wreturn-type",
  "helpUri":
"https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-type"}]}},
   "invocations": [{"executionSuccessful": true,
"toolExecutionNotifications": []}],
   "originalUriBaseIds": {"PWD": {"uri":
"file:///home/smatz/gcc-bug/569/"}},
   "artifacts": [{"location": {"uri": "testcase.C",
   "uriBaseId": "PWD"},
  "contents": {"text": "inline namespace __cxx11
__attribute__((__abi_tag__))\n{\n  struct basic_string\n  {\n  };\n} //
namespace __cxx11\n\nbasic_string\nGetSMFFile ()\n{\n}\n"},
  "sourceLanguage": "cplusplus"}],
   "results": []}]}
Internal compiler error:
0xee6ad7 check_tag
/repo/gcc-trunk/gcc/cp/class.cc:1474
0xee6ad7 mark_or_check_attr_tags
/repo/gcc-trunk/gcc/cp/class.cc:1517
0xee6ad7 mark_or_check_tags
/repo/gcc-trunk/gcc/cp/class.cc:1542
0xee6c59 find_abi_tags_r
/repo/gcc-trunk/gcc/cp/class.cc:1566
0x1b0b6b4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/repo/gcc-trunk/gcc/tree.cc:11420
0x1b0ed95 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/repo/gcc-trunk/gcc/tree.cc:11680
0xee7fd1 check_abi_tags
/repo/gcc-trunk/gcc/cp/class.cc:1649
0xfdd424 write_mangled_name
/repo/gcc-trunk/gcc/cp/mangle.cc:790
0xfe3450 mangle_decl_string
/repo/gcc-trunk/gcc/cp/mangle.cc:4393
0xfe363a get_mangled_id
/repo/gcc-trunk/gcc/cp/mangle.cc:4414
0xfe363a mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4452
0x1ae611d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x1886108 compiler_logical_location::get_internal_name_for_tree(tree_node*)
/repo/gcc-trunk/gcc/tree-logical-location.cc:59
0x1886108 current_fndecl_logical_location::get_internal_name() const
/repo/gcc-trunk/gcc/tree-logical-location.cc:140
0x2c983c0 sarif_builder::make_logical_location_object(logical_location const&)
const
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:1109
0x2c99ee1 sarif_builder::set_any_logical_locs_arr(json::object*,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:757
0x2c99ee1 sarif_builder::set_any_logical_locs_arr(json::object*,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:751
0x2c99ee1 sarif_builder::make_location_object(rich_location const&,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:780
0x2c9a0be sarif_builder::make_locations_arr(diagnostic_info const&)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:742
0x2c9bba5 sarif_builder::make_result_object(diagnostic_context*,
diagnostic_info const&, diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:604
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc

[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails

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

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

--- Comment #2 from Andrew Pinski  ---
Maybe caused by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781
...

[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails

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

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

--- Comment #1 from Andrew Pinski  ---
Started at or before r14-6204-g953a9302d1 :
https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/802491.html

[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug testsuite/112894] New: [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails

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

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

Bug ID: 112894
   Summary: [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C
fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 28 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 29 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 43 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 44 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 45 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 75 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 76 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17  dg-regexp 77 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17 warning at line 30
(test for warnings, line )
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++17 warning at line 46
(test for warnings, line )
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 28 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 29 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 43 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 44 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 45 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 75 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 76 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20  dg-regexp 77 not
found: " *inlined from [^\\n
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20 warning at line 30
(test for warnings, line )
+FAIL: g++.dg/warn/Winvalid-memory-model-2.C  -std=gnu++20 warning at line 46
(test for warnings, line )


-LAST_UPDATED: Tue Dec  5 22:01:45 UTC 2023 (revision r14-6194-g9610ba7b6ff)
+LAST_UPDATED: Wed Dec  6 22:45:04 UTC 2023 (revision r14-6236-g09a08df7193)

[Bug target/112890] [14 Regression] gcc.dg/vect/tsvc/vect-tsvc-s1281.c timesout with -march=armv9-a+sve

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Andrew Pinski  ---
This works again with:
LAST_UPDATED: Wed Dec  6 22:45:04 UTC 2023 (revision r14-6236-g09a08df7193)

So maybe just a testing issue ...

[Bug target/112891] [10/11/12/13/14 Regression] Missing vzeroupper insert.

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

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

--- Comment #2 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #1)
> Aaused by r10-3477-g2a2e3a0dfcbe08, Can be fixed by revert the patch.
> 
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -15032,14 +15032,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
>if (avx_upper_reg_found)
> return AVX_U128_DIRTY;
> 
> -  /* If the function is known to preserve some SSE registers,
> -RA and previous passes can legitimately rely on that for
> -modes wider than 256 bits.  It's only safe to issue a
> -vzeroupper if all SSE registers are clobbered.  */
> -  const function_abi  = insn_callee_abi (insn);
> -  if (vzeroupper_pattern (PATTERN (insn), VOIDmode)
> - || !hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
> -abi.mode_clobbers (V4DImode)))
> +  if (vzeroupper_pattern (PATTERN (insn), VOIDmode))
> return AVX_U128_ANY;
> 
>return AVX_U128_CLEAN;
Remove this regressed many testcases

So it looks like we need to handle ix86_avx_u128_mode_after 

--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -15177,7 +15177,14 @@ ix86_avx_u128_mode_after (int mode, rtx_insn *insn)
   bool avx_upper_reg_found = false;
   note_stores (insn, ix86_check_avx_upper_stores, _upper_reg_found);

-  return avx_upper_reg_found ? AVX_U128_DIRTY : AVX_U128_CLEAN;
+  if (avx_upper_reg_found)
+   return AVX_U128_DIRTY;
+
+  const function_abi  = insn_callee_abi (insn);
+  if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
+ abi.mode_clobbers (V4DImode)))
+   return AVX_U128_ANY;
+  return  AVX_U128_CLEAN;
 }

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:3d0f3382fa7b5677f35a9becf75ac436cd7eda7b

commit r14-6261-g3d0f3382fa7b5677f35a9becf75ac436cd7eda7b
Author: Alexandre Oliva 
Date:   Thu Dec 7 00:38:14 2023 -0300

libsupc++: try cxa_thread_atexit_impl at runtime

g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run using that toolchain on a (later) platform that offers
__cxa_thread_atexit_impl.

This patch adds runtime testing for __cxa_thread_atexit_impl on select
platforms (GNU variants, for starters) that support weak symbols.


for  libstdc++-v3/ChangeLog

PR libstdc++/112858
* config/os/gnu-linux/os_defines.h
(_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL): Define.
* libsupc++/atexit_thread.cc [__GXX_WEAK__ &&
_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL]
(__cxa_thread_atexit): Add dynamic detection of
__cxa_thread_atexit_impl.

[Bug target/105576] x86: Support a machine constraint to get raw symbol name

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #7 from Julian Waters  ---
Strangely, the following works if compiled with optimizations enabled, -O1 and
above, but not with -O0, when optimizations are disabled

[[gnu::extended(; [dispatcher] "i" (static_cast([] ()
noexcept -> void {})); ; start)]]
asm (R"(
.endif
.rva %l[start], 1f, %c[dispatcher], 2f
.seh_code
)");

With -O0 the error is

exceptions.cpp: In function 'void exceptions()':
exceptions.cpp:59:5: warning: 'asm' operand 0 probably does not match
constraints
   59 | asm (R"(
  | ^~~
exceptions.cpp:59:5: error: impossible constraint in 'asm'

With -O1 and above, %c[dispatcher] yields:

.rva .L2, 1f, _ZZL10exceptionsvENUlPVK19_EXCEPTION_POINTERSPVKvE0_4_FUNES1_S3_,
2f

[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

--- Comment #3 from Gaius Mulley  ---
Created attachment 56822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56822=edit
Proposed fix v1

Here is version 1 of a bugfix which catches an actual parameter of type address
as a mismatch with a formal parameter of type cardinal.  It treats all
procedures without () as an address.  This satisfies ISO modula-2 but not the
PIM variants.

Version 2 should improve the type checker (M2Check) module by changing the
assumption that a procedure without () is an address to a pointer of a fully
formed proc type.  In turn SymbolTable.GetType should be changed to return the
pointer to proc type.  Every call to SymbolTable.GetType would need to be
eyeball checked and maybe replaced by GetReturnType if necessary.

[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

--- Comment #2 from Gaius Mulley  ---
This bug has been forwarded from the gm2 mailing list.

[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-07
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/112893] New: gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

Bug ID: 112893
   Summary: gm2 fails to detect procedure address actual parameter
is incompatible with cardinal formal parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

gm2 silently compiles the following code:

MODULE proccard ;

FROM NumberIO IMPORT WriteCard ;
FROM StrIO IMPORT WriteString, WriteLn ;

PROCEDURE func () : CARDINAL ;
BEGIN
   RETURN 42
END func ;


BEGIN
   WriteString ('the value is: ') ; WriteCard (func, 5) ; WriteLn
END proccard.

whereas it should detect that func is the address of a procedure and this is
incompatible with the cardinal 1st parameter of WriteCard.

[Bug tree-optimization/112892] New: MAX, VEC_PERM> could be just VEC_PERM,...,c>

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

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

Bug ID: 112892
   Summary: MAX, VEC_PERM> could be just
VEC_PERM,...,c>
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
static inline int MAX(int a, int b)
{
if (a < b)  return b;
return a;
}

void f(int *a, int n)
{
  n = 128;
  int i;
  for(i = n-1; i >= 1; i--)
  {
a[i] = MAX(a[i], a[i-1]);
  }
}
```
Currently we vectorize to:
```
  vect__4.9_43 = MEM  [(int *)vectp_a.7_41];
  vect__4.10_44 = VEC_PERM_EXPR ;
  vect__7.13_48 = MEM  [(int *)vectp_a.7_41 + -4B];
  vect__7.14_49 = VEC_PERM_EXPR ;
  vect__12.15_50 = MAX_EXPR ;
  vect__12.18_54 = VEC_PERM_EXPR ;
  MEM  [(int *)vectp_a.7_41] = vect__12.18_54;
```

But the VEC_PERMs here can be removed ...
as we are generating the opposite vector and such.

[Bug target/112891] [10/11/12/13/14 Regression] Missing vzeroupper insert.

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

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

Hongtao Liu  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Hongtao Liu  ---
Aaused by r10-3477-g2a2e3a0dfcbe08, Can be fixed by revert the patch.

--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -15032,14 +15032,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
   if (avx_upper_reg_found)
return AVX_U128_DIRTY;

-  /* If the function is known to preserve some SSE registers,
-RA and previous passes can legitimately rely on that for
-modes wider than 256 bits.  It's only safe to issue a
-vzeroupper if all SSE registers are clobbered.  */
-  const function_abi  = insn_callee_abi (insn);
-  if (vzeroupper_pattern (PATTERN (insn), VOIDmode)
- || !hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
-abi.mode_clobbers (V4DImode)))
+  if (vzeroupper_pattern (PATTERN (insn), VOIDmode))
return AVX_U128_ANY;

   return AVX_U128_CLEAN;


It looks like abi.mode_clobbers is not equal to there's ymm/zmm live through
the callee, it just means callee doens't need to clobber those registers
according to RA. So when there's no 256/512-bit registers live through the
callee there're would be some mistake for the mode. since
ix86_avx_u128_mode_after will return AVX_U128_CLEAN is there's no 256/512-bit
registers are returned, but actaully it 's still dirty for upper bits since
there's no vzeroupper inserted.

[Bug target/112891] New: [10/11/12/13/14 Regression] Missing vzeroupper insert.

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

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

Bug ID: 112891
   Summary: [10/11/12/13/14 Regression] Missing vzeroupper insert.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

#include
void
__attribute__((noinline))
bar (double* a)
{
a[0] = 1.0;
a[1] = 2.0;
}

void
__attribute__((noinline))
foo (double* __restrict a, double* b)
{
a[0] += b[0];
a[1] += b[1];
a[2] += b[2];
a[3] += b[3];
bar (b);
}

double
foo1 (double* __restrict a, double* b)
{
foo (a, b);
return exp (b[1]);
}


gcc -O3 -mavx2 Got

bar(double*):
vmovapd xmm0, XMMWORD PTR .LC0[rip]
vmovupd XMMWORD PTR [rdi], xmm0
ret
foo(double*, double*):
mov rax, rdi
vmovupd ymm0, YMMWORD PTR [rsi]
mov rdi, rsi
vaddpd  ymm0, ymm0, YMMWORD PTR [rax]
vmovupd YMMWORD PTR [rax], ymm0
jmp bar(double*)
foo1(double*, double*):
sub rsp, 8
callfoo(double*, double*)
vmovsd  xmm0, QWORD PTR [rsi+8]
add rsp, 8
jmp exp
.LC0:
.long   0
.long   1072693248
.long   0
.long   1073741824

In foo, 256-bit ymm are used, and the upper bits are dirty, but there's no
vzeroupper inserted by exp which cause big avx->sse transition penalty.

[Bug tree-optimization/112859] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||sjames at gcc dot gnu.org
Summary|[12/13/14 Regression] wrong |[12/13/14 Regression] wrong
   |code at -O3 on  |code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-2097-g9f34b780b0461e

--- Comment #3 from Sam James  ---
bisected to r12-2097-g9f34b780b0461e

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

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

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

Bug 112850 Summary: -Wanalyzer-tainted-allocation-size false positive seen in 
Linux kernel's sound/core/rawmidi.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112850

   What|Removed |Added

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

[Bug analyzer/112850] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's sound/core/rawmidi.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed on trunk (for gcc 14) by the above commit.

[Bug analyzer/103546] -Wanalyzer-null-dereference false positives reported on flex-generated scanners

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

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

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

https://gcc.gnu.org/g:08b7462d3ad8e5acd941b7c777c5b26b4064d686

commit r14-6239-g08b7462d3ad8e5acd941b7c777c5b26b4064d686
Author: David Malcolm 
Date:   Wed Dec 6 19:25:26 2023 -0500

analyzer: fix taint false positives with UNKNOWN [PR112850]

PR analyzer/112850 reports a false positive from
-Wanalyzer-tainted-allocation-size on the Linux kernel [1] where
-fanalyzer complains that an allocation size is attacker-controlled
despite the value being correctly sanitized against upper and lower
limits.

The root cause is that the expression is sufficiently complex
to exceed the -param=analyzer-max-svalue-depth= threshold,
currently at 12, with depth 13, and so it is treated as UNKNOWN.
Hence the sanitizations are seen as comparisons of an UNKNOWN
symbolic value against constants, and these were being ignored
by the taint state machine.

The expression in question is relatively typical for those seen in
Linux kernel ioctl handlers, and I was surprised that it had exceeded
the analyzer's default expression complexity limit.

This patch addresses this problem in three ways:
(a) the default value of the threshold parameter is increased, from 12
to 18, so that such expressions are precisely handled
(b) adding a new -Wanalyzer-symbol-too-complex to warn when the symbol
complexity limit is reached.  This is off by default for users, and
on by default in the test suite.
(c) the taint state machine handles comparisons against UNKNOWN svalues
by dropping all taint information on that execution path, so that if
the complexity limit has been exceeded we don't generate false positives

As well as fixing the taint false positive (PR analyzer/112850), the
patch also fixes a couple of leak false positives seen on flex-generated
scanners (PR analyzer/103546).

[1] specifically, in sound/core/rawmidi.c's handler for
SNDRV_RAWMIDI_STREAM_OUTPUT.

gcc/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* doc/invoke.texi: Add -Wanalyzer-symbol-too-complex.

gcc/analyzer/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* analyzer.opt (-param=analyzer-max-svalue-depth=): Increase from
12 to 18.
(Wanalyzer-symbol-too-complex): New.
* diagnostic-manager.cc
(null_assignment_sm_context::clear_all_per_svalue_state): New.
* engine.cc (impl_sm_context::clear_all_per_svalue_state): New.
* program-state.cc (sm_state_map::clear_all_per_svalue_state):
New.
* program-state.h (sm_state_map::clear_all_per_svalue_state): New
decl.
* region-model-manager.cc
(region_model_manager::reject_if_too_complex): Add
-Wanalyzer-symbol-too-complex.
* sm-taint.cc (taint_state_machine::on_condition): Handle
comparisons against UNKNOWN.
* sm.h (sm_context::clear_all_per_svalue_state): New.

gcc/testsuite/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* c-c++-common/analyzer/call-summaries-pr107158-2.c: Add
-Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/call-summaries-pr107158.c: Likewise.
*
c-c++-common/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c:
Likewise.
* c-c++-common/analyzer/feasibility-3.c: Add
-Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/flex-with-call-summaries.c: Add
-Wno-analyzer-symbol-too-complex.  Remove fail for
PR analyzer/103546 leak false positive.
* c-c++-common/analyzer/flex-without-call-summaries.c: Remove
xfail for PR analyzer/103546 leak false positive.
* c-c++-common/analyzer/infinite-recursion-3.c: Add
-Wno-analyzer-symbol-too-complex.
*
c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
Likewise.
*
c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:
Likewise.
* c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c:
Likewise.
* c-c++-common/analyzer/null-deref-pr108806-qemu.c: Likewise.
* c-c++-common/analyzer/null-deref-pr108830.c: Likewise.
* c-c++-common/analyzer/pr94596.c: Likewise.
* c-c++-common/analyzer/strtok-2.c: Likewise.
* c-c++-common/analyzer/strtok-4.c: Add -Wno-analyzer-too-complex
and -Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/strtok-cppreference.c: Likewise.
* gcc.dg/analyzer/analyzer.exp: Add -Wanalyzer-symbol-too-complex

[Bug analyzer/112850] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's sound/core/rawmidi.c

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

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

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

https://gcc.gnu.org/g:08b7462d3ad8e5acd941b7c777c5b26b4064d686

commit r14-6239-g08b7462d3ad8e5acd941b7c777c5b26b4064d686
Author: David Malcolm 
Date:   Wed Dec 6 19:25:26 2023 -0500

analyzer: fix taint false positives with UNKNOWN [PR112850]

PR analyzer/112850 reports a false positive from
-Wanalyzer-tainted-allocation-size on the Linux kernel [1] where
-fanalyzer complains that an allocation size is attacker-controlled
despite the value being correctly sanitized against upper and lower
limits.

The root cause is that the expression is sufficiently complex
to exceed the -param=analyzer-max-svalue-depth= threshold,
currently at 12, with depth 13, and so it is treated as UNKNOWN.
Hence the sanitizations are seen as comparisons of an UNKNOWN
symbolic value against constants, and these were being ignored
by the taint state machine.

The expression in question is relatively typical for those seen in
Linux kernel ioctl handlers, and I was surprised that it had exceeded
the analyzer's default expression complexity limit.

This patch addresses this problem in three ways:
(a) the default value of the threshold parameter is increased, from 12
to 18, so that such expressions are precisely handled
(b) adding a new -Wanalyzer-symbol-too-complex to warn when the symbol
complexity limit is reached.  This is off by default for users, and
on by default in the test suite.
(c) the taint state machine handles comparisons against UNKNOWN svalues
by dropping all taint information on that execution path, so that if
the complexity limit has been exceeded we don't generate false positives

As well as fixing the taint false positive (PR analyzer/112850), the
patch also fixes a couple of leak false positives seen on flex-generated
scanners (PR analyzer/103546).

[1] specifically, in sound/core/rawmidi.c's handler for
SNDRV_RAWMIDI_STREAM_OUTPUT.

gcc/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* doc/invoke.texi: Add -Wanalyzer-symbol-too-complex.

gcc/analyzer/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* analyzer.opt (-param=analyzer-max-svalue-depth=): Increase from
12 to 18.
(Wanalyzer-symbol-too-complex): New.
* diagnostic-manager.cc
(null_assignment_sm_context::clear_all_per_svalue_state): New.
* engine.cc (impl_sm_context::clear_all_per_svalue_state): New.
* program-state.cc (sm_state_map::clear_all_per_svalue_state):
New.
* program-state.h (sm_state_map::clear_all_per_svalue_state): New
decl.
* region-model-manager.cc
(region_model_manager::reject_if_too_complex): Add
-Wanalyzer-symbol-too-complex.
* sm-taint.cc (taint_state_machine::on_condition): Handle
comparisons against UNKNOWN.
* sm.h (sm_context::clear_all_per_svalue_state): New.

gcc/testsuite/ChangeLog:
PR analyzer/103546
PR analyzer/112850
* c-c++-common/analyzer/call-summaries-pr107158-2.c: Add
-Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/call-summaries-pr107158.c: Likewise.
*
c-c++-common/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c:
Likewise.
* c-c++-common/analyzer/feasibility-3.c: Add
-Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/flex-with-call-summaries.c: Add
-Wno-analyzer-symbol-too-complex.  Remove fail for
PR analyzer/103546 leak false positive.
* c-c++-common/analyzer/flex-without-call-summaries.c: Remove
xfail for PR analyzer/103546 leak false positive.
* c-c++-common/analyzer/infinite-recursion-3.c: Add
-Wno-analyzer-symbol-too-complex.
*
c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
Likewise.
*
c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:
Likewise.
* c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c:
Likewise.
* c-c++-common/analyzer/null-deref-pr108806-qemu.c: Likewise.
* c-c++-common/analyzer/null-deref-pr108830.c: Likewise.
* c-c++-common/analyzer/pr94596.c: Likewise.
* c-c++-common/analyzer/strtok-2.c: Likewise.
* c-c++-common/analyzer/strtok-4.c: Add -Wno-analyzer-too-complex
and -Wno-analyzer-symbol-too-complex.
* c-c++-common/analyzer/strtok-cppreference.c: Likewise.
* gcc.dg/analyzer/analyzer.exp: Add -Wanalyzer-symbol-too-complex

[Bug target/112888] [14 Regression] RISCV ICE: in compute_lcm_local_properties, at config/riscv/riscv-vsetvl.cc:2695

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick O'Neill  ---
Tested locally - confirmed to resolve the failure & committed.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=db642d60ee81cd99d55f4e228d01de704b5b7cfa

Thanks for the quick fix!

[Bug target/112888] [14 Regression] RISCV ICE: in compute_lcm_local_properties, at config/riscv/riscv-vsetvl.cc:2695

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from JuzheZhong  ---
Could you commit this patch for me ?:

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639642.html

This patch fixes this ICE.

My internet can not access the gcc.git.

[Bug target/112890] New: [14 Regression] gcc.dg/vect/tsvc/vect-tsvc-s1281.c timesout with -march=armv9-a+sve

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

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

Bug ID: 112890
   Summary: [14 Regression] gcc.dg/vect/tsvc/vect-tsvc-s1281.c
timesout with -march=armv9-a+sve
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

WARNING: gcc.dg/vect/tsvc/vect-tsvc-s1281.c execution test program timed out.
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1281.c execution test

It worked with:
LAST_UPDATED: Fri Dec  1 20:44:17 UTC 2023 (revision r14-6063-gc6bb413eeb9)

But fails with:
LAST_UPDATED: Tue Dec  5 22:01:45 UTC 2023 (revision r14-6194-g9610ba7b6ff)


This is with qemu so I am not 100% sure if this is a GCC bug or a qemu bug. I
am using qemu 8.1.3 .

[Bug ipa/81323] IPA-VRP doesn't handle return values

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #9 from Jan Hubicka  ---
Note that  r14-5628-g53ba8d669550d3 does just the easy part of propagating
within single translation unit. We will need to add actual IPA bits into WPA
next stage1

[Bug fortran/112873] F2023 degree trig functions

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06
 Status|UNCONFIRMED |NEW

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> PS:  I implemented the half-cycle trig functions (e.g., sinpi, ...) for
> FreeBSD a few years ago.  These have a 2-clause BSD license.  I'm
> willing to dual-license the code with LGPL if you think these might
> be good fallback routines.

Thanks for the offer.  But do we actually need fallback routines?

In your experience, how good (or bad) is a naive inline version
like we do for the degree versions?

[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c

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

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

Alexandre Oliva  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Alexandre Oliva  ---
The testcase changes silenced the noise that made the problem visible, but the
latent bug is still lurking.

The patch that cures the underlying bug is at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638949.html

[Bug target/112871] [14 Regression] RISCV ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -03 rv32gc_zicond

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Created attachment 56821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56821=edit
testcase-2-freport-bug-output

Here's a different testcase that manifests the same error:
int a, b, d, e, c;
char *f;
static int g;
void h(long long i) {
  int *j = 
  ++*j;
k:
  if (c >> d) {
e = a % b;
(*j = i) && ++*j;
*f |= 1;
if (i)
  goto k;
  }
}

> /scratch/tc-testing/tc-dec-6-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32gcv_zicond -mabi=ilp32d -O1 red.c -freport-bug
red.c: In function 'h':
red.c:15:1: error: unrecognizable insn:
   15 | }
  | ^
(insn 54 53 55 8 (set (reg:SI 192 [ g_lsm.9 ])
(if_then_else:SI (ne:SI (reg:SI 136 [ _9 ])
(const_int 0 [0]))
(reg:SI 136 [ _9 ])
(reg:SI 193))) -1
 (nil))
during RTL pass: vregs
red.c:15:1: internal compiler error: in extract_insn, at recog.cc:2812
0xa2a25d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0xa2a27f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:116
0xa28b53 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0xedeaee instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1611
0xedeaee instantiate_virtual_regs
../../../gcc/gcc/function.cc:1994
0xedeaee execute
../../../gcc/gcc/function.cc:2041
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 /scratch/tmp/ccFI5hsr.out file, please attach
this to your bugreport.

This testcase is a bit simpler since all the logic is in one function. It also
throws an ice with -O1 instead of -O3 that the previous testcase needed.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #6 from Alexandre Oliva  ---
Thanks for the report, sorry about the regressions.  The faulty patch was
reverted, another patch with this and other problems fixed will be pushed
shortly, once testing completes.  I am not, however, taking this PR because
this issue is pretty much resolved, and I understand there's another nvptx
issue with weakundef symbols yet to be resolved, so I'm leaving this PR for
that.

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #7 from Jakub Jelinek  ---
Actually
--- gcc/cp/cp-gimplify.cc.jj2023-12-05 09:06:06.112878408 +0100
+++ gcc/cp/cp-gimplify.cc   2023-12-06 22:32:46.379370223 +0100
@@ -2906,7 +2906,14 @@ cp_fold (tree x, fold_flags_t flags)
 fold_cache = hash_map::create_ggc (101);

   if (tree *cached = fold_cache->get (x))
-return *cached;
+{
+  /* unshare_expr doesn't recurse into SAVE_EXPRs.  If SAVE_EXPR's
+argument has been folded into a tree invariant, make sure it is
+unshared.  See PR112727.  */
+  if (TREE_CODE (x) == SAVE_EXPR && *cached != x)
+   return unshare_expr (*cached);
+  return *cached;
+}

   uid_sensitive_constexpr_evaluation_checker c;

is what it really fixes.

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #5)
> It has been added that way by Marek in
> r8-727-g6b6ae9eb9c06b6911573bb9a13cf98b5a7c98b78

Yet another option would be to keep it, but x = unshare_expr (r);
And perhaps first verify r doesn't have too many subtrees and punt in that
case, so that the unsharing doesn't result in huge IL in pathological cases.

[Bug analyzer/112889] ICE with -fanalyzer seen on Linux kernel drivers/infiniband/hw/cxgb4/cm.c

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06

--- Comment #1 from David Malcolm  ---
Happens for a concrete_binding 2 bits below the start of the base region, due
to:

172   bool ins = Traits::is_empty (*e);
173   if (ins)
174 {
175   e->m_key = k;
176   new ((void *)>m_value) Value (v);
177   gcc_checking_assert (!Traits::is_empty (*e)
178&& !Traits::is_deleted (*e));
179 }

(gdb) call b.dump(true)
start: -2, size: 1, next: -1

(gdb) p k.is_empty()
$6 = true
(gdb) p k.is_deleted()
$7 = false

where concrete_binding has:
  void mark_deleted () { m_bit_range.m_start_bit_offset = -1; }
  void mark_empty () { m_bit_range.m_start_bit_offset = -2; }
  bool is_deleted () const { return m_bit_range.m_start_bit_offset == -1; }
  bool is_empty () const { return m_bit_range.m_start_bit_offset == -2; }

Possibly also affects the "1 bit before the base region" case as well.

Working on a fix to use the size field for the deleted/empty values.

It's a failing assertion, so may well be present (but latent) in older
releases.

[Bug fortran/112873] F2023 degree trig functions

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Dec 06, 2023 at 08:56:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> The patch looks mostly fine, but can you explain why you make some of the
> specific functions generic?  Like:
> 
> +  make_generic ("dacosd", GFC_ISYM_ACOSD, GFC_STD_GNU);
> 
> Because we do not make the ordinary specific dacos generic, only acos.

I'm probably mis-remembering how make_generic() works.  I'll look
at this PR over weekend and fix up the patch.

> Do you also plan to provide a patch for gfortran.texi abd intrinsic.texi?

Whoops.  I forgot about the *.texi files.  I'll update those this
weekend as well.

Thanks for the response.

PS:  I implemented the half-cycle trig functions (e.g., sinpi, ...) for
FreeBSD a few years ago.  These have a 2-clause BSD license.  I'm
willing to dual-license the code with LGPL if you think these might
be good fallback routines.

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #5 from Jakub Jelinek  ---
It has been added that way by Marek in
r8-727-g6b6ae9eb9c06b6911573bb9a13cf98b5a7c98b78

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #4 from Jakub Jelinek  ---
BTW, the reason why cp_save_expr wrapped it into a SAVE_EXPR at first was that
the
COND_EXPR at that point wasn't TREE_READONLY, just non-side-effects and all 3
of its arguments were TREE_READONLY.
Though, obviously if it wouldn't be wrapped in SAVE_EXPR at the beginning, it
would probably work fine, as unshare_expr then would unshare the trees deeper.
Dunno, perhaps instead of
+  r = cp_fold (TREE_OPERAND (x, 0));
+  if (tree_invariant_p (r))
+   x = r;
for SAVE_EXPR we should do nothing, the SAVE_EXPR argument will be folded
during cp_fold_r, and if we decided at some point to use a SAVE_EXPR, we better
gimplify it that way.

Other thoughts?

[Bug libstdc++/112314] Missing index assertions in basic_string_view

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-11127-g4f74f6c7aa0820943ba0777dc41d69a969576e18
Author: Jonathan Wakely 
Date:   Wed Nov 1 15:01:22 2023 +

libstdc++: Add assertion to std::string_view::remove_suffix [PR112314]

libstdc++-v3/ChangeLog:

PR libstdc++/112314
* include/std/string_view (string_view::remove_suffix): Add
debug assertion.
*
testsuite/21_strings/basic_string_view/modifiers/remove_prefix/debug.cc:
New test.
*
testsuite/21_strings/basic_string_view/modifiers/remove_suffix/debug.cc:
New test.

(cherry picked from commit 6afa984f47e16e8bd958646d7407b74e61041f5d)

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #3 from Jakub Jelinek  ---
Actually no, ubsan_handle_shift is called here with
SAVE_EXPR (x)->s[VIEW_CONVERT_EXPR(j)] ? NON_LVALUE_EXPR <1> :
NON_LVALUE_EXPR <0>>
as op0.
And what goes out of it + the whole LSHIFT_EXPR with instrumentation looks
reasonable as well:
if (SAVE_EXPR <16 + VIEW_CONVERT_EXPR(j)>;, SAVE_EXPR (x)->s[VIEW_CONVERT_EXPR(j)] ?
NON_LVALUE_EXPR <1> : NON_LVALUE_EXPR <0>>;, SAVE_EXPR <16 +
VIEW_CONVERT_EXPR(j)> > 31;)
  {
__builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, (unsigned
long) (SAVE_EXPR (x)->s[VIEW_CONVERT_EXPR(j)] ? NON_LVALUE_EXPR <1> :
NON_LVALUE_EXPR <0>>), (unsigned long) (SAVE_EXPR <16 +
VIEW_CONVERT_EXPR(j)>));
  }
else
  {
<<< Unknown tree: void_cst >>>
  }, (SAVE_EXPR (x)->s[VIEW_CONVERT_EXPR(j)] ? NON_LVALUE_EXPR <1> :
NON_LVALUE_EXPR <0>>) << SAVE_EXPR <16 + VIEW_CONVERT_EXPR(j)>;;
i.e. the x->s[j] ? 0 : 1 is evaluated in SAVE_EXPR first, then 16 + j > 31
comparison, etc.

Seems the problem happens during cp_fold, which when called on the
COMPOUND_EXPR with
SAVE_EXPR (x)->s[VIEW_CONVERT_EXPR(j)] ? NON_LVALUE_EXPR <1> :
NON_LVALUE_EXPR <0>>
as first argument and
SAVE_EXPR <16 + VIEW_CONVERT_EXPR(j)> > 31
second recurses using
3113  op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops,
flags);
on the first one and returns
(bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1
(i.e. extracts it out of the SAVE_EXPR).
case SAVE_EXPR:
  /* A SAVE_EXPR might contain e.g. (0 * i) + (0 * j), which, after
 folding, evaluates to an invariant.  In that case no need to wrap
 this folded tree with a SAVE_EXPR.  */
  r = cp_fold (TREE_OPERAND (x, 0), flags);
  if (tree_invariant_p (r))
x = r;
  break;
And then because it thinks it is invariant (the COND_EXPR has for some reason
TREE_READONLY set on it), it also drops it from the COMPOUND_EXPR.
Now, guess there is some tree sharing (while c-ubsan.cc calls unshare_expr when
it uses the expressions multiple times, the unsharing stops at SAVE_EXPR) and
so when the bounds-strict instrumentation modifies it and adds important
side-effect to it, it modifies both remaining copies of the SAVE_EXPR's
argument.

[Bug analyzer/112889] New: ICE with -fanalyzer seen on Linux kernel drivers/infiniband/hw/cxgb4/cm.c

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

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

Bug ID: 112889
   Summary: ICE with -fanalyzer seen on Linux kernel
drivers/infiniband/hw/cxgb4/cm.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

Affects only trunk (for gcc 14): https://godbolt.org/z/Tshdnvshx

typedef unsigned char __u8;
struct sk_buff
{
  unsigned char *data;
};
struct cpl_pass_accept_req
{
  __u8 : 6;
  __u8 sack : 1;
};
void build_cpl_pass_accept_req(struct sk_buff* skb)
{
  struct cpl_pass_accept_req* req;
  skb->data -= sizeof(*req);
  req = (struct cpl_pass_accept_req *)skb->data;
  req->sack = 1;
}

gcc -fanalyzer 

t.c: In function ‘build_cpl_pass_accept_req’:
t.c:16:13: internal compiler error: in put, at hash-map.h:177
   16 |   req->sack = 1;
  |   ~~^~~
0x87eec0 hash_map, ana::svalue
const*> >::put(ana::binding_key const* const&, ana::svalue const* const&)
../../src/gcc/hash-map.h:177
0x87f842 hash_map,
ana::concrete_binding*> >::put(ana::concrete_binding const&,
ana::concrete_binding* const&)
../../src/gcc/analyzer/store.cc:2246
0x87f842 consolidation_map::put(ana::concrete_binding
const&, ana::concrete_binding*)
../../src/gcc/analyzer/analyzer.h:525
0x87f842
ana::store_manager::get_concrete_binding(generic_wide_int
>, generic_wide_int >)
../../src/gcc/analyzer/store.cc:2232
0x14db141 ana::binding_key::make(ana::store_manager*, ana::region const*)
../../src/gcc/analyzer/store.cc:133
0x14ddcd6 ana::binding_cluster::bind(ana::store_manager*, ana::region const*,
ana::svalue const*)
../../src/gcc/analyzer/store.cc:1377
0x14ddcd6 ana::binding_cluster::bind(ana::store_manager*, ana::region const*,
ana::svalue const*)
../../src/gcc/analyzer/store.cc:1365
0x14de76a ana::store::set_value(ana::store_manager*, ana::region const*,
ana::svalue const*, ana::uncertainty_t*)
../../src/gcc/analyzer/store.cc:2617
0x144ceb5 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*,
ana::path_context*)
../../src/gcc/analyzer/engine.cc:1507
0x144f680 ana::exploded_graph::process_node(ana::exploded_node*)
../../src/gcc/analyzer/engine.cc:4123
0x145035a ana::exploded_graph::process_worklist()
../../src/gcc/analyzer/engine.cc:3512
0x1452330 ana::impl_run_checkers(ana::logger*)
../../src/gcc/analyzer/engine.cc:6206
0x14532c6 ana::run_checkers()
../../src/gcc/analyzer/engine.cc:6297
0x14445ec execute
../../src/gcc/analyzer/analyzer-pass.cc:87


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug fortran/112873] F2023 degree trig functions

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The patch looks mostly fine, but can you explain why you make some of the
specific functions generic?  Like:

+  make_generic ("dacosd", GFC_ISYM_ACOSD, GFC_STD_GNU);

Because we do not make the ordinary specific dacos generic, only acos.

Do you also plan to provide a patch for gfortran.texi abd intrinsic.texi?

[Bug c++/112869] [14 Regression] ICE at gimplify_expr, at gimplify.cc:17531 on libopenmpt-0.7.3

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

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

--- Comment #3 from Sergei Trofimovich  ---
I confirm the proposed change fixes build of libopenmpt-0.7.3 as well. Thank
you!

[Bug fortran/105543] Function returning a class array with contiguous attribute rejected

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-December/05.html

[Bug sanitizer/112727] [11/12/13/14 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #2 from Jakub Jelinek  ---
struct S { bool s[8]; };

void
foo (const S *x)
{
  unsigned n = 0;
  for (unsigned j = 0; j < 8; j++)
n |= ((!x->s[j]) ? 1 : 0) << (16 + j);
}

-O2 -fsanitize=shift-exponent,bounds-strict -Wuninitialized
is all that is needed.
Seems the SAVE_EXPR  used in the .UBSAN_BOUNDS call is evaluated separately
both in
the __builtin___ubsan_handle_shift_out_of_bounds argument and then later on
again,
but because the call is conditional and is gimplified first, j is initialized
only in case 16 + j > 31 and uninitialized otherwise.

Now, if I try:
int bar (void);

int
baz (int x)
{
  return bar () << x;
}
we properly evaluate SAVE_EXPR  first, then conditionally in
__builtin___ubsan_handle_shift_out_of_bounds argument and again afterwards.
So I guess the bug is that (x->s[j] ? 0 : 1) isn't considered as having
side-effects
by the shift sanitization.  And we then add the bounds-strict sanitization into
it
which definitely turns it into something with side-effects.

[Bug target/112888] New: [14 Regression] RISCV ICE: in compute_lcm_local_properties, at config/riscv/riscv-vsetvl.cc:2695

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112888
   Summary: [14 Regression] RISCV ICE: in
compute_lcm_local_properties, at
config/riscv/riscv-vsetvl.cc:2695
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56820=edit
-freport-bug output

Testcase:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/c-c%2B%2B-common/goacc/kernels-double-reduction-n.c;h=8f7f415b58d848cf51427c102972e248c1bcb191;hb=c9d5b46a25547035e381b0246de5cb553ca8b02d

Command:
> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv 
> kernels-double-reduction-n.c -fopenacc -O2

during RTL pass: vsetvl
kernels-double-reduction-n.c: In function 'foo._omp_fn.0':
kernels-double-reduction-n.c:18:9: internal compiler error: in
compute_lcm_local_properties, at config/riscv/riscv-vsetvl.cc:2695
   18 | #pragma acc kernels copyin (a[0:n]) copy (sum) /* { dg-message
"optimized: assigned OpenACC gang loop parallelism" } */
  | ^~~
0xac6f4b pre_vsetvl::compute_lcm_local_properties()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2695
0x173b419 pre_vsetvl::earliest_fuse_vsetvl_info()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2884
0x173d5d9 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3531
0x173d93f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3578
0x173d93f pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3561
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.

Looks like the newly added assert is firing:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv-vsetvl.cc;h=68f0be7e81d124dde4537761719c93902992af2f;hb=c9d5b46a25547035e381b0246de5cb553ca8b02d#l2695

[Bug libstdc++/112802] : _ToClosure::operator() has no constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |14.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Patrick Palka  ---
I can fix this as a follow-up.

[Bug tree-optimization/112887] during GIMPLE pass: phiopt ICE: Floating point exception (SIGFPE) at tree-ssa-phiopt.c:2224 with --param=l1-cache-line-size=0x20000000

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

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

--- Comment #1 from Andrew Pinski  ---
param_l1_cache_line_size should most likely limited to a max of 128MB .

[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor

[sberg.fun at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Stephan Bergmann  ---
While the original reproducer from comment 0 appears to be fixed in recent GCC
14 trunk, a slight modification still fails at least with recent GCC 14 trunk:

> $ cat test.cc
> struct S1 {
>   int a;
>   consteval S1(int n): a(n) {}
> };
> struct S2 {
>   S1 x;
>   S2(): x(0) {}
> };

> $ g++ -fsyntax-only -std=c++20 test.cc
> test.cc: In constructor ‘S2::S2()’:
> test.cc:7:11: error: call to consteval function 
> ‘((S2*)this)->S2::x.S1::S1(0)’ is not a constant expression
> 7 | S2(): x(0) {}
>   |   ^~~~
> test.cc:7:11:   in ‘constexpr’ expansion of ‘((S2*)this)->S2::x.S1::S1(0)’
> test.cc:3:26: error: modification of ‘*(S2*)this’ is not a constant expression
> 3 | consteval S1(int n): a(n) {}
>   |  ^~~~

[Bug tree-optimization/112887] New: during GIMPLE pass: phiopt ICE: Floating point exception (SIGFPE) at tree-ssa-phiopt.c:2224 with --param=l1-cache-line-size=0x20000000

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112887
   Summary: during GIMPLE pass: phiopt ICE: Floating point
exception (SIGFPE) at tree-ssa-phiopt.c:2224 with
--param=l1-cache-line-size=0x2000
   Product: gcc
   Version: 14.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 56819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56819=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 --param=l1-cache-line-size=0x2000 testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: Floating point exception
 foo (void)
 ^~~
0xb8d28f crash_signal
/repo/gcc-6-branch/gcc/toplev.c:333
0xd0df7b hoist_adjacent_loads
/repo/gcc-6-branch/gcc/tree-ssa-phiopt.c:2224
0xd0ec46 tree_ssa_phiopt_worker
/repo/gcc-6-branch/gcc/tree-ssa-phiopt.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

There is a division by zero, since param_align_bits == 0:

...
  int param_align = param_l1_cache_line_size;
  unsigned param_align_bits = (unsigned) (param_align * BITS_PER_UNIT);
...

[Bug target/111068] ICE: in extract_insn, at recog.cc:2791 unrecognizable insn with -ffloat-store -mavx10.1-512

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is impossible to bisect.
It ICEd until r14-3430, but r14-3431 removed -mavx10.1-512 support and when it
was readded in r14-5607 it doesn't ICE anymore.
Guess we should add the testcase to the testsuite.

[Bug target/111161] [13 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4394 during build

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed by r14-1621-g7f26e76c9848aeea9ec10ea701a6168464a4a9c2
and r13-7766-gb81d476756a1f17617f0837761785c4b5d1d195d

[Bug target/111939] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*vec_extractv2di_1} with -Ofast -mapxf -mabi=ms -mavxifma -mno-avx

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This has been fixed by r14-5242-gca281a7b97163273de9d73da556fb3f6dcc3b61b
already.

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

[Bug target/112394] ICE: in extract_constrain_insn, at recog.cc:2705 insn does not satisfy its constraints: {*vec_extractv2di_1} with -O -mavx512vbmi2 -mapxf -mno-sse4.2

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

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

--- Comment #4 from Jakub Jelinek  ---
*** Bug 111939 has been marked as a duplicate of this bug. ***

[Bug target/108032] internal compiler error : in final_scan_insn_1, at final.c:3079

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Closing.

[Bug target/112851] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick O'Neill  ---
Fixed. Thank you!

[Bug testsuite/109146] Tail call prevention in frame-address.c is not correct

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
noipa was added in r14-5628-g53ba8d669550d3 to avoid the IPA VRP return.

So fixed from GCC's point of view.  Yes noipa is not implemented in clang/LLVM
but the testcase is a GCC testcase after all.

[Bug target/112852] [14 Regression] RISCV ICE: vsetvl pass: in partial_subreg_p, at rtl.h:3187 on rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick O'Neill  ---
Fixed. Thank you!

[Bug testsuite/109147] Missing IPA-VRP for return values

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

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

Bug 109146 Summary: Tail call prevention in frame-address.c is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109146

   What|Removed |Added

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

[Bug ipa/81323] IPA-VRP doesn't handle return values

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed with r14-5628-g53ba8d669550d3 .

[Bug middle-end/112854] [14] RISCV ICE: expand: in store_integral_bit_field, at expmed.cc:1049 on rv32gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick O'Neill  ---
Fixed. Thank you!

[Bug middle-end/112872] [14 Regression] RISCV ICE: in store_integral_bit_field, at expmed.cc:1049 with -03 rv64gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick O'Neill  ---
Fixed. Thank you!

[Bug target/112855] [14] RISC-V vector: vsetivli clobbers variable value

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick O'Neill  ---
Confirmed to be fixed. Thank you!

[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu

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

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

--- Comment #9 from Jakub Jelinek  ---
If we wanted to support just INSN_UIDs up to 0x5554, it could be even just
  lra_insn_recog_data_len = index * 3U / 2 + 1;

Looking around, vec.cc has similar limitation, it uses unsigned rather than int
alloc,
and
...
/* Grow slower when large.  */
alloc = (alloc * 3 / 2);

  /* If this is still too small, set it to the right size. */
  if (alloc < desired)
alloc = desired;
So, my understanding is for vectors up to 0x elements it will do the
expected thing, for larger it will simply reallocate to the desired exact value
(i.e. as if it was an exact growth rather than the normal exponential one).
Perhaps what we could do in both places use
alloc = (alloc * (size_t) 3 / 2);
plus the if (alloc < desired) alloc = desired;, such that at least on 64-bit
hosts we'd use an exponential growth even after 0x a little bit, but on
32-bit hosts we'd keep what we do.  On the lra side then
  lra_insn_recog_data_len = index * (size_t) 3 / 2;
  if (lra_insn_recog_data_len <= index)
lra_insn_recog_data_len = index + 1;

[Bug tree-optimization/112884] Missing optimization: fold a%2==0 ? a/2*2 : 0 to a%2==0 ? a : 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06
   Severity|normal  |enhancement
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

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

VRP does have the information:
=== BB 3 
a_3(D)  [irange] unsigned int [0, 0][2, 4294967294] MASK 0xfffe VALUE 0x0
 :
iftmp.0_5 = a_3(D) & 4294967294;


But it does not do the folding ...

[Bug rtl-optimization/40209] stale REG_UNUSED note vs single_set

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||internal-improvement,
   ||wrong-code
   Last reconfirmed||2023-12-06
Summary|ICE in iv_analyze_def   |stale REG_UNUSED note vs
   |caused by stale REG_UNUSED  |single_set
   |note|
 Ever confirmed|0   |1

--- Comment #10 from Andrew Pinski  ---
.

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Andrew Pinski  ---
The REG_UNUSED vs single_set issue is being tracked in PR 40209 .

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

[Bug target/112886] New: We need a new print_operand output modifier for vector double

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

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

Bug ID: 112886
   Summary: We need a new print_operand output modifier for vector
double
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I've been working with vector double support to provide faster memory latency
for specialized applications.  While the work I've been doing might not make it
in GCC 14, I've been looking at what is needed to provide usable asm support
for using vector pairs.

The problem is we have %x for VSX registers that maps the traditional FPR
registers into 0..31 and the traditional Altivec registers into 32..63.  We
have %L that returns the 2nd register in a multiple register object. 
However, we don't have a combination of %x and %L, where for VSX
registers it would return the 2nd register in the vector pair as a VSX register
number.

For example, if you wanted to write a loop where you use vector pairs to load
the values and then manually process each vector, you might want to write using
%S to access the 2nd vector register:

__vector_pair *p, sum;
size_t i, n;
// ...
__asm__ ("xxspltib %x0,0\nxxspltib %S0,0" : "=wa" (sum));
for (i = 0; i < n; i++)
__asm__ ("xvadddp %x0,%x1,%x2\n\txvadddp %S0,%S1,%S2"
 : "=wa" (sum)
 : "wa" (sum), "wa" (p[i]));

However without this new print_operand output modifier, you would have to use
either "d" or "f" to limit the registers to the traditional FPR registers. 
I.e.:

__vector_pair *p, sum;
size_t i, n;
// ...
__asm__ ("xxspltib %0,0\nxxspltib %L0,0" : "=f" (sum));
for (i = 0; i < n; i++)
__asm__ ("xvadddp %0,%1,%2\n\txvadddp %L0,%L1,%L2"
 : "=f" (sum)
 : "f" (sum), "f" (p[i]));

If you do this, you limit the number of vector pairs that can be used to 16
instead of 32.  Generally you would want to use this in performance critical
code, and often there you are using all of the registers.

You can't just modify %L to deal with VSX registers, because the user might
be using an instruction that only accesses Altivec registers, i.e.:

__vector_pair *p, sum;
size_t i, n;
// ...
__asm__ ("vspltisw %0,0\nvspltisw %L0,0" : "=v" (sum));
for (i = 0; i < n; i++)
__asm__ ("vadduqm %0,%1,%2\n\tvadduqm %L0,%L1,%L2"
 : "=v" (sum)
 : "v" (sum), "v" (p[i]));

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

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

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #34 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #33)
> This should be now hopefully latent after
> r14-6210-ge44ed92dbbe9d4e5c23f486cd2f77a6f9ee513c5, we need to decide about
> the updating and usability of REG_UNUSED notes, but after moving the pass it
> shouldn't trigger on this testcase.

Which case this becomes a dup of bug 40209 which is tracking the single_set
usage issue (and has for a long time).

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

[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Note, on
void
foo (void)
{
}
./cc1 -quiet --param min-nondebug-insn-uid=0x2000 pr112411.c
still works but is fairly slow (various passes index arrays by INSN_UID and if
the uids are huge, it takes a lot of memory and compile time to clear them).
But
./cc1 -quiet --param min-nondebug-insn-uid=0x2aaa a.c

cc1: out of memory allocating 18446744065119617112 bytes after a total of
1626112 bytes
Seems lra does some vec handling by hand and uses an int variable for it:
lra.cc (check_and_expand_insn_recog_data):
  lra_insn_recog_data_len = index * 3 / 2 + 1;
Shall we change lra_insn_recog_data_len to size_t (and tweak comparisons to
avoid signed vs. unsigned compares)?
Or at least adjust the above such that the computation is say done in unsigned
HOST_WIDE_INT and use INT_MAX for lra_insn_recog_data_len on overflow rather
than negative value (including UB at compile time)?

With the following patch it compiles even with
./cc1 -quiet --param min-nondebug-insn-uid=0x4000 a.c
but my 32GB RAM + 24GB swap was almost full with that.

--- gcc/params.opt.jj   2023-11-02 07:49:18.010852541 +0100
+++ gcc/params.opt  2023-12-06 18:55:57.045420935 +0100
@@ -779,7 +779,7 @@ Common Joined UInteger Var(param_min_loo
 The minimum threshold for probability of semi-invariant condition statement to
trigger loop split.

 -param=min-nondebug-insn-uid=
-Common Joined UInteger Var(param_min_nondebug_insn_uid) Param
+Common Joined UInteger Var(param_min_nondebug_insn_uid) Param IntegerRange(0,
1073741824)
 The minimum UID to be used for a nondebug insn.

 -param=min-size-for-stack-sharing=
--- gcc/lra.cc.jj   2023-12-05 13:17:29.642260866 +0100
+++ gcc/lra.cc  2023-12-06 19:14:52.117499420 +0100
@@ -764,11 +764,13 @@ static void
 check_and_expand_insn_recog_data (int index)
 {
   int i, old;
+  HOST_WIDE_INT len;

   if (lra_insn_recog_data_len > index)
 return;
   old = lra_insn_recog_data_len;
-  lra_insn_recog_data_len = index * 3 / 2 + 1;
+  len = index * HOST_WIDE_INT_C (3) / 2 + 1;
+  lra_insn_recog_data_len = MIN (len, INT_MAX);
   lra_insn_recog_data = XRESIZEVEC (lra_insn_recog_data_t,
lra_insn_recog_data,
lra_insn_recog_data_len);

[Bug tree-optimization/112885] FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: Segmentation fault )

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect this is already fixed with  r14-6132 (aka PR 112848 ).

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

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

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

--- Comment #21 from Michael Matz  ---
(In reply to Jan Hubicka from comment #20)
> > 
> > Live patching (user-space) doesn't depend on any particular alignment of
> > functions, on x86-64 at least.  (The plan for other architectures wouldn't 
> > need
> > any specific alignment either).  Note that the above complaints about 
> > missing
> > alignment is for kernel (!) ftrace/livepatching on arm64 (!), not on x86_64.
> 
> I had impression that x86-64 also needs forced alignment so the patching
> can be always done atomically.  But it is not a big practical difference
> if we go with a flag specifying minimal function alignment.

Not for userspace live patching (it's done while the process is stopped).
kernel live patching may or may not need it.  Point being that alignment
shouldn't be implied by the live patching options as its orthogonal.

[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I'm using this param all the time, but typically with low values (like 1000 or
1 depending on how large a problematic function is).
I guess enforcing a range to be [1, INT_MAX / 2] or so wouldn't hurt anything
and the likelyhood of overflow in that case is low (and likelyhood of needing
more than INT_MAX / 2 debug insns in one function is also low).

[Bug tree-optimization/112885] New: FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: Segmentation fault )

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

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

Bug ID: 112885
   Summary: FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler
error: Segmentation fault )
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56818=edit
Preprocessed source

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/  /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c   
-f
diagnostics-plain-output   -O2 -fno-tree-pre -fno-tree-dominator-opts
-fdump-tre
e-sink -fdump-tree-optimized -S -o ssa-sink-16.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c
-fdi
agnostics-plain-output -O2 -fno-tree-pre -fno-tree-dominator-opts
-fdump-tree-si
nk -fdump-tree-optimized -S -o ssa-sink-16.s
during GIMPLE pass: cddce
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c: In function
'f':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c:5:5:
internal
 compiler error: Segmentation fault
0x8b656f crash_signal
../../gcc/gcc/toplev.cc:316
0xa26a4c find_uses_to_rename_use
../../gcc/gcc/tree-ssa-loop-manip.cc:424
0xa26c03 find_uses_to_rename_use
../../gcc/gcc/tree-ssa-loop-manip.cc:414
0xa26c03 find_uses_to_rename_stmt
../../gcc/gcc/tree-ssa-loop-manip.cc:464
0xa26c03 find_uses_to_rename_bb
../../gcc/gcc/tree-ssa-loop-manip.cc:495
0xa27683 find_uses_to_rename
../../gcc/gcc/tree-ssa-loop-manip.cc:521
0xa27683 rewrite_into_loop_closed_ssa_1
../../gcc/gcc/tree-ssa-loop-manip.cc:588
0xa27683 rewrite_into_loop_closed_ssa(bitmap_head*, unsigned int)
../../gcc/gcc/tree-ssa-loop-manip.cc:628
0x9075e7 repair_loop_structures
../../gcc/gcc/tree-cfgcleanup.cc:1190
0x9075e7 cleanup_tree_cfg(unsigned int)
../../gcc/gcc/tree-cfgcleanup.cc:1209
0x78089b execute_function_todo
../../gcc/gcc/passes.cc:2057
0x780ebb do_per_function
../../gcc/gcc/passes.cc:1687
0x78103f execute_todo
../../gcc/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/gcc/cc1 -fpreprocessed
ssa-sink-16.i -quiet -dumpbase ssa-sink-16.c -dumpbase-ext .c -O2 -version
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none
-fno-tree-pre -fno-tree-dominator-opts -fdump-tree-sink -fdump-tree-optimized
-o ssa-sink-16.s
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
GNU C17 (GCC) version 14.0.0 20231204 (experimental) [master
r14-6126-g886f256ce3b] (hppa-linux-gnu)
compiled by GNU C version 14.0.0 20231204 (experimental) [master
r14-6126-g886f256ce3b], GMP version 6.3.0, MPFR version 4.2.1, MPC version
1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 04c59775674c2a8fe5fa9ca70cc96db0

Program received signal SIGSEGV, Segmentation fault.
find_uses_to_rename_use (bb=0xfabdc070, use_blocks=0x191d580,
need_phis=, use=)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:424
424   if (!loop_outer (def_loop))
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0xa26a3c to 0xa26a5c:
   0x00a26a3c :ldw 10(r24),ret0
   0x00a26a40 :cmpib,= 0,ret0,0xa26aa0 
   0x00a26a44 :copy r25,r3
   0x00a26a48 :ldw c(ret0),r26
=> 0x00a26a4c :ldw 20(r26),ret0
   0x00a26a50 :cmpib,=,n 0,ret0,0xa26aa0 
   0x00a26a54 :ldw 4(ret0),r19
   0x00a26a58 :cmpib,= 0,r19,0xa26aa0 
End of assembler dump.
(gdb) p/x $r26
$1 = 0x0
(gdb) bt
#0  find_uses_to_rename_use (bb=0xfabdc070, use_blocks=0x191d580,
need_phis=, use=)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:424
#1  0x00a26c04 in find_uses_to_rename_use (need_phis=0x19bacc0,
use_blocks=0x191d580, use=, bb=0xfabdc070)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:414
#2  find_uses_to_rename_stmt (use_flags=5, need_phis=0x19bacc0,
use_blocks=0x191d580, stmt=0xfabdc070)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:464
#3  find_uses_to_rename_bb (bb=, use_blocks=0x191d580,
need_phis=0x19bacc0, use_flags=5)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:495
#4  0x00a27684 in find_uses_to_rename (use_flags=5, need_phis=0x191d580,
use_blocks=0x191d580, changed_bbs=)
at ../../gcc/gcc/tree-ssa-loop-manip.cc:521
#5  rewrite_into_loop_closed_ssa_1 (use_flags=5, update_flag=,
changed_bbs=) at 

[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode

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

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

--- Comment #3 from Jonathan Wakely  ---
This minimal fix is enough to remove the reference to __glibcxx_assert_fail
when optimization is enabled (at any level):

--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -598,7 +598,7 @@ namespace std

 # define __glibcxx_assert(cond)   
\
   do { \
-if _GLIBCXX17_CONSTEXPR (_GLIBCXX_DO_ASSERT)   \
+if (_GLIBCXX_DO_ASSERT)\
   if (__builtin_expect(!bool(cond), false))   
\
_GLIBCXX_ASSERT_FAIL(cond); \
   } while (false)

But we still need the more complete fix for -O0.

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #20 from Jan Hubicka  ---
> 
> Live patching (user-space) doesn't depend on any particular alignment of
> functions, on x86-64 at least.  (The plan for other architectures wouldn't 
> need
> any specific alignment either).  Note that the above complaints about missing
> alignment is for kernel (!) ftrace/livepatching on arm64 (!), not on x86_64.

I had impression that x86-64 also needs forced alignment so the patching
can be always done atomically.  But it is not a big practical difference
if we go with a flag specifying minimal function alignment.

[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode

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

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

--- Comment #2 from Jonathan Wakely  ---
That change was broken anyway: when _GLIBCXX_ASSERTIONS was not defined, the
condition in the assertion is if constexpr (is_constant_evaluated()) which is
always true, even when not actually doing constant eval.

I'll test this:

--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -538,6 +538,7 @@ namespace std
   // This can be used without checking if the compiler supports the feature.
   // The macro _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED can be used to check if
   // the compiler support is present to make this function work as expected.
+  __attribute__((__always_inline__))
   _GLIBCXX_CONSTEXPR inline bool
   __is_constant_evaluated() _GLIBCXX_NOEXCEPT
   {
@@ -589,19 +590,28 @@ namespace std
 #endif

 #if defined(_GLIBCXX_ASSERTIONS)
-# define _GLIBCXX_DO_ASSERT true
-#elif _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED
-# define _GLIBCXX_DO_ASSERT std::__is_constant_evaluated()
-#else
-# define _GLIBCXX_DO_ASSERT false
-#endif
-
 # define __glibcxx_assert(cond)   
\
   do { \
-if _GLIBCXX17_CONSTEXPR (_GLIBCXX_DO_ASSERT)   \
-  if (__builtin_expect(!bool(cond), false))   
\
-   _GLIBCXX_ASSERT_FAIL(cond); \
+if (__builtin_expect(!bool(cond), false))  \
+  _GLIBCXX_ASSERT_FAIL(cond);  \
   } while (false)
+#elif _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED
+namespace std
+{
+  __attribute__((__always_inline__,visibility("default")))
+  inline void
+  __glibcxx_compile_time_assert_fail()
+  { }
+}
+# define __glibcxx_assert(cond)   
\
+  do { \
+if (std::__is_constant_evaluated())   
\
+  if (__builtin_expect(!bool(cond), false))   
\
+   __glibcxx_compile_time_assert_fail();   \
+  } while (false)
+#else
+# define __glibcxx_assert(cond)
+#endif

 // Macro indicating that TSAN is in use.
 #if __SANITIZE_THREAD__

[Bug preprocessor/111965] -fno-debug-cpp does not disable -fdebug-cpp

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 56817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56817=edit
gcc14-pr111965.patch

Full lightly tested patch.

[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug target/112445] [14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1861 unable to find a register to spill: {*umulditi3_1} with -O -march=cascadelake -fwrapv since r14-4968-g89e5d90

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Thanks for the fix.

[Bug tree-optimization/112884] New: Missing optimization: fold a%2==0 ? a/2*2 : 0 to a%2==0 ? a : 0

[xxs_chy at outlook dot com via Gcc-bugs]

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

Bug ID: 112884
   Summary: Missing optimization: fold a%2==0 ? a/2*2 : 0 to
a%2==0 ? a : 0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xxs_chy at outlook dot com
  Target Milestone: ---

Godbolt example: https://godbolt.org/z/Ec1ax79r8

For the select arm "a / 2 * 2" in:

unsigned src(unsigned a) {
return a % 2 == 0 ? (a / 2 * 2) : 0;
}

it's equivalent to "a", so the program could be folded to:

unsigned tgt(unsigned a) {
return a % 2 == 0 ? a : 0;
}

Both GCC and LLVM missed such optimization in select arms.

[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-06
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
(In reply to Tamar Christina from comment #0)
> I know this is not a supported scenario, but I'm wondering if it's still
> easy to support.
> 
> We have some libraries that use C++ mostly as an abstraction layer and try
> to ensure that it needs no runtime support from libstdc++.
> 
> A recent commit: g:5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 changed how
> `__glibcxx_assert` is defined and now always calls
> `std::__glibcxx_assert_fail`.
> 
> This means that now you always need libstdc++ even in contex where things
> would have been folded away before.  Similarly we're getting the same thing
> through usage of `std::unique_ptr`.

Ugh, that's undesirable. It should only depend on that symbol when
_GLIBCXX_ASSERTIONS is defined, but the change means we also use that symbol
for constexpr checks.

I'm surprised it doesn't get folded away though, since the code looks like:

  if (std::__is_constant_evaluated())
if (__builtin_expect(COND, false))
  __glibcxx_assert_fail(...);

Since __is_constant_evaluated is always false at runtime, that function can
never be called. Either it's needed during compile-time and makes the program
ill-formed, or it's not needed at all.

Ah, __is_constant_evaluated() is not marked always_inline, so at -O0 it just
looks like a normal function call.

> It seems that undefining `_GLIBCXX_VERBOSE_ASSERT` gets it to go to
> `__builtin_abort()` which makes it work again.
> 
> If this change was intentional, would it be possible to make
> `_GLIBCXX_VERBOSE_ASSERT` user configurable?

You can use --disable-libstdcxx-verbose for that, or do you need to control it
during preprocessing?

[Bug middle-end/112881] ICE: in count_type_elements, at expr.cc:7034 when initializing struct with a _BitInt(64) member

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 56816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56816=edit
gcc14-pr112881.patch

Untested fix.

Zdenek, thanks for all your work on these bugreports, it is very much
appreciated.

[Bug libstdc++/112314] Missing index assertions in basic_string_view

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-10029-gc5c57aa7e63da2e769f4fda6e2ec9e8bd0c7b344
Author: Jonathan Wakely 
Date:   Wed Nov 1 15:01:22 2023 +

libstdc++: Add assertion to std::string_view::remove_suffix [PR112314]

libstdc++-v3/ChangeLog:

PR libstdc++/112314
* include/std/string_view (string_view::remove_suffix): Add
debug assertion.
*
testsuite/21_strings/basic_string_view/modifiers/remove_prefix/debug.cc:
New test.
*
testsuite/21_strings/basic_string_view/modifiers/remove_suffix/debug.cc:
New test.

(cherry picked from commit 6afa984f47e16e8bd958646d7407b74e61041f5d)

[Bug tree-optimization/112880] ICE: in smallest_mode_for_size, at stor-layout.cc:356 with __builtin_mul_overflow() of _BitInt(1024)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 56815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56815=edit
gcc14-pr112880.patch

Untested fix.

[Bug c++/112883] New: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)

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

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

Bug ID: 112883
   Summary: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b
(test for excess errors)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

On hppa-unknown-linux-gnu:

FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'

Similar fails:
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)

See PR98531.

[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

--- Comment #20 from John David Anglin  ---
The fails have changed on hppa with gcc-14 trunk:

FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'


FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'


FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19:
error: invalid use of non-static data member
'std::basic_format_args,
wchar_t> >::__as_base ::'

FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr1 =
decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr2 =
decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(),
(declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'template class
_Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr3 =
decltype (_Cont<...auto...>(declval >(),
declval >(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr1 = decltype
(_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr2 = decltype
(_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error:
conflicting global module declaration 'using
std::ranges::__detail::_DeduceExpr3 = decltype
(_Cont<...auto...>(declval >(),
declval >(), (declval<_Args>)()...))'

The latter fail looks like PR112737.

[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org
 Target|cris-elf|cris-elf
   ||hppa-unknown-linux-gnu

--- Comment #2 from John David Anglin  ---
Same errors occur on hppa-linux-gnu.

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

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

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

--- Comment #4 from Tobias Burnus  ---
There are *two* independent issues:

(A) Predefined firstprivate does not find mappings done in the same
directive, e.g.

  int a[100];
  int *p = [0];
  #pragma omp target teams distribute map(a)
p[0] = 5;


(B) The base pointer is not stored, hence, the following fails:

  int a[100];
  int *p = [0];
  //   #pragma omp target enter data map(a[10:])  /* same result */
  #pragma omp target teams distribute map(a[10:])
p[15] = 5;

Here,
   map(a[10:])  /* or: map(a[start:n])  */
gives:
   map(tofrom:a[start] [len: _7])
  map(firstprivate:a [pointer assign, bias: D.2943])

But then the basepointer is gone. Thus, any later lookup of an address that
falls between basepointer and first mapped storage location is not found.

[Bug libstdc++/112882] New: [14 Regression] std::clamp no longer usable in header only mode

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

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

Bug ID: 112882
   Summary: [14 Regression] std::clamp no longer usable in header
only mode
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

I know this is not a supported scenario, but I'm wondering if it's still easy
to support.

We have some libraries that use C++ mostly as an abstraction layer and try to
ensure that it needs no runtime support from libstdc++.

A recent commit: g:5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 changed how
`__glibcxx_assert` is defined and now always calls
`std::__glibcxx_assert_fail`.

This means that now you always need libstdc++ even in contex where things would
have been folded away before.  Similarly we're getting the same thing through
usage of `std::unique_ptr`.

It seems that undefining `_GLIBCXX_VERBOSE_ASSERT` gets it to go to
`__builtin_abort()` which makes it work again.

If this change was intentional, would it be possible to make
`_GLIBCXX_VERBOSE_ASSERT` user configurable?

[Bug libstdc++/112477] Assignment of value-initialized iterators differs from value-initialization

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
I agree this should work.

[Bug libstdc++/112480] optional::reset emits inefficient code when T is trivially-destructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed for 13.3, thanks for the report and analysis of the codegen.

[Bug libstdc++/111948] subrange modifies a const size object

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed for 13.3, thanks for the report.

[Bug libstdc++/112832] [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 13.3, thanks for the report.

[Bug libstdc++/110133] System error message should ideally use strerror_r over strerror

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 13.3, I don't think I'll backport it further.