[Bug target/88558] Inline lrint, lrintf

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

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

HaoChen Gui  changed:

   What|Removed |Added

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

--- Comment #3 from HaoChen Gui  ---
fixed.

[Bug target/88558] Inline lrint, lrintf

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r14-4484-g5cbe235de6d5c2a04a3116c6b6e63a0e4b8da304
Author: Haochen Gui 
Date:   Mon Oct 9 14:33:23 2023 +0800

rs6000: enable SImode in FP register on P7

gcc/
PR target/88558
* config/rs6000/rs6000.cc (rs6000_hard_regno_mode_ok_uncached):
Enable SImode on FP registers for P7.
* config/rs6000/rs6000.md (*movsi_internal1): Add fmr for SImode
move between FP registers.  Set attribute isa of stfiwx to "*"
and attribute of stxsiwx to "p7".

[Bug target/106769] PPCLE: vec_extract(vector unsigned int) unnecessary rldicl after mfvsrwz

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r14-4485-gc1e474785859c9630fcae19c8d2d606f5642c636
Author: Haochen Gui 
Date:   Mon Oct 9 14:34:46 2023 +0800

rs6000: support 32bit inline lrint

gcc/
PR target/88558
* config/rs6000/rs6000.md (lrintdi2): Remove TARGET_FPRND
from insn condition.
(lrintsi2): New insn pattern for 32bit lrint.

gcc/testsuite/
PR target/106769
* gcc.target/powerpc/pr88558.h: New.
* gcc.target/powerpc/pr88558-p7.c: New.
* gcc.target/powerpc/pr88558-p8.c: New.

[Bug target/88558] Inline lrint, lrintf

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r14-4485-gc1e474785859c9630fcae19c8d2d606f5642c636
Author: Haochen Gui 
Date:   Mon Oct 9 14:34:46 2023 +0800

rs6000: support 32bit inline lrint

gcc/
PR target/88558
* config/rs6000/rs6000.md (lrintdi2): Remove TARGET_FPRND
from insn condition.
(lrintsi2): New insn pattern for 32bit lrint.

gcc/testsuite/
PR target/106769
* gcc.target/powerpc/pr88558.h: New.
* gcc.target/powerpc/pr88558-p7.c: New.
* gcc.target/powerpc/pr88558-p8.c: New.

[Bug tree-optimization/99395] s116 benchmark of TSVC is vectorized by clang and not by gcc

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2021-03-05 00:00:00 |2023-10-9

--- Comment #7 from Richard Biener  ---
(In reply to JuzheZhong from comment #6)
> Hi, Richi.
> 
> Recently, I am evaluating TSVC performance of GCC:
> 
> I found both RISC-V and aarch64 can SLP vectorize it:
> 
> https://godbolt.org/z/ssvTxxjeT
> 
> Both GCC-13 and trunk GCC can SLP it like LLVM (GCC-12 failed) but with
> -fno-vect-cost-model.
> 
> I suspect we should adjust Vector COST model (I don't think we should ajust
> cost
> model in target backend since LLVM by default vectorize such case).

We are only vectorizing part of the scalar code.  The CSE issue still exists,
so is the resulting loop analysis issues.

[Bug tree-optimization/111730] erroneous alloc-size-larger-than warning with -O1

[xavier.cooney03 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Xavier Cooney  ---
I see, thanks for looking into this.

The unreduced test case (which was from a student confused about the error
message) was still passing a value to `malloc` which from the context which gcc
could see wasn't /necessarily/ non-negative.

But the code
```
void foo2(int x) {
char *a = malloc(x);
(void) a;
}
```
doesn't trigger the warning, even though `x` could also be negative.

I'm not sure why the extra loops are necessary for the warning to be emitted if
the compiler is trying to warn about any time a potentially negative value
might be passed to `malloc`.

Also the error message reads to me as saying that argument 1 must be in the
range [18446744071562067968, 18446744073709551615] (in which case it would be
incorrect), rather than saying the argument could be in the range (in which
case it would be correct).

Thanks again for look into this :)

[no subject]

[ขวัญจิรา ศิลปการสกุล via Gcc-bugs]

สินเชื่อเพื่อธุรกิจสำหรับ
บริษัท หจก. โรงงานอุตสาหกรรมหรือธุรกิจขนาดย่อม ทั่วประเทศ
✏️ อนุมัติวงเงินสูงสุด 10 ล้านบาท ด้วยอัตราดอกเบี้ย 1%
สนใจรายละเอียดเพิ่มเติมติดต่อ  คุณ สรวิชญ์ 0657652873
LINE ID  sinsub01

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
The original project is too complex for me to come up with a reproduction case,
I can help with gdb if additional information is needed.

[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Nick Krempel from comment #0)
> T{1, 2} + 1;
>   Ditto.

That is what clang's issue: https://github.com/llvm/llvm-project/issues/54016
is about even.

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
GCC11.3 is ok, GCC13.2 and later have the issue, I didn't verify GCC12.

[Bug libgcc/111731] New: [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 111731
   Summary: [13/14 regression] gcc_assert is hit at
libgcc/unwind-dw2-fde.c#L291
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

The issue is not solved by PR110956'fix.

I did some debugging with gdb, and here are the logs:

The first time gdb stop at
https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2-fde.c#L143

│   138   ob->next = unseen_objects;
│   139   unseen_objects = ob;  
│   140 
│   141   __gthread_mutex_unlock (&object_mutex);   
│   142 #endif  
│  >143 }

(gdb) frame
#0  __register_frame_info_bases (begin=0x7fffd551e000, ob=0x1e386d0, tbase=0x0,
dbase=0x0) at ../../../libgcc/unwind-dw2-fde.c:143
(gdb) p registered_frames->root->entry_count
$31 = 2
(gdb) p registered_frames->root->content.entries[0]
$32 = {base = 140736772300800, size = 1, ob = 0x1e386d0}
(gdb) p registered_frames->root->content.entries[1]
$33 = {base = 140736772317184, size = 178483158, ob = 0x1e386d0}

The second time gdb stop at
https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2-fde.c#L143

│   138   ob->next = unseen_objects;
│   139   unseen_objects = ob;  
│   140 
│   141   __gthread_mutex_unlock (&object_mutex);   
│   142 #endif  
│  >143 }

