[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Biener from comment #1)
> > 
> > void bar ();
> > void foo (int *a)
> > {
> >   int qa = 0;
> >   for (int i = 0; i < 3; i++)
> > if (a[i])
> >   a[qa++] = 0;
> >   if (qa > 3)
> > bar ();
> > }
> > 
> > where we should be able to eliminate the call to bar ().
> 
> What is interesting is we can optimize away the call to bar in this slightly
> modified case during vrp2:
> void bar ();
> bool cond;
> void foo (int *a)
> {
>   int qa = 0;
>   for (int i = 0; i < 3; i++)
> if (cond)
>   a[qa++] = 0;
>   if (qa > 3)
> bar ();
> }
> 
> But I don't see why having the load inside the loop would make a difference
> 

It's because we can jump-thread the invariant condition.  The most
canonical testcase would be sth like

int foo (int *a)
{
  int qa = 0;
  for (int i = 0; i < 3; i++)
if (a[i++])
  qa++;
  if (qa < 0 || qa > 3)
bar ();
  return qa;
}

[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #3 from Richard Biener  ---
Note the old VRP was able to at least tell that qa was [0, +INF] by means of
iterating and saturating to +INF after too many iterations.  SCEV isn't of
help here.  Since we've lost the last lattice-based (iterating) VRP pass now
what's the plan for cases like this?

[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> 
> void bar ();
> void foo (int *a)
> {
>   int qa = 0;
>   for (int i = 0; i < 3; i++)
> if (a[i])
>   a[qa++] = 0;
>   if (qa > 3)
> bar ();
> }
> 
> where we should be able to eliminate the call to bar ().

What is interesting is we can optimize away the call to bar in this slightly
modified case during vrp2:
void bar ();
bool cond;
void foo (int *a)
{
  int qa = 0;
  for (int i = 0; i < 3; i++)
if (cond)
  a[qa++] = 0;
  if (qa > 3)
bar ();
}

But I don't see why having the load inside the loop would make a difference

[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||85316
 CC||aldyh at gcc dot gnu.org
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
One of the reasons we diagnose this is that we fail to compute a range
for 'qa_7'.  Before the VRP pass that diagnoses the -Warray-bounds violation we
have

   [local count: 1073741824]:
  # qa_7 = PHI <0(2), qa_6(5)>
  # RANGE [irange] int [0, 3] NONZERO 0x3
  # i_8 = PHI <0(2), i_16(5)>
  if (i_8 != 3)
goto ; [75.00%]
  else
goto ; [25.00%]

   [local count: 268435456]:
  # RANGE [irange] long unsigned int [0, 2147483647][18446744071562067968,
+INF]
  _3 = (long unsigned int) qa_7;
  # RANGE [irange] long unsigned int [0, 8589934588][18446744065119617024,
18446744073709551612] NONZERO 0xfffc
  _4 = _3 * 4;
  # PT = { D.18799 } (escaped)
  # ALIGN = 4, MISALIGN = 0
  _5 =  + _4;
  if ( != _5)
goto ; [53.47%]
  else
goto ; [46.53%]

   [local count: 143532440]:
  _11 = (signed long) _4;
  # RANGE [irange] long int [-2305843009213693952, 2305843009213693951]
  _20 = _11 /[ex] 4;
  # RANGE [irange] long unsigned int [0,
2305843009213693951][16140901064495857664, +INF]
  __n.3_21 = (long unsigned int) _20;
  # RANGE [irange] int [0, 63] NONZERO 0x3f
  _22 = __builtin_clzl (__n.3_21);
  # RANGE [irange] int [0, 63] NONZERO 0x3f
  _23 = 63 - _22;
  # RANGE [irange] long int [0, 63] NONZERO 0x3f
  _24 = (long int) _23;
  # RANGE [irange] long int [0, 126] NONZERO 0x7e
  _25 = _24 * 2;
  # USE = nonlocal escaped null { D.18799 } (escaped)
  # CLB = nonlocal escaped null { D.18799 } (escaped)
  std::__introsort_loop.isra (, _5, _25);
  if (_11 > 64)
goto ; [50.00%]
  else
goto ; [50.00%]

and we fail to eliminate this last conditional.  We also fail to
eliminate the (long)(((unsigned long)qa_37) * 4) /[ex] 4 round-trip
(because of possible overflow).

So even proving qa_7 is [0, +INF] would help a bit (not the diagnostic),
realizing qa_7 is [0, 3] like i_8 would be even better.  A testcase
for this could look like

void bar ();
void foo (int *a)
{
  int qa = 0;
  for (int i = 0; i < 3; i++)
if (a[i])
  a[qa++] = 0;
  if (qa > 3)
bar ();
}

where we should be able to eliminate the call to bar ().


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

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

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

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

--- Comment #8 from Richard Biener  ---
I have opened PR107986 for the testcase in comment#2 which isn't yet fixed on
trunk.

[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-06
  Known to fail||12.2.0, 13.0
 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.3
 Blocks||56456
  Known to work||11.3.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/107986] New: [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

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

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

Bug ID: 107986
   Summary: [12/13 Regression] Bogus -Warray-bounds diagnostic
with std::sort
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

PR104165 comment 2 talks about a test case reduced in
https://bugzilla.redhat.com/show_bug.cgi?id=2051783:

#include 

bool cond;
int foo;

int func (void)
{
  int a[3], qa = 0;
  for(int i = 0; i < 3; i++)
if (cond)
  a[qa++] = foo;

  std::sort (a, a + qa);
  return 0;
}

which still warns with both GCC 12 and 13 at -O2 -Wall like

In file included from
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/algorithm:61,
 from t.C:1:
In function 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]',
inlined from 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/bits/stl_algo.h:1854:5,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/bits/stl_algo.h:1950:31,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/bits/stl_algo.h:1942:5,
inlined from 'void std::sort(_RAIter, _RAIter) [with _RAIter = int*]' at
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/bits/stl_algo.h:4860:1,
inlined from 'int func()' at t.C:13:13:
/home/rguenther/install/gcc-13/usr/local/include/c++/13.0.0/bits/stl_algo.h:1859:32:
warning: array subscript 16 is outside array bounds of 'int [3]'
[-Warray-bounds=]
 1859 |   std::__insertion_sort(__first, __first + int(_S_threshold),
__comp);
  |  
~^~
t.C: In function 'int func()':
t.C:8:7: note: at offset 64 into object 'a' of size 12
8 |   int a[3], qa = 0;
  |   ^

I'll also note the lack of a non-included location in t.C.

[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #1 from Andrew Pinski  ---
Most likely OFFSET_TYPE not being handled.

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

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

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

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

https://gcc.gnu.org/g:790ff87f675f28bce5e7e35918ae09c3ece4ec4d

commit r13-4499-g790ff87f675f28bce5e7e35918ae09c3ece4ec4d
Author: Richard Biener 
Date:   Tue Dec 6 08:22:01 2022 +0100

tree-optimization/104165 - bougs -Warray-bounds, add testcase

The following adds the testcase from the description which was
fixed by r13-2894-gbe4a6551ed37c1.

PR tree-optimization/104165
* g++.dg/warn/Warray-bounds-pr104165-1.C: New testcase.

[Bug tree-optimization/107985] New: [13 Regression] ICE in as_a, at value-range.h:393

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107985
   Summary: [13 Regression] ICE in as_a, at value-range.h:393
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221204 snapshot (g:24b9337d1f1b5197b6498dceb9074319be003449) ICEs
when compiling the following testcase, reduced from
test/Analysis/pointer-to-member.cpp from the clang 15 test suite, w/ -O1
-ftree-vrp -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre:

struct B {
  int f;
};

struct D : public B {
};

void foo() {
  D d;
  d.f = 7;

  int B::* pfb = ::f;
  int D::* pfd = pfb;
  int v = d.*pfd;
}

% g++-13 -O1 -ftree-vrp -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre -c
bq32p5di.cpp
during GIMPLE pass: evrp
bq32p5di.cpp: In function 'void foo()':
bq32p5di.cpp:15:1: internal compiler error: in as_a, at value-range.h:393
   15 | }
  | ^
0x92a7d7 irange const& as_a(vrange const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/value-range.h:393
0x92ac0c irange const& as_a(vrange const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/range-op.cc:4502
0x92ac0c range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/range-op.cc:4504
0x2009e48 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/gimple-range-fold.cc:565
0x200aba2 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/gimple-range-fold.cc:489
0x1ffab24 gimple_ranger::update_stmt(gimple*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/gimple-range.cc:550
0x1377644 update_stmt_operands(function*, gimple*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/tree-ssa-operands.cc:1150
0x1396aee update_stmt_if_modified
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/gimple-ssa.h:185
0x1396aee update_stmt_if_modified
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/gimple-ssa.h:182
0x1396aee substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/tree-ssa-propagate.cc:935
0x1fc734e dom_walker::walk(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/domwalk.cc:311
0x139576e substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/tree-ssa-propagate.cc:998
0x149fc57 execute_ranger_vrp(function*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/tree-vrp.cc:1084

[Bug target/107984] New: ICE: in verify_target_availability, at sel-sched.cc:1553 with -O2 -fselective-scheduling2 -mabi=ms -mavx512vl

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107984
   Summary: ICE: in verify_target_availability, at
sel-sched.cc:1553 with -O2 -fselective-scheduling2
-mabi=ms -mavx512vl
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fselective-scheduling2 -mabi=ms -mavx512vl
testcase.c 
testcase.c: In function 'foo0':
testcase.c:12:5: warning: division by zero [-Wdiv-by-zero]
   12 |   u %= 0;
  | ^~
during RTL pass: sched2
testcase.c:18:1: internal compiler error: in verify_target_availability, at
sel-sched.cc:1553
   18 | }
  | ^
0x786e04 verify_target_availability
/repo/gcc-trunk/gcc/sel-sched.cc:1553
0x786e04 find_best_reg_for_expr
/repo/gcc-trunk/gcc/sel-sched.cc:1667
0x786e04 fill_vec_av_set
/repo/gcc-trunk/gcc/sel-sched.cc:3784
0x13625c5 fill_ready_list
/repo/gcc-trunk/gcc/sel-sched.cc:4014
0x13625c5 find_best_expr
/repo/gcc-trunk/gcc/sel-sched.cc:4374
0x13625c5 fill_insns
/repo/gcc-trunk/gcc/sel-sched.cc:5535
0x13625c5 schedule_on_fences
/repo/gcc-trunk/gcc/sel-sched.cc:7353
0x13625c5 sel_sched_region_2
/repo/gcc-trunk/gcc/sel-sched.cc:7491
0x13649c6 sel_sched_region_1
/repo/gcc-trunk/gcc/sel-sched.cc:7533
0x136614c sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.cc:7634
0x136614c sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.cc:7619
0x13662c9 run_selective_scheduling()
/repo/gcc-trunk/gcc/sel-sched.cc:7720
0x1344b55 rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.cc:3743
0x1344b55 execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3890
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4497-20221206065114-g769370f3e2e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4497-20221206065114-g769370f3e2e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221206 (experimental) (GCC)

[Bug fortran/106576] Finalization of temporaries from functions not occuring

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

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

--- Comment #7 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #6)
>  
> > I hope that you are well and that the lack of time is for a good cause?
> 
> Hi Paul,
> 
> yes, I'm well, and the lack of time is indeed for a good cause :-)
> 
> > I have just returned to my finalizer patch. With it applied, your testcase
> > produces the same output as NAG.
> 
> That's great!
>  
> > I will attach the present version of the patch to this PR.
> 
> Is there a chance that we will see this patch in gcc13?  Even if it
> does not fix every last bug in finalizers in gfortran, it would still
> be a very large improvement compared to the current condition.

Hi Thomas,

It's good to hear from you. I hope to submit the patches before Christmas. I am
working on some final wrinkles and testcases. I am still intensely busy on the
daytime job, which is something of a blocker.

Regards

Paul

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

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Mine, let me fix it.

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

[caiyinyu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from caiyinyu  ---
Created attachment 54024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54024=edit
glibc tests build log and fails test result

build log: tmp-tst-math-2022-12-05.log
test results: test-xxx.out

[Bug target/107983] btf: bad call relo against 'test_task_acquire_release_current' in section 'tp_btf/task_newtask'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from James Hilliard  ---
Working LLVM btf dump:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next/tools/testing/selftests/bpf/task_kfunc_success.bpf.linked3.o
format raw
[1] PTR '(anon)' type_id=3
[2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[3] ARRAY '(anon)' type_id=2 index_type_id=4 nr_elems=1
[4] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[5] PTR '(anon)' type_id=2
[6] PTR '(anon)' type_id=7
[7] STRUCT '__tasks_kfunc_map_value' size=8 vlen=1
'task' type_id=8 bits_offset=0
[8] PTR '(anon)' type_id=16
[9] STRUCT 'hash_map' size=32 vlen=4
'type' type_id=1 bits_offset=0
'key' type_id=5 bits_offset=64
'value' type_id=6 bits_offset=128
'max_entries' type_id=1 bits_offset=192
[10] VAR '__tasks_kfunc_map' type_id=9, linkage=global
[11] PTR '(anon)' type_id=12
[12] INT 'unsigned long long' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[13] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=11
[14] FUNC 'test_task_acquire_release_argument' type_id=13 linkage=global
[15] FUNC_PROTO '(anon)' ret_type_id=8 vlen=1
'(anon)' type_id=8
[16] STRUCT 'task_struct' size=10048 vlen=253
'thread_info' type_id=17 bits_offset=0
'__state' type_id=21 bits_offset=192
'stack' type_id=22 bits_offset=256
'usage' type_id=23 bits_offset=320
'flags' type_id=21 bits_offset=352
'ptrace' type_id=21 bits_offset=384
'on_cpu' type_id=2 bits_offset=416
'wake_entry' type_id=27 bits_offset=448
'wakee_flips' type_id=21 bits_offset=576
'wakee_flip_decay_ts' type_id=18 bits_offset=640
'last_wakee' type_id=8 bits_offset=704
'recent_used_cpu' type_id=2 bits_offset=768
'wake_cpu' type_id=2 bits_offset=800
'on_rq' type_id=2 bits_offset=832
'prio' type_id=2 bits_offset=864
'static_prio' type_id=2 bits_offset=896
'normal_prio' type_id=2 bits_offset=928
'rt_priority' type_id=21 bits_offset=960
'se' type_id=34 bits_offset=1024
'rt' type_id=46 bits_offset=3072
'dl' type_id=48 bits_offset=3456
'sched_class' type_id=64 bits_offset=5248
'sched_task_group' type_id=66 bits_offset=5312
'stats' type_id=67 bits_offset=5632
'btrace_seq' type_id=21 bits_offset=7680
'policy' type_id=21 bits_offset=7712
'nr_cpus_allowed' type_id=2 bits_offset=7744
'cpus_ptr' type_id=68 bits_offset=7808
'user_cpus_ptr' type_id=71 bits_offset=7872
'cpus_mask' type_id=70 bits_offset=7936
'migration_pending' type_id=22 bits_offset=8064
'migration_disabled' type_id=33 bits_offset=8128
'migration_flags' type_id=33 bits_offset=8144
'rcu_read_lock_nesting' type_id=2 bits_offset=8160
'rcu_read_unlock_special' type_id=74 bits_offset=8192
'rcu_node_entry' type_id=38 bits_offset=8256
'rcu_blocked_node' type_id=76 bits_offset=8384
'rcu_tasks_nvcsw' type_id=18 bits_offset=8448
'rcu_tasks_holdout' type_id=60 bits_offset=8512
'rcu_tasks_idx' type_id=60 bits_offset=8520
'rcu_tasks_idle_cpu' type_id=2 bits_offset=8544
'rcu_tasks_holdout_list' type_id=38 bits_offset=8576
'trc_reader_nesting' type_id=2 bits_offset=8704
'trc_ipi_to_cpu' type_id=2 bits_offset=8736
'trc_reader_special' type_id=74 bits_offset=8768
'trc_holdout_list' type_id=38 bits_offset=8832
'trc_blkd_node' type_id=38 bits_offset=8960
'trc_blkd_cpu' type_id=2 bits_offset=9088
'sched_info' type_id=77 bits_offset=9152
'tasks' type_id=38 bits_offset=9408
'pushable_tasks' type_id=78 bits_offset=9536
'pushable_dl_tasks' type_id=36 bits_offset=9856
'mm' type_id=79 bits_offset=10048
'active_mm' type_id=79 bits_offset=10112
'rss_stat' type_id=80 bits_offset=10176
'exit_state' type_id=2 bits_offset=10336
'exit_code' type_id=2 bits_offset=10368
'exit_signal' type_id=2 bits_offset=10400
'pdeath_signal' type_id=2 bits_offset=10432
'jobctl' type_id=18 bits_offset=10496
'personality' type_id=21 bits_offset=10560
'sched_reset_on_fork' type_id=21 bits_offset=10592 bitfield_size=1
'sched_contributes_to_load' type_id=21 bits_offset=10593
bitfield_size=1
'sched_migrated' type_id=21 bits_offset=10594 bitfield_size=1
'sched_remote_wakeup' type_id=21 bits_offset=10624 bitfield_size=1
'in_execve' type_id=21 bits_offset=10625 bitfield_size=1
'in_iowait' type_id=21 bits_offset=10626 bitfield_size=1
'restore_sigmask' type_id=21 bits_offset=10627 bitfield_size=1
'in_user_fault' type_id=21 bits_offset=10628 bitfield_size=1
'brk_randomized' type_id=21 bits_offset=10629 

[Bug target/107983] New: btf: bad call relo against 'test_task_acquire_release_current' in section 'tp_btf/task_newtask'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

Bug ID: 107983
   Summary: btf: bad call relo against
'test_task_acquire_release_current' in section
'tp_btf/task_newtask'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james.hilliard1 at gmail dot com
  Target Milestone: ---

I'm seeing this failure in GCC which does not occur with LLVM:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/task_kfunc_success.bpf.linked3.o
name task_kfunc_success
libbpf: loading object 'task_kfunc_success' from buffer
libbpf: elf: section(2) .symtab, size 600, link 1, flags 0, type=2
libbpf: elf: section(3) .data, size 0, link 0, flags 3, type=1
libbpf: elf: skipping section(3) .data (size 0)
libbpf: elf: section(4) .bss, size 8, link 0, flags 3, type=8
libbpf: elf: section(5) tp_btf/task_newtask, size 2704, link 0, flags 6, type=1
libbpf: sec 'tp_btf/task_newtask': found program
'test_task_acquire_release_argument' at insn offset 0 (0 bytes), code size 13
insns (104 bytes)
libbpf: sec 'tp_btf/task_newtask': found program
'test_task_acquire_release_current' at insn offset 13 (104 bytes), code size 13
insns (104 bytes)
libbpf: sec 'tp_btf/task_newtask': found program
'test_task_acquire_leave_in_map' at insn offset 26 (208 bytes), code size 56
insns (448 bytes)
libbpf: sec 'tp_btf/task_newtask': found program 'test_task_xchg_release' at
insn offset 82 (656 bytes), code size 88 insns (704 bytes)
libbpf: sec 'tp_btf/task_newtask': found program 'test_task_get_release' at
insn offset 170 (1360 bytes), code size 86 insns (688 bytes)
libbpf: sec 'tp_btf/task_newtask': found program
'test_task_current_acquire_release' at insn offset 256 (2048 bytes), code size
3 insns (24 bytes)
libbpf: sec 'tp_btf/task_newtask': found program 'test_task_from_pid_arg' at
insn offset 259 (2072 bytes), code size 26 insns (208 bytes)
libbpf: sec 'tp_btf/task_newtask': found program 'test_task_from_pid_current'
at insn offset 285 (2280 bytes), code size 26 insns (208 bytes)
libbpf: sec 'tp_btf/task_newtask': found program 'test_task_from_pid_invalid'
at insn offset 311 (2488 bytes), code size 27 insns (216 bytes)
libbpf: elf: section(6) license, size 4, link 0, flags 3, type=1
libbpf: license of task_kfunc_success is GPL
libbpf: elf: section(7) .maps, size 32, link 0, flags 3, type=1
libbpf: elf: section(8) .comment, size 43, link 0, flags 30, type=1
libbpf: elf: skipping unrecognized data section(8) .comment
libbpf: elf: section(9) .reltp_btf/task_newtask, size 864, link 2, flags 40,
type=9
libbpf: elf: section(10) .BTF, size 469313, link 0, flags 0, type=1
libbpf: looking for externs among 25 symbols...
libbpf: collected 4 externs total
libbpf: extern (ksym) #0: symbol 10, name bpf_task_acquire
libbpf: extern (ksym) #1: symbol 21, name bpf_task_from_pid
libbpf: extern (ksym) #2: symbol 18, name bpf_task_kptr_get
libbpf: extern (ksym) #3: symbol 11, name bpf_task_release
libbpf: map '__tasks_kfunc_map': at sec_idx 7, offset 0.
libbpf: map '__tasks_kfunc_map': found type = 1.
libbpf: map '__tasks_kfunc_map': found key [15], sz = 4.
libbpf: map '__tasks_kfunc_map': found value [6621], sz = 8.
libbpf: map '__tasks_kfunc_map': found max_entries = 1.
libbpf: map 'task_kfu.bss' (global data): at sec_idx 4, offset 0, flags 400.
libbpf: map 1 is "task_kfu.bss"
libbpf: sec '.reltp_btf/task_newtask': collecting relocation for section(5)
'tp_btf/task_newtask'
libbpf: sec '.reltp_btf/task_newtask': relo #0: insn #2 against 'pid'
libbpf: prog 'test_task_acquire_release_argument': found data map 1
(task_kfu.bss, sec 4, off 0) for insn 2
libbpf: sec '.reltp_btf/task_newtask': relo #1: insn #8 against
'bpf_task_acquire'
libbpf: prog 'test_task_acquire_release_argument': found extern #0
'bpf_task_acquire' (sym 10) for insn #8
libbpf: sec '.reltp_btf/task_newtask': relo #2: insn #10 against
'bpf_task_release'
libbpf: prog 'test_task_acquire_release_argument': found extern #3
'bpf_task_release' (sym 11) for insn #10
libbpf: sec '.reltp_btf/task_newtask': relo #3: insn #14 against 'pid'
libbpf: prog 'test_task_acquire_release_current': found data map 1
(task_kfu.bss, sec 4, off 0) for insn 1
libbpf: sec '.reltp_btf/task_newtask': relo #4: insn #21 against
'bpf_task_acquire'
libbpf: prog 'test_task_acquire_release_current': found extern #0
'bpf_task_acquire' (sym 10) for insn #8
libbpf: sec '.reltp_btf/task_newtask': relo #5: insn #23 against
'bpf_task_release'
libbpf: prog 'test_task_acquire_release_current': found extern #3
'bpf_task_release' (sym 11) for insn #10
libbpf: sec '.reltp_btf/task_newtask': relo #6: insn #28 against 'pid'
libbpf: prog 'test_task_acquire_leave_in_map': found data map 1 (task_kfu.bss,
sec 4, off 0) 

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

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

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

--- Comment #16 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #14)
> > Jonathan, has anyone suggested adding generic init_list constructors to the
> > container classes?
> 
> Not that I'm aware of. There might be concerns about introducing more
> ambiguities like the vector{1,2} case.

Yes, I had to constrain it to when there is a conversion from __elt to
value_type.  Might as well also require value_type to be a class.

> > What do you think about doing the above translation in the compiler?  Is the
> > compiler allowed to do that?
> 
> Good question.
> 
> If the compiler first checked that the code as-written would call the
> initializer_list constructor (and not some other constructor)
> then it should be safe to do it.

My current hack checks for a list of at least 8 elements to exclude other
constructors, but checking actual overload resolution does sound safer.

[Bug target/107860] Compilation failure, ambiguous fisttp

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Andrew Pinski  ---
You need to do "arch -x86_64 bash" to this build really.
Otherwise you end up with the arm64 assembler.
So if you start with that, it should work.

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #6 from David Malcolm  ---
Fix for the overzealous reducing is to simply add "__attribute__((nonnull(1,
2)))" to the reproducer here:

__attribute__((nonnull(1, 2)))
void
arranger_object_unsplit (ArrangerObject *r1, ArrangerObject *r2,
 ArrangerObject **obj, _Bool fire_events)

I'm working on a fix for the false +ve.

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from David Malcolm  ---
Gah, this is slightly over-reduced, in that it removes the nonnull attributes. 
I'll try putting them back in.

Working on a fix.

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #4 from David Malcolm  ---
Created attachment 54023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54023=edit
Reduced reproducer

Attached is a reduced version of the reproducer, which demonstrates the false
+ve on trunk with just -fanalyzer on the command line:
  https://godbolt.org/z/fsec1f4hT
and also with gcc 12, 11, and 10.

[Bug tree-optimization/107982] [13 Regression] ICE in in lower_bound, at value-range.h:350

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

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

[Bug tree-optimization/107982] [13 Regression] ICE in in lower_bound, at value-range.h:350

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|--- |13.0
Summary|ICE in in lower_bound, at   |[13 Regression] ICE in in
   |value-range.h:350   |lower_bound, at
   ||value-range.h:350
   Keywords||ice-on-valid-code

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

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

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

--- Comment #15 from Jakub Jelinek  ---
So, do we want a new attribute on allocator to tell the compiler that it is a
class whose methods don't care about the address of the object and it has
trivial ctor and dtor and it is enough to construct it once instead of many
times, or shall the C++ FE hardcode it for std::allocator template if it sees
certain things in the header?
Not constructing thousands of these would be nice.
The temporary arrays might be a good idea for the more general case if we can't
optimize it better.

[Bug middle-end/107982] New: ICE in in lower_bound, at value-range.h:350

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

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

Bug ID: 107982
   Summary: ICE in in lower_bound, at value-range.h:350
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

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

This appears to be a recent regression.

The testcase is reduced from SLATEC.

ICEs with -O2, -O3 on x86_64-pc-linux-gnu, but succeeds with -O0, -O1, -Os.

during GIMPLE pass: dom
gfcbug156.f90:1:19:

1 |   SUBROUTINE TQLRAT (N, D, E2, IERR)
  |   ^
internal compiler error: in lower_bound, at value-range.h:350
0x870e8c frange::lower_bound() const
../../gcc-trunk/gcc/value-range.h:350
0x1e6fd39 frange::lower_bound() const
../../gcc-trunk/gcc/range-op-float.cc:1927
0x1e6fd39 foperator_div::op2_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
../../gcc-trunk/gcc/range-op-float.cc:2328
0x1d4fc3c gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1196
0x1d4e94e gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:694
0x1d4f40a gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1150
0x1d4e9cd gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:692
0x1d4fcc3 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1243
0x1d4e94e gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:694
0x1d51c25 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
../../gcc-trunk/gcc/gimple-range-gori.cc:1373
0x11473bf path_range_query::compute_ranges_in_block(basic_block_def*)
../../gcc-trunk/gcc/gimple-range-path.cc:454
0x1147a81 path_range_query::compute_ranges(bitmap_head const*)
../../gcc-trunk/gcc/gimple-range-path.cc:622
0x11cfb7d hybrid_jt_simplifier::simplify(gimple*, gimple*, basic_block_def*,
jt_state*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:1418
0x11cee4a jump_threader::simplify_control_stmt_condition(edge_def*, gimple*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:385
0x11cf53a jump_threader::thread_through_normal_block(vec*, edge_def*, bitmap_head*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:951
0x11d0737 jump_threader::thread_through_normal_block(vec*, edge_def*, bitmap_head*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:1175
0x11d0737 jump_threader::thread_across_edge(edge_def*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:1154
0x10c9624 dom_opt_dom_walker::after_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-dom.cc:1725
0x1d07a8f dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.cc:354
0x10ce0d4 execute
../../gcc-trunk/gcc/tree-ssa-dom.cc:939
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

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

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #12)
> Another significant part of the problem is that vector doesn't have
> a generic initializer_list constructor.  Adding
> 
>   template 
>   _GLIBCXX20_CONSTEXPR
>   vector(initializer_list<__elt> __l,
>  const allocator_type& __a = allocator_type())
>   : _Base(__a)
>   {
> _M_range_initialize(__l.begin(), __l.end(),
> random_access_iterator_tag());
>   }
> 
> so that it can construct from initializer_list makes the
> construction into a simple loop over a static array.

Which is potentially *much* more efficient, because it constructs the strings
in place, instead of making unelidable copies of the initializer_list elements.

> Jonathan, has anyone suggested adding generic init_list constructors to the
> container classes?

Not that I'm aware of. There might be concerns about introducing more
ambiguities like the vector{1,2} case.

> What do you think about doing the above translation in the compiler?  Is the
> compiler allowed to do that?

Good question.

If the compiler first checked that the code as-written would call the
initializer_list constructor (and not some other constructor) then
it should be safe to do it.

In the general case, somebody would probably find a way to notice and complain.
But if you're thinking of optimizing the specific case of vector then I
think it would be unobservable. The string copies can't be observed, because
it's unspecified when and how often std::allocator calls operator new.

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

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #16 from James Hilliard  ---
(In reply to David Faust from comment #15)
> Created attachment 54021 [details]
> [v2] DATASEC entries for extern funcs
> 
> v2 fixes an off-by-one bug introduced in the patch which was causing
> libbpf: Invalid BTF total size

Yeah, this seems to work.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Keywords||testsuite-fail

[Bug fortran/107968] array slicing gives wrong result for an array pointer defined in a subroutine

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following attempt fixes the erroneous output:

diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..c4525f67ef3 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2641,6 +2641,9 @@ gfc_trans_transfer (gfc_code * code)
seen_vector = true;
break;
  }
+
+ if (!seen_vector && !gfc_is_not_contiguous (expr))
+   goto scalarize;
}

  if (seen_vector && last_dt == READ)

However, this defeats the optimization on array I/O and regresses on

gfortran.dg/implied_do_io_1.f90
gfortran.dg/implied_do_io_4.f90

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
No need to ignore it, this should work:

--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -241,6 +241,11 @@
 #undef y
 #endif

+#if defined __GLIBC_PREREQ && ! __GLIBC_PREREQ(2, 19)
+// Glibc defines this prior to 2.19
+#undef __unused
+#endif
+
 #if __has_include()
 // newlib's  defines these as macros.
 #undef __lockable


Interesting that the comment Andrew posted also mentions __block, because we
use that as a variable name in a few places. It hasn't failed so far :-)

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

--- Comment #4 from seurer at gcc dot gnu.org ---
These systems are pretty old.  So, just ignore it?

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> I think we should warn but how to warn is going to have to special case the
> macro I think.

But saying that I do think it is valid C2X code if you take the C2X standard
seperately from the older standards.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|va_start incorrectly|va_start does not warn
   |accepts an arbitrary number |about an arbitrary number
   |of arguments in C2x |of arguments in C2x mode

--- Comment #3 from Andrew Pinski  ---
I think we should warn but how to warn is going to have to special case the
macro I think.

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

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

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

David Faust  changed:

   What|Removed |Added

  Attachment #54017|0   |1
is obsolete||

--- Comment #15 from David Faust  ---
Created attachment 54021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54021=edit
[v2] DATASEC entries for extern funcs

v2 fixes an off-by-one bug introduced in the patch which was causing
libbpf: Invalid BTF total size

[Bug c/107980] va_start incorrectly accepts an arbitrary number of arguments in C2x

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #2 from Aaron Ballman  ---
(In reply to Andrew Pinski from comment #1)
> Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
> ```
> 7.16.1.4 The va_start macro
> void va_start(va_list ap, ...);
> 
> 
> Any additional arguments are not used by
> the macro and will not be expanded or evaluated for any reason.
> ```
> 
> 
> I would assume since it is `arguments` rather than additional argument, that
> it could be more than one additional argument.

Yes, the standard says "arguments" because there can be additional arguments
due to using `...`. However, think about the user experience:
```
// This should always be happily accepted because it's
// idiomatic C before C2x and it's valid C in C2x and later.
va_start(list, some_arg);

// This should be accepted in C2x mode and if you care
// to do such things, warn the user that it's incompatible
// with standards before C2x. Pre-C2x, this is an error.
va_start(list);

// Under what circumstances is this anything other than
// programmer confusion? It's invalid before C2x and the
// extra args are meaningless in C2x and later.
va_start(list, 1, 2, 3, 4);
```

[Bug c++/107981] 'operator auto' has not been declared in base

[egor.pugin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Egor Pugin  ---
Ignore previous comment.

[Bug c++/107981] 'operator auto' has not been declared in base

[egor.pugin at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Egor Pugin  ---
Also see following test cases.

===

ok for gcc

struct a {
operator auto();
};
struct b : a {
using a::operator auto;
};

===

not ok for gcc, ok for msvc

struct a {
operator auto();
};
struct b : a {
using a::operator auto;
};

int main(){b v;int x = v;}

===

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

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

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

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

We already do that for cleaning up the array itself; the problem is any
temporaries created while initializing array elements.  That's why I was
thinking about a parallel array of temporaries.  Though that would only work if
all the element initializers construct the same temporaries, which is true in
this case but not in general.

But really I think we should try to avoid constructing an array of std::string
in the first place, as in comment #12.

[Bug c/107980] va_start incorrectly accepts an arbitrary number of arguments in C2x

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
```
7.16.1.4 The va_start macro
void va_start(va_list ap, ...);


Any additional arguments are not used by
the macro and will not be expanded or evaluated for any reason.
```


I would assume since it is `arguments` rather than additional argument, that it
could be more than one additional argument.

[Bug c++/107981] New: 'operator auto' has not been declared in base

[egor.pugin at gmail dot com via Gcc-bugs]

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

Bug ID: 107981
   Summary: 'operator auto' has not been declared in base
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor.pugin at gmail dot com
  Target Milestone: ---

struct a {
operator auto() { return 1; }
};
struct b : a {
using a::operator auto;
};

gives

:5:23: error: 'operator auto' has not been declared in 'struct a'
5 | using a::operator auto;
  |   ^~~~

Exerything is fine for clang/msvc.

https://godbolt.org/z/cTnxs97r6

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

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

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

--- Comment #12 from Jason Merrill  ---
Another significant part of the problem is that vector doesn't have a
generic initializer_list constructor.  Adding

  template 
  _GLIBCXX20_CONSTEXPR
  vector(initializer_list<__elt> __l,
 const allocator_type& __a = allocator_type())
  : _Base(__a)
  {
_M_range_initialize(__l.begin(), __l.end(),
random_access_iterator_tag());
  }

so that it can construct from initializer_list makes the
construction into a simple loop over a static array.

Users can do this optimization manually by writing e.g.

  auto init = {
  "aahing", "aaliis", "aarrgh", "abacas", "abacus", "abakas", "abamps",
"abands", "abased", "abaser", "abases", "abasia",
  };
  const std::vector lst (init.begin(), init.end());

and so using the (template) iterator constructor instead of the (non-template)
initializer_list constructor.  But that shouldn't be necessary.

Jonathan, has anyone suggested adding generic init_list constructors to the
container classes?

What do you think about doing the above translation in the compiler?  Is the
compiler allowed to do that?

[Bug c/107980] New: va_start incorrectly accepts an arbitrary number of arguments in C2x

[aaron at aaronballman dot com via Gcc-bugs]

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

Bug ID: 107980
   Summary: va_start incorrectly accepts an arbitrary number of
arguments in C2x
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron at aaronballman dot com
  Target Milestone: ---

GCC implemented WG14 N2975 which relaxes the requirements for va_start.
However, there's a diagnostic missing for it when the user passes more than two
arguments:
```
#include 

void func(int i, ...) {
  va_list va;
  va_start(va, i, 23, 4);

  va_end(va);
}

```
is silently accepted by GCC even with -Wall and -pedantic.

I noticed this when I was working on the Clang implementation of N2975. I
noticed that GCC has not changed the definition of __builtin_va_start, which I
think is a good approach (keeping builtin interfaces stable between compiler
and language versions is a nicety). I was considering adding
`__builtin_c23_va_start` to Clang with a signature that accepts `...` so I can
diagnose this case, but I think that will run afoul of 7.16.1.4p4 "Any
additional arguments are not used by the macro and will not be expanded or
evaluated for any reason." without some heroics, so I'm not certain how/if
Clang will address this.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

--- Comment #3 from Andrew Pinski  ---
https://sourceware.org/git/?p=glibc.git;a=commit;h=d1d9eaf478b7d3a11a599c120498b79fe5629a61
was the change in glibc.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #2 from Andrew Pinski  ---
Note only glibc 2.19 and above no longer use __unused:
* The public headers no longer use __unused nor __block.  This change is to
  support compiling programs that are derived from BSD sources and use
  __unused internally, and to support compiling with Clang's -fblock
  extension which uses __block.

My bet is that this is an older glibc and we include a header glibc file which
used __unused ...

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Richard Biener  ---
(In reply to Peter Bergner from comment #3)
> Is this the same bug, so just a simpler test case?
> 
> bergner@fowler:LTC193379$ cat bug.c
> int len = 16;
> extern char *src;
> char dst[16];
> 
> void
> foo (void)
> {
> #ifdef OK
>   for (int i = 0; i < 16; i++)
> #else
>   for (int i = 0; i < len; i++)
> #endif
> dst[i] = src[i];
> }
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -DOK
> -ftree-vectorize bug.c
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -UOK
> -fno-tree-vectorize bug.c
> 
> bergner@fowler:LTC193379$
> /home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-ltc193379-debug/gcc -S -O3 -UOK
> -ftree-vectorize bug.c
> bug.c: In function ‘foo’:
> bug.c:13:12: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
>13 | dst[i] = src[i];
>   | ~~~^~~~
> bug.c:3:6: note: at offset 16 into destination object ‘dst’ of size 16
> 3 | char dst[16];
>   |  ^~~
> bug.c:13:12: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
>13 | dst[i] = src[i];
>   | ~~~^~~~
> bug.c:3:6: note: at offset 17 into destination object ‘dst’ of size 16
> 3 | char dst[16];
>   |  ^~~
> 
> I'll note that -fno-unroll-loops doesn't affect anything.

It looks similar.  Note the code we warn is isolated by DOM threading
after loop opts here.  The unrolling done is also a bit excessive but
that's because we estimate an upper bound on the epilogue based on
the array size accessed.

The IL we diagnose is definitely bogus but unreachable at runtime which
we don't see so it's also a code size issue.

[Bug fortran/107922] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8473

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |13.0
 Status|ASSIGNED|RESOLVED

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Oh, also these:

FAIL: experimental/names.cc (test for excess errors)
FAIL: experimental/names.cc (test for excess errors)

[Bug libstdc++/107979] New: [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

Bug ID: 107979
   Summary: [13 regression] r13-4391-g0ded30b361d2b1 causes excess
errors in 17_intro/names.cc on big endian
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:0ded30b361d2b1e43048b640e9ad6fef161fe9a9, r13-4391-g0ded30b361d2b1
make  -k check RUNTESTFLAGS="--target_board=unix'{-m64}'
conformance.exp=17_intro/names.cc"
FAIL: 17_intro/names.cc (test for excess errors)
# of unexpected failures1


I am seeing this failure on powerpc64 BE systems.


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/17_intro/names.cc -m64
-D__GLIBCXX__= -fdiagnostics-plain-output -S -o names.s^M
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/17_intro/names.cc:135:
error: expected ';' at end of member declaration^M
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/17_intro/names.cc:135:
error: 'be' does not name a type; did you mean 'e'?^M
compiler exited with status 1
FAIL: 17_intro/names.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/17_intro/names.cc:135:
error: expected ';' at end of member declaration
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/17_intro/names.cc:135:
error: 'be' does not name a type; did you mean 'e'?

commit 0ded30b361d2b1e43048b640e9ad6fef161fe9a9
Author: Jonathan Wakely 
Date:   Mon Nov 28 20:48:55 2022 +

libstdc++: Do not use __used or __packed as identifiers

[Bug c++/107978] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in dump_ada_declaration, at c-family/c-ada-spec.cc:2802 with -fdump-ada-spec

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
apinski@xeond:~/src/upstream-gcc/gcc/gcc/c-family$ git diff c-ada-spec.cc
diff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc
index faf71742522..2291638e9b3 100644
--- a/gcc/c-family/c-ada-spec.cc
+++ b/gcc/c-family/c-ada-spec.cc
@@ -3549,6 +3549,8 @@ void
 dump_ada_specs (void (*collect_all_refs)(const char *),
int (*check)(tree, cpp_operation))
 {
+  if (seen_error ())
+return;
   bitmap_obstack_initialize (NULL);

   overloaded_names = init_overloaded_names ();


Should fix this.

[Bug fortran/107968] array slicing gives wrong result for an array pointer defined in a subroutine

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

A look at the tree dump shows a funny expansion of the array section in
the data transfer (write statement).  It appears that some optimization
of the transfer of arrays is attempted, but the stride looks wrong.

Replacing

  WRITE (0,*) vertices_pointer%vlon(1:)

by any of the following produces different - working - output:

  WRITE (0,*) [vertices_pointer%vlon(1:)]
  WRITE (0,*) (vertices_pointer%vlon(1:))
  WRITE (0,*) (vertices_pointer%vlon(i),i=1,size(vertices_pointer%vlon))

And - as reported - why should the addition of a (dead) pointer assignment
after the write change the way the array section is expanded?

Looking at older gfortran version, all tested seem to fail.
And with the dead pointer assignment uncommented, gfortran-7 ICEs.

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

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

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

--- Comment #1 from Andrew Pinski  ---
  ncases = tree_to_shwi (range) + 1;
  labelvec = XALLOCAVEC (rtx, ncases);
  memset (labelvec, 0, ncases * sizeof (rtx));


I think this is a won't fix.
Doctor, it hurts when I bend my arm this way.
Don't bend it that way then.

[Bug c++/107978] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in dump_ada_declaration, at c-family/c-ada-spec.cc:2802 with -fdump-ada-spec

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107978
   Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in dump_ada_declaration, at
c-family/c-ada-spec.cc:2802 with -fdump-ada-spec
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-g++ -fdump-ada-spec testcase.C 
testcase.C:1:10: error: aggregate 'S s' has incomplete type and cannot be
defined
1 | struct S s;
  |  ^
testcase.C:1:11: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in dump_ada_declaration, at
c-family/c-ada-spec.cc:2802
1 | struct S s;
  |   ^
0x8e5d3c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.cc:8872
0x7810a7 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/repo/gcc-trunk/gcc/tree.h:3651
0x7810a7 dump_ada_declaration
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:2802
0x629 dump_ada_nodes
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:826
0x629 dump_ads
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:3481
0x629 dump_ada_specs(void (*)(char const*), int (*)(tree_node*,
cpp_operation))
/repo/gcc-trunk/gcc/c-family/c-ada-spec.cc:3560
0xed18e9 c_parse_final_cleanups()
/repo/gcc-trunk/gcc/cp/decl2.cc:4919
0x10fb220 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1266
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/107977] New: ICE: in add_specializations, at cp/module.cc:13186 with -fdump-ada-spec -fmodule-header

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107977
   Summary: ICE: in add_specializations, at cp/module.cc:13186
with -fdump-ada-spec -fmodule-header
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-g++ -fdump-ada-spec -fmodule-header testcase.C 
testcase.C: internal compiler error: in add_specializations, at
cp/module.cc:13186
0x705fad depset::hash::add_specializations(bool)
/repo/gcc-trunk/gcc/cp/module.cc:13186
0xf3f230 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
/repo/gcc-trunk/gcc/cp/module.cc:17879
0xf406a4 finish_module_processing(cpp_reader*)
/repo/gcc-trunk/gcc/cp/module.cc:20235
0xecfe92 c_parse_final_cleanups()
/repo/gcc-trunk/gcc/cp/decl2.cc:5148
0x10fb220 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1266
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4493-20221205115445-g109148dd16e-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4493-20221205115445-g109148dd16e-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221205 (experimental) (GCC)

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

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #14 from James Hilliard  ---
(In reply to David Faust from comment #13)
> Created attachment 54017 [details]
> DATASEC entries for extern funcs
> 
> Applies on top of 54002: updated patch
> Adds emission of DATASEC entries for extern funcs. Rough, needs cleanup.

Seeing a regression in get_func_ip_test.c looks like:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen object
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.linked1.o
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o
libbpf: linker: adding object file
'/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o'...
libbpf: Invalid BTF total size: 25303
libbpf: failed to parse .BTF from
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o:
-22
Error: failed to link
'/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o':
Invalid argument (22)

Broken GCC BTF dump:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o
format raw
libbpf: Invalid BTF total size: 25303
Error: failed to load BTF from
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/get_func_ip_test.bpf.o:
Invalid argument

Working LLVM btf dump:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next/tools/testing/selftests/bpf/get_func_ip_test.bpf.o
format raw
[1] FUNC_PROTO '(anon)' ret_type_id=2 vlen=0
[2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[3] FUNC 'unused' type_id=1 linkage=global
[4] PTR '(anon)' type_id=5
[5] INT 'unsigned long long' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[6] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=4
[7] FUNC 'test1' type_id=6 linkage=global
[8] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=4
[9] FUNC 'test2' type_id=8 linkage=global
[10] PTR '(anon)' type_id=11
[11] FWD 'pt_regs' fwd_kind=struct
[12] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=10
[13] FUNC 'test3' type_id=12 linkage=global
[14] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=10
[15] FUNC 'test4' type_id=14 linkage=global
[16] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=4
[17] FUNC 'test5' type_id=16 linkage=global
[18] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'ctx' type_id=10
[19] FUNC 'test6' type_id=18 linkage=global
[20] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[21] ARRAY '(anon)' type_id=20 index_type_id=22 nr_elems=4
[22] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[23] VAR '_license' type_id=21, linkage=global
[24] INT '_Bool' size=1 bits_offset=0 nr_bits=8 encoding=BOOL
[25] VAR 'CONFIG_X86_KERNEL_IBT' type_id=24, linkage=extern
[26] TYPEDEF '__u64' type_id=5
[27] VAR 'test1_result' type_id=26, linkage=global
[28] VAR 'test2_result' type_id=26, linkage=global
[29] VAR 'test3_result' type_id=26, linkage=global
[30] CONST '(anon)' type_id=0
[31] VAR 'bpf_fentry_test3' type_id=30, linkage=extern
[32] VAR 'test4_result' type_id=26, linkage=global
[33] VAR 'test5_result' type_id=26, linkage=global
[34] VAR 'test6_result' type_id=26, linkage=global
[35] VAR 'bpf_fentry_test1' type_id=30, linkage=extern
[36] VAR 'bpf_fentry_test2' type_id=30, linkage=extern
[37] VAR 'bpf_fentry_test4' type_id=30, linkage=extern
[38] VAR 'bpf_modify_return_test' type_id=30, linkage=extern
[39] DATASEC '.bss' size=0 vlen=6
type_id=27 offset=0 size=8 (VAR 'test1_result')
type_id=28 offset=0 size=8 (VAR 'test2_result')
type_id=29 offset=0 size=8 (VAR 'test3_result')
type_id=32 offset=0 size=8 (VAR 'test4_result')
type_id=33 offset=0 size=8 (VAR 'test5_result')
type_id=34 offset=0 size=8 (VAR 'test6_result')
[40] DATASEC '.kconfig' size=0 vlen=1
type_id=25 offset=0 size=1 (VAR 'CONFIG_X86_KERNEL_IBT')
[41] DATASEC '.ksyms' size=0 vlen=5
type_id=31 offset=0 size=1 (VAR 'bpf_fentry_test3')
type_id=35 offset=0 size=1 (VAR 'bpf_fentry_test1')
type_id=36 offset=0 size=1 (VAR 'bpf_fentry_test2')
type_id=37 offset=0 size=1 (VAR 'bpf_fentry_test4')
type_id=38 offset=0 size=1 (VAR 'bpf_modify_return_test')
[42] DATASEC 'license' size=0 vlen=1
type_id=23 offset=0 size=4 (VAR '_license')

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

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107976
   Summary: ICE: SIGSEGV (stack overflow) in
emit_case_dispatch_table (stmt.cc:783) with large
--param=jump-table-max-growth-ratio-for-speed
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc
--param=jump-table-max-growth-ratio-for-speed=1813160384 testcase.c 
x86_64-pc-linux-gnu-gcc: internal compiler error: Segmentation fault signal
terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.


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

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

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

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

Consider it pre-approved.

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

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

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

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

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

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

[hewillk at gmail dot com via Gcc-bugs]

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

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

I would never do that.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

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

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

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

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

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

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

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

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

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

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

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

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





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




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

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

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

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

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

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

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

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

[thiago at kde dot org via Gcc-bugs]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

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

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

For some reason clang is working fine.

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

[mrjjot at gmail dot com via Gcc-bugs]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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


Re-confirmed for the other cases.

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

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

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

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

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

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

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

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

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

[rguenther at suse dot de via Gcc-bugs]

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

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

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

Does it allow the nesting when nested in a union?

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

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

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

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

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

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

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

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

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

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

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

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

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

We start with

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

lowered to

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

and with a CFG

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

   :
  return D.2772;

SSA:

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

thread1 causes the arg to split and lose locations:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

```

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

when compiling openssl-1.1.1s with the following workflow:

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

I get this unexpected warning (error)

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


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

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

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

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

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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