[Bug fortran/106100] New: where

[xiao.liu--- via Gcc-bugs]

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

Bug ID: 106100
   Summary: where
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiao@compiler-dev.com
  Target Milestone: ---

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #1 from Xi Ruoyao  ---
Stage 1 GCC generates some very strange code for stage 2 GCC, jumping to
"0x2000":

.L747:
beqz$r12,.L750
lu12i.w $r13,8192>>12   # 0x2000
ld.d$r5,$r26,8
add.d   $r3,$r3,$r13
ld.d$r1,$r3,168
ld.d$r22,$r3,160
ld.d$r23,$r3,152
ld.d$r24,$r3,144
ld.d$r26,$r3,128
ld.d$r27,$r3,120
ld.d$r28,$r3,112
ld.d$r29,$r3,104
ld.d$r30,$r3,96
ld.d$r31,$r3,88
or  $r4,$r25,$r0
ld.d$r25,$r3,136
addi.d  $r3,$r3,176
jr  $r13

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from chenglulu  ---
Created attachment 53205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53205&action=edit
0001-Fix-bug-for-PR16097.patch

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

Sascha Wilde  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|UNCONFIRMED
Version|10.2.0  |12.1.0

--- Comment #29 from Sascha Wilde  ---
Unfortunately the problem is still not fully resolved.
When bootstrapping the compiler (tested with 12.1 on NetBSD 9.2) libintl is
still build without -fPIC, however, when manually rebuilding libintl it is
build
correctly without any changes to the Makefile:

gmake BOOT_CFLAGS='-O' -j2 bootstrap   # wrong result, due to libintl w/o -fPIC
cd intl
gmake -j2 clean
gmake -j2  # builds a sane libintl with -fPIC
cd ..
gmake BOOT_CFLAGS='-O' -j2  # now results in a woring compiler and libgccjit.so

No idea why that is, but it's fully reproachable...

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #7 from Xi Ruoyao  ---
(In reply to chenglulu from comment #6)
> Created attachment 53205 [details]
> 0001-Fix-bug-for-PR16097.patch

You can reuse LU32I_B and LU52I_B instead of hard coding those long constants
:).

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #8 from chenglulu  ---
> You can reuse LU32I_B and LU52I_B instead of hard coding those long
> constants :).

I have fixed it, thanks！:)

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE in reject_statement, at |ICE in reject_statement, at
   |fortran/parse.cc:2879   |fortran/parse.cc:2879 since
   ||r8-3056-g5bab4c9631c478b7
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Likely started with r8-3056-g5bab4c9631c478b7, it was rejected before the
revision anyway.

[Bug middle-end/106056] Missing call to targetm.asm_out.final_postscan_insn after processing an asm_input

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-06-27
 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Thanks for the suggestion, do you have a test-case which is affected?

[Bug target/106053] [13 Regression] wrong code with -O -fno-tree-fre since r13-707-g68e0063397ba820e

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-27
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |with -O -fno-tree-fre   |with -O -fno-tree-fre since
   ||r13-707-g68e0063397ba820e
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r13-707-g68e0063397ba820e.

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #9 from chenglulu  ---
Created attachment 53206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53206&action=edit
use LU52I_B and LU32I_B instead of hard coding those long

[Bug fortran/106048] [10/11/12/13 Regression] ICE in ubsan_encode_value, at ubsan.cc:143 / verify_gimple failed

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Last reconfirmed||2022-06-27
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Likely started with r8-3365-gb89a63b916340ef2.

[Bug tree-optimization/106073] [12/13 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-3903-g0288527f47cec669

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org
Summary|[12/13 Regression] wrong|[12/13 Regression] wrong
   |code at -O3 on  |code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-3903-g0288527f47cec669

--- Comment #3 from Martin Liška  ---
Started with r12-3903-g0288527f47cec669.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Fri, 24 Jun 2022, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
> 
> --- Comment #12 from H.J. Lu  ---
> (In reply to Richard Biener from comment #11)
> > No, I think you would need to pattern match an actual store sequence,
> > for example by looking at
> > 
> >  if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
> >  && pow2p_hwi (DR_GROUP_STORE_COUNT (stmt_info)))
> >/* cost a possibly merged store only once (but with larger mode?) */
> >if (DR_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info)
> >  ...
> 
> The information aren't available in add_stmt_cost.

They should be ...

[Bug tree-optimization/106087] Segmentation fault in GIMPLE pass: ccp

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Dup.

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

[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||nyh at math dot technion.ac.il

--- Comment #8 from Martin Liška  ---
*** Bug 106087 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106099] ICE in execute_todo, at passes.cc:2134

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
A simple C testcase:
$ cat testcase.c
void
foo (void)
{
  for (unsigned i = 0; i < sizeof (foo); i++)
;
}
$ x86_64-pc-linux-gnu-gcc -O -fsanitize=unreachable
-fsanitize-undefined-trap-on-error -fno-tree-ccp -fno-tree-dominator-opts
testcase.c
during GIMPLE pass: ivcanon
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in execute_todo, at passes.cc:2134
2 | foo (void)
  | ^~~
0x755240 execute_todo
/repo/gcc-trunk/gcc/passes.cc:2134
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 rtl-optimization/106082] [13 Regression] Recent change broke m68k

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||ice-checking,
   ||ice-on-valid-code

--- Comment #2 from Richard Biener  ---
Not sure if I am qualified to look but if there's a problematical
distribute_notes operation then the guards in try_combine need amending.

Maybe __clear_cache is somehow wrongly annotated.

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2022-06-27
Summary|ICE in execute_todo, at |[13 Regression] ICE in
   |passes.cc:2134  |execute_todo, at
   ||passes.cc:2134 since
   ||r13-1204-gd68d366425369649

--- Comment #2 from Martin Liška  ---
Started with r13-1204-gd68d366425369649.

[Bug middle-end/106081] missed vectorization

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

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

Martin Liška  changed:

   What|Removed |Added

 Blocks||26163
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-27
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug gcov-profile/106036] Missing stdint.h include in libgcc/libgcov.h

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Thanks for clarification, closing as invalid.

[Bug target/106053] [13 Regression] wrong code with -O -fno-tree-fre since r13-707-g68e0063397ba820e

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Liška from comment #2)
> Started with r13-1204-gd68d366425369649.

Since -funreachable-traps is a new option, is this a regression then?

[Bug rtl-optimization/106101] New: [12/13 Regression] ICE in reg_bitfield_target_p

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

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

Bug ID: 106101
   Summary: [12/13 Regression] ICE in reg_bitfield_target_p
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Testcase reduced from opie