(gdb) frame
#0  __register_frame_info_bases (begin=0x7fffd409c000, ob=0x26b2e00, tbase=0x0,
dbase=0x0) at ../../../libgcc/unwind-dw2-fde.c:143
(gdb) p registered_frames->root->entry_count
$34 = 4
(gdb) p registered_frames->root->content.entries[0]
$35 = {base = 140736750796800, size = 1, ob = 0x26b2e00}
(gdb) p registered_frames->root->content.entries[1]
$36 = {base = 140736750817280, size = 199987168, ob = 0x26b2e00}
(gdb) p registered_frames->root->content.entries[2]
$37 = {base = 140736772300800, size = 1, ob = 0x1e386d0}
(gdb) p registered_frames->root->content.entries[3]
$38 = {base = 140736772317184, size = 178483158, ob = 0x1e386d0}

The first time gdb stop at unexpected line
https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2-btree.h#L829:

│   825   unsigned slot = btree_node_find_leaf_slot (iter, base);   
│   826   if ((slot >= iter->entry_count) ||
(iter->content.entries[slot].base != base)) 
│   827 {   
│   828   // Not found, this should never happen.   
│  >829   btree_node_unlock_exclusive (iter);   
│   830   return NULL;  
│   831 } 

(gdb) p slot
$26 = 1
(gdb) p iter->content.entries[slot]
$27 = {base = 140736750817280, size = 199987168, ob = 0x26e7900}
(gdb) p iter->content.entries[2]
$28 = {base = 140736772300800, size = 1, ob = 0x1e386d0}
We can see that when we try to remove btree node of
0x7fffd551e000(140736772300800).

 The return value of btree_node_find_leaf_slot is 1, but I think it should
return 2. 


Both btree_insert and btree_remove will call

// Find the position for a slot in a leaf node.
static unsigned
btree_node_find_leaf_slot (const struct btree_node *n, uintptr_type value)
{
  for (unsigned index = 0, ec = n->entry_count; index != ec; ++index)
   if (n->content.entries[index].base + n->content.entries[index].size > value) 
 return index;
  return n->entry_count;
} 


But

registered_frames->root->content.entries[1].base +
registered_frames->root->content.entries[1].size >
registered_frames->root->content.entries[2].base

registered_frames->root->content.entries[2].base +
registered_frames->root->content.entries[2].size >
registered_frames->root->content.entries[1].base 

and it makes btree_node_find_leaf_slot return wrong slot(at btree_insert, it
will return slot 1 for base1, and move base2 to slot2, but at btree_remove, it
still return slot 1 bacause of upper logic), I'm not sure if this is the
rootcause.

[Bug tree-optimization/111730] erroneous alloc-size-larger-than warning with -O1

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

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

--- Comment #3 from Andrew Pinski  ---
Note you can reproduce the same warning with ( -O2 -fno-code-hoisting
-fno-tree-loop-im -fno-tree-pre):
```
// #include 

typedef long unsigned int size_t;
extern void *malloc (size_t size) __attribute__ ((__malloc__));
int *t;
void foo(int x) {
// if (x < 1) return;
for (int i = 0; i < x; i++) {*t = i;}

char *a = malloc(x);

for (int i = 0; i < x; i++)
a[i] = 0;

while (a[x - 1]) {*t++;}
}
```

I still think you should add a check for x being negative to fix the
code/warning. Unless you have a unreduced testcase which has the test before
and still able to produce the warning, this will most likely be closed as
invalid.

[Bug tree-optimization/111730] erroneous alloc-size-larger-than warning with -O1

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

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

--- Comment #2 from Andrew Pinski  ---
The difference between -O1 and -O2 is -O2 removes the empty loops.

[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #5 from Jiang An  ---
Related:
https://cplusplus.github.io/CWG/issues/2548.html

[Bug c/111730] erroneous alloc-size-larger-than warning with -O1

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

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

--- Comment #1 from Andrew Pinski  ---
You might want to add a check that x is not negative and I suspect that will
fix the warning.

[Bug c/111730] New: erroneous alloc-size-larger-than warning with -O1

[xavier.cooney03 at gmail dot com via Gcc-bugs]

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

Bug ID: 111730
   Summary: erroneous alloc-size-larger-than warning with -O1
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xavier.cooney03 at gmail dot com
  Target Milestone: ---

Created attachment 56076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56076&action=edit
bug.c

Hi, in some circumstances gcc incorrectly emits the alloc-size-larger-than
warning:

$ gcc -O1 -Wall -c bug.c
bug.c: In function ‘foo’:
bug.c:9:15: warning: argument 1 range [18446744071562067968,
18446744073709551615] exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
9 | char *a = malloc(x);
  |   ^
bug.c:4:14: note: in a call to allocation function ‘malloc’ declared here
4 | extern void *malloc (size_t size) __attribute__ ((__malloc__));
  |  ^~


This only seems to occur when using -O1, other optimisation levels (-O0, -O2,
-O3, -Os) don't result in the warning.

The 'useless' loops are necessary to reproduce, removing the first or last loop
causes the warning to disappear.

18446744071562067968 = 0x8000
18446744073709551615 = 0x

It seems as if gcc is incorrectly deducing that `x` must be negative.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC)

[Bug middle-end/111621] [RISC-V] Bad register allocation in vadd.vi may cause operational error

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

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #3 from JuzheZhong  ---
I don't think this is a bug.

You are using  __riscv_vadd_vx_i32m4_m.

The vd is not necessary same as vs2 and this intrinsic is supposed to use
TAMA which means that the tailed element and mask-inactive elements are
agnostic (can be either all ones or original value).

So the codegen is correct even though -O0 result is different from -O2/-O3.

If you want to use make vd same as vs2, you should use these following
intrinsics:

__riscv_vadd_vx_i32m4_tu
__riscv_vadd_vx_i32m4_mu
__riscv_vadd_vx_i32m4_tumu

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #21 from Jeremy R.  ---
Another option might be just do nothing and don't set the badbit, just pretend
it's an empty string. This shouldn't break existing programs and would at least
be something a programmer could more easily track down.

[Bug driver/111700] ICE: SIGSEGV in needs_read_p (input.cc:598) with -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr on pre-processed input

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

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

--- Comment #3 from David Malcolm  ---
Should be fixed on trunk by the above patch.

Keeping open to track backporting the fix to gcc 13.

[Bug analyzer/111155] RFE: better diagrams for string operations

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

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

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

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

commit r14-4477-gb365e9d57ad445c5491737e230bc94213a139de7
Author: David Malcolm 
Date:   Sun Oct 8 18:43:16 2023 -0400

analyzer: improvements to out-of-bounds diagrams [PR55]

Update out-of-bounds diagrams to show existing string values,
and the initial write index within a string buffer.

For example, given the out-of-bounds write in strcat in:

void test (void)
{
  char buf[10];
  strcpy (buf, "hello");
  strcat (buf, " world!");
}

the diagram improves from:

  
âââ¬ââ¬â¬â¬¬ââ¬ââ
   â [0] â [1] â[2] â[3] â[4] ââ [5]
â [6] â [7] â
  
âââ¼ââ¼â¼â¼â¤âââ¼ââ¼ââ¤
   â ' ' â 'w' â'o' â'r' â'l' ââ 'd'
â '!' â NUL â
  
âââ´ââ´â´â´â´â´ââ´ââ´ââ¤
   â  string literal (type: 'char[8]')  
â
  
âââ
  â ââââ  â
â â
  â ââââ  â
â â
  v vvvv  v v v
 
âââ¬â¬
  â [0] â  ...   â[9] ââ 
   â
 
âââ´â´â¤âafter
valid rangeâ
  â 'buf' (type: 'char[10]')  ââ 
   â
 

 
âââ¬ââ¤ââ¬â¤
â   â
 
â­ââ´â®   
â­ââ´ââ®
  âcapacity: 10 bytesââoverflow of 3
bytesâ
 
â°ââ⯠  
â°¯

to:


ââ¬â¬â¬â¬¬ââ¬ââ
 â[0] â[1] â[2] â[3] â[4] ââ [5]
â [6] â [7] â

ââ¼â¼â¼â¼â¤âââ¼ââ¼ââ¤
 â' ' â'w' â'o' â'r' â'l' ââ 'd'
â '!' â NUL â

ââ´â´â´â´â´â´ââ´ââ´ââ¤
 â string literal (type: 'char[8]') 
â

â
   âââââ  â
â â
   âââââ  â
â â
   vvvvv  v v v
 
âââ¬â¬â¬âââ¬
  â [0] â... â[5] â ...  â[9] ââ 
   â
 
âââ¼â¬â¬â¬â¬â¼â¼âââ´ââ
â
  â 'h' â'e' â'l' â'l' â'o' ââNUL â   
âafter valid rangeâ
 
âââ´â´â´â´â´â´â´â
â
  â 'buf' (type: 'char[10]')  ââ 
   â
 

 
âââ¬ââ¤ââ¬â¤
â   â
 
â­ââ´â®   
â­ââ´ââ®
  âcapacity: 10 bytesââoverflow of 3
bytesâ
 
â°ââ⯠  
â°¯

gcc/analyzer/ChangeLog:
PR analyzer/55
* access-diagram.cc (boundaries::boundaries): Add logger param
(boundaries::add): Add logging.
(boundaries::get_hard_boundaries_in_range): New.
(boundaries::m_logger): New field.
(boundaries::get_table_x_for_offset): Make public.
(class svalue_spatial_item): New.
(class compound_svalue_spatial_item): New.
(add_ellipsis_to_gaps): New.
(valid_region_spatial_item::valid_region_spatial_item): Add theme
param.  Initialize m_boundaries, m_existing_sval, and
m_existing_sval_spatial_item.
(valid_region_spatial_item::add_boundaries): Set m_boundaries.
Add boundaries for any m_existing_sval_spatial_item.
(valid_region_spatial_item::add_array_elements_t

[Bug driver/111700] ICE: SIGSEGV in needs_read_p (input.cc:598) with -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr on pre-processed input

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:94caa6a6b4bd73b6c2bf3ab5e43ca42c5da4287a

commit r14-4474-g94caa6a6b4bd73b6c2bf3ab5e43ca42c5da4287a
Author: David Malcolm 
Date:   Sun Oct 8 18:43:15 2023 -0400

diagnostics: fix ICE on sarif output when source file is unreadable
[PR111700]

gcc/ChangeLog:
PR driver/111700
* input.cc (file_cache::add_file): Update leading comment to
clarify that it can fail.
(file_cache::lookup_or_add_file): Likewise.
(file_cache::get_source_file_content): Gracefully handle
lookup_or_add_file failing.

gcc/testsuite/ChangeLog:
PR driver/111700
* c-c++-common/diagnostic-format-sarif-file-pr111700.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/111728] C++ 20 coroutine segmentation fault in generic lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Reduced to just using coroutine header file:
```
#include 
struct promise;
struct coroutine : std::coroutine_handle
{
using promise_type = ::promise;
bool await_ready() { return false; }
void await_suspend( coroutine_handle h) {}
int await_resume() {}
};
struct promise
{
coroutine get_return_object() { return {coroutine::from_promise(*this)}; }
std::suspend_always initial_suspend() noexcept { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}
};
coroutine 
write_fields() {
  int static_buffer[10];
  co_await [](auto)
  -> coroutine 
  {
if (sizeof(static_buffer));
  co_return;
  }(0);
}
```

Confirmed.

