[Bug c++/70690] [6/7 Regression] r235002 miscompiles tcmalloc

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r12-5254-gbd95d75f3412e1a7debab7c6c602ba409f274eb5
Author: Jason Merrill 
Date:   Thu Nov 11 22:03:53 2021 -0500

c++: c++20 constexpr default ctor and array init

The implicit constexpr patch revealed that marking the constructor in the
PR70690 testcase as constexpr made the bug reappear, because build_vec_init
assumed that a constexpr default constructor initialized the whole object,
so it was equivalent to value-initialization.  But this is no longer true
in
C++20.

PR c++/70690

gcc/cp/ChangeLog:

* init.c (build_vec_init): Check default_init_uninitialized_part in
C++20.

gcc/testsuite/ChangeLog:

* g++.dg/init/array41a.C: New test.

[Bug c++/95117] Segmentation fault with static await_ready() or await_resume()

[oficsu at gmail dot com via Gcc-bugs]

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

Ofee Oficsu  changed:

   What|Removed |Added

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

--- Comment #1 from Ofee Oficsu  ---
There's no ICE since GCC 10.2

[Bug c/66918] Disable "inline function declared but never defined" warning

[oficsu at gmail dot com via Gcc-bugs]

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

Ofee Oficsu  changed:

   What|Removed |Added

 CC||oficsu at gmail dot com

--- Comment #11 from Ofee Oficsu  ---
There's another example. A bit suspicious as it's related to loopholes, but GCC
produces too many warning on my example and there's no way to suppress them:
https://godbolt.org/z/PbnM8cfc1

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Hongtao.liu  ---
unsigned long pscc_a_2_3;
int pscc_a_1_4;
unsigned long pc2;
void pscc(int n)
{
  long mask = 1ll << n;
  pc2 = __sync_fetch_and_or(_a_2_3, mask) & mask;
}

void pscc1(int n)
{
  long mask = 1ll << 65;
  pc2 = __sync_fetch_and_or(_a_2_3, mask) & mask;
}

pscc and pscc1 have different behavior when n >= 64, It seems unsafe to
optimize variable mask?

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #6)
> Created attachment 51785 [details]
> The v2 incomplete patch
> 
> Hongtao, please finish it.  Thanks.

Yes.

[Bug debug/103241] New: Odd 0 length entries in location lists

[wcohen at redhat dot com via Gcc-bugs]

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

Bug ID: 103241
   Summary: Odd 0 length entries in location lists
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcohen at redhat dot com
  Target Milestone: ---