> ./cc1 -quiet /tmp/y.tab.i -O -I include -w
during RTL pass: combine
/tmp/y.tab.i: In function ‘yyparse’:
/tmp/y.tab.i:59:1: internal compiler error: Segmentation fault
   59 | }
  | ^
0x14010ac crash_signal
/space/rguenther/src/gcc/gcc/toplev.cc:322
0x21932ef reg_bitfield_target_p
/space/rguenther/src/gcc/gcc/combine.cc:14142
0x219473f distribute_notes
/space/rguenther/src/gcc/gcc/combine.cc:14653
0x2173f8f try_combine
/space/rguenther/src/gcc/gcc/combine.cc:4485
0x216a2f6 combine_instructions
/space/rguenther/src/gcc/gcc/combine.cc:1268
0x2195541 rest_of_handle_combine
/space/rguenther/src/gcc/gcc/combine.cc:14976
0x2195602 execute
/space/rguenther/src/gcc/gcc/combine.cc:15021
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 rtl-optimization/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.2
 Target||s390x-*-*

[Bug rtl-optimization/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #1 from Richard Biener  ---
Created attachment 53207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53207&action=edit
reduced testcase

[Bug rtl-optimization/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-27
   Keywords||needs-bisection
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Program received signal SIGSEGV, Segmentation fault.
0x021932ef in reg_bitfield_target_p (x=0x76a4ee10,
body=0x76a4e450) at /space/rguenther/src/gcc/gcc/combine.cc:14142
14142 if (GET_CODE (target) == SUBREG)
(gdb) p target
$1 = (rtx) 0xafafaf010047

one frame up:

(gdb) p debug_rtx (place)
(insn 24 52 25 4 (set (strict_low_part (reg/v:SI 71 [ yyval ]))
(mem/f:SI (plus:DI (reg:DI 85)
(const_int 4 [0x4])) [2 *_3+4 S4 A32])) "/tmp/y.tab.i":41:23
1485 {movstrictsi}
 (nil))

static int
reg_bitfield_target_p (rtx x, rtx body)
{
...
  else if (GET_CODE (dest) == STRICT_LOW_PART)
target = SUBREG_REG (XEXP (dest, 0));

but the strict_low_part doesn't contain a SUBREG ...!?  Adding a check to
that avail would of course fix this.

It's all ancient code though...

[Bug tree-optimization/106070] [13 Regression] Wrong code with -O1 since r13-469-g9a53101caadae1b5

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #9 from Richard Earnshaw  ---
The testcase incorrectly assumes that long is 64-bits.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 106070 Summary: [13 Regression] Wrong code with -O1 since 
r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug demangler/105039] rust demangler stack overflow

[hs.naveen2u at gmail dot com via Gcc-bugs]

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

hs.naveen2u at gmail dot com changed:

   What|Removed |Added

 CC||hs.naveen2u at gmail dot com

--- Comment #3 from hs.naveen2u at gmail dot com ---
Can anyone please review the patch so that it can be used?

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu since r13-911

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #2 from Xi Ruoyao  ---
Created attachment 53208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53208&action=edit
reduced testcase

It looks like a LoongArch code generation issue, not really related to the
changes in r13-911.

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

  Build|loongarch64-linux-gnu   |
Summary|[13 regression] ICE |[13 regression] ICE
   |building stage 2 libgcc on  |building stage 2 libgcc on
   |loongarch64-linux-gnu since |loongarch64-linux-gnu
   |r13-911 |because stage 2 gcc is
   ||miscompiled
   Host|loongarch64-linux-gnu   |

--- Comment #3 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #2)
> Created attachment 53208 [details]
> reduced testcase

For this testcase GCC generates:

.L20:
lu12i.w $r13,4096>>12   # 0x1000
add.d   $r3,$r3,$r13
ld.d$r1,$r3,24
or  $r4,$r23,$r0
ld.d$r23,$r3,16
la.local$r5,b
addi.d  $r3,$r3,32
jr  $r13

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

  Known to work|12.1.0  |

--- Comment #4 from Xi Ruoyao  ---
Remove "known to work" because 12.1.0 miscompiles the test case too.

[Bug tree-optimization/106070] [13 Regression] Wrong code with -O1 since r13-469-g9a53101caadae1b5

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

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

--- Comment #10 from Richard Earnshaw  ---
the testcase in the committed patch, that is.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
See also bug 104799.

[Bug middle-end/106056] Missing call to targetm.asm_out.final_postscan_insn after processing an asm_input

[piannetta at kalrayinc dot com via Gcc-bugs]

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

--- Comment #2 from Paul Iannetta  ---
Right now, I can't pinpoint a test-case within the official gcc testsuite, and
the list of targets which define TARGET_ASM_FINAL_POSTSCAN_INSN is limited to:
mips, avr and m68k.  From my understanding the only target that might be
affected is avr.

However, we maintain a VLIW target and rely on this hook to append our bundle
separator and there is a discrepancy between the treatment of extended asm and
basic asm blocks.

```
asm ("nop":::);
asm ("nop":::);
```

Each extended asm block triggers final_postscan and our bundle separator is
rightfully inserted.  However,

```
asm ("nop");
asm ("nop");
```

does not trigger final_postscan and the bundle separator is missing.

[Bug c++/106102] New: gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

Bug ID: 106102
   Summary: gcc/cp/mapper-resolver.cc fails to build against musl:
musl-1.2.3-dev/include/sched.h:84:7: error: attempt to
use poisoned "calloc"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

For build errors like 'error: attempt to use poisoned "calloc"': is it a gcc
bug or libc bug?

At least on musl libc gcc marks calloc() as '#pragma GCC poison' but later
stumbles on '#define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))'
from musl's own sched.h.

Here is an example failure on this week's gcc:

/build/build/./prev-gcc/xg++ -B/build/build/./prev-gcc/
-B/<>/gcc-13.0.0/x86_64-unknown-linux-musl/bin/ -nostdinc++
-B/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/src/.libs
-B/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/libsupc++/.libs 
-I/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl
 -I/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include 
-I/build/gcc-13-20220626/libstdc++-v3/libsupc++
-L/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/src/.libs
-L/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -O2 -I/<>/musl-1.2.3-dev/include
-B/<>/musl-1.2.3/lib/ -idirafter /<>/musl-1.2.3-dev/include
-idirafter
/<>/bootstrap-tools/lib/gcc/x86_64-unknown-linux-musl/7.3.0/include-fixed
-Wl,-rpath,/<>/gcc-13.0.0-lib/lib -Wl,-L/<>/musl-1.2.3/lib -Wl,-rpath
-Wl,/<>/musl-1.2.3/lib
-Wl,-dynamic-linker=/<>/musl-1.2.3/lib/ld-musl-x86_64.so.1 -fno-checking
-gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Icp
-I../../gcc-13-20220626/gcc -I../../gcc-13-20220626/gcc/cp
-I../../gcc-13-20220626/gcc/../include
-I../../gcc-13-20220626/gcc/../libcpp/include
-I../../gcc-13-20220626/gcc/../libcody
-I/<>/gmp-with-cxx-6.2.1-dev/include -I/<>/mpfr-4.1.0-dev/include
-I/<>/libmpc-1.2.1/include  -I../../gcc-13-20220626/gcc/../libdecnumber
-I../../gcc-13-20220626/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-13-20220626/gcc/../libbacktrace -I/<>/isl-0.20/include  -o
cp/mapper-resolver.o -MT cp/mapper-resolver.o -MMD -MP -MF
cp/.deps/mapper-resolver.TPo ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr.h:148,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/ext/atomicity.h:35,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/bits/shared_ptr_base.h:61,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/bits/shared_ptr.h:53,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
 from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
 from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned
"calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned
"calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^
make[3]: *** [Makefile:1143: cp/mapper-resolver.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod lto-dump.pod gfdl.pod gpl.pod cpp.pod gcc.pod gcov-tool.pod
gcov.pod gcov-dump.pod
make[3]: Leaving directory '/build/build/gcc'
make[2]: *** [Makefile:5000: all-stage2-gcc] Error 2
make[2]: Leaving directory '/build/build'
make[1]: *** [Makefile:24628: stage2-bubble] Error 2
make[1]: Leaving directory '/build/build'
make: *** [Makefile:24840: bootstrap] Error 2

gcc is configured as:

./configure --prefix=/<>/gcc-13.0.0
--with-gmp-include=/<>/gmp-with-cxx-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-with-cxx-6.2.1/lib
--with-mpfr-include=/<>/mpfr-4.1.0-dev/include
--with-mpfr-lib=/<>/mpfr-4.1.0/lib --with-mpc=/<>/libmpc-1.2.1
--with-libelf=/<>/libelf-0.8.13
--with-native-system-header-dir=/<>/musl-1.2.3-dev/include
--pro

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

--- Comment #9 from Alex Coplan  ---
So if f is UB, I suppose the question is whether the codegen for g is correct?

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

--- Comment #10 from Jakub Jelinek  ---
IMHO it is.

[Bug middle-end/106081] missed vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org
 Blocks||53947

--- Comment #3 from Richard Biener  ---
Might be a bit easier case than PR103999 since the accumulation is in 'double'
here.  In fact it should already work, but we fail to SLP the reduction
because

t.c:14:24: missed:   Build SLP failed: not grouped load _1 = *k_50;

and non-SLP as well:

t.c:14:24: note:   ==> examining statement: _1 = *k_50;
t.c:14:24: missed:   multiple types with negative step.
t.c:14:24: missed:   not falling back to elementwise accesses
t.c:16:30: missed:   not vectorized: relevant stmt not supported: _1 = *k_50;
t.c:14:24: missed:  bad operation or unsupported loop bound.

changing k-- to k++ lets us vectorize the code but in an awkward way
(SLP still fails on us so we get interleaving).

So the first thing to fix is SLP of non-grouped loads where I think we also
have a bug for.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/106088] ld cannot find dependent libraries when cross compiling

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Richard Biener  ---
Thus moved.

[Bug target/106091] [11/12/13 Regression] during RTL pass: swaps ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 69 with -fnon-call-exceptions

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in execute_todo, at |[13 Regression] ICE in
   |passes.cc:2134 since|execute_todo, at
   |r13-1204-gd68d366425369649  |passes.cc:2134 since
   ||r13-1204-gd68d366425369649
   Target Milestone|--- |13.0

[Bug fortran/106100] where

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #2 from Richard Biener  ---
The failure can only happen if system headers are included after gcc posioning.
All system headers need to be included from system.h for this reason.

I think gcc/cp/mapper-resolver.cc needs to arrange the
../../c++tools/resolver.cc code from not including anything.

[Bug lto/106103] New: ICE in binds_to_current_def_p when source object files are compiled with -flto -Os

[ivanka2012 at gmail dot com via Gcc-bugs]

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

Bug ID: 106103
   Summary: ICE in binds_to_current_def_p when source object files
are compiled with -flto -Os
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivanka2012 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-build_pc-linux-gnu
Target: x86_64-w64-mingw32
 Build: x86_64-build_pc-linux-gnu

Created attachment 53209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53209&action=edit
Source code that contains alc.cpp.ii, buffer.cpp.ii and openal-info.c.i

Compile the attached source files in the archive with the following commands:
x86_64-w64-mingw32-g++ -flto -Os -std=gnu++14 -o alc.o -c alc.cpp.ii
x86_64-w64-mingw32-g++ -flto -Os -std=gnu++14 -o buffer.o -c buffer.cpp.ii
x86_64-w64-mingw32-gcc -flto -Os -std=gnu11 -o openal-info.o -c openal-info.c.i
x86_64-w64-mingw32-g++ -r openal-info.o buffer.o alc.o -o /dev/null -lkernel32

The linker will yield the following:
during GIMPLE pass: dse
alc.cpp.ii: In function 'alcGetString':
alc.cpp.ii:1167:13: internal compiler error: in binds_to_current_def_p, at
symtab.cc:2494
 1167 | const char *alcGetString() try {
  | ^
0x681fd1 symtab_node::binds_to_current_def_p(symtab_node*)
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/symtab.cc:2494
0xc5a980 ref_maybe_used_by_call_p_1
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-alias.cc:2804
0xc5c137 ref_maybe_used_by_call_p
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-alias.cc:2929
0xc5c137 ref_maybe_used_by_stmt_p(gimple*, ao_ref*, bool)
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-alias.cc:2961
0xc7e517 dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-dse.cc:981
0xc7ff76 dse_optimize_stmt
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-dse.cc:1385
0xc7ff76 execute
   
/x/crosstool-ng/.build/x86_64-w64-mingw32/src/gcc/gcc/tree-ssa-dse.cc:1491

The compiler is configured with the following flags:
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=x86_64-w64-mingw32 --prefix=/prefix --exec_prefix=/prefix
--with-sysroot=/prefix/x86_64-w64-mingw32/sysroot
--enable-languages=c,c++,fortran --with-pkgversion='crosstool-NG
1.25.0.40_994767d' --disable-shared --enable-__cxa_atexit --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-libmpx
--disable-libstdcxx-verbose
--with-gmp=/x/crosstool-ng/.build/x86_64-w64-mingw32/buildtools
--with-mpfr=/x/crosstool-ng/.build/x86_64-w64-mingw32/buildtools
--with-mpc=/x/crosstool-ng/.build/x86_64-w64-mingw32/buildtools
--with-isl=/x/crosstool-ng/.build/x86_64-w64-mingw32/buildtools --enable-lto
--enable-threads=posix --enable-target-optspace --enable-plugin --disable-nls
--enable-multiarch --with-local-prefix=/prefix/x86_64-w64-mingw32/sysroot
--enable-long-long
However, this was supplied by crosstool-ng, which I used to compile the
toolchain. You might need to use that instead.
The toolchain can be compiled with crosstool-ng using the following:
./ct-ng x86_64-w64-mingw32
./ct-ng build
I also set the prefix to something more reasonable and all compiler and linker
flags were set to be '-g' but nothing else.

Notes:
This is already the most minimal possible test case. I tried fiddling with the
compiler and linker flags and the above combination is the most minimal one
that produces the ICE. The source code has also been processed with cvise for
several days.
I also observed this ICE in the "alias" GIMPLE pass in other test cases that
are not included here since I haven't reduced those.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #3 from Sergei Trofimovich  ---
Aha, that makes sense.

In this case include chain is:
- c++tools/resolver.cc
 -> c++tools/resolver.h
  -> libcody/cody.hh
-> libstdc++-v3/include/memory
  -> libstdc++-v3/include/bits/shared_ptr.h
-> ...
  -> libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h
   -> musl-1.2.3-dev/include/pthread.h
 -> musl-1.2.3-dev/include/sched.h [uses calloc()]

AFAIU libstdc++-v3/include are all user-facing libraries and are expected to
include system headers like .

It's a bit worrying that resolver.cc depends on  in such an indirect
way.

Would it be fair to say "system.h" needs to include  for this case and
be done with it?

Does gcc do any system header wrapping by chance to minimize such leaks? I'm
only asking because I noticed musl has different include order from glibc:
https://github.com/NixOS/nixpkgs/issues/142066#issuecomment-1159568114. I tried
to make include order alone closer to glibc and it did not fix the issue.

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

--- Comment #11 from Alex Coplan  ---
(In reply to Jakub Jelinek from comment #8)
> The IMHO UB case is for a != b when one address is at the start of one
> object and the other address is at the end of another one

Just to dig a little deeper on this, what makes this case UB? Is there
something in the standard to this effect?

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

[jbeulich at suse dot com via Gcc-bugs]

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

jbeulich at suse dot com changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #16 from jbeulich at suse dot com ---
(In reply to Hongtao.liu from comment #15)
> Fixed in GCC12.

Only almost - the new FMA testcase there fails for i?86-*-*. I don't think even
the few uses of VFMA* actually match the expectations. The majority of the
operations are carried in the FPU anyway, despite -mfpmath=sse.

[Bug target/106053] [13 Regression] wrong code with -O -fno-tree-fre since r13-707-g68e0063397ba820e

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

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

--- Comment #2 from Richard Biener  ---
It works with -mavx or when 'foo' is early inlined (using always-inline).

Working:

  u.1_8 = u;
  _9 = (long long unsigned int) u.1_8;
  u64_0_10 = _9 | 23725760132;
  _18 = u64_0_10 * 3095179400;
  _50 = _18 == 0;
  _53 = (__int128) _50;
  _54 = -_53;
  _58 = (__int128) _50;
  _59 = -_58;
  D.2295.a = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _69 = BIT_FIELD_REF ;
  _66 = BIT_FIELD_REF ;
  _67 = VIEW_CONVERT_EXPR(_54);
  _68 = _66 + _67;
  _70 = VIEW_CONVERT_EXPR(_59);
  _71 = _69 + _70;
  v256u8_r_26 = {_68, _71};
  x = v256u8_r_26;

not working:

  u.1_27 = u;
  _28 = (long long unsigned int) u.1_27;
  u64_0_29 = _28 | 23725760132;
  _38 = u64_0_29 * 3095179400;
  _56 = _38 == 0;
  _59 = (__int128) _56;
  _60 = -_59;
  D.2034.a = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _70 = BIT_FIELD_REF ;
  _67 = BIT_FIELD_REF ;
  _69 = _67 + { 4294967295, 4294967295, 4294967295, 4294967295 };
  _71 = VIEW_CONVERT_EXPR(_60);
  _72 = _70 + _71;
  BIT_FIELD_REF  = _69;
  BIT_FIELD_REF  = _72;

and CCP produces the bogus constant folded vector from

  _38 = u64_0_29 * 3095179400;
  _1 = () _38;
  _50 = _1 ^ 1;
  _53 = _50 & 1;
  _54 = (__int128) _53;
  _55 = -_54;
  _68 = VIEW_CONVERT_EXPR(_55);
  _69 = _68 + _67;

but it's interpretations are OK I think.  It must go wrong in veclower somehow,
the broken version ends up with a compare in signed-bool while the working
one uses an __int128 compare.

[Bug target/106104] New: PR 87007 testcase fails with 32-bit compiler

[jbeulich at suse dot com via Gcc-bugs]

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

Bug ID: 106104
   Summary: PR 87007 testcase fails with 32-bit compiler
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at suse dot com
  Target Milestone: ---

Much like just pointed out in PR 102464, FPU insns are used despite
-fpmath=sse, and hence no VXORPS would ever be emitted.

[Bug target/106104] PR 87007 testcase fails with 32-bit compiler

[jbeulich at suse dot com via Gcc-bugs]

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

jbeulich at suse dot com changed:

   What|Removed |Added

 Target||i?86-*-*

--- Comment #1 from jbeulich at suse dot com ---
Oddly enough the testcase succeeded in 9.3, failed in 10.3, succeeded again in
11.3, and now fails again.

[Bug testsuite/106105] New: new test case gcc.dg/torture/pr106070.c in r13-1243-gb36a1c964f9975 fails for 32 bits

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

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

Bug ID: 106105
   Summary: new test case gcc.dg/torture/pr106070.c in
r13-1243-gb36a1c964f9975 fails for 32 bits
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b36a1c964f99758de1f3b169628965d3c3af812b, r13-1243-gb36a1c964f9975

This fails on both power 7 and 8 BE for 32 bits.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg-torture.exp=gcc.dg/torture/pr106070.c"
FAIL: gcc.dg/torture/pr106070.c   -O0  execution test
FAIL: gcc.dg/torture/pr106070.c   -O1  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2  execution test
FAIL: gcc.dg/torture/pr106070.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/pr106070.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr106070.c   -Os  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
# of expected passes8
# of unexpected failures8


commit b36a1c964f99758de1f3b169628965d3c3af812b
Author: Richard Biener 
Date:   Fri Jun 24 13:37:22 2022 +0200

middle-end/106070 - bogus cond-expr folding

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

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

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

--- Comment #14 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #13)
> On Fri, 24 Jun 2022, hjl.tools at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
> > 
> > --- Comment #12 from H.J. Lu  ---
> > (In reply to Richard Biener from comment #11)
> > > No, I think you would need to pattern match an actual store sequence,
> > > for example by looking at
> > > 
> > >  if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
> > >  && pow2p_hwi (DR_GROUP_STORE_COUNT (stmt_info)))
> > >/* cost a possibly merged store only once (but with larger mode?) */
> > >if (DR_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info)
> > >  ...
> > 
> > The information aren't available in add_stmt_cost.
> 
> They should be ...

I meant that DR_GROUP_STORE_COUNT (stmt_info) was zero.

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #17 from jbeulich at suse dot com ---
Largely the same is actually true for the RNDSCALEPH test added for the PR
here.

[Bug tree-optimization/106070] [13 Regression] Wrong code with -O1 since r13-469-g9a53101caadae1b5

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

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

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

https://gcc.gnu.org/g:00063459f683adcd92ada8325984e6b10e9f7a95

commit r13-1299-g00063459f683adcd92ada8325984e6b10e9f7a95
Author: Jakub Jelinek 
Date:   Mon Jun 27 15:35:25 2022 +0200

testsuite: Fix up pr106070.c test [PR106070]

The test FAILs on 32-bit targets, because when unsigned long
is 32-bit, (unsigned long) -1 isn't 0x.
The options to fix this would be either using -1UL, or switch
to unsigned long long and using -1ULL, I chose the latter because
the test then FAILs in r13-1242 even on 32-bit targets.
And while at it, some deobfuscation and formatting tweaks.

2022-06-27  Jakub Jelinek  

PR tree-optimization/106070
* gcc.dg/torture/pr106070.c: Use unsigned long long instead of
unsigned long and -1ULL instead of 0x, deobcuscate
and improve formatting.

[Bug gcov-profile/106090] [GCOV] Wrong coverage for loop statements

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
No, it's correct as it only contains do_it() call that is triggered the same
number times as line 20 minus one.

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #9 from Martin Liška  ---
(In reply to luoxhu from comment #8)
> (In reply to rguent...@suse.de from comment #6)
> > On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
> > > 
> > > --- Comment #5 from Jakub Jelinek  ---
> > > The problem with switch-conversion done multiple times is that when it is 
> > > done
> > > early, it can do worse job than when it is done late, e.g. we can have 
> > > better
> > > range information later which allows (unfortunately switch-conversion 
> > > doesn't
> > > use that yet, there is a PR about it) to ignore some never reachable 
> > > values
> > > etc.
> > > So ideally we either need to be able to undo switch-conversion and redo 
> > > it if
> > > things have changed, or do it only late and for e.g. inlining costs 
> > > perform it
> > > only in analysis mode and record somewhere what kind of lowering would be 
> > > done
> > > and how much it would cost.
> > > With multiple if-to-switch, don't we risk that we turn some ifs into 
> > > switch,
> > > then
> > > switch-conversion lowers it back to ifs and then another if-to-switch 
> > > matches
> > > it again and again lowers it?
> > 
> > Yeah, I think ideally switch conversion would be done as part of switch
> > lowering (plus maybe an extra if-to-switch).  The issue might be what
> > I said - some passes don't like switches, but they probably need to be
> > taught.  As of inline cost yes, doing likely-switch-converted analysis
> > would probably work.
> 
> git diff
> diff --git a/gcc/passes.def b/gcc/passes.def
> index b257307e085..1376e7cb28d 100644
> --- a/gcc/passes.def
> +++ b/gcc/passes.def
> @@ -243,8 +243,6 @@ along with GCC; see the file COPYING3.  If not see
>  Clean them up.  Failure to do so well can lead to false
>  positives from warnings for erroneous code.  */
>NEXT_PASS (pass_copy_prop);
>/* Identify paths that should never be executed in a conforming
>  program and isolate those paths.  */
>NEXT_PASS (pass_isolate_erroneous_paths);
> @@ -329,6 +327,7 @@ along with GCC; see the file COPYING3.  If not see
>POP_INSERT_PASSES ()
>NEXT_PASS (pass_simduid_cleanup);
>NEXT_PASS (pass_lower_vector_ssa);
> +  NEXT_PASS (pass_if_to_switch);
>NEXT_PASS (pass_lower_switch);
>NEXT_PASS (pass_cse_reciprocals);
>NEXT_PASS (pass_reassoc, false /* early_p */);
> 
> Tried this to add the second if_to_switch before lower_switch, but switch
> lowering doesn't work same as switch_conversion:

Note the lowering expand to a decision tree where node of such tree can be
jump-tables,
bit-tests or simple comparisons.

> 
> ;; Function test2 (test2, funcdef_no=0, decl_uid=1982, cgraph_uid=1,
> symbol_order=0)
> 
> beginning to process the following SWITCH statement ((null):0) : ---
> switch (_2)  [INV], case 1:  [INV], case 2:  [INV],
> case 3:  [INV], case 4:  3> [INV], case 5:  [INV], case 6:  [INV]>
> 
> ;; GIMPLE switch case clusters: JT(values:6 comparisons:6 range:6 density:
> 100.00%):1-6

So jump-table is selected. Where do you see this GIMPLE representation?

...

> 
> ASM still contains indirect jump table like -fno-switch-conversion:

> 
> Is this bug of lower_switch or expected?

What bug do you mean? 

> From the code, they have different
> purpose as switch_conversion turns switch to single if-else while

No switch_conversion expands a switch statement to a series of assignment
based on CSWITCH[index] arrays.

> lower_switch expand CLUSTERS as a decision tree.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #32 from qinzhao at gcc dot gnu.org ---
(In reply to James Y Knight from comment #31)
> It doesn't make sense to have a mode in which `int array[0]` is accepted but
> is not a flex array.
> 
> Either that should be a compilation error (as the standard specifies), or it
> should be a flex array. Accepting it as an extension but having it do the
> wrong thing is not useful or helpful.
> 
> Note that Clang has a dedicated warning flag for zero-length arrays:
> -Wzero-length-array, so anyone who wants to prohibit them may use
> -Werror=zero-length-array. It would be helpful for GCC could follow suit
> there.

there is a Bugzilla that has been filed for GCC to request the same warning for
GCC:
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=94428

-Wzero-length-array


As suggested by Siddhesh in comment#23, -Wstrict-flex-arrays might be necessary
to be added too, and 
-Wzero-length-array will be an alias to 
-Wstrict-flex-arrays=3

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

--- Comment #12 from Richard Earnshaw  ---
(In reply to Alex Coplan from comment #11)
> (In reply to Jakub Jelinek from comment #8)
> > The IMHO UB case is for a != b when one address is at the start of one
> > object and the other address is at the end of another one
> 
> Just to dig a little deeper on this, what makes this case UB? Is there
> something in the standard to this effect?

As stated in #6, zero-sized objects are a GNU extension.  I guess that means we
get to define what the behaviour should be :)

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

--- Comment #13 from Alex Coplan  ---
(In reply to Richard Earnshaw from comment #12)
> (In reply to Alex Coplan from comment #11)
> > (In reply to Jakub Jelinek from comment #8)
> > > The IMHO UB case is for a != b when one address is at the start of one
> > > object and the other address is at the end of another one
> > 
> > Just to dig a little deeper on this, what makes this case UB? Is there
> > something in the standard to this effect?
> 
> As stated in #6, zero-sized objects are a GNU extension.  I guess that means
> we get to define what the behaviour should be :)

Sure, but Jakub's reply seemed to get at some underlying principle as opposed
to just saying "zero-sized objects are a GNU extension and we declare this case
to be undefined".

[Bug middle-end/106081] missed vectorization

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

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

--- Comment #4 from Jan Hubicka  ---
Thanks! It seems that imagemagick has quite few loops that inovlve consuming
shorts and producing doubles. Also it would be nice to do something about
__builtin_convertvector so it does not produce stupid code...

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #4 from Sergei Trofimovich  ---
Posted my naive attempt:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597353.html

[Bug rtl-optimization/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #3 from Segher Boessenkool  ---
STRICT_LOW_PART is required to contain a SUBREG though.

[Bug tree-optimization/106106] New: SRA scalarizes structure copies

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

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

Bug ID: 106106
   Summary: SRA scalarizes structure copies
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

The following example

#include 

float32x2x2_t f2(const float *p1, const float *p2)
{
float32x2x2_t v = vld2_f32(p1);
return vld2_lane_f32(p2, v, 1);
}

uses a type `float32x2x2_t` which is an array consisting of two `float32x2_t`
types.  This type fits within the maximum object size for SRA so it tries to
scalarize it.

However doing so it makes some useless copies:

  D.22939 = __builtin_aarch64_ld2v2sf (p1_2(D));
  v = D.22939;
  __b = v;
  D.22937 = __builtin_aarch64_ld2_lanev2sf (p2_3(D), __b, 1); [tail call]

becomes

  D.22939 = __builtin_aarch64_ld2v2sf (p1_2(D));
  v$val$0_3 = D.22939.val[0];
  v$val$1_5 = D.22939.val[1];
  __b.val[0] = v$val$0_3;
  __b.val[1] = v$val$1_5;
  D.22937 = __builtin_aarch64_ld2_lanev2sf (p2_4(D), __b, 1); [tail call]

having broken the structures up it causes problem for register allocation as
these types require sequential register allocation and reload is unable to
consolidate all the copies resulting in superfluous register moves:

f2:
ld2 {v2.2s - v3.2s}, [x0]
mov v0.8b, v2.8b
mov v1.8b, v3.8b
ld2 {v0.s - v1.s}[1], [x1]
ret

The following snippet from a real library using intrinsics shows the resulting
carnage https://godbolt.org/z/xnre3Pe34.

Perhaps SRA should not scalarize a type if it's just being used in a copy? or
have a way to prevent scalarization of certain types?

[Bug c++/106107] New: dynamic_cast fail within constant expression

[pkeir at outlook dot com via Gcc-bugs]

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

Bug ID: 106107
   Summary: dynamic_cast fail within constant expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 53210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53210&action=edit
The code described in the bug report.

The dynamic_cast, evaluated within the static_assert, in the code below, fails
(GCC trunk); while the runtime assert passes. Both pass with Clang and MSVC.

I have in place a workaround for the lack of an implicit destructor in Derived
due to bug 93413 - I am not sure if this is independent of that 93413.

#include 

struct Base {
  virtual constexpr ~Base() {}
};

struct Derived : public Base
{
#if !defined(__clang__)
  // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
  constexpr virtual ~Derived() {};
#endif
};

constexpr bool test()
{
  Base* bp = new Derived;
  Derived* dp = dynamic_cast(bp);
  bool b = dp != nullptr;
  delete bp;
  return b;
}

int main(int argc, char *argv[])
{
  static_assert(test());

  assert(test());

  return 0;
}

[Bug fortran/106108] New: gfortran gives warning about unitilialized variable for string with both allocatable length and size

[kaiserkarl31 at yahoo dot com via Gcc-bugs]

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

Bug ID: 106108
   Summary: gfortran gives warning about unitilialized variable
for string with both allocatable length and size
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaiserkarl31 at yahoo dot com
  Target Milestone: ---

gfortran using "-Wuninitialized" spits out an erroneous warning message for the
declaration of a string that has both allocatable length and allocatable
dimension. Making it a fixed-length string works: gfortran handles the
fixed-length string with allocatable dimension.

The following program is a minimal working example:
program test
   implicit none
   character (len=:), dimension(:), allocatable :: args
   allocate( character(len=6) :: args(2) )
   args(1) = 'hello,'
   args(2) = 'world!'
   print '(2(A,1X))', args
end program test

The compiler seems to handle the above code just fine, but it should not warn
the user. Instead, if compiled with "-Wall" or "-Wuninitialized", it says this:

test.f90:3:55:

3 |character (len=:), dimension(:), allocatable :: args
  |   ^
Warning: ‘.args’ is used uninitialized [-Wuninitialized]


As I said before, making the length fixed seems to work:
program test
   implicit none
   character (len=6), dimension(:), allocatable :: args
   allocate( args(2) )
   args(1) = 'hello,'
   args(2) = 'world!'
   print '(2(A,1X))', args
end program test

This version produces no warnings.

[Bug testsuite/106105] new test case gcc.dg/torture/pr106070.c in r13-1243-gb36a1c964f9975 fails for 32 bits

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Hasn't r13-1299-g00063459f683a fixed this already?

[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:508231d54405ac9f120cf30c28cd6eb10ceded30

commit r13-1303-g508231d54405ac9f120cf30c28cd6eb10ceded30
Author: Marek Polacek 
Date:   Mon Jun 27 14:52:58 2022 -0400

c++: Add fixed test [PR89197]

Fixed since bug 97899 was fixed.

PR c++/89197

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist130.C: New test.

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

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

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

--- Comment #12 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:508231d54405ac9f120cf30c28cd6eb10ceded30

commit r13-1303-g508231d54405ac9f120cf30c28cd6eb10ceded30
Author: Marek Polacek 
Date:   Mon Jun 27 14:52:58 2022 -0400

c++: Add fixed test [PR89197]

Fixed since bug 97899 was fixed.

PR c++/89197

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist130.C: New test.

[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Done.

[Bug fortran/106108] gfortran gives warning about unitilialized variable for string with both allocatable length and size

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

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

[Bug fortran/106089] false positives with -Wuninitialized for allocation on assignment

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kaiserkarl31 at yahoo dot com

--- Comment #2 from anlauf at gcc dot gnu.org ---
*** Bug 106108 has been marked as a duplicate of this bug. ***

[Bug fortran/104430] [10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742 since r9-3522-gd0477233215e37de

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
Summary|[10/11/12/13 Regression]|[10 Regression] ICE in
   |ICE in  |gfc_conv_component_ref, at
   |gfc_conv_component_ref, at  |fortran/trans-expr.cc:2742
   |fortran/trans-expr.cc:2742  |since
   |since   |r9-3522-gd0477233215e37de
   |r9-3522-gd0477233215e37de   |

--- Comment #5 from anlauf at gcc dot gnu.org ---
Seems to be fixed on gcc-11 and newer.

Tobias, is the fix backportable to gcc-10 so that this one can be closed?

[Bug c++/106109] New: Internal compiler error

[philip.deegan at gmail dot com via Gcc-bugs]

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

Bug ID: 106109
   Summary: Internal compiler error
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philip.deegan at gmail dot com
  Target Milestone: ---

Hi,

With the release of FC36 and GCC12, we've begun to get an internal compiler
error for the following code,
https://github.com/PHAREHUB/PHARE/blob/master/tests/core/data/electrons/test_electrons.cpp#L464-L519

Firstly it says "invalid use of auto", but adding "-> void" to the lambda
resolves this, however following that we get an internal compiler error.

```
/io/tests/core/data/electrons/test_electrons.cpp: In member function ‘void
ElectronsTest_ThatElectronsVelocityEqualIonVelocityMinusJ_Test::TestBody()
[with gtest_TypeParam_ = std::pair,
PHARE::core::InterpConst<1> >]’:
/io/tests/core/data/electrons/test_electrons.cpp:519:10: internal compiler
error: Segmentation fault
  519 | check(this->Vex, this->Vix, this->Jx, Ne, GridYee::JxToMoments);
  | ~^~
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccCpGiQv.out file, please attach this to
your bugreport.
ninja: build stopped: subcommand failed.
```

```
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/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,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-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/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 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC) 
```
ccCpGiQv.out is uploaded here:
https://gist.github.com/PhilipDeegan/c47eb44c96f579aa62d23ab1b5f2daa0

Changing to use a free templated function fails.
Commenting out the code inside the lambda fails.

If you have any issues building, we provide some Dockerfiles.
If this is in the wrong place please let me know.
Happy to test things to help investigate.

Thanks

[Bug c++/106109] Internal compiler error

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

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

--- Comment #1 from Andrew Pinski  ---
> ccCpGiQv.out is uploaded here:

Can you attach it? You might need to compress it too.

[Bug c++/106109] Internal compiler error

[philip.deegan at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Philip Deegan  ---
Created attachment 53211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53211&action=edit
preprocessed source

[Bug c++/106110] New: Expected ambiguity but it resolves fine

[ted at lyncon dot se via Gcc-bugs]

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

Bug ID: 106110
   Summary: Expected ambiguity but it resolves fine
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ted at lyncon dot se
  Target Milestone: ---

I made a type trait to test if a call to a function using certain arguments
would be ambiguous or not, but in the below example, where I expected that
calling the function `foo` with a `std::tuple` would result in
ambiguity, it is not detected as such.
```
#include 
#include 

template 
void foo(const std::tuple&) { std::cout << "T\n"; }

template 
void foo(const std::tuple&) { std::cout << "Ts...\n"; }

template 
struct is_foo_call_ambiguous {
static std::true_type test(...);

template 
static auto test(AArgs&&...)
-> decltype(foo(std::declval()...), std::false_type{});

static constexpr bool value =
decltype(test(std::declval()...))::value;
};

template 
static constexpr bool is_foo_call_ambiguous_v =
is_foo_call_ambiguous::value;

int main() {
// expected `true` here, but it reports `false`:
std::cout << is_foo_call_ambiguous_v> << '\n';

// `false` as expected:
std::cout << is_foo_call_ambiguous_v> << '\n';
}
```
As can be seen here, clang++ reports it to be ambiguous:
https://godbolt.org/z/YTevWvbzz

If I understand it correctly, the added tiebreaker
(https://cplusplus.github.io/CWG/issues/1395.html) for variadic templates
should not apply here.

[Bug c++/106109] Internal compiler error

[philip.deegan at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Philip Deegan  ---
a bit more testing on our end, I think the issue stems from the lack of & on
GridYee::JxToMoments
https://github.com/PHAREHUB/PHARE/blob/master/tests/core/data/electrons/test_electrons.cpp#L519

> &GridYee::JxToMoments

I would have assumed not taking the address of a function would cause a
compiler error in this context.

adding in & resolves the internal compiler error.

sorry for the noise

[Bug c++/106109] Internal compiler error

[philip.deegan at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Philip Deegan  ---
as a minimal reproducer 


`
template
class G
{
public:
auto static F() { return 1; }
};

int main()
{
auto fn = [](auto const& f) -> void { f(); };

fn(G::F);

return 0;
}
`

https://godbolt.org/z/f4WYnPvs6

Only if G is a template class does it appear

[Bug c++/106109] Internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Already fixed in r13-768-g850a9ce8bcca59.  We'll be updating Fedora gcc
shortly.

[Bug testsuite/106105] new test case gcc.dg/torture/pr106070.c in r13-1243-gb36a1c964f9975 fails for 32 bits

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
The last round of tests I ran still showed this failing but I will check with
the latest commit.

[Bug testsuite/106105] new test case gcc.dg/torture/pr106070.c in r13-1243-gb36a1c964f9975 fails for 32 bits

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
OK, it is fixed.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

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

commit r13-1311-g3b21c21f3f5726823e19728fdd1571a14aae0fb3
Author: Sergei Trofimovich 
Date:   Mon Jun 27 13:27:24 2022 +0100

c++: avoid  poisoning on musl [PR106102]

On musl  uses calloc() (via ).  includes
it indirectly and exposes use of poisoned calloc() when module code
is built:

/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
 
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
 from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
 from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

gcc/cp/

PR c++/106102
* mapper-client.cc: Include  via "system.h".
* mapper-resolver.cc: Ditto.
* module.cc: Ditto.

libcc1/

PR c++/106102
* libcc1plugin.cc: Include  via "system.h".
* libcp1plugin.cc: Ditto.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

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

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

--- Comment #6 from Sergei Trofimovich  ---
Also found a closely related jit build failure, but there  is used
directly.

Proposed the change to move  before poisoning step as:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597379.html

[Bug c++/106110] Expected ambiguity but it resolves fine

[ted at lyncon dot se via Gcc-bugs]

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

--- Comment #1 from Ted Lyngmo  ---
Sorry, the helper variable template should be:
```
template 
static constexpr bool is_foo_call_ambiguous_v =
is_foo_call_ambiguous::value;
```
It gives the same result: https://godbolt.org/z/bKbn8Gre7

[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #1 from Antoni  ---
Created attachment 53212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53212&action=edit
patch fixing the bug

[Bug tree-optimization/106070] [13 Regression] Wrong code with -O1 since r13-469-g9a53101caadae1b5

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #12 from Richard Biener  ---
Jakub fixed it.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 106070 Summary: [13 Regression] Wrong code with -O1 since 
r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Mon, 27 Jun 2022, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
> 
> --- Comment #14 from H.J. Lu  ---
> (In reply to rguent...@suse.de from comment #13)
> > On Fri, 24 Jun 2022, hjl.tools at gmail dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
> > > 
> > > --- Comment #12 from H.J. Lu  ---
> > > (In reply to Richard Biener from comment #11)
> > > > No, I think you would need to pattern match an actual store sequence,
> > > > for example by looking at
> > > > 
> > > >  if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
> > > >  && pow2p_hwi (DR_GROUP_STORE_COUNT (stmt_info)))
> > > >/* cost a possibly merged store only once (but with larger mode?) */
> > > >if (DR_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info)
> > > >  ...
> > > 
> > > The information aren't available in add_stmt_cost.
> > 
> > They should be ...
> 
> I meant that DR_GROUP_STORE_COUNT (stmt_info) was zero.

Ah, OK - use DR_GROUP_SIZE then.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Priority|P3  |P2

--- Comment #4 from Richard Biener  ---
(In reply to Segher Boessenkool from comment #3)
> STRICT_LOW_PART is required to contain a SUBREG though.

So

Trying 23 -> 24:
   23: r77:DI=[r85:DI]
  REG_DEAD r85:DI
   24: strict_low_part(r71:SI)=r77:DI#4
  REG_DEAD r77:DI
Successfully matched this instruction:
(set (strict_low_part (reg/v:SI 71 [ yyval ]))
(mem/f:SI (plus:DI (reg:DI 85)
(const_int 4 [0x4])) [2 *_3+4 S4 A32]))
allowing combination of insns 23 and 24

just exposes the issue that RTL expansion produces:

;; MEM[(char * *)&yyval] = _4;

(insn 23 22 24 (set (reg/f:DI 77)
(mem/f:DI (reg/f:DI 62 [ _3 ]) [2 *_3+0 S8 A64])) "/tmp/y.tab.i":41:23
-1
 (nil))

(insn 24 23 0 (set (strict_low_part (reg/v:SI 71 [ yyval ]))
(subreg:SI (reg/f:DI 77) 4)) "/tmp/y.tab.i":41:23 -1
 (nil))

which is emitted via

#3  0x01fe5354 in gen_movstrictsi (operand0=0x76a49d20, 
operand1=0x76a4e438) at insn-emit.cc:11776
#4  0x019163e5 in s390_expand_insv (dest=0x76a4e3f0, 
op1=0x768c8690, op2=0x768c8690, src=0x76a4e3d8)
at /space/rguenther/src/gcc/gcc/config/s390/s390.cc:6530
#5  0x020373a8 in gen_insv (operand0=0x76a4e3f0, 
operand1=0x768c8690, operand2=0x768c8690, operand3=0x76a4e3d8)
at /space/rguenther/src/gcc/gcc/config/s390/s390.md:4217
...
#8  0x01242f07 in maybe_expand_insn (icode=CODE_FOR_insv, nops=4, 
ops=0x7fffc500) at /space/rguenther/src/gcc/gcc/optabs.cc:7998
#9  0x00e43d46 in store_bit_field_using_insv (insv=0x7fffc7a0, 
op0=0x76a49d20, op0_mode=SImode, bitsize=32, bitnum=32, 

;
; movstrictsi instruction pattern(s).
;

(define_insn "movstrictsi"
  [(set (strict_low_part (match_operand:SI 0 "register_operand" "+d,d,d,d"))
 (match_operand:SI 1 "general_operand" "d,R,T,t"))]
  "TARGET_ZARCH"
  "@
   lr\t%0,%1
   l\t%0,%1
   ly\t%0,%1
   ear\t%0,%1"
  [(set_attr "op_type" "RR,RX,RXY,RRE")
   (set_attr "type" "lr,load,load,*")
   (set_attr "cpu_facility" "*,*,longdisp,*")
   (set_attr "z10prop" "z10_fr_E1,z10_fwd_A3,z10_fwd_A3,z10_super_E1")])

all of which is ancient code ...

target issue after all.

[Bug target/106097] undefined behaviors regarding integer shifts in loongarch_build_integer

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to chenglulu from comment #9)
> Created attachment 53206 [details]
> use LU52I_B and LU32I_B instead of hard coding those long

> +  codes[cost].value = (value & LU32I_B)
> + | (sign51 ? LU52I_B : 0);

nit： I think this can fit in one line.

Otherwise LGTM.  As the port maintainer you can push it directly into master. 
Normally we should bootstrap and regtest before applying a patch, but currently
the bootstrap is blocked by PR106096 :(.