[Bug tree-optimization/111668] [12/13 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

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

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

--- Comment #8 from Krister Walfridsson  ---
I still see negation of a wide signed Boolean in the IR for this function. But
now it is forwprop4 that changes

  _38 = (signed int) _16;
  _43 = -_38;
  _66 = () _43;

to

  _56 = () _16;
  _66 = -_56;

[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #8)
> Created attachment 56073 [details]
> "Fix" for this PR
> 
> Hi Harald,
> 
> You are touching the right place. However, this should be happening in
> gfc_conv_expr_descriptor I would have thought so that strlen_lhs comes back
> with the correct value.

Yes, this might be a latent issue still showing up elsewhere for deferred
length, although your patch seems to fix cases immediately related to
those in this PR.

I was suspecting gfc_conv_variable as a possibly further place for a fix:
it has a loop over ref's that looks incomplete for REF_COMPONENT.

Nevertheless, your patch works for me.

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #20 from Jeremy R.  ---
Silently ruining the behavior of the rest of a program and leaving the
programmer to pull their hair out over what on earth is happening seems very
un-ideal behavior.

This is a very easy mistake to make and the current behavior makes tracking
down that mistake exceedingly difficult.

I do recognize the concerns here about existing programs and crashing being
arguably less friendly, but something should be done here. 

Libc++ and msvc's stl both segfault and there's some value in making the
behavior here consistent.

(In reply to Jonathan Wakely from comment #13)
> I'm not suggesting we should print "(null)", that would be crazy
Maybe, but it's also a nice middle ground between silently corrupting the
stream and crashing the program.

Throwing an exception, even only in debug, also seems reasonable as existing
programs may be able to recover from the exception without crashing.

[Bug c/111708] Calling external global function instead of local static function.

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #7 from Martin Uecker  ---
Created attachment 56075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56075&action=edit
patch adding error external / internal mismatch of functions


Untested patch.

[Bug libstdc++/111729] Design considerations for operator<<(basic_ostream&, const charT*)

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
Thank you for the quick response

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

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

[Bug libstdc++/111729] Design considerations for operator<<(basic_ostream&, const charT*)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 86130.

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

[Bug libstdc++/111729] New: Design considerations for operator<<(basic_ostream&, const charT*)

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 111729
   Summary: Design considerations for operator<<(basic_ostream&,
const charT*)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following program violates a precondition specified in the standard and is
UB however it leads to some surprising behavior

#include 
int main() {
std::cout<<(const char*)nullptr;
std::cout<<"test";
}

There is no segfault, no abort, no non-zero exit status, and no exception.
Instead the program silently continues with the output stream's badbit set.
This can silently ruin the behavior of the rest of the program leaving the
programmer to pull their hair out over what on earth is happening.

Yes, it's UB and the programmer can't expect anything, however it's a very easy
mistake to make and the current behavior makes tracking down that mistake
exceedingly difficult.

I would like to humbly suggest that any of the following behaviors would be
better: Segfaulting, throwing an exception, aborting, an assertion failure in
debug, or printing "(null)" (which is the %s behavior). Libc++ and msvc's stl
both segfault here.

[Bug c++/111728] C++ 20 coroutine segmentation fault in generic lambda

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

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

--- Comment #1 from Andrew Pinski  ---
[apinski@xeond2 upstream-gcc-git]$ ~/upstream-gcc/bin/gcc main.cpp.ii 
-std=gnu++20
/home/yunus/Projects/terraqtt/examples/main.cpp: In instantiation of
‘write_fields(write_fields()::_Z12write_fieldsv.Frame*)::
[with auto:50 = int]’:
/home/yunus/Projects/terraqtt/examples/main.cpp:12:4:   required from here
/home/yunus/Projects/terraqtt/examples/main.cpp:12:3: internal compiler error:
in rewrite_param_uses, at cp/coroutines.cc:3798
0x792564 rewrite_param_uses
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3798
0x1613da4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0x1613ef8 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11634
0xad2426 rewrite_param_uses
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:3786
0x1613da4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11400
0xccfdcc cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/tree.cc:5591
0x1613e13 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11424
0x1613ef8 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11634
0x16144a3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree.cc:11516
0xaca338 coro_rewrite_function_body
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:4205
0xacf3f5 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/coroutines.cc:4485
0xb24b59 finish_function(bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl.cc:18168
0xc700a6 instantiate_body
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:27110
0xc81bcb instantiate_decl(tree_node*, bool, bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:27379
0xc92d5b instantiate_pending_templates(int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:27457
0xb3b2d1 c_parse_final_cleanups()
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl2.cc:5060
0xd7bfc0 c_common_parse_file()
/home/apinski/src/upstream-gcc-git/gcc/gcc/c-family/c-opts.cc:1296
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++/111728] New: C++ 20 coroutine segmentation fault in generic lambda

[yunus at ayar dot eu via Gcc-bugs]

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

Bug ID: 111728
   Summary: C++ 20 coroutine segmentation fault in generic lambda
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunus at ayar dot eu
  Target Milestone: ---

Created attachment 56074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56074&action=edit
Compressed version of main.cpp.ii (~ 5.5 MB) from g++ -save-temps

The following code causes a segmentation fault with ASIO 1.28, C++ 20's
coroutines and evaluating of expressions inside a generic coroutine lambda. I
tried to strip the test case as much as possible:

```cpp
#include 
#include 

inline asio::awaitable write_fields()
{
  std::byte static_buffer[10];

  co_await [&](auto field) -> asio::awaitable {
// Next line is not ok.
if (0 == sizeof(static_buffer));
co_return 0;
  }(0);

  co_return 0;
}

int main() { static_cast(write_fields()); }
```


My exact version:

```txt
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230728 (Red Hat 13.2.1-1) (GCC)
```


I compiled the attached (main.cpp.ii) with: g++ main.cpp.ii -std=gnu++20
The following output was generated:

```txt
/home/yunus/Projects/terraqtt/examples/main.cpp: In instantiation of
‘write_fields(write_fields()::_Z12write_fieldsv.Frame*)::
[with auto:50 = int]’:
/home/yunus/Projects/terraqtt/examples/main.cpp:12:4:   required from here
/home/yunus/Projects/terraqtt/examples/main.cpp:12:3: internal compiler error:
Segmentation fault
   12 |   }(0);
  |   ^
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/cchUnOPu.out file, please attach this to
your bugreport.
```

[Bug tree-optimization/111727] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Version|unknown |14.0
   Keywords||wrong-code
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-08
Summary|wrong code at -O3 on|[14 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

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

[Bug tree-optimization/111727] New: wrong code at -O3 on x86_64-linux-gnu

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

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

Bug ID: 111727
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/xherWE8x6

It might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652.

[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231008 (experimental) (GCC) 
[509] % 
[509] % gcctk -O2 small.c; ./a.out
[510] % 
[510] % gcctk -O3 small.c
[511] % ./a.out
Aborted
[512] % cat small.c
int a, b, c;
int main() {
  for (; a < 2; a += 2) {
for (b = 0; b < 1; b++)
  if (a < 1)
c = 0;
for (; c < 1; c++)
  ;
}
  if (a != 2)
__builtin_abort();
  return 0;
}

[Bug libstdc++/111726] lgamma usage in std::poisson_distribution could cause a Data race

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Data race in|lgamma usage in
   |std::poisson_distribution   |std::poisson_distribution
   ||could cause a Data race

--- Comment #1 from Andrew Pinski  ---
(In reply to Krisztián Rugási from comment #0)
> As far as I can tell this issue has been present since the initial
> implementation of std::poisson_distribution.
> The cause of it is that the implementation uses the lgamma function, which
> modifies a global variable.

I am not 100% sure but since _M_initialize does not use signgam, this is just 2
writes to a global variable that will not be read so the data write race is
100% ok.

[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault

[frank.scheiner at web dot de via Gcc-bugs]

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

--- Comment #7 from Frank Scheiner  ---
Hi again,

this problem was bisected by me and I identified the following commit as first
bad commit:

[5fc4d3e1837](https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/cselib.cc;h=2abc763a3f8ed4f7bb2460b8fd9cba94b6520b59;hp=9b582e5d3d6db03dd6e47d331830a5ef04fcae31;hb=5fc4d3e1837;hpb=e9d50e7a4e290d7476cc7e6b5a8f2f1fb496c570)

Reverting this one for "gcc-releases/gcc-13.1.0" (plus reverting an older
surrounding change ([1]) that broke the build for me) allows to build Linux
v6.6-rc3 without gcc ICEing on valid code in the two mentioned files.

Actually [1] breaks the build for me and [5fc4d3e1837] unbreaks it, but instead
breaks operation for specical cases.

[1]:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0b00b63a39108311f2e6f9cbe9072579f57df7c



Tomáš Glozar  further debugged this and will add his
findings as soon as his account is approved here. I couldn't add his email
address to the CC list, so maybe this depends on the account approval, too.

Cheers,
Frank

P.S.
The bisect log:
```
root@dl380-g7:/usr/src/gcc# git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [0afa9dfb8fb3302db7f104add5654436927dcb56] c: support the attribute
starting with '_'
git bisect good 0afa9dfb8fb3302db7f104add5654436927dcb56
# status: waiting for bad commit, 1 good commit known
# bad: [ed7278d98e4727a7def30ab91fcef4658e34baa4] git_update_version: add
robust logging
git bisect bad ed7278d98e4727a7def30ab91fcef4658e34baa4
# good: [ba3e5a3826be53ecbb7d6044c50878d44640c296] rs6000: Rework
vsx_extract_
git bisect good ba3e5a3826be53ecbb7d6044c50878d44640c296
# good: [e9d50e7a4e290d7476cc7e6b5a8f2f1fb496c570] Setting explicit NANs sets
UNDEFINED for -ffinite-math-only.
git bisect good e9d50e7a4e290d7476cc7e6b5a8f2f1fb496c570
# bad: [847f5addc4d07a2f3b95f5daa50ab4a64dfd957d] openmp: Map holds clause to
IFN_ASSUME for C/C++
git bisect bad 847f5addc4d07a2f3b95f5daa50ab4a64dfd957d
# bad: [08b51baddc53d64aa4c5e7a81ef3c4bf320293be] c++, c: Implement C++23
P1774R8 - Portable assumptions [PR106654]
git bisect bad 08b51baddc53d64aa4c5e7a81ef3c4bf320293be
# bad: [5fc4d3e1837ea4850aac6460f563913f1d3fc5b8] cselib: Skip BImode while
keeping track of subvalue relations [PR107088]
git bisect bad 5fc4d3e1837ea4850aac6460f563913f1d3fc5b8
# first bad commit: [5fc4d3e1837ea4850aac6460f563913f1d3fc5b8] cselib: Skip
BImode while keeping track of subvalue relations [PR107088]
```

[Bug libstdc++/111726] New: Data race in std::poisson_distribution

[rugasikrisztian at gmail dot com via Gcc-bugs]

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

Bug ID: 111726
   Summary: Data race in std::poisson_distribution
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rugasikrisztian at gmail dot com
  Target Milestone: ---

The following program, which uses separate std::poisson_distribution instances
on multiple threads, has a data race in both the constructor and operator() of
the distribution:

https://godbolt.org/z/r1ojKdYna


#include 
#include 

int rand_poisson() {
thread_local std::mt19937_64 gen{ 0x123456789 };
std::poisson_distribution dist{ 15.0 };
return dist(gen);
}

int main() {
std::jthread T1{ rand_poisson };
std::jthread T2{ rand_poisson };
}


Compiled with gcc 13.2 and the options -std=c++20 -O3 -fsanitize=thread, the
output is:

==
WARNING: ThreadSanitizer: data race (pid=1)
  Write of size 4 at 0x7fed5e87a108 by thread T2:
#0 lgamma  (libtsan.so.2+0x536da) (BuildId:
dd14181575b14129bf3264ad0047089fc45e39d4)
#1 std::poisson_distribution::param_type::_M_initialize()
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/random.tcc:1275
(output.s+0x4014a0) (BuildId: 835919b751a9e2f5ac4bdd461e8f650240b0a6eb)
#2 std::poisson_distribution::param_type::param_type(double)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/random.h:4573
(output.s+0x4014a0)
#3 std::poisson_distribution::poisson_distribution(double)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/random.h:4609
(output.s+0x4014a0)
#4 rand_poisson() /app/example.cpp:6 (output.s+0x4014a0)
#5 int std::__invoke_impl(std::__invoke_other, int (*&&)())
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/invoke.h:61
(output.s+0x401559) (BuildId: 835919b751a9e2f5ac4bdd461e8f650240b0a6eb)
#6 std::__invoke_result::type std::__invoke(int
(*&&)()) /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/invoke.h:96
(output.s+0x401559)
#7 int std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:292
(output.s+0x401559)
#8 std::thread::_Invoker >::operator()()
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:299
(output.s+0x401559)
#9 std::thread::_State_impl >
>::_M_run()
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:244
(output.s+0x401559)
#10   (libstdc++.so.6+0xe8ad2) (BuildId:
9f3caf39aab289429a6a218ddc8d4c9ff5ef08a4)

  Previous write of size 4 at 0x7fed5e87a108 by thread T1:
#0 lgamma  (libtsan.so.2+0x536da) (BuildId:
dd14181575b14129bf3264ad0047089fc45e39d4)
#1 int
std::poisson_distribution::operator()
>(std::mersenne_twister_engine&, std::poisson_distribution::param_type const&)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/random.tcc:1388
(output.s+0x40255c) (BuildId: 835919b751a9e2f5ac4bdd461e8f650240b0a6eb)
#2 int
std::poisson_distribution::operator()
>(std::mersenne_twister_engine&)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/random.h:4666
(output.s+0x401524) (BuildId: 835919b751a9e2f5ac4bdd461e8f650240b0a6eb)
#3 rand_poisson() /app/example.cpp:7 (output.s+0x401524)
#4 int std::__invoke_impl(std::__invoke_other, int (*&&)())
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/invoke.h:61
(output.s+0x401559) (BuildId: 835919b751a9e2f5ac4bdd461e8f650240b0a6eb)
#5 std::__invoke_result::type std::__invoke(int
(*&&)()) /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/invoke.h:96
(output.s+0x401559)
#6 int std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:292
(output.s+0x401559)
#7 std::thread::_Invoker >::operator()()
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:299
(output.s+0x401559)
#8 std::thread::_State_impl >
>::_M_run()
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/std_thread.h:244
(output.s+0x401559)
#9   (libstdc++.so.6+0xe8ad2) (BuildId:
9f3caf39aab289429a6a218ddc8d4c9ff5ef08a4)

  Location is global '__signgam' of size 4 at 0x7fed5e87a108
(libm.so.6+0x14e108)

  Thread T2 (tid=4, running) created by main thread at:
#0 pthread_create  (libtsan.so.2+0x40cd6) (BuildId:
dd14181575b14129bf3264ad0047089fc45e39d4)
#1 std::thread::_M_start_thread(std::unique_ptr >, void (*)()) 
(libstdc++.so.6+0xe8e4b) (BuildId: 9f3caf39aab289429a6a218ddc8d4c9ff5ef08a4)
#2 main /app/example.cpp:12 (output.s+0x40126a) (BuildId:
835919b751a9e2f5ac4bdd461e8f650240b0a6eb)

  Thread T1 (tid=3, finished) created by main thread at:
#0 pthread_create  (libtsan.so.2+0x40cd6) (BuildId:
dd14181575b14129bf3264ad0047089fc45e39d4)
#1 std::thread::_M_start_thread(std::unique_ptr >, void (*)()) 
(libstdc++.so.6+0xe

[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd

[guojie at loongson dot cn via Gcc-bugs]

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

Guo Jie  changed:

   What|Removed |Added

 CC||guojie at loongson dot cn

--- Comment #2 from Guo Jie  ---
It seems that “omp simd reduction” cannot collaborate well with “loop peeling”,
which will result in a probability error in this test case.

LoongArch tree vect pass dump:

  # “omp simd” temporary arrays.
  struct S D.3833[8];
  struct S D.3832[8];
  ...


  # prologue loop.
   [local count: 723433550]:
  MEM  [(struct S *)&D.3832][0].s = 0;
  _44 = D.3832[0].s;
  _41 = (long unsigned int) i_1;
  _58 = _41 * 4;
  _59 = a_18(D) + _58;
  _60 = _59->s;
  _61 = _44 + _60;
  D.3832[0].s = _61;
  _64 = D.3833[0].s;
  _65 = D.3832[0].s;
  _66 = _64 + _65;
  D.3833[0].s = _66;  # Save temporary reduction results.
  MEM  [(struct S *)&D.3832][0].s = _66;
  _69 = b_28(D) + _58;
  _70 = MEM  [(const struct S &)&D.3832][0].s;
  _69->s = _70;
  i_72 = i_1 + 1;
  ivtmp_73 = ivtmp_2 - 1;
  ivtmp_78 = ivtmp_77 + 1;
  if (ivtmp_78 < prolog_loop_niters.42_7)
goto ; [85.71%]
  else
goto ; [14.29%]
  [local count: 620085901]:
  goto ; [100.00%]


  # vector body loop.
   [local count: 118111599]:
  # i_48 = PHI 
  # ivtmp_55 = PHI 
  # vectp_a.50_126 = PHI 
  # vectp_b.58_158 = PHI 
  # ivtmp_161 = PHI 
  MEM  [(struct S *)&D.3832] = { 0, 0, 0, 0, 0, 0, 0, 0 };
  _16 = (long unsigned int) i_48;
  _17 = _16 * 4;
  _19 = a_18(D) + _17;
  vect__20.52_128 = MEM  [(int *)vectp_a.50_126];
  _20 = _19->s;
  MEM  [(int *)&D.3832] = vect__20.52_128;
  vect__24.54_131 = MEM  [(int *)&D.3833]; # Wrong value.
  ...
  vect__26.56_133 = vect__20.52_128 + vect__24.54_131;
  ...
  if (ivtmp_162 < bnd.44_109)
goto ; [0.00%]
  else
goto ; [100.00%]
  ...

The temporary reduction result of “prologue loop” is only stored in D.3833[0],
and all other elements of D.3833 are 0. Therefore, only the first element of
vect__26.56_133 accumulates the scalar reduction result of “prologue loop”. 

I think the reasonable solution should be to broadcast the scalar reduction
result of “prologue loop” to all elements of D.3833.

[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
Created attachment 56073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56073&action=edit
"Fix" for this PR

Hi Harald,

You are touching the right place. However, this should be happening in
gfc_conv_expr_descriptor I would have thought so that strlen_lhs comes back
with the correct value.

Cheers

Paul

[Bug c/111708] Calling external global function instead of local static function.

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #6 from Martin Uecker  ---

I think your nested declaration of "extern int f(int);" has external linkage,
because the declaration with internal linkage is not visible (it is hidden by
the definition of the object with no linkage). So I agree this is compile-time
UB and we miss the warning which we have for objects.

[Bug target/111725] New: Missed one vsetvl

[lehua.ding at rivai dot ai via Gcc-bugs]

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

Bug ID: 111725
   Summary: Missed one vsetvl
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lehua.ding at rivai dot ai
  Target Milestone: ---

online: https://godbolt.org/z/br456cPs8
C Code (compiler option: -march=rv32gcv -mabi=ilp32d -S -fno-schedule-insns
-fno-schedule-insns2  -fno-tree-vectorize -frename-registers -O2):

#include "riscv_vector.h"

float f (int8_t * restrict in, int8_t * restrict out, int n, int m, unsigned
cond, size_t vl, float scalar)
{
  vbool64_t mask = *(vbool64_t*) (in + 100);

  for (size_t i = 0; i < n; i++)
{
  vfloat32mf2_t v = __riscv_vle32_v_f32mf2 ((float *)(in + i + 200),
__riscv_vsetvlmax_e32mf2 ());
  __riscv_vse32_v_f32mf2 ((float *)(out + i + 200), v,
__riscv_vsetvlmax_e32mf2 ());

  vfloat32mf2_t v2 = __riscv_vle32_v_f32mf2_tumu (mask, v, (float *)(in + i
+ 300), __riscv_vsetvlmax_e32mf2 ());
  __riscv_vse32_v_f32mf2_m (mask, (float *)(out + i + 300), v2,
__riscv_vsetvlmax_e32mf2 ());
}

  vfloat32m1_t v = *(vfloat32m1_t*)(in + 30);
  for (size_t i = 0; i < n; i++)
{
  v = __riscv_vfmv_s_f_f32m1_tu (v, (scalar + i), 3);
}
  v = __riscv_vfadd_vv_f32m1 (v,v, 3);
  return __riscv_vfmv_f_s_f32m1_f32 (v);
}

Assembly Code:

f:
li  a5,999424
addit0,a5,576
add t1,a0,t0
vsetvli a4,zero,e32,mf2,tu,mu
vlm.v   v0,0(t1)
beq a2,zero,.L2
addit5,a0,200
addit6,a1,300
addia6,a2,200
add t3,a0,a6
.L3:
vle32.v v1,0(t5)
addia3,t6,-100
vse32.v v1,0(a3)
addit4,t5,100
vle32.v v1,0(t4),v0.t
vse32.v v1,0(t6),v0.t
addit5,t5,1
addit6,t6,1
bne t5,t3,.L3
li  a5,299008
addit0,a5,992
add t1,a0,t0
vl1re32.v   v2,0(t1)
li  a4,0
.L6:
fcvt.s.wu   fa5,a4
fadd.s  ft0,fa5,fa0
vfmv.s.fv2,ft0
addia4,a4,1
bne a4,a2,.L6
vfadd.vvv3,v2,v2 # Miss vsetivli zero,3,e32,m1,ta,ma
vfmv.f.sfa0,v3
ret
.L2:
li  t2,299008
addia1,t2,992
add a0,a0,a1
vl1re32.v   v2,0(a0)
vsetivlizero,3,e32,m1,ta,ma
vfadd.vvv3,v2,v2
vfmv.f.sfa0,v3
ret

[Bug tree-optimization/111724] New: [Regression] Missed optimizations probably because of too early arithmetic optimization

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 111724
   Summary: [Regression] Missed optimizations probably because of
too early arithmetic optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we found some optimizations (probably because of too early arithmetic
optimization) that GCC may have missed. We would greatly appreicate if you can
take a look and let us know what you think.

Given the following code:
https://godbolt.org/z/8EW8fx78K
int n;
void func(int w, int a, int b){
for(int i=0;iFrom original(tree):
   (void) (n = (a + b) * 2 + n) >;

This leads to:
  _1 = a_11(D) + b_18;
  _2 = _1 * 2;
  _4 = _2 + n_lsm.4_7;

So, it looks like the missed LICM is due to too early arithmetic optimization.

On gcc-6.4, it works as expected.

We found that this also affects other optimizations, such as common
subexpression elimination. We can provide examples if required.

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues

[fchelnokov at gmail dot com via Gcc-bugs]

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

Fedor Chelnokov  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #4 from Fedor Chelnokov  ---
Related discussion: https://stackoverflow.com/q/77051011/7325599

And an example from it:

int main() {
using U = int(&&)[1];
(void) *U{}; //ok everywhere

using T = int[1];
(void) *T{}; //error in GCC
}

Online demo: https://godbolt.org/z/4s8v9PPqT