I wrote a dwgrep (https://pmachata.github.io/dwgrep/) script to examine the
location lists of function parameters of the kernel and print out each function
and parameter that had zero length entries in the location lists:

  dwgrep /usr/lib/debug/lib/modules/5.14.15-200.fc34.x86_64/vmlinux -e '
let A := entry (?TAG_subprogram) (?AT_ranges || ?AT_low_pc);
let FSTART := (A ?AT_ranges @AT_ranges low) || ( A low);
let PARM := A child ?TAG_formal_parameter;
(PARM ?AT_location @AT_location address length==0) ([A name, FSTART, PARM
name])' | grep \\[ | more

Some of the functions in the kernel that were flagged may have been confused by
the constant propagation, irsa, or partial inlining optimization.  However,
There were some functions parameters that included entries with 0 length
entries in the location list for the parameter.  Focusing on one function,
static_protections:

["static_protections", 0x8107a540, "prot"]
["static_protections", 0x8107a540, "start"]
["static_protections", 0x8107a540, "pfn"]
["static_protections", 0x8107a540, "npg"]
["static_protections", 0x8107a540, "warnlvl"]


Using The following to look at the section of the debuginfo associated with the
function:

llvm-dwarfdump -c --name="static_protection"
/usr/lib/debug/lib/modules/5.14.15-200.fc34.x86_64/vmlinux | more

See the following for static_protection where first entry for "prot" parameter
is 0 length and overlaps the next entry:

0x00e44d5c:   DW_TAG_formal_parameter
DW_AT_abstract_origin   (0x00e3fb6d "prot")
DW_AT_location  (0x002c83db: 
   [0x8107a540, 0x8107a540): DW_OP_reg5 RDI
   [0x8107a540, 0x8107a569): DW_OP_reg5 RDI,
DW_OP_piece 0x8
   [0x8107a5a0, 0x8107a5f3): DW_OP_reg5 RDI
   [0x8107a617, 0x8107a65b): DW_OP_reg3 RBX
   [0x8107a66a, 0x8107a67e): DW_OP_reg3 RBX,
DW_OP_piece 0x8
   [0x8107a67e, 0x8107a68c): DW_OP_reg5 RDI
   [0x8107a68c, 0x8107a6a1): DW_OP_reg3 RBX,
DW_OP_piece 0x8
   [0x8107a6a1, 0x8107a6a1): DW_OP_reg3 RBX,
DW_OP_piece 0x8
   [0x8107a6a1, 0x8107a6cb): DW_OP_reg3 RBX
   [0x8107a6cb, 0x8107a6cb): DW_OP_reg3 RBX,
DW_OP_piece 0x8
   [0x81bc6967, 0x81bc6994): DW_OP_reg3 RBX,
DW_OP_piece 0x8
   [0x81bc69b5, 0x81bc6a24): DW_OP_reg3 RBX,
DW_OP_piece 0x8)
DW_AT_unknown_2137  (0x002c83c3)

0x00e44d69:   DW_TAG_formal_parameter
DW_AT_abstract_origin   (0x00e3fb7a "start")
DW_AT_location  (0x002c84ed: 
   [0x8107a540, 0x8107a5a0): DW_OP_reg4 RSI
   [0x8107a5a0, 0x8107a65b): DW_OP_reg12 R12
   [0x8107a65b, 0x8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg4 RSI), DW_OP_s
tack_value
   [0x8107a66a, 0x8107a68c): DW_OP_reg4 RSI
   [0x8107a68c, 0x8107a6cb): DW_OP_reg12 R12
   [0x8107a6cb, 0x8107a6cb): DW_OP_reg4 RSI
   [0x81bc6967, 0x81bc698c): DW_OP_reg4 RSI
   [0x81bc698c, 0x81bc6a24): DW_OP_reg12 R12)
DW_AT_unknown_2137  (0x002c84dd)

0x00e44d76:   DW_TAG_formal_parameter
DW_AT_abstract_origin   (0x00e3fb87 "pfn")
DW_AT_location  (0x002c85a8: 
   [0x8107a540, 0x8107a5a0): DW_OP_reg1 RDX
   [0x8107a5a0, 0x8107a65b): DW_OP_reg15 R15
   [0x8107a65b, 0x8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg1 RDX), DW_OP_s
tack_value
   [0x8107a66a, 0x8107a68c): DW_OP_reg1 RDX
   [0x8107a68c, 0x8107a6cb): DW_OP_reg15 R15
   [0x8107a6cb, 0x8107a6cb): DW_OP_reg1 RDX
   [0x81bc6967, 0x81bc6983): DW_OP_reg1 RDX
   [0x81bc6983, 0x81bc6a24): DW_OP_reg15 R15)
DW_AT_unknown_2137  (0x002c8598)

0x00e44d83:   DW_TAG_formal_parameter
DW_AT_abstract_origin   (0x00e3fb94 "npg")
DW_AT_location  (0x002c8663: 
   

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #5 from James Y Knight  ---
The originally-reported program still appears to exhibit the issue.

Just looking at the unwind code -- and without attempting to test anything --
it appears that the solution may be as simple as inserting two lines:
  if (found_type == found_terminate)
return _URC_FATAL_PHASE1_ERROR;

at line 651 of eh_personality.cc
(https://github.com/gcc-mirror/gcc/blob/b85a03ae11b157d60ddf93b71632efe0bde3bafd/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L651)

I believe that would abort the search phase (similarly to what happens if you
run out of unwind frames before finding any catch handler) and cause
_Unwind_RaiseException to return _URC_FATAL_PHASE1_ERROR, which then causes
_cxa_throw to call terminate().

[Bug middle-end/54571] Missed optimization converting between bit sets

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 Depends on||103216

--- Comment #4 from Andrew Pinski  ---
This is fixed mostly by the patch which fixes PR 103216.
We still have stuff like:
  _1 = x_3(D) & 1;
  _7 = _1 != 0;
  _8 = (int) _7;
  _9 = y_4(D) | _8;

and:
  _1 = x_3(D) & 2;
  _7 = _1 != 0;
  _8 = (int) _7;
  _9 = y_4(D) | _8;

and
   _1 = x_3(D) & 2;
  _7 = _1 != 0;
  _8 = (int) _7;
  _9 = _8 << 1;
  _10 = y_4(D) | _9;

Which we produce things like:
xorl%eax, %eax
andl$2, %edi
sete%al
orl %esi, %eax

Where the sete/xor could be reproduced with shift for an example.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103216
[Bug 103216] missed optimization, phiopt/vrp?

[Bug tree-optimization/97711] Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Mine, the patch which fixes PR 103216 fixes this too.
> 
> Note it does not fix it fully on the gimple level, we are left with:
>   _1 = x_3(D) & 1;
>   _7 = _1 != 0;
>   _6 = (int) _7;
>   _9 = x_3(D) - _6;

So this is optimized because VRP is able to figure out _1 has a range of [0,1]
a and then able to change _1 != 0 to (bool) _1.
That will be for GCC 13 to fix this fully on the gimple level.

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/97711] Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Mine, the patch which fixes PR 103216 fixes this too.

Note it does not fix it fullly on the gimple level, we are left with:
  _1 = x_3(D) & 1;
  _7 = _1 != 0;
  _6 = (int) _7;
  _9 = x_3(D) - _6;


But the RTL level does optimize it to:
movl%edi, %eax
andl$-2, %eax

[Bug tree-optimization/97711] Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Depends on||103216
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
Mine, the patch which fixes PR 103216 fixes this too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103216
[Bug 103216] missed optimization, phiopt/vrp?

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-15
 Ever confirmed|0   |1

[Bug libstdc++/103240] New: std::type_info::before gives wrong answer for ARM EABI

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

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

Bug ID: 103240
   Summary: std::type_info::before gives wrong answer for ARM EABI
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: arm*-*-*gnueabi

This passes on x86_64 but fails on armv7hl:

// f1.C
#include 

namespace
{
  struct S { };
}

std::type_info const& t1 = typeid(S);

// f2.C
#include 
#include 

extern std::type_info const& t1;

namespace
{
  struct S { };
}

std::type_info const& t2 = typeid(S);

int main()
{
  if (t1 == t2)
  {
assert( !t1.before(t2) );
assert( !t2.before(t1) );
  }
  else
  {
assert( t1.before(t2) || t2.before(t1) );
  }
}

$ g++ f1.C f2.C
$ ./a.out
a.out: f2.C:22: int main(): Assertion `t1.before(t2) || t2.before(t1)' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)

The problem is in libsupc++/tinfo2.cc

bool
type_info::before (const type_info ) const _GLIBCXX_NOEXCEPT
{
#if __GXX_MERGED_TYPEINFO_NAMES
  return name () < arg.name ();
#else
  return (name ()[0] == '*') ? name () < arg.name ()
:  __builtin_strcmp (name (), arg.name ()) < 0;
#endif
}

This should have been fixed like operator== was in r179236 so that it checks
__name[0] not name()[0], otherwise the '*' is skipped and so is never found
there. That means we do a strcmp comparison of the mangled names, even when the
'*' says the types must be compared by pointer address. In the testcase the two
structs have the same mangled name, even though they are distinct types (due to
the unnamed namespaces). The string comparison therefore returns 0, and so
neither type is "before" the other, despite being distinct types.

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

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

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Alfred M. Szmidt from comment #1)
> > Could someone go over these bugs and commit the pending patches?
> 
> Only bug 21823 is left now.

OK, that's closed now; can this one be closed now, too?

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

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

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

Bug 21823 Summary: MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

   What|Removed |Added

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

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Gallager  ---
(In reply to Eric Gallager from comment #10)
> Is it ok to close this as FIXED now? Or should we leave it open for
> backports?

Closing per comments in bug 80047

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

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

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

Bug 80047 Summary: fixincludes/fixincl.c: PVS-Studio: Improper Release of 
Memory Before Removing Last Reference (CWE-401)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80047

   What|Removed |Added

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

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #11 from Eric Gallager  ---
(In reply to Xi Ruoyao from comment #10)
> Fixed in trunk.
> 
> I'm not sure if this should be backported.

ok, I'll close this and the other, then.

[Bug tree-optimization/103216] missed optimization, phiopt/vrp?

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||103218
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584411.html
   Keywords||patch

--- Comment #7 from Andrew Pinski  ---
With PR 103218 patch and the one which I submited here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584411.html

This is basically fixed (we run into PR 103220 but that is a gimple level
missed optimization which should not matter really).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103218
[Bug 103218] (a < 0) << signbit is not always optimized to a & signbitmask at
the gimple level

[Bug sanitizer/102911] AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
.

[Bug tree-optimization/103219] [12 Regression] ICE Segmentation fault at -O3 (during GIMPLE pass: unrolljam) since r12-4526-gd8edfadfc7a9795b

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Aldy Hernandez from comment #1)
> Looks like a latent bug elsewhere as we're not threading anything.  For that
> matter, test fails even with -fno-thread-jumps.

Right, it is a dup of one of the other bugs listed in see also.  The code in
unrolljam is suspect as mentioned in one of them (I can't remember which one).

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #6 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584293.html

[Bug c++/103239] missing reason why template argument deduction/substitution failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||7.1.0
   Last reconfirmed||2021-11-14
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Note the first "template argument deduction/substitution failed" message was
missing until GCC 9.

Confirmed.

[Bug tree-optimization/103184] [12 Regression] ICE caused by r12-5102

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

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

[Bug tree-optimization/103235] [12 Regression] Recent change to atomics triggers ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
Dup of bug 103184.

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

[Bug tree-optimization/103235] [12 Regression] Recent change to atomics triggers ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||ice-on-valid-code
 Target||csky

[Bug c++/103236] [9/10/11/12 Regression] ICE: in tsubst_pack_expansion, at cp/pt.c:13162

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||8.1.0
Summary|ICE: in |[9/10/11/12 Regression]
   |tsubst_pack_expansion, at   |ICE: in
   |cp/pt.c:13162   |tsubst_pack_expansion, at
   ||cp/pt.c:13162
  Known to work||7.1.0, 7.4.0
   Last reconfirmed||2021-11-14

--- Comment #2 from Andrew Pinski  ---
GCC 7.4.0 and before did:
: In lambda function:
:5:35: error: parameter packs not expanded with '...':
 [](auto) { }([](auto... x) { x; });
   ^
:5:35: note: 'x'
: In function 'void foo(const Ts& ...)':
:6:4: error: operand of fold expression has no unexpanded parameter
packs
   ([] {

 [](auto) { }([](auto... x) { x; });
 ~~~
   }(), ...);
   ~^~

[Bug tree-optimization/103237] [10/11/12 Regression] wrong code with -ftree-vectorize at -O1 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|wrong code with |[10/11/12 Regression] wrong
   |-ftree-vectorize at -O1 on  |code with -ftree-vectorize
   |x86_64-linux-gnu|at -O1 on x86_64-linux-gnu
  Known to fail||10.1.0, 10.3.0, 11.2.0
   Last reconfirmed||2021-11-14
 Status|UNCONFIRMED |NEW
  Known to work||9.1.0, 9.4.0
   Target Milestone|--- |11.3

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

[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Sergei Trofimovich from comment #4)
> Created attachment 51792 [details]
> gdb-bug.cc


That was filed as PR 102216.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

--- Comment #20 from Thomas Koenig  ---
(In reply to Mikael Morin from comment #19)
> (In reply to Thomas Koenig from comment #15)
> > One possibility would be to extend the patch Sandra posted at
> > https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html
> > to scalarization.
> 
> Probably nice to have, but it relies on casts which I see as fragile, and I
> don’t trust the middle end to not mishandle corner cases here and there.

Is it indeed fragile?  And if we think up enough test cases to
throw into the testsuite, I think we can at least make sure that
it does not break quietly :-)

[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

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

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

--- Comment #7 from Jonathan Wakely  ---
Nobody is maintaining the modules code right now. This was introduced by a
libstdc++ change, but as far as I know the library code is correct and this is
just a compiler bug that should get fixed in stage 3.

[Bug c++/103239] New: confusing template argument deduction error message

[ich.freak at gmx dot net via Gcc-bugs]

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

Bug ID: 103239
   Summary: confusing template argument deduction error message
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ich.freak at gmx dot net
  Target Milestone: ---

When trying to resolve a function call, GCC iterates through the candidates,
checking if it can deduce/substitute template parameters. When failing to
deduce/substitute, it outputs nicely why it failed to do so. However, when 2
candidates fail for the same reason, it appears that this reason is only
printed for the first candidate, not for the second one, leaving the user with
a confusing message such as

[...]
note:   template argument deduction/substitution failed:
:8:5: note: candidate: [...]

that is, no reason is printed after the colon and, instead, the next candidate
is listed. This seems surprising and unintended. It would be nice to tell the
user why deduction/substitution failed for his/her favorite candidate.

I drafted a small example here: https://godbolt.org/z/PjeGa3YPe
The code is:

#include 
template struct X {
using T = int;
template using Z = Y::T;

X() = default;
template> X(Y&& y, int, Q&& q = Q()) {}

template> 
X(Y&& y, int, Q&& q = Q(), int ignore = 10) {}
};

int main () {
const X<0> x = X<0>();
X<0> y(x, 0);
}

[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

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

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

--- Comment #6 from Hans-Peter Nilsson  ---
(In reply to seurer from comment #5)
> I am still seeing these today with
> g:a40970cf043553f0ca09a3b7be1c5a949623d915, r12-4318

[list elided]

For cris-elf too.  For cris-elf, be5bdccd865b (r12-4056) was clean, but on the
next run of my autotester, with 5f9ccf17de7f (r12-4088), these appeared:
+g++.sum g++.dg/modules/xtreme-header-3_a.H
+g++.sum g++.dg/modules/xtreme-header-3_b.C
+g++.sum g++.dg/modules/xtreme-header-3_c.C
+g++.sum g++.dg/modules/xtreme-header_a.H
+g++.sum g++.dg/modules/xtreme-header_b.C

Then no change in the results for these tests until and including db3d7270b42f
(r12-4245).
At the next run, with e6f6972b5f47 (r12-4255), these were added:
+g++.sum g++.dg/modules/xtreme-header-5_a.H
+g++.sum g++.dg/modules/xtreme-header-5_b.C
+g++.sum g++.dg/modules/xtreme-header-5_c.C

Then similarly no change until and including 008e7397dad9 (r12-4324).
At the next run, with 30cce6f65a77 (r12-4331), this was added:
+g++.sum g++.dg/modules/xtreme-tr1_b.C

Then similarly no change until and including d1dcaa31453f (r12-4351).
At the next run, with b37351e3279d (r12-4359), that one disappeared again:
-g++.sum g++.dg/modules/xtreme-tr1_b.C

Then no change matching "g++.dg/modules/xtreme-" up to and including
a29174904bb1 (r12-5240), which is the last run at this writing.

I'm going to see about xfailing these, as apparently no-one takes pity beyond
documenting them.  My own excuse is that C++ modules isn't really a priority
for cris-elf.

[Bug c++/103238] New: c++ Feature: array-copy experimental extensions implementing P1997

[wjwray at gmail dot com via Gcc-bugs]

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

Bug ID: 103238
   Summary: c++ Feature: array-copy experimental extensions
implementing P1997
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: patch
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

This is a feature-tracking PR for an incoming patch to implement
C++ proposal P1997 "Relaxing restrictions on array", that adds:

  C array copy semantics:
* array-array initializations
* array-array assignments
* array return-by-value from functions
 (array formal parameters are unchanged; there's no pass-by-value).

  Plus, C++ specific:
* array pseudo-destructors
* array element type deduction
 (i.e. admitting placeholder auto in array variable declarations).

Implementation strategy

The features are implemented as an experimental extension, disabled by default.
The patch should have no effect until enabled by the new option:

-farray-copy (flag_array_copy)

This single flag enables all features, copy-semantic or not.
The features are enabled as an extension in all -std modes as appropriate
(i.e. placeholder auto in C++11 and up).

The extension is documented as experimental with no guarantee of stability;
features may be added, removed or changed in detail.
In particular, there's no guarantee of ABI stability; 
allowing array as a function return type has ABI impact:

  * Calling conventions for the array return slot must be agreed
  * On the C++ side, name-mangling conventions must be defined.

The plan is to first merge array-copy as experimental, with ABI defined as
'what the code does', and then to go ahead with ABI discussions, decide on
a written specification, and then do any required implementation work.

C and C++ proposal status

P1997R1 was seen by SG22, the ISO Joint C and C++ Liaison Study Group,
on Aug 6th 2021 with positive feedback from both C and C++ sides of the room.

It was voted forward to C++ EWG, with the strong recommendation to proceed
only once implementation experience has been gained. This work is the result.
The EWG chair prefers that "it be reviewed and tentatively approved by ...gcc
code owners" as an upstreamable contribution. The aim is to merge array-copy
extensions on trunk for wide availability. Likewise for other compilers.

The C compatible subset of the copy-semantic changes apply to C language,
and could be made to accommodate array extensions such as VLAs and VM types.
The plan is to follow up on the C side once this patch is accepted into g++:
(1) to assist in writing the C proposal based on this experience, and
(2) to contribute to the gcc implementation, with support of C code owners.

The C++ proposal will be revised based on experience and feedback as the
implementation is honed via issues, bug fixes or further opportunities.

An interesting suggestion is that these array extensions be incorporated into
C and C++ standards as a DR, applying as they do to the C subset and all -std,
with DR standing for Dennis Ritchie, great language designer in the sky.

[Bug tree-optimization/103237] New: wrong code with -ftree-vectorize at -O1 on x86_64-linux-gnu

[haoxintu at gmail dot com via Gcc-bugs]

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

Bug ID: 103237
   Summary: wrong code with -ftree-vectorize at -O1 on
x86_64-linux-gnu
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all.

This seems a long latent bug existed after GCC-10.1.

$cat small.c
#include 
#include 
struct S0 {
  uint16_t a;
};
union U1 {
  struct S0 b;
};
int32_t g1[1] = {0};
uint32_t g2[][10][1] = {
{}, {}, {}, {}, {}, {}, {{}, {}, {}, {}, {}, {}, {4294967295UL}}};
union U1 g3;
static int32_t func_1() {
  int32_t *l_1 = [0];
  uint32_t l_2 ;
  for (g3.b.a = (27); (g3.b.a != 45);
   g3.b.a = g3.b.a + 9) {
for (l_2 = 0; (l_2 <= 3); l_2 += 1) {
  uint32_t *l_3 = [6][6][0];
  *l_1 = *l_3 ^= ((0 == 0) << 0);
}
  }
  return 0;
}
int main() {
  func_1();
  for (int i = 0; i < 1; i++)
printf("%d\n", g1[i]);
  return 0;
}


$gcc -O2 -ftree-vectorize small.c ; ./a.out
-1

$gcc -O1 -ftree-vectorize small.c ; ./a.out
0

$gcc -O1 small.c ; ./a.out
-1

$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/haoxin/haoxin-data/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build/ --enable-bootstrap
--enable-checking=release --enable-multilib --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 2024 (experimental) (GCC) 

Can also check here: https://godbolt.org/z/ncar1aWYM

Thanks,
Haoxin

[Bug tree-optimization/103235] [12 Regression] Recent change to atomics triggers ICE

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
Works for me:

[hjl@gnu-cfl-2 pr103235]$
/export/build/gnu/tools-build/gcc-gitlab-cross/build-csky-linux/gcc/cc1 -O2 
pthread_cancel.i -I./ -quiet -w
[hjl@gnu-cfl-2 pr103235]$
/export/build/gnu/tools-build/gcc-gitlab-cross/build-csky-linux/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/export/build/gnu/tools-build/gcc-gitlab-cross/build-csky-linux/gcc/xgcc
Target: csky-linux
Configured with: /export/gnu/import/git/gitlab/x86-gcc/configure
--with-demangler-in-ld --target=csky-linux --prefix=/usr/gcc-12.0.0-csky-linux
--with-local-prefix=/usr/local --with-system-zlib --disable-libcc1
--disable-libcilkrts --disable-libsanitizer --disable-libmpx
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 2024 (experimental) (GCC) 
[hjl@gnu-cfl-2 pr103235]$

[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130

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

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

--- Comment #4 from Sergei Trofimovich  ---
Created attachment 51792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51792=edit
gdb-bug.cc

Found similar bug in gdb/c++ at gdb/language.c. It might have slightly better
loop structure.
As a downside it relies on very complex std::sort definition. Extracted
example:

#include 
enum language_t {
language_unknown,
language_auto,
language_foo,
nr_languages
};
extern const language_t languages_[nr_languages] /* = { auto, foo, unk }
*/;
bool lc (language_t, language_t);
const language_t* add_set_language_command ()
{
language_t *ls = new language_t[nr_languages];

// pull auto, unk in front. sort the rest
language_t* ls_p = ls;
*ls_p++ = language_auto;
*ls_p++ = language_unknown;

language_t* sort_begin = ls_p;
for (const auto lang : languages_)
{
// already present
if (lang == language_auto || lang == language_unknown)
continue;

   *ls_p++ = lang;
}
std::sort (sort_begin, ls_p, lc);
return ls;
}

$ ./gcc12/bin/g++-12.0.0 -O2 gdb-bug.cc -Werror=array-bounds

In file included from /...-gcc-12.0.0/include/c++/12.0.0/algorithm:61,
 from gdb-bug.cc:1:
In function 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = language_t*;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter]',
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = language_t*;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter]' at /...-gcc-12.0.0/include/c++/12.0.0/bits/stl_algo.h:1940:31,
inlined from 'void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter =
language_t*; _Compare = bool (*)(language_t, language_t)]' at
/nix/store/kckkq6280kixj8wxg4d0ks9lck8nai73-gcc-12.0.0/include/c++/12.0.0/bits/stl_algo.h:4853:18,
inlined from 'const language_t* add_set_language_command()' at
gdb-bug.cc:28:19:
/...-gcc-12.0.0/include/c++/12.0.0/bits/stl_algo.h:1849:32: error: array
subscript 18 is outside array bounds of 'language_t [3]' [-Werror=array-bounds]
 1849 |   std::__insertion_sort(__first, __first + int(_S_threshold),
__comp);
  |  
~^~
gdb-bug.cc: In function 'const language_t* add_set_language_command()':
gdb-bug.cc:12:53: note: at offset 72 into object of size 12 allocated by
'operator new []'
   12 | language_t *ls = new language_t[nr_languages];
  | ^
cc1plus: some warnings being treated as errors

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

--- Comment #19 from Mikael Morin  ---
(In reply to Thomas Koenig from comment #15)
> One possibility would be to extend the patch Sandra posted at
> https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html
> to scalarization.

Probably nice to have, but it relies on casts which I see as fragile, and I
don’t trust the middle end to not mishandle corner cases here and there.

(In reply to Bernhard Reutner-Fischer from comment #17)
> Do we want to address arrays always at position 0 (maybe to help graphite ?)
> or would it be sufficient to just not dereference the array "before" the
> first position 
> 
I’m not sure I understand the difference.

[Bug tree-optimization/103235] [12 Regression] Recent change to atomics triggers ICE

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

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

--- Comment #2 from Jeffrey A. Law  ---
Can you please double-check?  It just reproduced for me.  Perhaps you were
missing -I./ which is sometimes needed for cross toolchains to *-linux.

[jlaw@dl360p gcc]$ ./cc1 -O2 pthread_cancel.i -I./ -quiet -w
pthread_cancel.c: In function ‘__pthread_cancel’:
pthread_cancel.c:60:1: error: type mismatch in binary expression
int

unsigned int

int

_36 = _4 & 8;
during GIMPLE pass: fab
pthread_cancel.c:60:1: internal compiler error: verify_gimple failed
0x134a788 verify_gimple_in_cfg(function*, bool)
/home/jlaw/test/gcc/gcc/tree-cfg.c:5577
0x1198471 execute_function_todo
/home/jlaw/test/gcc/gcc/passes.c:2042
0x119740d do_per_function
/home/jlaw/test/gcc/gcc/passes.c:1687
0x1198661 execute_todo
/home/jlaw/test/gcc/gcc/passes.c:2096
Please submit a full bug report,

[jlaw@dl360p gcc]$ pushd /home/jlaw/test/gcc
~/test/gcc ~/test/obj/csky-linux-gnu/obj/gcc/gcc
[jlaw@dl360p gcc]$ git status .
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add ..." to include in what will be committed)
gcc/J
gcc/j

nothing added to commit but untracked files present (use "git add" to track)
[jlaw@dl360p gcc]$ git log -n1 HEAD
commit 8a601f9bc45f9faaa91f18d58ba71b141acff701 (HEAD -> master, origin/trunk,
origin/master, origin/HEAD)
Author: Aldy Hernandez 
Date:   Sun Nov 14 16:17:36 2021 +0100

Remove gcc.dg/pr103229.c

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

Mikael Morin  changed:

   What|Removed |Added

  Attachment #51787|0   |1
is obsolete||

--- Comment #18 from Mikael Morin  ---
Created attachment 51791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51791=edit
new draft patch

This fixes comment #13 as well, but it breaks printing of the dummy array from
the contained subroutine s. :-(

[Bug c++/103236] ICE: in tsubst_pack_expansion, at cp/pt.c:13162

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
may be dup of PR99590.

[Bug tree-optimization/103235] [12 Regression] Recent change to atomics triggers ICE

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-14
 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com
 Status|UNCONFIRMED |WAITING

--- Comment #1 from H.J. Lu  ---
I can't produce it with r12-5243 for csky-linux-gnu.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

--- Comment #17 from Bernhard Reutner-Fischer  ---
Do we want to address arrays always at position 0 (maybe to help graphite ?) or
would it be sufficient to just not dereference the array "before" the first
position like Mikael suggests in comment #14?

gfc_conv_expr_descriptor has this
  if (se->data_not_needed)
gfc_conv_descriptor_data_set (, parm,
  gfc_index_zero_node);
  else
/* Point the data pointer at the 1st element in the section.  */
gfc_get_dataptr_offset (, parm, desc, base,
subref_array_target, expr);

  gfc_conv_descriptor_offset_set (, parm, offset);

where base is (for "section"-addressing) 9 for the testcase in comment #16 as
can be seen in Richard's initial report.

[Bug c++/103236] New: ICE: in tsubst_pack_expansion, at cp/pt.c:13162

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103236
   Summary: ICE: in tsubst_pack_expansion, at cp/pt.c:13162
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This seems to be an old bug, but I haven't found the dup of which bug it is.
Maybe I have reported a similar one a long time ago, but I'm not sure.

template 
void foo(const Ts&...) {
  ([] {
[](auto) { }([](auto... x) { x; });
  }(), ...);
}

int main() {
  foo(0);
}

https://godbolt.org/z/Y916oqvje

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

--- Comment #16 from Bernhard Reutner-Fischer  ---
In addition to comment #1
here's an excerpt of an existing test with just one dimension:

$ cat f_pr86389.f90
! PR 19239.  Check for various kinds of vector subscript.  In this test,
! all vector subscripts are indexing single-dimensional arrays.
! { dg-do run }
program main
  implicit none
  integer, parameter :: n = 10
  integer :: i
  integer, dimension (n) :: a, b, idx, id

  idx = (/ 3, 1, 5, 2, 4, 10, 8, 7, 6, 9 /)
  id = (/ (i, i = 1, n) /)
  b = (/ (i * 100, i = 1, n) /)

  a = 0
  a (idx (10:6:-2)) = b (idx (1:7:3))
write(*,*) "#i   =", id
write(*,*) "idx  =", idx
write(*,*) "now a=", a
write(*,*) "now b=", b
write(*,*) "a idx(10:6:-2)=", idx (10:6:-2)
write(*,*) "b idx(1:7:3)  =", idx (1:7:3)
  call test (idx (10:6:-2), idx (1:7:3))

contains
  subroutine test (lhs, rhs)
integer, dimension (:) :: lhs, rhs
integer :: i
!!!if (size (lhs, 1) .ne. size (rhs, 1)) STOP 11
!do i = 1, size (lhs, 1)
do i = 1, 3 ! spare us the code for size(), fixed const
  if (a (lhs (i)) .ne. b (rhs (i))) STOP 12
end do
!a = 0
  end subroutine test
end program main

[Bug tree-optimization/103235] New: [12 Regression] Recent change to atomics triggers ICE

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

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

Bug ID: 103235
   Summary: [12 Regression] Recent change to atomics triggers ICE
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51790=edit
Testcase

This change:
commit fb161782545224f55ba26ba663889c5e6e9a04d1
Author: liuhongt 
Date:   Mon Oct 25 13:59:51 2021 +0800

Improve integer bit test on __atomic_fetch_[or|and]_* returns

Is causing various ports (csky, mips*, s390, maybe others) to fail to build
glibc:
bash-5.1# ./cc1 -O2 /tmp/pthread_cancel.i  -quiet
pthread_cancel.c: In function '__pthread_cancel':
pthread_cancel.c:60:1: error: type mismatch in binary expression
int

unsigned int

int

_36 = _4 & 8;
during GIMPLE pass: fab
pthread_cancel.c:60:1: internal compiler error: verify_gimple failed
0x11a2ef3 verify_gimple_in_cfg(function*, bool)
../../../gcc/gcc/tree-cfg.c:5577
0xff2179 execute_function_todo
../../../gcc/gcc/passes.c:2042
0xff1115 do_per_function
../../../gcc/gcc/passes.c:1687
0xff2369 execute_todo
../../../gcc/gcc/passes.c:2096


Attached is a testcase that ought to trigger with a csky-linux-gnu cross
compiler.  I haven't done any debugging other than to bisect to the change
above.

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #11 from Martin Liška  ---
But yes, with ulimit -s 512, one can reduce it to:

$ cat pr103231.c
long g_1496_BK8K8el_2738;
int fn1_l_1522;
int fn1_l_2664;
long fn1_l_1761;
unsigned int fn1_l_1812;
int fn1_l_2189;
int fn1_by;
int fn1_l_2688;
short fn1_l_1852;
short fn1_l_2352;
void fn1() {
  unsigned l_2456;
LABEL_5959g:
  __builtin_printf("l_2456=%llu\n", l_2456);
LABEL_TaTak:
  if (fn1_by)
if (fn1_l_2189) goto LABEL_5959g;
  int BK8K8hl_2189 = fn1_l_2352 * (~fn1_l_1852 & g_1496_BK8K8el_2738);
  short dg = l_2456 & fn1_l_1761;
  l_2456 = dg;
  if (fn1_l_1522) fn1_l_1761 = ~BK8K8hl_2189;
  short Bm9m9El_1852 = ~(~0 && fn1_l_2688);
  unsigned Bm9m9Fl_1522 = -Bm9m9El_1852;
  if (fn1_l_1812) fn1_l_1852 = ~fn1_l_2664 ^ Bm9m9Fl_1522;
  goto LABEL_TaTak;
}

with the following back-trace:

#0  0x01218987 in range_query::get_tree_range (this=0x7fffd4a0,
r=..., expr=0x776200d8, stmt=) at
/home/marxin/Programming/gcc/gcc/value-query.cc:213
#1  0x01bcb812 in fold_using_range::range_of_range_op
(this=0x7ff8396f, r=..., s=0x7776c108, src=...) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:617
#2  0x01bcce12 in fold_using_range::fold_stmt (this=0x7ff8396f,
r=..., s=0x7776c108, src=..., name=0x7776b360) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:552
#3  0x01bc14a7 in gimple_ranger::fold_range_internal
(this=this@entry=0x7fffd4a0, r=..., s=s@entry=0x7776c108,
name=name@entry=0x7776b360) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:243
#4  0x01bc1757 in gimple_ranger::range_of_stmt (this=0x7fffd4a0,
r=..., s=0x7776c108, name=0x7776b360) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:296
#5  0x01bc1dc0 in gimple_ranger::range_of_expr (this=0x7fffd4a0,
r=..., expr=0x7776b360, stmt=) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:113
#6  0x01bcb7e0 in fold_using_range::range_of_range_op
(this=0x7ff87c4f, r=..., s=0x7776d140, src=...) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:600
#7  0x01bcce12 in fold_using_range::fold_stmt (this=0x7ff87c4f,
r=..., s=0x7776d140, src=..., name=0x7776b3a8) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:552
#8  0x01bc14a7 in gimple_ranger::fold_range_internal
(this=this@entry=0x7fffd4a0, r=..., s=s@entry=0x7776d140,
name=name@entry=0x7776b3a8) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:243
...
#164 0x01bc1757 in gimple_ranger::range_of_stmt (this=0x7fffd4a0,
r=..., s=0x7773f500, name=0x7776b708) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:296
#165 0x01bc1dc0 in gimple_ranger::range_of_expr (this=0x7fffd4a0,
r=..., expr=0x7776b708, stmt=) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:113
#166 0x01bfec29 in (anonymous namespace)::format_integer (dir=...,
arg=0x7776b708, query=0x7fffd4a0) at
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:1386
#167 0x01bf8de4 in (anonymous namespace)::format_directive (info=...,
res=0x7fffcf80, dir=..., query=) at
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:3091
#168 0x01bfc092 in (anonymous namespace)::compute_format_length
(query=0x7fffd4a0, res=0x7fffcf80, info=...) at
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4033
#169 handle_printf_call (gsi=gsi@entry=0x7fffd880, ptr_qry=...) at
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4703
#170 0x0112a8de in strlen_pass::check_and_optimize_call
(this=0x7fffd480, zero_write=0x7fffd28f) at
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:5379
#171 0x0112b592 in strlen_pass::check_and_optimize_stmt
(this=0x7fffd480, cleanup_eh=) at
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:5583
#172 0x0112b9d6 in strlen_pass::before_dom_children
(this=0x7fffd480, bb=0x7760d270) at
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:5767
#173 0x01b8de48 in dom_walker::walk (this=0x7fffd480,
bb=0x7760d270) at /home/marxin/Programming/gcc/gcc/domwalk.c:309
#174 0x0112befb in (anonymous namespace)::printf_strlen_execute
(fun=0x77764000, warn_only=) at
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:5831
#175 0x00e2effa in execute_one_pass (pass=0x2a1a250) at
/home/marxin/Programming/gcc/gcc/passes.c:2567
#176 0x00e2f8f3 in execute_pass_list_1 (pass=0x2a1a250) at
/home/marxin/Programming/gcc/gcc/passes.c:2656
#177 0x00e2f905 in execute_pass_list_1 (pass=0x2a17cc0) at
/home/marxin/Programming/gcc/gcc/passes.c:2657
#178 0x00e2f936 in execute_pass_list (fn=0x77764000,
pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2667
#179 0x00a73975 in cgraph_node::expand (this=0x77616220) at
/home/marxin/Programming/gcc/gcc/context.h:48
#180 cgraph_node::expand (this=0x77616220) at

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #10 from Martin Liška  ---
(In reply to Zhendong Su from comment #9)
> A very simple repro (with ulimit -s 32):

Well, using a stack limit of 32B does not make sense, pretty much any
executable hits stack overflow with such a small limit.

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #9 from Zhendong Su  ---
A very simple repro (with ulimit -s 32):

[530] % compile.sh small.c
*** Compiling with: gcctk -O1 small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

*** Compiling with: gcc110 -O1 small.c
[531] % 
[531] % cat small.c
int a, b;
int main() {
  int c, d;
L1:
  if (a) {
__builtin_printf("%d", d);
  L2:
goto L1;
  }
  if (b) {
d = c;
goto L2;
  }
  return 0;
}
[532] % 
[532] % cat compile.sh
#!/bin/bash

ulimit -s 32

echo "*** Compiling with: gcctk -O1 $1"
gcctk -O1 $1

echo

echo "*** Compiling with: gcc110 -O1 $1"
gcc110 -O1 $1
[533] %

[Bug analyzer/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

[alx.manpages at gmail dot com via Gcc-bugs]

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

--- Comment #3 from alx.manpages at gmail dot com ---
Hi Jonathan,

On 11/14/21 15:57, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103233
> 
> Jonathan Wakely  changed:
> 
> What|Removed |Added
> 
>   Status|UNCONFIRMED |WAITING
> Last reconfirmed||2021-11-14
>   Ever confirmed|0   |1
> 
> --- Comment #2 from Jonathan Wakely  ---
> (In reply to Alejandro Colomar from comment #0)
>> There are two problems here:
>>
>> One is a dereference of a NULL pointer in the standard C++ library code
>> (at least that's what -fanalyzer reports).
> 
> The analyzer doesn't support C++ properly yet, and is completely wrong here.
> See below.
> 
> 
> 
>> Another is that I'm seeing the error while compiling user code (my library):
>> 
> 
> What error? Please provide the code to reproduce the problem, not just a URL,
> see https://gcc.gnu.org/bugs

Well, not an error, but a warning (I transformed it into an error with 
-Werror).

The error/warning that I referred to
was the one I copied entirely
(including the command to produce it).
The case that I reported was compiling an already preprocessed file. 
Since it was a big temporary file
(and probably less readable than the source), I didn't share it.
I simplified the file, and compiled it directly,
to simplify reproducing it:



$ cat sys_warning.cxx
/**
  * Copyright (c) 2018 by Alejandro Colomar 
  * SPDX-License-Identifier:  GPL-2.0-only

**/


#include 

#include 

#include 
#include 
#include 
#include 
#include 


static constexpr intMAX_FEATURES = 5;
static constexpr double GOOD_MATCH_P = 0.25;


[[gnu::nonnull(1, 2)]]
void orb_align(const class cv::Mat *ref,
class cv::Mat *img,
class cv::Mat *img_matches);


void orb_align(const class cv::Mat *ref,
class cv::Mat *img,
class cv::Mat *img_matches)
{
class std::vectorkeypoints_0;
class std::vectorkeypoints_1;
class cv::Matdescriptors_0;
class cv::Matdescriptors_1;
struct cv::Ptr  orb;
class std::vector  matches;
struct cv::Ptr  matcher;
ptrdiff_tgood_matches;
class std::vector > points_0;
class std::vector > points_1;
ptrdiff_tsize;
class cv::Matimg_hg;
class cv::Matimg_align;

/* Detect ORB features & compute descriptors */
orb = cv::ORB::create(MAX_FEATURES, 1.2f, 8, 31, 0, 2,
cv::ORB::HARRIS_SCORE, 31, 20);
orb->detectAndCompute(*ref, cv::Mat(), keypoints_0, descriptors_0,
false);
orb->detectAndCompute(*img, cv::Mat(), keypoints_1, descriptors_1,
false);

/* Match structures */
matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");
matcher->match(descriptors_1, descriptors_0, matches, cv::Mat());

/* Sort matches by score */
std::sort(matches.begin(), matches.end());

/* Remove not so good matches */
good_matches= GOOD_MATCH_P * matches.size();
matches.erase(matches.begin() + good_matches, matches.end());

/* Draw top matches */
if (img_matches)
cv::drawMatches(*img, keypoints_1, *ref, keypoints_0, matches,
*img_matches,  cv::Scalar::all(-1),
cv::Scalar::all(-1), std::vector(),
cv::DrawMatchesFlags::DEFAULT);

/* Extract location of good matches */
size= matches.size();
for (ptrdiff_t i = 0; i < size; i++) {
points_1.push_back(keypoints_1[matches[i].queryIdx].pt);
points_0.push_back(keypoints_0[matches[i].trainIdx].pt);
}

/* Find homography */
img_hg = cv::findHomography(points_1, points_0, cv::RANSAC,
 3, cv::noArray(), 2000, 0.995);

/* Use homography to warp image */
cv::warpPerspective(*img, img_align, img_hg, ref->size(),
cv::INTER_LINEAR, cv::BORDER_CONSTANT,
cv::Scalar());

/* Write img_align into img */
*img= img_align;
img_align.release();
}



$ c++ -D _GNU_SOURCE -D _POSIX_C_SOURCE=200809L -O3 -Wall -Wextra 
-Winvalid-pch -fno-common -fpic -isystem/usr/include/opencv4 

[Bug ipa/103234] New: ipa-sra is broken (and therefore disabled) on variably sized parameters

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

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

Bug ID: 103234
   Summary: ipa-sra is broken  (and therefore disabled) on
variably sized parameters
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Disabling workaround I needed to add to ipa-fnsummary:

   for (tree parm = DECL_ARGUMENTS (node->decl);
parm && !no_signature; parm = DECL_CHAIN (parm))
 if (variably_modified_type_p (TREE_TYPE (parm), node->decl))
   {
 if (dump_file)
{
  fprintf (dump_file, "No signature change:"
   " has parameter with variably modified type.\n");
}
 no_signature = true;
   }

we end up with few ICES in gfortran testsuite:

./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O2 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O2 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O3 -g 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -O3 -g 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -Os 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associate_35.f90   -Os 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associated_assumed_rank.f90
  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associated_assumed_rank.f90
  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions  (test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associated_assumed_rank.f90
  -O3 -g  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/associated_assumed_rank.f90
  -O3 -g  (test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O2 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O2 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O3
-g  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -O3
-g  (test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -Os 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/trim_optimize_4.f90   -Os 
(test for excess errors)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90,  -O2  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90,  -O2 -fomit-frame-pointer
-finline-functions  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90,  -O3 -g  (internal compiler
error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90,  -Os  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_2.f90, -O2 -ftree-vectorize -msse2 
(internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_5.f90,  -O2  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_5.f90,  -O2 -fomit-frame-pointer
-finline-functions  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:
gfortran.fortran-torture/execute/entry_5.f90,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops  (internal compiler error)
./testsuite/gfortran/gfortran.sum:FAIL:

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||dl.soluz at gmx dot net

--- Comment #16 from Patrick Palka  ---
*** Bug 103232 has been marked as a duplicate of this bug. ***

[Bug c++/103232] scoped template specalization is not supported (not with C+17 nor C++20)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
dup of PR85282, the plan is to implement this in GCC 12.

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

[Bug c++/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Alejandro Colomar from comment #0)
> There are two problems here:
> 
> One is a dereference of a NULL pointer in the standard C++ library code
> (at least that's what -fanalyzer reports).

The analyzer doesn't support C++ properly yet, and is completely wrong here.
See below.



> Another is that I'm seeing the error while compiling user code (my library):
> 

What error? Please provide the code to reproduce the problem, not just a URL,
see https://gcc.gnu.org/bugs


> |/usr/include/c++/11/bits/stl_vector.h:346:25:
> |  346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) :
> pointer();
> |  |   
> ~^
> |  | |
> |  | (7) following 'false' branch...

This cannot happen. The length is this->size() + 1 and we already checked for
overflow, so it is guaranteed to be a positive integer.


>|..
>|  127 | return static_cast<_Tp*>(::operator new(__n *
> sizeof(_Tp)));
>|  | 
> ~
>|  ||
>|  |(12)
> ...to here
>|  |(13) this
> call could return NULL


This is nonsense, operator new(size_t) cannot return null.

[Bug c++/103233] Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;



$ dpkg -l "*[cg]++*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===
un  c++-compiler(no description
available)
un  c++abi2-dev (no description
available)
ii  g++   4:11.2.0-2   amd64GNU C++ compiler
ii  g++-1111.2.0-10amd64GNU C++ compiler
un  g++-11-multilib (no description
available)
un  g++-multilib(no description
available)
un  g++-x86-64-linux-gnu(no description
available)
ii  lib32stdc++6  11.2.0-10amd64GNU Standard C++
Library v3 (32 bit Version)
un  libg++2.8-dev   (no description
available)
un  libg++27-dev(no description
available)
un  libg++272-dev   (no description
available)
un  libsigc++-2.0-0c2a  (no description
available)
ii  libsigc++-2.0-0v5:amd64   2.10.4-2 amd64type-safe Signal
Framework for C++ - runtime
ii  libstdc++-10-dev:amd6410.3.0-12amd64GNU Standard C++
Library v3 (development files)
un  libstdc++-10-doc(no description
available)
ii  libstdc++-11-dev:amd6411.2.0-10amd64GNU Standard C++
Library v3 (development files)
un  libstdc++-11-doc(no description
available)
un  libstdc++-dev   (no description
available)
un  libstdc++2.10-dev   (no description
available)
un  libstdc++2.8-dev(no description
available)
un  libstdc++2.9-dev(no description
available)
un  libstdc++2.9-glibc2.1-dev   (no description
available)
un  libstdc++3.0-dev(no description
available)
ii  libstdc++6:amd64  11.2.0-10amd64GNU Standard C++
Library v3
un  libstdc++6-11-dbg   (no description
available)

[Bug c++/103233] New: Warning from system libraries in user code: CWE-476 -Werror=analyzer-null-dereference

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 103233
   Summary: Warning from system libraries in user code: CWE-476
-Werror=analyzer-null-dereference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

There are two problems here:

One is a dereference of a NULL pointer in the standard C++ library code
(at least that's what -fanalyzer reports).
Another is that I'm seeing the error while compiling user code (my library):


c++ -D _GNU_SOURCE -D _POSIX_C_SOURCE=200809L -D
SYSCONFDIR_='"/usr/local/etc/alx"' -O3 -Wall -Wextra -Winvalid-pch -fno-common
-Werror -fpic -isystem/usr/local/include -D_GNU_SOURCE
-D_POSIX_C_SOURCE=200809L -isystem/usr/include/opencv4
-isystem/usr/local/include -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L
-isystem/usr/local/include -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L -fanalyzer
-std=gnu++20 -Wno-vla -I /home/alx/src/alx/libalx/include -fpreprocessed -S
-o /home/alx/src/alx/libalx/tmp/alx/cv/features2d/orb.cxx.s
/home/alx/src/alx/libalx/tmp/alx/cv/features2d/orb.cxx.i
In member function 'void std::vector<_Tp,
_Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...)
[with _Args = {const cv::Point_&}; _Tp = cv::Point_; _Alloc =
std::allocator >]':
cc1plus: error: dereference of NULL '__cur' [CWE-476]
[-Werror=analyzer-null-dereference]
  'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_&}; _Tp =
cv::Point_; _Alloc = std::allocator >]': events 1-2
|
|/usr/include/c++/11/bits/vector.tcc:426:7:
|  426 |   vector<_Tp, _Alloc>::
|  |   ^~~
|  |   |
|  |   (1) entry to 'std::vector
>::_M_realloc_insert&>'
|..
|  436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
|  | ~~~
|  | |
|  | (2) calling 'std::vector
>::_M_check_len' from 'std::vector >::_M_realloc_insert&>'
|
+--> 'std::vector<_Tp, _Alloc>::size_type std::vector<_Tp,
_Alloc>::_M_check_len(std::vector<_Tp, _Alloc>::size_type, const char*) const
[with _Tp = cv::Point_; _Alloc = std::allocator >]':
events 3-5
   |
   |/usr/include/c++/11/bits/stl_vector.h:1756:7:
   | 1756 |   _M_check_len(size_type __n, const char* __s) const
   |  |   ^~~~
   |  |   |
   |  |   (3) entry to 'std::vector
>::_M_check_len'
   | 1757 |   {
   | 1758 | if (max_size() - size() < __n)
   |  | ~~
   |  | |
   |  | (4) following 'false' branch...
   |..
   | 1761 | const size_type __len = size() + (std::max)(size(),
__n);
   |  | ~~
   |  | |
   |  | (5)
...to here
   |
<--+
|
  'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_&}; _Tp =
cv::Point_; _Alloc = std::allocator >]': event 6
|
|/usr/include/c++/11/bits/vector.tcc:436:21:
|  436 | _M_check_len(size_type(1), "vector::_M_realloc_insert");
|  | ^~~
|  | |
|  | (6) returning to
'std::vector >::_M_realloc_insert&>'
from 'std::vector >::_M_check_len'
|
  'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_&}; _Tp =
cv::Point_; _Alloc = std::allocator >]': event 7
|
|/usr/include/c++/11/bits/stl_vector.h:346:25:
|  346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer();
|  |~^
|  | |
|  | (7) following 'false' branch...
|
  'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const cv::Point_&}; _Tp =
cv::Point_; _Alloc = std::allocator >]': event 8
|
|/usr/include/c++/11/bits/vector.tcc:450:48:
|  450 |__new_start + __elems_before,
|  |^~~~
|  |   

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

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #16 from dennis luehring  ---
the sample still gets reduced by clang to 160 with -O2 or -O3

clang:

main:   # @main
mov eax, 160
ret

and gcc 11.2/trunk producing

-O2
main:
pushrbp
mov edi, 12
sub rsp, 48
movqxmm15, QWORD PTR .LC0[rip]
mov DWORD PTR [rsp+8], 30
movqQWORD PTR [rsp], xmm15
pxorxmm15, xmm15
mov QWORD PTR [rsp+32], 0
movaps  XMMWORD PTR [rsp+16], xmm15
calloperator new(unsigned long)
mov rcx, QWORD PTR [rsp]
lea rdx, [rax+12]
lea rdi, [rsp+16]
mov QWORD PTR [rsp+16], rax
mov QWORD PTR [rsp+32], rdx
mov QWORD PTR [rax], rcx
mov ecx, DWORD PTR [rsp+8]
mov QWORD PTR [rsp+24], rdx
mov DWORD PTR [rax+8], ecx
callstd::_Vector_base >::~_Vector_base()
[base object destructor]
add rsp, 48
mov eax, 160
pop rbp
ret
mov rbp, rax
jmp .L5
main.cold:
.LC0:
.long   10
.long   20

-O3
main:
sub rsp, 24
mov edi, 12
movqxmm15, QWORD PTR .LC0[rip]
mov DWORD PTR [rsp+8], 30
movqQWORD PTR [rsp], xmm15
calloperator new(unsigned long)
mov esi, 12
mov rdi, rax
mov rax, QWORD PTR [rsp]
mov QWORD PTR [rdi], rax
mov eax, DWORD PTR [rsp+8]
mov DWORD PTR [rdi+8], eax
calloperator delete(void*, unsigned long)
mov eax, 160
add rsp, 24
ret
.LC0:
.long   10
.long   20


does that mean its still not clear if the unused new/delete can be removed
here?

[Bug c++/103232] scoped template specalization is not supported (not with C+17 nor C++20)

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #1 from dennis luehring  ---
gcc 11.2
https://gcc.godbolt.org/z/jG8f6Phjc
clang 7
https://gcc.godbolt.org/z/c4Md5Yh1x

[Bug c++/103232] New: scoped template specalization is not supported (not with C+17 nor C++20)

[dl.soluz at gmx dot net via Gcc-bugs]

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

Bug ID: 103232
   Summary: scoped template specalization is not supported (not
with C+17 nor C++20)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dl.soluz at gmx dot net
  Target Milestone: ---

C++17 allows scoped template specalization - clang 7+ and VStudio 2017/2019
allow it - gcc 11.2 and trunk are not able to compile the sample

--
enum class Type{ Int, Float };

struct Mapper {
template struct type_to_enum{};

template<> struct type_to_enum{
 static constexpr auto value = Type::Int;
};

template <> struct type_to_enum {
static constexpr auto value = Type::Float;
};
};
-

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 103229 Summary: gcc/gimple-range-cache.cc:654:10: runtime error: null 
pointer passed as argument 1, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229

   What|Removed |Added

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

[Bug tree-optimization/103229] gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/103229] gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-5242-ga7ef5da3a9c348c35abb72d6f64f209f5661cfa4
Author: Aldy Hernandez 
Date:   Sun Nov 14 11:27:32 2021 +0100

Do not pass NULL to memset in ssa_global_cache.

The code computing ranges in PHIs in the path solver reuses the
temporary ssa_global_cache by calling its clear method.  Calling it on
an empty cache causes us to call memset with NULL.

Tested on x86-64 Linux.

gcc/ChangeLog:

PR tree-optimization/103229
* gimple-range-cache.cc (ssa_global_cache::clear): Do not pass
null value to memset.

gcc/testsuite/ChangeLog:

* gcc.dg/pr103229.c: New test.

[Bug c++/87656] Useful flags to enable with -Wall or -Wextra

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Eric Gallager from comment #8)
> Any reason not to put -Wnested-externs in -Wall or -Wextra?

It warns for any "extern" declaration in other than file scope.  This is
completely standard C, and useful as well.

It is harmful to warn about idiomatic code, especially if there is no real
alternative.

I don't think anyone will accidentally do this either (you don't type "extern"
if you don't mean it, after all).

Do you have any example where this warning helped you find a bug?

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #10 from Xi Ruoyao  ---
Fixed in trunk.

I'm not sure if this should be backported.

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #8 from Aldy Hernandez  ---
Created attachment 51789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51789=edit
similar problem on aarch64 kernel

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
This looks like a ranger proper issue, as the strlen pass is just a simple
client, not a crazy ass abuser like the threader passes :).

Jeff reported pretty much an identical backtrace while building the aarch64
kernel.

Andrew, this testcase may save you the hassle of dealing with an aarch64 cross.

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #6 from Zhendong Su  ---
(In reply to Martin Liška from comment #5)
> Simplified test-case:

Oh, great; thanks, Martin!

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #5 from Martin Liška  ---
Simplified test-case:

cat pr103231.c
void BHbHb2l_1912();

int a;
int bs;
long g_1496_BK8K8el_2738;
long fn1_l_1522;
int fn1_l_1708;
int fn1_l_2085;
int fn1_l_2664;
int fn1_bv;
int fn1_l_2354;
int fn1_l_2188;
long fn1_bx;
int fn1_BHbHb1l_2637;
long fn1_l_2756;
void fn1() {
  long l_1761;
  unsigned l_1552, l_1810, l_1812, bw;
  int l_2189, by, l_2688;
  short l_1852;
  short l_1912;
  short l_2108;
  short l_2126;
  short l_2352;
  unsigned l_2456;
LABEL_5959g:
  __builtin_printf("l_2456=%llu\n", l_2456);
  if (l_1812)
  ca:
if (a) goto LABEL_IbIbjc;
  if (fn1_l_2188) {
if (fn1_l_2756 && fn1_l_2188 <= 7)
LABEL_TaTak:
  if (l_2352) goto LABEL_6969u;
if (by) {
LABEL_6969u:
  if (l_2189)
;
  if (l_1912) goto LABEL_5959g;
n:
  int BK8K8hl_2189 = l_2352 * (~l_1852 & g_1496_BK8K8el_2738);
  if (l_2126) {
int Bpl_2365 =
fn1_bx / ~(l_1552 || fn1_l_2354 % l_2108 & fn1_l_2664);
if (fn1_l_2354) bw = Bpl_2365 || l_1912;
short dg = ~(l_2456 & l_1761),
  dh = (l_1912 & by | fn1_l_2756) * BK8K8hl_2189 | dg;
if (bs) {
  l_1912 = dh * dg;
  if (l_1810) {
if (fn1_l_2085) goto LABEL_m9m9J;
goto q;
  }
}
l_2456 = dh;
if (fn1_l_1522) goto n;
l_1761 = ~BK8K8hl_2189;
long dl = l_1761 ^ (l_2108 | bw ^ ~fn1_l_2354);
  t:
l_2108 = (l_2108 && l_1812 && l_2126) - ~0;
int w = -~0 ^ -l_1552 * ((dl || by) >> fn1_l_2188);
l_1552 = w;
if (fn1_l_1522) {
  int x = l_2688 | fn1_l_1708 & l_1552;
  short BHbHbZg_5 = (l_1810 | a) & l_1852;
  if (a)
  y:
l_2688 = -(fn1_l_1522 & (x ^ BHbHbZg_5));
  l_1810 = x;
  BHbHb2l_1912(fn1_l_1522 && fn1_l_2188 && fn1_BHbHb1l_2637);
}
if (0)
  ;
if (l_1812) goto ca;
  }
  short Bm9m9El_1852 = ~(~0 && l_2688);
  unsigned Bm9m9Fl_1522 = -Bm9m9El_1852;
  if (l_1812)
  LABEL_m9m9J:
l_1852 = ~fn1_l_2664 ^ Bm9m9Fl_1522;
  long B97976l_1761 = ~fn1_bv ^ (l_1552 && l_2108);
  if (fn1_bv)
  q:
l_2126 = ~(B97976l_1761 ^ a) / fn1_l_2354 / l_1761;
  if (by) goto LABEL_TaTak;
  if (l_1810) goto y;
  goto t;
}
  }
LABEL_IbIbjc:
}

one needs ulimit -s 4096 in order to reproduce it.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez  ---
I can't opine on the intricacies of the loopch pass, but the decision the path
solver took was correct:

./cc1 a.c -fdump-tree-all-details -quiet -I/tmp -O2 --param threader-debug=all

Then in the *.ch2 dump file I see:

==
path_range_query: compute_ranges for path: 5->12
range_defined_in_block (BB12) for h_8 is int [0, 0]

=== BB 5 
b.0_3   int [0, 0][5, +INF]
 [local count: 60236916]:
e = 1;
goto ; [100.00%]


=== BB 12 
Imports: h_8  
Exports: h_8  
b.0_3   int [0, 0][5, +INF]
 [local count: 602369155]:
# h_8 = PHI <0(5), h_11(11)>
if (h_8 != 9)
  goto ; [90.00%]
else
  goto ; [10.00%]

etc.

The conditional in BB12 resolves to true:

   loopch static returned: _Bool [1, 1]

Which I got from a small tweak to the ch source:

diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c
index 566cc275317..d5d80e33450 100644
--- a/gcc/tree-ssa-loop-ch.c
+++ b/gcc/tree-ssa-loop-ch.c
@@ -74,7 +74,14 @@ entry_loop_condition_is_static (class loop *l,
path_range_query *query)
   int_range<2> r;
   query->compute_ranges (e);
   query->range_of_stmt (r, last);
-  return r == int_range<2> (desired_static_value, desired_static_value);
+  bool ret = (r == int_range<2> (desired_static_value, desired_static_value));
+  if (ret && dump_file)
+{
+fprintf (dump_file, "loopch static returned: ");
+r.dump(dump_file);
+fprintf (dump_file, "\n");
+}
+  return ret;
 }

[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c

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

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

--- Comment #4 from Martin Liška  ---
Started with r12-5014-g6b8b959675a3e14c.

[Bug tree-optimization/103231] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-11-14
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
I can reproduce it with ulimit -s 4096, having ulimit -s 8192 works.
BT is following:

#0  gimple_ranger::range_of_stmt (this=0x2ceda20, r=..., s=0x772e9800,
name=0x772ea1b0) at /home/marxin/Programming/gcc/gcc/gimple-range.cc:259
#1  0x01bc1045 in gimple_ranger::range_on_entry (this=0x2ceda20, r=...,
bb=0x7766db60, name=0x772ea1b0) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:141
#2  0x01bc1b91 in gimple_ranger::range_of_expr (this=0x2ceda20, r=...,
expr=0x772ea1b0, stmt=) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:118
#3  0x01bc128c in gimple_ranger::range_on_exit (this=0x2ceda20, r=...,
bb=0x7766db60, name=0x772ea1b0) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:178
#4  0x01bc1eee in gimple_ranger::range_on_edge (this=0x2ceda20, r=...,
e=, name=0x772ea1b0) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:222
#5  0x01bc8818 in fur_stmt::get_phi_operand (this=,
r=..., expr=0x772ea1b0, e=0x777802d0) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:167
#6  0x01bca5cf in fold_using_range::range_of_phi (this=0x7fc034ef,
r=..., phi=0x772e9a00, src=...) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:789
#7  0x01bccea1 in fold_using_range::fold_stmt (this=0x7fc034ef,
r=..., s=0x772e9a00, src=..., name=0x772ea240) at
/home/marxin/Programming/gcc/gcc/gimple-range-fold.cc:554
#8  0x01bc1457 in gimple_ranger::fold_range_internal
(this=this@entry=0x2ceda20, r=..., s=s@entry=0x772e9a00,
name=name@entry=0x772ea240) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:243
#9  0x01bc1707 in gimple_ranger::range_of_stmt (this=0x2ceda20, r=...,
s=0x772e9a00, name=0x772ea240) at
/home/marxin/Programming/gcc/gcc/gimple-range.cc:296

[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #22 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/103231] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |12.0
   Keywords||ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
You might want to try adding "--param ggc-min-expand=1 --param
ggc-min-heapsize=1", it might cause the ICE to be come deterministic.
There are a few other options including running cc1 under valgrind too.

[Bug tree-optimization/103231] ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
> [659] % 
> [659] % gcctk -O0 -w small.c
> [660] % 
> [660] % gcctk -O1 -w small.c
> [661] % gcctk -O1 -w small.c
> [662] % gcctk -O1 -w small.c
> gcctk: internal compiler error: Segmentation fault signal terminated program
> cc1
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
Backtrace here would be useful.  It is bit strange that you did not get
it from error message.  One can use -S -wrapper gdb,--args to make the
cc1 executed within gdb.
> [663] %

Re: [Bug tree-optimization/103231] New: ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

[Jan Hubicka via Gcc-bugs]

> [659] % 
> [659] % gcctk -O0 -w small.c
> [660] % 
> [660] % gcctk -O1 -w small.c
> [661] % gcctk -O1 -w small.c
> [662] % gcctk -O1 -w small.c
> gcctk: internal compiler error: Segmentation fault signal terminated program
> cc1
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
Backtrace here would be useful.  It is bit strange that you did not get
it from error message.  One can use -S -wrapper gdb,--args to make the
cc1 executed within gdb.
> [663] %

[Bug tree-optimization/103231] New: ICE (nondeterministic) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

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

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

Bug ID: 103231
   Summary: ICE (nondeterministic) on valid code at -O1 on
x86_64-linux-gnu: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Created attachment 51788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51788=edit
reproducer

This one is flaky and very difficult to reduce (likely due to memory errors).
The reproducer is still quite large and hairy.

[658] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211114 (experimental) [master r12-5239-ga8029add306] (GCC) 
[659] % 
[659] % gcctk -O0 -w small.c
[660] % 
[660] % gcctk -O1 -w small.c
[661] % gcctk -O1 -w small.c
[662] % gcctk -O1 -w small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[663] %

[Bug tree-optimization/103229] gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to Aldy Hernandez from comment #1)
> Untested, but if someone wants to test and commit, feel free.

Nevermind, I'll pass it through the gauntlet and commit.

[Bug tree-optimization/103219] [12 Regression] ICE Segmentation fault at -O3 (during GIMPLE pass: unrolljam) since r12-4526-gd8edfadfc7a9795b

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

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Aldy Hernandez  ---
Looks like a latent bug elsewhere as we're not threading anything.  For that
matter, test fails even with -fno-thread-jumps.

$ ./cc1 a.c -O3 -fno-thread-jumps -quiet -w
during GIMPLE pass: unrolljam
a.c: In function ‘main’:
a.c:3:5: internal compiler error: Segmentation fault
3 | int main() {
  | ^~~~
0x133a4fb crash_signal


Seems like tree_loop_unroll_and_jam is dereferencing a null return from
single_dom_exit():

  auto_bitmap exit_bbs;
  bitmap_set_bit (exit_bbs, single_dom_exit (outer)->dest->index);
  todo |= do_rpo_vn (cfun, loop_preheader_edge (outer), exit_bbs);

(gdb) p debug(outer)
loop_1 (header = 9, latch = 26, niter = )
$6 = void
(gdb) p single_dom_exit (outer)
$7 = 

[Bug tree-optimization/103229] gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

--- Comment #1 from Aldy Hernandez  ---
Untested, but if someone wants to test and commit, feel free.

diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index a63e20e7e49..b347edeb474 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -651,7 +651,8 @@ ssa_global_cache::clear_global_range (tree name)
 void
 ssa_global_cache::clear ()
 {
-  memset (m_tab.address(), 0, m_tab.length () * sizeof (irange *));
+  if (m_tab.address ())
+memset (m_tab.address(), 0, m_tab.length () * sizeof (irange *));
 }

 // Dump the contents of the global cache to F.

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

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

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

--- Comment #5 from Martin Liška  ---
The canonical approach would be using config/bootstrap-ubsan.mk config file.

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

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

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

--- Comment #4 from Martin Liška  ---
(In reply to hubicka from comment #3)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103230
> > 
> > --- Comment #2 from Martin Liška  ---
> > > How do you build ubsan compiler?
> > 
> > F="-O0 -g -fsanitize=undefined" ; make -j16 all-host -k CFLAGS="$F"
> > CXXFLAGS="$F"  LDFLAGS="$F"
> > 
> > is the fastest approach.
> Thanks, it is similar to what I tried.  I guess there should be no ";"
> but yet it leds to misconfigured libiberty for me on kunlun.  I will
> look into that.

Note that kunlun may have an old system GCC compiler.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #28 from Jan Hubicka  ---
Bit unrelated but shows that threader seems bit expensive on other builds too.
Getting stats from cc1plus LTO-link with -flto-partition=one it seems that
backwards threader and dom are two slowest tree passes.

We get
 - 1% of build time for CCP, forward propagate, slp vectrization 
 - 2% of build time for cfgcleanup, VRP, PTA, PRE, FRE
 - 3% of build time for dominator optimization
 - 4% of build time for backwards jump threading

For RTL we get
 - 1% of buid time for fwprop, dse1, dse2, loop init, CPROP, CSE2, LRA live
ranges
 - 2% of build time for CSE, PRE, combiner, LRA non-specific, reload CSE, 
 - 3% for combiner
 - 4% for IRA and scheduler

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 2301k (  0%)
 phase opt and generate :1312.92 ( 98%)  70.40 ( 97%)1386.30 ( 98%)
26038M ( 97%)
 phase last asm :  27.07 (  2%)   1.63 (  2%)  28.77 (  2%)
  376M (  1%)
 phase stream in:   0.96 (  0%)   0.32 (  0%)   1.29 (  0%)
  464M (  2%)
 phase finalize :   3.64 (  0%)   0.47 (  1%)   4.12 (  0%)
0  (  0%)
 garbage collection :  27.45 (  2%)   0.04 (  0%)  27.54 (  2%)
0  (  0%)
 dump files :   3.53 (  0%)   0.35 (  0%)   4.37 (  0%)
0  (  0%)
 callgraph functions expansion  :1311.82 ( 98%)  70.34 ( 97%)1385.15 ( 98%)
26022M ( 97%)
 callgraph ipa passes   :   0.18 (  0%)   0.00 (  0%)   0.18 (  0%)
0  (  0%)
 ipa dead code removal  :   0.35 (  0%)   0.01 (  0%)   0.37 (  0%)
0  (  0%)
 ipa virtual call target:   0.02 (  0%)   0.00 (  0%)   0.02 (  0%)
  272  (  0%)
 ipa cp :   0.12 (  0%)   0.01 (  0%)   0.16 (  0%)
   49M (  0%)
 ipa inlining heuristics:   9.04 (  1%)   0.98 (  1%)   9.75 (  1%)
  402M (  1%)
 lto stream decompression   :   1.66 (  0%)   0.17 (  0%)   1.60 (  0%)
0  (  0%)
 ipa lto gimple in  :  36.64 (  3%)   3.55 (  5%)  40.05 (  3%)
 3138M ( 12%)
 ipa lto decl in:   0.39 (  0%)   0.21 (  0%)   0.61 (  0%)
  137M (  1%)
 ipa lto constructors in:   0.45 (  0%)   0.05 (  0%)   0.45 (  0%)
   60M (  0%)
 ipa lto cgraph I/O :   0.36 (  0%)   0.09 (  0%)   0.44 (  0%)
  274M (  1%)
 ipa reference  :   0.00 (  0%)   0.01 (  0%)   0.00 (  0%)
0  (  0%)
 ipa pure const :   0.51 (  0%)   0.06 (  0%)   0.65 (  0%)
  342k (  0%)
 ipa modref :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 4272k (  0%)
 cfg construction   :   0.84 (  0%)   0.03 (  0%)   0.87 (  0%)
   86M (  0%)
 cfg cleanup:  26.67 (  2%)   0.53 (  1%)  28.48 (  2%)
  199M (  1%)
 trivially dead code:   8.90 (  1%)   0.36 (  0%)   9.26 (  1%)
  166k (  0%)
 df scan insns  :   5.46 (  0%)   0.23 (  0%)   5.41 (  0%)
 1498k (  0%)
 df reaching defs   :  13.04 (  1%)   0.17 (  0%)  12.73 (  1%)
0  (  0%)
 df live regs   :  48.91 (  4%)   0.75 (  1%)  49.22 (  3%)
   14M (  0%)
 df live regs   :  20.46 (  2%)   0.33 (  0%)  20.80 (  1%)
0  (  0%)
 df must-initialized regs   :   1.05 (  0%)   0.01 (  0%)   1.00 (  0%)
0  (  0%)
 df use-def / def-use chains:   5.91 (  0%)   0.08 (  0%)   6.25 (  0%)
0  (  0%)
 df live reg subwords   :   0.00 (  0%)   0.00 (  0%)   0.05 (  0%)
0  (  0%)
 df reg dead/unused notes   :  18.21 (  1%)   0.24 (  0%)  18.56 (  1%)
  223M (  1%)
 register information   :   4.60 (  0%)   0.08 (  0%)   4.21 (  0%)
0  (  0%)
 alias analysis :  19.76 (  1%)   0.28 (  0%)  19.63 (  1%)
  478M (  2%)
 alias stmt walking :  29.06 (  2%)   2.30 (  3%)  30.32 (  2%)
   65M (  0%)
 register scan  :   2.12 (  0%)   0.06 (  0%)   2.50 (  0%)
   20M (  0%)
 rebuild jump labels:   2.65 (  0%)   0.05 (  0%)   2.86 (  0%)
  576  (  0%)
 integration:  35.83 (  3%)   6.81 (  9%)  41.90 (  3%)
 2650M ( 10%)
 tree CFG cleanup   :  21.87 (  2%)   2.23 (  3%)  24.72 (  2%)
   35M (  0%)
 tree tail merge:   3.02 (  0%)   0.18 (  0%)   3.04 (  0%)
  132M (  0%)
 tree VRP   :  29.83 (  2%)   1.92 (  3%)  32.77 (  2%)
  354M (  1%)
 tree copy propagation  :   5.06 (  0%)   0.36 (  0%)   4.95 (  0%)
 6205k (  0%)
 tree PTA   :  22.85 (  2%)   1.54 (  2%)  24.96 (  2%)
  107M (  0%)
 tree SSA incremental   :  35.53 (  3%)   1.74 (  2%)  36.94 (  3%)
  381M (  1%)
 tree operand scan   

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #3 from hubicka at kam dot mff.cuni.cz ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103230
> 
> --- Comment #2 from Martin Liška  ---
> > How do you build ubsan compiler?
> 
> F="-O0 -g -fsanitize=undefined" ; make -j16 all-host -k CFLAGS="$F"
> CXXFLAGS="$F"  LDFLAGS="$F"
> 
> is the fastest approach.
Thanks, it is similar to what I tried.  I guess there should be no ";"
but yet it leds to misconfigured libiberty for me on kunlun.  I will
look into that.

Re: [Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

[Jan Hubicka via Gcc-bugs]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103230
> 
> --- Comment #2 from Martin Liška  ---
> > How do you build ubsan compiler?
> 
> F="-O0 -g -fsanitize=undefined" ; make -j16 all-host -k CFLAGS="$F"
> CXXFLAGS="$F"  LDFLAGS="$F"
> 
> is the fastest approach.
Thanks, it is similar to what I tried.  I guess there should be no ";"
but yet it leds to misconfigured libiberty for me on kunlun.  I will
look into that.

[Bug libfortran/95177] error: array subscript has type char

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #15 from Roland Illig  ---
(In reply to Steve Kargl from comment #9)
> I'm still trying to understand how an
> option names -Werror=char-subscripts could trigger an
> error.  There are no subscripts.

There _are_ subscripts, just look at the precompiled C translation unit.

$ printf '%s\n' '#include ' 'isspace(ch)' | gcc -E -

On Cygwin, the output ends with:

__locale_ctype_ptr ()) + sizeof(""[ch]))[(int)(ch)])&010)

The expression `sizeof(""[ch])` has two purposes. The first is to add 1 to the
array index (since EOF is -1 in that implementation), the second is to trigger
the GCC diagnostic, to prevent the undefined behavior. That's why all C
programmers who know the  functions cast the argument from `char` to
`unsigned char`, to be absolutely sure that there is no undefined behavior, no
matter what value the argument has.

On NetBSD, the pattern is similar:

((int)((_ctype_tab_ + 1)[(ch)] & 0x0040))

Here, the argument is directly used as an array subscript, without casting it
first, with the same effect of triggering the GCC diagnostic.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||sandra at codesourcery dot com

--- Comment #15 from Thomas Koenig  ---
One possibility would be to extend the patch Sandra posted at
https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html
to scalarization.  With the patch,

the snippet

   integer :: i,j
   integer :: a(4, 4)
   do j=1,size(a,2)
 do i=1,size(a,1)
   a(i,j) = 0
 end do
   end do

is translated to

  while (1)
{
  {
logical(kind=4) D.4265;

D.4265 = j > 4;
if (D.4265) goto L.4;
i = 1;
while (1)
  {
{
  logical(kind=4) D.4268;

  D.4268 = i > 4;
  if (D.4268) goto L.6;
typedef integer(kind=4) [1:4];
typedef integer(kind=4) [1:4][1:4];
  ((integer(kind=4)[1:4][1:4]) a)[(integer(kind=8)) j]{lb: 1 sz:
16}[(integer(kind=8)) i]{lb: 1 sz: 4} = 0;
  L.5:;
  i = i + 1;
}
  }
L.6:;
L.3:;
j = j + 1;
  }
}

which looks good.

[Bug fortran/102043] Wrong array types used for negative stride accesses

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

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

--- Comment #14 from Mikael Morin  ---
Created attachment 51787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51787=edit
draft patch

This "fixes" the problem of negative index access, and adjusts vector subscript
handling, so that correct code is produced for comment #1.
It seems to break comment #13 even more, for reasons that I don’t see (yet).

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

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

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

--- Comment #2 from Martin Liška  ---
> How do you build ubsan compiler?

F="-O0 -g -fsanitize=undefined" ; make -j16 all-host -k CFLAGS="$F"
CXXFLAGS="$F"  LDFLAGS="$F"

is the fastest approach.

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #1 from hubicka at kam dot mff.cuni.cz ---
> Happens with UBSAN compiler for:
> 
> $ gcc gcc/testsuite/gcc.c-torture/execute/pr71494.c -O1  -flto
> ...
> /home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550:33: runtime error: load
> of value 255, which is not a valid value for type 'bool'
> #0 0x18acc38 in modref_tree::merge(modref_tree*,
> vec*, modref_parm_map*, bool)
> /home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550
> #1 0x188452c in modref_propagate_in_scc

At 4385 I have:
   changed |= cur_summary_lto->stores->merge
(callee_summary_lto->stores, _map, _map, !first);

parm-map is the vector, however there is no read of it.
There is bool which is relevant only when parm_index is not unknown, so
I suspect it may a full copy with uninitialized bool which would be
harmless. We had similar issues with asan before.

How do you build ubsan compiler?
Honza

Re: [Bug ipa/103230] New: ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

[Jan Hubicka via Gcc-bugs]

> Happens with UBSAN compiler for:
> 
> $ gcc gcc/testsuite/gcc.c-torture/execute/pr71494.c -O1  -flto
> ...
> /home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550:33: runtime error: load
> of value 255, which is not a valid value for type 'bool'
> #0 0x18acc38 in modref_tree::merge(modref_tree*,
> vec*, modref_parm_map*, bool)
> /home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550
> #1 0x188452c in modref_propagate_in_scc

At 4385 I have:
   changed |= cur_summary_lto->stores->merge
(callee_summary_lto->stores, _map, _map, !first);
 

parm-map is the vector, however there is no read of it.
There is bool which is relevant only when parm_index is not unknown, so
I suspect it may a full copy with uninitialized bool which would be
harmless. We had similar issues with asan before.

How do you build ubsan compiler?
Honza

[Bug ipa/103230] ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||12.0
   Priority|P3  |P1
   Last reconfirmed||2021-11-14
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW

[Bug ipa/103230] New: ipa-modref-tree.h:550:33: runtime error: load of value 255, which is not a valid value for type 'bool'

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

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

Bug ID: 103230
   Summary: ipa-modref-tree.h:550:33: runtime error: load of value
255, which is not a valid value for type 'bool'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Happens with UBSAN compiler for:

$ gcc gcc/testsuite/gcc.c-torture/execute/pr71494.c -O1  -flto
...
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550:33: runtime error: load
of value 255, which is not a valid value for type 'bool'
#0 0x18acc38 in modref_tree::merge(modref_tree*,
vec*, modref_parm_map*, bool)
/home/marxin/Programming/gcc/gcc/ipa-modref-tree.h:550
#1 0x188452c in modref_propagate_in_scc
/home/marxin/Programming/gcc/gcc/ipa-modref.c:4385
#2 0x188a2b7 in execute /home/marxin/Programming/gcc/gcc/ipa-modref.c:4932
#3 0x1f513bc in execute_one_pass(opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2567
#4 0x1f54a44 in execute_ipa_pass_list(opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2996
#5 0xb3bd3c in do_whole_program_analysis
/home/marxin/Programming/gcc/gcc/lto/lto.c:469
#6 0xb3c538 in lto_main() /home/marxin/Programming/gcc/gcc/lto/lto.c:637
#7 0x2417b3b in compile_file /home/marxin/Programming/gcc/gcc/toplev.c:452
#8 0x2422188 in do_compile /home/marxin/Programming/gcc/gcc/toplev.c:2156
#9 0x2422c03 in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.c:2308
#10 0x6edfd90 in main /home/marxin/Programming/gcc/gcc/main.c:39
#11 0x76f1453f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#12 0x76f145eb in __libc_start_main_impl ../csu/libc-start.c:409
#13 0xaa3b74 in _start (/dev/shm/objdir2/gcc/lto1+0xaa3b74)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug tree-optimization/103229] gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||12.0
   Last reconfirmed||2021-11-14
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Priority|P3  |P1

[Bug tree-optimization/103229] New: gcc/gimple-range-cache.cc:654:10: runtime error: null pointer passed as argument 1, which is declared to never be null

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

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

Bug ID: 103229
   Summary: gcc/gimple-range-cache.cc:654:10: runtime error: null
pointer passed as argument 1, which is declared to
never be null
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, amacleod at redhat dot com
Blocks: 63426
  Target Milestone: ---

One can see the following UBSAN error:

$ cat memset.c
int main() {
  int i;
  for (; i;)
;

  return 0;
}

$ /dev/shm/objdir2/gcc/xgcc -B/dev/shm/objdir2/gcc/ memset.c -O
/home/marxin/Programming/gcc/gcc/gimple-range-cache.cc:654:10: runtime error:
null pointer passed as argument 1, which is declared to never be null
#0 0x6a9cec7 in ssa_global_cache::clear()
/home/marxin/Programming/gcc/gcc/gimple-range-cache.cc:654
#1 0x2e270ee in path_range_query::compute_ranges_in_phis(basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:359
#2 0x2e2796e in path_range_query::compute_ranges_in_block(basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:404
#3 0x2e29c62 in path_range_query::compute_ranges(vec const&, bitmap_head const*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:603
#4 0x303814e in back_threader::find_taken_edge_cond(vec const&, gcond*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:315
#5 0x3037a9d in back_threader::find_taken_edge(vec const&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:272
#6 0x3037356 in back_threader::maybe_register_path()
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:228
#7 0x30393b9 in back_threader::find_paths_to_names(basic_block_def*,
bitmap_head*) /home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:415
#8 0x3039927 in back_threader::find_paths_to_names(basic_block_def*,
bitmap_head*) /home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:455
#9 0x3039fbf in back_threader::find_paths(basic_block_def*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:489
#10 0x303a138 in back_threader::maybe_thread_block(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:534
#11 0x303c5f6 in back_threader::thread_blocks()
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:897
#12 0x303cb83 in execute
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.c:971
#13 0x22f94dc in execute_one_pass(opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2567
#14 0x22f9fd8 in execute_pass_list_1
/home/marxin/Programming/gcc/gcc/passes.c:2656
#15 0x22fa0a1 in execute_pass_list_1
/home/marxin/Programming/gcc/gcc/passes.c:2657
#16 0x22fa15b in execute_pass_list(function*, opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:2667
#17 0x22f375b in do_per_function_toporder(void (*)(function*, void*),
void*) /home/marxin/Programming/gcc/gcc/passes.c:1773
#18 0x22fccec in execute_ipa_pass_list(opt_pass*)
/home/marxin/Programming/gcc/gcc/passes.c:3001
#19 0x1263839 in ipa_passes
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2154
#20 0x1264914 in symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2289
#21 0x12659a8 in symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2537
#22 0x27e2c6d in compile_file /home/marxin/Programming/gcc/gcc/toplev.c:479
#23 0x27ed0de in do_compile /home/marxin/Programming/gcc/gcc/toplev.c:2156
#24 0x27edb59 in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.c:2308
#25 0x72610e3 in main /home/marxin/Programming/gcc/gcc/main.c:39
#26 0x76f1453f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#27 0x76f145eb in __libc_start_main_impl ../csu/libc-start.c:409
#28 0xaf8ec4 in _start (/dev/shm/objdir2/gcc/cc1+0xaf8ec4)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined