[Bug c++/115445] [15 Regression] [modules] ICE when repeating an export of function declared in GMF

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #1 from m.cencora at gmail dot com ---
Works fine on gcc-14 and clang

[Bug tree-optimization/115438] [15 Regression] 503.bwaves_r regressed 5-11% on different x86_64 machines at -Ofast -march=native since r15-1006-gd93353e6423eca

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will see what happens.  It's somewhat expected but OTOH it's not expected.

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #17 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:919e88f7915b57ae3a2152a1947dbfac3fccfe88

commit r15-1197-g919e88f7915b57ae3a2152a1947dbfac3fccfe88
Author: Gerald Pfeifer 
Date:   Wed Jun 12 08:46:20 2024 +0200

doc: Simplify *-*-linux-gnu dependencies

Glibc 2.1 was released in 1999, binutils 2.12 in 2002; no need to
explicitly list them as dependencies any longer.

gcc:
PR target/69374
* doc/install.texi (Specific) <*-*-linux-gnu>: Do not list
glibc 2.1 and binutils 2.12 as minimum dependencies.

[Bug tree-optimization/115455] New: ICE: verify_flow_info failed during GIMPLE pass: cfg

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115455
   Summary: ICE: verify_flow_info failed during GIMPLE pass: cfg
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error during the cfg GIMPLE pass when
compiling the provided code. 
The issue can also be reproduced on Compiler Explorer.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:
# cat bugfunc.c

void f(void)
{
  void p(void)
  {
  __label__ l1;
  void q(void)
  {
goto l1;
  }

  l1:;
  }
  p();
}
int
main (void)
{
  f();
  return 0;
}   


***
Command Lines:
# gcc bugfunc.c -std=c11 -fvisibility=hidden -fsanitize=address -fno-
omit-frame-pointer -fno-common -fstrict-aliasing -fstack-protector-strong
-fno-exceptions -fno-rtti -fpic -ffunction-sections -fdata-sections -Werror 
-Wall -Wextra  -Wno-unused-parameter -Wno-c++98-compat
-Wno-c++98-compat-pedantic -Wno-missing-noreturn -Wno-missing-prototypes
-Wno-missing-field-initializers -Wno-cast-align -Wno-nested-anon-types
-Wno-vla-extension -Wno-vla-extension -o bugfunc
cc1: error: command-line option ‘-fno-rtti’ is valid for C++/D/ObjC++ but not
for C [-Werror]
bugfunc.c: In function ‘p’:
bugfunc.c:3:8: error: label ‘({anonymous})’ has incorrect context in bb 4
3 |   void p(void)
  |^
during GIMPLE pass: cfg
bugfunc.c:3:8: internal compiler error: verify_flow_info failed
0xb633de verify_flow_info()
/root/gdbtest/gcc/obj/../gcc/gcc/cfghooks.cc:287
0x10fa16c checking_verify_flow_info()
/root/gdbtest/gcc/obj/../gcc/gcc/cfghooks.h:214
0x10fa16c cleanup_tree_cfg_noloop
/root/gdbtest/gcc/obj/../gcc/gcc/tree-cfgcleanup.cc:1154
0x10fa16c cleanup_tree_cfg(unsigned int)
/root/gdbtest/gcc/obj/../gcc/gcc/tree-cfgcleanup.cc:1205
0x10f1ba4 execute_build_cfg
/root/gdbtest/gcc/obj/../gcc/gcc/tree-cfg.cc:379
0x10f1ba4 execute
/root/gdbtest/gcc/obj/../gcc/gcc/tree-cfg.cc:413
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.

***
Also ICE on trunk, compiler explorer:https://godbolt.org/z/KsWE7h7zE
***

[Bug c++/115425] [13/14/15 regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE: tree check: expected   |[13/14/15 regression] ICE:
   |type_pack_expansion or  |tree check: expected
   |expr_pack_expansion, have   |type_pack_expansion or
   |error_mark in   |expr_pack_expansion, have
   |tsubst_pack_expansion, at   |error_mark in
   |cp/pt.cc:13778  |tsubst_pack_expansion, at
   ||cp/pt.cc:13778

--- Comment #2 from Sam James  ---
The ICE started in 13.

[Bug testsuite/115365] [15 regression] New test case gcc.dg/pr100927.c from r15-1022-gb05288d1f1e4b6 fails

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

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

Sam James  changed:

   What|Removed |Added

Summary|New test case   |[15 regression] New test
   |gcc.dg/pr100927.c from  |case gcc.dg/pr100927.c from
   |r15-1022-gb05288d1f1e4b6|r15-1022-gb05288d1f1e4b6
   |fails   |fails

--- Comment #8 from Sam James  ---
(Calling it a regression given it regresses the testsuite.)

[Bug tree-optimization/113681] [14/15 Regression] ICE in tree_profiling, at tree-profile.cc:803 since r14-6201-gf0a90c7d7333fc

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

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

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

https://gcc.gnu.org/g:66f48557e11a530646e5562c50a75b4b9839f171

commit r15-1196-g66f48557e11a530646e5562c50a75b4b9839f171
Author: Alexandre Oliva 
Date:   Wed Jun 12 00:16:27 2024 -0300

[tree-prof] skip if errors were seen [PR113681]

ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.


for  gcc/ChangeLog

PR tree-optimization/113681
* tree-profile.cc (pass_ipa_tree_profile::gate): Skip if
seen_errors.

for  gcc/testsuite/ChangeLog

PR tree-optimization/113681
* c-c++-common/strub-pr113681.c: New.

[Bug libstdc++/115454] New: std::experimental::find_last_set is buggy on x86-64-v4

[lee.imple at gmail dot com via Gcc-bugs]

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

Bug ID: 115454
   Summary: std::experimental::find_last_set is buggy on x86-64-v4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lee.imple at gmail dot com
  Target Milestone: ---

We are using a simd with 4 uint64_t elements (with `deduce_t`) on x86-64-v4.
We are trying to find the last element with the value -1 (i.e. all 1s).

The code is as following (available at https://godbolt.org/z/3f1nszf8E ),
compiled with the options `-O3 -march=x86-64-v4 -std=c++20`.

```c++
#include 
#include 

using deduce_t_element = std::experimental::simd<
std::uint64_t,
std::experimental::simd_abi::deduce_t
>;
using fixed_size_element = std::experimental::simd<
std::uint64_t,
std::experimental::simd_abi::fixed_size<4>
>;

int f_deduce(deduce_t_element e) {
return find_last_set(e != -1);
}

int f_fixed_size(fixed_size_element e) {
return find_last_set(e != -1);
}
```

G++ trunk gives the following assembly (I add the comments).

```asm
f_deduce(std::experimental::parallelism_v2::simd >):
  vpcmpeqd %ymm1, %ymm1, %ymm1
  movl $-1, %eax
  vpcmpq $4, %ymm1, %ymm0, %k0
  kmovb %k0, %edx
  orb $-16, %dl# %dl |= 0xf0
  je .L1
  movzbl %dl, %edx 
  movl $31, %eax
  lzcntl %edx, %edx# leading zeros is 24 
   # because the next byte is always 0b
  subl %edx, %eax  # so we get the result is 31 - 24 = 7
.L1:
  ret
f_fixed_size(std::experimental::parallelism_v2::simd >):
  vpcmpeqd %ymm0, %ymm0, %ymm0
  movl $63, %edx
  vpcmpq $4, (%rdi), %ymm0, %k0
  kmovb %k0, %eax
  andl $15, %eax
  lzcntq %rax, %rax
  subl %eax, %edx
  movl %edx, %eax
  vzeroupper
  ret
```

In fact, the first function always gives the result 7 whatever argument it
gets, which is more obvious from clang++'s result.

```asm
f_deduce(std::experimental::parallelism_v2::simd>): #
@f_deduce(std::experimental::parallelism_v2::simd>)
  movl $7, %eax
  retq
f_fixed_size(std::experimental::parallelism_v2::simd>): #
@f_fixed_size(std::experimental::parallelism_v2::simd>)
  vpcmpeqd %ymm0, %ymm0, %ymm0
  vpcmpeqq (%rdi), %ymm0, %k0
  kmovd %k0, %eax
  xorb $15, %al
  movzbl %al, %eax
  lzcntq %rax, %rcx
  movl $63, %eax
  subl %ecx, %eax
  vzeroupper
  retq
```

I don't know why, but compiled result of `fixed_size_simd` seems to be
different.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?
The invalid offset is zero, so: hashst r0,0(r1)
As the assembler mentions, the range of valid offsets is [-512,-8] and the
offset must be a multiple of 8.

The "bug" is that we initialize rop_hash_save_offset to zero very early, before
any option processing.  Later, we compute the actual offset, but only in the
case where Altivec is enabled (TARGET_ALTIVEC_ABI is true).  If Altivec is
disabled as in this test case, we end up using rop_hash_save_offset's invalid
initial zero value.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #5 from Andrew Pinski  ---
Also it is not just old glibc but most non-"modern" libc out there (e.g.
Solaris I think). So maybe don't reference glibc in the comments in
configure.ac either. Just say some libc.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> Also, a typo: it has ac_cv_search_pthread_crate (not create).

Someone had rust crate on their mind when they did the patch :).

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #3 from Sam James  ---
Also, a typo: it has ac_cv_search_pthread_crate (not create).

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Note when this gets fixed, Make sure that this gets synced over toto
gdb-binutils repo too since toplevel configure is shared.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 regression] Noise from  |[15 regression] Noise from
   |new dlopen, pthread |new dlopen, pthread
   |configure checks|configure checks since
   ||r15-1177-g75299e4fe50aa8
 CC||cohenarthur at gcc dot gnu.org
   Target Milestone|--- |15.0

[Bug other/115453] [15 regression] Noise from new dlopen, pthread configure checks

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

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

--- Comment #1 from Sam James  ---
246:configure:8884: checking for library containing dlopen
634:ac_cv_search_dlopen='none required'

246:configure:8884: checking for library containing dlopen
634:ac_cv_search_dlopen='none required'

[Bug other/115453] New: [15 regression] Noise from ne wdlopen, pthread configure checks

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

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

Bug ID: 115453
   Summary: [15 regression] Noise from ne wdlopen, pthread
configure checks
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

With dash as /bin/sh, at least:
```
checking for library containing dlopen... none required
checking for library containing pthread_create... none required
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure: line
8997: test: too many arguments
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure: line
8999: test: too many arguments
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure: line
9003: test: too many arguments
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure: line
9005: test: =: unary operator expected
The following languages will be built: c,jit,lto
```

Missing quoting to handle if the var is blank.

[Bug target/115452] New: ICE when dump stv2 for gcc.target/i386/pr70322-2.c with -march=cascadelake

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

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

Bug ID: 115452
   Summary: ICE when dump stv2 for gcc.target/i386/pr70322-2.c
with -march=cascadelake
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

gcc -m32 -march=cascadelake ./gcc/testsuite/gcc.target/i386/pr70322-2.c -mstv
-mno-bmi -S -Os -fdump-rtl-stv2-details

./gcc/testsuite/gcc.target/i386/pr70322-2.c: In function ‘foo’:
./gcc/testsuite/gcc.target/i386/pr70322-2.c:12:1: internal compiler error: RTL
check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1934
   12 | }
  | ^
0x88ef75 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
./gcc/rtl.cc:770
0x96be78 rhs_regno(rtx_def const*)
./gcc/rtl.h:1934
0x96cd8d rhs_regno(rtx_def const*)
./genrtl.h:38
0x96cd8d convert_op
./gcc/config/i386/i386-features.cc:1056
0x1af7711 convert_insn
./gcc/config/i386/i386-features.cc:1468
0x1af9808 convert
./gcc/config/i386/i386-features.cc:1987
0x1af9808 convert_scalars_to_vector
./gcc/config/i386/i386-features.cc:2536
0x1af9808 execute
   ./gcc/config/i386/i386-features.cc:2750


cut from i386-features.cc:1056---

  if (dump_file)
fprintf (dump_file, "  Preloading operand for insn %d into r%d\n",
 INSN_UID (insn), REGNO (tmp));
--cut end---

Looks like tmp is SUBREG.

[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1

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

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

--- Comment #3 from Kewen Lin  ---
(In reply to Peter Bergner from comment #2)
> (In reply to Jeffrey A. Law from comment #1)
> > It looks like the test wants to see xxsel, but after that change we get
> > xxlor and  what looks like a slight difference in register allocation.  I
> > can't really judge if the new code is better, worse is equivalent.
> 
> xxsel XT,XA,XB,XC computes XT = (XA & ~XC) | (XB & XC).  Using De Morgan's
> law given XB == XC, that seems to simplify to XT = XA | XB which is what
> you're producing and an xxlor (a simple logical or) is not going to be
> slower than a xxsel and is probably faster.  I agree with Bill that this
> looks like an example of needing to update the expected results of the test
> case.  I'll let Segher and/or Ke Wen comment though.

I agree they are equivalent here, from the scheduling descriptions, xxsel and
xxlor are in the same unit.

[Bug d/115295] [15 regression] Various gdc testsuite regressions

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alexandre Oliva from comment #4)
> Created attachment 58410 [details]
> candidate patch
> 
> This patch reverts dg-additional-sources to the earlier behavior, in which
> sources are added regardless of the test, introducing an explicit flag to
> activate the link-only mode.  This should bring the D testsuite back to a
> functioning state (I'd appreciate if someone who has a D compiler could give
> it a spin; I'm new to it), and the additional of the flag to the pr95401.cc
> test should address the original problem.

So I fixed the other `dg-additional-sources` issues in the vect testsuite by
adding `dg-do run` to them (PR 113899, r14-8978-g948dbc5ee45f9f). I suspect we
should just do the same for g++.dg/vect/pr95401.cc . I had missed the c++
testsuite's vect testcases when I was looking for dg-additional-sources when I
fixed that one.

[Bug target/115451] ARM neon: float32 comparison intrinsics get scalar implementation since GCC 11

[povilas at radix dot lt via Gcc-bugs]

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

--- Comment #1 from Povilas Kanapickas  ---
Link to godbolt https://godbolt.org/z/MbnMhzrTT

[Bug target/115451] New: ARM neon: float32 comparison intrinsics get scalar implementation since GCC 11

[povilas at radix dot lt via Gcc-bugs]

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

Bug ID: 115451
   Summary: ARM neon: float32 comparison intrinsics get scalar
implementation since GCC 11
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: povilas at radix dot lt
  Target Milestone: ---

The following code:

#include 

uint32x4_t test(float32x4_t a, float32x4_t b)
{
return vcgtq_f32(a, b);
}

Results in the following assembly when compiled with GCC 11 to GCC 14.1 (g++
-O3 -mfpu=neon test.cc). The problem does not happen on ARM64, nor if
-funsafe-math-optimizations is enabled.

_Z4test19__simd128_float32_tS_:
.fnstart
.LFB10719:
vmov.32 r3, d0[1]
vcmpe.f32   s0, s4
sub sp, sp, #16
vmrsAPSR_nzcv, FPSCR
vmovs10, r3
vmov.32 r3, d2[1]
vmovs11, r3
vmov.32 r3, d1[0]
vcmpe.f32   s10, s11
vmovs12, r3
vmov.32 r3, d3[0]
vmovs13, r3
vmov.32 r3, d1[1]
vmovs14, r3
vmov.32 r3, d3[1]
vmovs15, r3
ite gt
movgt   r3, #-1
movle   r3, #0
vmrsAPSR_nzcv, FPSCR
vcmpe.f32   s12, s13
str r3, [sp]
ite gt
movgt   r3, #-1
movle   r3, #0
vmrsAPSR_nzcv, FPSCR
vcmpe.f32   s14, s15
str r3, [sp, #4]
ite gt
movgt   r3, #-1
movle   r3, #0
vmrsAPSR_nzcv, FPSCR
str r3, [sp, #8]
ite gt
movgt   r3, #-1
movle   r3, #0
str r3, [sp, #12]
vld1.64 {d0-d1}, [sp:64]
add sp, sp, #16
@ sp needed
bx  lr

[Bug d/115295] [15 regression] Various gdc testsuite regressions

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

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

--- Comment #4 from Alexandre Oliva  ---
Created attachment 58410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58410&action=edit
candidate patch

This patch reverts dg-additional-sources to the earlier behavior, in which
sources are added regardless of the test, introducing an explicit flag to
activate the link-only mode.  This should bring the D testsuite back to a
functioning state (I'd appreciate if someone who has a D compiler could give it
a spin; I'm new to it), and the additional of the flag to the pr95401.cc test
should address the original problem.

[Bug tree-optimization/115450] [15 Regression] cpu2017 502.gcc runtime miscompute on aarch64 with SVE since r15-1006-gd93353e6423eca

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Target||aarch64-linux-gnu
   Keywords||wrong-code
Summary|cpu2017 502.gcc runtime |[15 Regression] cpu2017
   |miscompute  |502.gcc runtime miscompute
   ||on aarch64 with SVE since
   ||r15-1006-gd93353e6423eca
   Target Milestone|--- |15.0
 Blocks||26163


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 tree-optimization/115450] cpu2017 502.gcc runtime miscompute

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

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

--- Comment #1 from Andrew Pinski  ---
>[r15-1006-gd93353e6423eca] Do single-lane SLP discovery for reductions


Interesting because PR 115256 bisect it to an earlier patch.

[Bug tree-optimization/115450] New: cpu2017 502.gcc runtime miscompute

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

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

Bug ID: 115450
   Summary: cpu2017 502.gcc runtime miscompute
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

5022.gcc is meicompiling for aarch64 with -O3 -Wl,-z,muldefs -lm
-fallow-argument-mismatch -fpermissive -fstack-arrays -flto
-Wl,--sort-section=name -fno-strict-aliasing -fgnu89-inline -march=native
-mcpu=neoverse-v2 -msve-vector-bits=128

gcc -v
Using built-in specs.
COLLECT_GCC=/home/kvivekananda/install_base/bin/gcc
COLLECT_LTO_WRAPPER=/home/kvivekananda/install_base/libexec/gcc/aarch64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc_base/configure --enable-multiarch=yes
--enable-languages=c,c++,fortran,lto --disable-bootstrap
--prefix=/home/kvivekananda/install_base : (reconfigured) ../gcc_base/configure
--enable-multiarch=yes --disable-bootstrap
--prefix=/home/kvivekananda/install_base --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240607 (experimental) (GCC) 


Bisect points to:
[d93353e6423ecaaae9fa47d0935caafd9abfe4de] Do single-lane SLP discovery for
reductions

[Bug tree-optimization/115449] `(truncate)a` and `(nop_convert)~(truncate)a` are bitwise inversion of each other

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 58409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58409&action=edit
Patch which I am testing

Just attaching it for now.

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088 since r15-1047-g7876cde25cbd2f

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #5 from Hongtao Liu  ---
Fixed.

[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088 since r15-1047-g7876cde25cbd2f

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:1d496d2cd1d5d8751a1637abca89339d6f9ddd3b

commit r15-1191-g1d496d2cd1d5d8751a1637abca89339d6f9ddd3b
Author: liuhongt 
Date:   Tue Jun 11 10:23:27 2024 +0800

Fix ICE in rtl check due to CONST_WIDE_INT in CONST_VECTOR_DUPLICATE_P

The patch add extra check to make sure the component of CONST_VECTOR
is CONST_INT_P.

gcc/ChangeLog:

PR target/115384
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
Only do the simplification of (AND (ASHIFTRT A imm) mask)
to (LSHIFTRT A imm) when the component of const_vector is
CONST_INT_P.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr115384.c: New test.

[Bug target/115176] rbit pattern should use bitreverse rtl now

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||4271.html
   Keywords||patch

--- Comment #3 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654271.html

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?

It would be nice if the assembler told us, btw :-)

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

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

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

--- Comment #2 from Segher Boessenkool  ---
So, what value do we output? And why?

[Bug tree-optimization/115449] `(truncate)a` and `(nop_convert)~(truncate)a` are bitwise inversion of each other

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2024-06-11
 Ever confirmed|0   |1
Summary|`(truncate)a` and   |`(truncate)a` and
   |`(nop_convert)~(truncate)a` |`(nop_convert)~(truncate)a`
   ||are bitwise inversion of
   ||each other

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

[Bug tree-optimization/115449] New: `(truncate)a` and `(nop_convert)~(truncate)a`

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

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

Bug ID: 115449
   Summary: `(truncate)a` and `(nop_convert)~(truncate)a`
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
void setBit(unsigned char &a, int b) {
   unsigned char c = 0x1UL << b;
   a &= ~c;
a |= c;
}

void setBit(signed char &a, int b) {
   signed char c = 0x1UL << b;
   a &= ~c;
a |= c;
}
```

We should be able to optimize both setBit on the gimple level to:
```
  _1 = 1 << b_4(D);
  c_5 = ([un]signed char) _1;
  _2 = *a_7(D);
  _3 = _2 | c_5;
  *a_7(D) = _3;
```
Removing the ~ that is there.


So we already have this pattern (deals with some type changes though) in
gimple:
 /* (~x | y) & x -> x & y */
 /* (~x & y) | x -> x | y */
 (simplify
  (bitop:c (rbitop:c @2 @1) @0)
  (with { bool wascmp; }
   (if (bitwise_inverted_equal_p (@0, @2, wascmp)
&& (!wascmp || element_precision (type) == 1))
(bitop @0 @1

The problem is bitwise_inverted_equal_p does not see that:
  c.0_4 = (signed char) _1;
  _5 = ~c.0_4;
  _16 = (charD.11) _5;

and
  c_11 = (charD.11) _1;

are bitwise inversions of each other.

[Bug other/115448] New: Improvements to CFG edge visualization in diagnostic paths

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

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

Bug ID: 115448
   Summary: Improvements to CFG edge visualization in diagnostic
paths
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

See https://godbolt.org/z/5e6d3Pvff (from bug 115436) where the path has:

│
└──> 'my_str_push_char': events 3-4
   │
   │   28 | static bool my_str_push_char(my_str* s, char c) {
   │  | ^~~~
   │  | |
   │  | (3) entry to 'my_str_push_char'
   │   29 |   if (s->len >= s->cap) if (!my_str_realloc(s, s->cap * 2))
return false;
   │  |  ~   
   │  |  |
   │  |  (4) following 'true' branch... ─>─┐
   │  |│
   │
 'my_str_push_char': event 5
   │
   │  |│
   │  |┌───┘
   │   29 |│  if (s->len >= s->cap) if (!my_str_realloc(s, s->cap * 2))
return false;
   │  |│   ~^
   │  |│|
   │  |└───>(5) ...to
here
   │
 'my_str_push_char': event 6
   │
   │   29 |   if (s->len >= s->cap) if (!my_str_realloc(s, s->cap * 2))
return false;
   │  |  ^
   │  |  |
   │  |  (6) calling 'my_str_realloc'
from 'my_str_push_char'
   │
   └──> 'my_str_realloc': events 7-13
  │

If we supported "intraline" edges, then events 4 and 5 could probably be linked
like this (thus consolidating event 5 in with events 3-4):

│
└──> 'my_str_push_char': events 3-5
   │
   │   28 | static bool my_str_push_char(my_str* s, char c) {
   │  | ^~~~
   │  | |
   │  | (3) entry to 'my_str_push_char'
   │   29 |   if (s->len >= s->cap) if (!my_str_realloc(s, s->cap * 2))
return false;
   │  |  ~ ~^
   │  |  |  | 
   │  |  (4) following 'true' branch... ───>(5) ...to
here   
   │
 'my_str_push_char': event 6
   │
   │   29 |   if (s->len >= s->cap) if (!my_str_realloc(s, s->cap * 2))
return false;
   │  |  ^
   │  |  |
   │  |  (6) calling 'my_str_realloc'
from 'my_str_push_char'
   │
   └──> 'my_str_realloc': events 7-13
  │

[Bug analyzer/115436] False positive with -Wanalyzer-malloc-leak

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-11
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

I think there *might* be a true positive here for the case where s->cap ==
0x8000, so that s->cap * 2 becomes 0 due to overflow; should my_str_realloc
be checking for s->str being null for the "needs malloc" case?

Otherwise, confirmed with trunk using Compiler Explorer:
https://godbolt.org/z/c3vEYf6do

Looks like
(a) it's not "realizing" that s->cap must be non-zero after the first alloc
(with the caveat about overflow noted above)

(b) there's a definite bug in binding_map, where __analyzer_dump () shows an
overlapping concrete binding:

clusters within root region
  cluster for: (*INIT_VAL(s_2(D)))
ESCAPED
key:   {bytes 0-7}
value: 'char *' {UNKNOWN(char *)}
key:   {bytes 0-23}
value: 'struct my_str' {UNKNOWN(struct my_str)}
key:   {bytes 16-23}
value: 'unsigned int' {UNKNOWN(unsigned int)}

where the binding for bytes 0-23 overlaps that for bytes 0-7.

[Bug tree-optimization/115447] GCC fails to tail call unless variable wrapped in a block

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

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

--- Comment #3 from Andrew Pinski  ---
Note if you don't do the assignment (to extend the lifetime of the temp), GCC
does tail calls bar unlike clang/LLVM.

[Bug tree-optimization/115447] GCC fails to tail call unless variable wrapped in a block

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
> Putting the variable inside this block does not change the semantics of the 
> function

YES it does, the side effect of the dtor happens after bar in the original case
and before bar in the second case. They could have side effects on global
memory that is outside of what the front-end knows.

[Bug tree-optimization/115447] GCC fails to tail call unless variable wrapped in a block

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 58408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58408&action=edit
testcase from godbolt

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #16 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:6bc26cceb243c6f359f65a1afa5515f911f3327d

commit r15-1189-g6bc26cceb243c6f359f65a1afa5515f911f3327d
Author: Gerald Pfeifer 
Date:   Wed Jun 12 00:04:09 2024 +0200

doc: Remove redundant introduction of x86-64

The same sentence as in the x86_64-*-solaris2* section is in the
x86_64-*-* section directly above.

gcc:
PR target/69374
* doc/install.texi (Specific) : Remove
redundant introduction of x86-64.

[Bug ipa/115447] New: GCC fails to tail call unless variable wrapped in a block

[mikolajpirog at gmail dot com via Gcc-bugs]

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

Bug ID: 115447
   Summary: GCC fails to tail call unless variable wrapped in a
block
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikolajpirog at gmail dot com
  Target Milestone: ---

GCC 14.1 fails to perform a tail call optimization when a function has a
variable with a non-trivial dtor, unless the variable is put inside a block
statement. Putting the variable inside this block does not change the semantics
of the function, but makes the dtor fire up before calling the next function,
so TCO may be performed. Compiler explorer: https://godbolt.org/z/r6TvsG3W4

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

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

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

--- Comment #3 from Lewis Hyatt  ---
(In reply to Brecht Sanders from comment #2)
> I have made a native Windows MinGW-w64 build where the lines "gcc_assert
> (!the_parser);" were commented out in file gcc/cp/parser.cc and got
> confirmation this successfully works around the issue.

Thanks! Do you mind please confirming, are you building it with the following
downstream patch in place (which is not part of GCC itself as of now):
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0021-PR14940-Allow-a-PCH-to-be-mapped-to-a-different-addr.patch
? If so, it would be interesting if possible to confirm whether the assert
still triggers without that patch.

[Bug c++/115446] [15 Regression] Segfault when exporting operator new

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

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

--- Comment #1 from Andrew Pinski  ---
s/unsigned long/decltype(sizeof(0))/

to make the testcase more portable since not all targets use `unsigned long` as
size_t.

[Bug c++/115446] [15 Regression] Segfault when exporting operator new

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/115446] New: [15 Regression] Segfault when exporting operator new

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 115446
   Summary: [15 Regression] Segfault when exporting operator new
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

$ cat op_new.cpp
module;

void* operator new(unsigned long, void*);

namespace std
{
template
auto construct_at(_Tp*) -> decltype(::new((void*)0) _Tp())
{
return new _Tp();
}

void use(int*p)
{
construct_at(p);
}
}

export module std;

export
{
using ::operator new;
}

$ g++ -Wno-global-module -fmodules-ts -std=c++2b -c op_new.cpp

'
Segmentation fault
9 | auto construct_at(_Tp*) -> decltype(::new((void*)0) _Tp())
  | ^
0x26c45cc internal_error(char const*, ...)
???:0
0xc06a7a lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
???:0
0xa93fde build_operator_new_call(tree_node*, vec**, tree_node**, tree_node**, tree_node*, tree_node*, tree_node**,
int)
???:0
0xb8c6f0 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xcb2a28 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x26ed6c4 pp_format(pretty_printer*, text_info*, urlifier const*)
???:0
0x26f06a5 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x26c2e7a diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x26c45cc internal_error(char const*, ...)
???:0
0x972a48 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xbf6a6d name_lookup::add_overload(tree_node*)
???:0
0xbf6ce4 name_lookup::process_binding(tree_node*, tree_node*)
???:0
0xc00ce2 name_lookup::search_namespace(tree_node*)
???:0
0xc00de0 name_lookup::search_qualified(tree_node*, bool)
???:0
0xc06a70 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
???:0
0xa93fde build_operator_new_call(tree_node*, vec**, tree_node**, tree_node**, tree_node*, tree_node*, tree_node**,
int)
???:0
0xb8c6f0 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xca6373 instantiate_decl(tree_node*, bool, bool)
???:0
0xcd08eb instantiate_pending_templates(int)
???:0
0xb690f0 c_parse_final_cleanups()
???:0


Works fine on gcc-14.
Reduced from an implementation of "std" module:

module;

#include 

export module std;

export
{
using ::operator new;
}

[Bug driver/115440] unrecognized command-line option '--c++17'; did you mean '--stdc++17'?

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Untested fix:
--- gcc/opts-common.cc.jj   2024-05-21 10:19:35.694512065 +0200
+++ gcc/opts-common.cc  2024-06-11 23:10:43.428656210 +0200
@@ -524,6 +524,7 @@ add_misspelling_candidates (auto_vecsafe_push (alternative);
}
 }
In my limited understanding, if opt1 is non-NULL in option_map, so the
{ "--machine", "", "-m", false, false },
{ "--machine", "no-", "-m", false, true },
...
{ "--std", "", "-std=", false, false },
entries, I think that is about mapping --machine foobar to -mfoobar or
--machine no-foobar to -mfoobar or --std foobar to -std=foobar
We do accept --std c++17 with the same meaning as -std=c++17 but just don't add
the space in between because opt1 is for the case where the option is present
as two separate options.

[Bug target/114905] aarch64 locally_streaming function ICE in dwarf2cfi due to mismatched CFA instructions in prologue/epilogue

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-11

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

Note it looks like the location of the attributes is not correct according to
the ACLE though.
```
#include 
__arm_locally_streaming
void
no_gprs_saved_very_streaming (__SVBool_t x)
__arm_streaming_compatible
{
  asm ("");
}
```

is the corrected testcase and yes we still ICE.

[Bug sanitizer/115205] ICE when using -fsanitize=hwaddress

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

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

--- Comment #5 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652975.html

[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1

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

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

--- Comment #2 from Peter Bergner  ---
(In reply to Jeffrey A. Law from comment #1)
> It looks like the test wants to see xxsel, but after that change we get
> xxlor and  what looks like a slight difference in register allocation.  I
> can't really judge if the new code is better, worse is equivalent.

xxsel XT,XA,XB,XC computes XT = (XA & ~XC) | (XB & XC).  Using De Morgan's law
given XB == XC, that seems to simplify to XT = XA | XB which is what you're
producing and an xxlor (a simple logical or) is not going to be slower than a
xxsel and is probably faster.  I agree with Bill that this looks like an
example of needing to update the expected results of the test case.  I'll let
Segher and/or Ke Wen comment though.

[Bug c++/115445] New: [15 Regression] ICE when repeating an export of function declared in GMF

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 115445
   Summary: [15 Regression] ICE when repeating an export of
function declared in GMF
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

$ cat repeated_using.cpp

module;

namespace std
{
void make_error_code();
}

export module std;

export namespace std
{
using std::make_error_code;
using std::make_error_code;
}

$ g++ -Wno-global-module -fmodules-ts repeated_using.cpp

:13:16: internal compiler error: tree check: expected overload, have
function_decl in lookup_maybe_add, at cp/tree.cc:2533
   13 | using std::make_error_code;
  |^~~
0x26c45cc internal_error(char const*, ...)
???:0
0x972a48 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xbf6a6d name_lookup::add_overload(tree_node*)
???:0
0xbf6ce4 name_lookup::process_binding(tree_node*, tree_node*)
???:0
0xc00ce2 name_lookup::search_namespace(tree_node*)
???:0
0xc00de0 name_lookup::search_qualified(tree_node*, bool)
???:0
0xc0654f finish_nonmember_using_decl(tree_node*, tree_node*)
???:0
0xc6eb8a c_parse_file()
???:0
0xdc51d9 c_common_parse_file()
???:0

This is a recent regression - didn't occur in 20250526 snapshot.

[Bug libstdc++/115444] New: std::copy_n generates more code than needed

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 115444
   Summary: std::copy_n generates more code than needed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/1Yo3h3rqW
#include 
#include 

struct It {
explicit It();
It& operator++();
It operator++(int);
It& operator--();
It operator--(int);
const int& operator*() const;
const int& operator[](int) const;
friend It operator+(int, const It&);
friend It operator+(const It&, int);
friend It operator-(const It&, int);
int operator-(const It&) const;
It& operator+=(int);
It& operator-=(int);
bool operator==(const It&) const;
std::strong_ordering operator<=>(const It&) const;
using difference_type = int;
using value_type = int;
using reference = int&;
using pointer = int*;
#ifdef LESS
using iterator_category = std::bidirectional_iterator_tag;
#endif
};

void simple_copy(It first, int n, int *dest) {
std::copy_n(first, n, dest);
}

Compiled with `-std=c++20 -DLESS`, this produces the codegen I'd expect: a
single loop calling `It::operator++()` and `It::operator*()` and no other
user-defined operations. That is, we pass in the `n`, it loops `n` times, we're
done. This is perfect.

But if you compile with `-std=c++20 -ULESS`, you get more verbose codegen:
first a call to `It::operator+(int)`, then a call to `It::operator-(It)`, and
then the same loop as before. That is, it appears that libstdc++ is "lowering"
`std::copy_n(first, n, dest)` into `std::copy(first, first+n, dest)` and then
"lowering" that back into `std::copy_n(first, first+n - first, dest)` before
finally getting to the loop. It would be nice not to do this.

This was reported on Slack by Alfredo Correa, whose iterators allegedly have
expensive (still O(1), but expensive) `+` and `-` operations.



Sidebar: Alfredo also reports that he's trying to use `copy_n` with iterators
where maybe `first + n` isn't even computable — like, he's expecting that the
following program should have well-defined behavior.

// https://godbolt.org/z/zfq36Ker6
struct Dynamite {
int value_;
void operator=(Dynamite d) {
if (d.value_ == -1) throw "Success!";
value_ = d.value_;
}
};

int main() {
const Dynamite s[4] = {{1},{2},{3},{-1}};
Dynamite d[4] = {};
try {
std::copy_n(s, 1000, d);
assert(false);
} catch (const char *s) {
assert(d[0].value_ == 1);
assert(d[1].value_ == 2);
assert(d[2].value_ == 3);
puts(s);
}
}

Today, this program forms the invalid pointer value (s+1000) inside libstdc++'s
`std::copy_n`. I think it's within its rights to do that, and thus the behavior
of this program is undefined by the standard (specifically,
https://eel.is/c++draft/alg.copy#12 doesn't claim that it *is* defined, so it's
undefined). But I'd still encourage libstdc++ to make programs like this Just
Work.

[Bug testsuite/115443] New: aarch64: Test gcc.dg/vect/pr99102.c FAIL

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

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

Bug ID: 115443
   Summary: aarch64: Test gcc.dg/vect/pr99102.c FAIL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

We see a FAIL on a machine with SVE support:

FAIL: gcc.dg/vect/pr99102.c -flto -ffat-lto-objects  scan-tree-dump vect
"MASK_SCATTER_STORE"
FAIL: gcc.dg/vect/pr99102.c scan-tree-dump vect "MASK_SCATTER_STORE"

I suspect -- and pardon me if I'm wrong, I don't have a SVE box handy -- the
test will fail on an ARMv8 box:

# gcc -march=armv9-a  pr99102.c  -O2 -ftree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details -msve-vector-bits=256; grep MASK_SCATTER_STORE
a-pr99102.c.172t.vect
pr99102.c:9:29: note:  add new stmt: .MASK_SCATTER_STORE (vectp_a.13_69, { 0,
4, 8, 12 }, 8, vect_cst__12, vect_cst__68);
Value numbering stmt = .MASK_SCATTER_STORE (vectp_a.13_69, { 0, 4, 8, 12 }, 8,
vect_cst__12, vect_cst__68);
  .MASK_SCATTER_STORE (vectp_a.13_69, { 0, 4, 8, 12 }, 8, vect_cst__12,
vect_cst__68);

but

# gcc -march=armv8-a  pr99102.c  -O2 -ftree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details -msve-vector-bits=256; grep MASK_SCATTER_STORE
a-pr99102.c.172t.vect
#

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

[ismael at linux dot com via Gcc-bugs]

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

Ismael Luceno  changed:

   What|Removed |Added

  Attachment #58406|0   |1
is obsolete||

--- Comment #9 from Ismael Luceno  ---
Created attachment 58407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58407&action=edit
Avoid  poisoning on musl

Attaching the patch as shipped by Source Mage GNU/Linux.

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:6eb0e931097a8fec01591051c9ef582d52fe7f0c

commit r13-8842-g6eb0e931097a8fec01591051c9ef582d52fe7f0c
Author: Andrew Pinski 
Date:   Tue Jun 11 12:30:01 2024 -0700

Fix building JIT with musl libc [PR115442]

Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc.

Pushed as obvious after a quick build to make sure jit still builds.

gcc/jit/ChangeLog:

PR jit/115442
* jit-recording.cc: Define INCLUDE_SSTREAM before including
system.h and don't directly incldue sstream.

Signed-off-by: Andrew Pinski 
(cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Andrew Pinski
:

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

commit r14-10304-ge6b1c0820590a1f330099ed7560982b5c6da4e91
Author: Andrew Pinski 
Date:   Tue Jun 11 12:30:01 2024 -0700

Fix building JIT with musl libc [PR115442]

Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc.

Pushed as obvious after a quick build to make sure jit still builds.

gcc/jit/ChangeLog:

PR jit/115442
* jit-recording.cc: Define INCLUDE_SSTREAM before including
system.h and don't directly incldue sstream.

Signed-off-by: Andrew Pinski 
(cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r15-1188-ge4244b88d75124f6957bfa080c8ad34017364e53
Author: Andrew Pinski 
Date:   Tue Jun 11 12:30:01 2024 -0700

Fix building JIT with musl libc [PR115442]

Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc.

Pushed as obvious after a quick build to make sure jit still builds.

gcc/jit/ChangeLog:

PR jit/115442
* jit-recording.cc: Define INCLUDE_SSTREAM before including
system.h and don't directly incldue sstream.

Signed-off-by: Andrew Pinski 

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Robin Dapp from comment #6)
> Are you going to post a patch?

I was going to let the arm folks take care of it since I have no way to test
it.

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

--- Comment #6 from Robin Dapp  ---
Looks reasonable.  That's what we were doing before in internal-fn.cc before
expanding (except operands[2]).

Are you going to post a patch?

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

[ismael at linux dot com via Gcc-bugs]

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

--- Comment #5 from Ismael Luceno  ---
Applies fine to 14.1.0  too. Thanks.

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

[ismael at linux dot com via Gcc-bugs]

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

--- Comment #4 from Ismael Luceno  ---
I see, I didn't see your comment before attaching it; I had already come up
with that patch before filing the bug.

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Ismael Luceno from comment #2)
> Created attachment 58406 [details]
> Avoid  poisoning on musl

That is not the correct fix. see comment #1 for the correct one.

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

[ismael at linux dot com via Gcc-bugs]

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

--- Comment #2 from Ismael Luceno  ---
Created attachment 58406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58406&action=edit
Avoid  poisoning on musl

[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-11
 Status|UNCONFIRMED |ASSIGNED
   Assignee|dmalcolm at gcc dot gnu.org|pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
I have an obvious fix at least for the trunk.

diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 68a2e860c1f..70830e34965 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */

 #include "config.h"
+#define INCLUDE_SSTREAM
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
@@ -29,7 +30,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "jit-builtins.h"
 #include "jit-recording.h"
 #include "jit-playback.h"
-#include 

 namespace gcc {
 namespace jit {

[Bug d/115295] [15 regression] Various gdc testsuite regressions

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

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Alexandre Oliva from comment #2)
> Ugh, it looks like D deviates from one of the fundamental assumptions behind
> the change, namely, that for each named source file, the compiler would
> attempt to generate one (set of) output files, so when not linking, an
> explicitly named output file would be rejected by the compiler.
> 
> I suppose we could make the new behavior of omitting additional sources in
> compile tests dependent on the input language.

This is because D (and at a glance Go and Rust too) sets this setting in
lang-specs.h

```
int combinable;   /* If nonzero, compiler can deal with
 multiple source files at once (IMA).  */
```

[Bug c++/115442] New: gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"

[ismael at linux dot com via Gcc-bugs]

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

Bug ID: 115442
   Summary: gcc/jit/jit-recording.cc fails to build against musl:
attempt to use poisoned "calloc"
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ismael at linux dot com
  Target Milestone: ---

Build error:
/usr/src/gcc-14.1.0.bld/./prev-gcc/xg++
-B/usr/src/gcc-14.1.0.bld/./prev-gcc/ -B/usr/x86_64-pc-linux-musl/bin/
-nostdinc++
-B/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/src/.libs
-B/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/libsupc++/.libs
 -isystem
/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/include/x86_64-pc-linux-musl
 -isystem
/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/include 
-isystem /usr/src/gcc-14.1.0/libstdc++-v3/libsupc++
-L/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/src/.libs
-L/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/libsupc++/.libs
-fcf-protection -fPIC -c  -DIN_GCC_FRONTEND -march=native -mtune=native -m64 
-fPIC -Os -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -fPIC -I. -Ijit
-I/usr/src/gcc-14.1.0/gcc -I/usr/src/gcc-14.1.0/gcc/jit
-I/usr/src/gcc-14.1.0/gcc/../include 
-I/usr/src/gcc-14.1.0/gcc/../libcpp/include
-I/usr/src/gcc-14.1.0/gcc/../libcody -I//include -I//include -I/usr/include 
-I/usr/src/gcc-14.1.0/gcc/../libdecnumber
-I/usr/src/gcc-14.1.0/gcc/../libdecnumber/bid -I../libdecnumber
-I/usr/src/gcc-14.1.0/gcc/../libbacktrace
-I/usr/src/gcc-14.1.0.bld/./isl/include -I/usr/src/gcc-14.1.0/isl/include  -o
jit/jit-recording.o -MT jit/jit-recording.o -MMD -MP -MF
jit/.deps/jit-recording.TPo /usr/src/gcc-14.1.0/gcc/jit/jit-recording.cc
In file included from /usr/include/pthread.h:30,
 from
/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/include/x86_64-pc-linux-musl/bits/gthr-default.h:35,
 from
/usr/src/gcc-14.1.0.bld/prev-x86_64-pc-linux-musl/libstdc++-v3/include/x86_64-pc-linux-musl/bits/gthr.h:157,
 from
/usr/src/gcc-14.1.0/libstdc++-v3/include/ext/atomicity.h:35,
 from
/usr/src/gcc-14.1.0/libstdc++-v3/include/bits/ios_base.h:39,
 from
/usr/src/gcc-14.1.0/libstdc++-v3/include/std/ios:44,
 from
/usr/src/gcc-14.1.0/libstdc++-v3/include/std/istream:40,
 from
/usr/src/gcc-14.1.0/libstdc++-v3/include/std/sstream:40,
 from /usr/src/gcc-14.1.0/gcc/jit/jit-recording.cc:32:
/usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
In file included from /usr/src/gcc-14.1.0/gcc/jit/jit-recording.cc:22:
/usr/src/gcc-14.1.0/gcc/system.h:938:21: note: poisoned here
  938 |  #pragma GCC poison calloc strdup strndup
  | ^~
/usr/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)))
  |^
/usr/src/gcc-14.1.0/gcc/system.h:938:21: note: poisoned here
  938 |  #pragma GCC poison calloc strdup strndup
  | ^~

[Bug other/115437] Wrong optimized code - GCC didn't detect a variable is modified

[Explorer09 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kang-Che Sung  ---
Now I come to realize that the C standard doesn't say that a pointer type is
"compatible" with any other pointer type. So that "Foo **" type and "Bar **"
type are assumed to never alias. This is troubling because I saw many APIs that
would take a "pointer to pointer" argument in order to output address to a
particular object (for example, asprintf()), and it would be difficult to write
concise code while strictly conforming to the so-called strict aliasing rule.

[Bug driver/115440] unrecognized command-line option '--c++17'; did you mean '--stdc++17'?

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

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

--- Comment #2 from Jonathan Wakely  ---
People certainly do write --std, I see it all the time. I don't like it though.

[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

[kristian.spangsege at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Kristian Spangsege  
---
These changes look good to me.

A couple of points:
* Should the `else`s still be there now that the preceding branches terminate
with `break`?
* `do_out()` has the same problem as `do_in()`.
* If there is already testing of `codecvt`, should a test be added for the
"empty output" case?
* This could break code that expects the incorrect behavior.

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> I think something like this:
> ```
> [apinski@xeond2 arm]$ git diff mve.md
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index 9fe51298cdc..8af4797e935 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -6897,6 +6897,12 @@ (define_expand "vcond_mask_"
>   (match_operand:MVE_VLD_ST 2 "s_register_operand")))]
>"TARGET_HAVE_MVE"
>  {
> +  if (!register_operand (operands[3], mode))
> +operands[3] = force_reg (operands[3]);
> +  if (!register_operand (operands[1], mode))
> +operands[1] = force_reg (operands[1]);
> +  if (!register_operand (operands[2], mode))
> +operands[1] = force_reg (operands[2]);

copy and pasto:`operands[1] = force_reg (operands[1]);` is the correct line for
above.

>switch (GET_MODE_CLASS (mode))
>  {
>case MODE_VECTOR_INT:
> 
> ```
> Signed-off-by: Andrew Pinski  

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

--- Comment #4 from Andrew Pinski  ---
I think something like this:
```
[apinski@xeond2 arm]$ git diff mve.md
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 9fe51298cdc..8af4797e935 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -6897,6 +6897,12 @@ (define_expand "vcond_mask_"
  (match_operand:MVE_VLD_ST 2 "s_register_operand")))]
   "TARGET_HAVE_MVE"
 {
+  if (!register_operand (operands[3], mode))
+operands[3] = force_reg (operands[3]);
+  if (!register_operand (operands[1], mode))
+operands[1] = force_reg (operands[1]);
+  if (!register_operand (operands[2], mode))
+operands[1] = force_reg (operands[2]);
   switch (GET_MODE_CLASS (mode))
 {
   case MODE_VECTOR_INT:

```
Signed-off-by: Andrew Pinski  

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

[carlos.seo at linaro dot org via Gcc-bugs]

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

--- Comment #3 from Carlos Eduardo Seo  ---
(In reply to Robin Dapp from comment #2)
> We already discussed that briefly on the mailing list.  Richard Sandiford
> suspected a target bug.  What options do I need to configure GCC in order to
> reproduce that locally?

You can reproduce exactly what is being done by the CI by following:
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/7ca35f2e430081d6ec91e910002f92d9713350fa/tcwg_gnu_embed_check_gcc/master-thumb_m55_hard_eabi/reproduction_instructions.txt

If you prefer to do it manually:

configure  SHELL=/bin/bash \
   
--with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
\
   
--with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
\
   
--with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
\
--with-gnu-as \
--with-gnu-ld \
--disable-libmudflap \
--enable-lto \
--enable-shared \
--without-included-gettext \
--enable-nls \
--with-system-zlib \
--disable-sjlj-exceptions \
--enable-gnu-unique-object \
--enable-linker-build-id \
--disable-libstdcxx-pch \
--enable-c99 \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-long-long \
--with-cloog=no \
--with-ppl=no \
--with-isl=no \
--enable-threads=no \
--disable-multiarch \
--disable-multilib \
--with-mode=thumb \
--with-arch=armv8.1-m.main+mve.fp+fp.dp \
--with-float=hard \
   
--with-sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi
\
--with-headers=yes \
--with-native-system-header-dir=/include \
--with-newlib \
--enable-checking=yes \
--disable-bootstrap \
--enable-languages=c,c++,lto \
   
--prefix=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
\
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \
--target=arm-eabi

[Bug tree-optimization/115382] Wrong code with in-order conditional reduction and masked loops

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:2b438a0d2aa80f051a09b245a58f643540d4004b

commit r15-1187-g2b438a0d2aa80f051a09b245a58f643540d4004b
Author: Robin Dapp 
Date:   Fri Jun 7 14:36:41 2024 +0200

vect: Merge loop mask and cond_op mask in fold-left reduction [PR115382].

Currently we discard the cond-op mask when the loop is fully masked
which causes wrong code in
gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
when compiled with
-O3 -march=cascadelake --param vect-partial-vector-usage=2.

This patch ANDs both masks.

gcc/ChangeLog:

PR tree-optimization/115382

* tree-vect-loop.cc (vectorize_fold_left_reduction): Use
prepare_vec_mask.
* tree-vect-stmts.cc (check_load_store_for_partial_vectors):
Remove static of prepare_vec_mask.
* tree-vectorizer.h (prepare_vec_mask): Export.

[Bug middle-end/115428] 3 * unused in today's build

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

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

--- Comment #3 from Andrew Pinski  ---
I can't figure out why GCC didn't warn about summary_cast_reg though ...

[Bug middle-end/115428] 3 * unused in today's build

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44598,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52105

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> The reason why has_pointer_operand_p is not warned about is because it is a
> `static inline` function which GCC will never warn about. Looks like clang
> only warns about them if they are in a main source.

See PR 52105 for that.

> 
> The reason why relation_to_code is not warned about is a similar reasons but
> this time for `static const` variables.

This one see PR 44598.

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #35 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

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

commit r12-10548-ga995fded34fe488153b06bb41e026277f01efded
Author: Francois-Xavier Coudert 
Date:   Thu Mar 7 14:36:03 2024 +0100

Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as , , etc, causes many compilation
errors, similar to:

  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from
  /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from
  /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute
  only applies to structs, variables, functions, and namespaces
546 | _LIBCPP_INLINE_VISIBILITY
| ^
  /usr/include/c++/v1/__config:813:37: note: expanded from macro
  '_LIBCPP_INLINE_VISIBILITY'
813 | #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
| ^
  /usr/include/c++/v1/__config:792:26: note: expanded from macro
  '_LIBCPP_HIDE_FROM_ABI'
792 |
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(
  _LIBCPP_VERSIONED_IDENTIFIER
|  ^
  In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
  In file included from /home/dim/src/gcc/master/gcc/system.h:233:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from
  /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from
  /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of
  declaration list
547 | char_type toupper(char_type __c) const
| ^
  /usr/include/c++/v1/__locale:553:48: error: too many arguments
  provided to function-like macro invocation
553 | const char_type* toupper(char_type* __low, const
char_type* __high) const
|^
  /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note:
  macro 'toupper' defined here
146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
| ^

This is because libc++ uses different transitive includes than
libstdc++, and some of those transitive includes pull in various ctype
declarations (typically via ).

There was already a special case for including  before
safe-ctype.h, so move the rest of the C++ standard header includes to
the same location, to fix the problem.

PR middle-end/111632

gcc/ChangeLog:

* system.h: Include safe-ctype.h after C++ standard headers.

Signed-off-by: Dimitry Andric 
(cherry picked from commit 9970b576b7e4ae337af1268395ff221348c4b34a)

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

--- Comment #34 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:8f11ed1c58e14421ba4be1652764fc47fdce8dc7

commit r12-10547-g8f11ed1c58e14421ba4be1652764fc47fdce8dc7
Author: Francois-Xavier Coudert 
Date:   Sat Mar 16 09:50:00 2024 +0100

libcc1: fix  include

Use INCLUDE_VECTOR before including system.h, instead of directly
including , to avoid running into poisoned identifiers.

Signed-off-by: Dimitry Andric 

PR middle-end/111632

libcc1/ChangeLog:

* libcc1plugin.cc: Fix include.
* libcp1plugin.cc: Fix include.

(cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)

[Bug c/115428] 3 * unused in today's build

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

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

--- Comment #1 from Andrew Pinski  ---
The reason why has_pointer_operand_p is not warned about is because it is a
`static inline` function which GCC will never warn about. Looks like clang only
warns about them if they are in a main source.

The reason why relation_to_code is not warned about is a similar reasons but
this time for `static const` variables.

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #2 from Robin Dapp  ---
We already discussed that briefly on the mailing list.  Richard Sandiford
suspected a target bug.  What options do I need to configure GCC in order to
reproduce that locally?

[Bug c++/115431] ICE: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in decl_template_parm_check, at cp/cp-tree.h:5131

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||115331

--- Comment #1 from Andrew Pinski  ---
Might be a dup of bug 115331.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331
[Bug 115331] [13/14/15 Regression] ICE-on-invalid passing a typoed lambda to a
list-initializer

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654086.html

[Bug target/115439] [15 Regression] ICEs after r15-638 on master-thumb_m55_hard_eabi

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm-eabi
  Component|c++ |target
Summary|[Regression] ICEs after |[15 Regression] ICEs after
   |7ca35f2e43 on   |r15-638 on
   |master-thumb_m55_hard_eabi  |master-thumb_m55_hard_eabi
   Keywords||ice-on-valid-code
   Target Milestone|--- |15.0

[Bug c/95715] __atomic_fetch_add accepts nonsense arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com

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

[Bug c/115441] Pointer/integer mismatch in __atomic_fetch-* not covered by -Wint-conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Actually yes it is a dup of bug 95715, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95715#c1 .

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

[Bug c/115441] Pointer/integer mismatch in __atomic_fetch-* not covered by -Wint-conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95715

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 95715.

[Bug c++/68615] Unhelpful location when missing a semi-colon on a function declaration at the end of a header

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #9 from Andi Kleen  ---
*** Bug 82013 has been marked as a duplicate of this bug. ***

[Bug c/82013] better error message for missing semicolon in prototype

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #8 from Andi Kleen  ---
Duplicate

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

[Bug driver/115440] unrecognized command-line option '--c++17'; did you mean '--stdc++17'?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug target/80742] attribute target no- does not work

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|WAITING |RESOLVED

[Bug c/115441] New: Pointer/integer mismatch in __atomic_fetch-* not covered by -Wint-conversion

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 115441
   Summary: Pointer/integer mismatch in __atomic_fetch-* not
covered by -Wint-conversion
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
void foo(int *x, int *y)
{
__atomic_fetch_add(x, y, __ATOMIC_SEQ_CST);
}

Godbolt:
https://godbolt.org/z/1czvaxMTd

[Bug middle-end/63556] gcc should dedup string postfixes

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Andi Kleen  ---
Since the linker does it the change is not needed.

[Bug rtl-optimization/30688] Branch registers loaded too late on ia64

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Andi Kleen  ---
ia64 is obsolete

[Bug driver/115440] New: unrecognized command-line option '--c++17'; did you mean '--stdc++17'?

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 115440
   Summary: unrecognized command-line option '--c++17'; did you
mean '--stdc++17'?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

This is merely a very minor glitch in an error message. But I keep noticing it
when I accidentally use an EDG-style "--c++11, --c++14, ..." option with GCC
instead of the correct "-std=c++11, -std=c++14, ...".

% g++ --c++17 test.cpp
g++: error: unrecognized command-line option '--c++17'; did you mean
'--stdc++17'?
% g++ --stdc++17 test.cpp
g++: error: unrecognized command-line option '--stdc++17'

Instead of "--stdc++XX" it should be suggesting "-std=c++17" (one dash, equals
sign).  (Two dashes "--std=c++XX" does also work, but ~nobody writes that in
real life, so I don't think the driver should suggest that anybody start.)

[Bug c++/115439] New: [Regression] ICEs after 7ca35f2e43 on master-thumb_m55_hard_eabi

[carlos.seo at linaro dot org via Gcc-bugs]

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

Bug ID: 115439
   Summary: [Regression] ICEs after 7ca35f2e43 on
master-thumb_m55_hard_eabi
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlos.seo at linaro dot org
  Target Milestone: ---

Commit 7ca35f2e43 (internal-fn: Do not force vcond_mask operands to reg) causes
the following crashes in the testsuite on master-thumb_m55_hard_eabi

FAIL: 18 regressions

regressions.sum:
=== g++ tests ===

Running g++:g++.dg/dg.exp ...
FAIL: c-c++-common/vector-compare-3.c -std=gnu++14 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++17 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++20 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++20 (test for excess errors)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++98 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: c-c++-common/vector-compare-3.c -std=gnu++98 (test for excess errors)
FAIL: g++.dg/opt/pr79734.C -std=gnu++14 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: g++.dg/opt/pr79734.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/pr79734.C -std=gnu++17 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: g++.dg/opt/pr79734.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/pr79734.C -std=gnu++20 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: g++.dg/opt/pr79734.C -std=gnu++20 (test for excess errors)
FAIL: g++.dg/opt/pr79734.C -std=gnu++98 (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: g++.dg/opt/pr79734.C -std=gnu++98 (test for excess errors)
=== gcc tests ===

Running gcc:gcc.dg/dg.exp ...
FAIL: c-c++-common/vector-compare-3.c -Wc++-compat  (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: c-c++-common/vector-compare-3.c -Wc++-compat  (test for excess errors)

Details:
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/436/artifact/artifacts/notify/mail-body.txt/*view*/

[Bug tree-optimization/115143] [11 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12 Regression] tree |[11 Regression] tree check:
   |check: expected class   |expected class 'type', have
   |'type', have 'exceptional'  |'exceptional' (error_mark)
   |(error_mark) in |in
   |useless_type_conversion_p,  |useless_type_conversion_p,
   |at gimple-expr.cc:85|at gimple-expr.cc:85
  Known to work||12.3.1

--- Comment #18 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #16)
> Fixed on the GCC 13 branch too. Backporting further requires removing the
> hunk that handles diamond bbs as that was not in 12 or 11. I will handle
> that tomorrow.

Fixed on the GCC 12 branch too now. Will handle 11 tomorrow.

[Bug tree-optimization/115143] [11/12 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

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

commit r12-10546-gd30afaae6764379a63c22459b40aaecfa82b0fc4
Author: Andrew Pinski 
Date:   Sat May 18 11:55:58 2024 -0700

PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143]

The problem here is even if last_and_only_stmt returns a statement,
the bb might still contain a phi node which defines a ssa name
which is used in that statement so we need to add a check to make sure
that the phi nodes are empty for the middle bbs in both the
`CMP?MINMAX:MINMAX` case and the `CMP?MINMAX:B` cases.

Bootstrapped and tested on x86_64_linux-gnu with no regressions.

PR tree-optimization/115143

gcc/ChangeLog:

* tree-ssa-phiopt.cc (minmax_replacement): Check for empty
phi nodes for middle bbs for the case where middle bb is not empty.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr115143-1.c: New test.
* gcc.c-torture/compile/pr115143-2.c: New test.
* gcc.c-torture/compile/pr115143-3.c: New test.

Signed-off-by: Andrew Pinski 
(cherry picked from commit 9ff8f041331ef8b56007fb3c4d41d76f9850010d)

[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|13.3|12.4

--- Comment #19 from Jonathan Wakely  ---
Fixed for 12.4 now anyway.

[Bug target/113042] popcount of 8bits and 128bits can be improved for !TARGET_CSSC

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

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

--- Comment #4 from Andrew Pinski  ---
New patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654115.html

[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 12.4 and 13.3

[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Also fixed for 12.4

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

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

https://gcc.gnu.org/g:874896659df65b4bdf85b3dbca0ab527bb4c920e

commit r12-10540-g874896659df65b4bdf85b3dbca0ab527bb4c920e
Author: Jonathan Wakely 
Date:   Tue Jul 4 16:03:45 2023 +0100

libstdc++: Fix std::__uninitialized_default_n for constant evaluation
[PR110542]

libstdc++-v3/ChangeLog:

PR libstdc++/110542
* include/bits/stl_uninitialized.h (__uninitialized_default_n):
Do not use std::fill_n during constant evaluation.

(cherry picked from commit 83cae6c4b788544635a71748e1881c150f42efef)